Home Anthropic: AIエージェント評価の実践ガイド — Demystifying Evals
投稿
キャンセル

✍️ Anthropic: AIエージェント評価の実践ガイド — Demystifying Evals

投稿日 22/02/2026
投稿者 0h-n0
21 分読了時間

ブログ概要（Summary）

Anthropicのエンジニアリングチームが公開した本ブログは、AIエージェント評価（eval）の全体像を体系的に整理したガイドである。評価の基本用語定義、3種類のグレーダー（コードベース・モデルベース・人間）、pass@kとpass^kの使い分け、そして評価システム構築の8ステップロードマップを提供している。SWE-Bench Verified、Terminal-Bench、tau-Bench、CORE-Benchなど主要ベンチマークの実例と、Descript・Bolt・Qodoなどの企業事例も含む実践的な内容である。

この記事は Zenn記事: マルチエージェントRAGの応答品質をLLM-as-Judgeで分解評価する実践手法 の深掘りです。

情報源

技術的背景（Technical Background）

AIエージェントの品質保証は、従来のソフトウェアテストとは根本的に異なる。エージェントの出力は非決定的であり、同じ入力に対して異なる結果を返すため、単一の実行結果では品質を判断できない。さらに、エージェントはツール呼び出し・マルチステップ推論・環境とのインタラクションを行うため、最終出力だけでなくプロセス全体の評価が必要となる。

Anthropicは自社のClaude Codeの開発過程でこの課題に直面し、「初期段階では変更の効果量が大きいため小規模なテストセットで十分だが、システムが成熟するにつれて大規模かつ多角的な評価が不可欠になる」という知見を得たと報告している。

実装アーキテクチャ（Architecture）

評価の基本構造

著者らは、評価（eval）を以下の数式で定義している。

\[\text{Eval} = \text{Task} + \text{Graders} + \text{Outcome}\]

各構成要素の定義は以下の通りである。

用語定義
Task定義された入力と成功基準を持つ単一テスト
Trialタスクの1回の試行。出力のばらつきがあるため複数回必要
Graderエージェントのパフォーマンスをスコアリングするロジック
Transcript完全な試行記録（出力、ツール呼び出し、推論、中間結果）
Outcome試行終了時の最終環境状態（エージェントの自己申告ではなく実際の状態）

Outcome（成果） の定義が重要である。著者らは「エージェントが何をしたと言ったかではなく、実際に何が起こったかを評価する」ことを強調している。例えば、予約処理エージェントの評価では、エージェントの応答テキストではなく、SQLデータベースに予約レコードが実際に存在するかを確認する。

2つの評価カテゴリ

Capability/Quality Evals（能力評価）: エージェントが苦手とする領域を対象とし、低い合格率から始まる。改善目標を設定し、合格率が十分に高くなったらRegression Evalsに「昇格」させる。

Regression Evals（回帰評価）: 既に達成した能力を維持できているかを検証する。合格率はほぼ100%を維持すべきであり、スコア低下は即座に修正が必要なブレークを示す。

3種類のグレーダー

コードベースグレーダー

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 文字列一致（正規表現）
assert re.match(r"expected_pattern", agent_output)

# テスト実行（fail-to-pass）
result = subprocess.run(["pytest", "test_fix.py"])
assert result.returncode == 0

# 静的解析
ruff_result = subprocess.run(["ruff", "check", "src/"])
mypy_result = subprocess.run(["mypy", "src/"])
bandit_result = subprocess.run(["bandit", "-r", "src/"])

# ツール呼び出し検証
assert "read_file" in transcript.tool_calls
assert "edit_file" in transcript.tool_calls

利点は高速・低コスト・客観的・再現可能であるが、正当な変異に対して脆弱で、主観的タスクには向かない。

モデルベースグレーダー（LLM-as-Judge）

ルーブリックベース評価、自然言語アサーション、ペアワイズ比較、参照ベース評価、マルチジャッジコンセンサスの手法がある。柔軟で自由形式の出力を扱えるが、非決定的であり、人間グレーダーとのキャリブレーションが必要である。

人間グレーダー

ゴールドスタンダードの品質を提供し、モデルベースグレーダーのキャリブレーションにも使用される。ただし高コスト・低速で、大規模な専門家アクセスが必要となる。

pass@k と pass^k の使い分け

2つの指標は同じ試行データから計算されるが、意味が根本的に異なる。

pass@k: $k$ 回の試行で少なくとも1回正解する確率。

\[\text{pass@}k = 1 - (1 - p)^k\]

ここで $p$ は1回の試行あたりの成功率である。$k$ が増えるとpass@kは上昇する。50%のpass@1は、タスクの半数で初回に成功することを意味する。開発ツールのように「1回成功すれば良い」場面に適する。

pass^k: $k$ 回の試行すべてが成功する確率。

\[\text{pass}^k = p^k\]

$k$ が増えるとpass^kは低下する。75%のper-trial成功率で3回試行すると、$\text{pass}^3 = 0.75^3 \approx 42\%$ となる。顧客対応エージェントのように一貫した信頼性が求められる場面に適する。

著者らは以下の関係を指摘している。$k = 1$ では両指標は同一だが、$k = 10$ では正反対のストーリーを語る。pass@10はほぼ100%に近づく一方、pass^10はほぼ0%に近づく。

主要ベンチマーク

ベンチマークタイプ特徴
SWE-Bench Verifiedコーディング実GitHub Issueから出題。1年で40%→80%超に
Terminal-Bench 2.0コーディングLinuxカーネルビルド、MLモデル訓練等の実務タスク
tau-Bench / tau2-Bench会話型マルチターンタスク指向会話。Dec-POMDPとしてモデル化
BrowseCompリサーチWeb上の「干し草の中の針」問題。1,266問
WebArenaコンピュータ使用ブラウザタスク。812タスク/241テンプレート
OSWorldコンピュータ使用OS全体の操作。369タスク
CORE-Bench研究再現性計算再現性評価。Opus 4.5はグレーダー修正後42%→95%

CORE-Benchの事例は特に示唆的である。Opus 4.5の初期スコアは42%だったが、グレーダーのバグ（「96.12」を不正解とし「96.124991…」を要求する硬直的な評価、曖昧な仕様、確率的タスク）を修正した結果、95%に跳ね上がった。これは「エージェントの性能」と「評価の品質」を区別することの重要性を示している。

評価システム構築の8ステップロードマップ

Step 0: 早期に始める

著者らは、20〜50個の簡単なタスクを実際の失敗事例から作成することを推奨している。初期のエージェント開発では変更の効果量が大きいため、小さなサンプルサイズで十分に有意な結果が得られる。

Step 1: 手動テストを自動化する

リリース前に手動で行っている確認作業を、自動化された評価タスクに変換する。バグトラッカーやサポートキューからユーザー報告の失敗事例を収集し、テストケースに変換する。

Step 2: 曖昧さのないタスクと参照解答を作成する

2人のドメインエキスパートが独立して同一の合否判定に到達できるレベルの明確さが求められる。フロンティアモデルがpass@100で0%を達成する場合、通常はタスクの不備を示す。

Step 3: バランスの取れた問題セットを構築する

行動が「発生すべき」ケースと「発生すべきでない」ケースの両方をテストする。著者らはClaude.aiのWeb検索評価を例に挙げている。「検索が必要なクエリ」（天気）と「知識で回答できるクエリ」（Apple創業者）の両方を含めなければ、過少/過剰トリガーのバランスが最適化されない。

Step 4: 安定した環境で堅牢な評価ハーネスを構築する

試行間で環境が汚染されない「隔離」が重要である。著者らは、Claude Codeが前回の試行のgit履歴を参照して不公平な優位性を得た事例を報告している。

Step 5: グレーダーを慎重に設計する

成果を評価し、経路を評価しない。エージェントは評価者が想定しなかった有効なアプローチを見つけることがある。マルチコンポーネントタスクには部分点を設計し、LLM-as-Judgeグレーダーは人間エキスパートと密にキャリブレーションする。

Step 6: トランスクリプトを確認する

多くの試行のトランスクリプトと評点を読み、失敗が「公正」に見えることを確認する。スコアが上がらない場合、エージェントの性能ではなく評価の品質が原因でないかを検証する。

Step 7: 能力評価の飽和を監視する

SWE-Bench Verifiedは30%から80%超に到達し、飽和に近づいている。飽和した評価では、大幅な能力向上がわずかなスコア改善としてしか現れない。Qodoは当初Opus 4.5に失望したが、より長く複雑なタスク向けの新しい評価フレームワークを構築した結果、明確な進歩を確認できた。

Step 8: 評価スイートを長期的に健全に保つ

評価スイートは継続的な管理が必要な「生きたアーティファクト」である。著者らは「eval-driven development」（計画された能力を定義する評価をエージェントが達成する前に構築する）を推奨している。

Swiss Cheeseモデル

著者らは安全工学のSwiss Cheese Model（スイスチーズモデル）を引用し、単一の評価レイヤーではすべての問題を捕捉できないと主張している。

手法タイミング利点欠点
自動評価プレローンチ、CI/CD再現可能、スケーラブル初期投資、保守が必要
本番モニタリングポストローンチ実ユーザー行動を観測事後対応、ノイジー
A/Bテスト大きな変更時実際のユーザー成果を測定低速（日〜週単位）、トラフィック必要
ユーザーフィードバック継続的予期しない問題を発見疎、自己選択的
手動レビュー週次サンプリング失敗モードの直感を構築時間集約的
体系的人間研究LLMグレーダーのキャリブレーションゴールドスタンダード高コスト、低速

複数の手法を組み合わせることで、1つのレイヤーをすり抜けた問題を別のレイヤーで捕捉する多層防御を実現する。

実運用での学び（Lessons from Production）

企業事例

Descript: 3つの次元（破壊防止・要求充足・実行品質）で評価を構築。手動評価からLLMグレーダーに移行し、定期的な人間キャリブレーションを実施。品質スイートと回帰スイートを分離運用している。

Bolt: エージェント展開後に評価構築を開始。3か月で静的解析グレーダー、ブラウザエージェントによるアプリテスト、LLMジャッジによる行動評価のシステムを構築した。

Claude Code（Anthropic内部）: 初期は高速イテレーション、その後に狭い領域（簡潔さ、ファイル編集）の評価を追加。後に複雑な行動（過剰エンジニアリング）の評価も構築し、研究チームとプロダクトチームの協力を促進した。

学術研究との関連

本ブログの内容は、Zheng et al. (2023) のLLM-as-a-Judge研究を実務に適用した知見の集大成と位置づけられる。特にpass@kとpass^kの使い分け、グレーダー品質がエージェント評価に与える影響（CORE-Benchの事例）、Swiss Cheeseモデルによる多層評価戦略は、学術研究では十分に議論されていない実務的な視点を提供している。

まとめ

Anthropicの本ブログは、AIエージェント評価を「何を・どう・いつ」の観点から体系化した実践ガイドである。特に「エージェントの性能か評価の品質か」を区別する視点、「成果を評価し経路を評価しない」原則、pass@kとpass^kの使い分けは、マルチエージェントRAGの品質評価パイプライン構築に直接活用できる知見である。

参考文献

blog tech_blog
evaluation agent LLM-as-Judge anthropic CI/CD
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次