Demystifying evals for AI agents

一行要約

エージェントの eval は「入力を与えて出力を採点する」だけでは済まず、多ターン・ツール呼び出し・環境の状態変化が絡むため、grader の種類・非決定性の扱い・transcript の読解までを設計対象にしなければならない。

要点

なぜ eval を作るのか

Good evaluations help teams ship AI agents more confidently. Without them, it’s easy to get stuck in reactive loops—catching issues only in production. 良い evaluation があれば、チームは AI エージェントをより自信を持って出荷できる。なければ、本番でしか問題に気づけない後手の繰り返しに陥りやすい。

エージェント開発の典型的な進行として、次が描かれている。

1. 最初は手動テスト・dogfooding・直感でも驚くほど遠くまで行ける
2. 限界は「変更後にエージェントが悪くなった気がするとユーザーが報告し、当てずっぽうで確かめるしかない（flying blind）」ときに来る
3. eval がなければデバッグは受け身になる — 苦情を待ち、手で再現し、直し、他が壊れていないことを祈る

The capabilities that make agents useful also make them difficult to evaluate. エージェントを有用にしている能力そのものが、エージェントの評価を難しくしている。

自律性・知能・柔軟性という役に立つ性質そのものが、評価を難しくしている。

eval の効用は開発段階で変わる。初期は「成功とは何か」をプロダクトチームに明示させる強制力として働き、後期は一定の品質水準を保つために働く。

When more powerful models come out, teams without evals face weeks of testing while competitors with evals can quickly determine the model’s strengths, tune their prompts, and upgrade in days. より強力なモデルが出たとき、eval を持たないチームは数週間のテストに直面する。一方、eval を持つ競合はモデルの強みを素早く見極め、プロンプトを調整し、数日で移行できる。

用語の定義

原典が明示的に定義している語。この語彙が揃っていないと eval の議論は噛み合わない。

語	定義
Task（problem / test case）	入力と成功基準が定義された1つのテスト
Trial	タスクへの1回の試行。出力がぶれるので複数 trial を回す
Grader	エージェントの性能の一側面を採点するロジック。1タスクに複数の grader、1 grader に複数の assertion（check）
Transcript（trace / trajectory）	trial の完全な記録。出力、ツール呼び出し、推論、中間結果を含む
Outcome	trial 終了時点の環境の最終状態
Evaluation harness	eval を端から端まで回す基盤。指示とツールを与え、タスクを並列実行し、全ステップを記録し、採点し、集計する
Agent harness（scaffold）	モデルをエージェントとして動かす仕組み。入力を処理し、ツール呼び出しを統率し、結果を返す
Evaluation suite	特定の能力・振る舞いを測るために設計されたタスクの集合

注意: eval の限界を示す実例として、Opus 4.5 が τ2-bench の航空券予約問題でポリシーの抜け穴を発見した件が挙げられている。書かれた通りの eval では「失敗」だが、実際にはユーザーにとってより良い解だった。 Frontier models can also find creative solutions that surpass the limits of static evals.

grader の3種類

種類	手法	強み	弱み
Code-based	文字列一致（完全 / 正規表現 / あいまい）、binary test（fail-to-pass, pass-to-pass）、静的解析（lint / type / security）、outcome 検証、ツール呼び出し検証（使ったツール、パラメータ）、transcript 解析（ターン数、トークン数）	速い、安い、客観的、再現性がある、デバッグしやすい	正当なバリエーションに脆い、ニュアンスを捉えない、主観的タスクに限界
Model-based	rubric 採点、自然言語 assertion、pairwise 比較、参照解ベース、multi-judge consensus	柔軟、スケールする、ニュアンスを捉える、自由記述を扱える	非決定的、コードより高価、人間の採点との calibration が必要
Human	SME レビュー、クラウドソーシング、抜き取り、A/B テスト、annotator 間一致	品質のゴールドスタンダード、専門ユーザーの判断に一致、model grader の calibration に使う	高価、遅い、専門家をスケールさせるのが難しい

タスクごとの採点は weighted（grader スコアの合算が閾値を超える）/ binary（全 grader が通る）/ hybrid のいずれか。

capability eval と regression eval

この2つを混同しないことが重要として、明確に分けられている。

	問い	期待される pass rate
Capability eval	このエージェントは何がうまくできるか？	低いところから始める。苦手なタスクを狙い、登る坂を与える
Regression eval	以前できていたことを今もできるか？	ほぼ100%

capability eval で坂を登っている間も regression eval を回して、変更が他所を壊していないか確認する。ローンチ後に pass rate が高くなった capability eval は、継続実行する regression suite に「卒業」させる。

エージェント種別ごとの評価

コーディングエージェント

Deterministic graders are natural for coding agents because software is generally straightforward to evaluate: does the code run and do the tests pass? 決定的な grader はコーディングエージェントに向いている。ソフトウェアは概して評価しやすいからだ。コードは動くか、テストは通るか、である。

• SWE-bench Verified: 人気の Python リポジトリの GitHub issue を与え、テストスイートで採点。失敗テストを直しつつ既存テストを壊さないことが条件。1年で 40% から 80%超に進歩
• Terminal-Bench: end-to-end の技術タスク（ソースからの Linux kernel ビルド、ML モデルの訓練など）
• pass/fail テストが揃ったら、transcript も採点するとよい。コード品質のヒューリスティック規則や、ツールの呼び方・ユーザーとの対話の仕方を model grader で評価する

会話エージェント

• 従来のチャットボットと違い、状態を保持し、ツールを使い、会話の途中で行動する
• 他と異なる難しさは「やり取りの質そのものが評価対象」であること
• 多くの場合、ユーザーを演じる2つ目の LLM が必要
• 成功が多次元になる: チケットは解決したか（state check）、10ターン未満で終わったか（transcript 制約）、トーンは適切だったか（LLM rubric）
• τ-Bench / τ2-Bench: 小売サポートや航空券予約で、一方のモデルがユーザーペルソナを演じる

リサーチエージェント

Research quality can only be judged relative to the task. リサーチの品質は、そのタスクとの関係においてしか判断できない。

• 「包括的」「よく出典が付いている」「正しい」の基準が文脈依存（市場調査 / 買収のデューデリ / 科学レポートで別）
• 固有の難しさ: 専門家同士でも合意しない、参照コンテンツが変わるので ground truth が動く、出力が長く開放的なので誤りの余地が大きい
• BrowseComp: 検証は簡単だが解くのは難しい設問で、web 上の「干し草の中の針」を探せるか
• 戦略は grader の組み合わせ — groundedness check（主張が出典で裏づけられているか）、coverage check（良い答えが必ず含むべき事実）、source quality check（最初にヒットした情報源ではなく権威ある情報源か）。客観的な正解があるなら完全一致で足りる
• 主観性ゆえに、LLM rubric は専門家の判断に対して頻繁に calibration する

computer use エージェント

• API やコード実行ではなく、人間と同じインターフェース（スクリーンショット、クリック、キーボード、スクロール）で操作する
• WebArena: URL とページ状態のチェックに加え、データを変更するタスクではバックエンドの状態を検証する（確認ページが出ただけでなく、実際に注文が入ったか）
• OSWorld: OS 全体の操作へ拡張。ファイルシステム、アプリ設定、DB 内容、UI 要素の属性を検査する
• トークン効率とレイテンシのトレードオフ: DOM ベースは速いがトークンを食い、スクリーンショットは遅いがトークン効率が良い。Wikipedia の要約は DOM 抽出が有利、Amazon でのラップトップケース探しはスクリーンショットが有利

非決定性の扱い（pass@k と pass^k）

Each task has its own success rate—maybe 90% on one task, 50% on another—and a task that passed on one eval run might fail on the next. タスクごとに固有の成功率がある。あるタスクでは90%、別のタスクでは50%かもしれない。そして、ある実行で通ったタスクが次の実行では落ちることもある。

指標	意味	k を増やすと	使いどころ
pass@k	k 回の試行で少なくとも1回正解する確率	上がる（shots on goal が増える）	1回成功すればよいツール
pass^k	k 回の試行が全部成功する確率	下がる	一貫性が必須の顧客向けエージェント

• 50% pass@1 は「初回試行で半分のタスクに成功する」の意味
• 試行ごとの成功率 75% で3試行なら、pass^3 = (0.75)³ ≈ 42%
• コーディングでは初回で解けるかに関心があるので pass@1 を見ることが多い

ゼロからイチへのロードマップ（Step 0〜8）

Step 0. 早く始める — 数百タスクを待たず、実際の失敗から取った 20〜50 個の単純なタスクから始める。初期のエージェントは小さいサンプルでも性能変化がはっきり出る。

Step 1. すでに手動でテストしていることから始める — 既存の手動チェックとバグ報告をテストケースに変換する。ユーザー影響で優先順位を付けると、労力が効くところに投じられる。

Step 2. 参照解付きの、曖昧さのないタスクを書く

A good task is one where two domain experts would independently reach the same pass/fail verdict. 良いタスクとは、2人のドメイン専門家が独立に判定して同じ合否に至るようなタスクである。

参照解を作ることで、タスクが解けることと grader が正しく動くことの両方を検証できる。

Step 3. バランスの取れた問題集合を作る — ある振る舞いが起きるべき場合と、起きるべきでない場合の両方をテストする。クラス不均衡な eval は片側だけの最適化を招く。

Step 4. 安定した環境を持つ堅牢な harness を作る — 各 trial はクリーンな環境から始めて隔離する。共有状態は run 間に相関した失敗を持ち込む。

Step 5. grader を慎重に設計する — 可能なら決定的な grader、必要なときだけ LLM grader。

Grade what the agent produced, not the path it took. エージェントが辿った経路ではなく、生み出した成果物を採点せよ。

過度に脆いテストを避けるため、経路ではなく成果物を採点する。多要素タスクには部分点を用意する。

Step 6. transcript を読む

You won’t know if your graders are working well unless you read the transcripts and grades from many trials. 多数の試行のトランスクリプトと採点結果を読まない限り、grader がうまく機能しているかは分からない。

Step 7. capability eval の飽和を監視する — 解けるタスクを全部通してしまうと改善のシグナルが出なくなる。飽和が進むと最難関のタスクしか残らないので進捗が鈍る。

Step 8. eval suite を長期的に健全に保つ — 中核基盤を持つ専任チームを置き、ドメイン専門家がタスクを寄与する形にする。

Owning and iterating on evaluations should be as routine as maintaining unit tests. evaluation を自分たちで保有し改善し続けることは、ユニットテストの保守と同じくらい日常的であるべきだ。

他の手法との組み合わせ

どれか1つでは足りないという主張。原典は Swiss Cheese Model を引いている。

No single evaluation layer catches every issue. With multiple methods combined, failures that slip through one layer are caught by another. 単一の評価層ですべての問題を捕まえられるわけではない。複数の手法を組み合わせれば、ある層をすり抜けた失敗を別の層が捕まえる。

手法	長所	短所
自動 eval	反復が速い、完全に再現可能、ユーザーに影響しない、毎コミット実行できる、本番投入せずスケールテストできる	初期投資が要る、保守が要る、実利用とずれていると誤った安心感を生む
本番モニタリング	実際のユーザー挙動が大規模に見える、合成 eval が見逃す問題を捕まえる、ground truth になる	受け身 — 問題がユーザーに届いてから、シグナルがノイジー、計装投資が要る
A/B テスト	実際のユーザー成果を測る、交絡を制御できる、体系的	遅い（有意差まで数日〜数週間）、デプロイ済みの変更しか試せない、原因の洞察に乏しい
ユーザーフィードバック	想定外の問題が出てくる、実例が付いてくる、プロダクト目標と相関する	まばらで自己選択的、深刻な問題に偏る、理由が書かれない、自動化できない
手動 transcript レビュー	失敗モードの直感が育つ、微妙な品質問題を捕まえる	時間を食う、スケールしない、網羅性が不安定、レビュア疲労
体系的な人間研究	主観タスクを扱える最高品質の判断、model grader を改善する	高価で遅い、頻繁には回せない、評価者間の調停が要る

Automated evals are especially useful pre-launch and in CI/CD, running on each agent change and model upgrade as the first line of defense against quality problems. 自動 eval はリリース前と CI/CD で特に有用である。エージェントの変更やモデルの更新のたびに走り、品質問題に対する第一の防衛線となる。

事例

• Claude Code: Anthropic 社員と外部ユーザーのフィードバックによる高速反復から始めた。その後、簡潔さ（concision）とファイル編集という狭い領域にまず eval を足し、次に over-engineering のような複雑な振る舞いへ広げた
• Descript（動画編集）: 成功するワークフローの3軸で eval を組んだ — 「壊さない」「頼んだことをやる」「うまくやる」。手動採点から、プロダクトチームが基準を定義し人間が定期 calibration する LLM grader へ進化
• Bolt: 広く使われるエージェントができた後から eval に着手。3ヶ月で、静的解析による採点・ブラウザエージェントによるアプリテスト・指示追従などの LLM judge を備えた eval システムを構築

結論

Teams that invest early find the opposite: development accelerates as failures become test cases. 早期に投資したチームは逆の結果を得る。失敗がテストケースになることで、開発は加速する。

基本は変わらない — 早く始める、現実的なタスクを集める、曖昧さのない成功基準を定義する、grader を組み合わせる、十分な難度を確保する、S/N 比を反復改善する、そして Read the transcripts!

そのまま使える具体例

コーディングエージェントのタスク定義（全 grader 種を例示したもの）:

task:
  id: "fix-auth-bypass_1"
  desc: "Fix authentication bypass when password field is empty and ..."
  graders:
    - type: deterministic_tests
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
    - type: llm_rubric
      rubric: prompts/code_quality.md
    - type: static_analysis
      commands: [ruff, mypy, bandit]
    - type: state_check
      expect:
        security_logs: {event_type: "auth_blocked"}
    - 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 を網羅的に見せるための例。実務では正しさの検証に unit test、全体的なコード品質に LLM rubric を使い、他は必要になったときだけ足す。

会話エージェントのタスク定義:

graders:
  - 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"
  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed}
  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: process_refund, params: {amount: "<=100"}}
      - {tool: send_confirmation}
  - 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

eval フレームワーク（付録）

	内容
Harbor	コンテナ化した環境でのテスト。クラウドをまたいで trial をスケールする基盤。Terminal-Bench 2.0 が registry 経由で使える
Braintrust	オフライン評価 + 本番 observability + 実験管理。組み込み scorer の autoevals ライブラリを含む
LangSmith	トレーシング、オフライン/オンライン評価、データセット管理。LangChain エコシステムと統合
Langfuse	セルフホスト可能な OSS。データ所在地要件がある場合の選択肢
Arize	Phoenix（OSS のトレーシング・デバッグ・評価）と AX（スケールと監視の SaaS）

It’s often best to quickly pick a framework fitting your workflow, then invest energy in the evals themselves. 自分のワークフローに合うフレームワークを手早く選び、そのうえで eval そのものに労力を注ぐのが最善であることが多い。

原典で言及されている関連文書

• building-effective-agents — エージェント設計の出発点として冒頭で参照されている
• effective-harnesses-for-long-running-agents — long-running agent の harness
• claude-code-best-practices — Claude Code 側の eval 事例の背景
• https://platform.claude.com/docs/en/test-and-evaluate/develop-tests — 成功基準と eval の作り方（Platform 版）

未取得の派生リンク

• https://github.com/sierra-research/tau2-bench — τ2-bench
• https://www.swebench.com/SWE-bench/ — SWE-bench Verified
• https://www.tbench.ai/ — Terminal-Bench
• http://arxiv.org/abs/2504.12516 — BrowseComp
• https://arxiv.org/abs/2307.13854 — WebArena
• https://os-world.github.io/ — OSWorld
• https://arxiv.org/abs/2406.12045 — τ-bench（pass^k の出典）
• https://alignment.anthropic.com/2025/automated-auditing/ — alignment auditing agents