用語：Agent Evaluation
一言で：Agent Evaluationとは、AIエージェントが複数ステップで環境やツールを操作しながら目標を達成できるかを、最終結果だけでなく軌跡・ツール使用・副作用・再現性まで含めて評価することです。
AI用語の分類：AIの評価・安全・倫理・ガバナンス
Agent Evaluation（エージェント評価）は、AIエージェントが目標を与えられたとき、複数ステップにわたって計画し、ツールを使い、環境を変更し、途中の結果を見ながら最終目標を達成できるかを評価することです。
一般的なLLM評価では、「質問を一つ与える→回答を一つ返す」という形が多く使われます。しかしAIエージェントは、Web検索、ファイル編集、コード実行、ブラウザ操作、API呼び出しなどを何度も繰り返します。そのため、最終回答だけ見ても性能を正しく判断できません。
目次
エージェントでは評価対象が広がる
エージェントの性能は、基盤モデルだけで決まりません。どのツールを渡したか、system promptは何か、メモリがあるか、何回まで行動できるか、ブラウザやOSの状態はどうか、といったscaffoldやenvironmentに大きく影響されます。
たとえば同じLLMでも、検索ツールだけを持つ場合と、ブラウザ・Python・ファイル編集・ターミナルを持つ場合では、解けるタスクが変わります。したがってAgent Evaluationのスコアは、モデル名だけではなく「モデル＋エージェント実装＋環境」の成績として読む必要があります。
Task・Trial・Trace・Grader
Anthropicはagent evalの基本要素を、task、trial、grader、transcript/traceとして整理しています。Taskは一つの問題と成功条件です。Trialは、そのtaskを一度実行した試行です。LLMは確率的に振る舞うため、同じtaskでも成功したり失敗したりします。そのため一回だけでなく複数trialを行うことがあります。[1]
Traceは、回答だけでなく、途中のツール呼び出し、観察、ファイル変更、エラー、状態変化などを含む実行記録です。Graderは、その結果が成功したかを判定します。
最終結果だけでは足りない理由
エージェントが最終的に正しい答えを出しても、途中で不要なファイルを削除した、機密情報を外部送信した、禁止されたサイトを使った、偶然答えを見つけただけ、といった問題があり得ます。
逆に、最終出力が少し違っていても、本質的には正しい作業を完了している場合があります。単純な文字列一致graderでは、この違いを正しく扱えません。Agent Evaluationでは、最終状態、途中経路、副作用、ポリシー遵守を分けて評価する必要があります。
PaperBenchの例
OpenAIのPaperBenchは、AIエージェントに機械学習論文を与え、その実験結果をコードから再現させる長期タスクです。エージェントは論文を理解し、コードを書き、実験を動かし、成果物を作る必要があります。[2]
評価では、論文ごとに詳細なrubricを作り、再現に必要な要素を細かく分解します。単に「最終回答が正しいか」ではなく、複雑な成果物を段階的な評価項目で採点します。これは長期エージェント評価の代表例です。
BrowseCompの例
BrowseCompは、Web上で見つけにくい情報を探索する能力を測るBenchmarkです。単純な検索一回では答えられない、複数ページをたどる必要がある問題を用意します。[3]
ここでは、検索モデルの知識だけでなく、「どのページを開くか」「手掛かりから次の検索をどう作るか」という探索戦略が性能に影響します。これもsingle-turn QAとは異なるAgent Evaluationです。
Graderのバグがスコアを壊す
Agent Evaluationで特に難しいのがgraderです。Anthropicは、CORE-Benchで採点方法やtask specificationに問題があり、実装を見直した結果、同じモデルのスコアが大きく変化した事例を紹介しています。
これは、「Benchmarkの数字が低い＝エージェント能力が低い」と即断できないことを示します。エージェントは自由度が高いため、評価作成者が想定しなかった正しい解き方を見つけることがあります。graderが一つの経路しか認めないと、本当は成功している行動を失敗と判定します。
Grader hackingとloophole
逆の問題もあります。エージェントがtaskを本質的に解かず、graderの穴を突いて合格することがあります。たとえば、評価ファイルを直接読める、テストの答えが環境内に残っている、形式だけ満たせば成功扱いになる、といったケースです。
Agent Evaluationでは、成功条件を「抜け道を使わず目標を達成したか」に近づけ、graderや環境を攻撃されにくく設計する必要があります。
複数回試行と成功率
LLMエージェントは同じ入力でも毎回同じ経路を通りません。1回成功しただけでは、安定して成功するとは限りません。そのためpass@1、success rate、pass@kなどの指標を使います。
たとえば10回中7回成功するagentと、1回だけ実行して成功したagentは、表面的にはどちらも“成功”ですが信頼性が違います。実運用で重要なのは、平均能力だけでなく失敗率と失敗パターンです。
コストと時間も評価対象になる
二つのagentが同じtaskを解けても、一方が10回のtool callで終わり、もう一方が500回呼び出すなら実用性は違います。token cost、API cost、wall-clock time、tool calls、再試行回数などを併せて測ることがあります。
長期タスクでは、成功率を上げるために推論時間を増やせるため、「制限時間や予算を揃える」ことが公平な比較に重要です。
安全性では副作用を見る
Computer-using agentや業務agentでは、「タスクを達成したか」だけでなく、「許可されていない操作をしなかったか」を評価します。送信、購入、削除、権限変更など、不可逆な行動が含まれるためです。
したがって安全なAgent Evaluationでは、task successとpolicy complianceを別指標にする必要があります。高い成功率を得るために危険な行動を許すなら、そのagentは実運用には適しません。
元の文脈へ戻ったときのチェックポイント
「このagentはBenchmarkで80%」という数字を見たら、まずtaskとenvironmentを確認します。どのツールを使えたか、ネット接続はあったか、時間制限は何分か、何回試行したか、graderは何かを見ます。
次に、最終結果だけの採点か、traceや副作用も評価しているかを確認します。同じモデルでもscaffoldや環境が違えばスコアは比較できません。
Agent Evaluationは、モデルの“頭の良さ”だけを測るものではありません。「目標を、与えられた環境で、安定して、安全に、合理的なコストで達成できるか」を測る総合評価です。
関連するAI用語
注・出典
AI協働制作について
本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。