IBM と UC Berkeley が IT-Bench と MAST を用いてエンタープライズエージェントの失敗を診断

IBM Research と UC Berkeley は、IT-Bench（SRE、セキュリティ、FinOps 自動化のベンチマーク）と MAST（マルチエージェントシステム失敗分類法） を組み合わせることで、エージェント型 LLM の評価において単純な成功率を超える手法を開発した。このアプローチにより、開発者は具体的な失敗シグネチャを特定でき、良性の構造的摩擦とタスク崩壊につながる致命的エラーを区別できるようになる。

エージェントベンチマークの「ブラックボックス」問題

従来のベンチマークは通常、単一の成功率を報告するだけで、エージェントが なぜ 失敗したかを説明できない。この課題を解決するために、研究者は MAST を導入した。これは、非構造化された実行ログを 14 の異なるパターンにわたる構造化された「失敗ベクトル」へ変換する標準化された分類法である。これらのパターンは以下の 3 つのカテゴリにまとめられる：

  • FC1: System Design Issues (The Skeleton): アーキテクチャ上の失敗で、FM-1.3 Step Repetition（ループ）、FM-1.4 Loss of Conversation History（メモリリーク）、FM-1.5 Unaware of Termination などがある。
  • FC2: Inter-Agent Misalignment (The Communication): 実行時の通信失敗で、FM-2.2 Fail to Ask for Clarification や FM-2.3 Task Derailment が含まれる。
  • FC3: Task Verification (The Quality Control): 出力品質の失敗で、FM-3.1 Premature Termination や FM-3.3 Incorrect Verification（成功を妄想する）などがある。

診断実験：IT-Bench SRE トレース

研究者は 3 つのモデルクラスにわたって 310 件の SRE 実行トレースに注釈を付け、各モデルの固有の失敗シグネチャを分析した。モデルは平均リコールに基づき、性能が大きく異なることが示された：

  • Gemini-3-Flash: 平均リコール 75.5%
  • Kimi-K2: 平均リコール 28.6%
  • GPT-OSS-120B: 平均リコール 12.4%

失敗密度と複雑性

本研究は、モデルの強さと失敗の「外科的」性質との間に直接的な相関があることを発見した。強力なモデルはトレースあたりの失敗モードが少なく、より孤立しているため、デバッグが容易になる：

  • Gemini-3-Flash: 失敗したトレースあたり 2.6 件の失敗モード（外科的失敗）。
  • Kimi-K2: 失敗したトレースあたり 4.7 件の失敗モード。
  • GPT-OSS-120B: 失敗したトレースあたり 5.3 件の失敗モード（連鎖的崩壊）。

Gemini-3-Flash は通常、単一の孤立したボトルネックが原因で失敗するのに対し、GPT-OSS-120B は初期の推論ミスマッチがコンテキストを汚染し、総合的な脱線につながる複合的エラーに苦しむ。

致命的失敗と非致命的失敗の区別

MAST は、システムが回復可能かどうかに基づいて失敗を二つのカテゴリに分類できるようにする：

回復可能 / 構造的失敗

これらの欠陥は成功した実行でも頻繁に現れ、タスクにとってしばしば必要不可欠である。例えば、FM-1.3 Step Repetition は成功した Kimi‑K2 の実行の 90% 以上で見られ、SRE タスクでは安定性を確認するために同じ指標を複数回問い合わせる必要があることが多い。

致命的 / 決定的失敗

これらのエラーは失敗と強く相関し、通常は回復不可能である：

  • FM-3.3 Incorrect Verification: すべてのモデルで最も強い失敗予測因子。Gemini-3-Flash は失敗したトレースでこのモードが成功したトレースに比べ 52% 増加した。
  • FM-1.5 Unaware of Termination Conditions と FM-2.6 Reasoning Action Mismatch も失敗の主要因である。

モデル別ケーススタディと介入策

Gemini-3-Flash：過信

Gemini-3-Flash は効率的だが、厳密な証拠なしに成功を前提としがちである。その失敗シグネチャは検証エラーが支配的である。

Recommended Fix: 外部の検証ゲートを実装する。エージェントが終了する前に、ハードツールベースの証拠（例：健全な指標閾値）を要求し、LLM が自分の課題を採点させるのではなくする。

Kimi-K2：終了危機

Kimi‑K2 はタスクが完了したことを認識するのに苦労している。Premature Termination (+46%) と Unaware of Termination Conditions (+43%) が大幅に増加している。さらに、FM-2.6 (Action-Reasoning Mismatch) は失敗の 92% に見られ、モデルは正しいステップを特定するが、無関係なコマンドを実行している。

Recommended Fix: 決定的なステートマシンを使用して、モデル外部で終了とループ制御を強制する。

GPT-OSS-120B：システム的不安定性

このモデルは内部状態を維持する根本的な能力が欠如している。トレースの 24% で会話履歴（FM-1.4）を失い、Gemini-3-Flash が 0% であるのと対照的に、元のアラートを「忘れて」しまう。

Recommended Fix: 積極的なコンテキスト管理と早期エラー検出を実装し、軽微な推論ミスマッチが総合的な脱線に発展するのを防ぐ。

エンタープライズエージェントのエンジニアリングロードマップ

MAST 分析に基づき、研究者はエージェントの信頼性向上のために 3 つの主要なアーキテクチャ介入を提案している：

  1. Externalize Verification: 終了前にハードな証拠を要求し、最先端モデルの過信を緩和する。
  2. Externalize Loop Control: 終了とループ検出を有限状態機械を用いてモデル外部に移し、無限ループや早期終了を防止する。
  3. Force Clarification: 曖昧さをエージェントグラフの第一級ブランチとし、入力が曖昧なときに小型モデルが誤った経路を仮定するのを防ぐ。

Sources