Anthropic、信頼できる AI エージェント評価の構築に関する知見を公開
本文の状態
日本語全文を表示中
詳細モードで約26分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Arize AI Blog
Anthropic の技術スタッフが、AI エージェント評価においてスコア上昇が実力向上ではなくテスト環境の欠陥や偶然によるものではないかを確認する重要性を指摘し、信頼できる評価構築の指針を示した。
AI深層分析を開く2026年8月4日 08:25
AI深層分析
キーポイント
スコアの誤解と真因の特定
モデルの性能向上と見えた事例が、実際には SQL クエリに LIMIT 句を追加する癖によるテスト環境の欠陥回避であり、評価ハッチを修正すると改善が消滅した。
エージェント評価の複雑性
エージェントは単一の関数ではなく、意思決定の連鎖や外部ツールとの相互作用を含む軌道上で動作するため、最終結果だけでなくプロセス全体を検証する必要がある。
信頼できる評価の要件
モデル変更、プロンプト調整、ツールの不具合、あるいは偶然の好運など、スコア変動の原因を特定できなければ評価は意味を持たない。
エラーの連鎖と環境の不確実性
初期の誤りがその後のすべての行動に影響を与え、外部システムの変化により再現が困難になる。
回帰評価と機能拡張評価の違い
前者は既知の動作が破損していないか検証し、後者はエージェントの能力範囲や未開拓領域を測定する。
重要な引用
The newer model had developed a habit of adding LIMIT clauses to its SQL queries.
Once Buleandra repaired the harness, much of the apparent improvement disappeared.
A passing result can emerge from durable capability, a flawed test, or a fortunate accident.
An incorrect assumption or malformed tool call near the beginning can influence every action that follows.
編集コメントを表示
編集コメント
この記事は、AI エージェントの性能評価において「スコア」だけでなく「なぜその結果が出たか」という因果関係を追跡する重要性を説いている。開発現場では数値の向上に喜ぶ傾向があるが、本稿はその背後にある潜在的な欠陥を見逃さないよう警告している。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Anthropic の技術スタッフであるマリアス・ブーレアンダ氏が、Arize Observe で「信頼できるエージェント評価」の構築について講演した内容を基に、本稿ではその要点を解説します。
マリアス・ブーレアンダ氏が、AI データアナリスト向けの評価で最新モデルを試した際、前世代モデルより 9 ポイントも高いスコアが出ました。この改善幅は十分大きく、意味のある能力向上の証拠として Anthropic の研究チームに共有できるほどでした。
しかし、結果を送信する前にブーレアンダ氏はログを確認しました。すると、その「勝利」が崩れ始めるのです。最新モデルには SQL クエリに LIMIT 句を追加する癖がついていました。
通常なら、クエリの規模を管理するための正当な手段です。しかし、この特定の評価環境では、ハネス（評価枠組み）の欠陥を回避するためにその癖が使われていたのです。ブーレアンダ氏がハネスを修正すると、見かけ上の改善はほとんど消えてしまいました。スコアは確かに差を検知しましたが、その原因を誤って特定していたのです。
ブーレアンダ氏は Anthropic の Applied AI チームに所属しています。このチームは製品研究と顧客の間に位置し、各チームがエージェントや評価、ハネスを改善するのを支援しています。この立場から彼は、ソフトウェア開発者にとって次第に身近な問題を目撃してきました。「エージェントベンチマークは正確な数値を生み出す一方で、複雑な因果関係を隠してしまう」という問題です。
モデル、プロンプト、ツール、グラダー（評価者）、あるいは環境のいずれかが変更された可能性があります。システムがたまたま有利な経路をたどった結果、スコアが上がっただけかもしれません。信頼できるエージェント評価には、どの説明が証拠に合致するかを見極めることが不可欠です。
AI エージェントの評価とは何か？
AI エージェント評価（agent evals）は、エージェントがタスクを成功裏に完了できるか、その結果に至るプロセスはどうなっているか、そして周囲のシステムが変化しても行動が信頼できるかを測定するための構造化されたテストです。
従来のユニットテストは、既知の入力と検証可能な出力を持つ限定された関数の評価を行います。ここでいう「限定された関数」とは、外部の状態や蓄積された履歴、中間的な意思決定に依存せず、定義された入力に対して定義された出力を返すように動作が完結しており予測可能であるような関数を指します。
一方、エージェントの行動は時系列（トラジェクトリ）に沿って展開されます。要求を理解し、アクションを選択し、ツールを呼び出し、結果を読み取り、計画を見直し、蓄積された履歴を次の意思決定に引き継ぐのです。つまり、エージェントの評価では複数の層を同時に検証する必要があります。
- 最終的な成果物
- 意思決定とツールの呼び出しの順序
- モデルおよびシステムプロンプト（指示）
- エージェントハーンネス（評価用フレームワーク）
- 外部ツールやサービスの状態
- 成功の可否を判定するグラダー（採点者）
合格した結果は、確かな能力によるものでもあれば、テスト自体の不備によるもの、あるいは単なる偶然の結果である可能性もあります。有用な評価とは、これらを見分けるための十分な証拠を提供できるものでなければなりません。
なぜ AI エージェントの評価はそれほど難しいのか？
AI エージェントの評価が難しいのは、その行動が時間経過とともに展開されること、指示が不十分な場合が多いこと、そしてユーザーがほぼ何でも要求できるインターフェースを備えているからです。
特に測定が困難な行動を生み出す 3 つの特徴があります：
エラーは経路全体で蓄積します。初期段階での誤った推測や不正なツール呼び出しが、その後のすべての行動に影響を及ぼす可能性があります。過去の観測情報がコンテキストに残っているため、小さなミスがエージェントのタスクに対する作業モデルの一部として定着してしまうのです。
タスクは不完全な状態で提示されることがほとんどです。ユーザーは成功の完全な定義を提供するよりも、テキストボックスに一文を入力し、システムに対して目標・制約・トレードオフ・停止条件を推測させることを期待します。
オープンエンドなインターフェースが「未知の未知」を生み出します。汎用的な入力フィールドは、プロダクトチームが想定していなかったリクエスト、あるいはエージェントが安全かつ確実に完了できないタスクさえも招きかねません。
これらの問題は、エージェントが長時間稼働するほど深刻化します。数時間にわたる実行経路には数百の意思決定が含まれており、そのいずれかが残りの処理を方向転換させる可能性があります。
周囲の環境は不確実性の新たな源泉となります。エージェントはデータベースやコードリポジトリ、Slack ワークスペース、チケット管理システム、CI パイプライン、サードパーティ製 API などにアクセスします。これらのシステムは独立して変化するため、成功または失敗の原因となった正確な条件を再現することが困難になります。
この作業を避ける代償は甚大です。評価（evals）がなければ、回帰現象（regressions）はユーザーが遭遇するまで隠れたままになり、モデルのアップグレードもチームがバージョン間を比較できる信頼できる手段を持たないため、遅々として進まず主観的なものになってしまいます。また、新機能が追加されても、製品がついにその機能をサポートできるようになったことに誰も気づかないという事態も起こり得ます。
あるアップグレード後、エージェントの全体的な挙動は似ているように感じられても、特定の価値のあるタスククラスにおいては劇的に改善されている可能性があります。能力評価（capability evals）こそが、こうした改善を可視化する場所となります。
回帰評価と能力評価の違いとは？
回帰評価は、以前動作していた機能が引き続き正しく動作しているかを検証するものです。一方、能力評価はエージェントの能力がどこまで拡張できるかを測定します。
生産環境チームには両方が必要です。なぜなら、これらは異なるエンジニアリング上の意思決定や製品戦略を支えるからです。
- 次元：回帰評価 (Regression evals) / 能力評価 (Capability evals)
- 主要な問い：この変更は既知の動作を壊したか？ / エージェントは今、何を実現できるか？
- 主な目的：修正済みの不具合が再発するのを防ぐ / 新しい能力と、まだ伸びしろがある領域を明らかにする
- 期待されるパフォーマンス：飽和状態に近づく高い合格率 / 改善の余地を残した挑戦的なベースライン
- 典型的なデータソース：カスタマーインシデント、報告された不具合、修正済みのバグ / フロンティアワークフロー、ベンチマークから着想を得たタスク、ストレステストケース
- 更新タイミング：プロダクト、評価ハーン（harness）、またはユーザー分布が変化した時 / モデル、ツール、あるいはエージェントの範囲が向上した時
| 支援する意思決定 | このリリースは安全か？ | 私たちは次に何を構築すべきか？
多くのチームは、まず回帰テストケースから始めます。その理由は、元となる素材がすでに存在しているからです。顧客が不具合を報告し、エンジニアリングチームが修正を加え、その事例がテストスイートに組み込まれます。これにより、同じ問題が静かに再発するのを防ぎます。
成熟した回帰テストスイートは、高い合格率を達成しているはずです。ユーザーの行動やプロンプト、ツール、外部システムの変化に伴いメンテナンスが必要になることもありますが、その中核的な目的は安定しています。それは、製品がすでに依存している機能を保護することです。
能力評価（Capability evals）は最前線にあります。Buleandra 氏はこのプロセスを「登山」に例えています。チームはエージェントが部分的にしか完了できないタスクから始め、モデルやプロンプト、ツール、あるいはハネスを変更して、最前線が前進したかどうかを測定します。
これらの評価は、モデルの選択以上に製品戦略に影響を与えます。失敗したツールの呼び出しからの回復能力が高まったり、長いワークフロー全体で一貫性を保ったり、曖昧な指示を解釈できるようになったりすれば、以前は常時人の監視が必要だった機能を解放できる可能性があります。
最も優れたエージェントチームは、能力評価に多大な投資を行います。その理由は、結果が単にリリースの安全性を示すだけではないからです。それは、製品が今後どのような姿になる可能性があるのかを教えてくれるのです。
AI エージェントの評価データセットをどのように構築すればよいのでしょうか？
有用なエージェント評価データセットとは、確立されたベンチマークの構造と、実際の生産環境での振る舞いの実質的な内容を組み合わせたものです。
最初のケースは、100 番目のケースよりも難しく感じるものです。なぜなら、タスクの形式やデータソース、成功基準、環境、そして評価者といったすべての決定が未確定のままだからです。
Buleandra のアドバイスは実用的です。「評価の形をそのまま真似すればいいのです」。
機能するデータパイプラインは以下のようになります。
まず、関連するパブリックベンチマークを調査します。タスクの枠組みや入力サンプルの作り方、成功基準の定義、証拠の収集方法、そして結果の評価方法を詳しく見てみましょう。
次に、実際の行動を捉えるために生産環境のログを掘り起こします。報告されたインシデントから始め、その後、誰もレビューしていない大規模なトランスクリプトアーカイブを分析します。
専門家がラベル付けした小規模な参照セットを作成します。深いドメイン知識を持つ人々に、成功する行動や許容される代替案、そして意味のある失敗モードを特定してもらいます。
そのラベルに対して、能力の高いモデルでキャリブレーションを行います。モデルの判断が専門家による参照セットと一致したら、そのモデルを使って大規模なデータセット全体にラベリングプロセスを広げます。
システムが変化するたびにこのパイプラインを繰り返します。データのドリフトやモデルのアップグレード、新ツールの導入、そして変化するユーザー行動に対応するために、定期的に生産環境のログを見直しましょう。
パブリックベンチマークは出発点となる構造を提供します。コーディングエージェントを構築するチームならリポジトリレベルのソフトウェアエンジニアリングベンチマークを研究し、運用エージェントを構築するチームならステートフルなツールや多段階のリカバリを含むタスクを検討するのが良いでしょう。
ベンチマークの形は、具体的なケースよりも転用しやすいものです。開発者はタスク形式や証拠要件、評価ロジックを借用し、自社の製品に合わせた事例に置き換えることができます。その素材となるのは、実際の運用で蓄積された会話ログです。
顧客からの苦情は分かりやすい出発点ですが、報告されるほど目立つ失敗しか捉えられていないことが多いです。真のチャンスは、誰も読んでいない何十万、あるいは何百万ものエージェントの行動履歴の中にあります。
小型で安価なモデルを使って、このアーカイブから以下のような情報を抽出できます。
- 類似する行動履歴をクラスタリングする
- 繰り返し発生する失敗モードにタグ付けする
- 珍しいツール使用シーケンスを浮き彫りにする
- 既知の事案と似た事例を特定する
- エージェントが疑わしい経路で成功したケースを見つける
このプロセスにより、観測データが評価データへと転換されます。トレースデータを単なる不活性なアーカイブとして放置するのではなく、テストスイートに恒久的に組み込むべき行動を発見するために活用します。
専門的な判断が必要な領域では、人間の専門家による関与が不可欠です。医療、法務、金融、あるいは高度に専門的なワークフローにおいては、正解と「説得力のある回答」を見分けることができるラベラーが必要です。
これらの専門家がデータセット全体をレビューする必要はありません。モデル支援型のラベリングプロセスの基準となるのは、小さくても慎重にラベル付けされた参照セットです。ただし、モデルと専門家の判断が食い違った箇所については、チームが継続してチェックを行うことが前提となります。
評価パイプラインは継続的に実行する必要があります。モデルのリリース、プロンプトの変更、ツールの更新、新しいユーザー層の導入など、あらゆる要因が本番環境のデータ分布を変化させます。一度きりの評価セットでは、もはや存在しない製品バージョンを記述するだけになってしまうからです。
エージェントの評価では、最終的な成果だけでなく、その結果に至るまでのプロセス（トラジェクトリ）の両方を測定すべきです。
成果ベースの評価は、エージェントが目標とする状態に到達できたかを問います。プロダクトの種類によりますが、成功とは「正しい分析の生成」「インフラ問題の修復」「有効なパッチのマージ」「データベースの更新」「サポートケースの解決」などを意味します。
一方、プロセス（トラジェクトリ）の評価では、エージェントがその状態に至るまでの経路を検証します。具体的には、選択したツールや設定パラメータ、参照した証拠、遭遇したエラー、そして停止を決断したタイミングなどが含まれます。
この二つの視点の両方が必要なのは、同じ結果でも背後にある行動が全く異なる場合があるからです。
エージェントは、危険なコマンドを発行したり、ハネス（評価環境）の欠陥を悪用したり、答えにたどり着くまで延々と試行錯誤したりしてタスクを完了させることがあります。プロセスが本番環境で使えるほど堅牢でないにもかかわらず、最終結果だけが通過してしまうケースです。
逆に、失敗したタスクにも前向きな兆候が含まれている場合があります。例えば、外部サービスのタイムアウトが発生する直前に、エージェントは正しい計画を立てて適切なツールを使用していたかもしれません。そのような実行を単なる「失敗」として一括りにすると、エージェントの振る舞いとインフラ側の問題という重要な区別が見えなくなってしまいます。
トジェクト分析は、インシデント化する前に弱いパターンを明らかにします。あるエージェントが今日成功しているとしても、冗長な呼び出しに依存していたり、サポートされていない仮定に基づいていたり、わずかな入力の変化で崩壊する回復経路を使っていたりする可能性があります。
トレーシングは、集計スコアと個々の意思決定をつなぎます。開発者は、その影響を与えた正確なツール呼び出し、観測結果、またはグラダーの判断へと、指標から移動できる必要があります。
このつながりがなければ、評価はエージェントが失敗したと宣告するだけで、エンジニアリングチームが何を修正すべきかについての示唆はほとんど提供できません。
エージェント評価における LLM-as-a-Judge（LLM を用いた採点者）をどのように較正すればよいのでしょうか？
LLM-as-a-Judge のスコアを信頼する前に、人間がラベル付けした事例に対して較正を行う必要があります。LLM-as-a-Judge とは、別のモデルの出力を採点するために使われる言語モデルのことです。具体的には、回答に点数をつけたり、2 つのトジェクトを順位付けしたり、人間のレビューヤーの代わりにルーブリックに沿って作業を確認したりします。
エージェントの結果の一部は、決定論的なチェックで検証できます。データベースの行が変更されたかどうかなど、明確な事実です。テストスイートも、パスしたか失敗したかのどちらかです。しかし、多くの重要なタスクには十分な曖昧さが含まれており、チームは出力やトジェクトを評価するために別のモデルに依存します。
採点者は、レポートがユーザーの実際の質問に応えているかどうか、パッチが根本原因を修正しているかどうか、あるいはエージェントが許容できるプロセスに従ったかどうかを評価する可能性があります。この柔軟性は、もう一つのモデル依存層を生み出し、そのエラーがベンチマークを歪める恐れがあります。
LLM を評価者（ジャッジ）として使う前に、チームは以下の点を確認すべきです。
まず、その判断結果を専門家によるラベル付け済み事例と比較します。合意だけでなく、意見が分かれたケースに注目して分析することが重要です。一貫性のない判断を生む曖昧な基準の文言は書き換えます。また、ジャッジには判断の根拠となる証拠を明示させる必要があります。さらに、評価用プロンプト、モデル、基準、出力形式はセットでバージョン管理し、ジャッジモデルやタスクの分布が変化した際には再調整を行います。
意見の不一致（ディスアグリーメント）分析が特に価値を持つのは、それが仕様の欠陥そのものを浮き彫りにすることが多いためです。ジャッジが文脈を見落としている可能性があります。基準に重要な優先事項が定義されていない場合もあります。また、チーム側で「成功」の共通定義を確立していないため、人間の評価者同士も意見が割れることがあります。
こうしたケースを解決することで、ジャッジの精度が向上し、製品要件が明確になります。
評価用プロンプトは本番環境のコードとして扱うべきです。わずかな言葉遣いの変更がスイート全体の結果を変え得ます。また、より新しいモデルに切り替えるだけで、評価対象のエージェント自体は何も変わっていないにもかかわらず、ベンチマーク結果が改善したように見えたり悪化したりする可能性があります。
信頼できるジャッジは、検証可能な証拠も同時に返すべきです。単なるスコアを出力するだけでなく、その結論を支える出力の該当箇所やツール呼び出し、通話記録の抜粋などを指し示す必要があります。
この証拠があれば、人間の評価者は最初から実行履歴を再構築することなく、判断結果を検証できます。
なぜエージェント用ハッチと評価用ハッチが重要なのか？
エージェントのハルネスと評価ハルネスは、エージェントが観測できる範囲や実行可能なアクション、そして得られたスコアの再現性を決定づけます。
Buleandra 氏は、AI サイト信頼性エンジニア（SRE）を構築するスタートアップとの協業を振り返ります。そのエージェントは Kubernetes クラスターや CI パイプライン、その他の運用システムに接続し、インフラストラクチャの問題の診断と修復が期待されていました。
チームは、評価環境を構築するための「賢い近道」があるかどうかを知りたがっていました。実用的な答えは、シミュレートされたクラスターを構築し、そこに現実的なデータを投入し、運用上のインシデントを再現可能にし、システムを特定の時点に巻き戻せるようにすることでした。
「誰もが難しいことをやっているのです」と Buleandra 氏は語ります。開発者にとってのその「難しいこと」には通常、以下が含まれます：
- すべての実行が既知のベースラインから開始できるようにするリセット可能な状態
- エージェントが一貫したインターフェースを受け取れるようにバージョン管理されたツールスキーマ
- 意味のある状況を再現するためのシードデータと障害シナリオ
- 安全でないアクションを制限する制御された認証情報と権限
- インフラの故障とエージェントのミスを区別できる詳細な環境ログ
この環境はテスト用固定装置（fixture）の一部となります。エージェントがファイル、データベース、チケット、デプロイメント、またはクラスターを変更できる場合、次の実行が始まる前にシステムを再現可能な状態に戻す必要があります。
特に製品がライブのサードパーティサービスに依存している場合、完璧なシミュレーションは依然として不可能です。評価プロセスでは、こうした限界を明確に可視化する必要があります。
API のタイムアウト、期限切れの認証情報、古くなったデータベースのスナップショット、そして不適切なツールの判断といった要因が、すべて同じ一般的な失敗ラベルに集約されてはいけません。これらの原因を見分けることができない場合、評価スコアはモデルの品質とインフラストラクチャの信頼性が混ざり合ったものとなり、解釈が困難になります。
この取り組みはプロンプトの実験よりも、分散システムエンジニアリングやテスト基盤の開発に近いです。まさにその理由から、本番環境におけるエージェントの評価には、ハーンプレイブック（評価用フレームワークの指針）が必要です。
モデルは製品の構成要素の一つに過ぎません。ツールの選定、プロンプト、メモリ、コンテキスト管理、リトライロジック、実行環境、そして採点基準が総合的に作用して、エージェントが何を実現できるかが決まります。
人間のトランスクリプトレビューは、なぜ偽の改善が見えてしまうのかを明らかにしますか？
人間のトランスクリプトレビューを通じて、ベンチマークでのスコア向上が真の実力向上なのか、単なる幸運な偶然によるものなのか、それとも評価システム自体に欠陥があるのかを見極めることができます。
SQL の LIMIT に関する事例は、「測定」と「理解」の間のギャップを浮き彫りにしています。Buleandra は 9 ポイントの改善を即座に把握できましたが、並列比較によるレビューを行うことで初めて、新しいモデルがハーン内のバグを回避する幸運な経路を見つけていたことが判明しました。
レイテンシの変化、ツールの順序変更、ランダムな変動、あるいは誤った行動を評価するグレーダーの影響などによって、一見すると改善されたように見える結果が得られることもあります。モデルが偶然にも一貫して良い結果を出してしまうと、その背後にあるメカニズムを検証するまで、それが持続的な能力向上であるかのように錯覚させてしまう恐れがあります。
「これに代わるものはありません」とブレンドラ氏はトランスクリプト（会話記録）の読解を強調しました。実行プロセスが数分から数時間に及ぶようになると、手動でのレビューは困難になります。そこで重要なのは、人間の注意を決定打となる部分へ誘導するツールを整備することです。
チームは、以下の3種類のツールを用いてトランスクリプトレビューのスケーラビリティを向上させることができます：
- 検索、フィルタリング、注釈付け、および長期間にわたる実行プロセスに対する質問に対応できる、タスク固有のトランスクリプトビューア
- ツール呼び出し、状態遷移、エラー、あるいはその他の重要な瞬間を中心に、2 つの実行結果を並列比較するツール
- 低信頼度の判定、モデルと人間の判断の相違、スコア変動の原因となった事例などを可視化するグレーダー判断ビュー
目指すべきは完全な自動化による解釈ではなく、効率的な検査です。モデル自身に、長い実行プロセスの要約、類似した失敗事例のグループ化、異常行動の特定、そして指標の変動を説明する可能性が高いケースのランキングを行わせることができます。
ただし、タスク、ハーン（評価枠組み）、およびプロダクトの理解を持つ人間が、その行動が真に意味のある能力向上であるかどうかを最終判断する必要があります。
このワークフローは集計されたメトリクスから始まり、根本的な証拠に至るべきです。ベンチマークの結果に変動が生じた際、開発者は以下の問いに答えられる必要があります：
どのケースが変更されたのか？
経路はどこで分岐したのか？
その分岐を引き起こしたのは、どのようなツール呼び出しや観測結果だったのか？
グラダー（評価者）は両方の実行を一貫して評価できたか？
エージェント自体が改善されたのか、それとも周辺システムに変化があったのか？
スコアはパフォーマンスのどこが変化したかを特定し、トランスクリプトのレビューはその理由を説明します。
評価駆動型開発は、AI エージェントにどのようなメリットをもたらすのでしょうか？
評価駆動型開発では、評価（evals）を開発ループ内に組み込みます。これにより、モデル、プロンプト、ツール、あるいはハッチネスのあらゆる変更を、既知の失敗事例や最前線の能力と比較して測定することが可能になります。
維持された評価システムがなければ、すべての変更が不確実性を生み出します。プロンプトの改訂は一つのワークフローを修復する一方で、別のワークフローを損なう可能性があります。ツールの更新は、手動でテストした数例では決して見えないような振る舞いの変化をもたらすかもしれません。より高性能なモデルがリリースされたとしても、製品チームはその新しい能力を活用するための根拠を持っていない恐れがあります。
成熟した評価ループは、いくつかのコンポーネントを結びつけます。
- 本番環境のトレース（traces）は、失敗や異常な振る舞いを明らかにします。
- 人間の専門家が、最も重要なケースをラベル付きの例に変換します。
- 回帰評価（regression evals）が、顧客にとって重要な動作を守ります。
- 能力評価（capability evals）が最前線の性能を測定します。
- LLM による判定（judges）は、人間のラベルに対してキャリブレーションされた後、レビューの範囲を広げます。
トランスクリプトの点検により、スコアが変化した理由が説明されます。
こうして得られたエビデンスが、次のエンジニアリング判断を導きます。各リリースから得られる情報が、次回の改善に活かされるのです。
このフィードバックループは、自己改善型エージェントの基盤としても機能します。エラーを観察し、その原因を特定できない限り、エージェントシステムが信頼性を持って自らを改善することはできません。
原文を表示
This piece builds on a talk Marius Buleandra, a member of Anthropic’s technical staff, gave at Arize Observe on building agent evals that hold up in production.
When Marius Buleandra tested a newer model on an AI data analyst eval, it appeared to beat its predecessor by nine points. The improvement looked substantial enough to share with Anthropic’s research team as evidence of a meaningful capability gain.
Before sending the result, however, Buleandra opened the transcripts, where the victory began to unravel. The newer model had developed a habit of adding LIMIT clauses to its SQL queries.
Under ordinary circumstances, that would be a defensible way to keep a query manageable. Inside this particular evaluation, it allowed the model to sidestep a defect in the harness. Once Buleandra repaired the harness, much of the apparent improvement disappeared. The score had detected a difference, but it had misidentified the cause.
Buleandra works on Anthropic’s Applied AI team, which sits between product research and customers and helps teams improve their agents, evals, and harnesses. That position has given him a close view of a problem increasingly familiar to software developers: agent benchmarks can produce precise numbers while concealing messy causal stories.
A model, prompt, tool, grader, or environment may have changed. The system may also have stumbled into a favorable path by chance. Reliable agent evaluation depends on knowing which explanation fits the evidence.
What are AI agent evals?
AI agent evals are structured tests that measure whether an agent completes a task successfully, how it reaches the result, and whether its behavior remains reliable as the surrounding system changes.
A conventional unit test usually evaluates a bounded function with a known input and an inspectable output. A bounded function is one whose behavior is self-contained and predictable: it takes a defined set of inputs and returns a defined output without depending on external state, accumulated history, or intermediate decisions.
An agent operates across a trajectory. It interprets a request, chooses an action, calls a tool, reads the result, revises its plan, and carries the accumulating history into every later decision. That means an agent eval may need to examine several layers at once:
The final outcome
The sequence of decisions and tool calls
The model and system instructions
The agent harness
The state of external tools and services
The grader used to determine success
A passing result can emerge from durable capability, a flawed test, or a fortunate accident. A useful eval must provide enough evidence to distinguish among them.
Why are AI agents so difficult to evaluate?
Agents are difficult to evaluate because their behavior unfolds over time, their instructions are frequently incomplete, and their interfaces allow users to ask for almost anything.
Three characteristics make that behavior especially difficult to measure:
Errors compound across the trajectory. An incorrect assumption or malformed tool call near the beginning can influence every action that follows. Because earlier observations remain in context, a small mistake can become part of the agent’s working model of the task.
Tasks arrive underspecified. Users rarely provide a complete definition of success. They type a sentence into a text box and expect the system to infer the goal, constraints, tradeoffs, and stopping conditions.
Open-ended interfaces create unknown unknowns. A general-purpose input field invites requests the product team may never have anticipated, including tasks the agent cannot safely or reliably complete.
These problems become more severe as agents run for longer periods. A multi-hour trajectory may contain hundreds of decisions, any one of which can redirect the rest of the run.
The surrounding environment introduces another source of uncertainty. Agents can reach into databases, code repositories, Slack workspaces, ticketing systems, CI pipelines, and third-party APIs. Those systems change independently, which makes it difficult to reproduce the exact conditions behind a success or failure.
The cost of avoiding this work is substantial. Without evals, regressions can remain hidden until a user encounters them. Model upgrades can also become slow and subjective because the team has no reliable way to compare versions. New capabilities may arrive without anyone realizing that the product can finally support them.
An agent can also feel similar after an upgrade while behaving much better on a narrow class of valuable tasks. Capability evals give those improvements somewhere to appear.
Regression evals vs. capability evals: What’s the difference?
Regression evals verify that previously working behavior continues to work. Capability evals measure how far the agent’s abilities can extend.
Production teams need both because they support different engineering and product decisions.
Dimension
Regression evals
Capability evals
Primary question
Did this change break known behavior?
What can the agent accomplish now?
Main purpose
Prevent fixed failures from returning
Reveal new capabilities and remaining headroom
Expected performance
A high pass rate that approaches saturation
A challenging baseline with meaningful room to improve
Typical data sources
Customer incidents, reported failures, and repaired bugs
Frontier workflows, benchmark-inspired tasks, and stress cases
When to refresh
When the product, harness, or user distribution changes
When models, tools, or the agent’s scope improve
Decision supported
Is this release safe?
What should we build next?
Most teams begin with regression cases because the source material is already available. A customer reports a failure, the engineering team fixes it, and the corresponding example enters the suite so the same problem cannot quietly return.
A mature regression suite should achieve a high pass rate. It may still require maintenance as user behavior, prompts, tools, and external systems change, although its central purpose remains stable: protect capabilities the product already depends on.
Capability evals occupy the frontier. Buleandra describes the process as hill climbing. The team begins with tasks that the agent can complete only some of the time, then changes the model, prompt, tools, or harness and measures whether the frontier moves.
These evals can influence product strategy as much as model selection. An agent that becomes better at recovering from failed tool calls, preserving coherence across long workflows, or interpreting ambiguous instructions may unlock features that previously required constant human supervision.
The strongest agent teams invest heavily in capability evals because the results reveal more than whether a release is safe. They show what the product may be ready to become.
How do you build an AI agent eval dataset?
A useful agent eval dataset combines the structure of established benchmarks with the substance of real production behavior.
The first case often feels harder than the hundredth because every decision remains open: task format, data source, success criteria, environment, and grader.
Buleandra’s advice is practical: “Just copy the shape of the eval.”
A workable data pipeline looks like this:
Study a relevant public benchmark. Examine how it frames tasks, samples inputs, defines success, captures evidence, and grades the result.
Mine production traces for real behavior. Start with reported incidents, then analyze the larger archive of transcripts that no human has reviewed.
Create a small expert-labeled reference set. Ask people with deep domain knowledge to identify successful behavior, acceptable alternatives, and meaningful failure modes.
Calibrate a capable model against those labels. Once its judgments align with the expert reference set, use it to extend the labeling process across a larger dataset.
Repeat the pipeline as the system changes. Revisit production traces periodically to account for data drift, model upgrades, new tools, and changing user behavior.
Public benchmarks provide a starting structure. A team building a coding agent might study repository-level software engineering benchmarks, while a team building an operational agent could examine tasks involving stateful tools and multi-step recovery.
The benchmark’s shape is more transferable than its exact cases. Developers can borrow the task format, evidence requirements, and grading logic, then replace the content with examples that reflect their own product. Production transcripts supply that content.
Customer complaints offer an obvious starting point, although they often only capture the failures visible enough to provoke a report. The larger opportunity lies inside the hundreds of thousands, or millions, of agent trajectories that nobody has read.
A smaller, inexpensive model can help mine this archive by:
Clustering similar trajectories
Tagging recurring failure modes
Surfacing unusual tool sequences
Identifying examples that resemble known incidents
Finding cases in which the agent succeeded through a suspicious path
This process turns observability data into evaluation data. Instead of allowing traces to accumulate as an inert archive, the team uses them to discover which behaviors deserve a permanent place in the test suite.
Human experts remain essential when the domain requires specialized judgment. A medical, legal, financial, or deeply technical workflow needs labelers who can distinguish a convincing answer from a correct one.
Those experts do not need to review the entire dataset. A small, carefully labeled reference set can anchor a model-assisted labeling process, provided that the team continues checking where the model and experts disagree.
The pipeline should run repeatedly. Each model release, prompt change, tool update, and new user cohort can alter the production distribution. An eval set that never changes will eventually describe a version of the product that no longer exists.
Agent outcomes vs. trajectories: what should you evaluate?
Agent evals should measure both the final outcome and the trajectory that produced it.
Outcome evaluation asks whether the agent reached the required end state. Depending on the product, success might mean producing a correct analysis, repairing an infrastructure problem, merging a valid patch, updating a database, or resolving a support case.
Trajectory evaluation examines how the agent reached that state, including the tools it selected, the parameters it supplied, the evidence it used, the errors it encountered, and the point at which it chose to stop.
Both views are necessary because the same outcome can conceal very different behavior.
An agent might complete a task after issuing risky commands, exploiting a harness defect, or retrying until it stumbles into the answer. The final result may pass even though the process remains too brittle for production.
A failed task can also contain encouraging evidence. The agent may have formed the correct plan and used the appropriate tools before an external service timed out. Treating that run as an undifferentiated failure would hide the distinction between agent behavior and infrastructure behavior.
Trajectory analysis also exposes weak patterns before they become incidents. An agent may be succeeding today while relying on redundant calls, unsupported assumptions, or a recovery path that will collapse under a slightly different input.
Tracing connects the aggregate score to those individual decisions. A developer should be able to move from a metric to the exact tool call, observation, or grader decision that influenced it.
Without that connection, an eval can announce that the agent failed while offering little guidance about what the engineering team should change.
How do you calibrate an LLM-as-a-Judge for agent evals?
An LLM-as-a-judge should be calibrated against human-labeled examples before its scores are trusted. An LLM-as-a-judge is simply a language model asked to grade another model’s output—scoring a response, ranking two trajectories, or checking work against a rubric in place of a human reviewer.
Some agent outcomes can be verified with deterministic checks. A database row either changed or it did not. A test suite either passed or it failed. Many consequential tasks contain enough ambiguity that teams rely on another model to assess the output or trajectory.
The judge might evaluate whether a report addressed the user’s actual question, whether a patch fixed the root cause, or whether the agent followed an acceptable process. That flexibility creates another model-dependent layer whose errors can distort the benchmark.
Before relying on an LLM judge, the team should:
Compare its verdicts with expert-labeled examples.
Inspect disagreement cases rather than tracking agreement alone.
Rewrite ambiguous rubric language that produces inconsistent decisions.
Require the judge to identify the evidence behind its verdict.
Version the judge prompt, model, rubric, and output format together.
Recalibrate whenever the judge model or task distribution changes.
Disagreement analysis is particularly valuable because it often reveals weaknesses in the specification itself. The judge may be missing context. The rubric may leave an important preference undefined. Human reviewers may also disagree because the team has never established a shared definition of success.
Resolving those cases improves the judge and clarifies the product requirements.
Judge prompts should be treated as production code. A small wording change can alter results across the entire suite, while switching to a newer judge model can make a benchmark appear to improve or regress even when the evaluated agent remains unchanged.
A trustworthy judge should also return inspectable evidence. Rather than producing only a score, it should point to the section of the output, tool call, or transcript passage that supports its conclusion.
That evidence allows a human reviewer to verify the verdict without reconstructing the entire run from scratch.
Why do the agent harness and evaluation harness matter?
The agent harness and evaluation harness influence what the agent can observe, which actions it can take, and whether the resulting score can be reproduced.
Buleandra recalled working with a startup building an AI site reliability engineer. The agent connected to Kubernetes clusters, CI pipelines, and other operational systems, where it was expected to diagnose and repair infrastructure problems.
The team wanted to know whether there was a clever shortcut for building the eval environment. The practical answer involved constructing a simulated cluster, filling it with realistic data, reproducing operational incidents, and making the system rewindable to a known point in time.
“Everybody is doing the hard thing,” Buleandra said. For developers, that hard thing usually includes:
Resettable state so every run can begin from a known baseline
Versioned tool schemas so the agent receives consistent interfaces
Seeded data and failure scenarios that reproduce meaningful conditions
Controlled credentials and permissions that limit unsafe actions
Detailed environment logs that separate infrastructure faults from agent mistakes
The environment becomes part of the test fixture. When an agent can mutate files, databases, tickets, deployments, or clusters, each run must return the system to a reproducible state before the next one begins.
Perfect simulation may remain impossible, especially when the product depends on live third-party services. The evaluation should make those limitations visible.
An API timeout, an expired credential, a stale database snapshot, and a bad tool decision should not collapse into the same generic failure label. When those causes remain indistinguishable, the score blends model quality with infrastructure reliability and becomes difficult to interpret.
This work resembles distributed systems engineering and test infrastructure more than prompt experimentation. That is precisely why production agent evaluation requires a harness playbook.
The model forms only one layer of the product. The tools, prompts, memory, context management, retry logic, environment, and graders collectively determine what the agent can accomplish.
How does human transcript review expose false improvements?
Human transcript review reveals whether a benchmark improvement reflects genuine capability, a favorable accident, or a defect in the evaluation system.
The SQL LIMIT example captures the gap between measurement and understanding. Buleandra could see the nine-point improvement immediately, although only a side-by-side review showed that the newer model had discovered a lucky route around the harness bug.
Other apparent gains can arise from changed latency, different tool ordering, random variation, or a grader that rewards the wrong behavior. A model may even get lucky consistently, which makes the effect look like a durable capability until someone examines the mechanism behind it.
“There’s no replacement for this,” Buleandra said of reading transcripts. Manual review becomes difficult as trajectories stretch from minutes to hours. The answer is to build tooling that directs human attention toward the decisive parts of the run.
Teams can scale transcript review with three kinds of tools:
Task-specific transcript viewers that support search, filtering, annotation, and questions over long trajectories
Side-by-side comparison tools that align two runs around tool calls, state transitions, errors, or other consequential moments
Grader-decision views that surface low-confidence verdicts, model-human disagreements, and the examples responsible for a score change
The goal is efficient inspection rather than fully automated interpretation. A model can summarize long trajectories, group similar failures, identify unusual behavior, and rank the cases most likely to explain a metric shift.
A human who understands the task, harness, and product still needs to decide whether the behavior represents a meaningful capability gain.
That workflow should begin with the aggregate metric and end at the underlying evidence. When a benchmark moves, the developer should be able to answer:
Which cases changed?
Where did the trajectories diverge?
Which tool calls or observations caused that divergence?
Did the grader evaluate both runs consistently?
Did the agent improve, or did the surrounding system change?
A score identifies where performance moved. Transcript review helps explain why.
How does evaluation-driven development improve AI agents?
Evaluation-driven development places evals inside the engineering loop so every model, prompt, tool, or harness change can be measured against known failures and frontier capabilities.
Without a maintained eval system, each change creates uncertainty. A prompt revision may repair one workflow while damaging another. A tool update may alter behavior in ways that a handful of manually tested examples never expose. A more capable model may ship while the product team lacks the evidence needed to use its new abilities.
A mature evaluation loop connects several components:
Production traces reveal failures and unusual behavior.
Human experts convert the most important cases into labeled examples.
Regression evals protect customer-critical behavior.
Capability evals measure the frontier.
LLM judges extend review after being calibrated against human labels.
Transcript inspection explains why the score changed.
The resulting evidence guides the next engineering decision.
Each release then produces information that can improve the next one.
This feedback loop also provides the foundation for self-improving agents. An agent system cannot reliably improve itself unless it can observe failures, identify mea
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み