Agent as a Judge は、あるエージェントが別のエージェントの作業を、生み出された成果物だけでなく、そのエージェントの 実行プロセス — 実際に何をしたかの記録 — を調べることで判定する評価の仕組みである。ここで参照できる唯一の説明は、あるエンジニアリングチームがコーディングエージェント向けに実装した事例であるため、以下はその実装とそれが対象とした問題を記述するものであり、一般的な、あるいは合意された定義ではない。この用語の起源はこの出典からは確定できない。出典は同名の学術論文を参考文献に挙げているが、その内容には触れていない。
出典が差分ではなくプロセスを見るべき理由として挙げるのは、ある種の失敗は成果物からは見えないという点である。出典は 4 つを挙げる。ローカルのテストは通っているのに実環境での検証を省くこと、完了していないタスクを完了と宣言すること（差分にはそれを示すものが何も残らない）、プロセスを迂回すること — 例として挙げられているのは --no-verify による pre-commit フックの回避で、これはプロセスには痕跡を残すが変更には残さない — そして意図された手順に従わないこと、たとえばテスト駆動開発が期待される場面でテストを書かない、チームが使ってほしいスキルを使わない、といったことである。出典の主張によれば、この 4 つはいずれもエージェントがどう作業したかを見ることでしか分からない。
2 つ目の動機として挙げられているのは、正しさとは無関係なものである。チームが、オーケストレーターが複数のワーカーへ並列にタスクを振り分ける形へ移行するにつれ、あるセッションが何に時間とトークンを費やしたのかを事後に再構成することが難しくなった。そのため判定役のレポートは、そのプロセスを可視化する役割も担っている。
用法
記述されている実装では、コーディングエージェントが完了を宣言するたびに判定役が呼び出される。これは Claude Code の Stop フックを通じて行われ、評価は独自のコンテキストを持つ別個のスキルとして実行される。判定は 2 段階で進む。まず、セッションのトランスクリプトから判断を加えずに事実を収集する。実行された Bash コマンド（重複排除したもの）、読み込まれたファイル、ツール使用回数、トークンコストと経過時間である。次に、エージェントが何を主張したかを割り出し、各主張を証拠と照らし合わせて確認しに行く。出典が掲げる原則は推測ではなく検証することであり、例として、エージェントがテストが通ったと言えば gh pr checks で CI の状態を確認し、動作を検証したと言えば実行ログを探す、といったことが挙げられている。証拠が見つからない場合、その評価軸は合格とも不合格ともされず、人間による確認待ちとして保留される。出典によれば、検証方法はタスクに応じて変わり、確認パターンの固定セットを事前に定義しておく必要はないという。
6 つの評価軸がそれぞれ OK、要確認、差し戻しのいずれかで採点され、最も弱い判定が全体の判定となる。前提情報（仕様、設計ドキュメント、Issue、関連コード）が読まれたか、テストだけにとどまらない検証の証拠があるか、危険な操作が行われたか（文脈に照らして判断される — --no-verify、git push --force、rm -rf）、虚偽報告の兆候があるか（主張がログと一致するか）、推奨される開発手法に従ったか、セキュリティチェックが実行されたか、の 6 つである。トークンコスト、使用モデル、作業時間は記録されるが、判定には明示的に寄与しない。
出力は 2 つの読み手に向けた 2 つの形をとる。人間向けの Markdown レポートには、判定、その根拠、そしてセッションの各フェーズにかかった時間のタイムラインが含まれる。フィードバックループ向けの JSON オブジェクトでは、各評価軸が判定とあわせて次に何をすべきかを持つ。示されている例では、保留された評価軸は理由と推奨アクションも持つ一方、合格した評価軸は判定のみを持つ。
適用される場面
- 関心が、結果のコードが正しいかどうかではなく、作業が適切に行われたかどうかにある場面に適用される。出典はこれをコードレビューの代替ではなく補完として位置づけている。チームはすでに人間によるレビューの前段として AI コードレビューツールを運用しており、それによってレビューの精度が向上したと報告したうえで、レビューでは届かない失敗に対処するためにこの仕組みをその上に構築した。
- 実行トランスクリプトが存在して読み取れること、そして判定役がそのトランスクリプトの外にあるシステムに対して主張を確認しに行くためのツールを持っていることを前提とする。記述されている構成は、コーディングエージェントのフックのサポート — 完了時に起動するための
Stopフック — と、判定対象のエージェントとは別のコンテキストで判定役を実行することに依存している。 - 述べられている効果は、人間のレビューに何が届くかに関わるものである。著者は、検証やプロセスが不十分な作業が、人が目を通すプルリクエストの段階より前に捕捉されるようになったと報告しており、これを大きな変化だと述べている。測定値は示されておらず、著者はこれがまだ個人的な試行であると述べている。
- 報告されている限界は精度ではなく適用範囲に関するものである。この仕組みはローカルの開発フローでのみ動作する。著者は、チームの AI ゲートウェイを通じて複数のエージェントにまたがる作業履歴を集約することや、すべてのプルリクエストの作成プロセスを確認することを、実現済みではなく検討中の事項として挙げている。
- 証拠が見つからない場合、設計上あえてその評価軸を合格とも不合格ともせず要確認の判定を返すため、出力は判定であると同時に、人間が確認すべき点のリストでもある。出典が示す実例は、前提情報、危険な操作、虚偽報告の各軸では合格したものの、実環境での検証、セキュリティスキャン、テストファーストの証拠の各軸で保留となったタスクである。
関連用語
- LLM-as-a-Judge — 同じく評価をモデルに委ねるものだが、プロセスではなく出力に適用される
- 軌跡評価 — エージェントを結果ではなく経路によって評価すること
- エージェント型コードレビュー — この仕組みがその上に位置づけられるとされる、成果物側のレビュー
- エージェントフック — 実装が完了時の起動に用いる仕組み
- ヒューマン・イン・ザ・ループ — 保留された評価軸は人間が解決するために提示される
- 検証負債