結論から書きます。AIエージェントが業務で失敗する条件は、モデルの賢さより設計で決まります。IBM Researchの評価基盤VAKRAは、候補ツールが多いほど、手順が長いほど、そして社内ルールを守らせるほど精度が落ちる傾向を示しました。打ち手は「小さく切る・道具を絞る・ルールは外側で縛る」です。

VAKRAとは何を測っている基盤なのか（一次資料の実測）

VAKRAは、企業業務を模した実行可能な環境の上でAIエージェントを走らせ、その推論・ツール利用・失敗の仕方を分解して観察するための評価基盤です。公開された分析記事によれば、環境には8,000以上のローカルホストされたAPIが用意され、62のドメインにまたがる企業類似の業務と文書コレクションが構築されています。ここで重要なのは、この8,000超のAPIも62ドメインも、実企業の実データ・実システムではなく、評価のために作られた模擬環境だという点です。

課題そのものの設計値も公開されています。一次資料の表現では、課題は3〜7ステップの推論チェーンを要しうる（can require）とされており、単発の質問応答ではなく、複数の段階を組み合わせて答えに到達する構成的推論（compositional reasoning）を試すことが狙いです。なお「全問が必ず3〜7ステップ」と書かれているわけではなく、そこまで踏ませうる設計だという記述にとどまります。

（出典：IBM Research（著者: Ankita Naik, Anupama Murthi, Praveen Venkateswaran ほか。記事は Hugging Face の ibm-research アカウントより公開）、2026-04-15、https://huggingface.co/blog/ibm-research/vakra-benchmark-analysis）

そして、読む前に必ず押さえるべき前提があります。この記事はIBM Research自身による発表であり、同社は当該ベンチマークVAKRAそのものの開発者・提供者です。つまり、自社が作った評価基準で、自社モデルを含む複数モデルを評価した自己申告型の分析にあたります。数字を捨てろという話ではなく、出どころを踏まえて割り引いて読む必要がある、という意味です。

4つの能力カテゴリと、その件数の偏り

VAKRAの分析は、エージェントに求められる能力を分けて計測しています。比較対象となったモデルは GPT-OSS-120B、Gemini-3-flash-preview、Claude-Sonnet-4-5、そしてIBM自社の Granite-4.0-h-Small-32B の4つです。ただし全カテゴリで同一の4モデルが揃って比較されているとは明記されておらず、節によって取り上げられるモデルは異なります。

能力カテゴリ 内容 テスト件数 ドメイン数
能力1 APIチェーン（BI系API）の連結実行 2,077件 54ドメイン
能力2 大量候補からのツール選択（ダッシュボードAPI） 1,597件 17ドメイン
能力3 マルチホップ推論（ダッシュボードAPI。論理ホップ数1〜5） 869件 38ドメイン
能力4 マルチホップ・複数ソース推論＋ポリシー遵守 644件 41ドメイン

この表を見てすぐ分かる不都合が一つあります。件数もドメイン数も、カテゴリごとに大きく偏っています。能力1は2,077件・54ドメインある一方、能力2は1,597件でありながらドメインは17しかありません。したがって「能力2のほうが難しい／簡単」といった能力間の単純比較には向きません。同じ物差しで並んでいるように見えて、母集団の広さが違うからです。評価の読み方についてはAIの答えの良し悪しは何で測るのかでも整理していますが、件数と条件を確認せずに順位だけ拾うのが一番危ない読み方です。

失敗が増える3つの条件

分析から読み取れる実務上の含意は、次の3点に集約できます。

  • ツール候補が多いと選択ミスが増える。能力2はまさに「大量のツール候補から正しいものを選ばせる」設定であり、選択そのものが独立した難所として切り出されています。
  • 手順（ホップ）が長いほど精度が落ちる。能力3は1〜5の論理ホップを要する課題で構成され、一次資料は「全モデルが1ホップの問題で最も良い結果を示し、2ホップ、さらに3ホップ以上で性能が低下した」と述べています。
  • ポリシー（社内ルール）を守らせると精度が下がる傾向がある。能力4はAPIと文書検索を併用しつつ、アクセス可能な知識ソースを平文で指示するツール利用ポリシーの下での挙動を比較する設計です。

ここで著者自身が挙げている限界も併記しておきます。1つのサンプルが複数ステップにまたがる複数のエラーを含みうるため、二重計上を避ける目的で、各事例は「最初に失敗した段階」へ順次分類されています。つまり失敗モードの内訳は、この分類手順に依存します。「どの失敗が何割か」という数字は、分類ルールを変えれば動きうる性質のものだと理解しておくべきです。

さらに、自社モデルの扱いにも注意が要ります。関連情報源へのアクセスを制限するポリシー制約下で性能低下を示さなかった唯一のモデルとして、IBM自社の Granite-4.0-h-Small-32B が挙げられています。発信元が開発者であり評価者でもある以上、この結論は特に割り引いて読む対象です。

なお本記事の取得時点では、各モデルの具体的な正答率（%）までは抽出できていません。数値の細部が必要な場合は、原文の図表で直接確認してください。データセット・コード・公開リーダーボードは外部検証手段として提供されていますが、記事公開時点で第三者による独立再現の結果は示されていません。

中小企業にとって、で、うちに関係あるのか

関係します。ただし「どのモデルを買うか」ではなく「どう設計するか」の話としてです。VAKRAが示しているのは、AIエージェントを基幹業務に繋ぐときの設計上の上限だからです。

第一に、使わせるツール／APIの候補を絞ることです。社内の全システムを一気に繋いで「あとはAIが適切に選ぶ」という設計は、選択ミスを増やす方向に働きます。用途ごとに接続先を限定したエージェントを複数用意するほうが、実務では安全です。ツール接続の考え方はAIエージェントのツール接続はどう変わってきたかで扱っています。

第二に、1つの依頼で踏ませる手順を短くすることです。一次資料が構成的推論の難所として置いた水準が、3〜7ステップという幅でした。長い業務は工程で分割し、節目で人が確認して次に渡す。全自動より、人の確認を挟んだ半自動のほうが実装も検証も容易です。

第三に、ルールはプロンプトに書くのではなく、システム側のガードで担保することです。「この条件では実行不可」といった制約は、モデルの遵守能力に賭けるのではなく、実行前のチェックや権限設計で機械的に止めるべきものです。ポリシー遵守が精度を下げる傾向があるという観察は、裏を返せば「モデルにルールを背負わせるほど本来の仕事が雑になる」ことを示しています。

  • 接続するAPIは業務単位で最小限に絞る
  • 依頼は1回あたりの手順を短くし、節目で人が確認する
  • 禁止条件はコード・権限側で止め、プロンプト任せにしない

TOEの読み筋

TOEでは、VAKRAを用いた検証は未実施です。ベンチマークの再現も、自社データでの追試も行っていません。そのうえで、この分析をどう受け止めているかを書きます。

読み筋は「賢いモデルを探す前に、タスクを小さくする」です。エージェント導入の相談を受けると、最初の設計はたいてい欲張りになります。既存の業務フローをそのまま1本のエージェントに任せ、必要そうなシステムを片っ端から繋ぐ。VAKRAの構造が示唆するのは、その設計がまさに失敗が増える三条件を全部踏んでいる、ということです。

もう一つの読み筋は、模擬環境の数字を自社の期待値に読み替えないことです。8,000超のAPIはすべてローカルにホストされた模擬環境であり、実企業の実データ・実システムでの精度を保証しません。自社で判断したいなら、自社の業務を5件から10件ほど切り出し、自分たちの基準で測るのが確実です。その考え方は自社の評価基準をどう作るかにまとめています。

まとめ

  • VAKRAは8,000以上のローカルホストAPIと62ドメインの模擬企業環境で、3〜7ステップの推論を要しうる課題をエージェントに解かせる評価基盤である
  • 4つの能力カテゴリは 2,077件／54ドメイン、1,597件／17ドメイン、869件／38ドメイン、644件／41ドメインと規模が大きく偏っており、能力間の単純比較には向かない
  • この記事はIBM Research自身による発表であり、同社はVAKRAの開発者かつ評価対象モデルの提供者でもある。自社の Granite だけがポリシー制約下で性能低下を示さなかったという結論は、特に割り引いて読む
  • 失敗モードの内訳は二重計上を避けるための順次分類に依存し、模擬環境の結果は実システムでの精度を保証しない
  • 中小企業が取るべき打ち手は、接続ツールを絞る・手順を短く切る・ルールはシステム側のガードで縛る、の3点である