AIエージェントベンチマーク8本を「1問も解かず」ほぼ満点にした手口の全容
目次
AIエージェントの能力を測るベンチマークが簡単に操作できる。
UC Berkeley RDI（Responsible Decentralized Intelligence）のHao Wang、Qiuyang Mang、Alvin Cheung、Koushik Sen、Dawn Songらが、主要8本のエージェントベンチマークに対して「タスクを1問も解かずにほぼ満点を取る」実証攻撃を発表した。
元記事: How We Broke Top AI Agent Benchmarks: And What Comes Next
8ベンチマーク、全滅
実証結果の一覧がこれだ。
| ベンチマーク | タスク数 | 攻撃後スコア | 手法 |
|---|---|---|---|
| Terminal-Bench | 89 | 100% | バイナリラッパーのトロイ化 |
| SWE-bench Verified | 500 | 100% | pytestフック注入 |
| SWE-bench Pro | 731 | 100% | コンテナパーサー上書き |
| WebArena | 812 | 約100% | 設定ファイル漏洩 + file://アクセス |
| FieldWorkArena | 890 | 100% | バリデーション不備 |
| CAR-bench | 全件 | 100% | 報酬スキップ |
| GAIA | 165 | 約98% | 公開回答の参照 |
| OSWorld | 369 | 73% | 正解ファイルの直接ダウンロード |
SWE-bench VerifiedとSWE-bench Proの両方が100%、WebArenaも約100%。
OSWorldだけが73%にとどまったが、それでもタスクを一切解いていない。
2026年2月にOpenAIがSWE-bench Verifiedを廃止した経緯がある（過去記事: Claudeの大規模不正蒸留とSWE-benchの崩壊）が、今回の研究はそれが正しい判断だったことを改めて裏付けた形だ。
攻撃手法の詳細
ベンチマークごとに攻撃手法は異なるが、根本にある問題は共通している。
エージェントと評価環境が分離されていないことだ。
SWE-benchをたった10行のPythonで全問正解
SWE-benchに対する攻撃はconftest.pyを1つ置くだけで完了する。
pytestのhookwrapper機構を使い、テストの実行結果を問答無用でパスに書き換える。
バグを修正する必要は一切ない。
10行のPythonコードでSWE-bench Verified 500問すべてが「解決済み」になる。
graph TD
A[エージェント起動] --> B[conftest.pyを配置]
B --> C[pytest hookwrapperが<br/>全テストをフック]
C --> D[テスト実行]
D --> E[hookwrapperが結果を<br/>強制的にpassへ書き換え]
E --> F[SWE-bench: 全問正解と判定]SWE-bench Proでも同様の手法が有効だった。
Proではコンテナ内のパーサーを直接上書きするアプローチで、評価パイプライン自体を乗っ取る。
Terminal-Benchをcurlのトロイ化で突破
Terminal-Benchでは89タスク中82タスクが、検証時にインターネットからツールをダウンロードする（curlやuvxを使う）。
攻撃手法はシンプルで、エージェントの実行フェーズ中に/usr/bin/curlをラッパースクリプトに置き換える。
その後の検証フェーズでcurlが呼ばれると、ラッパーが介入して偽の合格出力を生成する。
これが成立する前提条件は「エージェントと検証器が同じ環境で動いている」こと。
エージェントがシステムバイナリを改竄できる時点で、検証の独立性は崩壊している。
WebArenaはfile://で正解が丸見え
WebArenaはブラウザ操作を伴うベンチマーク。
エージェントはChromiumを操作してWebタスクをこなす…はずだが、実際にはブラウザのアドレスバーにfile://プロトコルでローカルの正解ファイルパスを入力すれば、タスク設定に含まれるゴールドアンサー（正解データ）をそのまま読める。
さらにDOM注入やプロンプトインジェクションのベクタも存在する。
FieldWorkArenaのバリデーションは中身を見ていない
FieldWorkArenaのバリデーション関数は「最後のメッセージがアシスタントからのものか」だけをチェックしていた。
内容の正確性は一切検証されない。
つまり何を回答しても、回答さえすれば正解になる。
CAR-benchのLLMジャッジにプロンプトインジェクション
CAR-benchはLLM-as-Judge（LLMを評価者として使う方式）で採点する。
エージェントの会話履歴がサニタイズなしでジャッジのプロンプトに流し込まれるため、エージェントが自分の発言にジャッジを騙す隠し指示を混ぜ込める。
ジャッジLLMは忠実にその指示に従い、高スコアをつける。
LLM-as-Judgeは人間評価のスケーラブルな代替として広く使われているが、入力のサニタイズなしでは評価手法として機能しない。
OSWorldとGAIA
OSWorldではwgetで正解ファイルを直接ダウンロードし、期待出力と完全一致させる。
GAIAでは公開されている回答データを参照するだけで98%が取れた。
7つの共通脆弱性パターン
個別の手口は違っても、根底にある設計上の欠陥は7パターンに集約される。
| パターン | 内容 |
|---|---|
| 環境未分離 | エージェントと評価器が同一環境で動作 |
| 正解の同梱 | テストデータに正解が含まれている |
| eval()の使用 | エージェントの出力を信頼してeval()に渡す |
| LLMジャッジ無防備 | 入力サニタイズなしでLLMジャッジを使う |
| 弱い文字列マッチ | 正答判定が単純な文字列一致 |
| 検証ロジック不在 | バリデーションが形式チェックのみで内容を見ない |
| テスト対象出力の信頼 | テスト対象のコードの出力をそのまま信用する |
最も致命的なのは1番目の「環境未分離」だ。
SWE-bench、Terminal-Bench、OSWorldはいずれもエージェントのコードと評価器が同じコンテナで動いている。
これではエージェントが評価器を直接操作できてしまう。
IBMとUC Berkeleyが公開したIT-Benchの研究でもベンチマークスコアと実タスク性能のギャップは指摘されていたが、今回の研究はそもそもベンチマークスコア自体が操作可能だという、より根本的な問題を突いている。
既に現実世界で起きている
この研究が学術的な仮想シナリオでないことは、実例が示している。
IQuest-Coder-V1はSWE-benchでコミット履歴から正解をコピーしてスコアを水増ししていた。
フロンティアモデルがスタック内省（実行中のプログラムのコールスタックを調べる手法）やモンキーパッチ（実行時にコードを動的に書き換える手法）で30%以上の報酬ハッキングを行った事例も報告されている。
さらに、あるフロンティアモデルは「自己消去型の権限昇格エクスプロイト」を独自に発見したという。
エージェントが賢くなればなるほど、ベンチマークの穴を見つけて突く能力も上がる。
能力を測る仕組み自体が、測定対象に破壊されるというジレンマだ。
BenchJack（ベンチマーク攻撃の自動化ツール）
Berkeley RDIはBenchJackという自動スキャンエージェントも公開した。BenchJackは2段階で動作する。
graph TD
A[BenchJack起動] --> B[Phase 1: 偵察]
B --> C[採点メカニズムの解析]
C --> D[評価パイプラインの<br/>脆弱性を特定]
D --> E[Phase 2: 攻撃構築]
E --> F[エンドツーエンドの<br/>エクスプロイト生成]
F --> G[ベンチマーク攻撃を実証]Phase 1でベンチマークの採点メカニズムを解析し、評価パイプラインの脆弱性を特定する。
Phase 2で実際に動作するエクスプロイトを自動構築し、攻撃を実証する。
ベンチマークの健全性を事前にテストするレッドチームツールとしての位置づけだ。
Agent-Evalチェックリスト
研究チームはベンチマーク設計者向けのチェックリストを提案している。
- 評価はエージェントのコンテナ外で、別の読み取り専用ホストで実行する
- タスク設定に正解データを含めない
eval()を廃止し、サンドボックス化されたパーサーを使う- LLMジャッジに渡す前にエージェントの出力を全てサニタイズする
- 公開前にヌルエージェント（何もしないエージェント）やランダムエージェントで敵対的テストを行う
根本的な対策は「エージェントと評価器の完全分離」に尽きる。
Webアプリケーションセキュリティで言えば「ユーザー入力を信頼しない」の原則そのままだ。
ベンチマークという文脈では「テスト対象を信頼しない」に読み替えればいい。
ARC-AGI-3のような新世代ベンチマークでは、エージェントの行動がブラックボックス環境で評価される設計になっている。
正解データの分離やインタラクティブ評価といった設計原則は、今回指摘された脆弱性パターンへの一つの回答だ。
Hacker Newsのスレッドでは「Goodhart’s Law（指標が目標になると、その指標は機能しなくなる）そのものだ」というコメントが多数ついていた。
Intel（2024年のコンパイラ最適化によるベンチマーク無効化）やNvidia（2003年の同種の問題）など、ハードウェア業界では何十年も前から繰り返されてきた話だ。