AI Agent評価は、Agentへタスクを与え、出力・Tool利用・実行後の状態を採点し、期待した振る舞いをどの程度再現できるか確認する取り組みです。
通常のLLM評価が一つの入力と出力を中心に扱うのに対し、AI Agentは複数ターンでToolを呼び、外部状態を書き換えます。最終回答が自然でも、誤った顧客へ返金していれば成功ではありません。想定した順番とは違っても、許可された操作だけで正しい結果へ到達していることもあります。この経路を追う土台がObservabilityとTraceです。
評価対象はモデル単体ではなく、Agent全体
Agentの結果はモデルだけで決まりません。
- Instructions
- 利用できるToolとその説明
- Agent loop
- Memoryと入力Context
- 実行環境
- モデルと推論設定
- 外部APIの応答
この組み合わせが変われば、同じモデルでも振る舞いは変わります。Anthropicも、Agentを評価するときはモデルとAgent harnessを組み合わせたシステムを評価すると整理しています。
そのため、モデルの公開ベンチマークだけで、自社のAgentが本番業務を処理できるとは判断できません。自社のInstructions、Tool、データ、権限、実行環境を含む評価が必要です。
Unit Test、ベンチマーク、監視との違い
| 手法 | 主な対象 | 分かること | 分からないこと |
|---|---|---|---|
| Unit Test | 関数や決定的な処理 | 入出力が仕様どおりか | Agent全体の非決定的な判断 |
| モデルベンチマーク | モデル単体 | 共通課題での相対性能 | 自社Toolと業務での成功率 |
| Agent評価 | Agentと実行環境 | タスク達成、Tool利用、失敗傾向 | 未収集の本番パターン |
| 本番監視 | 実利用時の挙動 | レイテンシ、エラー、利用傾向 | 期待結果が正しかったか |
どれか一つで済ませるものではありません。決定的に確認できる部分はUnit Testへ寄せ、Agentの判断と結果を評価し、本番監視から新しい失敗例を評価セットへ戻します。
Task、Trial、Grader、Transcript、Outcomeを分ける
AnthropicのAgent評価の整理を使うと、評価設計の責任を分けやすくなります。
Task
Agentへ与える一つの課題です。入力だけでなく、成功条件、利用できるTool、初期状態を定義します。
Trial
Taskを一度実行した記録です。Agentの出力は実行ごとに変わるため、一つのTaskを複数回試し、成功の再現性を見ます。一度成功したことと、安定して成功できることは別です。
Grader
結果を採点するロジックです。コードによる判定・モデルによるRubric評価・人間による評価を組み合わせます。
TranscriptまたはTrace
モデルの応答、Tool呼び出し、引数、Tool結果、再試行を含む実行過程です。失敗原因と、Graderが妥当かを確認するために使います。
Outcome
実行後に外部システムへ残った状態です。「返金しました」という回答ではなく、対象の注文に正しい金額の返金レコードが作成されたか。こちらを確認します。
Evaluation harness
Taskを実行し、環境を初期化し、Transcriptを記録し、Graderを動かして結果を集計する基盤です。本番と大きく異なるToolや権限で動かすと、評価結果も本番を表しません。Agentの実行・検証環境全体を扱うHarness Engineeringとも重なる領域です。
最終回答より先にOutcomeを確認する
Webシステムへ組み込むAgentでは、まず外部状態を決定的に確認します。
たとえば返金Agentなら、次の順で評価します。
- 正しい注文へ、許可された金額の返金が作成されたか
- 本人確認と返金条件を満たしたか
- 正しいToolと引数を使ったか
- 不要な更新や重複実行がなかったか
- 利用者への説明が正確だったか
- ターン数、レイテンシ、トークン、コストが許容範囲か
説明の自然さから採点を始めると、業務上の失敗を見落とします。データベース・ファイル・チケット・送信履歴といったOutcomeを先に確認し、その後でTranscriptと回答品質を見ます。
ただし、決められたTool順序を厳密に再現させる評価は、正しい別解まで失敗にする可能性があります。守るべきPolicyや必須操作は確認しつつ、処理経路を固定しすぎないようにします。
Graderは決定的な判定から使う
コードによるGrader
Unit Test・Schema検証・DB状態・静的解析・Tool引数・禁止操作の有無を確認します。速く、再現しやすい。コードで判定できる条件は、できるだけここへ置きます。
モデルによるGrader
説明の分かりやすさ・根拠との整合・トーンといった、単純な一致判定が難しい項目をRubricで採点します。Grader自体も非決定的です、人間の判断と定期的に照合します。
人間によるGrader
専門知識が必要な判断、曖昧な品質、新しい失敗例を確認します。すべてを人手で回すのではなく、モデルによるGraderの調整と抜き取り確認へ使います。
OpenAIの評価ガイドも、早い段階からタスク固有の評価を作り、ログから評価例を集め、自動評価を人間のフィードバックで調整する方針を示しています。
初期評価セットは実際の失敗から作る
最初から網羅的な評価基盤を作る必要はありません。Anthropicは初期段階では、実際の失敗から集めた20〜50件の単純なTaskから始める方法を示しています。まずは、すでに人が確認しているものからで十分です。
候補になるのは次の材料です。
- リリース前に人が毎回確認している操作
- 過去の障害やバグ
- Supportへ届いた失敗例
- 権限境界に近い操作
- Toolを呼ぶべきケースと、呼ばないケース
- 正常系と拒否すべきケース
Taskの文章とGraderが曖昧だと、Agentではなく評価問題の不備を測ることになります。既知の正解手順を一度通し、評価環境とGraderが正しい結果を合格にできるか確認します。
Offline評価と本番評価をつなぐ
Offline評価
リリース前に固定したDatasetを繰り返し実行します。モデル、Instructions、Tool定義、Agent loopを変えたときの比較と回帰確認に向いています。
本番評価
本番Traceやサンプリングした実行を対象にします。実際の入力分布、未知の失敗、コスト、レイテンシを確認できます。ただし、利用者へ影響が出た後に分かる項目もあります。
評価セットへの還流
本番で見つかった失敗を、再現可能なTaskへ変換します。修正後は回帰評価へ追加し、次のモデル更新やTool変更で同じ失敗が戻らないかを確認。ここまでつながって、評価セットが運用の資産になります。
Amazon Bedrock AgentCore Evaluationsは、Traceを共通形式へ変換し、組み込みまたは独自のEvaluatorで、オンデマンド・バッチ・オンライン評価を行う機能を提供しています。サービスを利用する場合も、何を成功とするかは業務側で定義する必要があります。
よくある誤解
公開ベンチマークが高ければ自社Agentも動く
公開ベンチマークはモデル比較の一つの材料です。自社のTool・権限・データ・失敗条件は含まれないため、そのまま本番判断には使えません。
一度成功すれば合格にできる
Agentの出力は実行ごとに変わります。重要なTaskは複数回実行し、平均値だけでなく、失敗の頻度と内容まで確認します。
LLM-as-a-Judgeなら人手確認は不要になる
モデルによるGraderにも偏りと揺らぎがあります。人間の判断との一致を確認し、Rubricと評価例を更新します。
ログがあれば評価できる
ログは起きたことを記録します。成功条件とGraderがなければ、その実行が正しかったかは決められません。
総合スコア一つで品質を判断できる
一つの数字へ集約すると、返答品質は上がったが誤更新が増えた、といった変化を見落とします。Outcome・Policy違反・Tool利用・回答品質・コストは分けて確認したいところです。
EastBraver Labsの判断基準
EastBraver Labsでは、Agent評価をモデル選定のためだけに使いません。
評価は、Agentへ渡してよい責任範囲を決めるための材料と考えます。
平均スコアが高くても、取り消せない操作で失敗するなら、そのToolは自動実行へ渡しません。まずは読み取り・下書き・提案から。失敗を観測できるようになってから、更新範囲を広げます。
評価結果を見るときは、Agentの失敗と、Task・Grader・環境の不備を分けます。数字だけで判断せず、失敗したTranscriptとOutcomeを読む。なぜ失敗扱いになったかまで確認します。
モデルを更新するときも、「新しい方が賢い」という説明ではなく、自社の回帰評価、レイテンシ、コスト、失敗モードを同じ条件で比較します。比較の前提となる「どのModelとRuntimeが動いていたか」という構成の記録は、AI BOMで追える状態にします。