AI開発コネクト
無料で相見積もり
AI最新ニュースClaude・Anthropic

Claudeの不可視透かしが9月30日に対象拡大。AI納品物の検収はこう変わる

Claudeの不可視テキスト透かしが9月30日にSonnet 5などへ拡大しました。EU AI法第50条への対応で、コード本体には入らずドキュメントに入ります。検出APIは発注側に開かれていません。契約と検収で決める3点を整理します。

公開: 2026.09.30 ／ 更新: 2026.09.30

AI が書いた文章かどうかは、読んでも分からない。だが機械には分かる状態が、2026 年 9 月 30 日からまた一段広がった。納品物に AI を使ったかどうかが後から第三者に判定されうる、という前提で契約と検収を組み直す時期に来ている。

虫眼鏡をかざした部分にだけ浮かび上がる、紙の透かし

公表されている事実

Anthropic は 2026 年 8 月 11 日、Claude が生成するテキストに**不可視の透かし（ウォーターマーク）**を入れると公表した。9 月 30 日から、その対象モデルが広がっている。公表されている内容は次のとおりである。

  • 透かしの対象に、Claude Fable 5・Claude Sonnet 5・Claude Opus 4.8 が加わった（2026 年 9 月 30 日から）。すでに対象だったのは Claude Fable 5.1・Claude Mythos 5.1・Claude Opus 5.5・Claude Opus 5
  • 残る旧モデルも 12 月 2 日までに対応する予定とされている
  • 方式は Google DeepMind の SynthID-Text。同じくらい自然な語の候補が複数あるとき、暗号鍵に由来する乱数で選び方を偏らせる。意味・品質・可読性は変わらない
  • 対象モデルではモデル側で適用され、利用者が無効化できない
  • 厳密な出力が必要な箇所（数式や、動作する必要のあるコード）には透かしを入れない。ただしコード中のコメントには入りうる
  • 検出用の API はプライベートプレビューで、規制当局・法執行機関・研究者・報道機関など限られた組織・個人にだけ提供されている
  • 透かしが示すのは「Claude がその内容に何らかの形で関与した可能性が高い」ということだけである。「Claude が書いた」と「Claude が大幅に編集した」は区別できず、人間が書いたことの証明にもならない
  • テキストが長いほど判定の確度が上がる。軽い編集なら透かしは残り、全面的に書き直せば消える

背景にあるのは EU の AI 法である。生成 AI の出力に機械可読な印を付けることを求める第 50 条の透明性義務が 2026 年 8 月 2 日に適用開始となり、違反時の制裁金は最大 1,500 万ユーロ、または全世界売上高の 3% のいずれか高いほうとされている。Anthropic はこの対応を EU 域内に限らず世界共通で適用している、と報じられている。

論点 1. 透かしが示すのは「関与」だけで、品質でも権利でもない

まず、過剰に読まないことが大事である。透かしは「この文章の生成に Claude が関わった可能性が高い」以上のことを示さない。

  • 書いた人が誰かは示さない。 Claude に下書きさせて人が全面的に直したのか、人が書いた文章を Claude に整えさせたのかは区別できない
  • 品質の保証にも否定にもならない。 透かしの有無と、納品物が要件を満たすかどうかは無関係である
  • 著作権の帰属を変えない。 誰に権利があるかは契約で決まる話であり、透かしが入っているかどうかで動くものではない

したがって「透かしが見つかったから契約違反だ」という使い方は成り立たない。使えるのは逆向きで、AI をどこまで使ってよいかを事前に決めていなかったことが後から表面化する、という形である。

論点 2. 検出できるのは、いまのところ発注側ではない

実務上いちばん効くのはここである。検出 API はプライベートプレビューで、提供先は規制当局・法執行機関・研究者・報道機関などに限られている。発注側の企業が、納品物を自分で検査することは現時点でできない。

つまり、

  • 発注側は「透かしで検収する」運用を組めない。検収は従来どおり、要件との突き合わせで行うしかない
  • 一方で、第三者が判定できる可能性は残る。公開する文書・提案書・広報物については、外部から指摘される場面を想定しておく必要がある

この非対称が、しばらく続くと考えられる。自社では確かめられないが、外からは分かるかもしれない、という状態である。

論点 3. コードは対象外でも、ドキュメントは対象になる

「動作する必要のあるコードには入らない」という仕様は、AI 駆動開発の納品物を考えるうえで重要である。整理すると次のようになる。

納品物 透かしが入りうるか
動作するソースコード本体 入らないとされている
ソースコード中のコメント 入りうる
設計書・手順書・仕様書 入りうる
議事録・報告書・提案書 入りうる
数式・厳密な出力が要る箇所 入らないとされている

AI 開発の見積書では、納品物としてソースコードのほかに設計書・手順書・運用マニュアルが並ぶのが普通である。つまり、透かしの話はコードの話ではなく、ドキュメントの話として効いてくる。納品物の受け渡しで確認する項目はAI開発の引き継ぎ。保守移行で確認する12項目にまとめている。

発注者・企業への影響

第一に、「AI をどこまで使ってよいか」を発注時に決めておく。禁止するのか、使ってよいが申告させるのか、自由にしてよいのか。決めていないまま納品後に問題化すると、判断の基準が無いので水掛け論になる。多くの場合、禁止ではなく「使ってよい。ただし最終責任は受注側が負う」で足りるはずである。

第二に、開示の要否を、成果物の行き先で分ける。社内用の設計書と、外部に公開する広報物・申請書類では、求められる説明が違う。EU 向けにサービスを提供する場合は AI 法第 50 条の開示義務が直接かかるため、そこだけは別扱いにしておきたい。生成 AI にまつわる法的な論点は生成AIの法的リスクで整理している。

第三に、検収の基準を要件側に寄せる。透かしで検査できない以上、「AI が書いたかどうか」を検収条件にしても運用できない。要件との一致・テストの通過・運用手順の再現性といった、確かめられるもので受け入れを決めるほうが現実的である。

第四に、プロンプトや生成の設定も納品物に含めるか決める。ドキュメントが AI 由来であるなら、再生成や修正のためにプロンプトが要る。誰がそれを持つかはAI開発でコードとプロンプトは誰のものかの論点そのものである。

契約・検収で決める 3 点

  1. AI の利用範囲。コード・ドキュメント・調査資料のそれぞれで、AI の利用を認めるか、申告を求めるか
  2. 開示の扱い。外部に出す成果物について、AI 利用を明示するかどうか。EU 向け提供があるか
  3. 検収の基準。何をもって受け入れとするか。AI 利用の有無を条件に含めない代わりに、何を確かめるか

この 3 点は案件の条件として書き出せるので、複数社に同じ文面で聞ける。無料で相見積もりの案件票では、納品物と権利の扱いを選択式の項目として揃え、各社に同じ形式で答えてもらっている。

まとめ

不可視の透かしは、AI 利用を取り締まる道具として作られたものではなく、EU AI 法の透明性義務に応えるための表示である。示せるのは「関与した可能性が高い」ことだけで、品質も権利も語らない。それでも発注側にとって意味があるのは、今まで曖昧なままにしてきた「AI をどこまで使ってよいか」が、外から見える対象になった点である。対象モデルは 12 月 2 日までにさらに広がる予定とされている。規則を作るなら、その前が落ち着いている。

参考・出典

AI開発の見積もりを、同じ条件で比べる。

条件を整理した 1 枚の案件票で複数のAI開発会社に依頼。初期費用だけでなく、データ整備・API 費・精度検証・保守・権利まで同じ列で比較できます。

無料で相見積もりを始める →
無料で相見積もり30秒で費用診断