「Claudeの新しいモデルが生成する文章には、目に見えない透かしが入ります」――2026年8月、Anthropicからそんな発表がありました。EUのAI法への対応として、8月2日以降に登場する新モデルから、生成されるテキストそのものに、機械だけが読み取れる印——いわゆる電子透かし——を埋め込んでいくとのことです。
私は日々、AIを利用してコードを生成し、文章を書いています。これは他人事ではありません。それに技術者としては、まず素朴な疑問が浮かびます。文章の見た目を変えずに透かしを入れるなんて、そんなことができるのか？
調べてみると、背景には数年前から積み上げられてきた研究がありました。しかも代表的な方式は論文もコードも公開されていて、自分の手元で動かして確かめられます。今回はその仕組みと実験の話です。
何が発表されたのか
Anthropicの公式ヘルプ「How Claude marks AI-generated content」の要点を整理します。
- 2026年8月2日以降にリリースされる新しいClaudeモデルは、生成するテキストに「知覚できない透かし」を埋め込む
- 画像などの生成ファイルには、C2PAという業界標準規格の署名付きメタデータを付与する
- EU向けの限定機能ではなく、APIやクラウド経由も含む世界共通の仕様
- 透かしの検出手段は後日提供予定
印象的なのは、公式自身が限界を率直に列挙していることです。透かしが検出されてもClaudeが著者とは限らない（校正や翻訳を通しただけでも付く）。大幅な編集や言い換えでは消える。短い文章からは検出できない。――この「できないことリスト」の意味は、仕組みを知ると腑に落ちます。
この発表はHacker Newsでも話題になりました（250ポイント超・200件超のコメント）。議論の中心は3つです。
- 仕組みの推定 ― 「知覚できない透かし」は、どうやって実現しているのか
- コードへの疑問 ― 一字違えば動かなくなるコードには、埋め込めないのではないか
- 誤判定の心配 ― 人間の文章を、誤って「AI製」と判定してしまわないか
発表から数時間で「透かし除去」を名乗るサイトが現れる一幕もありました。この記事の後半で、この3つの論点にはそれぞれ答えが出ます。
論文の話 ― 透かしは「単語」ではなく「統計」に宿る
Anthropicが具体的にどの方式を使うかは公開されていません。先ほどのHacker Newsの議論でも、そこは全員が非公開を前提に「おそらくこの系譜だろう」と推定を交わしていました。その推定でほぼ一致して挙がっていたのが、この分野の代表的な研究、Kirchenbauerらの「A Watermark for Large Language Models」（ICML 2023）です。GoogleがGeminiで実用化した「SynthID Text」（2024年にNature掲載）も同じ系譜にあります。
LLMは文章を書くとき、次の一語（正確にはトークン）を確率で選んでいます。「今日はいい天気」の続きなら「です」80%、「だ」15%、「かも」5%――こんな候補リストから一つを引く抽選を、延々と繰り返しています。
論文が提案する透かしは、この抽選にこっそり癖をつけます。手順は3つです。
- 直前のトークンと秘密鍵をハッシュ関数にかけ、数万語の語彙をその場で「緑リスト」と「赤リスト」に二分する（分け方は位置ごとに毎回変わる）
- 次のトークンを選ぶとき、緑リスト側の候補の確率をほんの少しだけ引き上げる
- 検出するときは、同じ鍵で各位置の緑リストを再計算し、文章中のトークンが「緑側」だった割合を数える
手順1に出てきた「緑リスト」から、本記事ではこの方式を緑リスト透かしと呼びます。論文での正式な呼び名はソフト透かし（soft watermark）——緑を強制するのではなく、確率をわずかに引き上げる”だけ”だからです。後続の研究では、著者3人の頭文字からKGW法とも呼ばれています。人間は緑リストの存在を知らずに書くので、緑率は理論値どおりになります（緑リストが語彙の25%なら約25%。コイン投げと同じです）。一方、透かし付きの文章は緑に偏る。この偏りは1語だけ見ても絶対に分かりません。特定の単語や記号が埋め込まれるわけではなく、文章全体の統計の中にだけ透かしが存在するからです。
例えるなら、押した本人にしか照合できないハンコです。鍵を知らなければ、どこに印があるのかすら分からない。そして鍵を知っていれば、モデル本体がなくても照合できる――検出に必要なのは、トークンの分割ルールと鍵だけです。
「z値」って何？ ― 偶然かどうかを数字にする
検出結果は「z値」という一つの数字で出てきます。聞き慣れない言葉ですが、中身は素朴です。
コインを100回投げて、表が80回出たとします。偶然にしては出来すぎです。この「出来すぎの度合い」を、期待値からのズレがばらつきの単位（標準偏差）いくつ分にあたるか、で表した数字がz値です。式は一本だけ書いておきます。
z = (緑トークンの数 − γT) ÷ √(Tγ(1−γ)) （γ=緑リストの比率、T=トークン数）
目安として、z=2は偶然でも2%ほど起こります。z=4なら偶然の確率は0.003%。z=10は、宇宙的な偶然を疑うレベルです。だから「z>4なら透かしあり」のようにしきい値を決めておけば、人間の文章を誤ってAI判定してしまう確率を、計算で管理できます。
ここが、文体の雰囲気を機械学習で当てる世間の「AI判定ツール」との根本的な違いです。あちらは原理的に誤判定率を保証できませんが、透かしの検定は確率を数式で制御できる。もう一つ、式のTに注目すると「短い文章では検出できない」理由も読み取れます。トークン数が少ないと、偏りがあってもzが伸びないのです。
実験 ― 自分のLLMに透かしを入れて、自分で検出する
Claudeの透かしは、外部からは確かめようがありません。これはClaudeに限った話ではありません。どのモデルでも透かしの鍵は非公開で、モデルと鍵（＝緑リストの作り方）は、非公開の1対1の関係になっています。緑リストを再現できるのは、そのモデルの鍵を持つ者だけ。つまり各モデルの透かしは、それぞれの提供者にしか見えない構図です。ただ、仕組みの実験なら、オープンなモデルを使って自分の手でできます。ここからの実験は、Claudeの透かしの実物ではなく、公開されている論文の方式で「この技術に何ができて何ができないか」を確かめるものです。Kirchenbauer方式はHugging Faceのtransformersライブラリに標準搭載されていて、オープンウェイトのモデルなら埋め込みから検出まで全部自分でできます。鍵を持っているのが自分自身だからです。
実験はGoogle Colabの無料枠（T4 GPU）で、オープンウェイトのQwen2.5-3B-Instructを使って行いました。手元のMacでも同じ手順で再現できます。やったのは4つの実験です。
実験に使ったノートブックは、こちらで公開しています。Google Colabでそのまま開いて、同じ実験を再現できます。
toztavi / Watermark_4_LLMLLMの文章に透かしを埋め込み・検出する実験ノートブック（Colab対応）
実験1は基本の確認です。同じお題（秋の京都のエッセイ）を、透かしなしと透かしありで1本ずつ生成します。まず2つを読み比べて、違いが分からないことを確かめる。それから検出器にかけて、数字でははっきり白黒が付くことを確かめます。
生成された2つの文章がこちらです。
文章A
秋の京都をひとり旅する魅力は、その特別な雰囲気と静寂に溢れています。秋の京都は、紅葉が美しい季節であり、街のあちこちで紅葉が舞い落ちる様子を眺めることは、至福の経験となります。散策路にはたくさんの人々が訪れ、人々の姿と自然との対話が織りなす風景は、心に響きます。独自性の高い観光地である京都を、一人で歩き回ることで、より深くその魅力を体感することができます。街の細道をひとりで歩くことで、誰もいない静けさの中での自分の時間が増えます。これにより、それぞれの場所や建物に寄り添うような視線で見つめることが可能になり、その土地の美しさをより深く感じることができます。
また、京都は歴史と文化に満ちており、一人旅では、それぞれの神社や仏閣、古都の魅力をゆっくりと楽しむことが可能です。個人的な時間を持てば、自分のペースで訪れたいスポットを探し、その場所に深く没頭できるでしょう。
秋の京都をひとりで旅することの最大の魅力は、その静けさと深み、そして自身との対話です。一人旅という形態が、京都の美しさをより深く引き出し、個々の価値観と出会う機会を提供してくれること无疑。
文章B
秋の京都、それは四季の中で最も落ち着きと豊かさを感じさせる季節です。その魅力は、四季折々の景観とともに深淵に沈む空の彩りと共に訪れる人々を強く魅了します。まず、京都は「四季折々見ごろ美」が有名な街です。春には華やかな花見の季節が始まります。夏には涼しい蝉の声が響きます。しかし、秋は最も深みのある色と風情を感じさせる季節です。紅葉の美しい景色は、一目見たら忘れがたき魅力を持っています。
京都が持つ文化的魅力も、秋の一人旅で深く引き立つでしょう。観光地の名所、祇園の祭りや皇居の特別区域は、四季折々の人々の行動や気候の変化を捉えるのに最適です。散策中に出会う地元の人々との繋がりや、古い建物や庭園の深淵な調和は、一旅行の経験として一生に残るものになるはずです。
また、独自の食文化や特有な生活習慣は、旅を通じて世界中の旅行者がその魅力を発見することができます。京料理の伝統美、本格的な茶道体験など、京都ならではの体験は、旅先での一人旅に特別な味わいを添えます。
秋の京都に一人で旅する醍醐味は、独自のペースでその美しい景色を楽しみ、京都の人々との繋がりを探求するこの一瞬一瞬にあります。さまざまな季節の色彩が織り成す美しい景色を眺めながら、少しずつ深淵な心を磨き、成長していけばよいでしょう。
どちらに透かしが入っているか、読んで分かるでしょうか。私には分かりませんでした。細かく見ると、Aの末尾には中国語の単語（无疑）が紛れ込み、Bには「皇居」（京都にあるのは京都御所です）という粗があります。つまりどちらも小型モデルらしい粗を含んでいて、品質の差は読み取れません。しかし検出器にかけると、はっきり白黒が付きます。
| 緑率 | z値 | 判定 | |
|---|---|---|---|
| 文章A | 23.3% | -0.70 | 検出せず |
| 文章B | 61.3% | 16.65 | 透かし検出 |
透かし入りは文章Bでした。緑リストの比率は25%に設定してあるので、透かしのないAは理論値どおりの23.3%。Bの61.3%が偶然出る確率は、z=16.65——事実上ゼロです。
実験2は「編集でどこまで消えるか」です。透かし付きの文章を手で直していきます。語尾を変え、文を入れ替え、書き足して――そのたびに検出器にかけ、z値がどう下がっていくかを観測します。
結果の推移がこちらです。
| 編集の段階 | 緑率 | z値 | 判定 |
|---|---|---|---|
| そのまま | 61.3% | 16.65 | 透かし検出 |
| 冒頭の語尾だけ常体に | 60.2% | 16.10 | 透かし検出 |
| 全文の語尾を常体に | 58.7% | 15.40 | 透かし検出 |
| 半分の文を書き直し | 37.3% | 4.87 | 透かし検出（ぎりぎり） |
| 全文を言い換え | 25.3% | 0.10 | 検出せず |
語尾を全部変えた程度ではz=15超——校正レベルの編集では、透かしはほぼ無傷で残ります。半分の文を書き直したところでz=4.87と、しきい値ぎりぎりまで低下。そして内容だけ保って全文を言い換えると、緑率25.3%——透かしを知らずに書かれた文章と統計的に見分けがつかない状態まで落ちました。緑リスト比率25%という理論値への着地が見事です。
正直に書いておくと、後半2段階の書き直しはAI（Claude）に手伝わせたものです。つまり最終段は、透かし研究で「言い換え攻撃」と呼ばれるものの実測に相当します。人間の丁寧な校正では消えず、AIの言い換えでは一撃で消える——この非対称も、この技術の現在地です。
実験3は「コードには埋め込めるのか」。FizzBuzzをあえて透かしオンで書かせてみます。コードは、続きがほぼ一意に決まる文章です。答えの書き方が一つしかない場面では、抽選に癖をつける余地がそもそもありません。
生成された出力がこちらです（透かしはオンにしてあります）。
def fizzbuzz():
for i in range(1, 101):
if i % 3 == 0 and i % 5 == 0:
print("FizzBuzz")
elif i % 3 == 0:
print("Fizz")
elif i % 5 == 0:
print("Buzz")
else:
print(i)コードに続けて、モデルは「この関数は、1から100までの各数字に対して、FizzBuzzルールに従って処理を行います」という短い説明文も付けていました（「コードのみ」の指示だったのですが）。
検出結果は、緑率28.6%・z=1.02で検出できず。透かしをオンにして生成したのに、です。
面白いのは28.6%という数字が、理論値25%よりわずかに高いことです。続きが一意に決まるコード部分では加点が空振りし、自由度のあるおまけの説明文の部分でだけ、少し緑に寄れた——1つの出力の中で「透かしが入る場所と入らない場所」が混在していたわけです。
実験4は「鍵が違えば見えない」。検出器側の鍵の数字を一つ変えて、さっきの透かし付き文章をもう一度判定してみます。
| 判定に使った鍵 | 緑率 | z値 | 判定 |
|---|---|---|---|
| 正しい鍵 | 61.3% | 16.65 | 透かし検出 |
| 別の鍵 | 28.6% | 1.66 | 検出せず |
同じ文章なのに、鍵の数字を1つ変えただけで検出器は何も見つけられなくなりました。緑リストは鍵から作られるので、鍵が違えば「別の分け方」で数えることになり、結果は当てずっぽうと同じになる。透かしの照合は、鍵を持つ本人にしかできない——本文で述べた「モデルと鍵は1対1」の実証です。
できることと、できないこと
実験の結果と公式の「限界リスト」を突き合わせると、この技術の輪郭が見えてきます。冒頭に挙げたHacker Newsの3つの論点に、実験を踏まえた私の見解を述べます。
仕組みの推定について。本命とされていたKirchenbauer方式を実際に動かした限り、「確率のわずかな偏り」だけで透かしは十分に機能しました。読んで区別できない2つの文章に、z=16という圧倒的な統計の差が付く（実験1）。Anthropicの実装が同じ方式である保証はありませんが、「知覚できない透かし」は絵空事ではなく、公開されている技術で現実に作れるものでした。
コードへの疑問について。これは疑問のとおりでした。続きが一意に決まるコードには、透かしをオンにしても入りません（実験3）。ただしこれは欠陥というより、確率が拮抗した場面にしか介入しない「ソフト」な設計——つまり品質を壊さないための遠慮——と引き換えの、原理的な限界です。
誤判定の心配について。ここは仕組みの側に答えがあります。判定はz値のしきい値で決まるので、人間の文章を誤ってAI製と判定する確率は、計算で好きなだけ小さく設定できます。実験でも、透かしのない文章の緑率は常に理論値の25%前後に収まり、誤判定は起きませんでした。文体の雰囲気を機械学習で当てる「AI判定ツール」と根本的に違うのはこの点です。ただしこれは透かしの検定に限った話で、世の中の検出サービス一般がそうだという意味ではありません。
そのうえで、実験2が示したできないことも押さえておきます。大幅なリライトや言い換えには耐えられません。そして鍵はベンダーごとに別物なので、Anthropicの透かしはAnthropicにしか見えず、他社のものは他社にしか見えない（実験4）。この方式の延長線上に「あらゆるAI文章を見抜く万能検出器」は生まれない、ということです。
最後に、一番大事な点です。公式ヘルプが明記しているとおり、透かしは「Claudeが処理した」ことの印であって、「AIが書いた」ことの証明ではありません。人間が書いた文章をAIで校正しても印は付くし、AIの文章を人間が大きく書き直せば印は消える。透かしから分かるのは著者ではなく、道具の通り道なのです。
精度（品質）や多様性は落ちないのか？
抽選に癖をつけると聞いて、私がまず気になったのはここです。生成される文章の精度（品質）や多様性は落ちないのか。理屈のうえでは、確かにトレードオフがあります。
まず精度。加点は「ソフト」な介入で、候補が拮抗している場面でだけ実質的に効きます。モデルが強い確信を持っている場面では、少々加点しても順位はひっくり返りません。つまり品質への影響は「どちらでも自然だった選択が、片側に寄る」ことに限られ、論文でも文章の自然さの悪化はごくわずかと報告されています。加点の強さは、検出のしやすさと品質への影響を天秤にかけるツマミです。強くすれば短い文章でも検出できるようになる代わりに不自然さが出て、弱くすれば品質はほぼ無傷の代わりに、検出に長い文章が必要になります。
実運用での検証もあります。GoogleはSynthIDをGeminiに実装したうえで、約2,000万件の応答を透かしあり/なしで比較し、利用者の評価（グッド/バッド）に目立った差が出なかったと報告しています（前掲のNature論文）。品質影響の実証としては、現時点で最大規模のものです。
多様性は、厳密に言えばわずかに削られる方向です。同じ鍵を使う限り、同じ文脈では毎回同じ側（緑）に寄り続けるからです。ただし緑リストの中身は位置ごとに毎回変わるため、「特定の言い回しばかり増える」ような目に見える癖にはなりません。読み比べて分かるレベルの差が出たという報告は見当たりませんでした。
そして、この「品質を守る設計」は、コードに透かしが入らないこととちょうど表裏一体です。正解が一つしかない場面では介入が空振りする——品質を落とさないための遠慮が、そのまま埋め込み不能につながっています。
まとめ
「AIの文章に見えない透かし」と最初に聞いたときは半信半疑でしたが、正体は暗号と統計の組み合わせでした。特定の語を埋め込むのではなく、次の一語を選ぶ確率にわずかな癖をつけ、文章全体から統計的に読み出す。だから人間には知覚できず、機械には検出できる。よくできた仕組みだと思います。ただし、癖をつけられるのは「どちらを選んでも自然な場面」だけ。コードのように続きのブレが少ない文章には、そもそも埋め込む余地がなく効きません——ここは覚えておきたい限界です。
同時に、この透かしが示せるのは「どの道具を通ったか」まで、ということもはっきりしました。文章の中身を確かめ、直し、最後に引き受けるのは、これまでどおり書き手の仕事です。
おまけ: 実験でつまずいたこと
この実験、実は2回つまずいています。どちらも透かしという技術の性質がよく出ているので、記録しておきます。
1つ目は「透かしが入らない」。生成時に透かしの設定を渡したつもりが、ライブラリのバージョン差でエラーも警告も出ないまま設定が捨てられていました。透かしは目に見えないので、入っていなくても出力からは分かりません。検出器にかけて初めて「緑率25%＝入っていない」と判明しました。入れたつもりの透かしの有無すら、検出器なしには確認できない——考えてみれば当たり前ですが、実際に体験すると不思議な感覚です。
2つ目は「入っているのに検出できない」。生成をGPU、検出をCPUで行っていたのが原因でした。緑リストは鍵から乱数でシャッフルして作りますが、PyTorchの乱数はCPUとGPUで生成アルゴリズムが違うため、同じ鍵から別の緑リストが再現されていたのです。検出器を生成と同じGPUに載せたら、z=16.65が出ました。
どちらのつまずきも、教訓は同じところに行き着きます。透かしの照合とは、生成時の条件を——鍵だけでなく実装の細部まで——完全に再現すること。だから鍵を持つ本人にしか検出できないし、条件が一つズレただけで何も見えなくなる。失敗が一番の教材でした。
出典: Anthropic「How Claude marks AI-generated content」 ／ J. Kirchenbauer et al., “A Watermark for Large Language Models”（ICML 2023） ／ S. Dathathri et al., “Scalable watermarking for identifying large language model outputs,” Nature（2024） ／ Hacker Newsの議論スレッド ／ 国内報道: CNET Japan「Claudeが生成した文章に「電子透かし」、全世界で導入へ」（2026-08-12）
