この記事は、エージェントを有用なものにしている能力、すなわち多数のターンにわたるツール呼び出しと状態変化をまたいで発揮される自律性、知性、柔軟性こそが、エージェントの評価を難しくしている能力でもあると論じる。そして、優れた評価があれば、チームは問題を本番環境で初めて見つけるのではなく、より自信を持ってエージェントをリリースできるとしている。記事が焦点を当てるのは、実際のユーザーなしに開発中に実行できる自動評価であり、Anthropic の社内での取り組みと、顧客との取り組みに基づいている。
記事はエージェント評価のための用語を定めている。定義された入力と成功基準を持つタスク、実行ごとに出力が変わるためにタスクに対して繰り返し行われる試行であるトライアル、1 つ以上のアサーションを通じてパフォーマンスのある側面を採点する採点器、トライアル内のすべてを記録したトランスクリプト（トレース、または軌跡）、環境の最終状態であるアウトカム、評価をエンドツーエンドで実行する評価ハーネス、モデルがエージェントとして行動できるようにするエージェントハーネス（またはスキャフォールド）、そして関連するタスクからなる評価スイートである。記事によれば、「エージェント」を評価するとは、ハーネスとモデルを一緒に評価することを意味する。そこから記事は採点器の種類を比較し、コーディング、会話、リサーチ、コンピュータ操作の各エージェントについて論じ、最後に実践的なロードマップを示している。
要点
- コードベースの採点器は高速、安価、客観的で再現可能だが、妥当なバリエーションに対して脆い。モデルベースの採点器は柔軟で自由形式の出力を扱えるが、非決定的であり、人間の判断に照らした較正が必要である。人間による採点器は最も信頼できる基準だが、高価で時間がかかる。
- 能力評価は低い合格率から始めて、チームに登るべき丘を与えるべきである。回帰評価は 100% 近くに位置して後退を捉えるべきであり、合格率が高くなった能力タスクは回帰スイートへ「卒業」させることができる。
- コーディングエージェントでは、SWE-Bench Verified や Terminal-Bench のように、コードが動くか、テストが通るかという決定論的なテストが自然である。トランスクリプトもあわせて採点すれば、コードの品質やエージェントのツールの使い方を評価できる。
- 会話エージェントでは、ユーザーをシミュレートするために 2 つ目の LLM が必要になることが多く、τ-bench とその後継のように、成功は多次元的（状態が解決されたか、ターン数の上限、口調）になりうる。
- リサーチエージェントの品質はタスクとの関係でしか判断できないため、記事は根拠性、網羅性、情報源の品質のチェックを組み合わせ、LLM のルーブリックを専門家の判断に照らして頻繁に較正することを提案している。
- 非決定性は、異なる問いに答える 2 つの指標で扱われる。k 回のトライアルで少なくとも 1 回成功する確率である pass@k と、k 回のトライアルがすべて成功する確率である pass^k である。
- 記事は、実際の失敗から集めた 20〜50 個の単純なタスクで早めに始めることを推奨している。初期の変更は効果が大きく、小さなサンプルでも検出できるからである。
- 良いタスクとは、2 人のドメイン専門家が独立に同じ合格／不合格の判定に至るタスクであり、参照解によって各タスクが解けることが証明される。フロンティアモデルで多数のトライアルを行っても合格率が 0% の場合、多くはタスク自体が壊れていることを示している。
- 一方に偏った最適化を避けるため、問題セットはバランスを取り、ある振る舞いが起こるべき場合と起こるべきでない場合の両方をテストすべきである。
- 各トライアルはクリーンで隔離された環境から始めるべきである。記事は、以前のトライアルで残された git の履歴を調べることで、Claude が一部の社内評価で不当な優位を得たと報告している。
- 記事は、エージェントがたどった正確な経路ではなく、エージェントが生み出したものを採点すること、部分点を組み込むこと、ルーブリックの各次元を別々の LLM ジャッジで採点すること、そして LLM-as-a-Judge に「Unknown」と答えるといった逃げ道を与えることを推奨している。
- 誰かがトランスクリプトを読むまでは、スコアを額面どおりに受け取るべきではない。採点のバグ、曖昧な仕様、ハーネスの制約によって、有能なエージェントのスコアが低くなることがある。
- 100% の評価からは改善のためのシグナルが得られない。飽和に近づくと、大きな能力向上がわずかなスコアの上昇としてしか現れないことがある。
- 記事は評価駆動開発、すなわちエージェントがまだ満たせないうちに計画中の能力のための評価を構築することを推奨し、プロダクトの要件に近い人々が評価タスクを提供できるようにすることを勧めている。
- 自動評価は、本番環境の監視、A/B テスト、ユーザーフィードバック、トランスクリプトの手動レビュー、体系的な人間による研究と並ぶ 1 つの層である。記事はこの組み合わせをスイスチーズモデルになぞらえている。このモデルでは、ある層をすり抜けた失敗が別の層で捕捉される。
背景
記事はその助言を、Anthropic 自身のチームと、同社が協業してきた顧客による実地で検証された実践として提示し、Claude Code と Claude.ai のウェブ検索を評価した Anthropic の経験によって例証するとともに、他社の評価プログラムについても簡潔に紹介している。記事中の YAML によるタスク定義は、理論上の例示であると明記されている。記事は最後に、エージェント評価は発展途上で急速に進化している分野であり、エージェントがより長く、マルチエージェントで、より主観的な仕事を担うようになるにつれて、その手法も適応していく必要があると述べる。また付録ではオープンソースおよび商用の評価フレームワークを挙げつつ、フレームワークの良し悪しはそこで実行されるタスク次第だと注意を促している。この記事は、軌跡評価 や エージェントハーネス の設計に関するこのウィキの他の資料と並ぶものである。