Claudeの透かしの中身が公表された

8月14日、Anthropicが技術FAQを出した。11日のサポートページが「何をするか」を書いたのに対し、こちらは「どう動き、どこで壊れ、何を証明しないか」を書いている。

前稿で外部資料から推定した内容の大半が、提供者の言葉で確認された。訂正すべき箇所も一つ出た。そして外部の実測値は、提供者の説明よりかなり厳しい。

方式はSynthID-Text

Google DeepMindが2024年にNature誌で公表した手法の一種だという。2022年のScott Aaronsonの提案に遡る系統で、設計原理は「語の選択に使う乱数の出所だけを変える」こと。前稿で立てた三系統の分類でいえば、分布保存型にあたる。

Anthropicの説明はこうだ。「今日の天気は寒く、そして」の次に来る語は「どんより」でも「灰色」でもよく、読者にとって差はない。この低リスクの選択を鍵で決める。文字を足すわけでも、隠し文字を入れるわけでもない。

比喩としてモノポリーが出てくる。サイコロの代わりに円周率の桁を使って駒を進める。プレイヤーには何も変わらないが、後から全手を並べて円周率と照合すれば、円周率を使ったゲームだと判定できる。透かしの入ったテキストも同じだ、と。

方式が査読済みであることは、選択として意味がある。Nature掲載の手法をそのまま採用したのだから、堅牢性も限界も先行研究として公開されている。8月11日から14日までの3日間、方式を伏せていたことのほうが不思議になる。

品質への影響について、初めて数字が出た。SynthID-Text論文で、Gemini実トラフィックの一部に透かし版を出し、高評価と低評価の比率を比較している。統計的な有意差はなかった。統制下の人間評価でも差は出ていない。

答え合わせ

エントロピー依存。FAQいわく、事実を述べる箇所では正確さを損なわずに選べる選択肢が少ないため、透かしは薄くなる。挙げられている例が『プリンキピア』の次に来る語で、正解が一つしかないから透かしが作用する余地がない。コードも同じ理由で薄く、ただしコメント部分には乗る。

前稿で「引用、数値、固有名詞、条文の文言」と書いた部分と、指しているものが一致する。

除去。軽い編集では完全には消えない。すべての語を置き換える完全な書き直しなら消える。

証明の限界。ここは提供者のほうが踏み込んで書いている。鍵で分かるのは「Claudeが部分的に書いた可能性はどれくらいか」だけ。人間が書いたかは確認できず、別のAIが書いたかも分からない。そして「Claudeが書いた」と「Claudeが大幅に編集した」を区別できない。

識別情報。含まれない。個人にも組織にも、チャットにも遡れない。透かしとその鍵から利用者に関する情報を復元する経路はない、と明記されている。前稿で触れた「AIに作業者IDが付いた」という読みは、これで成立しなくなった。

外部の数字は厳しい

前稿で引いた翻訳による除去攻撃、CWRAとCLSAは、SynthIDを検証対象に含んでいない。CWRAが試したのはKGW、UW、SIRの三方式。CLSAはKGW、SIR、XSIR、Unigram。

別系統の研究がSynthIDを直接扱っている。

法廷証拠としての適格性を評価した研究がある。Daubert基準とNIST SP 800-86のデジタル鑑識プロセスを枠組みに使い、意味を保った言い換えを攻撃手段として選んでいる。法的に現実的で、しかも証拠の改竄と呼ぶには無理があるからだ。

手法ごとに15種類のプロンプト、計846回の有効な言い換え試行。当初検出されたKGWとUnigramのテキストは例外なく透かしを失った。条件付き除去率100%。SynthIDはわずかに良い程度で98.3%。ただしこの98.3%はMarkLLMというオープンソース実装のSynthID-Textに対する数値であり、Anthropicの実運用版そのものではない。

攻撃前の時点でも偽陰性率が高い。KGW 70%、Unigram 83%、SynthID 80%。

査読分野を対象にした別の実験でも同じ傾向が出ている。ベースモデル構成で、攻撃なしの検出精度がSynthIDは0.909。PEGASUSによる言い換え後は0.135、DIPPERでは0.173。KGWの同条件が0.477と0.754だから、落ち込みはSynthIDのほうが大きい。few-shotとfine-tunedの構成でも、程度の差はあれ同じ順序になる。

品質を犠牲にしない設計が、そのまま言い換えへの弱さになっている。乱数の出所だけを変える方式は、語の並びが保たれている限り信号を運ぶが、並びが変われば運ぶものがない。

逆翻訳についての研究では、透かしの劣化が翻訳品質と相関するという指摘も出ている。機械翻訳が粗いほど、意味が保たれていても信号が歪む。

Anthropicが「軽い編集では完全には消えない」と書いた部分と、外部の実測値には温度差がある。

訂正

前稿で「校正に出せばマークが付き、内容は人間のものであり続ける」と書いた。不正確だった。

FAQによれば、校正では返ってくる文章のほとんどの語が人のものなので、透かしが付着する場所がほとんどない。文法と句読点だけ直させた場合、数箇所の修正にしか宿れず、検出には足りない可能性がある。

一方、翻訳は別扱いになっている。Claudeが生成した翻訳は透かしを帯びる。すべての語がClaudeによって選ばれているためだ。

サポートページが「校正、翻訳、要約、ファイル変換」と一列に並べていたものが、FAQで分解された。校正なら薄く、翻訳なら全部に乗る。実務上の意味がまるで違う。

境目は書かれていない。FAQは「Claudeが書けば書くほど、決定の数が増え、透かしの入る余地が広がる」とだけ述べている。文法だけの修正と大がかりな書き直しの間のどこかに線があるはずだが、その位置は示されていない。日本語話者が書きがちな不自然な英語を段落単位で直してもらう作業は、どちらに入るのか。

日本語で書いた原稿の英訳を任せる書き手にとっては、翻訳の側が効いてくる。

検出APIの形が焦点になる

検出APIを近く提供するという。実装の詳細は調整中。C2PA用には、ファイルを置いて確認できるツールもAnthropic側で用意する。

このAPIがどういう形で出るかは、前稿で書いた「閾値を誰が決めるのか」に直結する。単一の判定を返すのか、生の統計量を返すのか。前者なら区切りの位置を握るのは提供者になり、後者なら使う側が自分で決められる。

参考になるのはGoogleの前例だ。2024年10月、SynthID-Textをオープンソース化している。GitHubとHugging Face Transformers 4.46以降で配布し、Responsible GenAI Toolkitにも収めた。他の開発者が自社モデルの生成物を識別できるように、という趣旨だった。

その検出器の設計が示唆的で、Bayesian detectorは三つの状態を返す。透かしあり、なし、不確定。二つの閾値を設定することで、望む偽陽性率と偽陰性率を実現できる。区切りの位置は使う側が決める。

ただし方式のコードは公開しても、Googleが自社モデルに使っている鍵は公開していない。同じトークナイザを使うモデル同士は設定と検出器を共有できる、とドキュメントにある。方式は開き、鍵は握る。前稿で書いた鍵配布のジレンマに対する、ひとつの実装解になっている。

追加のトークンを生成しないので、速度もコストも変わらない。全世界に適用している理由は、地域で範囲を限定する持続的な方法をまだ持っていないから、と書かれている。所有権や法的責任は変わらない。

面白かったのは、Pangramのような既存のAI検出ソフトとの違いに触れた箇所だ。あちらは鍵を持たないので、言い回しの癖を見ている。AIモデルは「this isn't [X], it's [Y]」という構文を好み、"quietly"を予想以上に多用する。そうした兆候の拾い上げは、透かしの確認とは根本的に別の作業だ、と。

鍵を持つ側が、鍵を持たない検出手法の当てにならなさを説明している。

反応は片側からしか来なかった

発表後、有料利用者を中心に反発が広がった。ある要約は61万ビューを超え、否定的な反応が大きく振れた。

批判の型は三つに分かれる。

一つ目。指示も文脈も判断も無数の推敲も自分が与えた、Claudeは道具だった、それなのに生成物に透かしを入れるのは何の手柄を主張しているのか。これに対しては、手柄の主張ではなくリスクゆえの検出だ、という反論が付いた。

二つ目。他人の作品を吸い上げて作った成果物に透かしを入れるのは偽善ではないか。

三つ目が、質として抜けている。有料利用者の一人が解約の理由をブログに書いた。透明性そのものには反対しない。合成メディアの識別も、詐欺の調査も、来歴の確立も望ましい。反対しているのは、検出器の性能、誤差特性、対象モデル、通知とオプトアウトの規定、そして不利益な解釈に異議を申し立てる手続き、それらを顧客に説明する前に隠れた信号を導入したことだ、と。

擁護側も出ている。自分の頭で考えて自分で書けばいい。人の代わりに考えさせられて時間を無駄にさせる生成物を、簡単に検出できる信号ができたのは歓迎だ。批判側と擁護側が、同じ土俵の上で向かい合っている。透かしがAI使用を判定できるという前提を、双方が共有したままだ。

TechCrunchの見出しは「職場や授業でのカンニングが捕まる」だった。反発の主流をそう読んだわけだ。

前稿で書いた「証明できない側」の声は、三つ目のブログにしか見当たらなかった。

なぜ片側だけなのか

ここから先は推測になる。

検出器がまだ提供されていない。疑われた事例も存在しない。隠したい側は発表を読んだ瞬間に自分の話として認識できるが、証明できない側は実害が出るまで問題を認識しない。時間差がある。

剽窃検出ツールのときも同じ順序だった。導入時に声を上げたのは主に運用側で、誤判定を受けた学生の話が表に出てきたのは、実際に不利益が発生した後だ。引用や定型的な記載が積み上がっただけの数字で疑われた側は、疑われるまで自分が対象だと知らない。

発言のコストも違う。「AI使用を疑われたときに反証できない」と公に書けば、AIを使っている前提で読まれる。前稿で指摘した「開示しないほうが得」という構造が、投稿するかどうかの判断にも働く。

そして140字は「バレる」「困る」を運ぶのに向いていて、「異議申立ての手続きが未整備だ」を運ぶには短すぎる。唯一筋の通った批判が長文ブログに載ったのは、おそらく偶然ではない。

交わし方も書いてある

FAQは除去の条件を明示している。完全な書き直しなら消える。

同じ文が続く。その場合、そのテキストをAI生成と呼べるかどうかは議論の余地がある、と。

実務に落とすと、この条件は重い。論文一本分の英訳を全部書き直すというのは、翻訳を自分でやり直すのとほぼ同じ作業量になる。翻訳を任せた理由が英語運用の負担を減らすことだったなら、回避のために払うコストは、最初に節約したコストとほぼ同額だ。

もっとも、外部の実測値を見る限り、書き直しの徹底度はそこまで要らないらしい。オープンソース実装での試験では、言い換えツールを一度通すだけで98.3%が検出を外れている。手間をかけずに消したい者にとって、条件はFAQが書くほど厳しくない。

残ること

検出APIの提供時期は未定。旧モデルへの対応は、EUが8月2日以前に上市されたシステムに与えた4か月の猶予、12月2日までが目安になる。EUのAI Officeが9月に2つのタスクフォースを設け、署名者間で実装の慣行を持ち寄る場が始まる。

FAQの終盤に、透かしは何を証明するのかという一問がある。答えは、Claudeが何らかの時点で関与した可能性が高いということだけ。「Claudeが書いた」と「Claudeが大幅に編集した」の区別はつかない。

前稿の題は「透かしは『AIではない』を証明しない」だった。提供者は、それが「AIである」も証明しないと書いている。

読んでいただきありがとうございました。
コメント、記事購入、チップ等いつもありがとうございます。
大変感謝しております。
関連記事もありますので、下記サイトマップを参照していただければ幸いです。