AIエージェントのEval設計 — Anthropicが示す採点者3類型と非決定性のpass@k / pass^k

2026年1月9日、Anthropicのエンジニアリングブログに「Demystifying evals for AI agents」が公開されました。著者はMikaela Grace氏、Jeremy Hadfield氏、Rodrigo Olivares氏、Jiri De Jonghe氏ら。エージェント評価(eval)を初めて導入するチーム向けに、採点者の選び方、エージェント種別ごとの設計、非決定性への向き合い方をAnthropic内部の運用知見も交えてまとめた長尺記事です。

本記事では、原文の主要な主張をなぞりつつ、日本語の読者が「自分のチームで評価基盤を作る」ときに迷いそうな箇所に編集視点で補足を入れていきます。

背景 — なぜ「エージェントのeval」を改めて整理する必要があるのか

LLMの単発出力を採点するeval(評価)には、すでに公開されているフレームワークが多数あります。一方で、ツール呼び出しと推論を複数ターン連ねて環境を変更していくエージェントは、評価の難度が一段上がります。原文ではこの違いを次のように表現しています。

"The capabilities that make agents useful also make them difficult to evaluate."

中間結果に応じて方針を切り替え、ファイルを書き換え、外部APIを叩き、その途中で起きたミスがその後のターンに伝播していく。最終出力だけ採点しても、なぜ失敗したのかが追えません。さらに、評価セットに書いた手順とは違うルートで正解にたどり着く「創造的解法」も普通に出てきます。原文では、Opus 4.5がτ2-benchのフライト予約タスクで規約のループホールを発見し、書かれた評価上は失敗扱いだが利用者には有利な解を出した、という事例が紹介されています。

このため、ターン単位のtranscript(対話ログ)をどう保存し、どんな採点者を組み合わせ、何回のtrial(試行)でスコアを安定させるか、という運用設計が評価の中心になります。本記事はその設計判断を解像度高く言語化したものです。

関連して、Anthropicは2025年からエージェント向けツール設計の原則、Context Engineering論、Agent Skillsと、エージェント運用の各レイヤーの記事を順次公開しています。今回のevals記事は、それらで作ったエージェントを「測る」レイヤーに当たります。

評価の構成要素 — task / trial / grader / transcriptを最初に揃える

Anthropicは記事冒頭で、用語を以下のように定義しています。eval基盤を作るチームでは、社内ドキュメントもこの定義に揃えると、外部資料との行き来がしやすくなります。

これらは独立しており、harness(eval実行基盤)とagent harness(エージェント本体の足回り)が別概念であることに注意が必要です。harnessを変えればtrialの安定性が変わり、agent harnessを変えればエージェント自体の能力が変わるため、片方だけを動かして比較する規律が要ります。

採点者の3類型 — code-based / model-based / humanの使いどころ

evalを設計するときに最初に決めるのが、誰が採点するかです。Anthropicは大きく3類型に分けています。

実装の出発点は、まずcode-basedで決定論的に計れるところを最大化し、code-basedでは捉えられない品質指標(語調、説明の妥当性、コードの可読性など)に限ってmodel-basedを足す、という順序になります。humanは「LLM採点者を校正する基準」として位置づけ、定期的にサンプリングする運用が現実的です。

Capability EvalとRegression Evalは別物として扱う

原文で繰り返し強調されているのが、評価の目的を明確に分ける考え方です。

両者を1つのスイートに混ぜると、「全体パス率」を追いかけ始めて両方の信号を失います。Capabilityは「まだ解けないタスクを集めた峠」、Regressionは「すでに通れる道に置く番犬」と分けて運用するのが自然です。

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

原文ではエージェントを4種に分けて、それぞれの評価のコツを示しています。日本語の読者が自分のユースケースを当てはめやすいよう、要点と適合するベンチマークを並べます。

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

決定論的な採点が最も自然な領域です。コードはテストを走らせて成功 / 失敗を取れるため、code-based grader中心で設計できます。

ベンチマークの代表例は以下の2つで、いずれも1年単位でモデルのスコアが大きく動いている領域です。

• SWE-bench Verified: GitHub issueを与え、テストスイートで検証。1年で40% 超から80% 超へ進化
• Terminal-Bench: Linuxカーネルビルドや機械学習モデルの学習など、エンドツーエンドのターミナル操作タスク

原文には、決定論的テスト + LLMルーブリック + 静的解析(ruff / mypy / bandit) + 状態検証を組み合わせたYAML定義の例が示されています。「テストが通る」だけでなく、コード品質や監査ログの状態まで多面で見るのが要点です。

会話型エージェント

サポートチャットや旅行予約のように、対話そのものの品質が評価対象になる領域です。マルチターンを再現するために、利用者役を演じる別のLLMを立てる構成が一般的になっています。

代表ベンチマークはτ-Bench / τ2-Bench(小売サポート、航空会社予約)。原文の例では、共感の有無、解決の説明、ツール結果に基づく根拠付けの3点を、LLMルーブリック + 状態検証 + transcript検査で組み合わせて見ています。

リサーチエージェント

主観性が高く、「網羅的」「十分に根拠付けられた」の判定基準が文脈依存です。専門家でも見解が分かれます。Anthropicは複数の採点軸を組み合わせる戦略を推奨しています。

• groundedness check(主張は取得ソースに支持されているか)
• coverage check(良い回答に必須の鍵となる事実が含まれているか)
• source quality check(権威あるソースを使っているか)

代表ベンチマークはBrowseCompで、オープンウェブ上の「針を探す」型の質問が題材です。

コンピュータ操作エージェント

スクリーンショット、マウス、キーボード、スクロールでGUIを操作する領域です。実環境または仮想環境で動かす必要があり、harnessの安定性が評価結果に直結します。

代表ベンチマークはWebArena(URLとページ状態で検証)とOSWorld(ファイルシステム / アプリ設定 / DB / UI要素で検証)。トークン効率と遅延のバランス、たとえばDOMを抽出して読ませるかスクリーンショットだけを使うか、という設計判断が成績に効いてきます。

非決定性をどう測るか — pass@kとpass^kの使い分け

エージェントは同じ入力でも実行ごとに揺れます。これを単一スコアに落とすために、Anthropicは2つの指標を並べて使うことを勧めています。

k=1ではどちらも同じ値ですが、k=10で同じエージェントを測ると、pass@kは100% 近くに張り付き、pass^kは0% 近くに落ちることがある。この差が「平均的にはうまくいくが、たまにこける」エージェントを可視化します。

実務的には、検索や分析のように利用者がリトライできるユースケースではpass@k寄り、決済処理やチケット起票のように1回で確実性が求められる場面ではpass^k寄り、と読者側のリスク許容度に合わせる選択肢があります。

ゼロから1のロードマップ — Anthropicが提示する8ステップ

原文で示されている実装ロードマップを、要点を残しつつ日本語で再構成します。

ステップ0: いま始める

最初は20〜50タスクで十分とされています。「実際に起きた失敗」をそのままタスクに変換するのが最速で、効果サイズも初期は大きいので小規模サンプルで信号が出ます。後から始めようとすると、稼働中のシステムをリバースエンジニアリングして仕様を起こす作業が発生します。

ステップ1: 既存の手動テストから種を取る

リリース前に手で確認している動作、バグレポート、サポート問い合わせを優先順位付けします。属人化しているチェックリストの言語化からで構いません。

ステップ2: 曖昧さのないタスクに整える

「2人の専門家が独立に同じpass / fail判定にたどり着けるか」が判定基準です。実行可能性も併せて検証し、参照ソリューションを書いて証明します。

ステップ3: バランスの取れたテストセット

「動作すべきケース」と「動作すべきでないケース」を両方入れます。クラス不均衡(例: 検索が必要なクエリばかり集める)は採点を歪めます。

ステップ4: 安定したharnessと環境

"Each trial should start from a clean state."

trial間でファイルやキャッシュを共有させると、相関した失敗が起きて結果が読めなくなります。harness由来のflakyな失敗は、モデルの能力評価を直接汚染します。

ステップ5: 採点者の設計

decision treeとしては、まずcode-basedで決定論的に判定できるかを確認し、できないところでLLM採点を足す。原文でとくに重要なのは「特定のステップ順序を強制しない」という指針です。

エージェントが想定外の創意工夫で正解に到達したとき、それを誤判定する採点者は能力を抑えてしまう。

部分点(partial credit)の設計も推奨されています。サポートエージェントが問題特定と利用者検証はできたが返金処理に失敗した場合、完全失敗ではなく部分点で記録するほうが、改善の手がかりが残ります。LLM採点者は人間採点者と定期的に校正する前提で運用します。

ステップ6: transcriptを読む

"Reading transcripts is how you verify that your eval is measuring what actually matters."

採点ロジックを盲信せず、生のtranscriptを多数読みます。原文ではCORE-Benchでフロンティアモデル(Opus 4.5)が42% から、採点とタスクを修正したら95% に跳ねた事例が引かれています。原因は厳格すぎる採点、曖昧なタスク、再現不能なタスクの混入。スコアが低いとき、まずモデルを疑う前にevalを疑う規律が要ります。

ステップ7: capability evalの飽和を監視する

100% パス率になった時点で、そのスイートからは改善のシグナルが取れなくなります。SWE-Bench Verifiedも30% から80% 超へ進化し、現在は飽和帯に近づいています。コードレビュー企業のQodoでは、初期evalがOpus 4.5の差分を捉えられず、新しいワンショット評価を追加して初めて改善が見える形になった、と紹介されています。

ステップ8: スイートの長期メンテナンス

evals専任チームが基盤を持ち、ドメイン専門家とプロダクトチームが寄稿していく形が望ましいとされています。ユニットテストと同じ感覚で、明確な所有権とオープンな貢献経路を作ります。

Anthropic内部での運用 — Claude Code、Descript、Boltの事例

原文では、評価をどの段階から導入したかについて、3社の対比が紹介されています。

• Claude Code(Anthropic): 初期はAnthropic従業員と外部ユーザーのフィードバックで高速反復。後にevalを追加し、簡潔さやファイル編集などの軸を入れ、過剰なエンジニアリングを抑える指標まで広がった。本番監視 / A/Bテスト / ユーザーリサーチと併用
• Descript(ビデオ編集エージェント): 「壊さない / 要求通りにする / 良くする」の3軸で評価。手動採点 → プロダクトチームが定義し人間で校正するLLM採点 → 品質ベンチマークとリグレッションの2スイート、と段階進化
• Bolt: スケール後に遅れてevalを導入。3か月で構築し、静的解析 / ブラウザエージェントによるアプリテスト / 命令従順性などのLLMジャッジを組み合わせた

3社に共通するのは、最初から完璧な評価基盤を作ろうとしていない点です。実際の失敗をテストに変換し、回数を重ねるなかでスイートを成長させています。

evalだけに頼らない — Swiss Cheese Modelとしての品質保証

Anthropicは、自動evalをひとつの層と位置づけ、複数層の重なりで品質を担保するSwiss Cheese Model(スイスチーズモデル)を提示しています。

どの層も単体では万能ではなく、組み合わせで初めてカバレッジを得る、という整理です。これは、日本語の現場でも「LLM採点だけ高い」「本番ログを見ていない」のような偏りが起きやすいので、層の存在を可視化するチェックリストとして使えます。

evalフレームワーク選定の早見表

原文の付録(Appendix: Eval frameworks)で挙げられている主なツールを、選定の起点として並べます。原文では「フレームワーク選定は速く決め、投資は質の高いタスクと採点者に集中させる」という方針が示されています。

Anthropic自身のスタックでは、エージェントを動かす足回りとしてClaude CodeとAgent SDKが想定されており、長時間実行エージェントではAgent SDKのprimitivesを使う、と原文に明記されています。eval側のフレームワークと組み合わせるとき、エージェントharnessとeval harnessは別物として配線するのが原則です。

「evalは検査ではなく組織の意思疎通である」と読み替える視点

原文を通読して印象的なのは、evalを技術的な検査ツールというよりも、組織内の暗黙の期待値をすり合わせる装置として扱っている点です。原文の以下の引用がそれを端的に表しています。

"Two engineers reading the same initial spec could come away with different interpretations on how the AI should handle edge cases. An eval suite resolves this ambiguity."

「このエッジケースで何を返すべきか」という暗黙の期待は、自然言語で書かれた仕様だけだと人によって解釈が割れます。eval suiteはその解釈の差を、pass / failという二値で固着させます。これが組織にとっての副次効果になります。

"The people closest to product requirements and users are best positioned to define success."

成功条件を定義できるのは、利用者と要求に最も近い人です。evalsチームが基盤を作り、ドメイン専門家とプロダクトチームがtaskを書き寄せる、というAnthropicの運用は、この前提から逆算されています。日本語の現場で「とりあえずQAチームに丸投げする」「PMが見ているがエンジニアは見ていない」のような分担になっているなら、原文のメッセージは「定義の場をプロダクトの中心に戻す」ことを促していると読めます。

evalがあると、失敗は再現可能なtaskに変わります。

"Teams that invest early find the opposite: development accelerates as failures become test cases."

逆に投資しないチームは、失敗が反応的なループに溜まり続けます。本番で問題が出る → 直す → 別のところで再発する、という回り方です。evalはこれを断ち切るための、最も基本的な梯子になります。

まとめ

• エージェント評価は単発LLM評価と別物。ツール呼び出しと環境変更が複数ターン連なるため、transcript / outcome / harnessの語彙を最初に揃えるのが出発点
• 採点者はcode-based / model-based / humanの3類型。decision treeはcode-basedを最大化し、必要箇所だけLLM採点を足し、humanで校正する順序が現実的
• capabilityとregressionは別スイートに分ける。前者は低いパス率から始めて伸ばす、後者は100% を死守する
• 非決定性はpass@kとpass^kの2軸で見ると、利用者リスクとの対応が取りやすい
• 完璧を待たずに20〜50タスクで始め、transcriptを読み、飽和したらタスクを更新する、という運用が原文の繰り返しメッセージ
• evalは検査ツールであると同時に、組織内で「成功」の定義をすり合わせる装置として機能する

エージェント評価はまだ黎明期で、マルチエージェント構成、長時間タスク、主観的業務への対応に応じて手法も進化を続けると原文は締めています。日本語の現場で評価基盤を立ち上げるときも、最初の20タスクから始めて、transcriptを読みながらスイートを育てていく、という入り口は変わりません。