本番エージェントの品質検証に使えるテストケースを手作業で集めると数週間かかるうえ、エッジケースが抜け落ちる。実際のユーザー操作ログからデータを抽出しようにも、プライバシー制約と件数の偏りがネックになる。この問題をLLM自身に解かせる手法——合成評価データ生成——が2025年以降の標準プラクティスになりつつある。
合成評価データとは何か
合成評価データとはLLMが生成した入出力ペアで、エッジケースを含む多様なシナリオを短時間で大量に準備できます。
合成評価データ（synthetic eval dataset）とは、LLMを使って人工的に生成したテスト用の入出力ペアを指す。本物のユーザー操作データを収集するには時間・量・プライバシーの三重の制約があるが、合成データなら設計者が意図したシナリオ分布を自由に制御できる。
Anthropicのエージェント評価ガイドが強調するのも「まず20〜50件の単純なタスクから始め、実際の使用パターンに基づいたテストケースを作れ」という点だ。合成データはこの「実際の使用パターン」を加速度的に拡張する手段として機能する。前提として「2名の専門家が独立して同じpass/fail判定に到達できる」レベルの明確さが各テストケースに必要であり、生成時にもその明確さを設計の基準とする。
なぜエージェント評価に合成データが有効なのか
AIエージェント評価には状態依存・非決定性・ロングテールの三重課題があり、実データだけではエッジケース網羅が困難です。
エージェント評価には通常の入出力評価にはない3つの課題がある。
状態依存性: エージェントの応答は前のツール呼び出し結果に依存するため、静的な入力サンプルでは再現困難なシナリオが存在する。
非決定性: 同じ入力でも異なるツール順序が生まれる。pass@k（k回中1回以上成功）・pass^k（k回すべて成功）という指標を組み合わせて複数回測定する必要がある。
ロングテール問題: 日常的なシナリオはログに豊富だが、例外処理やセキュリティ境界付近のケースは実データではほとんど発生しない。
合成データ生成はこのロングテール問題に直接効く。温度パラメータと多様なペルソナを組み合わせることで、実業務では滅多に発生しないシナリオを意図的に大量生成できる。エージェントガバナンスの観点からも、本番前にセキュリティ境界のテストケースを設計で網羅できる点は大きい。
生成パターン：4つのシナリオ設計
合成評価データの設計は4パターンで構成され、それぞれ異なる設計観点で品質を確保します。
① ペルソナ駆動ユーザーシミュレーター
LLMに「あなたはXXXという役職の担当者です。以下のシステムを使って〜してください」というペルソナを与え、ユーザーとして振る舞わせる手法。ペルソナの多様性（経験レベル・業界・リクエストの丁寧さ）がデータの分布を決める。
実装ではtemperature=1.0付近で複数回生成してバリエーションを確保し、生成後にLLM-as-judgeで「このリクエストはリアルか？」を自動フィルタリングする二段構えが標準的だ。
② ツール呼び出しシナリオ生成
エージェントが使うツール定義（Function callingのスキーマ）を入力として与え、「このツールセットで解ける典型的なユーザーリクエストを生成せよ」とLLMに指示する。生成されたリクエストには、期待されるツール呼び出し順序（ゴールデントレース）を人間またはLLMが付与し、回帰テストの正解データとして使う。
ゴールデンデータセットによる回帰テストで解説している手法の実態は、多くの場合このパターンで生成されたシナリオが基盤になっている。
③ マルチターン会話データ生成
複数ターンの会話を生成する際は、StateGenが示すアーキテクチャが参考になる——「ユーザーシミュレーター / エージェント本体 / ツールシミュレーター / LLMジャッジ」の4ロールを独立したLLMループとして構成する設計だ。ツールシミュレーターが「バックエンドが真実」の不変条件を維持することで、ツール呼び出しハルシネーションを構造的に排除できる。
④ 敵対的ケース・エッジケース
カバーすべき3類型は「通常シナリオ」「複雑なエッジケース」「敵対的ケース（プロンプトインジェクション等）」。敵対的ケースはプロンプトインジェクションの多層防御と対になる評価データとして位置づけ、セキュリティ検証のパイプラインに組み込む。
品質管理——合成データの罠と対策
合成データの罠はLLMのモードバイアスで、多様性強制・シード制御・実データ混入の3施策でカバレッジを確保します。
合成データは「リアルに見えるが実際の分布とズレている」というモードバイアスが発生しやすい。対策は3つある。
多様性の強制: ペルソナ・業界・難易度をパラメータ化し、各セルから均等サンプリングする。Torque DSLのoneOf()コンビネータのように生成空間を事前に構造化し、同じパターンが重複生成されるのを設計で防ぐ方法も有効だ。
シード制御と再現性: 評価データは本番環境のモデル更新と並走するため、seed値で再生成可能にしておく。モデル更新前後で同一データセットを使えば回帰を数値として可視化できる。
実データとの混入（ハイブリッド構成）: Anthropicが推奨するように「本番で報告されたエラーを20〜50件ゴールデンセットに取り込み、合成データで補完する」ハイブリッド構成が現実的な落とし所だ。合成データ単体での評価は本番性能との乖離が生まれやすい。
合成データの品質検証にはLLM-as-judgeを使ってリアリズムスコアを自動採点し、スコアの低いサンプルを除外するパイプラインを構築する。Kuuの評価・可観測性支援では、このパイプライン設計から実装まで一体でサポートしている。
規模別の留意点（SMB / エンタープライズ）
SMB: まず20〜50件の手作業テストケースをゴールデンセットとして確立し、合成生成はエッジケース補完に絞る。DeepEvalやLangfuseの合成データ機能をAPIから呼ぶだけで開始でき、大きな初期投資は不要だ。小さなゴールデンセットを継続的に回すことが、予算内で評価品質を高める最短経路になる。
エンタープライズ: 大規模チームではRDE（Reinvention Deployed Engineering）との連携で評価パイプラインをCI/CDに統合し、本番トラフィックサンプリングと合成生成を組み合わせた継続的評価基盤を構築する。SSO連携でのアクセス制御と評価データのデータレジデンシー要件も設計に含める必要がある。
参考
- Demystifying evals for AI agents — Anthropic Engineering
- Synthetic Dataset Generation for LLM Evaluation — Langfuse
- State-Grounded Multi-Agent Synthetic Data Generation for Tool-Augmented LLMs — arXiv
まとめ
合成評価データ生成はエージェント評価の「種まき」に相当する。実データ収集待ちでテストが進まないという状況を解消し、ペルソナ駆動・ツール呼び出し・マルチターン・敵対的ケースの4パターンを組み合わせることでエッジケースを意図的にカバーできる。モードバイアスを抑える設計規律（多様性強制・シード制御・実データ混入）を加えれば、本番品質に近い評価基盤を構築できる。
エージェント評価の設計から合成データ生成パイプラインの構築まで、Kuuの評価・可観測性支援でご相談ください。