📝 原文: Demystifying evals for AI agents（Anthropic Engineering Blog）
はじめに
AIエージェントの開発が急速に進む中、「エージェントをどう評価するか」は多くの開発チームが直面する課題です。プロトタイプ段階では手動テストや直感で十分に開発を進められますが、本番環境でスケールし始めると評価なしでは破綻します。
Anthropicのエンジニアリングチームは、Claude Codeの開発経験と顧客企業（Descript、Bolt等）との協業から得られた知見を体系化し、AIエージェント評価の包括的ガイドを公開しました。本記事では、この原文を徹底的に解説し、実務に活かせる形で整理します。
🎯 この記事で学べること
- 評価（Eval）の基本概念と用語
- 3種類のGrader（採点器）の使い分け
- エージェント種別ごとの評価手法
- 非決定性に対応する
pass@kとpass^kの使い方 - ゼロから評価を構築する実践ロードマップ
- 「結果をグレーディングし、経路ではない」という核心原則
1. 評価（Eval）の基本構造と用語定義
評価とは何か
Evaluation（評価） とは、AIシステムに対するテストです。AIにインプットを与え、そのアウトプットに採点ロジックを適用して成功を測定します。
従来のLLMでは Single-turn Evaluation（シングルターン評価） が主流でした。プロンプト → レスポンス → 採点ロジックの3つで構成されるシンプルなものです。
一方、エージェントは複数のターンにわたってツールを呼び出し、環境の状態を変更し、中間結果に基づいて適応します。そのため Multi-turn Evaluation（マルチターン評価） が必要になります。ミスが伝播・複合するため、評価はさらに複雑になります。
📖 用語定義
| 用語 | 説明 | 具体例 |
|---|---|---|
| Task（タスク） | 定義されたインプットと成功基準を持つ単一のテスト | 「TypeErrorを修正せよ」 |
| Trial（試行） | タスクへの各試行。出力の変動に対応するため複数回実行 | 同一タスクのk回目の実行 |
| Grader（採点器） | エージェントのパフォーマンスを採点するロジック | pytest実行、LLM判定 |
| Transcript（記録） | 試行の完全な記録（出力、ツール呼び出し、推論など） | API呼び出しと応答の全記録 |
| Outcome（結果） | 試行終了時の環境の最終状態 | DBに予約が存在するか |
| Evaluation Harness | 評価をエンドツーエンドで実行するインフラ | タスク実行・採点・集計基盤 |
| Agent Harness | モデルがエージェントとして機能できるようにするシステム | Claude Code、Agent SDK |
| Evaluation Suite | 特定の能力を測定するタスクの集合 | 顧客サポート評価スイート |
⚠️ TranscriptとOutcomeの違いは重要です！
フライト予約エージェントがTranscriptで「予約完了」と出力しても、Outcomeは「実際にDBに予約が存在するか」です。「言ったこと」と「実際にやったこと」は区別して評価しなければなりません。
2. なぜ評価を構築すべきか
評価がないチームの末路
"The breaking point often comes when users report the agent feels worse after changes, and the team is 'flying blind' with no way to verify except to guess and check."
（破綻のポイントは、変更後にエージェントが悪化したとユーザーから報告され、チームが「盲目飛行」状態になり、推測と確認以外に検証方法がなくなったときに訪れることが多い。）
評価なしでは、デバッグは受動的になります：
- ユーザーからの苦情を待つ
- 手動で再現する
- バグを修正する
- 他の箇所が壊れていないことを祈る 🙏
評価がもたらす価値
| 段階 | 評価の役割 |
|---|---|
| 開発初期 | 「エージェントの成功」を明確に定義する |
| 本番運用後 | 一貫した品質基準を維持する |
| モデル更新時 | 数日でモデルの強みを把握しアップグレード可能 |
| チーム間連携 | 研究チームと製品チームの最高帯域のコミュニケーションチャネル |
実際の事例
Claude Code の進化：
- 初期: 社員フィードバックによる手動品質管理
- 狭域eval追加: 簡潔さやファイル編集など特定機能に評価を導入
- 拡張eval追加: 過度なエンジニアリングなど複雑な行動の評価
- 成熟期: 本番モニタリング・A/Bテスト・ユーザーリサーチとの統合
Descript のアプローチ：
動画編集エージェントの評価を3つの軸で構築：
- ❌ 壊すな（Don't break things）
- ✅ 言った通りにやれ（Do what I asked）
- ⭐ うまくやれ（Do it well）
手動採点 → LLMグレーダー → 定期的な人間キャリブレーションと段階的に進化。
Bolt AI のアプローチ：
すでに広く使われるエージェントを持ってから評価を構築。3ヶ月で評価システムを構築し、静的解析・ブラウザエージェントによるテスト・LLMジャッジによる指示遵守の評価を実行。
3. 3種類のGrader（採点器）
エージェント評価では通常、3種類のGraderを組み合わせます。各Graderは、TranscriptまたはOutcomeのいずれかを評価します。
比較表
| 項目 | 🔧 コードベースGrader | 🤖 モデルベースGrader | 👤 人間Grader |
|---|---|---|---|
| 手法 | 文字列マッチ、バイナリテスト、静的解析、ツール呼び出し検証、トランスクリプト分析 | ルーブリック評価、自然言語アサーション、ペアワイズ比較、リファレンス評価、多数決判定 | SMEレビュー、クラウドソーシング、スポットチェック、A/Bテスト、評価者間一致度 |
| 強み | 高速、安価、客観的、再現可能、デバッグ容易 | 柔軟、スケーラブル、ニュアンスを捉える、オープンエンドに対応 | ゴールドスタンダード品質、専門的判断、モデルGraderのキャリブレーション |
| 弱み | パターン不一致の有効解に脆い、ニュアンス不足 | 非決定的、高コスト、人間とのキャリブレーション必要 | 高コスト、低速、スケール困難 |
| 適用場面 | テスト通過、API呼び出し検証、出力形式チェック | 文章品質、推論妥当性、トーン評価 | エッジケース判定、Graderの精度検証 |
🔧 コードベースGrader の詳細
特徴：高速・安価・再現可能。客観的な条件を検証する場面で使用。
主な検証方法：
- 文字列マッチ（完全一致、正規表現、ファジー）
- バイナリテスト（fail-to-pass、pass-to-pass）
- 静的解析（lint、型チェック、セキュリティスキャン）
- Outcome検証（環境状態の確認）
- ツール呼び出し検証（使用ツール、パラメータ）
- Transcript分析（ターン数、トークン使用量）
🤖 モデルベースGrader の詳細
特徴：柔軟でニュアンス対応可能。主観的・定性的な判定に使用。
主な手法：
- ルーブリック評価: 明確な採点基準に基づくスコアリング
- 自然言語アサーション: 「エージェントは顧客の不満に共感を示した」
- ペアワイズ比較: 2つの出力のどちらが優れているか判定
- リファレンスベース評価: 正解例との比較
- 多数決判定: 複数のLLMジャッジの合意
💡 ポイント: 重要な判定には3回実行の多数決が推奨されています。
👤 人間Grader の詳細
特徴：ゴールドスタンダード。キャリブレーションとエッジケースに使用。
主な用途：
- LLM-as-Judgeのキャリブレーション（人間の判断と比較）
- 専門家レビュー（医療、法律等の高リスク領域）
- スポットチェック（ランダムサンプリングでの検証）
- A/Bテスト（ユーザー嗜好の判定）
スコアリング方式
各タスクのスコアリングは以下の方式から選択できます：
- 重み付け方式: 複合Graderスコアが閾値を超える必要がある
- バイナリ方式: すべてのGraderがパスする必要がある
- ハイブリッド: 上記の組み合わせ
4. Capability Eval vs Regression Eval
2種類のEvalを理解して使い分けることが重要です。
| 項目 | 🚀 Capability Eval（能力評価） | 🛡️ Regression Eval（回帰評価） |
|---|---|---|
| 問い | 「このエージェントは何ができるか？」 | 「以前できたことがまだできるか？」 |
| 初期パス率 | 低い（苦手なタスクをターゲット） | ほぼ100% |
| 目的 | チームに「登るべき丘」を与える | 後退を防ぐ |
| スコア低下時 | 改善の余地がある | ⚠️ 何かが壊れている |
「卒業」の仕組み
Capability Eval（低パス率）
↓ 改善を重ねる
↓ パス率が高くなる
↓
Regression Suite に「卒業」🎓
→ 継続的に実行し、ドリフトをキャッチ
Capability evalでパス率が高くなったタスクは、Regression Suiteに移行させて継続的に実行します。かつて「これができるか？」を測っていたものが、「まだ確実にできるか？」を測るものに変わります。
5. エージェント種別ごとの評価手法
概要比較
| エージェントタイプ | 主要Grader | ベンチマーク例 | 特有の課題 |
|---|---|---|---|
| 🖥️ コーディング | 決定論的テスト + LLMルーブリック + 静的解析 | SWE-bench Verified, Terminal-Bench | テスト通過とコード品質のバランス |
| 💬 会話型 | 状態検証 + Transcript制約 + LLMルーブリック | τ-Bench, τ2-Bench | ユーザーシミュレーションの必要性 |
| 🔍 リサーチ | 根拠性検証 + カバレッジ + LLM評価 | BrowseComp | 「包括的」の定義がコンテキスト依存 |
| 🖱️ コンピュータ操作 | 環境状態検証 + URL/UI検証 | WebArena, OSWorld | サンドボックス環境の構築 |
🖥️ コーディングエージェントの評価
コーディングエージェントはコードを書き、テストし、デバッグします。ソフトウェアは「コードは動くか？テストはパスするか？」で評価しやすいため、決定論的なGraderが自然です。
代表的なベンチマーク：
- SWE-bench Verified: GitHubイシューを与え、テストスイートで採点。LLMは1年で40%→80%超に進歩
- Terminal-Bench: Linuxカーネルビルドやモデル学習など、エンドツーエンドの技術タスク
評価構成の例（YAML）：
task:
id: "fix-auth-bypass_1"
desc: "Fix authentication bypass when password field is empty and ..."
graders:
# 1. 決定論的テスト（最重要）
- type: deterministic_tests
required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
# 2. LLMルーブリック（コード品質）
- type: llm_rubric
rubric: prompts/code_quality.md
# 3. 静的解析
- type: static_analysis
commands: [ruff, mypy, bandit]
# 4. 環境状態チェック
- type: state_check
expect:
security_logs: {event_type: "auth_blocked"}
# 5. ツール呼び出し検証
- type: tool_calls
required:
- {tool: read_file, params: {path: "src/auth/*"}}
- {tool: edit_file}
- {tool: run_tests}
tracked_metrics:
- type: transcript
metrics: [n_turns, n_toolcalls, n_total_tokens]
- type: latency
metrics: [time_to_first_token, output_tokens_per_sec, time_to_last_token]
💡 注意: この例はGraderの全範囲を示すためのものです。実際のコーディング評価では、通常ユニットテスト（正しさの検証）とLLMルーブリック（コード品質の評価）が中心で、追加のGraderは必要に応じて使います。
💬 会話エージェントの評価
会話エージェントの特徴は、インタラクション自体の品質も評価対象になることです。他のエージェントと異なり、ユーザーをシミュレートする別のLLMがしばしば必要になります。
成功は多次元的に評価されます：
- チケットは解決されたか？（状態チェック）
- 10ターン以内に完了したか？（Transcript制約）
- トーンは適切だったか？（LLMルーブリック）
評価構成の例（YAML）：
graders:
# 1. LLMルーブリック（サポート品質）
- type: llm_rubric
rubric: prompts/support_quality.md
assertions:
- "Agent showed empathy for customer's frustration"
- "Resolution was clearly explained"
- "Agent's response grounded in fetch_policy tool results"
# 2. 環境状態チェック
- type: state_check
expect:
tickets: {status: resolved}
refunds: {status: processed}
# 3. ツール呼び出し検証
- type: tool_calls
required:
- {tool: verify_identity}
- {tool: process_refund, params: {amount: "<=100"}}
- {tool: send_confirmation}
# 4. Transcript制約
- type: transcript
max_turns: 10
tracked_metrics:
- type: transcript
metrics: [n_turns, n_toolcalls, n_total_tokens]
- type: latency
metrics: [time_to_first_token, output_tokens_per_sec, time_to_last_token]
🔍 リサーチエージェントの評価
リサーチエージェントは情報を収集・統合・分析し、レポートを生成します。評価が特に難しい理由：
- 専門家間で意見が分かれる: 「包括的」の基準がコンテキストで異なる
- 正解が変動する: 参照コンテンツが常に変化する
- 出力が長くオープンエンド: 誤りの余地が大きい
評価戦略の組み合わせ：
- Groundedness Check: 主張がソースに裏付けられているか
- Coverage Check: 良い回答に含まれるべき主要事実が網羅されているか
- Source Quality Check: 参照元が権威あるものか
- 正解のある問い: 完全一致で検証（「X社のQ3売上は？」）
- LLMによる総合評価: コヒーレンスと完全性の検証
⚠️ リサーチ品質の主観性から、LLMベースのルーブリックは専門家の人間判断と頻繁にキャリブレーションする必要があります。
🖱️ コンピュータ操作エージェントの評価
スクリーンショット、マウスクリック、キーボード入力など、人間と同じインターフェースでソフトウェアを操作するエージェントです。
代表的なベンチマーク：
- WebArena: ブラウザベースのタスク。URL・ページ状態チェック + バックエンド状態検証
- OSWorld: フルOS制御。ファイルシステム・アプリ設定・DB内容・UIプロパティを検査
DOM vs スクリーンショットの使い分け：
| 方式 | 速度 | トークン効率 | 適用場面 |
|---|---|---|---|
| DOM操作 | 高速 | トークン消費大 | テキスト中心（例: Wikipedia要約） |
| スクリーンショット | 低速 | トークン効率的 | ビジュアル重視（例: Amazon商品検索） |
Claude for Chromeでは、エージェントが各コンテキストに応じて適切なツールを選択しているかの評価を構築し、タスク完了の速度と正確性を向上させました。
6. 非決定性への対処：pass@k と pass^k
なぜ非決定性が問題か
エージェントの振る舞いはラン間で変動します。あるタスクの成功率は90%かもしれないし、別のタスクでは50%かもしれません。1回のevalで通過したタスクが、次のランでは失敗するかもしれません。
この変動に対処するため、2つの重要な指標を使い分けます。
📊 2つの指標
pass@k：k回の試行で少なくとも1回成功する確率
$$\text{pass@}k = 1 - (1 - p)^k$$
kが増えるとスコアは上昇します。「1回でも成功すればOK」な場面に適しています。
pass^k：k回の試行がすべて成功する確率
$$\text{pass}^k = p^k$$
kが増えるとスコアは下降します。「毎回確実に動いてほしい」な場面に適しています。
比較表（成功率75%の場合）
| k | pass@k（1回でも成功） | pass^k（全部成功） |
|---|---|---|
| 1 | 75% | 75% |
| 3 | ≈98.4% | ≈42.2% |
| 10 | ≈99.99% | ≈5.6% |
⚠️ k=1では両メトリクスは同一ですが、k=10では劇的に乖離します。
実運用での使い分け
| 場面 | 推奨指標 | 理由 |
|---|---|---|
| 開発・探索段階 | pass@k | 能力の上限を探索する |
| 本番・信頼性 | pass^k | 一貫した信頼性を測定する |
| コーディングエージェント | pass@1 | 最初の試行で解を見つけるか |
| 顧客対応エージェント | pass^k | 毎回の対話で確実に成功するか |
💡 重要な洞察: pass@10が99.9%でも、pass^10が35%なら「10回中1回は3回連続で失敗する」ことを意味し、ユーザー体験に直結します。
7. 評価構築の実践ロードマップ（8ステップ）
Step 0: 🚀 早く始める
20〜50タスクから始める。完璧なeval setを待つ必要はない。
初期段階では変更の影響が大きいため、小さなサンプルでも十分に検出できます。待てば待つほど構築は難しくなります。
Step 1: 📝 手動テストを変換する
開発時に実行していた手動チェック、バグトラッカー、サポートキューからタスクを作成します。ユーザー影響度で優先順位をつけましょう。
Step 2: ✅ 曖昧さのないタスクを書く
良いタスクの基準：
2人のドメイン専門家が独立して同じ合否判定に達するもの。
各タスクにリファレンスソリューション（既知の正解）を作成すると、Graderの検証にも役立ちます。
Step 3: ⚖️ バランスの取れた問題セットを構築する
振る舞いが発生すべきケースと発生すべきでないケースの両方をテストします。
⚠️ 一方的な評価は一方的な最適化を生みます。
Step 4: 🏗️ 堅牢なハーネスを構築する
- 試行間で環境を完全隔離する
- インフラの不安定さが相関する失敗を生まないようにする
Step 5: 🎯 思慮深いグレーディングを設計する
核心原則：
💎 「結果をグレーディングし、経路ではない」（Grade results, not paths）
エージェントが特定のステップに従ったかをチェックしたくなりますが、これは脆すぎるテストになりがちです。
- 決定論的グレーダーを可能な限り使う
- LLMグレーダーは必要な場合にのみ使う
- 部分点を設計する
- LLM-as-Judgeには構造化ルーブリックと「Unknown」の逃げ道を用意する
💡 Opus 4.5がτ2-benchのフライト予約問題で、評価基準上は「失敗」だが実際にはポリシーの抜け穴を発見しユーザーにとってより良い解を見つけた例が紹介されています。ステップの固定検証は、こうした創造的な解法を排除してしまいます。
Step 6: 📖 トランスクリプトを読む
多くの試行からトランスクリプトを読まない限り、Graderがうまく機能しているかわかりません。
失敗が公正に見えるか、「測定のアーティファクトを測っていないか」を自問しましょう。
Step 7: 📈 飽和を監視する
パス率が100%に近づくと、そのevalは回帰テストとしてのみ機能します。改善のシグナルがなくなるため、新しいCapability evalの追加が必要になります。
Step 8: 🔧 長期メンテナンス
evalをユニットテストと同様に「生きたアーティファクト」として扱います。
- インフラチームがコア基盤を所有
- ドメインチームがタスクを追加
- 定期的にレビューと更新を実行
8. 多層防御モデル（Swiss Cheese Model）
Anthropicは安全工学のスイスチーズモデルをevalに適用しています。単一の手法ではすべての問題をキャッチできません。複数のアプローチを重ね合わせることで、1つをすり抜けた失敗を別の層でキャッチします。
| 手法 | 用途 | 長所 | 短所 |
|---|---|---|---|
| 自動eval | 高速イテレーション、すべてのコミットで実行 | 再現可能、ユーザー影響なし | 初期投資、メンテナンスドリフト |
| 本番モニタリング | 実ユーザー行動、分布ドリフト検出 | 合成evalの盲点を補完 | 事後的、ノイジー |
| A/Bテスト | 重要な変更の検証 | 実ユーザー結果、交絡制御 | 低速（日〜週単位） |
| ユーザーフィードバック | 予期しない問題の発見 | 直感では見つからない問題を発見 | 疎ら、自己選択バイアス |
| 手動Transcriptレビュー | 微妙な品質問題のキャッチ | 直感の構築 | 時間集約的、スケールしない |
| 体系的な人間研究 | LLM Graderのキャリブレーション | ゴールドスタンダード | 高コスト、評価者間不一致 |
🧀 スイスチーズモデル
自動eval → 本番モニタリング → A/Bテスト → ユーザーFB → 手動レビュー
[穴] [穴] [穴] [穴] [穴]
\\ | / | /
\\ | / | /
→→→→ 問題がすべての穴を通過する確率を最小化 ←←←←
9. 実務の落とし穴：CORE-BenchとMETRの事例
Anthropicは、eval設計自体のテストが不可欠であることを示す2つの具体的な失敗事例を紹介しています。
🔴 CORE-Bench の事例
Opus 4.5のスコアが当初42%だったが、これはeval側の問題だった：
| 問題 | 具体例 |
|---|---|
| 厳密すぎるグレーディング | 「96.12」vs「96.124991…」を不正解扱い |
| 曖昧な仕様 | 正解の判定基準が不明確 |
| 確率的タスク | 毎回結果が変わるタスクを含んでいた |
修正後、スコアは95%に跳ね上がった。
⚠️ 教訓: 低スコアがモデルの問題とは限らない。評価自体の品質を疑え。
🔴 METR の事例
時間制限ベンチマークで、設定された閾値に従うモデルがペナルティを受け、無視するモデルが高スコアを得るという逆転現象が発生した。
⚠️ 教訓: 評価のインセンティブ構造が意図した行動を奨励しているか確認すること。
10. まとめと実践への示唆
核心原則
💎 「結果をグレーディングし、経路ではない」（Grade results, not paths）
実践チェックリスト
- 早く始める — 完璧なスイートを待たず、20〜50タスクからスタート
- 実際の失敗から現実的なタスクを調達する — バグトラッカー、サポートキューを活用
- 曖昧さのない成功基準を定義する — 2人の専門家が同じ判定に達するか
- 複数のGraderタイプを組み合わせる — Code-Based中心、必要に応じModel-Based、キャリブレーションにHuman
- Capability EvalとRegression Evalを分ける — 高パス率タスクは回帰スイートに卒業
- pass@kとpass^kを使い分ける — 開発時はpass@k、本番はpass^k
- トランスクリプトを読む — Graderの動作を検証する唯一の方法
- 多層防御を実践する — 自動eval + モニタリング + A/Bテスト + 手動レビュー
- evalをメンテナンスする — 飽和の監視、Graderの定期検証
評価の価値は複利で効く
評価のないチームは反応的なループにはまり込みます。1つの失敗を修正し、別を作り、真の回帰とノイズを区別できません。
早期に投資するチームは逆の体験をします。失敗がテストケースになり、テストケースが回帰を防ぎ、メトリクスが推測を置き換え、開発が加速します。
参考リンク
| リソース | URL |
|---|---|
| 📄 原文: Demystifying evals for AI agents | https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents |
| 📄 Building effective agents (Anthropic) | https://www.anthropic.com/research/building-effective-agents |
| 🏆 SWE-bench Verified | https://www.swebench.com/ |
| 🏆 Terminal-Bench | https://terminal-bench.com/ |
| 🏆 τ-Bench / τ2-Bench | https://github.com/sierra-research/tau-bench |
| 🏆 WebArena | https://webarena.dev/ |
| 🏆 OSWorld | https://os-world.github.io/ |
| 🏆 BrowseComp | https://openai.com/index/browsecomp/ |