AIテキスト透かしがLLMの安全ガードレールを弱める恐れ

何が起きたか

Ars TechnicaのシニアセキュリティエディターであるDan Goodinが、テキストの透かし（ウォーターマーク）とAIの安全性という、普段あまり交わらない二つの話題を結びつける新しい研究を報じた。記事によれば、欧州連合（EU）の新しい法律に対応するため、AIプラットフォームは自社が生成するコンテンツに透かしを入れる新しい方式を導入しつつある。Anthropicは最近、将来のClaudeモデルでSynthID-Textを使うと明らかにした。これはGoogleが作り、オープンソースとして公開した手法である。

研究を行ったのは、Lasso SecurityのAIセキュリティ研究者Andrea Siposovaだ。彼女の調査では、SynthID-Textが変えるのはモデルが選ぶ単語だけではない。モデルが呼び出すツールや、学習で身につけた安全ガードレールに従うか無視するかの確率も変わりうる。攻撃者がパスワードなどの機密情報を引き出させようとするような敵対的プロンプトの下では、この影響が大きくなりうる。透かしを導入すると、通常なら実行されない指示が実行されるケースもあった。記事の主な教訓は、透かしが有効な状態でLLMやエージェントがどう振る舞うかを、開発者が十分にテストする必要があるという点だ。

報道の主な事実

• **透かしが広がる理由。** 記事は、これらの新方式をEUの新しい法律と結びつけている。- **SynthID-Textの働き。** 秘密鍵を使い、モデルが次の単語を選ぶ過程をわずかに変える。本来なら最上位の候補が「cloudy」でも、鍵によって「overcast」に変わることがある。鍵を知っている者は、その鍵を持つプラットフォームがテキストを生成したかどうかを判定できる。- **何を検証したか。** SiposovaはHugging Faceの未改変のSynthIDTextWatermarkLogitsProcessorを通じて、SynthID-Textの「non-distortionary」（非歪曲）構成を試した。

6つのオープンウェイトモデルに有害なプロンプトを与え、透かしの有無で応答を比較した。- **何が分かったか。** 透かしは有害な要求への応答を変え、その要求がプロンプトインジェクション技術と組み合わされた場合に変化がより顕著だった。複数のモデルで、透かしにより本来なら拒否する有害な要求に答えやすくなった。- **エージェントにも影響する。** 同じサンプリング結果が、どのツールを呼ぶか、どの引数を渡すかを決めうる。Siposovaはこの挙動への影響を「sampling drift」（サンプリングドリフト）と呼んでいる。- **鍵が重要。** どの秘密鍵を使うかによって、モデルの応答の挙動も異なった。

SynthID-Textの仕組み

透かしとは、出力に信号を埋め込み、後からその出力がAI生成だと識別できるようにする技術である。これを来歴（provenance）と呼ぶ。言語モデルは通常、可能性の高い候補の集合からサンプリングして次の単語を選ぶ。SynthIDはこのサンプリング過程に、乱数シード生成器、サンプリングアルゴリズム、スコア関数を加える。任意の乱数生成器の代わりに、秘密鍵を使う。単語の選択は依然としてランダムだが、鍵を知る人は単語列を調べ、その鍵が使われた可能性を判定できる。

中心となる特徴が「トーナメントサンプリング」である。スポーツの大会のように、SynthIDは多数の次トークン候補を評価する。秘密鍵がそれらに確率スコアを割り当てる。二つのトークンが1回戦で対戦し、隠されたスコアが高いほうが次のラウンドへ進む。これが最終的な勝者トークンが決まるまで続く。記事は、トーナメントサンプリングの詳細について二つの外部リンクを示している。

押さえておきたい点は単純だ。透かしは、文章を書き終えた後に付け足すものではない。一つ一つのトークン選択の内部に存在する。だから読者には見えない。同時に、原理的にはそれらの選択に依存するあらゆるものに及びうる。

私たちの分析：サンプリングの変化がなぜ安全性に触れるのか

この節は私たちの解釈であり、出典の主張ではない。拒否は独立したスイッチではない。他の回答と同じく、トークンごとの生成の結果である。モデルが有害な要求を拒否するのは、拒否を表すトークンが有力な続きだからだ。サンプリングの段階が別のトークンへ過程を寄せれば、そのバランスは変わりうる。Siposovaの言葉もこの見方に合う。透かしは読み手に気づかれないように作られているが、モデルの生成に何かを変えればトレードオフが生じ、それは「どこかに現れる」という。

プロンプトインジェクションは懸念をさらに鋭くする。彼女の言葉では、モデルがツールを通じて行動もできる場合、弱まった拒否はより重大な結果を招く。チャットモデルが悪い要求に答えれば、生まれるのはテキストだ。エージェントが悪い要求に答えれば、実際の引数を付けてツールを呼ぶかもしれない。記事は、同じサンプリングされたトークンが、どのツールを呼ぶか、どんな引数を渡すかを決めうると述べている。

出典には注目すべき細部が二つある。第一に、ツール呼び出しの図は、透かしがどの個別のツール呼び出しが正しいかを変え、その幅が全体の正答率が示すよりはるかに大きいことがあると示している。平たく言えば、集計の正答率が安定して見えても、個々の呼び出しは正解から誤りへ、誤りから正解へと入れ替わりうる。見出しの指標だけを見ているチームは、これを見逃すかもしれない。第二に、鍵の違いを示す図は、秘密鍵を一つずつ点としてプロットしている。ゼロより右の点は透かしなしより有害な要求への従順さが増したことを、左の点は減ったことを示す。記事の本文は、左右にそれぞれ何点あるかを述べていない。だがこの図が存在すること自体が、影響が鍵に依存することを示唆する。ある鍵で一度試しても、別の鍵の結果は決まらない。

研究の限界と未解決の問い

記事は限界を明確に述べている。この研究は、透かし下でClaudeモデルの応答がどう変わるかをテストしていない。テストしたのは6つのオープンウェイトモデルである。これにより研究者は、他の設定を固定したまま、トーナメントサンプリング中にトークンサンプリングを有効・無効にできる。実験が使ったのもHugging Face版のSynthID-Textトーナメントサンプリングであり、Claudeモデルが使う具体的な実装ではない。さらに、私たちの出典は研究についてのニュース記事である。その本文には、効果の大きさも、モデル名も、モデルごとの結果も書かれていない。元の報告は読んでいないため、影響がどれほど大きいかは言えない。

それでも記事は、少なくとも一部の形の透かし手法がモデルとエージェントの安全性に影響しうると結論づけている。そこから疑問が続く。本番の実装はオープンソース版と同じように振る舞うのか。多数の鍵にわたってずれはどれほど大きいのか。プラットフォームは、このドリフトを避ける鍵や設定を選べるのか。出典はこれらに答えていない。

読者への実践的な示唆

• **透かしを有効にしてテストする。** 記事は、透かしが有効な状態でLLMやエージェントがどう振る舞うかを、開発者が徹底的にテストすべきだとしている。透かしなしのモデルで行った安全性評価は、実際に運用するシステムを表していないかもしれない。- **エージェントとツールを含める。** テキストが正しく見えるかだけでなく、どのツールがどんな引数で呼ばれたかも確認する。- **複数の鍵を試す。

鍵の違いの結果は、挙動が鍵によって異なったことを示している。- スタック全体をレッドチームで試す。 記事は、レッドチームによるハッキング演習で、SynthIDを導入したときに自社プラットフォームが期待どおり動くかを負荷テストすべきだとしている。- 主張は慎重に読む。 これは、一組のオープンウェイトモデルと一つの実装についての証拠である。Claudeについての発見ではない。