Agent Judge：生産環境向けエージェントの長期コンテキスト評価を解決（10 分読了）
本記事は、長文コンテキストを持つ自律型エージェントの評価において従来の LLM ジャッジが機能不全に陥る理由を分析し、その限界と課題を明確に指摘している。
キーポイント
LLM ジャッジの根本的限界
長期的なタスクを実行するエージェント（数百回のツール呼び出しを含む）の完全な軌跡は、LLM のコンテキストウィンドウに収まりきらないため、従来の評価手法では不十分である。
状態変更の検証不可能性
CRM、AWS、Google Calendar などの外部システムでのステートフルな変更を、ソースオブトゥルースと照合して検証する能力が LLM ジャッジには欠如している。
実務への悪影響
評価の精度低下によりエージェントの失敗が見逃され、顧客満足度が損なわれる結果、チームは手動レビューという非効率な方法に依存せざるを得なくなっている。
他者の実行履歴の活用
他のワーカーが類似の実行、過去のラベル、以前の判断者間の不一致、または繰り返される失敗パターンを検索することで、現在のケースがシステムで既知のものかどうかを判断できる。
環境状態に基づく検証 (Verification)
Agent Judge はエージェントの主張だけでなく、API 応答やログなどの証拠を「真実源（ソース・オブ・トゥルース）」と照合し、アクションが実際に実行されたかを客観的に検証します。
ルブリック自動改善による精度向上
Rubric Builder がフィードバックを元に評価基準を継続的に更新・洗練させることで、初期版と比較して精度（Accuracy）0.76 から 0.86、F1 スコア 0.67 から 0.79 へと大幅に向上しました。
難易度が高いケースでの優位性
複雑なプロンプトや固定された LLM 判定器が困難さに直面して精度が急落する中、Agent Judge は難易度の高いケースでも安定した高精度を維持し、長期ホライゾンの評価に最適です。
重要な引用
As the industry moves toward long-horizon agents that autonomously perform tasks end-to-end, LLM judges fail to consistently produce accurate evals.
A basic LLM judge breaks down: it cannot fit the full agent trajectory into its context window, and it cannot verify stateful changes against source-of-truth systems such as Google Calendar, a CRM, AWS, or GitHub.
Other workers can search similar runs, prior labels, previous judge disagreements, or repeated failure patterns to understand whether the current case matches something the system has seen before.
Agent Judge evaluates stateful work directly: not whether the agent described the right action, but whether the action actually happened.
Long-horizon agent evals should be done by agents with dynamic rubrics, not fixed LLM judge prompts.
影響分析・編集コメントを表示
影響分析
この記事は、自律型エージェントの実装が進む中で、従来の評価手法がボトルネックとなっていることを鋭く指摘しており、業界全体でより高度な評価フレームワーク（例：多段階検証や外部システム連携型ジャッジ）への移行を迫る重要な示唆を含んでいます。開発チームは、長文コンテキストや状態管理を扱える新しい評価ツールの導入を検討する必要があるでしょう。
編集コメント
自律型エージェントの実用化において、評価（Eval）の信頼性は開発の成否を分ける重要要素ですが、現状の LLM ジャッジの限界を浮き彫りにした鋭い指摘です。
シンプルな LLM ジャッジからの脱却
ほとんどのチームは、シンプルな LLM（大規模言語モデル）ジャッジのアプローチを用いてエージェントの軌跡を評価しています。具体的には、ユーザーの問い合わせ、最終的なエージェントの出力、おそらくいくつかのメタデータ、そして評価基準（ルブリック）をジャッジに与え、「エージェントが意図通りに振る舞ったか」を問うのです。
業界が自律的にエンドツーエンドでタスクを実行する長期的なホライズンを持つエージェントへと移行するにつれ、LLM ジャッジは正確な評価結果を一貫して生み出すことができなくなっています。例えば、営業用エージェントはリードの調査を行い、CRM（顧客関係管理システム）を更新し、メールを送信し、会議を予約してから最終メッセージを返すことがあります。あるいは、コーディング用エージェントが数十個のファイルを編集し、AWS の設定を更新し、GitHub でプルリクエスト（PR）を作成することもあります。
どちらの場合も、基本的な LLM ジャッジは機能不全に陥ります。それは、完全なエージェントの軌跡をコンテキストウィンドウに収めることができないためです。また、Google カレンダー、CRM、AWS、GitHub といった真の情報源システムに対して状態変化を検証することもできません。その結果、自動化された評価の有効性は崩壊します。エージェントの失敗が検出されずに見過ごされ、顧客の不満は解消されず、チームは結局のところ、手動によるエージェント軌跡の見直しに戻らざるを得なくなります。
LLM ジャッジが長期的なホライズンを持つエージェントで機能しなくなるのには、3 つの理由があります：
- 長い軌跡。長期的なホライズンを持つエージェントは、データベース、サービス、ドキュメント、その他のシステムにわたる数百回のツール呼び出しを跨ぐことがあります。Codex や Claude Code といったコーディング用エージェントは、作業中にコンテキストを圧縮するため、長時間のホライズンを実行できます。これにより、その軌跡は数百万トークンにまで拡張され、LLM ジャッジが単一のコンテキストウィンドウに収めることができる範囲をはるかに超えてしまいます。
- LLM ジャッジは長い軌跡のごく一部しか読み取れない
多くの軌跡部分がジャッジの読解範囲外となる。
ジャッジが見落としがちな点
入力
残りの軌跡
出力
LLM コンテキストウィンドウ
長期にわたるエージェントの軌跡は、LLM ジャッジがコンテキスト内に保持できる範囲を超え得る。完全なトレースを一つのプロンプトに貼り付けると失敗する可能性があり、切り捨てたり分割したりすると重要な部分が読み飛ばされてしまう。
状態を持つアクション。本番環境のエージェントは単にテキストを生成するだけでなく、データベースへの照会、API 呼び出し、レコードの更新、メッセージ送信、ワークフローのトリガーなどを行う。例えば、背景で動作する販売用エージェントがリードのステータスを変更した場合、評価者は CRM を確認してその変更が反映されたことを検証しなければならない。
状態を持つシステムにアクセスできるのは Agent Judge だけである。
LLM ジャッジは軌跡しか見えない。
Agent Judge は本番の状態が存在するシステムを検査する。
LLM Judge（GitHub, AWS IAM, Secrets Manager, CloudWatch）
Agent Judge（GitHub, AWS IAM, Secrets Manager, CloudWatch）
LLM ジャッジは軌跡のみを見、対応する環境は見ないため、状態の変化が検証されない。一方、Agent Judge はエージェントが作用したのと同じシステムを照会し、そのアクションが実際に発生したかどうかを確認する。
行動の変化。AI システムの改善に伴い、モデル、ツール、ユーザーワークフローは進化します。先月まで有効だった評価基準は、古くなり、新しい失敗モードを見逃したり、改善された行動を過度にペナルティ付けたり、証拠を探す場所が間違っていたりすることがあります。本番環境では、クエリの分布やエージェントへの変更に合わせて基準も進化する必要があり、評価者が正確で有用であり続けるためです。
基準は静止したままです。エージェントは動きません。固定された基準は許容範囲を定義します。本番での行動はその範囲から逸脱します。
週 1
週 10
- 基準
- 行動
基盤となるモデル、ツール、ユーザーワークフローの変更により、エージェントの動作も変化します。固定された基準では古い基準に基づいて採点し続けるため、評価者は関連する新しい失敗モードを検出できなくなります。
評価は最終回答に対する判断ではなく、全体の軌跡に関する調査です。評価者は、エージェントが何を見、何をし、何を変更し、何に依存したかを検査する必要があります。
エージェント・ジャッジ
私たちは Agent Judge を設計しました。これは、検索、検証、適応という 3 つの異なる機能を通じて、これら 3 つの失敗モードに対処するためのエージェント型評価ハーンです。
検索：長い軌跡をナビゲート可能にすることで処理し、手動での追跡レビューを行わずとも埋もれた証拠を見つけることができます。
- 検証：ツールによる証拠と環境状態を確認することで状態保持アクションを処理し、評価がエージェントの行動の結果を検証できるようにします。
- 適応性：多くの生産環境の軌跡にわたる人間のフィードバックや生産シグナルとの評価比較を通じて、動的な人間およびエージェントの振る舞いに対応し、エージェント、ツール、製品の変化に応じてルブリックを進化させます。
Agent Judge はマルチエージェントシステムとして実行されます。リーダーエージェントは対象となる証拠を検査し、生成されたワーカーエージェントは検索または検証作業を分割し、フォークされたエージェントは最初のパスで提起された新たな質問を追跡します。
検索
長い軌跡において、失敗モードは微妙であり、単一の場所に存在することはめったにありません。 誤りは初期の検索結果、失敗したリトライ、後のツール呼び出し、または最終回答から生じることがあります。これらのケースを評価するには、多段推論が必要になることが多く、ある検索で手がかりが表面化し、その手がかりが新たな質問を提起し、評価者がその連鎖を追跡する必要があります。
Agent Judge は長期の軌跡を検索可能なオブジェクトに変換します。メッセージ、ツール呼び出し、取得されたドキュメント、データベース応答、ログ、リトライ、状態変更はすべて、単一のプロンプトに詰め込むための文脈ではなく、ナビゲート可能な証拠となります。
重要なスライスのみを抽出
Agent Judge は結果を決定するターンを選び出し、それ以外はコンテキストから除外します。
コーディングエージェントの軌跡
readgrepeditreadreadbashreadbashreadtesttestreadgitmsgeditbashgit
証拠
Agent Judge はルブリックに関連する証拠を軌跡全体で検索します。軌跡の残りはワーカーエージェントのコンテキストからは除外されます。
Agent Judge は 2 つの平面で検索を行います：現在の軌跡内と、過去の軌跡間です。ケースが曖昧または複雑な場合には、より多くの計算リソースを投入できます。具体的には、証拠の標的型スライスを読み込んだり、特定の部分を検査するためにワーカーエージェントを起動したり、最初の検索で新たな情報が表面化した際にフォークして追跡調査を行ったりします。
- 軌跡内：ワーカーエージェントは特定のターン、ツール呼び出しチェーン、取得されたレコード、ログ、または状態変更を検査します。あるワーカーはエージェントが使用したレコードを追跡し、別のワーカーは後の回答が古いか誤った証拠に依存していないかを確認します。
- 軌跡間：他のワーカーは類似の実行、過去のラベル、以前の審査官の不一致、または繰り返される失敗パターンを検索し、現在のケースがシステムが以前に見たものと同じかどうかを理解します。
コーディネーターは関連するスパン、ツール呼び出し、状態変更を収集し、証拠が不十分な場合は追跡調査を開始するか、評価結果に統合します。
検証
Agent Judge は、環境状態がエージェントの主張するアクションと一致しているかを確認します。正しいレコードが更新されたでしょうか？API 呼び出しは成功したでしょうか？生成された PR は適切なファイルを修正したでしょうか？ワークフローは実際にトリガーされたでしょうか？
記録された実行またはライブ実行において、Agent Judge は API レスポンス、データベース結果、ログ、更新確認、取得されたレコード、GitHub イベントなどのキャプチャされたツール証拠を検査します。監査ログ、イベントストリーム、タイムスタンプ、バージョン管理されたレコードなど、基盤システムが永続的な証拠を公開している場合、Agent Judge はデータベース、サービス API、GitHub、チケット管理システム、MCP サーバーなどの読み取り専用ソース・オブ・トゥルース（真実の源）システムに対して、状態保持アクションも検証できます。
主張されたアクションは、ソース・オブ・トゥルースに対してチェックされます。Agent Judge は各主張を記録された状態と照合し、両者が乖離する箇所をフラグ付けします。エージェントの主張：authFile の変更、テスト実行、PR 作成、バグ修正、最終的な主張。ソース・オブ・トゥルース：編集済み、テスト実行済み、PR #1247 公開、1 つのテスト失敗、未修正。差分存在。Agent Judge は各主張されたアクションをシステムの記録された状態と整合させます。3 つが一致しますが、最後の「バグ修正」の主張は乖離しています — CI システムではまだ failing test（失敗するテスト）が表示されています。
Agent Judge は状態保持作業を直接評価します。エージェントが正しいアクションを記述したかどうかではなく、そのアクションが実際に発生したかどうかを評価します。
適応
Agent Judge は、Rubric Builder を通じて適応します。これは、評価された軌跡と人間を介したフィードバック信号を次のルブリック版の改善に転換するフィードバックループです。その目的は、人間のフィードバックが将来の評価で用いられる基準に反映されるようにすることです。
ルブリックの更新は具体的です：欠落している基準を追加する、例を用いて曖昧な表現を明確にする、繰り返し発生する偽陽性または偽陰性を減らす、あるいは評価者がどの証拠をより注意深く検査すべきかを指示します。
このループは繰り返されます。Rubric Builder が改善のための探索を終了するまで、Agent Judge は更新されたルブリックを再実行します：
評価：Agent Judge は現在のルブリックを用いて、困難なケースまたは高シグナルのケースを評価します。
- 較正チェック：評価結果は、人間専門家のラベル、ペア比較での選好、生産環境の結果、環境チェック、評価者間の不一致、あるいは異なる結果をもたらす類似の実行など、フィードバック信号と比較されます。
- ルブリックの精緻化：分析エージェントは、孤立したエラーだけでなくギャップ全体のパターンをレビューし、焦点を絞ったルブリックの変更を提案します。
- 反復：精緻化されたルブリックは Agent Judge にフィードバックされ、より多くの生産データが流入するにつれてプロセスが繰り返されます。
評価基準はパスごとに収束する
各再実行で評価基準に焦点を絞った変更が行われる。精度は上昇し、改善の余地が尽きると安定する。
精度
評価基準の改良パス
CI テストチェックを追加
表現を厳密化
偽陽性ルールを削除
改善の余地が尽きる
連続する改良パス（それぞれが評価基準への焦点を絞った変更）を通じて、Agent Judge の精度は上昇し、Rubric Builder が改善の探索を終えるとともに頭打ちとなる。
時を経て、評価基準は生産環境での軌道データに対してテストされ、フィードバックから更新され、行動の変化に合わせて手書きで書き直すのではなく、エージェントと共に成長する生きたバージョン管理された評価アーティファクトとなる。
内部トラフィックによる評価
Agent Judge を、コーディングエージェントおよび LLM ジャッジと比較し、内部の生産環境でのトラフィックを用いて軌道レベルのハルシネーション検出においてテストした。ここでいう軌道レベルのハルシネションとは、軌道、ツール証拠、または真実性の高い環境状態に対して根拠のない主張や行動を指す。
各軌道のハルシネションについて人間专家がラベル付けを行った。このラベル付きセットを、コーディングエージェント用ハーネス、LLM ジャッジ、初期評価基準を用いた Agent Judge、および Rubric Builder による改良後の Agent Judge で評価した。
方法 | セットアップ | 精度 | 再現率 | 適合率 | F1 スコア
---|---|---|---|---|---
Agent Judge（改良済み評価基準） | Rubric Builder を備えたカスタムエージェント評価ハーネス | 0.86 | 0.88 | 0.71 | 0.79
Agent Judge（初期評価基準） | 初期評価基準を備えたカスタムエージェント評価ハーネス | 0.76 | 0.80 | 0.58 | 0.67
Claude CodeClaude Opus 4.6 in coding-agent harness with rg and jq0.730.530.560.54
CodexGPT-5.4 in coding-agent harness with rg and jq0.690.630.490.55
GPT-5.4 LLM JudgeLLM judge over trajectory and rubric0.740.800.540.65
GPT-5.4-mini LLM JudgeLLM judge over trajectory and rubric0.650.510.430.47
5 回の反復改良を経て、ルブリックビルダーを備えた Agent Judge は、初期のルブリックと比較して精度（accuracy）、再現率（recall）、適合率（precision）、および F1 スコアを向上させます。
困難なケースを測定するために、5 人の判事からなる LLM アンサンブルを難易度のベースラインとして使用しました。このベースラインを、初期ルブリックを備えた Agent Judge およびルブリックビルダーによる改良後の Agent Judge と比較します。
難易度別精度（Accuracy by Difficulty Decile）
軌道難易度ヒューリスティックにおいて、高いデシールはより困難です。10080604020012345678910 難易度デシール Accuracy (%) Agent Judge w/ Rubric Builder Agent Judge, initial rubric 5x LLM Judge Ensemble GPT-5.4 LLM Judge Claude Code Codex
難易度別精度。ルブリックビルダーを備えた Agent Judge は困難な尾部（hard tail）において最も強力であり、一方、5 人判事 LLM アンサンブルのベースラインは軌道難易度が上昇するにつれて急激に低下します。
難易度デシール全体を通じて、ルブリックビルダーを備えた Agent Judge はほとんどのデシールでベースラインと同等かそれ以上を示しますが、5 人判事 LLM アンサンブルの整合性は、難易度が上昇するにつれて急激に劣化します。
長期ホライズンのエージェント評価は、固定された LLM ジャッジプロンプトではなく、動的なルブリックを持つエージェントによって行われるべきです。高品質な評価には、エージェントが変更した環境状態や、生産動作の進化に合わせて適応するために必要なフィードバックを含む、完全なトラジェクトリコンテキストへのアクセスが必要です。
次のステップ
次のステップは失敗診断です。Agent Judge がより多くのトラジェクトリを評価するにつれ、単にスコアを付与するだけでなく、なぜ失敗が発生したかを分析し、関与するコードパス、ツール、プロンプト、またはワークフローを特定し、エージェントの改善に最も寄与する変更を浮き彫りにすべきです。
Agent Judge は、評価を生産向上ループに変換します：より優れたジャッジがより良い失敗分析をもたらし、より良い失敗分析がより優れたルブリックとトレーニング例をもたらすことで、同じループは最終的にコードベース、ツール、プロンプト、およびワークフローに対してターゲットを絞った変更を提案できるようになります。
原文を表示
Moving Away From Simple LLM Judges
Most teams evaluate agent trajectories with a simple LLM judge approach: give the judge the user query, final agent output, perhaps some metadata, and a rubric. Then, ask whether the agent behaved as intended.
As the industry moves toward long-horizon agents that autonomously perform tasks end-to-end, LLM judges fail to consistently produce accurate evals. For instance, a sales agent may research leads, update a CRM, send an email, and book a meeting before it returns a final message. Or a coding agent may edit dozens of files, update an AWS config, and open a GitHub PR.
In both cases, a basic LLM judge breaks down: it cannot fit the full agent trajectory into its context window, and it cannot verify stateful changes against source-of-truth systems such as Google Calendar, a CRM, AWS, or GitHub. As a result, the effectiveness of automated evals falls apart. Agent failures slip through undetected, customer dissatisfaction persists, and teams default back to manual review of agent trajectories.
LLM judges break down on long-horizon agents for three reasons:
- Long trajectories. Long-horizon agents can span hundreds of tool calls across databases, services, documents, and other systems. Coding agents like Codex and Claude Code can run for long horizons because they compact context as they work. That lets their trajectories extend into millions of tokens, far beyond what an LLM judge can fit into a single context window.
Agent Judge searches across two planes: within the current trajectory and across prior trajectories. It can spend more compute where the case is ambiguous or complex: reading targeted slices of evidence, spawning worker agents to inspect specific parts of the run, or forking follow-up searches when the first search surfaces new information.
- Within a trajectory: Worker agents inspect specific turns, tool-call chains, retrieved records, logs, or state changes. One worker might track which record the agent used, while another checks whether a later answer depended on stale or incorrect evidence.
- Across trajectories: Other workers can search similar runs, prior labels, previous judge disagreements, or repeated failure patterns to understand whether the current case matches something the system has seen before.
The coordinator collects the relevant spans, tool calls, and state changes, then combines them into an evaluation or launches follow-up searches if the evidence is incomplete.
Verification
Agent Judge verifies that the environment state matches the agent's claimed actions. Did the agent update the correct record? Did the API call succeed? Did the generated PR modify the right files? Did the workflow actually trigger?
On recorded or live runs, Agent Judge inspects captured tool evidence such as API responses, database results, logs, update confirmations, retrieved records, and GitHub events. When the underlying system exposes durable evidence, such as audit logs, event streams, timestamps, or versioned records, Agent Judge can also verify stateful actions against read-only source-of-truth systems like databases, service APIs, GitHub, ticketing systems, or MCP servers.
Over time, the rubric becomes a living, versioned evaluation artifact: tested against production trajectories, updated from feedback, and grown alongside your agents instead of rewritten by hand each time behavior shifts.
Evaluating on Internal Traffic
We tested Agent Judge against coding agents and LLM judges on trajectory-level hallucination detection using internal production traffic. We define trajectory-level hallucination as an unsupported claim or action relative to the trajectory, tool evidence, or source-of-truth environment state.
Human experts labeled each trajectory for hallucination. We evaluated the labeled set with coding-agent harnesses, LLM judges, Agent Judge with the initial rubric, and Agent Judge after Rubric Builder refinement.
MethodSetupAccuracyRecallPrecisionF1
Agent Judge, Refined RubricCustom agentic evaluation harness with Rubric Builder0.860.880.710.79
Agent Judge, Initial RubricCustom agentic evaluation harness with initial rubric0.760.800.580.67
Claude CodeClaude Opus 4.6 in coding-agent harness with rg and jq0.730.530.560.54
CodexGPT-5.4 in coding-agent harness with rg and jq0.690.630.490.55
GPT-5.4 LLM JudgeLLM judge over trajectory and rubric0.740.800.540.65
GPT-5.4-mini LLM JudgeLLM judge over trajectory and rubric0.650.510.430.47
After five refinement iterations, Agent Judge with Rubric Builder improves accuracy, recall, precision, and F1 over the initial rubric.
To measure hard cases, we used a five-judge LLM ensemble as a difficulty baseline. We compare that baseline against Agent Judge with the initial rubric and Agent Judge after Rubric Builder refinement.
Across difficulty deciles, Agent Judge with Rubric Builder matches or beats the baselines in most deciles, while the five-judge LLM ensemble consistency degrades sharply as difficulty increases.
Long-horizon agent evals should be done by agents with dynamic rubrics, not fixed LLM judge prompts. High-quality evals need access to the full trajectory context, the environment state the agent changed, and the feedback needed to adapt as production behavior evolves.
What's Next
The next step is failure diagnosis. As Agent Judge evaluates more trajectories, it should not only assign scores; it should analyze why failures happen, identify the code paths, tools, prompts, or workflows involved, and surface the changes most likely to improve the agent.
Agent Judge turns evals into a production improvement loop: better judges produce better failure analysis, better failure analysis produces better rubrics and training examples, and the same loop can eventually propose targeted changes back into codebases, tools, prompts, and workflows.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み