VAKRAの内部：推論、ツール使用、エージェントの失敗モード
VAKRA データセット | リーダーボード | リリースブログ | GitHub | リーダーボードに投稿する
私たちは最近、AIエージェントが企業のような環境でどれだけうまく推論し、行動できるかを評価するための、ツールに裏付けられ実行可能なベンチマークであるVAKRAを導入しました。
単一のスキルをテストする従来のベンチマークとは異なり、VAKRAはAPIとドキュメントにまたがる合成的（compositional）な推論を測定し、エージェントが複数ステップのワークフローを確実に完了できるかどうかを判断するために、完全な実行トレースを用います。
VAKRAは、エージェントが8,000+のローカルホストされたAPIと対話するための実行可能な環境を提供します。これらのAPIは、62のドメインにまたがる実データベースに裏付けられており、さらにドメインに整合したドキュメントコレクションも同梱されています。タスクは、構造化されたAPI操作と、自然言語によるツール利用の制約下での非構造化のリトリーブを組み合わせることで、3〜7ステップの推論チェーンを必要とする場合があります。
以下で確認できる通り、モデルはVAKRAに対して十分に性能を発揮できていません。このブログでは、VAKRAのタスクに関する追加のデータセット詳細を掲載し、さまざまなタスクで観測された失敗パターンの分析を提示します。
タスクの説明
以下に示す通り、VAKRAのベンチマークは4つのタスクで構成されており、それぞれが異なる一連の能力をテストします。
図1：VAKRAベンチマークにおける各能力の代表的な例
能力1：ビジネス・インテリジェンスAPIを用いたAPIチェイニング
この能力には、54のドメインにまたがる2,077件のテストインスタンスが含まれており、SLOT-BIRDおよびSEL-BIRDコレクションのツールを用いることが求められます（Elder et al., 2026）。Elder et al.でのセットアップと比べて、SLOT-BIRDおよびSEL-BIRDのツールユニバースは、より多くのドメインを含めることで拡張されています。各ドメインは1つのツールコレクションに制限されており、タスクでは最終的な回答に到達するために1〜12回のツール呼び出しをチェイニングします。
{
"query": "どのサッカーチームはビルドアップのプレー速度が31、ビルドアップのドリブルが53、そしてビルドアップのパスが32ですか？",
"tool_calls":[
{
"name": "get_data",
"arguments":{"tool_universe_id="486ea46224d1-aeb8037c5e78"},
"label": "retrieved_data_1"
},
{
"name": "select_data_equal_to",
"arguments":{"data_label":"retrieved_data_1","key_name":"play_speed","value":31},
"label": "FILTERED_DF_0"
},
{
"name": "select_data_equal_to",
"arguments":{"data_label":"FILTERED_DF_0","key_name":"play_dribble","value":53},
"label": "FILTERED_DF_1"
},
{
"name": "select_data_equal_to",
"arguments":{"data_label":"FILTERED_DF_1","key_name":"play_passing","value":32},
"label": "FILTERED_DF_2"
},
{"name":{get_team_name},"arguments":{"data_label":"FILTERED_DF_2","n":1}}}],
"answer": "FC Barcelona"
}
図2：SEL-BIRDコレクションからのデータサンプル
上に示した通り、各インスタンスには関連付けられたJSONデータソースがあり、そこから答えを導出する必要があります。このタスクをサポートするMCPサーバには、各インスタンスの最初に呼び出さなければならない特別なツールget_data(tool_universe_id=id)が含まれています。このツールはデータソースを初期化し、データの軽量なプレビューを返します（以下の図3を参照）、そして大きなデータ転送を避けるために、完全なデータセットをサーバ側に保存します。これにより、MCPプロトコルを介した大規模データの非効率な転送を防ぎます。さらに、この呼び出しはtool_universe_idに基づいて適切なツールセットをMCPサーバに公開させるよう設定し、インスタンスに対するデータソースをドメイン固有のデータベースに整合させます。
SLOT-BIRDコレクションは、Tableauや
Google Analyticsのようなシステムに着想を得た、汎用的なデータ操作のための7つのグローバルなツールを提供します（例：フィルタリング、ソート）。SEL-BIRDコレクションは、より専門化されたツールを導入することでこれを拡張します。これらの一部はSLOT-BIRDと共有されており、その他はカテゴリ引数をフラット化して別々の関数に分解したことによって導出されています（例：引数ascending: bool = Falseのsort_dataは、sort_data_ascendingおよびsort_data_descendingになります）。さらに、SLOT-BIRDの汎用関数（retrieve_data）は、クエリに特化したゲッターに置き換えられます。各インスタンスにおけるデータのすべてのキーには対応する取得関数（get_KEY_NAME）があり、1つのインスタンスにつき平均4つのget関数になります。
{
"handle": "retrieved_data_1",
"num_records": 2,
"key_details": [
{"name": "team_name", "dtype": "str", "first_3_values": ["FC Barcelona", "Manchester City"]},
{"name": "play_speed", "dtype": "int32", "first_3_values": [31, 40]},
{"name": "play_dribble", "dtype": "int32", "first_3_values": [53, 30]},
{"name": "play_passing", "dtype": "int32", "first_3_values": [32, 16]}
]}
}図3：get_data 関数によって取得されたデータプレビュー
能力2：ダッシュボードAPIを用いたツール選択
この機能は17のドメインにまたがって合計1,597件のインスタンスを含み、拡張されたREST-BIRDコレクションからツールを必要とします（Elder et al.）。
これらは、計算のほとんどをカプセル化した、高度に具体的でクエリに整合したエンドポイント型のインターフェースを使用します。FastAPIサーバー上で動作するREST APIとして提供され、その上でMCPサーバーによってラップされています。このタスクでは、ドメイン固有のツールセット（図1の例に示すとおり）から適切なAPIを選択する必要があります。各ドメインには最低6個から最大328個のツールが含まれ（平均116個）、前のタスクと同様に、リポジトリ内のget_dataツール設定によって、MCPサーバーに公開されるのは関連するドメイン固有APIのみになります。
OpenAI API仕様では、ツールリストの入力長が最大128ツールに制限されています。この制約により、このAPIを用いるエージェントビルダーは、ショートリスティング（候補絞り込み）といった仕組みによってツールリストの長さを直接管理する必要があります。リポジトリのベースラインエージェントでは、この課題に対して単純なショートリスティング機能が扱っています。
能力3：ダッシュボードAPIを用いたマルチホップ推論
ベンチマークの能力3セグメントには、38の対象ドメインから抽出された869件のテストインスタンスがあります。これらのインスタンスは、再びREST-BIRD APIコレクションに依存しますが、課題にマルチホップ推論を追加しています（図1の例を参照）。マルチホップの質問では、答えに到達するために、複数の支持となる証拠を抽出し、結合する必要があります。このセクションのインスタンスは、クエリに回答するのに必要な論理的ホップが1〜5ホップの範囲です。テストデータセット内のクエリにおける質問タイプの分布は、以下の図4に示します。
図4：能力3（MultiHop）におけるAPIホップタイプの分布、および能力4（MultiHop MultiSource Reasoning）におけるハイブリッドホップタイプの分布
能力4：マルチホップ・マルチソース推論とポリシー遵守
能力4には41のドメインにまたがる644件のインスタンスが含まれており、これもREST-BIRD APIコレクションに基づいて構築されています。上の図4は、ポリシーなしのテストクエリにおけるハイブリッドホップの分布を示しています。以下の特徴を持つ、最も複雑なクエリを含みます。
マルチソース：このセグメントでは、ドメインごとにドキュメントインデックスが追加されます。この能力におけるクエリは、API呼び出しに加えて、これらのドキュメントインデックスからの情報を必要とする場合があります。能力3と同様に、このタスクにもマルチホップのクエリがあります。必要な情報源はホップ単位で適用されるため、たとえば、ある質問は次のような情報源を持つ3つの論理ホップ（ソース：API - RAG（ドキュメント取得） - API）を含む可能性があります。正しい推論を強制するため、データ生成時に情報源が汚染除去されます。つまり、特定のホップに必要な情報は、1つのソースにだけ存在するようにします。たとえば、あるホップをAPIを用いて回答する必要がある場合、質問に答えるために必要になりそうな情報を含むドキュメントを削除することで、ドキュメントインデックスを構築します。
マルチターン：このデータセットのセグメントでは、状況設定にマルチターンの会話も追加されます。各インスタンスは複数ターンを含むダイアログです。データはコンテキスト-レスポンスのペアとして公開され、コンテキストは現在のダイアログ履歴をエンコードし、エージェントは現在のターンに対する応答のみを担当します。
ツール利用ポリシー: これらのインスタンスの一部には、エージェントが従うことが求められるツール利用ポリシーが含まれます。これらのポリシーは、エージェントがアクセスを許可される知識ソースと、その知識ソースにアクセスしてよい状況を定めた、プレーンテキスト形式の指示として提示されます。たとえば：
ユーザーの問い合わせが「テクノロジー＆ソフトウェア」に関するものであり、それがコードベース、ソフトウェア基盤、アプリケーション、そしてテクノロジーにおけるユーザーの相互作用を扱うトピックに該当する場合は、ドキュメント・リトリーバーのみを用いて回答するようにしてください。他の種類のツールは使用しないでください。
プロジェクトリポジトリ内のベースライン・エージェントは、このポリシーへの遵守を、プロンプトへの簡単な追加によって強制します： "You are a helpful assistant with access to tools.
Tool Usage Constraint: {additional_instructions}."。もちろん、エージェントビルダーは任意の制約の強制メカニズムを選ぶことができます。
評価フレームワーク
VAKRAは、成功が一貫したマルチステップのワークフローを実行する能力と、回答の正しさの双方に依存するような、ツール環境においてエージェントを評価します。私たちは最終出力だけでなく、ツール呼び出し、入力、中間結果を含むツール実行の全軌跡も評価する実行中心の評価フレームワークを導入します。
評価指標
VAKRA Evaluatorは、サンプルごとに2つの主要な入力に基づいて動作します： 予測される最終応答と、それに対応するツール呼び出し軌跡です。予測軌跡から得られるツール呼び出しは、中間のツール出力を検証するために、真の事実（ground truth）と同じ環境で実行されます。
評価はウォーターフォール型のパイプライン（図6）に従い、後続の段階は前の段階の成功に条件付けられます：
- 能力4のタスクでは、まずポリシー遵守がプログラム的に検証されます（このステップは他の能力には適用されません）。
- 次に、予測されたツール呼び出しのシーケンスを、真の事実のシーケンスと比較します。
- 有効な軌跡を持つサンプルのみが、最終的な応答評価へ進みます。
図6: ウォーターフォール型 評価パイプライン
ツールシーケンスの比較 実行可能な環境が存在するため、エージェントは環境を探索でき、私たちが特定したものとは異なるAPIの組み合わせを呼び出すことで、答えを返すことがある。代替ではあるが有効なツール呼び出しや推論経路をサポートするため、厳密なステップ単位の一致を強制するのではなく、各予測ツールを実行し、そのツール応答の集合を真の事実のものと比較することで正しさを評価します。
具体的には、まずプログラムによるチェックを行い、真の事実のツール応答に含まれるすべての情報が、予測されるツール応答によって回収されているかどうかを検証します。このチェックは、部分一致、意味的同等性、あるいは表現の違い（例：順序、集約、フォーマットの違い）を含むケースでは結論が出ない可能性があります。そのような場合には、構造の違いがあっても、予測された軌跡が必要な情報をすべて取得しているかどうかを判断するために、CRAGフレームワーク Yang et al., 2024 から適応した二次のLLMベース評価を適用します。このステップでは、予測された軌跡が、たとえ別のツール呼び出しのシーケンスで得られたとしても、必要な情報をすべて捉えているかどうかを判断するために、適応したpromptを使用します。
最終応答の評価 前のチェックに合格した軌跡に対して、最終応答はLLMベースのジャッジによって評価されます。このステップにより、応答が (i) 予測されたツール出力に根拠づけられていること、そして (ii) 文章表現や構造の潜在的な違いを考慮しつつ、真の事実の回答と事実整合していることが保証されます。
この設計により、エージェントが正しい回答を作るだけでなく、正しくかつ完全な推論プロセスによってそれを得た場合に報酬が与えられることを確実にします。
採点
最終的なリーダーボードのスコアを得るために、すべての能力は同等の重み付けを行います
能力スコアを取得するために、能力1〜3の各能力内のすべてのサンプルには同じ重みが与えられます。
能力4では、不均質なクエリにより高い重みを与えます。
エラー分析
ここでは、4つのVAKRA機能にわたる詳細なエラー分析を提示します。分析を容易にするため、各失敗を最初の崩れのポイントに割り当てる段階別のエラー分類を採用します。具体的には、次の順で評価します：(i) 正しいツール（群）が選択されたか、(ii) 必要な引数が欠落や幻覚なしに提供されたか、(iii) 引数の値が正しいか、そして (iv) 最終応答が正確であり、かつツール出力に基づいているか。
失敗段階の分離
1つのサンプルには、異なるステップにまたがって複数のエラーが現れる可能性があるため、各インスタンスを最も早い失敗段階（例：ツール選択エラーは引数エラーに優先）に順次分類します。これにより、二重カウントを防ぎ、エラーカテゴリをデータセットの互いに素な割合（分数）として解釈できるようにします。よりきめ細かな指標（例：ツール使用に関する precision/recall）も可能ですが（Elder et al., 2026）、この定式化はエージェントの失敗をシンプルで解釈しやすく分解できることが分かりました。
このパートのベンチマークでは、単一のタスクを解くために複数のツールを選択し、順序付ける必要がありました。この機能には2077件のサンプルがあります。これはすべてのモデルにとって難しいものでしたが、GPT-OSS-120Bはベンチマークのこの区間で最も良い結果を示しました。
- GPT-OSS-120Bは、大きく他のモデルを上回りました。主に、ツールスキーマの理解が優れていたことによるものです。
- このベンチマークのツールはパラメータ数が多く、その多くが任意です。比較すると、GPT-OSS-120Bは他のモデルに比べて、埋めるべき適切なパラメータの選択において特に堅牢でした。
- 全体として、すべてのツール呼び出しを正しく行った後に正しい回答を合成することは、このベンチマーク区間では比較的難しくありませんでした。おそらく、ツール呼び出しのシーケンスによって、Dashboard API機能と比べてツール選択問題が推測しにくくなったためでしょう。
図7：SEL-BIRD vs SLOT-BIRD エラータイプの分析
ビジネスインテリジェンス（BI）API機能には2つのAPIセットがあり、SLOT-BIRDおよびSEL-BIRDのツールコレクションから構成されています。このベンチマークのSEL部分は600サンプルであり、一方でSLOT部分は1477サンプルでした。これら2つのコレクションはいずれもBI API機能の下でまとめられていますが、特性はわずかに異なります。SLOT-BIRDコレクションは、埋めるべきパラメータ値が多数ある少数の汎用ツールを持ちますが、SEL-BIRDコレクションは、各ツールあたりのパラメータ数が少ない、より大きな数のツールを持ちます。これらのツールコレクションを用いるモデルが犯す相対的なエラーにも、この違いが反映されています。
返却形式: {"translated": "翻訳されたHTML"}- SLOT-BIRDを使用すると、GPT-OSS-120bを除くすべてのモデルで、ツール引数に対して正しい名称を生成する際に相当数の誤りが発生しました。これは主に、このベンチマークの当該セグメントにおいてGPT-OSS-120bが全体として非常に良い結果を出した理由です。
- パラメータを埋める回数が少ないため、同じモデルでもSEL-BIRDツールコレクションを使用した場合は、そうした誤りはごくわずかでした。しかし、正しいツールを選択する誤りはさらに多くなっており、より大規模（かつ動的な）ツールセットから選ぶ難しさが増したことを反映しています。
- 上に示したとおり、ツール選択能力における1597サンプルでは、Gemini-3-flash-previewが、エラーカテゴリすべてにおいて、テストした他のモデルを上回っています。
- 予想どおりです。ダッシュボードAPIのインスタンスでは、モデルに多数のツールオプションから選ばせる必要がありますが、各ツールに必要なパラメータ数はわずかです。そのため、ツール選択と、パラメータ値選択の双方において多数の誤りが発生します。
- 必須パラメータを幻覚で生成したり、スキップしたりすることには大きな問題はないようです。しかし、すべてのツール呼び出しが正しく行われたとしても、モデル（特にGemini-3-flash-previewとClaude-Sonnet-4-5）は、ツール応答から正しい答えを統合して作り出すことに依然として苦戦しています。プロットの右端側で大きく落ち込んでいることが、その証拠です。
マルチホップ推論：ホップ深さがモデル性能に与える影響
図8：ホップ深さごとのモデル精度の比較
マルチホップ推論は、モデルに対して暗黙的に結び付いた複数の問いそれぞれに成功して答えることを要求するため、元のタスクの難しさを増します。各問いでは、正しいAPIを選択して呼び出す必要があります。予想どおり、すべてのモデルは、論理ホップが1つだけの問いで最も良い性能を示し、2ホップ、さらに3ホップ以上の問いでは性能が低下しました。
マルチホップ・マルチソース推論：ハイブリッドホップがモデル性能に与える影響
図9：相互作用タイプ別のモデル精度（API、ドキュメントリトリーバ、ハイブリッド）
データセットの最終セグメントには、他のセグメントのツール/APIソースに加えて、ドキュメントソースが含まれます。これにより、単一または複数のAPI呼び出し、単一または複数のドキュメント検索、あるいはAPI呼び出しとドキュメント検索の組み合わせが必要となるケースが生じます。
- これまでと同様に、単一のAPI呼び出し（1ホップAPI）が必要なケースは、複数回のAPI呼び出し（2ホップAPI）が必要なケースと比べて、性能に明確な差があります。また、ドキュメントリトリーバを含めることでタスクはより難しくなります（RAGホップとハイブリッド）。
- 興味深いことに、単一のドキュメントリトリーバ呼び出しが必要な質問（1ホップRAG）では、GPT-OSS-120Bはパラメータ知識から直接答えを返そうとします。しかし、質問が複数ホップを要求しているように見える場合には、その質問に答えます。我々は、1ホップRAGの質問はWikipediaのエンティティに強く焦点を当てているため、モデルがツール呼び出しを省略してしまうのではないかと仮説を立てています（この問題は1ホップAPIでは見られません。そこでは、質問中にバックエンドのデータベース固有のエンティティ／事実がより頻繁に含まれている可能性があります）。
- また、Gemini-3-flash-previewの性能が、他のハイブリッドホップパターンと比べて2ホップAPI-RAGで大きく伸びることも興味深い点です。これはおそらく、ダッシュボードAPI（ツール選択能力）におけるGemini-3-flash-previewの比較的強い性能によって説明でき、したがってツール呼び出しによって正しい中間回答が特定できれば、検索クエリがより成功しやすくなるためだと考えられます。
ポリシーがモデル性能に与える影響
図10：ポリシータイプ別のモデル精度
ポリシーは、多段（multi-hop）かつ多ソース（multi-source）の推論の上に、追加の難しさという層をもたらします。ポリシーが、回答に必要なソースと一致している場合、つまりそれがモデルが質問に答えるために必要なツール一覧に影響しない場合、私たちはそれを「回答に更新なし（No Updates to Answer）」と呼びます。図10に示すとおり、Granite-4.0-h-Small-32Bを除くすべてのモデルは、最も関連性の高い情報ソースへのアクセスを制限するポリシー制約の下で、性能が明確に低下します（つまり「ポリシーが答えを更新する（Policy updates the answer）」）。
一般に、モデルは（多くの場合）制約に違反するか、十分な情報を取得できないことがわかりました。時にはポリシーを理解しているものの、質問に正しく答えられなかったり、あるいは以前に分析した失敗モードのいずれかを示したりします。
全体として、ツール利用のポリシー制約がある設定では、モデルがツールやソースに対して推論することはできる一方で、その推論に外部の制約を取り込むことに苦労することが示唆されます。これは、信頼性の高い実運用においてしばしば重要な要件です。
結論
VAKRAは、表面的なツール能力と、堅牢でエンドツーエンドのエージェント信頼性との間にある重大なギャップを明らかにします。最新のモデルはますますAPIを選択し、単独のツール呼び出しを実行できるようになっていますが、VAKRAは、それらの能力だけでは実運用のために十分ではないことを示しています。実際のところ、モデルは、実行制約のもとでの合成（compositional）推論を必要とする場面でしばしば破綻します。対象は、API、ドキュメント、対話コンテキスト、そしてポリシー要件にまたがります。
VAKRAを試してみてください — あなたのエージェントはどこで壊れますか？
あなたのエージェントは盤石だと思いますか？テストしてみましょう。
VAKRA で動かしてみて、どこで崩れるのかを確認してください。つまり、ツール選択、多段推論（multi-hop reasoning）、あるいはポリシー制約のどこで破綻するのかです。
- ⭐ リーダーボードに提出： https://github.com/IBM/vakra?tab=readme-ov-file#submitting-to-the-live-leaderboard
- データセットを探索： https://huggingface.co/datasets/ibm-research/VAKRA
- ️ コードを確認： https://github.com/IBM/vakra
ぜひ試して、あなたのエージェントが何を学んだのか教えてください
