Agent-as-a-Judge——軌跡評価設計と実装

本番エージェントが1日1万件のタスクを処理するとき、LLM-as-a-judgeで最終出力のみを採点しても「どのステップで誤判断が起きたか」はわからない。ツール呼び出しの選択ミス、中間ステップでの根拠の脱落、不要なループ——こうした軌跡上の障害は最終出力が「それらしく見える」ことで隠れる。Agent-as-a-Judgeは、評価者自身をエージェントとして設計し、被評価エージェントの実行軌跡全体をツール使用・多段推論を駆使して検証するアーキテクチャだ。

本記事はAIエージェントガバナンスの評価設計に連動しています。LLM-as-a-judgeの評価基盤設計と合わせて参照してください。

LLM-as-a-judgeとAgent-as-a-Judgeはどう違うのか

LLM-as-a-judgeはテキストのみを入力とする単一LLM呼び出しで最終出力を評価しますが、Agent-as-a-Judgeはファイルアクセス・コード実行・記憶を備えた評価エージェントが軌跡全体を多段推論で検証します。

LLM-as-a-judgeの本質的な限界は入力がテキストのみである点だ。採点プロンプトにエージェントの出力テキストと評価ルーブリックを渡すと、LLMはそのテキストを読んでスコアを返す。この設計では人間評価との相関係数は0.8〜0.9程度に達するが、「ツールが正しく呼ばれたか」「実際にコードは動いたか」「途中ステップで情報が落ちなかったか」は検証できない。

Agent-as-a-Judgeは評価器自体をエージェントとして構成する。

観点	LLM-as-a-judge	Agent-as-a-Judge
入力	テキスト（出力のみ）	テキスト＋ファイル＋ログ＋実行結果
評価対象	最終出力の品質	実行軌跡全体（中間ステップ含む）
ツール使用	なし	コード実行・ファイル読み取り・サンドボックス実行
多段推論	なし	あり（依存グラフ構築→検証→フィードバック生成）
コスト	低（1 LLMコール）	高（複数ステップの推論とツール使用）

「最終出力が正しく見えるが軌跡が壊れている」ケースが増えるほど、Agent-as-a-Judgeの優位性が現れる。コード生成・複雑なデータ処理・マルチホップの情報取得タスクが典型だ。

Agent-as-a-Judgeの4段階評価パイプラインはどう設計するか

Agent-as-a-Judgeは依存グラフ構築→コード/ファイル特定→サンドボックス実行→ステップ単位フィードバック生成の4段階で動作します。各段階でツールを使い、人間が追跡可能な証拠を記録します。

具体的な実行フローを示す。

フェーズ1: 依存グラフ構築

タスク要件を解析し、どのモジュール・ファイル・ツールが正しく使われるべきかの依存グラフを生成する。これにより「評価すべき中間チェックポイント」が明確になり、場当たり的な採点を避けられる。

``task: "顧客データCSVを読み込み、月次売上を集計してJSONで出力する" 依存グラフ: ① csv_reader ツール呼び出し → 成否 ② データ変換ロジック → 集計式の正確性 ③ json_writer ツール呼び出し → スキーマ適合性``

フェーズ2: 対象コード/ファイルの特定

被評価エージェントが生成したコード・設定ファイル・中間出力を特定し、ジャッジエージェントが実際にファイルを開いて内容を確認する。LLMジャッジではテキストとして渡すしかないが、Agent-as-a-Judgeはファイルシステムから直接読み取れる。

フェーズ3: サンドボックス実行と検証

生成されたコードやスクリプトを隔離されたサンドボックスで実際に実行し、戻り値・副作用・生成ファイルを検証する。「コードが動いたか」という真実が確認できる。

フェーズ4: ステップ単位フィードバック生成

依存グラフの各ノードについてPASS/FAILを証拠付きで記録する。「③json_writer: FAIL — 出力キーが total ではなく sum であり、スキーマと不整合」のように、被評価エージェントの開発者が修正できるレベルの詳細フィードバックを生成する。

エンタープライズでのジャッジエージェント権限設計

ジャッジエージェントには被評価エージェントのログ・生成物への読み取り権限のみを付与します。書き込み権限や本番DB接続は原則禁止し、サンドボックス内でのみコードを実行させる設計がセキュリティの基本です。

ジャッジエージェントは評価対象のファイルやコードを「読み・実行する」ために相当な権限を要求する。この権限設計を誤ると、評価インフラ自体がアタックサーフェスになる。

最小権限の原則（評価用スコープ）:

``READ: 評価対象エージェントのトレースログ、生成ファイル、中間出力 EXEC: 隔離サンドボックス内のみ（本番DB・外部APIへのアクセスは禁止） WRITE: 評価スコアレポートのみ（評価対象ファイルへの書き込みは禁止）``

サンドボックスはコンテナ（例: Docker）ベースで構成し、タイムアウトを設定する（ジャッジがループしても被害が拡大しないよう）。ジャッジエージェント自身のトレースを記録し、監査ログに保存することで、評価プロセスの透明性を確保する。

マルチテナント環境ではテナント分離が必須だ。テナントAのエージェントを評価するジャッジが、テナントBのログにアクセスできてはならない。エンタープライズのマルチテナント分離設計と同じ原則を評価基盤にも適用する。

評価スケールが大きくなると、ジャッジエージェントの実行コストが課題になる。1評価あたり複数のLLM呼び出し＋サンドボックス実行が発生するため、高頻度で全件に適用するのは非現実的だ。実用的にはリスクベースサンプリングを採用し、ヒューリスティック層（100%）→ LLM-as-judge（10〜20%）→ Agent-as-a-Judge（1〜5%の高リスクサンプルまたは品質劣化が疑われるケース）の3層に配置する設計が安定している。詳細な評価基盤設計・スケーリング支援についてはKuuのRDEサービスが対応しています。

Agent-as-a-Judgeの限界とリスク管理

Agent-as-a-Judgeには評価バイアス・ログ偽造による評価欺瞞・推論の不透明性という3つの本質的限界があります。定期的な人間キャリブレーションとジャッジ自身のトレース記録が対策の柱です。

研究段階から実用に移すにあたり、認識すべき限界が3つある。

評価バイアス: ジャッジエージェントのベースモデルが訓練データに含む偏りを引き継ぐ。特定の出力スタイルやフォーマットを過大評価・過小評価する傾向が生じる可能性がある。定期的に人間がジャッジ出力をサンプルレビューし、スコアと実際の品質の乖離を計測するキャリブレーションが必要だ。

ログ偽造（評価欺瞞）: 被評価エージェントが評価基準を学習し、ジャッジが評価するログを意図的に改ざんする「ゲーミング」リスクがある。評価対象エージェントに評価基準を直接公開しない設計、ジャッジのサンドボックス実行による実際の動作検証（テキストログではなく実行結果を見る）が対策になる。

推論の不透明性: ジャッジエージェント自身が多段推論するため、「なぜそのスコアになったか」の説明責任がLLM-as-a-judgeより複雑になる。ジャッジのトレースをすべて記録し、エージェントの可観測性基盤と統合して人間がレビューできる状態を保つことが前提だ。

参考

まとめ

Agent-as-a-Judgeは、ツール使用・記憶・多段推論を持つ評価エージェントが被評価エージェントの実行軌跡全体を4段階パイプラインで検証するアーキテクチャだ。最終出力の品質だけを採点するLLM-as-a-judgeでは見えない「軌跡上の障害」を可視化し、コード生成・複雑データ処理・マルチホップ推論タスクの品質保証を定量化する。

実装では最小権限のサンドボックス設計、リスクベースサンプリングによるコスト制御、定期的な人間キャリブレーションを組み合わせることで、エンタープライズの評価スケールに耐える基盤を構築できる。

評価基盤の設計・Agent-as-a-Judge実装・エンタープライズスケールへの展開についてはKuuのRDE（Reinvention Deployed Engineering）サービスにご相談ください。