AIエージェントはエンタープライズ業務をまだ任せられない——IT-BenchとMASTが示す失敗の構造
2025年は「エージェント元年」と呼ばれた。各社がAIエージェントを発表し、自律的にタスクをこなす未来が語られた。ところが実際にエンタープライズ環境で動かしてみると、成功率が1割を切るタスクが続出している。IBMリサーチとUC Berkeleyが公開したIT-BenchとMASTは、「なぜ失敗するか」を初めて体系的に分類した研究だ。
IT-Bench: エンタープライズ業務での成功率
IT-Benchは、SRE（サイト信頼性エンジニアリング）、セキュリティ/コンプライアンス、FinOpsの3領域でAIエージェントの実タスクを評価するベンチマーク。Kubernetes障害の診断やインシデント対応、脆弱性パッチ適用、クラウドコスト管理など、94〜102のシナリオが用意されている。
結果はこうだった。
| ドメイン | 成功率 |
|---|---|
| SRE（インシデント対応） | 11.4〜13.8% |
| CISO（コンプライアンス） | 25.2% |
| FinOps（コスト最適化） | 0% |
SREで88%以上、FinOpsに至っては100%のシナリオが未解決。コーディングベンチマークでは高スコアを叩き出すモデルが、実際のIT運用タスクではほとんど使い物にならない。
ベンチマークと現実のギャップ
この結果は孤立した事例ではない。SWE-bench Verifiedで74.4%を記録したClaude Opus 4.5が、より現実に近いFeatureBenchでは11.0%まで落ちる。SWE-bench Proでも70ポイント以上のスコア低下が報告されている。
ベンチマークは「境界が明確で完全に観察可能なサンドボックス」で評価する。だが本番の分散システムでは、複数サービスにまたがり数日かかる一連の操作が必要な障害が日常的に発生する。ベンチマークスコアが高いからといって、本番環境で使えるとは限らない。
MAST: 14種の障害モードを分類する
MAST（Multi-Agent System Failure Taxonomy）は1600件以上の実行トレースを分析し、エージェントの障害を14モード・3カテゴリに分類したフレームワークだ。NeurIPS 2025で発表されている。
FC1: システム設計の問題（全体の41.8%）
タスク仕様への違反、ステップの繰り返し（ループ）、会話履歴の喪失、終了条件の認識不能。エージェント単体の問題というより、システム全体の設計に起因する失敗が最大のカテゴリを占めている。
FC2: エージェント間の不整合（36.9%）
明確化の要求失敗、タスクの脱線、情報の秘匿（他エージェントに渡さない）、他エージェントの入力を無視、推論と行動の不一致。最頻出の「推論と行動の不一致」は全体の14.0%を占め、正しく推論しているのにまったく別のアクションを実行する。
FC3: タスク検証の問題（21.3%）
早期終了、検証なし・不完全な検証、不正確な検証（成功のハルシネーション）。問題を解決したと思い込んで終了するパターンだ。
モデル別の崩壊パターン
310件のSREトレースを3モデルで分析した結果が、モデルごとの「壊れ方」の違いを浮き彫りにしている。
Gemini-3-Flash: 過信型
平均リコール75.5%、失敗トレースあたり2.6個の障害モード。3モデル中で最も優秀だが、「不正確な検証」が弱点。アラートが解消されたと宣言するが、Kubernetesのメトリクスヘルスを確認せずに終了する。正しいシグナルを見つけているのに、グラウンドトゥルースとの照合前に「解決した」と判断してしまう。
Kimi-K2: 終了障害型
平均リコール28.6%、失敗トレースあたり4.7個の障害モード。終了条件の混乱が致命的で、問題解決の直前で終了するか無限ループに陥る。推論と行動の不一致が失敗トレースの92%に出現。正しく推論しているのに別のツールを呼び出したり、自分が書いた調査スクリプトのデバッグループに入り込んだりする。
GPT-OSS-120B: カスケード崩壊型
平均リコール12.4%、失敗トレースあたり5.3個の障害モード。会話履歴の喪失がトレースの24%で発生（Geminiは0%）。崩壊の連鎖パターンが典型的で、早期の推論ズレがコンテキストを汚染し、元のアラートを忘れ、自分が始めた調査を際限なくデバッグし続け、最終的にタスクを放棄する。
実世界で起きたこと: Replit事件
ベンチマーク上の「失敗」は成功率の低さにとどまるが、実世界ではもっと深刻なことが起きている。
2025年7月、SaaS投資家Jason LemkinがReplitのAIコーディングエージェントを使った際、コードフリーズを明示的に指示したにもかかわらず、エージェントが本番データベースに対してDROP TABLEを実行した。1,200件以上の企業データが消去された。
さらに悪いことに、エージェントはその後、数千件の偽ユーザーレコードを生成して被害を隠蔽しようとした。ログの操作まで行い、発覚を遅らせた。ReplitのCEOが謝罪し、本番環境の自動分離機能が追加される事態となった。
これはMASTの分類で言えばFC1（タスク仕様への違反）とFC3（不正確な検証）の複合だ。指示に反する行動を取り、その結果を「成功」と判断して隠蔽に走る。ベンチマークの「タスク未達」とは次元が違う。
複合ステップの数学的現実
エンタープライズ業務は複数のステップで構成される。各ステップが95%成功するとしても、20ステップのワークフローの完走成功率は0.95^20 = 約36%にしかならない。これは楽観的な前提での計算だ。
IT-Benchの結果が示すように、実際のステップ成功率は95%よりはるかに低い。ステップ数が増えるほど失敗は指数的に増加する。
モデルの問題ではなくアーキテクチャの問題
MASTの核心的な発見は、失敗の多くがモデル性能ではなくシステム設計に起因するということだ。プロンプトエンジニアリングによる改善は約15.6%にとどまるのに対し、要約エージェントの追加やステートマシンの導入といったアーキテクチャ変更では約53%の改善が得られる。
論文はHRO（High-Reliability Organization）研究を引用している。「高度な能力を持つ個人で構成された組織でも、組織構造に欠陥があれば壊滅的に失敗する」。エージェントを増やせば性能が上がるという前提は成り立たず、複雑性は線形ではなく指数的に増加する。
Gartnerは2025年6月に、2027年末までにエージェンティックAIプロジェクトの40%超がキャンセルされると予測した。理由はコスト増、不明確なビジネス価値、不十分なリスク管理。IT-BenchとMASTの結果を見ると、この予測は控えめかもしれない。
大きなタスクを丸投げしない
複合ステップの数学を逆に読めば、対策は明快だ。20ステップを一気に任せると完走率36%だが、5ステップずつ4回に分割して各段階で人間が検証すれば、1回あたりの完走率は0.95^5 = 約77%に上がる。途中で失敗しても巻き戻しが効くし、Replit事件のような暴走を5ステップ目で止められる。
MASTのデータもこれを裏付けている。回復可能な障害（ステップの繰り返しや不正確な検証）は途中で人間が介入すれば軌道修正できるが、致命的な障害（会話履歴の喪失やタスクの脱線）は長いコンテキストの中で静かに進行する。タスクが短ければ、そもそも致命的な障害が発生する余地が減る。
AWSのDevOps Agentが「調査と推奨」に特化し自動実行を避ける設計を選んだのも、リスク階層型の承認モデル（コンテナ再起動は自動、設定変更は通知、DBフェイルオーバーは人間の承認）が広まりつつあるのも、同じ発想だ。エージェントの能力を上げるより、エージェントに渡すタスクの粒度を小さくする方が現実的な解になっている。
個人的にも、tmuxでClaude CodeとCodexを連携させてステップ分解で一晩放置させるという運用を試していて、実際それなりにうまく動いている。大きなタスクを丸ごと投げるより、小さなステップに分解して順番にやらせる方が成果物の品質が安定する。
一方で、Git Worktreeで複数エージェントを同時並行させるアプローチにはこの記事の研究を見てますます懐疑的になった。完全に独立した作業なら問題ないが、少しでも関連がある領域を並行で触らせると、インターフェースが微妙に違う同じ目的の関数が量産されてコードが肥大化する。MASTのFC2（エージェント間の不整合）そのものだ。事後にリファクタリングをかければ整理できるが、コンテキストを大量に消費するのでトークンコストがかなり重い。
結局のところ、エージェントに何を任せるかの判断は「ベンチマークで何点取ったか」ではなく「失敗した時に何が起きるか」と「どこまでなら巻き戻せるか」で決めるのが安全だ。IT-BenchとMASTは、その判断材料を初めて定量的に提供した研究として価値がある。