Claudeのテキスト透かしとは？LLMウォーターマークの仕組みとEU AI法対応を徹底解説

あなたが今読んでいるこの文章、AIが書いたものだと見分けられますか？

画像ならAI生成かどうかの検出ツールが普及し、音声でも合成音声を識別する技術が進んできました。しかしテキストは長らく「灰色地帯」でした。見た目に痕跡が残らず、人間が書いた文章とAIの出力を統計的な方法で区別することは、非常に困難な問題とされてきたのです。

2026年8月、Anthropicはこの問題に対する一つの回答を示しました。Claudeの出力にテキスト透かし（テキストウォーターマーク）を導入したのです。引き金となったのはEU AI法の施行期限（2026年8月2日）でしたが、注目すべきはAnthropicがこの機能をEU域内だけでなく全世界のユーザーに一律適用したという判断です。

この記事では次のことが理解できるようになります。

• テキスト透かしがどのような技術的原理で動作しているか
• EU AI法のAI生成コンテンツ開示要件と、Anthropicの対応戦略
• 品質への影響はどの程度か、そして何が本当の問題か
• コードや事実記述では効かないという決定的な限界
• KGW法・SynthID-Textなど類似手法との比較と技術の進化系譜

段階的に理解を深めていきましょう。

そもそもテキストウォーターマークとは何か

画像の透かしとの決定的な違い

透かし（ウォーターマーク）という言葉を聞いて、多くの方がまず思い浮かべるのは画像への応用でしょう。PNG画像やJPEG画像では、ピクセルの輝度値をごく微小な量だけ変化させることで、人間の目には見えない情報を埋め込むことができます。その変化は0.1%程度であっても統計的には十分に検出可能で、かつ見た目への影響はほぼゼロです。

テキストはまったく異なります。「天気が良いです」を「天気がよいです」に変えれば、意味は通じますが文体が変わります。「晴れ」を「晴天」に変えれば、ニュアンスが微妙にずれます。1文字、1語を変えるだけで意味・文体・ニュアンスが変わるテキストには、「見えない余白」が存在しないのです。

では、どこに情報を隠すのか。その答えが「どの単語を選ぶか、という選択の揺らぎ」です。

Unicode不可視文字方式が採用されない理由

一時期、AIが生成したテキストに不可視のUnicode文字（ゼロ幅スペースや同形字など）を挿入して識別情報を埋め込む方式が話題になりました。この方式の利点は実装が簡単な点にありますが、致命的な弱点があります。

コピー＆ペーストをしてテキストエディタに貼り付けるだけで消える場合があります。また、「不可視文字を除去するスクリプト」は数十行のコードで書けてしまいます。さらに、別のLLMに「この文章を書き直して」と頼むだけでもすべて消えます。

Claudeが採用したのはこうした「文字を足す方式」ではなく、統計的ウォーターマークと呼ばれる根本的に異なるアプローチです。

技術的原理：「乱数のソース」を差し替える

LLMはそもそも確率的にトークンを選んでいる

まず、大規模言語モデル（LLM）がどのように文章を生成しているかを確認しておきましょう。

LLMは文章を「トークン」と呼ばれる小さな単位（単語や形態素など）に分解して処理します。次のトークンを生成する際、モデルは過去のすべてのトークンを参照し、「次にどのトークンが来る確率が高いか」を表す確率分布を計算します。

たとえば「今日はとても良い」に続くトークンとして、「天気」「日」「気分」「一日」「お天気」などの選択肢がそれぞれ一定の確率で候補に挙がります。どれを選ぶかは、その確率分布からサンプリング（無作為抽出）することで決定されます。

この「サンプリングの自由度」こそが、透かしを埋め込む余白です。

通常の生成と透かし付き生成の対比

通常の生成では、真の乱数生成器が確率分布からトークンを選びます。一方、透かし付き生成では以下のようなプロセスが走ります。

通常の生成:
  確率分布 → 真の乱数 → トークン選択

透かし付き生成:
  確率分布 → [秘密鍵 + 直前の数語] → 疑似乱数 → トークン選択

ここで最も重要なのは、確率分布そのものは変えない（distribution-preserving）という点です。「天気」と「日」の選ばれやすさの比率は変わりません。変わるのは「どちらを選ぶか」を決定する乱数のソースだけです。

秘密鍵を持つAnthropicだけが、「この文章の単語選択列は偶然のパターンではなく、特定の秘密鍵から導かれた疑似乱数に基づいている」ということを統計的に検証できます。秘密鍵を知らない第三者には、その選択が自然なランダム性によるものか、透かしによるものかを区別できません。

なぜ数百トークンが必要なのか

1単語の選択だけでは、「偶然そのトークンが選ばれた」という説明が十分に成立してしまいます。コインを1回投げて表が出ても「このコインは透かし入りだ」とは言えないのと同じです。

しかし200トークン、300トークンにわたって「秘密鍵が示す選択」と一致するパターンが続けば、それが偶然である確率は天文学的に小さくなります。統計的に有意な検出ができるのです。

この「数百トークンが必要」という性質が、後述する「短いテキストには効かない」という限界の直接の原因となっています。

EU AI法がこの技術を求めた理由

Article 50が定めるAI生成コンテンツの開示要件

EU AI法（EU Artificial Intelligence Act）のArticle 50は、AIシステムに対してAI生成・改変コンテンツへの機械可読なマーキングを義務付けています。

具体的には以下の義務が生じます。

• AI生成テキストには、機械が識別可能なマークを付与すること
• ディープフェイク画像・動画については、人間が視認可能な形での開示も必要
• 対象となるコンテンツを処理するシステムは、このマークを検出できること

適用期限は段階的に設けられており、新しいモデルには2026年8月2日から、既存モデルへの対応期限は2026年12月2日となっています。

AnthropicのEU行動規範署名とグローバル展開

Anthropicは2026年7月にEU AI法に関連する行動規範に署名し、同年8月にClaudeへのテキスト透かし導入を発表しました。

技術的に注目すべきは全世界への一律適用という判断です。EUのコンプライアンス要件に対応するために「EU域内のユーザーだけに適用する」という選択肢も技術的には可能でしたが、Anthropicはそれを選びませんでした。

この判断には複数の背景が考えられます。第一に、実装コストの削減です。ユーザーの地理的位置を検出して機能を切り替えるよりも、全ユーザーに一律に適用する方がシステム設計が単純です。第二に、規制の先取りです。EU以外の国でも類似の規制が広がりつつある中、今から全世界に対応しておく方が将来のコストを下げられます。第三に、ブランド戦略です。「透明性と安全性を重視する企業」としての姿勢を示すことができます。

「相互運用性のための手法公開」というジレンマ

EU AI法はAI生成コンテンツの検出可能性を担保するために、業者が採用する透かし手法の相互運用性（interoperability）を求めています。つまり「他のシステムでも検出できるよう、手法をある程度公開せよ」という要件です。

ここに構造的な矛盾があります。手法を公開することは、同時に「どうすれば透かしを消せるか」の情報も公開することを意味するからです。透かしが機能する仕組みを知れば、それを回避する方法も原理的には導き出せます。

この矛盾は技術的な問題ではなく、規制設計に内在する問題です。後半で改めて取り上げます。

品質への影響はあるのか

Anthropicの公式見解

Anthropicは公式発表の中で、テキスト透かしが「コンテンツの品質・創造性・可読性に影響を与えない」と述べています。これは技術的には納得できる主張です。

先に述べたように、統計的ウォーターマークは確率分布を変えず、サンプリングの乱数ソースのみを変更します。高確率で選ばれるべきトークンが低確率で選ばれる確率は変わりません。つまり文章の自然さを支える確率構造は維持されています。

Google DeepMindの検証結果

ClaudeのウォーターマークはSynthID-Textと同系統の手法を採用しているとみられますが、Google DeepMindはSynthID-Textの大規模評価において、ウォーターマークの有無によるユーザー評価の統計的有意差がなかったことを報告しています。

評価では、透かし付きテキストと透かしなしテキストをランダムに提示し、人間の評価者にどちらが良い文章かを判断させました。評価者は透かしの有無を知らされておらず、二つの出力に対する好みに有意な差は生じませんでした。

実務者としてどう受け止めるべきか

「知覚不能」と「影響ゼロ」は厳密には別物です。個々の文章において影響を感じることがなくても、特定のタスクや特定のプロンプト条件下でわずかなパターンの変化が生じる可能性を完全には排除できません。

実際の開発現場では、以下の点に留意するとよいでしょう。

気にしなくてよいケース：一般的な文章生成、説明文、要約、翻訳、マーケティングコピーなど。これらはトークン選択の自由度が高く、透かしによる影響が品質に現れることはほぼありません。

注意が必要なケース：厳密に再現性が求められるタスク（同じシードで同じ出力を期待する場合）や、特定の温度パラメータ・サンプリング設定と組み合わせたときの挙動には、事前の検証をお勧めします。

決定的な限界：コードと事実記述には効かない

ここが技術的に最も重要であり、かつ最も見落とされやすいポイントです。

「出力が一意に決まる場面では透かしは適用されない」

統計的ウォーターマークが機能するのは、「複数の自然なトークン選択が存在する」場面に限られます。選択の余地がなければ、埋め込む余白もないのです。

効かない3つの領域

コード生成

プログラムコードでは、構文・変数名・APIの使い方が多くの場面で一意に決まります。

たとえばPythonでリストを逆順に並べる場合、list.reverse()またはlist[::-1]という選択肢はありますが、それは二択程度であり、数百トークンにわたって意味ある統計的パターンを蓄積するほどの自由度はありません。関数名、クラス名、メソッド名、演算子、インデントなど、コードの大部分は文脈から強く制約されます。

実践的には、AIが書いたコードを人間が書いたものとして盗用していても、テキスト透かしでは検出できないということを意味します。

固有名詞・数値・事実記述

「フランスの首都はパリです」という文章には選択の揺らぎがありません。首都の名前は一つしかなく、それを変えれば誤情報になります。同様に、特定の事実を述べる文章、数値を含む記述、固有名詞を中心とした説明文では、トークン選択の自由度が著しく低下します。

逆説的に言えば、断定的で事実を主張するような文体——フェイクニュースや誤情報拡散に使われやすいタイプの文章——ほど、透かしが乗りにくい傾向があります。

短いテキスト

SNS投稿、メールの件名、見出し文、短い返答など、数十トークン程度のテキストでは統計的パターンが蓄積されません。

検出には数百トークンにわたるパターンの積み上げが必要であるため、短いテキストでは偽陰性（透かしが入っているのに検出されない）のリスクが高まります。

皮肉な結論：最も悪用される領域で最も効かない

整理すると、透かしが最も有効に機能するのは「長い創作文・説明文・論説文など、語彙の選択に自由度が高いテキスト」です。一方、透かしが機能しないのは「コード・事実記述・短文」です。

有害利用のリスクが高い場面を考えると、コード盗用・フェイクニュース的な事実の歪曲・スパムメール（短文大量送信）のまさにその領域で、透かしは最も機能しません。

それでもなお透かし導入に意義があるとすれば、「大量に生成された長文コンテンツの出所を事後的に確認できる」という用途です。たとえばコンテンツファームが大量のAI生成記事を人間が書いたものとして流通させている場合、テキストが長ければ長いほど検出可能性が上がります。

検出はどう行われるのか

検出APIでできること

Anthropicは透かし検出のためのAPIを提供する予定です（執筆時点では一般公開の詳細は未確定）。検出APIに対象テキストを送信すると、「このテキストにClaudeのウォーターマークが含まれているか否か」の判定結果が返ります。

テキストが長いほど検出精度は向上します。先述の統計的原理から当然の帰結で、より多くのトークン選択の記録が積み上がるほど、秘密鍵との一致を確率的に証明しやすくなります。

検出APIでできないこと

技術的な限界として明確に理解しておく必要があるのは、検出APIが**「Claudeが書いた可能性がある」ことを示すに過ぎない**という点です。

• 「人間が書いた」ことの証明はできない：透かしが検出されなくても、人間が書いた証明にはなりません
• 「他社AIが書いた」かどうかも判定不可：GPT-4o、Gemini、Llama等の出力かどうかは判定できません
• 偽陰性は起こりうる：透かしが入っていても、短文や事実記述では検出されないことがあります

この「偽陰性が起こりうる」という前提を抜きに検出結果を解釈すると、深刻な誤用につながります。教育機関での不正使用の検出、採用選考での候補者の文章チェックなどで「検出されなかった＝AIを使っていない」と解釈することは、現状の技術では正当化できません。

透かしは簡単に消せるのか

透かしの除去可能性は、技術コミュニティにおける核心的な批判点の一つです。

最も単純な除去手段はパラフレーズ攻撃です。別のLLMに「この文章を同じ意味で書き直して」と依頼するだけで、トークン選択のパターンが完全にリセットされ、透かしが消えてしまいます。これは秘密鍵を知らなくても実行可能です。

技術ブログ等では「テキストAIウォーターマークは常に自明に除去可能だ」という批判的論考も発表されており、特定の除去手段に対する技術的な詳細が示されています。

しかし除去コストと抑止効果のバランスで評価すれば、話は単純ではありません。透かしを除去するために追加のLLM処理が必要になれば、その分のコスト・時間・手間が除去者に課されます。すべての悪意ある利用者がその除去手順を実施するわけではなく、特に大量生成を目的とした利用（コンテンツスパム等）に対しては一定の抑止効果が期待できます。

類似手法との比較：LLMウォーターマークの進化系譜

KGW法：最初の実用的手法

テキストウォーターマークの学術的な先駆けとして、2023年にKirchenbauer et al.が提唱した**KGW法（Kirchenbauer-Geiping-Wen法）**があります。

この手法では、トークンの語彙をランダムに「グリーンリスト」と「レッドリスト」に二分し、生成時にグリーンリストのトークンが選ばれやすくなるようにロジット（出力スコア）を補正します。検出時には、テキスト中のグリーンリストトークンの割合が期待値より有意に高いかを検定します。

この手法のシンプルさは魅力的ですが、確率分布を意図的に歪めるという根本的な問題があります。本来低確率だったトークンが選ばれやすくなることで、わずかながら品質に影響が出る可能性があります。また、パラフレーズ攻撃に比較的弱いとされています。

SynthID-Text：分布保存型の進化

2024年にGoogle DeepMindが発表したSynthID-Textは、KGW法の問題点を克服するためにトーナメントサンプリングという独自の手法を採用しています。

具体的には、秘密鍵と直前のコンテキストから生成した疑似乱数を使い、複数のサンプリング候補の中から「透かしのパターンを埋め込む」選択を行います。この過程で確率分布そのものは変化しません——distribution-preservingという性質を保ちつつ、統計的な検出力を確保しています。

大規模なユーザー評価でも品質への影響がなかったことが報告されており、技術的完成度の高さが評価されています。Claudeが採用したとみられる手法はこのSynthID-Textと同系統のアプローチです。

手法比較表

ClaudeがSynthID-Text系を採用した意義

GoogleとAnthropicという業界の主要プレーヤーが同系統の手法を採用することは、業界標準化への動きと見ることができます。相互運用可能な検出エコシステムが形成されれば、「A社が生成したコンテンツをB社の検出APIで確認できる」ような未来も視野に入ってきます。EU AI法が相互運用性を求める趣旨とも合致します。

次のフロンティア：意味に透かしを打つ

現在の研究が目指している方向性は「単語選択レベル」から「意味空間レベル」への移行です。

SemStampや**PASA（Paragraph-level Semantic Watermark）**などの手法では、個々のトークン選択ではなく、文・段落全体の意味ベクトル（embedding）に対して透かし情報を埋め込みます。この方式では、「どの単語を使うか」ではなく「どういう意味のことを言うか」の選択に透かしが乗るため、パラフレーズによる除去に対して原理的に強くなります。

ただし計算コストが大幅に増加する課題があり、実用化への道のりはまだ長い段階です。

私たちはこの技術とどう付き合うべきか

コンテンツ制作者が知っておくべきこと

ClaudeのAPIやWebインターフェースを使って生成したテキストには、今後透かしが入っています。そのテキストをそのまま公開する場合、検出APIによって「Claudeが生成した可能性が高い」と判定される可能性があることを念頭に置いてください。

一方、人間が大幅に編集・加筆した文章では、透かしのパターンが薄れる可能性があります。ただしこの「薄れ具合」は編集の程度によって異なり、保証はされません。AI支援で執筆した文章として透明性を持って公開するか、実質的にゼロから書き直すかのどちらかが、リスク管理の観点からは明確です。

企業のコンプライアンス担当が確認すべきこと

EU域内でサービスを提供する企業、あるいはEUの顧客に対してAI生成コンテンツを含む製品・サービスを提供する企業には、以下の確認が必要です。

新モデル適用期限（2026年8月2日）：すでに経過しているため、現時点でのコンプライアンス状況を確認してください。

既存モデル対応期限（2026年12月2日）：レガシーシステムで旧版のClaudeを利用している場合、年内に移行計画を立てる必要があります。

透かし検出APIの活用：自社システム内でAI生成コンテンツを管理・追跡する仕組みを整備する際に、検出APIを組み込むことを検討してください。

AIコンテンツの表示義務：EU域内のエンドユーザーに対しては、AI生成コンテンツであることを人間が視認できる形で開示することがEU AI法の別条項で求められています。透かしはあくまで機械可読な識別子であり、エンドユーザーへの開示とは別のレイヤーです。

ベンダー依存リスクの把握：使用するAIサービスプロバイダーが義務に準拠しているかどうかを契約・利用規約で確認することも重要です。

検出結果を「証拠」にしてはいけない理由

技術的に最も危険な誤用は、透かし検出結果を確定的な証拠として扱うことです。

教育機関が学生のレポートをClaudeの検出APIにかけて「透かしなし→人間が書いた」と判断することは、現状では正当化できません。透かしが検出されない理由は複数あります。短いテキストだったかもしれない、事実記述中心だったかもしれない、別のAIを使ったかもしれない、透かしを意図的に除去したかもしれない、純粋に人間が書いたかもしれない。これらを検出結果だけで区別することは不可能です。

採用選考での文章審査においても同様です。「Claudeの透かしが検出されなかった」は「AIを使っていない」の証明ではなく、「Claudeが書いたという直接の証拠がなかった」に過ぎません。

この誤解が社会的に広まることが、現状における最大のリスクの一つと言えます。

まとめ：透かしは万能薬ではなく、最初の一歩

Claudeのテキスト透かしを一言で表すなら、「乱数のソースを秘密鍵に差し替えることで、確率分布を歪めずにトークン選択のパターンを統計的に識別可能にする技術」です。

技術的な誠実さという点では、Anthropic自身が限界を認めています。コードには効かない、事実記述には効かない、短文には効かない。これらは隠された欠点ではなく、技術原理から必然的に導かれる制約です。

EU AI法という規制が生んだ実装ではあるものの、規制自体にも矛盾が残っています。手法を公開して相互運用性を確保すれば、同時に回避手順も公開されます。パラフレーズ攻撃という誰でも使える方法で透かしは消えます。「完璧なウォーターマーク」は現状では存在しません。

それでも、なぜ意義があるのか。それは「完璧な解決策ではなくとも、コストをかけなければ除去できない仕組みを作ることで、悪意のない流用や大量のスパム生成に対する一定の抑止効果が生まれる」からです。AI生成コンテンツが溢れる時代において、透かしは「AIが書いた」という事実の確認を少し簡単にしてくれる道具に過ぎません。その限界を正確に理解した上で使うことが、実務者として重要なベストプラクティスです。

今後の注目点は3つです。第一に、検出APIの一般公開とその利用規約。第二に、意味空間型ウォーターマークの実用化動向。第三に、Google・Anthropicが牽引する業界標準化の進展です。この分野は今、急速に動いています。

よくある質問（FAQ）

Claudeの透かしは自分で無効化できますか？

Claudeのユーザー設定や一般的なAPIパラメータから透かしを無効化する方法は公開されていません。ただし、出力されたテキストをパラフレーズ（別のAIに書き直させるなど）することで、透かしパターンが失われる可能性があります。これは技術的な事実であり、意図的な悪用を推奨するものではありません。

透かし入りテキストを編集したら消えますか？

一部の編集では透かしが弱まることがありますが、どの程度の編集で消えるかは透かしの実装詳細と編集量・質に依存します。単純な語句の置き換えや誤字修正程度では消えないと考えられます。大幅な書き直しは透かしを弱める可能性がありますが、完全に消えることを保証する「安全な編集量」は現状では定義されていません。

API経由の出力にも透かしは入りますか？

Anthropicの公式発表では、透かしはClaudeの出力全般に適用されることが示されています。WebインターフェースだけでなくAPIを通じた出力にも透かしが付与される可能性が高いですが、APIの利用規約や実装の詳細については最新の公式ドキュメントを確認することをお勧めします。

過去にClaudeで生成した文章は検出対象になりますか？

テキスト透かしの導入タイミングより前に生成された文章には、透かしが含まれていません。検出APIは「このテキストにClaudeのウォーターマークが含まれているか」を確認するものであり、透かし導入以前のテキストは検出されない（偽陰性になる）可能性が高いです。

他社のAI（GPT・Gemini）も透かしを入れていますか？

OpenAIのGPTシリーズについては、同様のテキスト透かし技術の一般提供は執筆時点では公式発表されていません。GoogleのGeminiについては、同社がSynthID-Textを開発・研究していることから、Geminiへの同様の機能導入が技術的には可能な状態にあります。ただし各社の実装状況は変化する可能性があるため、各社の公式発表を随時確認することをお勧めします。

参考文献

• Anthropic公式：Claude Text Watermark
• Google DeepMind：SynthID
• Kirchenbauer, J. et al. (2023). "A Watermark for Large Language Models." ICML 2023.
• TechCrunch：Anthropic says it will watermark text generated by its AI models
• seangoedecke.com "Text AI watermarks will always be trivial to remove"
• EU Artificial Intelligence Act, Article 50 (Transparency obligations for providers and deployers of certain AI systems)