9月22日、NVIDIAが「How to Evaluate AI Agents From Tool Calls to Task Completion」と題した記事を公開した。LLMの活用がチャットボットや単発の推論タスクにとどまらず、複数のツールを連携させて長期的な目標を達成する「エージェント」へとパラダイムシフトしている今、評価手法もそのアーキテクチャの複雑さに追いついていない。本記事はその課題に正面から向き合い、ツールコールから最終的なタスク完了までを体系的に評価するフレームワークを詳解している。
「それっぽい出力」では評価できない
LLMの従来の評価手法は、静的なタスクに対して単一の出力を採点する設計だった。しかしAIエージェントは複数のツールを順番に呼び出し、エラーを処理し、環境の状態を読み取りながら動作する。1つの出力文字列を採点するだけでは全く足りない。
Berkeley Function-Calling Leaderboard（BFCL）はツール選択と引数の精度を評価する指標として登場したが、それでも「個々の呼び出し」しか評価しない。issue_refundの呼び出し形式が正しくても、前後のチェックやDB更新が抜けていれば、タスクは失敗する。呼び出し精度は必要条件であって十分条件ではない。
評価の2層構造：ステップとE2E
本格的なエージェント評価には、ツールを実際に実行し、ステップをまたいで状態を追跡できるフル実行環境が必要だ。その上に2種類のスコアリングが乗る。
- ステップレベル（プロセス採点）：その時点の状態を踏まえて、その呼び出しは有効か、必要だったか
- エンドツーエンド（E2E・成果採点）：経路を無視して最終状態だけを確認する。払い戻しは処理されたか、チケットは正しくルーティングされたか
ステップレベルはチェーンのどこで壊れたかを教える。デバッグやファインチューニングの対象を絞る際に有効だ。一方E2Eは、ステップ1での失敗とステップ9での失敗を同じ「タスク失敗」として扱う。ユーザーが実際に体験するのはE2Eなので、リリースの合否判定はE2Eを使い、デバッグにはステップレベルのトレースを残すというのが現実的な運用になる。
両スコアの元データは共通で、トレース（1回の試行における操作ログの順序付き記録）だ。プロセス採点は各行を採点し、E2E採点は最終状態を採点する。
追うべきメトリクス6本
評価は「Benchmark → Trial → Task → Turn → Step」という階層で集計される。Stepは通常ツール呼び出し1回に相当し、上位の指標はすべてここから積み上がる。
| メトリクス | 軸 | 意味 |
|---|---|---|
| タスク成功率 | 精度 | リリース判定基準。環境がゴール状態に達したか |
| 一貫性 | 精度 | 3〜5回の試行での成功率の幅。90%→74%のモデルは84%固定より信頼できない |
| ツール呼び出し精度 | 精度 | ハルシネーションや余分な呼び出しが現れる |
| 引数精度 | 精度 | 「APIを間違えた」と「APIは正しいが引数が間違い」を分離できる |
| 成功あたりのステップ数 | 冗長性 | タスク完了までの軌跡の長さ |
| 成功あたりのコスト | コスト | トークン・GPU秒は成功1件あたりで測る |
一貫性のポイントは見落とされやすい。3〜5回の試行で成功率の範囲を報告すべきで、点推定（平均値1つ）は確率的システムに対して不誠実だ。
また、並列ツール呼び出しはステップ数とレイテンシを削減するが、呼び出し回数は変わらない。1ターンで4ツールを同時呼び出しても、呼び出し数は4のままだ。
実際のトレースを読む
記事ではSWE-bench Verified（実際のGitHubイシューを使った実行可能テスト検証）の実トレースが紹介されている。タスクは_pytest.capture.EncodedFileのバグ修正だ。
| ステップ | ツール呼び出し | 判定 | 理由 |
|---|---|---|---|
| 1 | terminal(find /testbed -name "capture.py") |
valid | 編集前にファイルを特定 |
| 2 | file_editor(view, capture.py) |
redundant | 400行超のファイルを丸ごと表示は非効率 |
| 3 | terminal(grep -n "EncodedFile" capture.py) |
recovered | ステップ2の非効率を修正し、関連箇所に絞り込み |
| 4 | file_editor(view, view_range=...) |
valid | 根本原因（__getattr__の委譲）を特定 |
このトレースの採点結果：
- E2Eスコア: 1（テスト通過）
- ステップレベルスコア: 3/4（ステップ2が冗長）
- ツール呼び出し精度: 3/4
- 引数精度: 4/4
ステップ2の「ファイル全体を表示」は論理的に誤りではないが、より効率的な手段があったため冗長と判定された。これがE2Eスコアには影響しない一方、ステップレベルとツール呼び出し精度には反映される。E2EとステップレベルをセットでモニタリングするKPIがここで意味を持つ。
学術ベンチマークとエンタープライズベンチマークの違い
学術ベンチマークはモデルの能力上限を抽象的に測る。エンタープライズベンチマークは「自分のジョブを、自分のAPIで、自分のポリシーのもとでこなせるか」という狭く実用的な問いに答える。
NVIDIAはNemotron 3.5 Lightningのベンチマークとして、複数の独自指標を採用している。Bankingスコアはマルチターンの銀行業務会話においてエージェントがタスクを完了できるかを測るドメイン特化型の評価指標で、実際の業務フローに即した完了率を計測する。GDPval-AA v2はLLMジャッジのEloスコアを1,000人の人間専門家のベースラインに固定することで、主観的なジャッジのドリフトを防ぐ設計になっている。PinchBenchは速度と精度を同時に評価するベンチマークで、Nemotron 3.5 Lightningはここで86%の精度を達成し、同等精度のQwen3.6 35Bより10,000タスクを30%速く完了している。
公開スコアは参考になるが、リリースの合否判定にそのまま使うべきではない。自分のタスクへの適応が不可欠だ。
自分のワークロードでベンチマークする手順
- 公開ベンチマークで基準を設定する。3〜5回の試行で成功率の範囲を記録する
- 実際のチケット・トレース・APIからドメイン評価を構築する。ジャッジの主観ではなく、DBの行・マージ済みPR・クローズ済みチケットなど環境の状態でゲートする
- モデルとハーネスをその分布に適応させる
- 成功率・一貫性・成功あたりのステップ数・成功あたりのコストを再測定し、ステップレベルトレースはデバッグ用に保持する
環境での検証を優先し、言語の評価にはジャッジを使い、ツール呼び出し精度と引数精度でチェーンの断点を特定する、という分業が推奨されている。
詳細はHow to Evaluate AI Agents From Tool Calls to Task Completionを参照していただきたい。
