- IBM ResearchとArtificial Analysisが2026年5月27日、エンタープライズIT特化のAIエージェント評価ベンチマーク「ITBench-AA」を公開
- Claude Opus 4.7・GPT-5.5・Gemini 3.5など主要フロンティアモデルが全て50%未満のスコアに留まる
- 最高スコアはClaude Opus 4.7の46.7%、最下位はGemini 3.1 Pro Previewの30%
- ターン数を増やすほどスコアが下がる「深掘りの沼」現象を確認
- SIerやDX担当者にとってAIエージェント期待値の再設定を迫る重要な指標になる
「AIエージェントが企業のIT運用を自動化する」という宣伝文句を、最近よく耳にしませんか?IBM Researchが2026年5月27日に公開した新ベンチマークの結果は、その期待に冷や水を浴びせるものでした。最先端AIですら、エンタープライズIT業務では半分も正解できないのです。
ITBench-AAとは|IBMとArtificial Analysisの共同ベンチマーク
既存ベンチマークが「飽和」していた問題
これまでAIエージェントの能力を測る指標として、SWE-benchやGAIAといったベンチマークが使われてきました。
しかし、これらはすでに高スコアモデルが続出して飽和しており、最新モデル同士の本当の実力差が見えづらくなっていました。
たとえばSWE-benchではClaude Opus 4.7が87.6%を記録するなど、上位モデルが90%近くに達しています。これでは「どれを選んでも同じ」と感じてしまいますよね。
そこでIBM Research(IBMの研究部門)とArtificial Analysis(AIモデル評価専門の独立研究機関)が手を組み、エンタープライズITの現場に特化した新しい評価基盤を作ったのです。
評価対象は59個のKubernetesインシデント
ITBench-AAの第一弾はSRE(サイト信頼性エンジニアリング)領域の59タスクです。
内訳は公開タスク40個と非公開のホールドアウトタスク19個。Kubernetes(コンテナ運用基盤)クラスタで実際に発生するインシデントを再現しています。
故障シナリオの例は次のとおりです。
- リソースクォータが枯渇してPod(コンテナ単位)が起動しない
- 新バージョンへのロールアウトが失敗する
- データベースへのコネクションプールが枯渇する
- ネットワークパーティションが発生して通信が分断される
AIエージェントには100ターンまでのシェルアクセスが与えられ、各タスクを3回ずつ評価。合計177回の試行で実力を測ります。
ベースになっているのは、IBM自身がSaaS事業で実際に経験したインシデント群です。机上の空論ではなく、本番運用で起きた生々しい障害が題材になっているわけですね。
衝撃の評価結果|全モデルが50%未満
上位モデルのスコア表
結果は衝撃的でした。主要なフロンティアモデル全てが50%の壁を越えられなかったのです。
上位モデルのスコアは次のとおりです。
- Claude Opus 4.7(Adaptive Reasoning): 46.7%、平均26ターン、1タスク$5.38
- GPT-5.5(xhigh設定): 45.8%、平均31ターン
- Qwen 3.7 Max: 42.5%
- GLM-5.1(Reasoning): 40%、1タスク$1.23
- Gemini 3.5 Flash(high): 40%、1タスク$1.70
- DeepSeek V4 Pro: 38%
- Gemma 4 31B(Reasoning): 37%、1タスク$0.14
- Gemini 3.1 Pro Preview: 30%、平均83ターン、1タスク$2.23
注目したいのはオープンウェイトのGemma 4 31Bです。スコアは37%とGemini 3.1 Pro Previewより高く、しかも1タスクあたりのコストは$0.14と16倍も安いのです。
「商用のフロンティアモデルなら必ず勝てる」という思い込みが崩れる結果ですよね。
ターン数とスコアの逆相関|「深掘りの沼」
もうひとつ興味深いのが、ターン数が多いモデルほどスコアが下がる傾向です。
最高スコアのClaude Opus 4.7は平均26ターンで終わるのに対し、最下位のGemini 3.1 Pro Previewは83ターンも費やしています。
これは「考えすぎる」ことが裏目に出る現象。調べれば調べるほど、上流システムや偶発的な症状まで「これも原因かも」と誤検出してしまうのです。
ある中小企業のITサポート担当者を想像してみてください。プリンタが動かないという相談を受けて、ネットワーク・OS・電源・ケーブル・ドライバ・ルータと延々と調べ続けた結果、「全部疑わしい」という報告書を出してしまう状態に近いと言えるでしょう。
ITBench-AAの採点基準は厳しく、1つでも誤った根本原因を含めるとスコアが大きく下がる仕組み。慎重なエージェントほど点数を落としやすいというパラドックスがあるのです。
なぜエンタープライズITはAIに難しいのか
多重システム連携の複雑性
Kubernetesクラスタの中だけでも、Pod・Service・Namespace・Network Policyといった要素が多次元的に依存し合っています。
さらにアラート、ログ、メトリクス、トレースといった観測データはタイムスタンプがズレており、人間の運用エンジニアでも因果関係をたどるのに時間がかかる領域です。
AIエージェントは大量の情報を一気に処理できる反面、「どこから手をつけるべきか」という判断は人間に比べて弱いのが現状です。
「Full Recall」という厳しい採点基準
ITBench-AAの採点方式はAverage Precision at Full Recallと呼ばれます。
正解となる根本原因をすべて漏れなく特定しないと、スコアは0.0扱いという厳格さです。
つまり、1つでも見逃すと完全失敗。さらに余計な誤検出を加えても減点される、というダブルパンチの設計になっています。
これは医療や金融と同じ「ミスが許されない世界観」を反映した評価基準。エンタープライズの現場で求められる水準を正面から再現しているのです。
責任の所在問題
仮にAIエージェントが「データベースが原因です」と誤診断し、復旧作業を進めた結果、実際の原因が別にあって障害が拡大したらどうなるでしょうか。
誰が責任を取るのか。AI提供企業?導入企業?運用担当者?
日本企業がAIエージェント導入に二の足を踏む大きな理由が、まさにこの責任設計の曖昧さです。ITBench-AAの低スコアは、「全自動化はまだ早い」という現実を裏付ける材料にもなっています。
競合ベンチマークとの違い|SWE-bench・GAIAとの比較
類似のAIエージェント評価ベンチマークと比べると、ITBench-AAの独自性がより鮮明になります。
- SWE-bench: GitHub Issueの解決能力を測る。Claude Opus 4.7が87.6%と既に飽和状態
- GAIA: 一般的な推論とツール利用を評価。単発タスク中心で系統依存が浅い
- τ-bench: エージェントの再現性を測るが、単一実行のみ
- AgentBench: 8つの環境(OS・DB・Webなど)で汎用性を評価するが、本番運用シナリオではない
- OSWorld: 実OS操作を評価するが、エンタープライズ特化ではない
ITBench-AAはSRE・CISO・FinOpsという3本柱のエンタープライズシナリオに特化している点で、これらとは設計思想が異なります。
現時点で公開されているのはSRE分野のみですが、今後CISO(セキュリティコンプライアンス)とFinOps(IT財務運用)への拡張が予告されています。
つまり、これからのAIエージェントは「コードを書ける」だけでなく、「本番運用を任せられるか」で評価される時代に入りつつあるわけですね。
日本市場への影響|SIer・DX案件に突きつけられる現実
日本のSIer業界やDX推進部門にとっても、ITBench-AAの結果は無視できません。
NTTデータや富士通、日本総研といった大手SIerは、AIエージェントを活用したサービス開発に着手しています。しかし「Claudeでも47%、Geminiは30%」という現実を顧客に説明する必要が出てきました。
これまでのように「AIで完全自動化を実現します」と提案するのは難しくなります。代わりに次のような設計が標準になるでしょう。
- 多重冗長化: 複数モデルで判定し、合意が取れた診断のみ採用
- 人間監視: AIの一次切り分けを人間が必ずレビューする
- 段階的自動化: 影響範囲の小さい復旧作業のみAI実行を許可
- 明確な責任設計: SLAやリスク分担を契約段階で明文化
金融庁監督下の銀行や、FISC基準(金融機関の安全対策基準)に従う業界では、「失敗してもAIのせい」では済まされません。
むしろITBench-AAのようなベンチマークは、顧客との期待値合わせの強力な武器になります。「最先端でも50%未満」という客観的データを示せば、過剰な期待を抑えつつ、現実的な自動化計画に合意してもらえるからです。
日本でも、IPA(情報処理推進機構)やFISCが業界別ベンチマークを整備する可能性が出てきたと言えるでしょう。
よくある質問(FAQ)
Q1. ITBench-AAは誰でも使えますか?
はい、ベンチマークの結果はArtificial Analysisの公式リーダーボードで公開されており、自社モデルの評価も可能です。参照実装の「Stirrup」はオープンソースとして提供されています。
Q2. なぜターン数が多いと不利になるのですか?
採点方式が「Full Recall」のため、誤検出(False Positive)が含まれるとスコアが下がります。長く探索するほど無関係な要因まで原因候補に挙げてしまい、結果的に減点されやすくなるのです。
Q3. SWE-benchで高スコアなのに、なぜITBench-AAでは低いのですか?
SWE-benchはGitHub Issueに対するコード修正という比較的閉じたタスクです。一方、ITBench-AAは複数のシステム・観測データ・時間軸を横断する開放系タスク。求められる能力の種類が大きく異なります。
Q4. 中小企業がAIエージェントを導入するのは時期尚早ですか?
用途次第です。問い合わせ対応や文書作成など影響範囲の小さい領域では十分実用的。一方、本番システムの運用自動化はまだPoC段階と考え、人間の監視を前提に設計するのが安全です。
Q5. CISOやFinOpsのベンチマークはいつ公開されますか?
具体的な公開時期は発表されていませんが、IBMとArtificial Analysisが順次拡張すると表明しています。CIS BenchmarkやFinOps Foundationの定義に基づくシナリオが用意される予定です。
まとめ|AIエージェント期待値の再設定が必要
今回のITBench-AAが示した重要なポイントを振り返ります。
- Claude Opus 4.7の46.7%が最高スコアで、全フロンティアモデルが50%未満
- オープンウェイトのGemma 4 31Bが37%で、Gemini 3.1 Pro Preview(30%)を上回るコスト効率を示した
- ターン数を増やすほどスコアが下がる「深掘りの沼」現象が確認された
- 「Full Recall」という厳格な採点基準で、エンタープライズの実運用水準を再現
- SIerやDX案件では、AI単独完全自動化ではなく「人間と協働する設計」が必須
AIエージェントは確実に進化していますが、本番運用に耐える水準にはまだ届いていません。次のアクションとして、自社の業務で「AIに任せる範囲」と「人間が必ず確認する範囲」を明確に線引きしてみることから始めましょう。

