AI Agentの評価体系構築

この章では、AI Agentを開発・運用するときに、どのような評価体系を作ればよいかを整理します。

前の章では、評価体系は最初から完成させるものではなく、少しずつ育てていくものだと見てきました。では、実際に何を評価すればよいのでしょうか。

AI Agentは、最終回答が正しく見えても、使うべきツールを使っていなかったり、必要以上にツールを利用してコストやレイテンシが大きくなっていたり、関係ないテストを削除して成功扱いにしていたりすることがあります。

そのため、Agentを改善するために、AI Agentの評価は最終回答の正誤だけではなく、過程、ツール利用、根拠、安全性、コストや安定性を複数のレイヤーで見る必要があります。

評価体系の全体像

この章では、AI Agentの評価観点を6つのカテゴリで整理します。

カテゴリ	見るもの	代表的な失敗
Outcome Metrics	最終的に目的を達成したか	回答は自然だが、タスクが解決していない
Trajectory Metrics	どのような過程で到達したか	結果は合っているが、非効率な手順を通っている
Tool Use Metrics	ツールを正しく使えたか	必要なDBや検索を使わずに推測で回答する
Groundedness Metrics	根拠に基づいているか	根拠にない回答をする
Safety / Policy Metrics	やってはいけないことをしていないか	承認なしに更新や削除を実行する
Cost / Latency / Reliability Metrics	本番運用できるか	遅い、高い、不安定、再現しない

これらは横並びの指標リストというより、別々の失敗モードを見つけるためのレイヤーです。重要な失敗を見逃さないように組み合わせていくことが大切です。

Outcome Metrics: 最終的に目的を達成したか

Outcome Metricsは、Agentが最終的にタスクを達成したかを見る指標です。最も分かりやすく、最初に設計しやすい評価です。

指標	見るもの	例
Task Success Rate	タスクが完了したか	問い合わせに回答できた、修正PRを作れた
Correctness	最終結果が正しいか	回答、計算、分類が正しい
Reference Alignment	参照情報と一致しているか	FAQ、仕様書、DB結果と矛盾しない
User Acceptance Rate	人間が結果を採用したか	AIの提案を担当者がそのまま使った
Resolution Rate	問題が解決したか	サポート問い合わせが再オープンされない

ただし、Outcome Metricsだけでは不十分です。最終回答は正しくても、途中の行動が危険だったり、非効率であったりするからです。

Trajectory Metrics: どのような過程で到達したか

Trajectory Metricsは、Agentがゴールに到達するまでの行動の質を見る指標です。

指標	見るもの	例
Plan Quality	妥当な作業計画を立てたか	まず仕様を確認してから実装する
Step Efficiency	無駄なステップが少ないか	同じ検索やtool callを何度も繰り返さない
Decision Correctness	分岐判断が正しいか	人間承認が必要な操作を自動実行しない
Recovery Quality	失敗から回復できたか	APIエラー後に再試行や代替手段を選ぶ
Constraint Adherence	指示や制約を守ったか	read-only条件で更新系APIを呼ばない

Outcomeは「結果が良かったか」を見ます。Trajectoryは「その結果に至るプロセスが信頼できるか」を見ます。Agent開発では、このTrajectoryの観測が特に重要です。

Trajectoryに加え、一つ一つのプロセスで正しくtoolを使えているかを評価することもAI Agentの改善のためには重要です。次に、それを評価するTool Use Metricsをみていきましょう。

Tool Use Metrics: ツールを正しく使えたか

AI Agentは、検索、DB、社内API、コード実行、ブラウザ、チケットシステムなどのツールを使います。そのため、ツール利用そのものも評価対象になります。

AnthropicのWriting effective tools for agentsでは、Agentは与えられたツールに強く依存するため、ツールの設計と評価を継続的に改善することが重要だと説明されています。

指標	見るもの	例
Tool Selection Accuracy	適切なツールを選べたか	最新情報を必要な場面で検索する
Tool Use Recall	必要なツールを使えたか	顧客情報が必要な場面でCRMを参照する
Argument Correctness	tool callの引数が正しいか	customer_id、date range、file pathが正しい
Tool Call Validity	schemaに合う呼び出しができたか	や型が正しい
Tool Result Utilization	ツール結果を正しく使えたか	検索結果を無視して想像で回答しない

Tool Use Metricsを見ると、Trajectoryだけでなく、「答えるために必要な道具を正しく使えたか」を確認できます。

Groundedness / Hallucination Metrics: 根拠に基づいているか

AI Agentを現場に見せる前に、最低限押さえたいのがGroundednessです。回答が自然でも、根拠にない情報を作っているなら、業務では使いにくくなります。

指標	見るもの	例
Groundedness	回答が与えられた根拠に基づいているか	reference docsと矛盾しない
Hallucination Rate	根拠にない情報を作っていないか	存在しない仕様やポリシーを述べる
Citation Correctness	引用が主張を支えているか	引用先に実際にその内容がある
Context Relevance	参照した文脈が適切か	関係ない文書を根拠にしていない
Abstention Quality	分からないときに分からないと言えるか	根拠がないときに推測で断言しない

現場の人に早く見せることは重要です。ただし、現場レビューの前に、少なくともhallucination、groundedness、policy violationは自動で検知できるようにしておくと、レビューの時間を有効に使いやすくなります。

Safety / Policy Metrics: やってはいけないことをしていないか

Agentは外部ツールを使い、状態を変更することがあります。そのため、単なる回答品質だけでなく、安全性や権限境界も評価対象になります。

指標	見るもの	例
Policy Adherence	業務・法務・安全ポリシーを守ったか	返金条件や医療・金融助言ルールを守る
Unauthorized Action Rate	権限外操作をしていないか	承認なしに削除・送信・キャンセルしない
Sensitive Data Leakage	機密情報やPIIを漏らしていないか	他顧客の情報を出さない
Guardrail Trigger Accuracy	guardrailが適切に発火したか	危険操作を止める
Handoff / Escalation Accuracy	人間に渡すべきケースを渡せたか	曖昧・高リスクケースを自動処理しない

安全性の評価では、最初から巨大な評価体系を作る必要はありません。まずは、そのAgentにとって最も危険な操作や、最も避けたい失敗を明確にし、そこから評価を作ります。

ここでのHandoffは、Agentが自分で処理を続けるのではなく、人間の担当者や別の承認フローに引き渡すことを指します。Customer Support Agentであれば、返金条件が曖昧なケース、法務・医療・金融など慎重な判断が必要なケース、顧客感情が強く人間対応が望ましいケースなどが該当します。Handoffは「最終回答が正しいか」だけでは見えにくいため、Safety / Policy Metricsの中で明示的に評価します。

Cost / Latency / Reliability Metrics: 本番運用できるか

プロダクションでは、品質だけでなく、コスト、遅延、安定性も評価対象になります。

指標	見るもの	例
Cost per Task	1タスクあたりの推論・ツールコスト	1問い合わせあたり何円か
Cost per Successful Task	成功1件あたりの実効コスト	失敗や再試行を含めたコスト
Token Usage	token消費量	contextやtool resultが大きすぎないか
Time to Completion	完了までの時間	ユーザーが待てる範囲か
Regression Rate	変更で既存ケースが壊れていないか	prompt変更後に成功率が下がる
Multi-run Stability	複数回実行して安定するか	同じ入力で結果が大きくぶれない

AnthropicのQuantifying infrastructure noise in agentic coding evalsでは、agentic coding evalのスコアが、タスクの難しさだけでなく、CPU、RAM、時間制限などの実行環境に左右されることが示されています。外部ツールや実行環境に依存するAgent評価では、環境由来のノイズも評価設計に含める必要があります。

ユースケースごとの評価観点

評価体系は、Agentの用途によって重点が変わります。すべての指標を同じ重みで見る必要はありません。以下、ユースケースごとの評価観点の例です。

ユースケース	特に重要な観点	見るべき失敗
Customer Support Agent	Outcome、Groundedness、Safety / Policy（Handoff含む）	ポリシーにない返金条件を作る、人間に渡すべきケースを自動処理する
Coding Agent	Outcome、Trajectory、Tool Use、Reliability	テストを削除して通す、必要なlintやbuildを実行しない、CIノイズを実装バグと誤解する
Research Agent	Groundedness、Citation、Tool Use、Abstention	引用が主張を支えていない、探索不足なのに断言する
Data Analyst Agent	Correctness、Tool Use、Reproducibility	SQLや集計条件が間違う、再現できない分析を返す
Workflow Automation Agent	Outcome、Trajectory、Safety、Reliability	順序を間違える、承認なしに更新する、途中失敗から復帰できない

事例を細かく書き分けるより、最初はこのように「どの失敗を見逃したくないか」で評価観点を選ぶと分かりやすくなります。

評価体系構築のはじめ方

最初の評価体系を作るときの進め方を整理します。

1一番困る失敗を決める

まずは指標カタログを網羅しようとせず、ドメイン上もっとも困る失敗を決めます。例えば、Customer Support Agentなら誤った返金案内、Coding Agentならテスト削除による見かけ上の成功です。

1小さなテストケースを作る

10件から30件程度で構いません。実際の失敗例、想定ユースケース、境界ケースを入れます。

1決定的に判定できるものからscorerにする

形式、必須項目、tool callの有無、引用の有無など、機械的に見られるものから始めます。このscorerをもとに、現場の人に見せる前の最低限の品質に仕上げていきます。

1人手評価を行う

決定的なscorerで確認できない部分は、人間が評価します。最初は「良い/悪い」のような軽いFeedbackでも構いません。重要なのは、現場の人が何を良いと感じ、どこに違和感を持ったのかをTraceに紐づけて残すことです。そこから、正確性、根拠の有無、業務で使える品質、失敗モードなど、評価項目を少しずつ言語化していきます。

1評価体系とAI Agentの両方を発展させる

人手評価で見えた失敗は、Datasetに追加し、必要に応じてscorerやrubricに反映します。評価結果を見ながらAI Agentを改善し、同じDatasetで再評価し、前回より良くなったかを確認します。評価体系は一度作って終わりではありません。新しい失敗、本番でのFeedback、現場の判断を取り込みながら、AI Agent本体と一緒に育てていきます。

次の章では、まず、Weaveを用いた自動評価の評価体系構築をみていきます。その後に、Weaveを用いた人手評価の具体的な進め方を見ていきます。

参考

次の章では、Weaveを使ってDataset、scorer、evaluation、traceをつなげ、評価体系を実際に動かす方法を見ていきます。

前へAI Agent評価の心得次へ Weaveによる評価体系の構築