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

> Agent-as-a-JudgeはLLM単一呼び出しではなくツール使用・記憶・多段推論を持つ評価エージェントで軌跡全体を採点します。4段階の依存グラフ型評価パイプラインとエンタープライズでの権限分離設計を解説します。

- Canonical: https://kuucorp.com/blog/agent-as-a-judge-evaluation-architecture/
- Date: 2026-07-28
- Last modified: 2026-07-28
- Publisher: Kuu株式会社 (https://kuucorp.com)

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

本記事は[AIエージェントガバナンス](/ai-governance/)の評価設計に連動しています。[LLM-as-a-judgeの評価基盤設計](/blog/llm-as-a-judge-agent-evaluation-enterprise/)と合わせて参照してください。

## 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）ベースで構成し、タイムアウトを設定する（ジャッジがループしても被害が拡大しないよう）。ジャッジエージェント自身のトレースを記録し、[監査ログ](/blog/ai-agent-audit-log-management/)に保存することで、評価プロセスの透明性を確保する。

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

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

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

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

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

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

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

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

## 参考

- [Agent-as-a-Judge: A Survey — arXiv 2601.05111](https://arxiv.org/abs/2601.05111)
- [AI Agent-as-a-Judge: A Framework to Evaluate Agents with Agents — Toloka](https://toloka.ai/blog/ai-agent-as-a-judge-a-framework-to-evaluate-agents-with-agents/)
- [Agent-as-a-Judge: Evaluate Agents with Agents — arXiv 2410.10934](https://arxiv.org/abs/2410.10934)

## まとめ

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

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

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