# AI Agent評価とは — 本番導入前後に何を測るか

> AI Agent評価の対象を、最終回答、Tool利用、実行結果、安全性、コストに分け、回帰評価と本番監視をつなぐ方法を整理します。

Canonical URL: https://labs.eastbraver.com/guides/ai-agent-evaluation
Published: 2026-07-01
Updated: 2026-07-15
Category: field-guide
Tags: evaluation, ai-agent, software-engineering

AI Agent評価は、Agentへタスクを与え、出力・Tool利用・実行後の状態を採点し、期待した振る舞いをどの程度再現できるか確認する取り組みです。

通常の[LLM](/guides/llm)評価が一つの入力と出力を中心に扱うのに対し、AI Agentは複数ターンで[Tool](/guides/tool)を呼び、外部状態を書き換えます。最終回答が自然でも、誤った顧客へ返金していれば成功ではありません。想定した順番とは違っても、許可された操作だけで正しい結果へ到達していることもあります。この経路を追う土台が[ObservabilityとTrace](/guides/observability-tracing)です。

## 評価対象はモデル単体ではなく、Agent全体

Agentの結果はモデルだけで決まりません。

- Instructions
- 利用できるToolとその説明
- Agent loop
- Memoryと入力Context
- 実行環境
- モデルと推論設定
- 外部APIの応答

この組み合わせが変われば、同じモデルでも振る舞いは変わります。[Anthropicも、Agentを評価するときはモデルとAgent harnessを組み合わせたシステムを評価すると整理しています](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)。

そのため、モデルの公開ベンチマークだけで、自社のAgentが本番業務を処理できるとは判断できません。自社のInstructions、Tool、データ、権限、実行環境を含む評価が必要です。

## Unit Test、ベンチマーク、監視との違い

| 手法 | 主な対象 | 分かること | 分からないこと |
| --- | --- | --- | --- |
| Unit Test | 関数や決定的な処理 | 入出力が仕様どおりか | Agent全体の非決定的な判断 |
| モデルベンチマーク | モデル単体 | 共通課題での相対性能 | 自社Toolと業務での成功率 |
| Agent評価 | Agentと実行環境 | タスク達成、Tool利用、失敗傾向 | 未収集の本番パターン |
| 本番監視 | 実利用時の挙動 | レイテンシ、エラー、利用傾向 | 期待結果が正しかったか |

どれか一つで済ませるものではありません。決定的に確認できる部分はUnit Testへ寄せ、Agentの判断と結果を評価し、本番監視から新しい失敗例を評価セットへ戻します。

## Task、Trial、Grader、Transcript、Outcomeを分ける

[AnthropicのAgent評価の整理](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)を使うと、評価設計の責任を分けやすくなります。

### Task

Agentへ与える一つの課題です。入力だけでなく、成功条件、利用できるTool、初期状態を定義します。

### Trial

Taskを一度実行した記録です。Agentの出力は実行ごとに変わるため、一つのTaskを複数回試し、成功の再現性を見ます。**一度成功したことと、安定して成功できることは別**です。

### Grader

結果を採点するロジックです。コードによる判定・モデルによるRubric評価・人間による評価を組み合わせます。

### TranscriptまたはTrace

モデルの応答、Tool呼び出し、引数、Tool結果、再試行を含む実行過程です。失敗原因と、Graderが妥当かを確認するために使います。

### Outcome

実行後に外部システムへ残った状態です。「返金しました」という回答ではなく、対象の注文に正しい金額の返金レコードが作成されたか。こちらを確認します。

### Evaluation harness

Taskを実行し、環境を初期化し、Transcriptを記録し、Graderを動かして結果を集計する基盤です。本番と大きく異なるToolや権限で動かすと、評価結果も本番を表しません。Agentの実行・検証環境全体を扱う[Harness Engineering](/guides/harness-engineering)とも重なる領域です。

## 最終回答より先にOutcomeを確認する

Webシステムへ組み込むAgentでは、まず外部状態を決定的に確認します。

たとえば返金Agentなら、次の順で評価します。

1. 正しい注文へ、許可された金額の返金が作成されたか
2. 本人確認と返金条件を満たしたか
3. 正しいToolと引数を使ったか
4. 不要な更新や重複実行がなかったか
5. 利用者への説明が正確だったか
6. ターン数、レイテンシ、トークン、コストが許容範囲か

説明の自然さから採点を始めると、業務上の失敗を見落とします。データベース・ファイル・チケット・送信履歴といったOutcomeを先に確認し、その後でTranscriptと回答品質を見ます。

ただし、決められたTool順序を厳密に再現させる評価は、正しい別解まで失敗にする可能性があります。守るべきPolicyや必須操作は確認しつつ、処理経路を固定しすぎないようにします。

## Graderは決定的な判定から使う

### コードによるGrader

Unit Test・Schema検証・DB状態・静的解析・Tool引数・禁止操作の有無を確認します。速く、再現しやすい。コードで判定できる条件は、できるだけここへ置きます。

### モデルによるGrader

説明の分かりやすさ・根拠との整合・トーンといった、単純な一致判定が難しい項目をRubricで採点します。Grader自体も非決定的です、人間の判断と定期的に照合します。

### 人間によるGrader

専門知識が必要な判断、曖昧な品質、新しい失敗例を確認します。すべてを人手で回すのではなく、モデルによるGraderの調整と抜き取り確認へ使います。

[OpenAIの評価ガイドも、早い段階からタスク固有の評価を作り、ログから評価例を集め、自動評価を人間のフィードバックで調整する方針を示しています](https://developers.openai.com/api/docs/guides/evaluation-best-practices)。

## 初期評価セットは実際の失敗から作る

最初から網羅的な評価基盤を作る必要はありません。[Anthropicは初期段階では、実際の失敗から集めた20〜50件の単純なTaskから始める方法を示しています](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)。まずは、すでに人が確認しているものからで十分です。

候補になるのは次の材料です。

- リリース前に人が毎回確認している操作
- 過去の障害やバグ
- Supportへ届いた失敗例
- 権限境界に近い操作
- Toolを呼ぶべきケースと、呼ばないケース
- 正常系と拒否すべきケース

Taskの文章とGraderが曖昧だと、Agentではなく**評価問題の不備**を測ることになります。既知の正解手順を一度通し、評価環境とGraderが正しい結果を合格にできるか確認します。

## Offline評価と本番評価をつなぐ

### Offline評価

リリース前に固定したDatasetを繰り返し実行します。モデル、Instructions、Tool定義、Agent loopを変えたときの比較と回帰確認に向いています。

### 本番評価

本番Traceやサンプリングした実行を対象にします。実際の入力分布、未知の失敗、コスト、レイテンシを確認できます。ただし、利用者へ影響が出た後に分かる項目もあります。

### 評価セットへの還流

本番で見つかった失敗を、再現可能なTaskへ変換します。修正後は回帰評価へ追加し、次のモデル更新やTool変更で同じ失敗が戻らないかを確認。ここまでつながって、評価セットが運用の資産になります。

[Amazon Bedrock AgentCore Evaluationsは、Traceを共通形式へ変換し、組み込みまたは独自のEvaluatorで、オンデマンド・バッチ・オンライン評価を行う機能を提供しています](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/evaluations.html)。サービスを利用する場合も、何を成功とするかは業務側で定義する必要があります。

## よくある誤解

### 公開ベンチマークが高ければ自社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](/guides/ai-bom)で追える状態にします。

## 関連記事

- [エージェント運用の検証が主題に](/digest/ai-digest-20260704)
- [評価基盤の外部依存を見直す日](/digest/ai-digest-20260706)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)
- [モデル選定とエージェント運用が接続](/digest/ai-digest-20260714)
- [AIエージェント運用は堅牢性と統制へ](/digest/ai-digest-20260716)

## 検証範囲

- 一次情報: 公式ドキュメント / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開