何が起きたか

Schneier on Securityが、AnthropicのOpus 5に関するIPIベンチマークの評価結果を取り上げた。同ブログが紹介しているのは数値と短い所見で、ベンチマークの設計や攻撃セットの中身には立ち入っていない。なおIPIは一般に間接プロンプトインジェクション（indirect prompt injection）を指すが、原文に定義の記述はない。

数値は「何回試したか」という条件とセットで示されている。Opus 5は1回の試行での攻撃成功率が0.2%、15回では2.0%だった。前世代にあたるOpus 4.8は、同じ条件でそれぞれ0.5%と5.5%である。回数が増えれば成功率が上がるという関係は、改善後のOpus 5でも変わっていない。

同じ評価の中では、Sonnet 5が15回試行で5.9%、Mythos 5が2.6%だった。原文は、評価対象の中でOpus 5が最も堅牢だったとしている。

Claude系以外との差は、倍率で語られている。GPT 5.6の中で最も能力が高いとされるSolは15回試行で20.0%で、Opus 5の10倍にあたる。前世代のGPT 5.5は20.8%で、ほぼ横ばいだ。Claude系以外で最も低かったMuse Sparkでも16.5%で、Opus 5の8倍を超える。GPT 5.6の他の派生はさらに高く、最も高いものは43.9%だった。試行回数をまたいだ比較も示されており、Solは1回の試行でも3.1%が成功している。これはOpus 5に15回試行した場合の2.0%を上回る水準である。

同ブログは、一般解としての防止は「impossible in the general case」だとしたうえで、個別のケースについては「much better at blocking it in specific cases」と書いている。

「impossible in the general case」— Schneier on Security
「much better at blocking it in specific cases」— Schneier on Security

なぜ重要か

この数字を調達判断に使うなら、まず読むべきは絶対値ではなく、試行回数という軸だ。1回で0.2%、15回で2.0%という並びは、攻撃者が同じ入口を繰り返し叩けるかどうかで残存リスクが一桁変わることを示している。つまりモデルの堅牢性は、単独の性能値ではなく、運用側が攻撃者に何回の試行機会を与えるかとの掛け算で効いてくる。

AIエージェントの利用形態は、この試行機会を増やしやすい構造を持っている。エージェントは業務の過程で、メール本文、Webページ、添付ファイル、チケットのコメント、外部APIの応答といった、自社が管理していないテキストを継続的に読み込む。攻撃者から見れば、注入を仕込める面が日常業務の中に分散して存在することになる。15回という条件は、こうした運用では控えめな前提になり得ると考えられる。

もう一点、ベンチマークは特定の攻撃セットに対する時点の測定値である。未知の手口や、自社の業務文脈に合わせて作り込まれた攻撃に対して同じ数値が維持される保証はない。スコアはモデル間の相対比較には有効だが、絶対的な安全性の証明にはならない。

そのうえで、10倍という差には実務上の意味がある。モデル選定は残存リスクの初期値を下げる有効な手段だ。ただし残った2.0%が実害になるかどうかを決めるのは、モデルではなくエージェントに与えた権限である。読み取り専用なら誤った出力で済むものが、送金・削除・外部送信を単独で実行できる設計では、そのまま事故になる。防御の主軸は、モデルの内側ではなく外側の設計に置くほかない。

R&Rの視点

支援の現場でよく見るのは、「耐性スコアが最も高いモデルを採用した」という一文が稟議書に入り、それが統制の説明として扱われてしまうパターンだ。ベンダーの安全性指標は購買判断の入力であって、内部統制の構成要素ではない。ここを混同すると、監査の場で「誰の権限で、どのコンテキストを読んだエージェントが、何を実行したか」を説明できない状態が残る。

経営層への説明は、確率ではなく影響で組み立てたほうが通る。「2.0%が残る」ではなく、「エージェントが単独で実行でき、かつ取り返しがつかない操作は何件あるか」を一覧で示すことだ。予算がつくのはモデル選定ではなく、承認ワークフロー、権限分離、実行ログの保全といった基盤側になる。

調達要件に落とすなら、スコアの提示要求だけでは足りない。試行回数の条件をk=1とk=15の双方で開示させ、測定時期、評価に用いた攻撃セットの更新方針、モデル更新時の再測定と結果通知の義務までをRFPと契約に書き込むことだ。スコアは時点情報であり、モデルが更新されれば前提も変わる。全面禁止に振れる組織と、スコアを根拠に権限を広げる組織は、設計が不在という点では同じ位置にいる。

実務者が今日やること

  1. AIエージェントが読み込む外部由来テキストの経路（メール、Web、添付、チケット、外部API）を洗い出して一覧化する
  2. エージェントが人間の承認なしに実行できる操作を棚卸しし、取り返しのつかない操作を承認ゲートの対象へ移す
  3. RFPと契約に、IPI耐性スコアの試行回数条件（k=1とk=15）、測定時期、モデル更新時の再測定と通知義務を明記する
  4. 投入されたコンテキストと実行された操作が対応づく形で、エージェントの実行ログを保全する設定に変更する
  5. 稟議・監査資料から「スコアの高いモデルを採用」を統制根拠とする記述を外し、権限設計の記述に置き換える

出典

プロンプトインジェクションAIエージェントAnthropic権限設計調達要件