目次
マルチエージェントを組み、ツールを与え、Agent SDKで動かした——では、そのエージェントが「ちゃんと仕事をしているか」をどう測るのだろう。単発の出力ならAI評価（Evals）で点をつけられる。だがエージェントは何手も考え、ツールを呼び、状態を持って動く。最後の一言が正しく見えても、途中で危ない橋を渡っていたかもしれない。ここで主役になるのがエージェント評価（Agent Evals）だ。
本記事では、エージェント評価とは何か・LLM評価との違い・何を測るか（5軸）・どう測るか（3人の採点者）・固有の難所・実務の回し方とベンチマークを、公式情報に基づいて整理する。先に要点。① エージェント評価は「最後の出力」だけでなく「行動の軌跡（trajectory）」まで測る。② Anthropicは「経路ではなく成果（最終状態）を採点せよ」と勧める——手順の丸暗記チェックは脆いから。③ まずは実際の失敗から20〜50件の小さな評価セットを作り、自動採点で回す。
「最後の答え」と「歩いた道」の両方を測る
— 出力評価では足りない。エージェントは多段・ツール・状態だから
Anthropicの推奨は「経路より成果を採点」——だが軌跡は「なぜ失敗したか」を教えてくれる。両方を使い分ける。
1. エージェント評価（Agent Evals）とは
エージェント評価とは、ツールを使い、複数手を踏んで目標を達成する「エージェント」が、本当にタスクを成し遂げられるかを体系的に測る工程だ。プロンプト1回の良し悪しを見るLLM評価の発展形で、対象が「1つの出力」から「一連の行動」に広がる。
なぜ重要か。Anthropicはエージェント評価の解説で 「評価は後回しにするほど作りにくくなる。初期なら製品要件がそのままテストケースに翻訳できる」と述べ、「20〜50個の、実際の失敗から取ったシンプルなタスクが立派な出発点になる」と勧める。つまり「なんとなく動いている」を、再現可能な数字に変えるのがエージェント評価だ。これはAIオブザーバビリティ（実行を観測する）と対になる——観測したトレースが、評価の材料になる。
2. なぜLLM評価と別物か（出力 vs 軌跡）
従来のLLM評価は、基本的に「入力→1つの出力」を採点する。だがエージェントは計画し、ツールを呼び、結果を見て次を決め、状態を更新する。だから最終出力だけ見ても足りない。Googleも「出力を確認するだけでは不十分で、エージェントの行動の“なぜ”を理解する必要がある」と述べ、評価を「最終応答」と「軌跡（trajectory）」の2系統に分ける。Microsoftも「最終出力だけでなく、各ステップの質と効率も評価する」として、全体評価（system）と工程評価（process）に分けている。
💡 核心：「正しい最終答え」が壊れた途中経過を隠すことがある。逆に、答えは合っていても偶然・運・危険な近道だったかもしれない。だからエージェントでは「結果」と「過程」の両面を見る。単発の出力評価・LLM-as-judgeの基礎は AI評価（Evals）の記事を参照。
3. 何を測る？5つの軸
エージェント評価でよく使われる観点を、5つに整理する。
目標を達成したか。「予約しました」という発言ではなく、DBに予約が存在するかという最終状態で判定する。
妥当な手順を踏んだか。正しいツールを正しい順序・回数で使ったか。無駄な遠回りや危険な手は無かったか。
正しいツールを選び、正しい引数を渡したか。関数名・引数の型・値まで照合する（不要な呼び出しの検出も）。
何ステップ・何トークン・いくら・どれだけ時間がかかったか。正解でもコストが膨らめば実用にならない。観測値との連携が要る。
出力が関連・正確・十分か。開放的な内容はLLM-as-judgeやルーブリックで採点する。
注意：④効率（トークン・コスト・遅延）は、特定ベンダーが「評価指標」として明文化しているわけではなく、多くはオブザーバビリティの観測値を評価に持ち込む実務的な扱いだ。とはいえループして暴走するエージェントを止めるには欠かせない軸である。
4. どう測る？3人の採点者と「成果か軌跡か」
採点者（grader）は大きく3種類。Anthropicの整理に沿うと、それぞれに長短がある。
| 採点者 | 長所 | 短所 |
|---|---|---|
| コード（プログラム） | 速い・安い・客観的・再現可能 | 正しい言い換え・別解に脆い |
| LLM-as-judge（モデル） | 柔軟・大規模化可・ニュアンスを拾う | 非決定的・割高・人間との較正が要る |
| 人間 | 品質のゴールドスタンダード | 高コスト・遅い（可能なら避ける） |
まずはコードで測れるものをコードで、主観的・開放的な部分だけ別のモデルでLLM-as-judgeに任せ、人間は要所のスポットチェックに使う——が定石だ。LLM-as-judgeの設計（詳細なルーブリック・離散的な出力・判定者バイアス）は LLM評価の記事で詳しく扱っている。
「軌跡の丸暗記チェック」は脆い
では軌跡はどう採点するか。ここでAnthropicは強い立場を取る：「エージェントが特定の手順——ツール呼び出しを正しい順序で——を踏んだかを確認したくなるが、この方法は厳しすぎて脆いテストになる。エージェントは設計者が想定しなかった妥当な別解を見つけるからだ。創造性を不必要に罰しないために、“辿った経路”ではなく“生み出した成果”を採点する方がよいことが多い」。たとえば飛行機予約なら、「予約しました」という発言ではなく、環境のSQL DBに予約が実在するかを最終状態として測る。
一方、GoogleやMicrosoftは軌跡の一致度（完全一致／順不同一致／部分一致など）を正式な指標として提供している。両者は矛盾ではない——軌跡評価は「なぜ失敗したか」の診断に効き、成果評価は「妥当な創造性を罰しない」。実務では、厳密な完全一致は避け、「重要なツールが呼ばれたか」という鍵となる行動のチェックに緩めるのが現実的な落としどころだ。
5. エージェント評価ならではの難所
エージェント評価は、単発の出力評価には無い固有の難しさを抱える。
- 非決定性（同じ入力でも経路が変わる）：1回成功しても再現するとは限らない。k回すべてで成功するか（pass^k）といった信頼性の指標が要る。τ-benchの論文は「kが増えるほど性能が落ち、モデルの不安定さが露呈する」と報告している（数値は公開時点のもの）。
- 誤差の連鎖（compounding errors）：1手の成功率が p なら、t手では概ね pt。手数が伸びるほど一気に崩れる。長時間タスクほど成功率が急落するのはこのためだ。
- 報酬ハッキング／仕様の悪用：採点の「文字面」だけ満たして本来の目的を達成しない挙動。DeepMindの例では、ロボットアームがカメラと物体の間に自分を割り込ませ、掴んでいないのに掴んだように見せかけた。「正しく見えるが危険な経路」を見抜くため、軌跡・副作用の評価が要る。
- 評価セットの陳腐化・汚染：ベンチマークが学習データに混入（contamination）すると、スコアが実力を映さなくなる。エージェントの成熟に合わせて回帰用の評価を更新し続ける必要がある。
安全に関わる「危険な経路」の問題は AIガードレールとも地続きだ。最終答えだけを見る評価は、こうした落とし穴を素通りしてしまう。
6. 実務の回し方とベンチマーク
Anthropicの推奨を軸にすると、回し方はシンプルだ。
- 実際の失敗から小さく作る：何百件も要らない。本番で起きた失敗を20〜50件テストケース化する。
- 自動採点で回す：コード優先、開放的な部分だけLLM-as-judge。量を質より優先して数を確保する。
- 2種類を分ける：能力eval（何が得意か）と回帰eval（前にできたことがまだできるか）。
- ライフサイクルに乗せる：①出荷前の自動eval（CIに組込み）→②本番モニタリング→③A/Bテスト→④ユーザー反応・トレース確認、と層を重ねる。
- 早く書く：評価は後回しにするほど作りにくい。
業界の代表的なエージェント・ベンチマークも、自作評価の参考になる（各々「何を測るか」を見るのが大事。スコアはモデル・版で動くので鵜呑みにしない）。
| ベンチマーク | 何を測るか |
|---|---|
| SWE-bench / Verified | 実在のGitHub課題をパッチで解決し、テストスイートで合否判定（実行ベース） |
| τ-bench / τ²-bench | 小売・航空などでツール×ユーザーの多ターン対話＋方針遵守。最終DB状態で採点 |
| WebArena | 現実を模したサイトでの自律的なWeb操作タスク完了 |
| GAIA | 人間には易しくAIには難しい汎用アシスタント課題（推論＋ツール＋閲覧） |
| OSWorld | 実OS上でGUIを操作するコンピュータ使用を実行ベースで評価 |
| BFCL | 関数・ツール呼び出しの正確さ（関数名・引数の構造／実行可能性） |
ツールとしては LangSmith・Braintrust・DeepEval・Arize Phoenix などが軌跡やツール呼び出しの評価を支援する。多くはトレースを土台に、ステップ単位・実行単位・データセット単位で採点する仕組みだ。なおClaude Managed Agentsは、ルーブリックに照らして別の採点役が評価する成果ベース評価を組み込みで提供している。
まとめ
エージェント評価（Agent Evals）は、ツールを使い多段で動くエージェントが本当にタスクを達成できるかを測る工程だ。単発出力を見るLLM評価と違い、「最後の答え（成果）」と「歩いた道（軌跡）」の両方を見る。測る軸は①成果 ②軌跡 ③ツール使用 ④効率 ⑤最終品質。採点はコード→LLM-as-judge→人間を使い分け、Anthropicは「経路より成果（最終状態）を採点せよ」（手順の丸暗記チェックは脆い）と勧める。
固有の難所は非決定性（pass^k）・誤差の連鎖・報酬ハッキング・評価セットの陳腐化。実務では本番の失敗から20〜50件で小さく始め、自動採点でCIに乗せ、能力evalと回帰evalを分け、早く書くのが定石だ。関連：AI評価（Evals）、オブザーバビリティ、マルチエージェントの作り方、Managed Agents。
FAQ
Q. エージェント評価とは何ですか？
A. ツールを使い複数手を踏んで動くエージェントが、本当にタスクを達成できるかを体系的に測る工程です。プロンプト1回を採点するLLM評価の発展形で、対象が「1つの出力」から「一連の行動」に広がります。最後の答えだけでなく、そこに至る軌跡（どのツールをどう呼んだか）まで見るのが特徴です。
Q. 普通のLLM評価と何が違いますか？
A. 見る対象が「出力」か「行動の連なり」かが違います。エージェントは計画し、ツールを呼び、状態を更新するため、最終出力だけでは不十分です。正しい答えが壊れた途中経過を隠すこともあれば、答えが合っていても危険な近道だったこともある。だから成果（最終状態）と軌跡（過程）の両面を評価します。
Q. 何を測ればいいですか？
A. 代表的なのは5軸です。①成果（タスク成功＝最終状態がゴール通りか）②軌跡（妥当な手順か）③ツール使用の正確さ（正しいツール・正しい引数か）④効率（手数・トークン・コスト・遅延）⑤最終応答の質（関連・正確・十分か）。④はオブザーバビリティの観測値を持ち込む実務的な軸で、暴走を止めるのに重要です。
Q. 軌跡（手順）は厳密に一致をチェックすべき？
A. いいえ、厳密一致は脆くなりがちです。Anthropicは「ツール呼び出しを正しい順序で踏んだかの確認は厳しすぎて脆い。エージェントは妥当な別解を見つけるので、経路ではなく成果を採点する方がよい」と勧めます。実務では完全一致を避け、「重要なツールが呼ばれたか」という鍵となる行動に緩めるのが現実的。一方で軌跡は「なぜ失敗したか」の診断に有用なので、目的に応じて使い分けます。
Q. どう始めればいいですか？
A. 本番で起きた失敗を20〜50件、テストケース化するところから。Anthropicも「何百件も要らない。実際の失敗から取ったシンプルな20〜50件が立派な出発点」と述べています。コードで測れるものはコードで、開放的な部分だけ別モデルのLLM-as-judgeで自動採点し、CIに乗せて回帰を検知。能力eval（何が得意か）と回帰eval（前にできたことが保てているか）を分け、評価は早めに書くのがコツです。
