Anthropic AIエージェントの評価を解明 – ベストプラクティスとロードマップ

TL;DR

Anthropicは、AIエージェントの自動評価を設計するための詳細なフレームワークを公開し、厳格な評価が信頼性の高いリリースに不可欠である理由を示し、タスク収集から長期的なメンテナンスまでの実用的なロードマップを提供しています。

評価とは何か？

評価（eval） とは、AIシステムに入力を与え、その出力に採点ロジックを適用するテストです。Anthropicは、開発中に人間のユーザーなしで実行される自動評価に焦点を当てています。

シングルターン評価: 1つのプロンプト、1つの応答、シンプルな採点者。
マルチターン評価: ツール呼び出し、状態変化、一連の推論ステップを含みます。
エージェント評価: マルチターンのインタラクション、環境の変化、そしてしばしば静的な期待を超える創造的なモデル動作を組み合わせます。

主要な用語

用語	意味
タスク / 問題	定義された入力と成功基準を持つ単一のテストケース。
トライアル	タスクへの1回の試行。複数のトライアルでランダム性を捉えます。
採点者（グレーダー）	パフォーマンスの側面を採点するロジック。複数のチェックを含む場合があります。
トランスクリプト / トレース	すべてのメッセージ、ツール呼び出し、中間結果を含む、トライアルの完全な記録。
結果	環境の最終状態（例：データベースに予約が存在する）。
評価ハーネス	タスクを実行し、ステップを記録し、出力を採点し、結果を集計するインフラストラクチャ。
エージェントハーネス / スキャフォールド	モデルがエージェントとして動作できるようにするシステム（ツール呼び出しを調整）。
評価スイート	特定の能力を対象としたタスクの集合（例：カスタマーサポートシナリオ）。

評価が重要な理由

初期段階のエージェントは手動でテストできますが、本番環境に入るとチームはリグレッションの可視性を失います。
評価がなければ、デバッグは反応的になります。ユーザーの苦情を待ち、手動で再現し、修正し、他に壊れたものがないことを願うだけです。
評価はベースラインメトリクス、リグレッションガード、およびプロダクトとリサーチ間のコミュニケーションチャネルを提供します。
評価パイプラインを持つ企業は、強みを迅速に測定し、プロンプトを調整し、安全性を検証できるため、新しいモデルを数週間ではなく数日で採用できます。

採点者の種類

コードベースの採点者 – 決定的なチェック（例：ユニットテスト、静的解析）。コーディングエージェントに最適です。
モデルベースの採点者 – 構造化されたルーブリックを使用して判断するLLM。トーンや推論の質などの主観的な側面に有用です。
人間の採点者 – モデル判定の定期的な較正やエッジケースの検証に使用。

採点者のスコアは、タスクに応じて重み付け、バイナリ、またはハイブリッドで組み合わせることができます。

能力評価と回帰評価

能力評価は、低い合格率を対象として弱点を浮き彫りにし、改善を導きます。
回帰評価は、意図しない破損を検出するためにほぼ100%の合格率を目指します。
時間が経つにつれて、エージェントがタスクを確実に解決できるようになると、能力評価スイートは回帰評価スイートに昇格できます。

エージェントタイプ別の評価手法

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

明確に定義されたタスクと安定したテスト環境を使用します。
決定的な採点者（ユニットテスト）が主であり、例：SWE-bench Verified や Terminal-Bench。
ツール使用パターンやコード品質のヒューリスティックについては、トランスクリプト採点者で補完します。

会話エージェント

成果（例：チケット解決）と対話品質（トーン、ターン数）の両方を測定します。
多くの場合、ユーザーをシミュレートするために2つ目のLLMが必要です。
τ‑Bench や τ2‑Bench などのベンチマークは、マルチターンで敵対的な対話を評価します。

リサーチエージェント

根拠チェック、網羅性チェック、ソース品質チェックを組み合わせます。
「正しさ」は主観的なことが多いため、専門家の人間に対して校正されたLLMルーブリックを使用します。
ベンチマーク例：BrowseComp（オープンウェブ上の針を干し草の山から見つける）。

コンピューター使用エージェント

サンドボックス化されたGUI（ブラウザ、OS）でエージェントを実行し、最終状態（ファイル、DBエントリ、UI要素）を検証します。
ベンチマーク：WebArena（ブラウザタスク）およびOSWorld（OS全体の制御）。
ツール選択の効率を評価：DOM抽出 vs スクリーンショットベースの操作。

非決定性への対応

pass@k – k回の試行のうち少なくとも1回成功する確率。単一の成功で十分な場合に有用。
pass^k – k回すべての試行が成功する確率。一貫性重視の製品に重要。
両方の指標を報告すべきであり、選択は、時折の成功でよいか、保証された信頼性が必要かによって決まります。

ゼロから信頼できる評価へのロードマップ

ステップ	アクション	重要な洞察
0	実際の障害事例20〜50件から早期に開始する。	エージェントが頻繁に変更される場合、小さなサンプルでも高いシグナルが得られます。
1	既存の手動チェックやバグトラッカーの項目をタスクに変換する。	評価が実際のユーザー影響を反映することを保証します。
2	曖昧さのないタスク仕様と参照解を作成する。	2人の専門家が合格/不合格に同意できるべきです。曖昧な仕様はノイズの多いメトリクスを引き起こします。
3	ポジティブケースとネガティブケースのバランスを取り、一方的な最適化を避ける。	過剰トリガーや過少トリガー（例：不要な検索）を防ぎます。
4	安定した隔離された評価ハーネスを構築する（各トライアルでクリーンな環境）。	インフラのノイズを除去し、以前の状態による不当なアドバンテージを防ぎます。
5	まず決定的な採点者を選び、必要な場所でLLM採点者を追加し、時折の人間によるレビューで較正する。	厳格なステップバイステップの採点は創造的な解決策を罰するため、結果を採点し、経路は採点しない。
6	トランスクリプトを定期的に検査して、採点者の公平性を検証し、隠れたバグを検出する。	トランスクリプトのレビューは、評価が意図した行動を測定していることを確認する主要な方法です。
7	評価の飽和（スコアが100%に近い）に注意。飽和が発生したら、より難しいタスクや新しい次元を導入する。
8	専任の評価チームとプロダクトオーナーからの貢献を通じてスイートを維持し、スイートを単体テストライブラリのように扱う。

評価を他の品質シグナルと統合する

自動評価 – コード/モデル変更のたびにCI/CDで実行。
本番モニタリング – 分布ドリフトと実世界の障害を検出。
A/Bテスト – トラフィック量が許せば、重要な変更を検証。
ユーザーフィードバックとトランスクリプトサンプリング – 新しい障害モードを継続的に表面化。
体系的な人間による研究 – LLMジャッジを較正し、非常に主観的な出力を評価。

これらのレイヤーが一体となってスイスチーズモデルの安全性を形成します。それぞれが、他のレイヤーが見逃す可能性のある問題を捕捉します。

オープンソースおよび商用の評価フレームワーク

フレームワーク	強み
Harbor	コンテナ化されたエージェント実行、ベンチマークレジストリ（例：Terminal‑Bench 2.0）。
Braintrust	オフライン評価と本番環境の可観測性を組み合わせ、`autoevals`ライブラリを含む。
LangSmith / Langfuse	LangChainとの緊密な統合、トレーシング、データセット管理。Langfuseはセルフホスト型。
Arize Phoenix / AX	オープンソースのトレーシングとデバッグ。AXはSaaSスケーリングとモニタリングを追加。

スタックに合ったフレームワークを選び、高品質なタスクとグレーダーの構築に注力しましょう。

要点

厳格で自動化された評価は、信頼性の高いAIエージェント開発の基盤です。明確なタスクを定義し、決定的かつ校正されたグレーダーを使用し、能力と回帰の両方を測定し、スイートを長期間維持することで、チームはエージェントをより迅速にリリースし、自信を持って新しいモデルを採用し、コストのかかる反応的なデバッグサイクルを回避できます。

まとめ

Anthropicは、AIエージェント向けの自動評価の構築、実行、維持に関する包括的なガイドを発表し、定義、グレーダーの種類、メトリクス、ステップバイステップのロードマップを概説しました。