LLM-as-a-Judge とは、モデルに出力を生成させるのではなく評価させる手法である。別のインスタンスが構造化されたルーブリックに照らして作業を採点または検証し、その採点では判定を断言するのではなく根拠を示すことが求められる。エージェントのワークフローではステップ間のゲートとして使われ、判定者（ジャッジ）が合格を出さなければ、作業はそのまま先へ進まずに差し戻される。以下は Context Engineering Kit がこの手法をどう適用しているかの説明である。同プロジェクトはこの手法を、自らの発明ではなく、評価パターンに関する公開研究から取り入れたものとして扱っている。
用法
このキットは判定を二つのスケールで用いる。品質ゲートとしては、仕様駆動開発 の計画および実装の各ステップを、次のステップが始まる前にあらかじめ定めた検証ルーブリックに照らして評価する。サブエージェント駆動開発 の実行プリミティブとしては、いくつかの形で現れる。完成した作業に対して構造化されたルーブリックと根拠に基づく採点で行うジャッジ、合格するまで繰り返すリトライループの中で実装サブエージェントと組になる独立したジャッジ、合意を形成するか、あるいは合意を無理に作らずに不一致をそのまま報告する、反復的な討論を行う複数のジャッジ、そしてジャッジのサブエージェントと並行して用いられ、仕様となる材料をその場で生成するメタジャッジのサブエージェントである。いずれの場合もプロジェクトがジャッジに求めるものは同じで、意見ではなく、根拠とルーブリックにまで遡れる判定である。
この仕組みが依拠している性質は独立性である。ジャッジは作業を行ったサブエージェントとは別のものとして説明されており、だからこそその判定は、作業を生成したエージェント自身の確信よりも価値を持つ。
決定論から委任へ：AI ネイティブなソフトウェアエンジニアリングとエージェント型エンジニアの進化 は、この手法をより広い評価の実践の中に位置づけ、軌跡評価（最終的な答えがばらついても、エージェントが正しい順序でツールを選んだかを問うもの）や、ゴールデンデータセットに対する意味的類似度と並べている。こうしたことがなぜ重要なのかについての同論文の主張は、従来の実践では評価が後回しにされるのに対し、エージェント型の実践では評価こそが中心的な成果物になる、というものである。出力が非決定的であるため、品質は、敵対的なエッジケースを含む厳選された評価データセットと自動採点を通じて確立しなければならないからである。
二つ目の説明は、ツールキットではなく本番システムからのもので、私たちはマルチエージェントのリサーチシステムをどう構築したか が、Anthropic の Research チームが何をどのように採点したかを述べている。そもそもジャッジを用いた理由として挙げられているのは、リサーチの出力が単一の正解をほとんど持たない自由形式のテキストであり、プログラムによる評価になじまないという点である。そのルーブリックには五つの基準があった。事実の正確性（主張は情報源と一致しているか）、引用の正確性（引用した情報源は主張と一致しているか）、網羅性（求められたすべての側面を扱っているか）、情報源の質（質の低い二次情報源よりも一次情報源を優先したか）、ツールの効率（適切なツールを妥当な回数だけ使ったか）である。
ジャッジの構造について同チームが報告した知見は、ジャッジは多いほどよいという直感に反するものである。同チームは、複数のジャッジにそれぞれ別の構成要素を評価させる実験を行い、単一のプロンプトによる単一の LLM 呼び出しで、0.0 から 1.0 のスコアと合否判定を併せて出力させる方法が、最も一貫性が高く、人間の判断とも最もよく一致することを見出した。この手法は、テストケースに明確な答えがあり、ジャッジが意見を形成するのではなく正しさを確認する場合に特に有効だとされている。これは、後述するルーブリックの要件が述べているのと同じ前提条件である。
同じ記事は、この手法が単独では成り立たないことも明言している。自動評価が見逃したものを人間のテスターが見つけた例が報告されており、その中には、初期のエージェントが、学術 PDF や個人ブログのように権威はあるが検索順位の低い情報源よりも、SEO に最適化されたコンテンツファームを一貫して選んでしまう傾向があった。同チームは、リサーチエージェントのプロンプトに情報源の質に関するヒューリスティクスを加えることでこれを解決した。同記事の全体的な立場は、自動評価を導入していても手動テストは依然として不可欠だというものであり、その理由は、エージェントをテストする人間は評価が見逃すエッジケースを見つけるからである。
適用される場面
この手法が適用できるのは、確認すべき品質を、作業を見る前にルーブリックとして書き出せる場合である。受け入れ基準、検証ステップ、レビューの観点などがそれにあたる。基準を事前に述べられない場合、ジャッジには採点の拠り所がなく、このパターンはモデルに結果を気に入ったかどうかを尋ねるだけのものに成り下がる。
エージェントシステムの評価に関するキットのガイダンスは、LLM-as-a-Judge を多次元のルーブリックやバイアス緩和と並べて挙げているが、誰のバイアスが問題なのかは述べていない。キットが方向を明示している箇所では、レビュー対象の作業に含まれるバイアスを緩和するのはジャッジのサブエージェントである。この手法について最も強い主張は、この点を念頭に置いて読むべきである。同プロジェクトは、ジャッジに基づく品質ゲートによって、エージェントが動作しない、あるいは誤った解決策を生み出すケースが完全に排除されると述べているが、これは独立した評価ではなく内部での本番利用に基づく、自らのツールについての自己評価であり、周辺の資料が裏づける以上に強い主張である。
独立した情報源は、限界についてより率直である。決定論から委任へ：AI ネイティブなソフトウェアエンジニアリングとエージェント型エンジニアの進化 は、支配的な採点の仕組みそのものが不完全であり、厳密さのためにはそれを認める必要があると述べている。サーベイや実証研究は、LLM ジャッジに位置、冗長さ、自己選好などの系統的なバイアスがあることを記録しており、どのジャッジを選ぶかによってモデルの順位が入れ替わることもある。したがって、モデルをモデルで採点することは循環性を持ち込むことになり、キャリブレーション、参照によるアンカリング、ジャッジのアンサンブルはそれを部分的にしか緩和しない。同論文の結論は、頑健性は、静的な精度を超えてデータ、モデル、意図のドリフトへの反応を評価するテスト・評価・検証・妥当性確認の枠組みを通じて定量化しなければならない、というものである。また同論文は、未解決の問題の一つとして評価の妥当性を挙げている。すなわち、オープンエンドなタスクについて、構成概念妥当性があり、再現可能で、汚染に強い評価を確立すること、そして見せかけのツール使用の順序を評価してしまう軌跡指標を避けることである。
関連用語
- サブエージェント駆動開発 — 判定が実行プリミティブとして使われる場面
- 仕様駆動開発 — 判定がフェーズゲートとして使われる場面
- 決定論から委任へ：AI ネイティブなソフトウェアエンジニアリングとエージェント型エンジニアの進化 — 上で述べた、記録されているジャッジのバイアスと循環性に関する注意の出典
- 軌跡評価 — 同論文がこの手法と並べて挙げる、補完的な手法