AI エージェント評価の未来:エージェントが審査役となる時代へ
本文の状態
日本語全文を表示中
詳細モードで約12分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Arize AI Blog
AI エージェントの複雑な失敗を捉えるため、単一 LLM による評価から、エージェントが証拠を収集して判断する「Agent-as-a-Judge」への移行が急速に進んでいる。
AI深層分析を開く2026年8月20日 01:22
AI深層分析
キーポイント
評価パラダイムの転換
2024 年に提案された研究が 2025 年に ICML で採択され、2026 年には製品化されるなど、エージェント評価の手法が急速に実用段階へ移行している。
LLM-as-a-Judge の限界
従来の LLM が出力のみを評価する方式は、エージェント特有のループや文脈の欠落など、実行軌道(trajectories)内の失敗を検出できない構造的な欠陥を抱えている。
Agent-as-a-Judge の仕組み
この新手法では AI エージェントが他のエージェントの行動を調査し、ツール呼び出しや中間ステップなどの証拠を収集して基準に基づき判断を下す。
構造的な不整合の解決
最終回答に焦点を当てる従来の評価では、ツールへの不適切な引数や後付けの論理など、根本的な失敗を見逃す可能性がある。そのため、証拠を調査できるより高度な能力を持つ別のエージェントが評者として必要となる。
人間との比較における優位性
エージェント評者は人間の専門家よりも頻繁に合意形成に至り、単なるLLM評者よりも高い精度を示した。さらに、コストと所要時間が人間の評価に比べて桁違いに少ないという利点がある。
重要な引用
Agent-as-a-Judge is an evaluation approach in which an AI agent investigates another agent's behavior, gathers the evidence it needs, and makes a judgment against defined criteria.
The eval most teams run today is LLM-as-a-judge: an LLM scoring the output of another LLM.
The mismatch is structural, not a prompt-quality problem.
Agents are genuinely competitive with human expertise.
編集コメントを表示
編集コメント
エージェント技術の成熟に伴い、その信頼性を保証する評価プロセス自体も高度化している。この「Agent-as-a-Judge」は、単なる出力チェックを超えて、意思決定のプロセスまで検証する新たな基準となるだろう。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
2024 年 10 月、ある研究論文が「AI エージェントを評価する最良の方法は、別の AI エージェントを使うことだ」と提案しました。そして 2025 年、その論文は機械学習研究の最高峰の一つである ICML に採択されました。これは分野のトップの人々が「このアイデアには価値がある」と判断したことを示す強力なシグナルです。
2026 年 1 月までに、このアイデアについて書かれた記事が十分な数に達し、学術的な調査を支援するに至りました。さらに同年 7 月には、実際に製品として出荷が始まりました。通常、アイデアが論文から実用化されるまで 20 か月もかかることは稀です。それが起きた場合、なぜそうなのかを問う価値があります。
私がここで主張するのは、エージェントの登場によって「失敗」の姿が変わり、評価層もそれに伴って変えざるを得なくなったという点です。もしあなたが現在、評価(evals)を実行しているなら、そのやり方がまもなく変わるはずです。
「Agent-as-a-Judge(エージェントを評決者とする手法)」とは、AI エージェントが別のエージェントの行動を検証し、必要な証拠を集め、定義された基準に基づいて判断を下す評価アプローチです。単一のパスで判定する LLM 判事とは異なり、エージェント判事は一連の行動軌跡を追跡し、ツールの呼び出しや中間ステップを精査できます。そして最終的な結論を出す前に、どの証拠を検討すべきかを自ら決定できるのです。
image「Agent-as-a-Judge」の研究論文から ICML 採択を経て、生産環境での評価製品へ実装されるまでのタイムライン。
なぜ LLM-as-a-Judge はエージェントでは機能しなくなるのか
評価(eval)は出力を採点しますが、エージェントの失敗は「軌跡」の中に潜んでいます。現在多くのチームが採用している評価手法は「LLM-as-a-judge」、つまり別の LLM が生成した出力を LLM 自身が採点する方式です。
この手法では、ルーブリック(評価基準)を含むプロンプトテンプレートを作成し、「カラムマッピング」を実行します。これは、{input} や {output} といったテンプレート変数を、ログデータに保存された特定のフィールドに紐付ける作業です。サンプリングされた各行に対して LLM を1回呼び出すと、ラベル、スコア、解説が返されます。
この設計は、2023 年のアプリケーションには適していました。当時のアプリはプロンプトを受け取って回答を返すだけだったため、もし失敗があったとしても、それは明らかな「回答」の中に直接現れていました。
しかし、エージェントはこの前提を崩しました。エージェントが生成するのは単なる出力ではなく、「軌跡(trajectories)」です。これはユーザーの要求から最終的な応答に至るまでの間にある、モデル呼び出しやツール呼び出し、中間的な判断の全シーケンスを指します。
今、重要視される失敗は、このシーケンスの中に存在しています。本番環境でエージェントを運用している人なら誰でも、以下のような課題のリストを知っているはずです。
- ループに陥って進まなくなる
- 実行途中で文脈を忘れる
- エラーからの回復に失敗する
- ツール呼び出しが静かにゴミデータを返したことを前提に、もっともらしい回答を生成してしまう
- タスクが完了していないのに完了したと主張する
これらすべての問題は、最終的な回答が完璧に見える状態でも同時に発生し得ます。
この不一致はプロンプトの質の問題ではなく、構造的な問題です。評価用のテンプレートに列をマッピングする時点で、実際の失敗箇所を確認する前に「どこに問題があるか」を決めてしまっているのです。もし失敗が、14 番目のステップでツールに渡された陳腐な引数であり、その後にエージェントがそれを隠蔽していた場合、最終的な回答のみを見る評価者(ジャッジ)はそれを検出できません。より高度な視点が必要で、全体像を見渡せる別のエージェントが必要です。評価者は証拠をすべて探し出す能力を持たなければなりません。これは単なる私の推測ではなく、すでに実証済みの研究があります。
「Agent-as-a-Judge」方式は、平均的な人間評価者をすでに上回っています。
その根拠となるのが、Meta AI と KAUST から発表された 2024 年 10 月の論文「Agent-as-a-Judge: Evaluate Agents with Agents」です。シニア著者の一人であるユルゲン・シュミットフーバーは、LSTM(長短期記憶ネットワーク)の共同発明者であり、トランスフォーマー登場前の 10 年間、音声認識や機械翻訳の基盤となったニューラルネットワークアーキテクチャを考案した人物です。この経歴からも、本アプローチが真剣に検討されるべきアイデアであることが伺えます。
論文執筆チームは「DevAI」と呼ばれるベンチマークを作成しました。これは AI 開発タスク 55 件からなるセットで、3 つのオープンソースコーディングエージェントをこれに実行させました。その結果評価は 3 つの方法で行われました。1 つ目は専門家パネルによる評価、2 つ目は LLM(大規模言語モデル)ジャッジによる評価、そして 3 つ目がツールを活用した「Agent-as-a-Judge」です。この方式では、ファイルの特定やコードの読解、生成されたプロジェクトを通じた要件の追跡が可能となっています。
興味深い発見として、3 人の専門評価者が互いに 10〜30% の確率で意見が分かれ、実際の議論を数時間行った後にようやく合意に至ったことが挙げられます。人間による評価は評価のゴールドスタンダードですが、専門家の間ですら一致しないことは古くから知られています。その議論によって導き出されたコンセンサスに対して、エージェント・ジャッジは約 90% の整合性を示しました。一方、単純な LLM ジャッジでは約 70% に留まりました。しかし最も興味深いのは、エージェント・ジャッジが合意に至る頻度が、どの個人専門家のそれよりも高かったという点です。エージェントは人間並みの専門性を持つことが実証されました。
image エージェント・ジャッジによるベンチマーク結果。個々の人間専門家よりも頻繁に合意に至る様子が示されています。
さらに、エージェント・ジャッジは単に人間と同等かそれ以上の性能を持つだけでなく、コストと速度の面で桁違いに優れています。API 呼び出しで約 31 ドルでベンチマーク全体を評価できた一方、専門家の支払時間ではほぼ 1,300 ドルが必要でした。また、完了までの時間は人間の約 2% で済みました。エージェントは疲労することなく継続して実行できるため、人間が抱える判断疲れという大きな課題も解決します。
ただし、エージェントが完璧だったわけではありません。論文の著者たちは、判定者が過去の判断を積み重ねられるよう記憶モジュールを追加しようとしたことがありますが、その結果、初期の誤りが参照される後のすべての決定に伝播してしまい、精度が低下しました。実際に機能したのは、各要件に対して新鮮な証拠を集める方式の判定者でした。
なぜ分野がアジェンティック評価へと向かっているのか
ICML 2025 の採択後、定理証明器を呼び出して数学を検証する判定者や、生成されたコードを実行してから採点を行う判定者、検察官と弁護人のエージェントが裁判官の前で議論する法廷スタイルのフレームワーク、そして NeurIPS 2025 の Mind2Web 2 などのベンチマークにおけるウェブエージェント用の評価エージェントなど、フォローアップ研究が続々と生まれました。医療、法律、金融、教育といった特定ドメイン向けの判定エージェントも登場しています。
2026 年 1 月には分野が十分に成長し、包括的な調査(You et al.)が必要となりました。この調査では、LLM-as-a-judge から agent-as-a-judge への移行を形式化し、判定システムを発展段階の 3 つに分類しています。固定的なマルチエージェントワークフローに従う「手続型判定者」、発見した内容に基づいてツールをルーティング・呼び出す「反応型判定者」、そして独自のルールを記述する「自己進化型判定者」です。この調査が指摘する移行の理由は、現場の実践経験と完全に一致しています。単一パスの判定者は、監査できないバイアスを持ち、現実世界との照合ができず、指示に多くの制約がある場合に処理能力がオーバーロードしてしまうのです。
エージェントを審査員とする手法は極めて能力が高いですが、すべての評価に適用すべきというわけではありません。
階層型評価戦略における「Agent-as-a-Judge」の位置づけ
Arize では、評価システム構築には多層防御のスイスチーズモデルが最適だとよく指摘しています。まず安価で決定論的なコード評価器から始め、その上に LLM による審査員を積み重ね、必要に応じて人間の介入を加えるというアプローチです。各手法には欠点(穴)がありますが、これらを組み合わせることでほぼすべての問題を捕捉できます。Agent-as-a-Judge はこのスタックに追加できる新たな層であり、実行軌跡の失敗や多段階推論の質、あるいは特定の評価ルールを事前に記述していなかった予期せぬ失敗を検出します。
Arize AX は先月、「Agent-as-a-Judge」を実用化した製品をリリースしました。これはサンドボックス内のコーディングエージェントで、ランタイム時にトレースデータを読み込み、列マッピングなしで自然言語の採点指示を受け取り、その判断結果を通常の評価カラムとして書き戻します。同時にリリースされた Signal は、同じコンセプトを生産環境に対して継続的に実行するもので、 recurring な失敗をエビデンスと提案される修正策とともにランク付けされた課題としてグループ化します。他のベンダーも同様の機能を構築するでしょう。なぜならこのロジックに特許性はないからです。失敗が軌跡の中に存在するなら、審査員は軌跡へのランタイムアクセスが必要です。そして何を調査するかについて裁量権を持つランタイムアクセス付きの審査員は、定義上エージェントです。
しかし、これらを採用する前に、審査員自体の故障モードを問う価値があります。
誰が審査員を審査するのか?
上記で引用した「エージェントによる評価」の数値は、人間間の合意が存在するベンチマークから得られたものです。しかし、実際の運用環境のトラフィックにはそのような合意基準がありません。そのため、評価者の判断を人間と照合してスポットチェックを行う必要性は依然として残ります。
本番規模で1回の評価ごとにエージェントを実行するとコストがどれほどかかるのか、また、どの程度積極的にサンプリングすべきなのか。また、評価者自体も非決定論的な性質を持つため、同じトレースに対して同一の評価者が異なる実行間でどれだけ一貫した判断を下すのかも課題です。
さらに研究では、経路評価に特有のバイアスも報告されています。例えば、追加ステップが価値をもたらしたかどうかに関わらず、長い経路を好む傾向などです。
これらの問題はすべて、「出力のみ」の評価手法から離れるべき理由にはなりません。「出力のみ」の評価にも同様の問題があり、さらに経路そのものを見逃すという致命的な欠陥があります。むしろ、これらは元論文が評価者を人間と検証した理由であり、あなたも同様に検証すべき理由です。
評価はエージェントに関する報告書ではなく、エージェントの一部になりつつあります
2024 年の論文は、著者らが「フライホイール」と呼ぶ展望で幕を閉じました。これは、エージェントが評価者として豊富な中間フィードバックを提供し、そのフィードバックから学習することで、評価が単なる成績表(レポートカード)ではなく、トレーニングのシグナルへと変わるという考え方です。
20 ヶ月後、この「評価者」は実在するものとなり、常時稼働しています。さらに、自ら改善策を提案するようになりました。過去のあらゆる世代のソフトウェアでは、評価とはシステムに対して外部から行う行為でした。しかし、アジェンティックな評価(エージェントによる評価)こそが、最初のバージョンです。ここで評価層が主体として参加し、調査を行い、証拠を集積し、得た知見を自ら評価対象へとフィードバックします。
これが業界の行く末であり、テストを書くものではなく、エンジニアリングすべきエージェントとして評価システムを捉えるチームが、まずここに到達するでしょう。
原文を表示
In October 2024, a research paper proposed that the best way to evaluate an AI agent is another AI agent. In 2025 that paper got accepted to ICML, one of the most prestigious conferences for machine learning research, a strong signal that the top people in the field thought there was something there. By January 2026, enough people had written about the idea to support an academic survey. By July 2026, it started shipping in products. Ideas do not usually move from paper to production in 20 months, and when one does, it is worth asking why. I’m here to make the case that agents changed what failure looks like, and so the evaluation layer has no choice but to change with it. If you run evals today, I believe the way you run them is about to change.
Agent-as-a-Judge is an evaluation approach in which an AI agent investigates another agent’s behavior, gathers the evidence it needs, and makes a judgment against defined criteria. Unlike a single-pass LLM judge, an agent judge can follow a trajectory, inspect tool calls and intermediate steps, and decide what evidence to examine before reaching a verdict.
imageTimeline from the Agent-as-a-Judge research paper through ICML acceptance to agent-as-a-judge shipping in production evaluation products.
Why LLM-as-a-Judge breaks down for agents
Evals grade outputs, but agents fail in trajectories. The eval most teams run today is LLM-as-a-judge: an LLM scoring the output of another LLM. You write a prompt template containing a rubric, you do “column mapping” (wiring template variables like {input} and {output} to specific fields of your logged data), and every sampled row gets one LLM call that returns a label, a score, and an explanation. This design was a good fit for the applications of 2023. An app took a prompt and returned an answer, so the failure, if there was one, was sitting right there in the answer.
Agents broke that assumption. An agent produces a trajectory: a full sequence of model calls, tool calls, and intermediate decisions between the user’s request and the final response. The failures that matter now live inside that sequence. Anyone operating agents in production knows the catalog: stuck loops, context forgotten partway through a run, failed recovery from errors, plausible answers built on a tool call that silently returned garbage, and agents claiming a task was done when it wasn’t. Every one of those can coexist with a final answer that looks perfectly reasonable.
The mismatch is structural, not a prompt-quality problem. When you map columns into a judge template, you are deciding where the failure lives before you have looked at it. If the actual failure is a stale argument passed to a tool in step 14 that the agent then papered over, no judge pointed at the final answer will ever see it. You need something more capable, looking at the bigger picture: another agent. The judge has to be able to go looking through all the evidence. And this isn’t just my guess: we already have research that it works.
Agent-as-a-Judge already beat the average human evaluator
That research is “Agent-as-a-Judge: Evaluate Agents with Agents” (Zhuge et al., October 2024) which came out of Meta AI and KAUST. Its senior author is Jürgen Schmidhuber, co-inventor of the LSTM, the neural network architecture that ran most speech recognition and machine translation in the decade before transformers: a strong signal that this is an idea to take seriously.
The team that wrote the paper built DevAI, a benchmark of 55 AI development tasks, ran three open-source coding agents against it, and evaluated the results three ways: a panel of human experts, an LLM judge, and an agent judge equipped with tools for locating files, reading code, and tracing requirements through the generated project.
One interesting finding: the three expert evaluators disagreed with each other 10-30% of the time, and only converged after hours of real-world debate. Human evaluation is the gold standard for evals, but we’ve known for a long time that human evaluators are hardly unanimous. Against the consensus those debates produced, the agent judge scored around 90% alignment. By contrast, the plain LLM judge managed roughly 70%. But the most interesting finding: the agent judge reached the consensus answer more frequently than any individual human expert did. Agents are genuinely competitive with human expertise.
imageAgent-as-a-Judge benchmark results showing an agent judge reaching consensus more frequently than individual human experts.
It’s also worth mentioning that in addition to being as good if not better, an agent judge is orders of magnitude cheaper and faster. The agent judge evaluated the full benchmark for $31 in API calls, against nearly $1300 worth of paid time from the experts, and finished in about 2% of the time it took humans. The agent can also run continuously without getting tired, a major problem for human judgement.
Which isn’t to say the agent was perfect. The paper’s authors tried giving the judge a memory module, which let it build on past judgments, but that made it less accurate because one early mistake propagated through every later decision that referenced it. The judge that worked was the one that gathered fresh evidence for every requirement.
Why the field is moving toward agentic evaluation
After the ICML 2025 acceptance, follow-up work produced judges that verify math by invoking theorem provers, judges that run generated code before scoring it, courtroom-style frameworks where prosecutor and defender agents argue in front of a judge agent, and evaluation agents for web agents in benchmarks like Mind2Web 2 at NeurIPS 2025. Domain-specific judge agents appeared in medicine, law, finance, and education.
By January 2026 the field was large enough to need a comprehensive survey (You et al.), which formalizes the transition from LLM-as-a-judge to agent-as-a-judge and sorts judge systems into three developmental stages: procedural judges that follow fixed multi-agent workflows, reactive judges that route and invoke tools based on what they find, and self-evolving judges that write their own rules. The survey’s diagnosis of why the shift happened matches the practitioner experience exactly: single-pass judges carry biases they cannot audit, cannot verify anything against the real world, and get overloaded when their instructions have many constraints.
Agents as a judge are extremely capable, but that doesn’t mean everything should be an agent.
Where Agent-as-a-Judge fits in a tiered eval strategy
At Arize we often cite the Swiss cheese model of layered defense as the right way to build evals. Start with cheap, deterministic code evaluators, layer on LLM judges, and top off with human intervention when necessary. Each approach has holes, but layered together you catch nearly everything. Agent as a judge is a new layer you can add to the stack, catching trajectory failures, multi-step reasoning quality, and unexpected failures you never wrote a specific eval for.
Arize AX shipped a productized agent as a judge last month: a coding agent in a sandbox that reads trace data at runtime, takes scoring instructions in plain language with no column mapping, and writes its verdicts back as ordinary eval columns. Signal, which shipped alongside it, is the same idea run continuously against production, grouping recurring failures into ranked issues with evidence and proposed fixes. Other vendors will build equivalents, because nothing about the logic is proprietary: if failures live in trajectories, the judge needs runtime access to trajectories, and a judge with runtime access and discretion about what to examine is an agent by definition. Before adopting any of this, though, it is worth asking what the failure modes of the judges themselves are.
Who judges the judges?
The agent as a judge performance numbers I cited above came from a benchmark where a human consensus existed to measure against: production traffic has no such consensus, so spot-checking judge verdicts against humans remains necessary. What does running a full agent per evaluation cost at production scale, and how aggressively should you sample? An agent judge is itself nondeterministic, so how consistent is the same judge on the same trace across runs? And research is already cataloguing biases specific to trajectory judging, such as favoring longer trajectories regardless of whether the extra steps added value. None of these is a reason to stay on output-only evals, which have all the same problems plus blindness to the trajectory. They are the reasons the original paper validated its judge against humans, and the reason you should too.
Evaluation is becoming part of the agent, not a report about it
The 2024 paper closes with an outlook its authors call a flywheel: agent judges providing rich intermediate feedback that agents then learn from, so that evaluation stops being a report card and becomes a training signal. Twenty months later the judges are real, they run continuously, and they propose their own fixes. Every prior generation of software treated evaluation as something you do to a system from outside. Agentic evaluation is the first version where the eval layer participates: it investigates, it accumulates evidence, and it feeds what it learns back into the thing it is judging. That is where the field is going, and the teams that treat their evals as agents to be engineered, rather than tests to be written, will get there first.
The post Where agent evals are going: Agent-as-a-Judge appeared first on Arize AI.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み