1. なぜ今「評価データそのもの」なのか——枠組みではなく燃料の話
評価の議論は「どう測るか（How to measure）」に偏りがちだ。だが実運用でボトルネックになるのは、ほぼ例外なく「何を測るか（What to measure against）」——つまり評価に使うケースの量・質・鮮度である。エンジンの設計図が完璧でも、燃料タンクが空なら車は動かない。
とくにエージェント（自律的にツールを呼び、複数ステップで動くAI）は、単発の質問応答モデルよりも「壊れ方」の種類が多い。ツールの選択ミス、引数の取り違え、途中でループに陥る、権限のないAPIを叩く、途中まで正しいのに最後の要約でしくじる——これらは静的な質問リストでは捕まえにくい。本番で実際に起きた失敗を評価データに変換し続ける仕組みがなければ、評価は初期スナップショットのまま老朽化していく。
結論を先に言えば、成熟したエージェント運用ほど、評価データを「一度作る資産」ではなく「本番から回収し続ける流れ（フライホイール）」として扱っている。本記事の狙いは、その流れを具体的な部品に分解して設計可能にすることだ。
2. 用語整理：ゴールデンセット／評価ケース／トラジェクトリ
設計に入る前に、混同されやすい3つの用語を切り分けておく。この区別が曖昧なまま議論すると、「テストデータ」という一語に複数の別物が押し込まれて破綻する。
| 用語 | 指すもの | 粒度 | 主な用途 |
|---|---|---|---|
| ゴールデンセット (golden dataset) | 「正解」が人手で確認・固定された評価用ケースの集合。回帰テストの基準線。 | データセット（数十〜数千ケース） | リリース前の合否判定・回帰検知 |
| 評価ケース (eval case) | 1件分の入力＋期待される結果＋合否基準（アサーション）＋メタ情報のまとまり。 | 1レコード | ゴールデンセットの構成単位 |
| トラジェクトリ (trajectory) | エージェントが1タスクを処理した実際の軌跡。入力→思考→ツール呼び出し→出力までの全ステップ列。 | 実行ログ1本 | 評価ケースの原材料／失敗分析 |
関係を一文でまとめると——本番のトラジェクトリを選別・加工して評価ケースを作り、その評価ケースを束ねたものがゴールデンセットになる。フライホイールとは、この矢印を一方向で終わらせず、本番→評価ケース→ゴールデンセット→本番改善→また本番、と回し続けることを指す。
3. ゴールデンセット（評価データセット）の作り方
3-1. 「1ケース」に何を持たせるか
評価ケースは「入力と正解のペア」だけでは足りない。エージェント評価では、少なくとも次の要素を1レコードに含めておくと、後の自動採点と分析が一気に楽になる。
| フィールド | 内容 | 例 |
|---|---|---|
| input | ユーザー入力・初期状態・与える文脈 | 「先月の請求書をPDFで送って」 |
| expected / reference | 期待される最終出力、または満たすべき条件 | 正しい請求書PDFの添付＋対象月の一致 |
| assertions | 合否を機械判定するチェック（完全一致でなく基準で持つ） | 「対象月が7月」「金額が¥120,000」「送付ツールを1回だけ呼ぶ」 |
| trajectory基準 | 途中の振る舞いへの要件（任意） | 「権限確認APIを先に呼ぶ」「リトライは2回まで」 |
| metadata | カテゴリ・難易度・出所・作成日・バージョン | category=請求, source=prod, created=2026-08 |
ポイントはexpectedを「文字列の完全一致」で持たないこと。エージェントの出力は言い回しが揺れるため、完全一致は偽陰性の温床になる。「満たすべき条件（assertions）」に分解し、数値・キー事実・ツール呼び出し回数など検証可能な断片で持つ。文章品質はLLM-as-a-Judge、事実・構造はコードのアサーション、という二層で採点するのが基本形だ。
3-2. 分布を設計する——「集めた」ではなく「割り付けた」ケース
ゴールデンセットの価値は件数ではなくカバレッジ（網羅性）で決まる。100件の似たケースより、40件でも領域を割り付けたケースの方が強い。最低限、次の2軸でマトリクスを引き、各セルに目標件数を割り当てる。
- 機能軸：エージェントが扱うタスク種別（検索／要約／予約／計算／外部API操作 …）
- 難易度・リスク軸：定型／曖昧入力／エッジケース／敵対的入力（プロンプトインジェクション等）／高リスク操作（決済・削除）
とくに「高リスク×エッジケース」のセルは意図的に厚くする。頻度は低いが、壊れたときの損害が最大の領域だからだ。ここが薄いゴールデンセットは、平均スコアだけ立派で本番の致命傷を見逃す。
3-3. サイズと更新頻度の目安
絶対の正解はないが、実務的な出発点として：スモークテスト用に高速な20〜50件（毎PRで回す）、リグレッション用に100〜500件（毎リリース）、四半期に一度のフルスイートに数百〜数千件、という三段構成が扱いやすい。小さく速いセットと、大きく網羅的なセットを分けることで、CIの速度と網羅性を両立できる。
4. 本番トラジェクトリからの評価ケース自動収集
ここが本記事の核心だ。ゴールデンセットを手作りで維持し続けるのは、現実的にすぐ限界が来る。持続可能にする唯一の方法は、本番で実際に流れたトラジェクトリを評価ケースの原材料として自動で吸い上げることである。
4-1. 収集パイプラインの4段
| 段 | やること | 要点 |
|---|---|---|
| ① 捕捉 | 本番トラジェクトリを構造化ログとして残す（入力・各ステップ・ツール入出力・最終出力・レイテンシ・コスト） | OpenTelemetry等でスパン化しておくと後工程が楽 |
| ② 抽出（サンプリング） | 全ログから「評価ケース候補」だけを選別 | 失敗シグナル優先＋層化ランダムで多様性も確保 |
| ③ 加工（正解化） | 候補にラベル・期待条件を付与し、機密をマスキング | LLMで下書き→人手で確定の二段 |
| ④ 昇格 | 確定ケースをバージョン付きでゴールデンセットに追加 | ホールドアウトへ入れるかを明示的に判断 |
4-2. 「失敗ケース」を自動で釣り上げるシグナル
すべてのトラジェクトリを人手で見るのは不可能なので、拾うべき候補を機械的に絞る。エージェントの失敗は、次のような観測可能なシグナルとして表面化する。
- 明示的な負フィードバック：👎、低評価、途中離脱、会話のやり直し
- 暗黙のやり直し：同一ユーザーが直後に類似入力を再送（＝1回で解けていない）
- 実行時の異常：ツールのエラー／タイムアウト、リトライ多発、ステップ数やループの上限到達
- ガードレール発火：権限拒否、ポリシー違反検知、出力バリデーション失敗
- オンラインJudgeの低スコア：本番中に走らせている軽量な自動採点が閾値割れ
- コスト・レイテンシの外れ値：想定を大きく超えた実行（非効率な軌跡のサイン）
これらで釣った「失敗寄り」の候補を優先的にケース化する一方、成功トラジェクトリからも層化ランダムで少量を混ぜる。失敗ばかり集めると分布が歪み、「正常系の退行」を検知できなくなるからだ。
4-3. ラベリング：LLM下書き＋人手確定の二段
候補トラジェクトリに「何が正解だったか」を付ける工程がボトルネックになりやすい。ここはLLMに正解・期待条件・カテゴリの下書きを生成させ、人間は確認と修正だけ行う二段構えが効率的だ。完全自動ラベルはゴールデン（＝人手確認済み）の定義に反するので、少なくともホールドアウトに入れるケースは必ず人手で確定する。
4-4. 機密・PIIのマスキング（収集の前提条件）
本番ログには個人情報・社外秘・認証情報が混ざる。評価データセットは開発者が繰り返し閲覧し、時にJudgeモデルへ送られる二次利用物である以上、収集パイプラインの②〜③でPII検出とマスキング／トークナイズを必須化する。マスキングで壊れて評価不能になるケースは合成データで置き換える。ここを後回しにすると、フライホイール自体がコンプライアンス上の負債になる。
5. リークと陳腐化（eval rot）を防ぐ設計
本番からデータを回し始めると、新しい二大リスクが生まれる。リーク（評価が甘くなる）と陳腐化＝eval rot（評価が的外れになる）だ。フライホイールを回すほどこの2つが効いてくるので、設計の中心に置く。
5-1. データリークの型と対策
| リークの型 | 何が起きるか | 対策 |
|---|---|---|
| 訓練・チューニングへの混入 | 評価ケースがファインチューニングやfew-shot例に紛れ、モデルが「答えを暗記」 | ホールドアウトを訓練系から物理分離。IDでの重複チェック |
| プロンプトへの混入 | ゴールデンの入力例をシステムプロンプトの例示に流用 | プロンプト用例と評価用例のプールを分ける |
| ホールドアウト崩壊 | デバッグ中に評価ケースを何度も見て、実装をそれに過剰適合 | 「見て良い開発セット」と「本番判定用の秘匿セット」を分離 |
| 近似重複 | 本番由来ケースが訓練データとほぼ同一（言い換え違いだけ） | 埋め込み類似度で近傍を検出し除外 |
原則は「二つの財布」だ。日々いじる開発セット（見て良い・改善のために使う）と、リリース可否を決める秘匿ホールドアウト（頻繁に見ない・触らない）を明確に分ける。フライホイールで入ってきた新規ケースは、どちらへ入れるかを昇格時に必ず判断する。
5-2. 陳腐化（eval rot）の型と対策
eval rotとは、コードが腐る（bit rot）ように評価データが現実とずれていく現象を指す。放置された評価セットは、いつの間にか「もう存在しない仕様」を測り続ける。
- 仕様変更による陳腐化：プロダクト要件が変わり、かつての「正解」が今は不正解に。→ 期待条件（assertions）にもバージョンを持たせ、仕様変更時に洗い替え。
- ツール・API変更：呼ぶべきツール名や引数が変わり、トラジェクトリ基準が古くなる。→ ツール定義の変更をトリガーに該当ケースを棚卸し。
- 分布ドリフト：本番の入力傾向が季節・機能追加で変化し、ゴールデンが現実の縮図でなくなる。→ 本番分布とゴールデン分布を定期比較し、乖離をアラート。
- 飽和：モデルが賢くなり全ケース満点で、識別力がゼロに。→ 難易度を引き上げた新ケースを継続注入。
5-3. 鮮度を運用指標として持つ
陳腐化を「気づいたら直す」で運用すると必ず腐る。鮮度そのものをSLO化するのが要点だ。実務的な指標の例：ゴールデンセット内で「本番由来かつ90日以内」のケース比率、直近の仕様変更に対して未棚卸しのケース数、各カテゴリの最終更新日。これらをダッシュボードに載せ、閾値割れで棚卸しタスクを自動起票する。評価データにも“賞味期限”を設けるという発想だ。
6. LLM-as-a-Judge自体を較正する
評価データが良くても、それを採点するJudge（LLM審判）が狂っていれば全体が狂う。Judgeは「測る道具」であり、道具には校正（キャリブレーション）が要る。ここを飛ばすと、綺麗なスコアが出るのに何の保証もない状態になる。
6-1. Judgeが持つ代表的なバイアス
- 位置バイアス：2つの回答を比較させると、先に出した方を選びやすい。
- 冗長性バイアス：長い回答を「丁寧＝高品質」と誤認しやすい。
- 自己選好バイアス：自分（同系統モデル）が書いた文体を高く評価しやすい。
- 甘さ・寛大性：全体的に高得点に寄り、不合格を出し渋る。
6-2. 較正の手順
Judgeを信頼する前に、人手ラベルという“真値”に対してJudgeを検証する。最小の手順は次の通り。
- 人手で丁寧に採点したアンカーセット（数十〜百件、合格・不合格・境界を含む）を用意。
- Judgeに同じケースを採点させ、人手ラベルとの一致率（あるいは相関）を測る。
- 不一致ケースを読み、Judgeのプロンプト／評価ルーブリックを修正（採点基準を明文化・具体化）。
- 位置バイアス対策として順序を入れ替えた二重採点、冗長性対策として長さを基準から除外する明示指示を入れる。
- 同一入力を複数回採点させ再現性（ブレの小ささ）を確認。ブレが大きければ温度を下げ、ルーブリックを厳格化。
そして忘れてはならないのが、Judgeの一致率そのものも“陳腐化”するということ。モデルやルーブリックを更新したら、アンカーセットで再較正する。アンカーセットはゴールデンセットとは別に、Judgeを測るための小さなメタ評価データとして維持する。
7. 「評価データ・フライホイール」の全体設計
ここまでの部品を1本のループに組み上げる。フライホイールは、回すほど評価データが「本番の現実」に近づき、評価の識別力が上がっていく自己強化ループだ。
| フェーズ | 入力 | 処理 | 出力 |
|---|---|---|---|
| ① 稼働 | ユーザー入力 | 本番エージェントが応答 | トラジェクトリ＋各種シグナル |
| ② 回収 | トラジェクトリ | 失敗シグナル優先＋層化サンプリング | 評価ケース候補 |
| ③ 精製 | 候補 | PIIマスキング→LLM下書き→人手確定 | 正解付き評価ケース |
| ④ 昇格 | 評価ケース | 開発セット／秘匿ホールドアウトへ振り分け・バージョン付与 | 更新されたゴールデンセット |
| ⑤ 判定 | ゴールデンセット | 較正済みJudge＋コードアサーションでCI採点 | 合否・回帰レポート |
| ⑥ 改善 | 回帰レポート | プロンプト／ツール／モデルを修正しデプロイ | 改善された本番エージェント → ①へ |
横断して回り続ける2つの「番人」が、鮮度SLO（陳腐化を検知して棚卸しを起票）とJudge較正（アンカーセットで審判を定期校正）だ。この2つが止まると、フライホイールは“速く回る劣化装置”に化ける。回転数そのものより、回すたびに毒（リーク・腐り）を抜けているかが本質である。
8. 30日ではじめる導入ロードマップ
いきなり全部は作れない。小さく回し始めて、フライホイールを“既に回っている状態”にすることを最初のゴールにする。
- Day 1–7：計器化。本番トラジェクトリを構造化ログで残す。最低限、入力・ツール入出力・最終出力・👎/リトライ等のシグナルを記録。
- Day 8–14：最小ゴールデン。機能×リスクのマトリクスを引き、各セルに数件、計30〜50件の手作りケースをassertions付きで作る。CIで回す。
- Day 15–21：回収パイプライン。失敗シグナルで候補を日次抽出→LLM下書き→人手確定の流れを1本通す。PIIマスキングを組み込む。
- Day 22–26：二つの財布。開発セットと秘匿ホールドアウトを分離。新規ケースの昇格ルールを決める。
- Day 27–30：番人を起動。Judgeをアンカーセットで較正し、鮮度SLOをダッシュボード化。閾値割れで棚卸しを自動起票。
この時点で「本番の失敗が翌週には評価ケースになっている」状態になれば、フライホイールは回り始めている。あとは回転を止めないことだけが仕事になる。
9. よくある質問（Q&A）
Q1. ゴールデンセットは何件あればいいですか？
件数より分布です。まずは機能×リスクのマトリクスを埋める30〜50件から始め、CIを回せる状態を優先してください。そこから本番回収で網羅性を厚くし、スモーク用（数十件）・回帰用（数百件）・フル（数百〜数千件）の三段に育てるのが現実的です。
Q2. 本番ログを評価に使うのはプライバシー的に問題では？
だからこそ収集パイプラインの中にPII検出・マスキングを必須工程として組み込みます。マスキングで評価が壊れるケースは合成データで代替します。利用範囲・保持期間・アクセス権を社内規程と整合させたうえで運用してください（本記事は法的助言ではありません）。
Q3. LLM-as-a-Judgeだけで採点してはいけないのですか？
文章品質のような主観評価にはJudgeが向きますが、数値・キー事実・ツール呼び出し回数などはコードのアサーションで機械判定する方が確実です。二層で使い分け、Judgeは人手アンカーで較正してから信頼してください。
Q4. 「評価スコアは高いのに本番が壊れる」のはなぜ？
典型的には(1)評価データの陳腐化（もう存在しない仕様を測っている）、(2)リーク（実装が評価セットに過剰適合）、(3)分布のズレ（本番の実入力を代表していない）のいずれかです。鮮度SLOと秘匿ホールドアウトの分離が処方箋になります。
Q5. どのくらいの頻度で棚卸しすべきですか？
カレンダーではなくイベント駆動が基本です。仕様変更・ツール定義の更新・本番分布のドリフト検知をトリガーに該当カテゴリを棚卸しします。加えて鮮度SLO（例：本番由来90日以内ケースの比率）を下限割れしたら起票、という自動化を併用します。
10. まとめ
エージェント評価は「どう測るか」で語られがちだが、現場を止めるのは「何で測るか」——評価データの量・質・鮮度だ。枠組みを整えた次にやるべきは、本番トラジェクトリを評価ケースへ変換し続けるフライホイールを組むことである。
要点は3つ。第一に、ゴールデンセットは件数でなくカバレッジで設計し、正解は完全一致でなく検証可能なassertionsで持つ。第二に、本番の失敗シグナルで候補を釣り上げ、PIIマスキング→LLM下書き→人手確定でケース化する。第三に、フライホイールを回すほど効くリーク（二つの財布で分離）と陳腐化（鮮度SLO化）を設計の中心に置き、採点役のJudge自体もアンカーセットで較正し続ける。
「測れる」の前に「何で測るか」を資産化できたチームだけが、賢くなり続けるエージェントを安全に本番へ出し続けられる。次回のAgentOps連載では、この評価結果を運用ループ（デプロイ・監視・ロールバック）へつなぐ設計を扱う予定だ。
関連記事
免責事項
本記事はエージェント評価データの設計・運用に関する一般的な情報提供を目的としたものであり、特定製品の推奨や、法務・コンプライアンス上の助言を行うものではありません。本番ログの利用にあたっては、各組織のプライバシーポリシー・関連法令・社内規程に従ってください。記載内容は執筆時点（2026年8月）の一般的な実務動向に基づいており、実装の詳細は利用するフレームワークやツールによって異なります。
コメント