業務用AIエージェントの評価に「成功率」だけを使うと、うまくいかなかった理由が一切残りません。IBM Research と UC Berkeley が IT運用タスクの実行トレース310本を失敗の型で分類したところ、失敗した実行1回あたり平均2.6〜5.3個の問題が同時に起きていました。原因が単一でない以上、プロンプトを直すだけでは届きません。
誰が何を測ったのか
IBM Research（Ayhan Sebin、Saurabh Jha、Rohan Arora、Daby Sow）と UC Berkeley（Mert Cemri、Melissa Pan、Ion Stoica）の共同執筆による記事です（出典：Hugging Face ブログ ibm-research アカウント、2026-02-18、https://huggingface.co/blog/ibm-research/itbenchandmast）。
ここで最初に押さえておくべき点があります。この記事は ITBench を開発・公開している IBM Research 自身による発表であり、同社は当該ベンチマークの提供者です。分類の枠組みである MAST も、共著者である UC Berkeley 側が提唱したものです。つまり「自社のベンチマークと自社側の分類法が有用である」と主張する立場の文章であり、数字の出どころとしてはその利害関係を踏まえて読む必要があります。
測定の条件は以下のとおりです。
- 対象は ITBench のうち SRE（IT運用・障害対応）タスク領域に限定
- 分析されたAIエージェントの実行トレースは 310本（3つのモデルクラスにまたがる）
- 内訳は Gemini-3-Flash が100トレース、Kimi-K2 が105トレース、GPT-OSS-120B が105トレース
やっていることは単純です。従来のベンチマークは「タスクを達成できたか」しか返さない。そこに MAST という失敗モードの分類を重ね、1本1本のトレースの中で「どの型の失敗が、どれだけ起きていたか」を数えています。
成功率で並べると見えるもの、消えるもの
まず平均リコール（成績指標）で3モデルを並べると、順位はきれいに付きます。すべて ITBench の SRE タスクでの数値です。
| モデル | 平均リコール | トレース数 | 失敗1回あたりの失敗モード数 |
|---|---|---|---|
| Gemini-3-Flash | 75.5% | 100 | 2.6個 |
| Kimi-K2 | 28.6% | 105 | 4.7個 |
| GPT-OSS-120B | 12.4% | 105 | 5.3個 |
右端の列が、この記事の主題です。失敗したトレースだけを対象にすると、1回の失敗に検出された失敗モードは平均で 2.6個・4.7個・5.3個。失敗は単一原因では起きていないということです。成績が下がるほど、1回の実行の中で同時に壊れている箇所が増えていく傾向が読めます。
成功率だけを見ていると、この右端の列がまるごと消えます。「28.6%でした」という報告は、何を直せばいいかを何も語りません。
失敗の中身はモデルごとに違う
同じ「失敗」でも、型はモデルごとにはっきり傾向が分かれました。
- Gemini-3-Flash：失敗トレース内で FM-3.3「検証が不正確」の出現率が 52%増（成功トレースとの比較）。つまり作業自体は進むが、確認の詰めが甘い方向で崩れる
- Kimi-K2：失敗トレース内で「早すぎる終了」が +46%、「終了条件を認識できていない」が +43% と急増（105トレース中）。やめるべきでないところでやめてしまう
- GPT-OSS-120B：会話履歴を失う失敗（FM-1.4）の発生率が 24%。同じ指標で Gemini-3-Flash は 0%、Kimi-K2 は 7%（各モデルのトレース全体に対する割合）
さらに、推論と実行が食い違う失敗（FM-2.6「推論と実行動作の不一致」）は、Kimi-K2 の失敗トレース中 92%、GPT-OSS-120B のトレース中 94% に出現しています。頭の中で言っていることと、実際に叩いた操作が別、という状態です。
そして最も実務に効くのが次の数字です。FM-1.3「手順の繰り返し」は、Kimi-K2 の「成功した」実行のみを対象にして90%超で出現していました。成功しているのに、無駄な反復が起きている。成功＝効率的、ではありません。
直し方の当たり外れ
記事は、記憶関連の失敗への対処について先行研究の数字を引いています。プロンプト調整など人手の介入による改善は 最大15.6%、要約役のエージェントを追加するといったアーキテクチャ変更による改善は 最大53%。
ただしここは慎重に扱う必要があります。この「15.6%対53%」は本記事の実験結果ではなく先行研究からの引用で、対象タスクもn数も本文に示されていません。方向性の示唆として読むにとどめるべき数字です。
それでも、失敗1回あたり2.6〜5.3個という自前の計測と方向は揃っています。同時に複数壊れているものを、指示文の言い回しだけで直すのは構造的に無理がある、ということです。エージェントの構成そのものについてはAIエージェントとは何かも合わせて読むと整理しやすくなります。
この記事の限界
読者が数字を判断できるよう、書かれていないことも並べます。
- 分析対象は SRE（IT運用・障害対応）タスクに限定されており、経理・営業・カスタマーサポートなど他の業務領域のエージェントに一般化できる保証はありません
- 評価されたモデルは 3つのみです。失敗パターンの傾向を一般論にするには標本が少なすぎます
- 310本のトレースに失敗モードのラベルを付けた方法（人手の注釈かLLMによる自動判定か）、注釈者間の一致率、品質保証の手順が本文に明記されていません。分類の再現性を外部から検証できない状態です
- MAST はあくまで失敗を分類する枠組みであり、記事自体も「ベンチマークは失敗したことは分かっても理由が分からない」という課題への対処を示すもので、包括的な解決策を主張してはいません
- 前述のとおり、ベンチマークと分類法の双方が発信元側の成果物です
中小企業にとって何を意味するのか
ベンダーからAIエージェントの提案を受けるとき、示されるのはたいてい「成功率○％」「精度○％」という単一の数字です。この記事が示しているのは、その数字がうまくいかなかった理由を何も説明しないという事実です。
実務に落とすと3点あります。
- PoCの評価条件に「失敗ログの型別分類」を書き込む。成功率だけでなく、失敗した実行について何がどう壊れたかを型で分類して納品するよう、発注時点で求める。後から頼んでもログが残っていません
- 「プロンプトを直します」で終わる改善提案を疑う。失敗1回あたり平均2.6〜5.3個の問題が同時に起きている以上、単一の対処では届きにくい。構成の変更まで踏み込む余地があるかを確認する
- 成功したケースの手順数も見る。Kimi-K2 の成功実行の90%超で手順の繰り返しが出ていたように、成功していても無駄な反復は起きます。従量課金のAIではこれがそのままコストです
安価・軽量なモデルを選ぶ判断のとき、成功率の差だけで比べるのは片手落ちだということです。評価の物差しを自前で持つ話は自社の評価基準を持つ、コストを含めた見方はコストを含めた評価が対応します。
TOEの読み筋
TOEではこの ITBench / MAST を使った検証は未実施です。そのうえで、社内でエージェントを回してきた立場からの読み筋を書きます。
刺さったのは「成功したのに繰り返しが90%超」という数字でした。社内でも、動いてはいるが同じ確認を何度も走らせているエージェントに心当たりがあります。動いている限り誰も見に行かないので、これは成功率の管理では永久に発見されません。従量課金である以上、静かに費用だけが乗り続けます。
もう一つは「推論と実行の不一致」が失敗トレースの9割超という点です。ログの日本語部分だけを読んで「ちゃんと考えているな」と判断するのが、いかに危ういかを示しています。読むべきは思考の記述ではなく、実際に叩いたツールの列です。
一方で、SRE 限定・3モデルという条件は軽くありません。自社の業務にそのまま当てはめるのではなく、「失敗を型で数える」という手続きの部分だけを借りるのが妥当な使い方だと考えています。型そのものは自社の業務ログから作り直す必要があります。
まとめ
- IBM Research と UC Berkeley が、ITBench の SRE タスクで得たAIエージェントの実行トレース310本を、MAST という失敗モードの分類で数え直した
- 平均リコールは Gemini-3-Flash 75.5%（100トレース）、Kimi-K2 28.6%（105トレース）、GPT-OSS-120B 12.4%（105トレース）だが、失敗1回あたりの失敗モード数は 2.6個・4.7個・5.3個で、失敗は単一原因ではない
- 失敗の型はモデルごとに異なり、会話履歴を失う失敗は GPT-OSS-120B で24%、Gemini-3-Flash で0%、Kimi-K2 で7%と傾向が割れる
- Kimi-K2 の「成功した」実行の90%超で手順の繰り返しが出ており、成功は効率を意味しない
- ただし対象は SRE 限定・3モデルのみ、ラベル付けの方法と品質保証手順は本文に未記載で、発信元は当該ベンチマークの提供者でもある。手続きの考え方として借り、数字は条件付きで扱うのが妥当