Claude透かし検出APIは限定公開〜適格組織の一覧〜

検出器は誰に渡されたか

9月4日、Claude Platformの利用者に通知メールが届いた。9月9日からClaude Opus 5の出力に透かしを適用する、と。

前稿で、Opus 5は7月24日リリースだから移行期間側に入る計算になる、自分が使っているモデルに透かしが入っているか利用者の側から確かめる手段はない、と書いた。そこに日付が入った。

9月1日にはサポートページも更新され、検出の体制が明らかになっている。

9月9日に線が引かれる

メールの内容は事務的だ。透かしは語の選択に現れる知覚できない統計的パターンで、応答の意味も品質も可読性も変えない。文字もトークンも追加しない。価格、遅延、リクエストとレスポンスの形式に影響しない。利用者や組織や会話に関する情報を含まない。利用者側の対応は不要。

モデル層で適用されるため、AWS、Google Cloud、Microsoft Foundry経由でも同じように乗る。

他の現行モデルも数週間かけて順次対応し、各変更の前に日付を告知するという。12月2日の期限に向けた進行になる。

サポートページには、現時点で対応済みのモデルとしてFable 5.1とMythos 5.1の名前が出た。8月の時点では対応モデルの一覧が公表されておらず、自分の使っているモデルが該当するか確かめようがなかった。3週間で一部が出たことになる。ただし完全な対応表はまだない。

書き手にとって意味があるのは、境目が引かれたことだろう。メールの記述に従えば、9月8日までのOpus 5出力に透かしはなく、9日以降にはある。同じモデル、同じ使い方でも、日付で分かれる。

検出APIは限定公開

サポートページの記述が具体的になった。

透かし検出はprivate previewの段階にあり、EU法上の要件として適格な組織に提供されている。列挙されているのは、規制当局、法執行機関、メディア、ファクトチェッカー、独立研究者、教育機関、EUの市民社会団体。加えて、同法の遵守のために透かしの検証義務を負う企業。

アクセス希望は申請フォームから登録する。段階的に拡大する予定だという。

前稿で、秋から年末に限定アクセスのAPIか認証を伴うポータルが出るだろうと書いた。GoogleのSynthID Detectorがジャーナリストや研究者から順に開放する形を採っていたので、同じ設計になるはずだと。実際そうなった。

検出APIを一般公開すれば、何が検出されて何が検出されないかを無制限に試せる場になる。適格性の審査を挟むことで、そこを塞いだ。

責任の分岐も明示されている。Claudeを自社製品に組み込む側は、第50条が自分の製品とサービスに何を求めるかを独立に評価すべきだ、とサポートページに書かれている。マーキングと検出について技術ガイダンスは共有されるが、開示の義務そのものは組み込んだ側が負う建て付けになる。

ファイル側はもう開いている

テキストと違って、ファイルの検証はすでに誰でもできる。

claude.com/check-content で無料のClaude Content Checkerが公開された。画像、動画、音声のファイルを置けば、Claudeが発行したコンテンツ・クレデンシャルの有無を確認できる。処理はブラウザ内で完結し、ファイルは端末の外に出ない。Claude Platformのドキュメントにも技術文書が出ている。

三本目で、検出器も技術仕様も出ていないので検証の道が二重に塞がっている、と書いた。片方が開いたことになる。

ただし開いたのは、元から検証が容易だった側だ。C2PAは暗号署名なので、あるかないかが機械的に分かる。剥がしツールのファイル層が確実に効くと分かっていたのも、同じ理由による。

ファイルは無料で登録もいらず、テキストは申請フォームを通る。同じ「検出」という語の下で、手続きの重さがまるで違う。

線の内側と外側

解釈になるが、適格組織の一覧に教育機関が入っている点は見ておきたい。査読誌や学術出版社は名指しされていないものの、同法の遵守のために検証義務を負う企業という枠がある。メディアとファクトチェッカー、独立研究者も入る。

この線引きは、疑う側にアクセスを与えて、疑われる側には与えない。

学生を検査できる教育機関はAPIを得られる。AI使用を疑われた学生は得られない。投稿原稿を検査する側は枠に入りうるが、英訳をClaudeに任せた著者は入らない。

前稿で書いた需要の非対称が、制度として実装された形になっている。

もっともこれは実装の選択というより、規範の構造から来ている。第50条(2)が求めているのは第三者による検出可能性で、想定されている第三者は規制当局と社会的な検証者だ。個人が自分の潔白を示すための道具としては、はじめから設計されていない。

そして、そもそも透かしは潔白を示せない。陰性はAI生成でないことを意味しないので、APIを手に入れたところで疑われた側の役には立たない。使えないものが渡されていない、という形になる。

剥がす側はどうするか

三本目で書いたとおり、除去ツールの作者は自前の検出機能を実装しようとしていた。GeminiのSynthID、Claudeの継ぎ目、そしてMarkLLMのオープンソース実装が対象に挙がっている。

適格組織でなければAPIを使えないのだから、自前で測る必要は消えていない。むしろ近似のオラクルを持つ動機は強まる。

一方で、適格組織はAPIを持つ。前稿で書いた「検出APIは攻撃者にとってのオラクルになる」という問題は、限定公開で緩和されたが消えたわけではない。列挙された組織の数だけ、経路は存在する。

限界の記述は変わっていない

サポートページの制限の節は、8月11日時点とほぼ同じ内容で残っている。検出されたマークはClaudeが処理した可能性を示すが決定的ではない。校正や翻訳のようにClaudeが原著者でない場合があり、逆にマークが検出されないことも、AI生成でも処理でもなかったことを意味しない。

検出APIが出ても、この片側検査性は変わらない。適格組織が陽性を得ても、分かるのはClaudeが処理した可能性が高いということだけだ。

もう一つ、実務で混同されやすい区別がある。疑われた書き手が実際に突きつけられるのは、鍵を使う透かし検出ではなく、文体の癖を見るスタイル判定器のほうだ。前稿で触れたとおり、そちらは鍵を持たないので言い回しの偏りを拾っている。両者はまったく別の作業で、精度も根拠も違う。誤った告発の実体は、たいていこの後者による。

残ること

9月9日。Opus 5の出力に線が引かれる。

この記事を書いてきた期間の出力が、その境目をまたぐ。

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