見出し画像

生成AIの文章に「透かし」が入るらしいが、よく分からなかったので料理で例えてみた。

ソフエ

はじめに

生成AIが書いた文章に、目に見えない「透かし」を入れる。そんな技術がある。

きっかけは、Anthropicが「Claudeの生成テキストに透かしを埋め込む」と発表したことだった。

それを受けたNIK氏のポストがあり、さらにそれに答える形で、GPTZeroのCTOであるAlex Cui氏が透かしの仕組みを解説していた。読んでみたのだが、正直、最初はピンとこなかった。文章の内容を変えずに、要素を変えることで、透かしとして機能させるらしいのだが、専門用語が多いこともあり、スッと頭に入ってこなかった。

そこで、何かに例えてみることにした。選んだのは料理だ。理由ははっきりしていて、レシピが同じでも、使う食材は変えられるからだった。「決まっている部分」と「差し替えられる部分」がきれいに分かれている。この構造なら、いい感じの例えが作れそうな気がした。この記事は、その記録だ。そして、読み終えれば、

生成AIによる文書への「透かし」の入れ方について、
なんとなく理解できた気がする

くらいにはなると思う。

なお、先に白状しておくと、この料理の見立ては、途中で一度きれいに壊れる。

「出来上がった料理を調べれば、どのシェフが作ったか判別できそう」。最初はそう考えていたのだが、カレーみたいな一般的な料理でも、成立しないことが分かった。ただ、その壊れ方こそが、この技術のいちばん大事なところだった。

しかも、皮肉なことに、答えは自分が最初に手をつけなかったほうにあった。差し替えられる食材のほうばかり見ていたのだが、肝心なのはもう片方のレシピだったのだ。

だから先に、この記事の着地点を書いておく。

透かしは、料理には宿っていない。
レシピのほうに宿っている。

そして、文章という不思議な媒体は、今回の比喩の目線では、料理でありながら、同時にレシピでもあった。ここが分かると、何ができて何ができないのかが、驚くほどすっきり見えてくる。

なお、技術の仕組みや制度の部分は出典をつけて書く。「ここから先は自分の見立てだ」という部分は、はっきりそう断る。そのつもりで読んでほしい。

1. まず、レストランに置き換えてみた

生成AIによる文書作成を、レストランでの料理作成として置き換えてみた。

登場人物はこうだ。

流れはこうだ。

① 注文が入る
シェフは献立を組み立てる。カレーを作ると決めた以上、にんじんは入る。ここは「何を作るか」という意味の話なので、透かしは手を出さない。

② 秘密鍵を使って、品種を選ぶ
手を出すのは、その次だ。どのにんじんを使うか。 金時か、五寸か、島にんじんか。どれを選んでも、出てくるのはカレーである。ここで裏のルールが働く。「直前に使った食材」と「秘密鍵」を組み合わせた関数を通すと、「今回は金時を優先しよう」という偏りが、その瞬間ごとに決まる。

この図では、直前の食材が玉ねぎのとき、優先する組は金時に決まる。
にんじんの前がじゃがいもなら、また別の組分けになる。
サイコロは振っていないので、同じ食材と同じ鍵からは必ず同じ結果になる。

③ 味は変わらない
どれを選んでも成立する場面で、片方に寄せる。それだけを、何百回と繰り返す。

結果として、味も見た目も普通のカレーなのに、「なぜか特定のルールに沿った品種が選ばれ続けている」という痕跡が残る。

ここが、この技術のいちばん上手いところだと思う。意味には触れず、意味に影響しない選択の余地だけを使う。 だから品質を落とさずに情報を埋め込める。

補足：方式はひとつではない
透かしの入れ方には複数の方式がある。語彙を「緑」と「赤」に分けて緑側を優遇するもの、GoogleのSynthID-Textのようにトーナメント方式で候補を絞っていくものなど。ただし共通しているのは、「直前の文脈＋秘密鍵」で次の候補に偏りをつけるという骨格だ。この記事ではその共通部分だけを扱う。

逆に言えば、以降の説明はどれか特定のAIの実装をなぞったものではない。

また、厳密には、AIが選んでいるのは「品種」だけではなく、次に来る単語の候補すべてだ。ただし透かしが実際に働けるのは、どれを選んでも文意が変わらない範囲に限られる。だから「品種選び」に例えるのが、実態にいちばん近い。たぶん。

2. あれ？カレーだと、分からなくない？

さて、次は検出だ。ここで最初に描いた図が壊れた。

自分はこう考えていた。検査員は、運ばれてきた完成品の料理を調べて、「この品種の選び方は、うちのシェフのルールに合っている」と判定するのだろう、と。

ところが、料理として最初に浮かべた、カレーですら、成り立たなかった。

腕のいい検査員なら、完成したカレーを分析して「GABANのクミンが使われている」と突き止めることは、できるかもしれない（私は当然できない）。問題はそこではない。

思い出してほしいのは、②のルールだ。どの製品を使うかは、直前に何を使ったかと秘密鍵の組み合わせで決まる。

クミンを、玉ねぎを炒める後に振ったのか、煮込みに入る直後だったのか。
この順番の違いによって、投入されるクミンがS&BなのかGABANなのか、はたまた別の製品なのかが変わってしまうのだ。

そして、完成した一皿から、その順番は分からない（分かる人がいたらごめんなさい）。

具材の大きいところなら、まだ調理の常識から推測できる余地がある。にんじんはじゃがいもより先に鍋に入るだろう、といった具合に。けれどスパイスになると、いつ振られたのかは、カレーの中に溶けて消えてしまう。

だから検査員は、こう言うしかない。

「GABANのクミンが使われたことは、食べれば分かる。でも、それがどの工程で入れられたのかが分からない。だから、その工程でGABANが選ばれるべきだったのかどうかが、計算できない」

ルールに従った結果なのか、ただの偶然なのか。判定できない。

比喩が壊れた、と思った。

3. 文章は、料理でありレシピでもある

ただ、壊れた理由を考えているうちに、逆に本質にぶつかった。

そもそも自分が料理を例えに選んだのは、「レシピが同じでも、食材は変えられる」からだった。差し替えられる食材のほうに、透かしが入ると思っていた。ところが、その食材の話が成り立たなくなった原因は、捨て置いていたレシピのほうにあった。

料理は、完成した時点で工程が失われる。だから料理の世界では、工程を残したければレシピという別の記録を用意するしかない。カレーそのものと、その作り方を書いた紙。この二つは、別々の物体だ。

ところが、文章は違う。

書かれた順番が、そのまま残っている。

一文字目から最後まで、どういう順序で組み立てられたかが、テキストという形でそっくり保存されている。つまり文章は、完成品であると同時に、作業手順つきレシピでもある。料理の世界では別々だった二つが、文章の世界では一つに重なっている。

ここが、透かしが成立している条件そのものだった。

だから、1章の見立てはこう描き直すのが正しい。

シェフは、料理を作りながら、同時にレシピも書いている。
そして検査員が読むのは、レシピのほうだ。

この方式の透かしがテキストにしか入れられない理由も、これで説明がつく。カレーには入れられない。順番が消えてしまうからだ。

（画像や音声にも透かし技術はあるが、あちらは画素や波形を直接いじる、まったく別の仕組みだ。「選ぶ順番に痕跡を残す」というやり方が使えるのは、順番が保存される媒体だけである。）

4. 検査員は、シェフの舌を持っていなくていい

次に引っかかったのが、検査員の仕事の中身だった。

最初は「検査員はシェフの思考を再現するのだろう」と思っていた。同じ献立を頭の中で組み立て直して、「この文脈なら次はにんじんのはずだ」と判断する、と。だとすると、検査員はシェフと同じ舌と腕を持っていないといけない。つまり、検出するにはAIモデル本体が必要になる。

ところが、そうではなかった。

検査員に必要なのは、「直前の食材」と「秘密鍵」だけだ。この二つを関数に入れれば、「この時点で優先されるはずだった品種グループ」が機械的に計算できる。あとは、実際に使われた品種がそのグループに入っている割合を数えるだけでいい。

料理の腕も、味の判断も要らない。鍵と、目の前のレシピだけで採点できる。

想像していたより、ずっと素っ気ない仕事だった。実際、SynthID-Textの検出器は、モデル本体を動かさずに判定できる設計になっている。

なお、Anthropicは自社の透かしの具体的なアルゴリズムを公開していない。ここまで書いてきたのは、公開されている方式から見えてくる共通の骨格を、料理に置き換えたモデルであって、Claudeの実装そのものの説明ではない。以降も同じだと思って読んでほしい。

そして、この「数えるだけ」という性質から、ひとつ重要な限界が自動的に出てくる。

短い文章は、判定できない。

工程が3つしかないレシピで、そのうち2つがルール通りだったとしても、偶然かどうか区別がつかない。十分な数の工程があってはじめて、「偶然こうなる確率は低い」と言える。だから、数行コピペされただけの短い文章では、検出は難しくなる。実際、Nature論文でも、短文では精度が落ちることが示されている。

ついでに言うと、必要なのは長さだけではない。レシピの精度も要る。

世の中に転がっているレシピは、けっこう大雑把だ。「野菜を炒める」「スパイスを加えて煮込む」。人間が作る分にはこれで十分だが、検査には使えない。何をどの順で入れたかが、まとめられて消えてしまっているからだ。

検査員が必要としているのは、一工程も飛ばさず、何を、どの順で、どれだけ使ったかを全部書いた、異常に細かいレシピだ。普通なら誰も書かないような代物である。

そして文章は、それを勝手に満たしている。単語がひとつ選ばれるたびに、その選択がそのまま記録されていく。省略も要約もない。3章で「文章はレシピでもある」と書いたが、正確にはそこらのレシピではなく、極めて精緻なレシピなのだ。透かしが成立しているのは、この細かさのおかげでもある。

同じ理由で、選択肢が少ない文章にも効きにくい。プログラミングのコードや、定型的な事実の記述がそれだ。使える製品が一種類しかない場面ばかりでは、そもそも偏りの入れようがない。事実中心のテキストで効果が薄くなることは、SynthID-Textの実装上の注意点としても挙げられている。

5. じゃあ、消せるのか

ここまで来ると、消し方も自動的に見えてくる。

3章の結論はこうだった。透かしは料理ではなくレシピに宿っている。ということは、味を保ったままレシピを書き換えれば、透かしだけが消えるはずだ。

実際、よく挙げられる対策は、すべてこれで説明がつく。

  • 言い換える（パラフレーズ）：食材を変える。にんじんの品種を別のものに変えたり、クミンをGABANから手元にあるS&Bに変えたりするようなもの。手を入れた工程の判定が壊れるので、全体を通してやれば偏りは消える。

  • 人間が書き直す：一から作り直す。レシピの意図だけを把握したうえで、自分の手順でゼロから組み立てる。元の工程の偏りはほぼ消滅する。いちばん確実に消える方法だ。

  • 別の言語に翻訳する：厨房ごと変える。シェフは同じでも、道具や設備の規格、技法の体系が根本から違う厨房に移ることになる。工程そのものを、その流儀で組み直さざるを得ない。

  • 別のAIに書き直させる：シェフを変える。別の持ち味と裏ルールで作り直される。ただしこれは厳密には「消える」のではなく、元の透かしが、そのシェフの透かしに置き換わるというほうが近い。

どれも「料理は似ているが、レシピは別物」という同じ形をしている。大幅な書き換えや翻訳で検出が難しくなることは、SynthID-Textの側でも制約として認められている。

ただし、逆は言えない。

透かしが検出されなかったからといって、
「人間が書いた」と証明されたわけではない。

そもそも透かしが入っていないAIで書いたのかもしれないし、書き換えたのかもしれない。検出器が言えるのは「うちの鍵の痕跡は見つからなかった」までだ。

【コラム】冒頭だけ直せば、消えるのでは？
②のルールは「直前に何を使ったか」に依存している。なら冒頭を徹底的に書き換えれば、そこから先の計算がドミノ倒しで全部ずれるのでは、と考えた。
残念ながら、そうはならない。4章のとおり、検査員は各工程を採点して○の割合を数えるだけで、500工程目の採点に必要なのは499工程目の情報だけだからだ。冒頭50工程を壊しても、狂うのはその50工程分。51工程目からは何事もなく再開される。 透かしは一本の線ではなく、数百個の独立した印として散らばっている。だから上の対策は、どれも全文に手を入れるものばかりなのだ。

6. その検査員は、誰でもなれるわけではない

ここで、はっきりさせておきたい制約がある。ここまで「検査員」と呼んできた存在は、誰でもなれるわけではない。

秘密鍵がなければ、そもそも計算が始まらないからだ。

4章で見たとおり、判定に必要なのは「直前の食材」と「秘密鍵」の二つだった。片方が欠ければ、何も採点できない。

ただし、ここから「提供者だけが検証できる」と決まるわけではない。鍵や検出用の設定を誰に渡すかは、提供者側の運用設計の問題だからだ。実際、SynthID-Textでは、検出器を完全に非公開にする、APIとして提供する、公開する、といった複数の運用形態が想定されている。

つまり技術が決めているのは「鍵なしでは検証できない」ところまでで、その先は各社の判断に委ねられている。

とはいえ、少なくとも「誰でも自由に検証できる」わけではない。この点は実務でかなり効いてくる。学校の先生が生徒のレポートを自分で確かめたり、編集者が投稿された原稿をその場でチェックしたりできるかどうかは、提供者が窓口を開けているかどうかに丸ごと依存する。

透かしは、それ自体としては世の中に出回っている文章を誰でも検査できるようにする技術ではない。ここは、名前の印象と実態がいちばんズレるところだと思う。

ただ、この構図には制度の側から圧力がかかりつつある。

詳しくは7章で触れるが、EUではこの8月から、AI生成物に印をつけることを提供者に求めるルールが動き出した。そこに付随する行動規範は、印をつけるだけでなく、第三者がその印を検出できる手段を用意することまで求めている。

Anthropicもこの規範に署名していて、公式ドキュメントでは、利用者や第三者がClaudeの透かしを検出できるよう対応を進めており、詳細は今後のドキュメントで公開するとしている。

運用に委ねられていた部分に、制度が「窓口を開けろ」と乗ってきた、というのが現在の状況だ。どこまで実用的な形で開かれるかは、これから出てくる技術文書を待つことになる。

そして鍵は、漏れると終わる。誰でも透かしを偽造できるし、逆に狙って消すこともできる。だから実際の運用では、複数の鍵を用意して定期的に入れ替える、といった管理が要る。第三者に検出手段を開くという要請と、鍵を守るという要請は、正面からぶつかる。ここをどう設計するかが、たぶんこれからの見どころだ。

もうひとつ、地味だが効いてくる制約がある。この透かしは、料理を出しながらリアルタイムに食材を選ぶ方式なので、「あとから文章全体を眺めてバランスを整える」ような凝った入れ方ができない。ストリーミング生成という前提が、手法そのものを縛っている。

7. じゃあ、何のためにあるんだ

ここまでで、けっこう弱点が並んだ。言い換えれば消える。翻訳すれば消える。短い文章では効かない。しかも検証には鍵が要る。

では、なぜ各社はこれを実装しているのか。並べてみると、ここが最後に引っかかった。

答えは、比較対象を見ると分かる。AI文章の検出には、大きく二種類ある。

① 分類器型（GPTZeroなどが得意とするもの）
文章の癖や統計的な特徴から「AIっぽさ」を推測する。鍵がいらないので誰でも使えるが、推測である以上、外す。人間が書いた文章をAI判定してしまう誤検知が、実際に問題になってきた。

② 透かし型（この記事で見てきたもの）
鍵がないと使えない。でも判定は推測ではなく、確率の計算だ。だから「人間の文章を誤ってAI判定してしまう確率」を、あらかじめ数学的に低く設定できる。

ここが決定的な違いだと思う。少なくとも自分が腑に落ちたのは、透かし型の値打ちが「よく当たること」ではなく、「当たったときに、間違っていないと言える」ほうにある、という点だった。

そして、その用途に、ちょうど制度が追いついてきた。

【コラム】ちょうど今月、義務になった
EU AI法（Regulation (EU) 2024/1689）の第50条、透明性義務が、2026年8月2日から適用開始になった。この記事を書いている、つい先日の話だ。

ここで求められているのは、AIが生成したコンテンツを機械が読み取れる形でマーキングすること。不可視ウォーターマークやメタデータ、電子署名などが手段として想定されている。

違反時の制裁上限は1,500万ユーロ、または全世界年間売上高の3%のいずれか高いほう。 なお、8月2日より前に市場投入済みのシステムには移行期間が設けられている。その期限を2026年12月2日とする案も議論されている（Digital Omnibus）。 実際に各社は動いている。

Anthropicは第50条(2)の行動規範に署名し、2026年8月2日以降にリリースするモデルは、生成テキストへの透かし埋め込みと、ファイルへのC2PA準拠の署名付きメタデータ付与に対応すると表明している。

つまり透かしは、「AI文章を見抜くための万能ツール」として求められているのではない。提供者が、自分の出力に印をつけたことを示すための仕組みとして、法的に要求されている。

こう並べてみると、腑に落ちる。透かしは、書き手を追い詰めるための道具ではない。作った側が「これはうちが出力したものだ」と示すための、いわば出荷ラベルなのだ。

ここからは自分の見立てだが、だからこの技術は、破られやすいこと自体は、そこまで致命的ではないのだと思う。求められているのは完璧な防壁ではなく、真正性を示す一次的な手段のほうだからだ。

まとめ

長くなったので、確かめられたことだけ、短く三つに。

ひとつ。 透かしは、文章の意味には触れていない。どちらを選んでも意味が変わらない場面での、単語の選び方に埋め込まれている。しかもそれは「何が選ばれたか」ではなく「どういう順序で選ばれたか」に宿る。カレーからは投入順が復元できないが、文章からは復元できる。文章が、完成品であると同時にレシピでもあるからだ。

ふたつ。 検出は、AIの思考を再現する作業ではない。鍵と本文だけで、偏りを数えるだけの作業だ。だからこそ、数えるものが足りない短い文章や、選択肢の少ない文章には効かない。

みっつ。 言い換え・翻訳・書き直しで消える。これは「味を保ったままレシピを書き換える」行為だからだ。そして検証には鍵が要るので、誰でも自由に検証できるわけではない。それでもこの技術が実装されているのは、「見抜くため」ではなく「印をつけるため」 の仕組みとして、制度が求めているからだ。

比喩は途中で一度壊れたけれど、壊れた場所を掘ったら、いちばん知りたかったことが埋まっていた。ときどき、こういうことがある。

おまけ：で、この記事はどうなんだ

最後に、白状しておくことがある。

この記事は、Claudeに手伝ってもらって書いた。

構成の相談に乗ってもらい、下書きを出してもらって、そこに自分で手を入れて公開している。カレーの比喩も、途中で壊れたときのやりとりも、全部この共同作業の中で起きたことだ。

ということは、だ。そもそもこの記事は、Anthropicの発表から始まったのだった。自分が入り口で通り過ぎた話が、最後に自分に返ってきたことになる。

では、この文章に透かしは入っているのか（入っていると面白いよね）。

公式ドキュメントによると、対象は2026年8月2日以降にリリースされたモデルだ。それ以前のモデルには移行期間が設けられており、対応作業を進めている段階だという（2026年8月12日時点のAnthropicの説明）。

そして今回使ったのは、Claude Opus 5。リリースは2026年7月24日である。

惜しい。

9日違いで、まだ透かしが入らないほうのグループだった。

なんとも締まらないオチだが、これはこれで示唆がある。8月2日という日付は、技術的な節目ではない。新しくリリースされるモデルに規範が適用される、という制度上の線引きにすぎない。9日ずれただけで印の有無が変わるというのは、透かしが文章の性質ではなく、制度の都合で決まっていることの、これ以上ない実例だ。

そう考えると、7章で書いた「出荷ラベル」という見立ては、思っていたよりも正確だったことになる。工場の設備が変わったのではなく、ラベルを貼る決まりができただけなのだから。

もうひとつ。公式ドキュメントには、自分が見落としていた限界が書かれていた。

透かしが検出されても、Claudeが書いたことにはならない。校正や翻訳や要約に使っただけでも、出力には透かしが付く。中身のアイデアや文章が別のところから来ていても、同じように付く。

これは、まさにこの記事のことだ。比喩を考えたのも、カレーで破綻に気づいたのも、スパイスの例に差し替えたのも自分だ。でも透かしの上では、そこに区別はない。透かしが示すのは「誰が考えたか」ではなく、「Claudeを通《とお》ったかどうか」だけなのだ。

ラベルは、中身の著者を保証しない。その工場を通ったことだけを示す。

ちなみに、透かしを検出する手段は、この記事を書いている2026年8月12日時点では、まだ公開されていない。Anthropicは「今後のドキュメントで詳細を共有する」としているだけで、提供時期は明らかにされていない。印は付き始めたが、読み取る手段は間に合っていない。6章で書いた「窓口」は、まだ開いていないのだ。

というわけで、この文章がAIの手を通り、そのあと人間の手を通っていることを、ここに書いておく。透かしより、こっちのほうが確実だ。

おまけ2：公開した翌日に、前提が崩れた

（2026年8月13日 追記）

公開の翌日、この記事の前提がひとつ間違っていたことが分かった。分かったことを、ここにまとめておく。


幕は、2年前に開いていた

Googleは2024年5月から、Geminiのアプリ版・ウェブ版が生成するテキストに、SynthIDによる透かしを入れている。

1章の補足で「方式のひとつ」として名前を出したSynthID-Text。あれは論文の中の話ではなく、すでに動いているものだった。LLM透かしとしては世界初の大規模な実運用で、手法はNature誌に掲載され、実装はオープンソースとしても公開されている。

Anthropicより、2年早い。

この記事は「AI透かしの幕開け」のつもりで書き始めた。だが幕はとっくに開いていて、EU AI法の適用開始とAnthropicの発表がたまたま重なったので、新しい出来事に見えていただけだった。

ついでに言うと、これは1章の裏づけにもなっている。約2,000万件の応答を対象にした比較でも、透かしの有無による利用者評価の差は確認されなかったとされる。「品質を落とさずに埋め込める」は、実地で検証済みだった。

ただし対象は、Geminiのアプリ版・ウェブ版とされている。APIについては透かしの証拠が見つからなかったという第三者の検証もある。同じ会社のモデルでも、経路によって扱いが違う可能性がある。


「印をつける」と「テキストに透かしを入れる」は、別の話

もうひとつ、自分が分かっていなかった区別がある。

その前に、言葉を整理しておきたい。この記事では「印」と「透かし」を書き分けているのだが、説明せずに使っていた。

図：「印」と「透かし」の関係

つまり「印」が上位で、「透かし」はその一種。さらに透かしの中でも、画像とテキストは名前が同じだけで、技術的にはまったく別物だ（3章で「あちらは別の仕組み」と書いたのがこれ）。

この層が混ざると、ニュースの読み方を間違える。

OpenAIは2026年5月、C2PA準拠となり、SynthIDを画像に組み込み、誰でも使える検証ツールまで公開した。かなり踏み込んだ対応である。ただし、やったのは上の二段。テキストへの透かしは公表されていない。

つまり「AI生成物に印をつけている」と「テキストに透かしを入れている」は、別々に確認しないといけない。媒体が違えば技術も違うし、実施の有無も違う。行動規範への署名も、テキスト透かしの実装を意味しない。

テキストの透かしとして主要三社で比較をすると次のようになる。

  • Google … 2024年からGeminiのテキストに透かし（先行）

  • Anthropic … 2026年8月から、対象モデルのテキストに透かし

  • OpenAI … 画像の来歴表示は実施。テキスト透かしは公表なし

7章の「出荷ラベル」という見立ては変わらない。ただ、ラベルを貼り始めた工場は、一つではなかったということだ。


窓口が閉じているのは、Anthropicだけではなかった

6章で「窓口はまだ開いていない」と書いた。これもAnthropic固有の話ではない。テキストの検証手段を一般公開している事業者は、いまのところ存在しない。 Geminiの透かしも、2年前から入っているのに外部から確かめる方法がない。

ところが画像は事情がまるで違う。 上に書いたOpenAIの検証ツールもそうだし、Googleも検証ポータルを持っている。

画像には読み方が用意され、テキストには用意されていない。 印を付けるところまでは同じでも、確かめられるかどうかで差がついている。

理由は想像するしかないが（ここからは自分の見立てだ）、テキストの検出器を公開すると、鍵の推測や偽造につながる懸念が大きいのかもしれない。いずれにせよ6章に書いた「窓口を開けろという圧力」は、Anthropicだけでなく業界全体にかかっていることになる。


で、この間違いから何が言えるか

情けない話だが、書いていて気づいたことがある。

当然ながら、この間違いは、
透かしの有無とは何の関係もない。

仮にこの記事に透かしが入っていたとして、それが示すのは「Claudeを通った」ことだけだ。事実確認が足りていたかどうかは、何も語らない。逆に、透かしがなくても間違いは残る。そして、これも当たり前だけど、

透かしが示すことと、内容が正しいかどうかは、
完全に別の軸にある。

頭では分かっていたつもりだった。7章でも「ラベルは中身の著者を保証しない」と書いている。でも自分でやらかして、ようやく実感した。

なお、本記事の間違い（「Geminiが既にテキストへ透かしを入れている」ことに気づいていなかった）について、本編は直さず、この追記として残すことにした。

この記事は、分からなかったものが分かっていく過程そのものを中身にしてきた。 比喩が壊れたところも、そこから本質が見えたところも、全部残してある。

だったら、公開後に前提が崩れた話も、同じように残すほうが筋が通る。間違いを消すより、間違いが直る過程を一本増やすほうが、この記事らしい。

比喩は途中で壊れ、公開後には前提まで壊れた。掘るたびに何か出てくる。まだしばらく、掘る側にいようと思う。

◆注意◆ 本記事は筆者の個人的な整理・読み物です。
技術の仕組み・制度に関する記述は出典に基づきますが、「透かしは印をつけるための仕組みだ」といった位置づけの評価は、筆者の解釈です。事実と見立てを分けて読んでいただけると幸いです。また、透かし方式は実装ごとに細部が異なります。本記事は、公開されている複数の方式に共通する骨格を、比喩を通して説明したものです。特定のAIの実装をなぞったものではなく、Anthropicは自社の透かしの具体的なアルゴリズムを公開していません。

各社の導入状況は変化します。本編は2026年8月12日、おまけ2は8月13日時点で確認できたものです。

出典・参考

いいなと思ったら応援しよう！