AIエージェント評価の方法｜指標・手順・運用設計を実務で解説

AIエージェントの評価はLLM評価と何が違うのか？

AIエージェントの評価では、1回の回答の良し悪しではなく、複数ステップの行動過程と最終的な結果の両方を確かめる必要があります。

LLM（大規模言語モデル）の評価は、多くの場合「入力に対して出力が適切か」を採点すれば済みます。AIエージェントは違います。ツールを呼び出し、外部システムを操作し、途中の結果を見て次の行動を決めます。評価の単位は「回答」から「タスクの遂行」に変わります。

評価対象が「出力」から「軌跡と結果」に広がる

AIエージェントの評価では、最終出力に加えて、どのツールをどの順で呼んだかという軌跡（トラジェクトリ）と、その結果どうなったかを確認します。

たとえば経費精算を処理するAIエージェントなら、ユーザーへの返答文が丁寧かどうかより、「正しい申請レコードが正しいステータスで登録されたか」のほうが重要です。逆に、返答文が完璧でも、裏で誤ったAPIを呼んでいれば業務上は失敗です。Anthropicが公開している評価に関する解説でも、エージェントが「何をしたと言ったか」ではなく、実行後の環境の状態（outcome）で判定することが勧められています。

非決定性と環境依存が評価を難しくする

AIエージェントは同じ入力でも実行ごとに経路が変わり、環境の状態にも影響されます。複数回の試行と環境の固定が前提になります。

1回の試行で成功したからといって、本番で安定して成功するとは限りません。外部APIの応答やテスト用データの状態が試行ごとに変わると、AIエージェントが悪いのか環境が悪いのか区別できなくなります。実務では、評価用のサンドボックス環境を用意し、試行のたびに初期状態へ戻す仕組みを先に作っておくと、後の分析がかなり楽になります。この準備を省いて評価を始め、数字がぶれる原因を追えなくなるケースは珍しくないようです。

AIエージェントはどんな指標で評価すべきか？

指標はタスク成功率を中心に置き、プロセス品質・効率・安全性の3つを加えた4層で設計します。そのうえで事業KPIとつなぐのが実務的です。

指標を増やしすぎると、改善の判断ができなくなります。最初は「成功率＋各層から1〜2個」に絞り、運用しながら増やしていくほうが定着しやすいと感じます。

成果指標：タスク成功率と安定性（pass@k／pass^k）

最も重要な指標はタスク成功率です。あわせて、複数回試行しても毎回成功するかを示すpass^kを見ると、本番での安定性を判断できます。

2つの指標は似ていますが、意味は大きく異なります。

• pass@k：k回試行して1回でも成功すれば成功とみなします。「解ける能力があるか」を測る指標で、コード生成の評価でよく使われます。
• pass^k：k回試行してすべて成功した場合のみ成功とみなします。Sierraの研究チームが2024年に発表したベンチマーク「τ-bench」で提案された考え方で、顧客対応のように毎回同じ品質が求められる業務に向いています。

社内ヘルプデスクや受発注処理のように「10回に1回失敗すると業務が回らない」用途では、pass@kよりpass^kを重視すべきです。pass@kが高くてもpass^kが低いなら、能力はあっても安定性が足りない状態です。プロンプトやツール定義の曖昧さを疑うのが定石です。

プロセス・効率・安全性の指標

成功率だけでは失敗の原因がわかりません。ツール選択の正確さ、ステップ数、コスト、ガードレール違反率もあわせて測ります。

効率の指標は軽視されがちですが、AX（AI Transformation）の投資判断では最終的に「人手でやる場合と比べて安いか、速いか」が問われます。PoCの段階からタスクあたりのコストと所要時間を記録しておくと、意思決定者への説明がしやすくなります。

AIエージェント評価はどんな手順で進めるのか？

評価は「成功の定義」「タスクセットの作成」「採点器の設計」「ベースラインの計測」「改善ループ」の5段階で進めます。

1. 成功の定義：業務担当者と「何をもって完了とするか」を文章で合意する
2. タスクセットの作成：実際の業務ログや過去の失敗事例から評価タスクを作る
3. 採点器（グレーダー）の設計：タスクごとに、コード採点・LLM-as-a-Judge・人手のどれで判定するかを決める
4. ベースラインの計測：現行のプロンプト・モデル・ツール構成で複数回試行し、各指標を記録する
5. 改善ループ：失敗を分類し、修正のたびに同じタスクセットで再計測する

成功基準とタスクセットを先に決める

最初に業務担当者と完了条件を文章で合意し、実際の業務ログから数十件規模の評価タスクを作るところから始めます。

ここで「良い回答をすること」のような曖昧な基準のまま進めると、採点者によって判定が分かれます。「請求書番号・金額・取引先の3項目が会計システムに正しく登録され、承認者に通知が送られていること」のように、第三者が見ても同じ判定になる粒度まで具体化します。

タスクセットには、正常系だけでなく次のようなケースも意図的に含めます。

• 情報が足りず、AIエージェントが確認の質問をすべきケース
• 権限外の操作を求められ、断るべきケース
• ツールがエラーを返し、リトライまたは人への引き継ぎが必要なケース

最初から数百件をそろえる必要はありません。数十件でも、実際の失敗に基づくタスクであれば改善の手がかりとして十分に機能します。むしろ、件数を増やす前に「このタスクは人間の担当者なら確実に正解できるか」を確認するほうが大切です。正解が曖昧なタスクが混ざると、成功率の数字が信頼できなくなります。

ベースラインを測り、失敗を分類して改善する

初回の計測で現状値を記録したら、失敗ケースのトランスクリプトを読み込み、原因別に分類します。これで改善の優先順位がはっきりします。

数字だけを見て改善策を考えるのは避けたほうがよいでしょう。失敗したトランスクリプトを実際に読むと、「AIエージェントの判断ミス」と思われていたものが「ツールの説明文が曖昧」「評価タスクの正解が間違っていた」「採点器が正しい別解を不正解にしていた」といった、エージェント以外の問題だったとわかることが少なくありません。

評価の採点はコード採点とLLM-as-a-Judgeのどちらを使うべきか？

検証できる部分はコード採点、文脈の判断が要る部分はLLM-as-a-Judgeで採点し、人手のレビューで較正する併用型が原則です。

どちらか一方に寄せる必要はありません。1つのタスクの中でも、「レコードが登録されたか」はコードで、「ユーザーへの説明が適切か」はLLM-as-a-Judgeで判定する、という組み合わせが現実的です。

コード採点が向くケースと限界

最終状態の確認や形式のチェックのように、正解を機械的に判定できる部分は、まずコード採点で固めます。

DBのレコード、ファイルの生成、APIの呼び出し履歴などはコードで確実に検証できます。再現性が高いため、後で説明するCI（継続的インテグレーション）での回帰テストにもそのまま使えます。

一方で、軌跡を厳密に固定しすぎるのは危険です。「ツールAの次にツールBを呼ぶこと」と手順まで指定すると、AIエージェントが別の妥当な手順で目的を達成した場合に不正解になります。手順ではなく結果を採点するのが基本で、手順を縛るのは「承認前に送金APIを呼ばない」のような安全上の制約に限るのがよいと考えています。

LLM-as-a-Judgeの使いどころとバイアス対策

LLM-as-a-Judgeは主観的な観点の採点に有効です。ただしバイアスがあるため、採点基準を細かく分け、人手の判定と照合して較正します。

Zhengらが2023年に発表したMT-Benchの研究では、強いLLMを採点者にすると人間の評価とよく一致する一方で、次のバイアスが報告されています。

• 位置バイアス：比較する候補のうち、先に提示されたもの（あるいは後のもの）を好む
• 冗長性バイアス：長い回答を高く評価しやすい
• 自己優遇バイアス：自分と同じ系統のモデルの出力を好む可能性がある

実務での対策は次のとおりです。

1. 「総合的に良いか」ではなく、観点ごとに「満たす／満たさない」の二値で判定させる
2. 採点ルーブリックに合格例と不合格例を添える
3. 判定の根拠を出力させ、人手で抜き取りレビューする
4. 人手の判定との一致度を定期的に測り、ずれたらルーブリックを直す
5. 判断材料が足りない場合は「判定不能」を選べるようにする

OpenAI、Anthropic、Googleのいずれのモデルを採点者に使う場合でも、「LLMの判定をそのまま信じない」という前提は変わりません。最初の数週間は、人手レビューにある程度の工数を確保しておくのが無難です。

本番運用後にAIエージェントの品質をどう維持するのか？

本番運用後は、オフライン評価をリリース工程に組み込んで性能の後退（回帰）を防ぎます。同時に本番トレースを監視し、新しく見つかった失敗を評価セットに戻していきます。

AIエージェントの品質は、リリースした時点で固定されるわけではありません。モデルのバージョン更新、プロンプトの修正、ツールの仕様変更、利用者の使い方の変化によって、気づかないうちに劣化します。

回帰テストとしての評価をリリース工程に組み込む

プロンプト・モデル・ツールのどれかを変えるたびに同じ評価セットを自動で実行し、指標が悪化していればリリースを止める仕組みを作ります。

評価セットは目的に応じて2種類に分けて管理すると運用しやすくなります。

• 回帰用セット：すでに安定して解けるタスク。成功率がほぼ100%を保つことが前提で、下がったら何かが壊れたサインです
• 能力向上用セット：まだ十分に解けない難しいタスク。改善の進み具合を測るために使います

能力向上用セットのタスクが安定して解けるようになったら、回帰用セットへ移します。LLMのモデル更新は外部のベンダー側で起きるため、モデルのバージョンを固定できる場合は固定し、切り替える前に必ず評価セットを通す運用にしておくと安心です。

本番トレース監視と評価セットの継続更新

本番ではすべての実行トレースを記録します。異常の兆候を監視し、人手レビューで見つかった失敗を評価タスクに変えて評価セットを育てます。

本番の利用者による「役に立たなかった」というフィードバックや、人間の担当者への引き継ぎが起きたケースは、評価セットにとって最も価値のある材料です。オフライン評価は「既知の失敗を防ぐ仕組み」、本番監視は「未知の失敗を見つける仕組み」と位置づけ、この2つを循環させることが、AIエージェントを業務に定着させるうえでの要点だと考えています。

評価の仕組みは、AIエージェント本体ほど注目されません。それでも、評価があるからこそモデルの切り替えやプロンプトの改善を安心して進められます。AX推進の現場では、PoCの段階から評価セットとトレースの基盤をあわせて設計しておくことをおすすめします。

参考・出典

• Anthropic「Building effective agents」（2024年12月）
• Anthropic Engineering「Demystifying evals for AI agents」
• Yao, S. et al.「τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains」arXiv:2406.12045（2024年）
• Zheng, L. et al.「Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena」arXiv:2306.05685（2023年）
• Jimenez, C. E. et al.「SWE-bench: Can Language Models Resolve Real-World GitHub Issues?」arXiv:2310.06770（2023年）

公開前に監修者が確認すべき点

• 出典：web検索を使わず記憶をもとに書いています。2つ目のAnthropicの記事は公開日が不確かなため日付を外しました。5件とも、掲載前にURLと日付を確認してください。
• 数値：出典のない数値は入れていません。運用頻度の表は目安の例として明記しています。
• 一次体験：「〜と感じます」「〜と考えています」とした箇所は一次体験の草稿です。監修者ご自身の現場経験に合わせて調整してください。

姉妹メディアの関連記事