Anthropicは2026年1月9日(米国時間)、AIエージェント向けの評価(eval)を設計・運用するための実践手法をまとめた技術記事を公開しました。自律性・知能・柔軟性というエージェントを有用にする性質そのものが評価を難しくすると指摘し、社内開発や顧客との協業で得た知見をもとに、評価の構成要素、グレーダーの種類と使い分け、エージェントの類型別の評価手法、そして評価をゼロから構築する8ステップのロードマップを整理しています。

評価の構成要素

• ▸タスク — 入力と成功基準を定義した個々のテスト。各試行はトライアルと呼び、出力のばらつきに備えて複数回実行する
• ▸グレーダー — エージェントの性能の一側面を採点するロジック。1つのタスクに複数持てる
• ▸トランスクリプト — 出力・ツール呼び出し・推論・中間結果を含む試行の完全な記録
• ▸アウトカム — 試行終了時の環境の最終状態。予約完了の発言ではなく、予約がデータベースに存在するかで判定する
• ▸ハーネス — 評価ハーネスは評価を端から端まで実行する基盤。エージェントハーネスはモデルをエージェントとして動かす仕組みで、評価対象は両者の組み合わせになる

単一ターンの評価はプロンプト・応答・採点ロジックで完結しますが、エージェントは多数のターンにわたりツールを使って環境の状態を変えるため、誤りが伝播・複合します。Opus 4.5がτ2-benchの航空券予約問題でポリシーの抜け道を見つけ、評価上は不合格ながらユーザーにはより良い解決策を出した例のように、静的な評価の想定を超える創造的な解決も起きるとしています。

評価を作る意義

評価が無いと、ユーザーの苦情を待って手作業で再現・修正する事後対応に陥り、本物の劣化とノイズを区別できなくなると指摘します。Claude Codeも当初はフィードバックに基づく高速な反復で開発され、後から簡潔さやファイル編集といった狭い領域の評価を加え、過剰設計のような複雑な挙動の評価へ広げていきました。動画編集エージェントを3つの観点で評価するDescriptや、運用開始後3ヶ月で評価システムを構築したBoltの事例も紹介しています。評価は製品チームと研究チームをつなぐ帯域の広い伝達手段になり、新しいモデルが出た際に数日で強みを見極めて乗り換えることも可能にするとしています。

グレーダーの3類型と評価の2区分

• ▸コードベース — 文字列一致・テスト・静的解析など。高速・安価・客観的だが、想定パターン外の正解に脆く、主観的なタスクには不向き
• ▸モデルベース — ルーブリック採点・自然言語の検証など。柔軟でニュアンスを捉えるが非決定的で、人間の採点との較正が必要
• ▸人間 — 専門家レビューやA/Bテストなど。品質の基準になるが高価で遅い
• ▸能力評価と回帰評価 — 能力評価は低い合格率から始めて改善の目標にする。回帰評価はほぼ100%の合格率を保って劣化を検知する

能力評価は最適化が進んで合格率が高まると、継続的に実行する回帰スイートへ卒業させる運用を紹介しています。

エージェント類型別の評価手法

• ▸コーディング — テストの合否で決定的に採点しやすい。SWE-bench Verifiedのスコアは1年で40%から80%超に到達。コード品質のルーブリックなどトランスクリプトの採点を併用するのも有効
• ▸対話型 — 対話の質自体が評価対象で、ユーザー役を別のLLMが演じることが多い。チケット解決の状態確認・ターン数の制約・トーンのルーブリックなど多次元で測る。τ-Benchとτ2-Benchが代表例
• ▸リサーチ — 主張が情報源に裏付けられているかの確認、必須事実の網羅性の確認、情報源の質の確認を組み合わせる。LLMルーブリックは専門家の判断で頻繁に較正する
• ▸コンピュータ操作 — 実環境やサンドボックスで実行し、WebArenaはURLやページ状態とバックエンドの状態を、OSWorldはファイルや設定など多様な成果物を検証する

非決定性の扱い

• ▸pass@k — k回の試行のうち少なくとも1回成功する確率。1回の成功が意味を持つ場面に向く
• ▸pass^k — k回の試行がすべて成功する確率。試行あたり成功率75%でも3回連続では約42%に下がり、毎回の信頼性が求められる顧客向けエージェントで重要

エージェントの挙動は実行ごとに変わるため、タスクごとの成功率をどの指標で捉えるかを製品要件に応じて選ぶべきだとしています。

ゼロから構築する8ステップのロードマップ

• ▸ステップ0〜1 — 早く始める。実際の失敗から集めた20〜50件の簡単なタスクで十分で、リリース前に手動確認している項目やバグトラッカーが出発点になる
• ▸ステップ2〜3 — 専門家2人が同じ合否判定に至る曖昧さのないタスクを書き、全グレーダーを通過する参照解を用意する。挙動が起きるべき場合と起きるべきでない場合の両方を含む均衡の取れた問題集にする
• ▸ステップ4〜5 — 毎回クリーンな環境から始まる安定したハーネスを作る。グレーダーは可能な限り決定的なものを選び、経路ではなく成果物を採点し、部分点も設計する
• ▸ステップ6〜8 — トランスクリプトを読んで採点の妥当性を確かめ、合格率100%に近づく飽和を監視し、評価スイートをユニットテストと同様に継続的に保守する

落とし穴の例として、Opus 4.5のCORE-Benchのスコアが、厳格すぎる採点や曖昧なタスク仕様などの問題の修正後に42%から95%へ跳ね上がった件を挙げ、誰かが中身を精査しトランスクリプトを読むまでスコアを額面通りに受け取らない方針を紹介しています。また自動評価は手法の1つにすぎず、本番モニタリング、A/Bテスト、ユーザーフィードバック、手動のトランスクリプトレビュー、体系的な人間の評価と組み合わせて全体像を得るべきだとし、付録ではHarbor、Braintrust、LangSmith、Langfuse、ArizeのPhoenixといった評価フレームワークにも触れています。