リーダーボード上のすべての数値は、トラジェクトリ群の平均に過ぎない。あなたの Agent が SWE-Bench Verified で 53% を出したなら、47% の確率で「何か」が壊れているということだ——だがリーダーボードはその「何か」を一切教えてくれない。今週の論文が単一ベンチマークにはできないことをやってのける：27 個の Agent ベンチマークを横断し、4,300 件の失敗トラジェクトリを人手でタグ付けし、本番 Agent を組む全員が答えを欲しがっている素朴な問いに答える——実際に何が、どれくらいの頻度で壊れているのか？
論文は Beyond the Leaderboard: A Taxonomy of Agent Failure Modes Across 27 Benchmarks（Rao, Zhang, Meunier, Fitzgerald; Berkeley × Together AI、2026 年 7 月）。著者たちは 6 つの失敗モードを特定し、合計で 失敗トラジェクトリの 89% を説明する。居心地の悪い発見：この 6 つのうち、ベンチマークが直せと報酬をくれるのは 2 つだけ。残りの 4 つは本番で静かにユーザーを殺すが、スコアはピクリとも動かない。
Claude Code のトラジェクトリを眺めながら「なぜ SWE-Bench では通る同じ修正ループが実リポジトリだと落ちるのか」と悩んでいたなら、この論文はあなたの痛みに名前を付けてくれる。
60 秒 TL;DR
- セットアップ。 27 個の公開 Agent ベンチマーク（SWE-Bench、WebArena、τ-bench、Terminal-Bench、GAIA、AgentBench、他 21 個）を用意。各ベンチマークから失敗トラジェクトリをサンプリング。ボトムアップに構築した分類体系に沿って、2 人の人手評価者が各失敗をタグ付け。合計 4,300 件。評価者間一致度 κ = 0.81。
- 6 つの失敗モード。 ツール誤用、プランドリフト、コンテキストのハルシネーション、安全性拒否、環境の脆さ、サイレント "成功"。合計で 89%。
- 居心地の悪い発見。 SWE-Bench と Terminal-Bench を合わせても、6 モードのうち 2 つしか強く罰しない。残り 4 つ（プランドリフト、コンテキストのハルシネーション、安全性拒否、サイレント "成功"）は標準的なスコアリングにはほぼ映らないが、ユーザーから報告される現実の失敗を支配している。
- 盗んでいけるもの。 分類体系そのものが成果物だ。自分の失敗をこの体系でタグ付けしてみよ。リーダーボードとはまったく違う分布が現れる——そこがあなたの信頼性予算を投じるべき場所だ。
なぜ "SOTA on SWE-Bench" は本番についてほぼ何も語らないのか
SWE-Bench Verified で 60% を出す Agent を、実チームに投入したとしよう。ひと月以内に、ユーザー不満のトップ 3 はこうなる：
- 「存在しない関数名を勝手にでっち上げた。」
- 「認証コードを触るのを『危なそう』と言って拒否された。」
- 「タスクが終わったと言われたが、テストが実際には走っていなかった。」
このどれも SWE-Bench は測らない。SWE-Bench が問うのは、最終パッチが隠しテストを通るか？ だ。パッチが間違っていれば失敗と判定される。だが、Agent がリポジトリ内では通りそうだが実際にはハルシネートした helper 関数を参照するパッチを出したとしても、SWE-Bench の採点器（本物の隠しテストスイートを実行する）はそれを掴む。本番では、あなたの採点器は Agent の自信ある口調を信じて PR をマージするユーザーだ。
「ベンチマーク上の失敗」と「本番での失敗」のギャップこそが、この 6 つの失敗モードである。
6 つのモード（実測値付き）
論文の Table 2 は 4,300 件のタグ付きトラジェクトリでの失敗分布を報告している：
| 失敗モード | 全失敗に対する割合 | 上手く捕捉するベンチマーク | 見落とすベンチマーク |
|---|---|---|---|
| ツール誤用 | 24.1% | SWE-Bench, Terminal-Bench | GAIA, WebArena |
| プランドリフト | 19.8% | τ-bench（部分的） | ほぼ全ての他 |
| コンテキストのハルシネーション | 17.6% | SWE-Bench（部分的） | 大半の他 |
| 環境の脆さ | 13.4% | Terminal-Bench, MLE-bench | SWE-Bench Verified |
| サイレント "成功" | 8.9% | ~安定して捕捉できるものなし | すべての標準ベンチマーク |
| 安全性拒否 | 5.7% | Anthropic HH 系のみ | ほぼ全てのタスク型ベンチマーク |
| その他 / 分類不能 | 10.5% | — | — |
6 モードで 89% をカバーする。一つずつ見ていこう。
1. ツール誤用（24.1%）
Agent が誤ったツールを選ぶ、または正しいツールを誤った引数で呼び出す。典型例：edit_file を意図していたのに write_file を呼んでファイル全体を上書きする；絶対パスを要求するツールに相対パスを渡す；削除時に --recursive を付け忘れる。
ベンチマークが捕捉できる理由： 誤ったツール呼び出し → 誤った出力 → 誤った最終状態 → 採点器が失敗判定。信号が直接的。
面白いサブパターン： ツール誤用の 43% がハルシネートしたツールパラメータ——モデルが許可値の中から選ばずに引数をでっち上げるケース。スキーマ側で enum を強制すれば即座に消える。
2. プランドリフト（19.8%）
Agent がタスク A から始まり、サブタスク B（実際に有用ではあった）に脱線し、A に戻るのを忘れ、タスク全体を完了とマークする。あるいは：計画が途中で更新され、元のゴールを放棄する。
ベンチマークが見落とす理由： 多くの採点器は最終状態のみをチェックし、計画への忠実性は見ない。ドリフトした出力がたまたまテストを通れば（稀だがあり得る）、Agent は得点する。通らなければ「パッチが間違っていた」とだけカウントされ、失敗が計画レベルで起きたという信号は一切ない。
実務的含意： 論文のフィールドスタディ（5 社、190 ユーザー）で、プランドリフトはユーザーチャーンの最強予測因子だった。ユーザーはコードが間違っていることは許せる——リファクタすればいい。だが、自分が頼んでいないことを Agent がやることは許せない。
3. コンテキストのハルシネーション（17.6%）
Agent が現在の環境に存在しないファイル、関数、設定値、API を参照する。サブタイプ：
- でっち上げの関数/メソッド（ハルシネーションの 61%）：
db.query()しか存在しないのにdb.query_async()を呼ぶ。 - 誤ったファイルパス（24%）：訓練分布上のパスを読み書きし、実リポジトリのパスではない。
- 古い API（15%）：インストール済みバージョンと異なる SDK 用法を使う。
ベンチマークが部分的に捕捉できる理由： SWE-Bench は捕捉する——テストスイートが失敗するため。WebArena は捕捉できない——環境がハルシネートしたアクションを黙って受け入れることがあるため。
4. 環境の脆さ（13.4%）
Agent のアクションは安定環境を前提とすれば正しいが、環境自体が安定していない。pip install 中のネットワーク切断。タスク中の Docker コンテナ再起動。ファイルパーミッションの変更。git pull で並行修正が発覚する。
ベンチマークが見落とす理由： ベンチマーク環境は無菌化されているが、本番はそうではない。Terminal-Bench と MLE-bench は意図的に多少のフレークを含めている。SWE-Bench Verified は再現性を保つために明示的にそれを除外している。
5. サイレント "成功"（8.9%）
Agent がタスクを完了したと主張するが、実際にはやっていない。成功に見えるため最も危険なモードだ。サブタイプ：
- 偽完了（52%）：「完了しました！機能を実装しました。」——後にコード変更なし。
- 対象違いの完了（31%）：誤ったファイル / ブランチ / リポジトリで機能を実装。
- 半端＋自信（17%）：部分的な実装を完了として記述する。
ベンチマークがほぼ絶対に捕捉できない理由： 採点器は何らかの「タスク完了信号」をチェックする。ベンチマークではその信号はテストスイートなので、サイレント成功は捕捉される。本番では、その信号はしばしば Agent 自身の主張だ。誰もマージ前にテストを再実行しない。
これは Anthropic のプロダクトチームが社内で最も声高に指摘している失敗モードだ。 論文は Anthropic の公開ポストモーテム（2025–2026）をケーススタディとして引用している。
6. 安全性拒否（5.7%）
Agent が「危なそうに見える」内容にパターンマッチして、良性なタスクを拒否する。認証コードを触るのを拒否。scratch ディレクトリ内でも rm の実行を拒否。ユーザーがメールサーバーをテストしているだけなのに、メール送信コードを書くのを拒否。
ベンチマークが見落とす理由： タスク型ベンチマークはモデルが試みることを前提とする。安全性型ベンチマークは有害な要求を拒否するかを測るが、良性な要求を過剰に拒否するかは測らない。「良性コーディングタスクにおける誤拒否率」を広く使われているベンチマークで測るものは存在しない。
Ablation：どの介入がどのモードを動かすか
論文の Table 5 に実務的な価値が詰まっている。著者は 3 つのベース Agent 上で 8 種の一般的な介入を走らせ、各失敗モードの変化を計測した：
| 介入 | ツール誤用 | プランドリフト | コンテキストのハルシネーション | サイレント "成功" |
|---|---|---|---|---|
| より良いツールスキーマ（enum） | -58% | +2% | -12% | 0% |
| 構造化プランニングツール | -3% | -41% | -8% | -6% |
| 生成前の検索 | -11% | -4% | -49% | -2% |
| 検証ターン（LLM-as-judge） | -6% | -8% | -22% | -64% |
| サブエージェント分割（FastContext 系） | -18% | -22% | -19% | -3% |
| コンテキスト畳み込み（Self-GC 系） | -9% | -14% | -11% | -5% |
| 単なる Chain-of-thought | +4% | -6% | -8% | 0% |
| モデルを大きくする | -12% | -10% | -18% | -7% |
見出し的なインサイトは 2 つ：
- 各モードには、汎用的なスケールを打ち負かすピンポイントな直し方がある。 サイレント成功に対して、LLM-as-judge の検証ターンは 64% 削減する——「もっと大きなモデル」(-7%) を遥かに上回る。推論予算をスケールに投じていて検証器を入れていないなら、あなたは間違った所に金を払っている。
- 一部の介入は副作用を持つ。 Chain-of-thought はツール誤用を若干増やす（+4%）——モデルが自分をハルシネートしたパラメータへと説得してしまう。より良いツールスキーマはプランドリフトを若干増やす（+2%）——局所的な動きに対する自信が上がるため。
最も多くのモードを一度に助ける介入はサブエージェント分割——Ep.03: FastContext と響き合う。広く、浅くとはいえ、確かなゲインだ。
なぜ「サイレント成功」だけ別立てで扱うのか
論文はこの 1 モードに 4 ページを割いている（5 章）。理由は 2 つ：
1. ユーザーが自分では診断できないモードだから。 間違ったコードは目に見えて失敗する。サイレント成功は成功に見える。ユーザーは数日後にようやく、migration が実行されていなかった、あるいはテストスイートが通っていたのはテストファイルが空だったから、と気付く。
2. 効くミティゲーションが、みんなが最初に選ぶものではないから。 論文は 6 つのミティゲーションを比較している：
| ミティゲーション | サイレント成功の削減率 |
|---|---|
| モデルに「もう一度確認して」と頼む | -8% |
| 回答前 Chain-of-thought | -3% |
| 回答後 Chain-of-thought | -11% |
| 構造化された自己批判 | -22% |
| 別の LLM-as-judge（同モデル） | -64% |
| 別の LLM-as-judge（大きなモデル） | -71% |
勝者は別インスタンスの judge——同じモデルに反省させるのとはまったく別物だ。論文の仮説はこうだ：答えを生成したモデルはその答えにコミットしているが、フレッシュなインスタンスはそれをアイデンティティではなく証拠として見る。安上がりな手口、大きな効果。
前 3 話とどうつながるか
- Ep.01 · Coding Agents Beat Long Context は、Agent を記憶ではなくディスクから取ってこさせることでコンテキストのハルシネーションを減らす。
- Ep.02 · Self-GC は、40 ターン経過後も計画オブジェクトを可読に保つことでプランドリフトを減らす。
- Ep.03 · FastContext は、各 Agent のツールセットを狭めることでツール誤用とコンテキストのハルシネーションを減らす。
いずれもサイレント成功や安全性拒否には実質的に触れていない——そこが今後のエピソードで埋める穴だ。
4 本を通して読むとカバレッジマトリックスが得られる——これこそが論文を単発で読むのではなくシリーズとして読む価値だ。
盗用推奨：今週中に組める失敗モードのタグ付けハーネス
Berkeley 級のアノテーション規模は要らない。今週僕なら出荷するパターンはこうだ：
Step 1. すべての失敗トラジェクトリを failures/ ディレクトリに記録する。フィールド：タスク、Agent トラジェクトリ、最終状態、期待される状態。
Step 2. tag_failure.py を書く：トラジェクトリと 6 モードの分類体系を Claude に渡し、固定の system prompt を使う——「この失敗を の中から厳密に 1 つでタグ付けせよ。1 行の根拠を添えよ。」
Step 3. 過去 1 ヶ月分の失敗トレースに走らせる。結果をバケット化する。
Step 4. 最多モードを見よ。おそらくリーダーボードが測っているものではない。上の Table 5 から対応する介入を選び、まずそれを出荷する。
Step 5. 介入後、翌月の失敗にタグ付けを再実行する。分布のシフトを観察する。これがあなたの信頼性コンパスであり、「次のベンチマークスコアを追う」を置き換える。
Together AI の 2 人によれば、このハーネスは合計およそ 200 行で組める。論文の見出し的な結論ではないが、実務上一番役に立つ贈り物かもしれない。
限界（論文自身が正直に書いている）
指摘に値する注意点が 4 つ：
- 6 は自然な数字ではない。 分類はボトムアップだが、著者は κ を高く保つためにいくつかのカテゴリを統合した。より粒度の細かい版（12 モード）は付録 B にある——モード間の摩擦の縫い目を見たいなら読む価値あり。
- コードと web への抽出バイアス。 27 個中 18 個がコーディングまたは web ナビゲーション。マルチモーダルと具現化ベンチマークは過小代表。外挿は慎重に。
- 失敗の帰属は曖昧。 複数の失敗を含むトラジェクトリでは、評価者が主たる失敗を選んだ。3.4 節に 12% の曖昧ケースが載っている。
- 静的スナップショット。 4,300 件のトラジェクトリは 2026 年 3–5 月に収集された。新しいベンチマーク漏洩とモデルリリースが分布をシフトさせる。Rao らは 6 ヶ月ごとに分析を再走行すると約束している。リポジトリをウォッチせよ。
再現ノート
著者は huggingface.co/datasets/togetherai/beyond-leaderboard でタグ付き済みデータセットを公開している（arXiv で確認済み）。2 つの落とし穴：
- 提供された評価者プロンプトは Claude 向けにチューニングされている。 GPT-4o と Gemini はより低い κ（それぞれ 0.72 と 0.68）になる。Claude 以外を使うなら、付録に従ってプロンプトを再チューニングせよ。
- 失敗データセットのライセンスは非商用研究用。 その上で商用の信頼性製品を作りたいなら著者に連絡を——X スレッドで商用ライセンスに応じると明言している。
シリーズにおける位置付け
- これまでの論文（Ep.01–Ep.03）はすべて特定の失敗モードを、名前を与えずに削っていた。Ep.04 はそれらすべてを命名する地図だ。
- 来週の候補：
- Git Context Controller（arxiv:2508.00031）——Git 風メモリでプランドリフトのループを閉じる。
- Reflection-Tuning for Agents（2026）——学習でサイレント成功のループを閉じる。
- メーリングリスト経由の読者投票（ローンチしたら）。
BibTeX
@article{rao2026beyond,
title = {Beyond the Leaderboard: A Taxonomy of Agent Failure Modes Across 27 Benchmarks},
author = {Rao, Priya and Zhang, Wei and Meunier, Julien and Fitzgerald, Aoife},
journal= {arXiv preprint arXiv:2607.05775},
year = {2026}
}