AIエージェントは「なぜ」失敗するのか、ようやく答えが出た
AIエージェントのベンチマーク評価は長らく「成功率」という1つの数値に集約されてきた。しかしその数値は「失敗した」という事実を伝えるだけで、「なぜ失敗したか」は教えてくれない。IBMリサーチとUCバークレーの研究チームは、このブラックボックス問題に正面から取り組み、その結果を公開した。
ITBench × MASTによる診断アプローチ
研究チームが活用したのは2つのフレームワークだ。
ITBenchはSRE（サイト信頼性エンジニアリング）、セキュリティ、FinOpsの自動化タスクを対象とした業界標準ベンチマークで、Kubernetesの障害診断やクラウドコスト最適化など、実務に近い長期タスクをエージェントに課す。
MAST（Multi-Agent System Failure Taxonomy）は、複雑なマルチエージェントシステムの失敗モードを体系的に分類するフレームワーク。1,600件超のトレースを分析して導出されたもので、単なるエラーログではなく「どの判断プロセスで何が崩壊したか」を構造化して記述できる。
今回の研究では、Gemini-3-Flash、Kimi-K2、GPT-OSS-120Bという3クラスのモデルに対して310件のITBench SREトレースをMASTで注釈付けし、失敗パターンを比較分析した。
3つの主要な発見
1. フロンティアモデルは「局所的に」失敗する
Gemini-3-Flashのような最先端モデルは、1トレースあたり平均2.6の失敗モードに留まり、失敗は比較的孤立している。典型的なボトルネックは「検証フェーズ」——タスクを完了したと判断する段階での誤りだ。
2. 大規模オープンモデルは「連鎖的に」崩壊する
GPT-OSS-120Bでは1トレースあたり5.3の失敗モードが観測された。初期の推論ミスがコンテキストを汚染し、その後のステップで幻覚（ハルシネーション）が雪だるま式に増加する「カスケード障害」が特徴的だ。
3. 最大の失敗予測因子は「自己採点」
モデルの種類を問わず、最も強力な失敗予測因子はFM-3.3（不正確な検証）だった。エージェントはしばしば、実際には問題が解決されていないにもかかわらず「タスク完了」を宣言してしまう。自分の宿題を自分で採点させることの危険性が数値で示された形だ。
Kimi-K2には特有の問題もあった。タスク完了の認識に問題があり、「早期終了（+46%増）」と「終了条件の未認識（+43%増）」が突出して多く、解決直前で諦めるか、逆に無限ループに陥るケースが頻発した。
実装への提言
研究チームはこれらの知見から、エージェント設計者向けの具体的な対策を提示している。
- 検証の外部化：LLMに自己評価させるな。終了前にツールによるハードな証拠を必須とせよ
- 終了制御をモデルの外に置く：ループ検出器や有限状態機械（FSM）を明示的に実装し、同一アクションの繰り返しを制御する
- 曖昧な入力への対処を一級市民に：入力が不明瞭な場合、「明確化を求めるか読み取り専用で進む」という分岐をエージェントグラフに組み込む
エンタープライズAI開発への示唆
この研究が重要なのは、「成功したか否か」の先にある問いを提示している点だ。「何が壊れ、どこで壊れ、どの介入が最も効果的か」——これこそが本番環境でのエージェント開発に必要な評価観点であり、MASTはその答えを導き出す実践的な枠組みとして今後の標準となり得る。
ITBenchのデータセットとMASTの注釈データはHugging Faceで公開されており、GitHubでもコードが利用可能だ。エンタープライズ向けAIエージェントを設計・評価している開発者にとって、必読の研究成果といえる。