シンセティックテスト（Synthetic Test）とは、合成データ（synthetic data）で生成したテストケースを使って AI システムを自動評価する手法である。実運用ログだけでは網羅できないエッジケース・敵対的入力・規制要件をテスト入力として「合成」し、回帰検知と品質保証の起点にする。

本記事は、AI 導入企業の QA・PM・エンジニアを対象に、シンセティックテストの定義と LLM-as-a-Judge との違い、評価できる品質観点、導入4ステップ、よくある失敗を整理する。読み終える頃には、自社の AI プロジェクトにシンセティックテストを組み込むための初動設計ができるようになる。

シンセティックテストは「テスト入力を合成データで作る」ことで、実データでは集まらないシナリオを網羅し AI の品質を継続的に測る手法だ。 似た用語に「合成データ」「LLM-as-a-Judge」があるが、それぞれ役割が異なる。本章ではまずシンセティックテスト（Synthetic Test）の輪郭を整理し、評価器（Judge）との使い分けを明確にする。

シンセティックテストは、AI システムの入力側に「合成データ」を流し込み、想定通りの出力が得られるかを自動的に判定するテスト手法である。従来のソフトウェアテスト（unit test や e2e test 等）では、開発者が入力値と期待値を手書きで用意する。これに対しシンセティックテストでは、テスト入力そのものを大量に生成・変形して網羅性を上げる点が特徴だ。

合成データ（synthetic data）とは、実データを直接コピーせず、ルール・統計モデル・生成 AI などで人工的に作り出したデータを指す。シンセティックテストにおける合成データの主な役割は次の3つに整理できる。

• 実データが少ないドメインでテスト件数を増やす
• 個人情報を含まない代替データで本番に近い検証を行う
• 通常運用では発生しにくいエッジケース・異常系を意図的に作り出す

つまりシンセティックテストは「合成データ × 自動評価」の組み合わせであり、合成データはその燃料である。

シンセティックテストと混同されやすいのが LLM-as-a-Judge である。両者は AI 評価における役割が明確に違う。

実務では両者を組み合わせる。シンセティックテストで「100 件のテストケースを生成」し、LLM-as-a-Judge で「100 件の応答を採点」する流れが一般的だ。Judge そのものの設計や Judge プロンプトの作り方は、別記事「LLM-as-a-Judge とは？AI 出力を AI で評価する手法とハルシネーション検知の実装」で詳しく解説している。

生成 AI は同じ入力でも応答が揺らぐ。実データだけでは検出できない品質劣化を、合成データで先回りして拾う必要が出てきた。 加えて全面施行済みの EU AI Act など規制の動きで「評価記録の提出」が義務化される領域も広がっており、AI 開発者にとってシンセティックテストの網羅性は監査対応の前提条件になりつつある。

従来のソフトウェアでは、本番ログを集めれば代表的な入力パターンをほぼ網羅できた。生成 AI システムでは、それだけでは足りない理由が3つある。

第一に、ハルシネーション（hallucination）の発生条件は属人的でログに現れにくい。同じ質問を複数回投げても、毎回同じハルシネーションが起こるわけではないため、実データの「収集」では再現テストが組めない。

第二に、プロンプトインジェクションのような敵対的入力は、ユーザーが「実際に試した結果ログに残った」時点で既に被害が出ている。実データを待っていては手遅れであり、合成データで先に攻撃シナリオを試行する必要がある（ペネトレーションテストの発想を AI に拡張する形になる）。

第三に、AI エージェントは外部 API・ツール呼び出しを含む長い対話を行う。エッジケースの組み合わせは指数的に増え、本番ログだけでは網羅率が常に不足する。

合成データを使えば、これら「実データには出てこない／出るまで待てない」入力をシンセティックテストとして自由に生成できる。

全面施行済みの EU AI Act は、ハイリスク AI システムに対してテスト・評価記録の文書化を求めている。日本でも内閣府の AI 事業者ガイドラインや、経産省・総務省のガイダンスでリスクベースの評価が推奨される方向にある。

これらの共通点は「リスクシナリオを事前に想定し、想定通りに動くかを文書化された手続きで検証せよ」という要請だ。実データだけに依存していると、想定したシナリオが本番ログに現れなかった場合に「検証していない」と判断されかねない。シンセティックテストはリスクシナリオを意図的に合成データとして作り、評価結果を再現可能な形で残せるため、規制対応との相性が良い。

シンセティックテストは単一の品質指標を測るものではなく、機能品質・安全性・ロバスト性の3観点を統合的に扱える。 どの観点を優先するかは AI システムのユースケースによって変わるが、最低限この3軸でテストケースを設計しないと「動いて見えるが本番で崩れる」AI になりやすい。

最も基本的な観点が機能品質である。AI に与えたタスクが、正しく達成されているかを測る軸だ。RAG であれば「質問に対して正しい根拠を引用できているか」、要約であれば「重要事実を欠落なく拾えているか」、エージェントであれば「ユーザー指示の意図通りツールを呼び出したか」が該当する。

機能品質をシンセティックテストで測るときは、タスクの正答パターンと典型的な誤答パターンを合成データで作り、Judge が両者を区別できることを確認する。実装上は Judge の採点軸（accuracy / faithfulness / completeness 等）を先に固定し、その軸で点が取れるようにテストケースを設計するのが安定する。

安全性は、AI が「やってはいけない応答」をしないかを測る観点である。代表的な攻撃シナリオはプロンプトインジェクション、jailbreak、機密情報の漏洩などで、シンセティックテストではこれらの攻撃文をテンプレート化して大量生成し、AI ガードレールが正しく作動するかを検証する。

合成攻撃シナリオは公開されたレッドチーミング辞書をベースに自社用に拡張するのが現実的だ。例えば「業務マニュアルを丸ごと出力させる」「内部システムプロンプトを開示させる」などのパターンを、表現を変えて数百〜数千件に水増しする。これにより、表面的なキーワードフィルタでは防げない言い換え攻撃まで網羅できる。

ロバスト性は、想定外の入力に対して AI システムが極端に劣化しないかを測る観点である。古典的なソフトウェアテストでも境界値分析は基本だが、AI では「日本語に英語が混在」「タイ語の口語表現」「数値の単位違い」「非常に長い入力」など、自然言語特有のバリエーションが膨大になる。

シンセティックテストでは、ベースとなる入力を1つ用意し、それを系統的に変形（言語切り替え・誤字挿入・冗長化・短縮など）して数十〜数百のバリアントを生成する。同じ意図の入力に対して応答が大きく揺れる場合、その AI システムはロバスト性が低い。多言語サービスを提供する当社の現場では、日本語・英語・タイ語・ラオス語の4言語で同じ意図の入力を合成し、応答品質の言語間差を可視化することが多い。

シンセティックテストは「テストケース生成 → 採点 → 運用組み込み」の流れで段階的に立ち上げるのが現実的だ。 一気に網羅率 100% を目指すのではなく、リスクが高い領域から評価ループを回し始め、CI/CD と回帰検知に組み込んでいく。

Step 1 は評価対象と品質基準の定義である。「どの AI 機能を、どの観点（機能・安全・ロバスト）で、どのスコアを合格ラインとするか」を 1 ページにまとめる。ここを曖昧にしたまま生成に進むと、後でテストケースの良し悪しが判定できなくなる。

Step 2 はシンセティックテストケース生成である。生成方法は3つに大別できる。

1. ルールベース生成: テンプレート＋変数差し込みで大量化（境界値テストに強い）
2. LLM 生成: 既存データを LLM に渡して類似ケースを派生させる（多様性に強い）
3. ハイブリッド: ルールで骨格を作り、LLM で言い換え・自然化を行う

実務ではハイブリッドが扱いやすい。生成したケースには必ず期待出力（または合否基準）を付け、後段の Judge が採点できるようにする。

Step 3 は LLM-as-a-Judge による自動採点である。シンセティックテストで生成した数百〜数千件の入力を AI に流し込み、応答を Judge プロンプトで採点する。採点軸はあらかじめ Step 1 で決めた品質基準と一致させる。Judge 自体の精度については別記事の解説を参照してほしい。

Step 4 は継続運用への組み込みである。シンセティックテストは1回流して終わりではなく、プロンプト変更・モデル更新・ナレッジベース更新のたびに回す回帰テストとして組み込む。CI 上で「合格ライン未満なら本番デプロイをブロック」する運用が定着すると、属人的な品質判断から脱却できる。テストケース自体も定期的に追加し、本番で見つかった問題は必ずシンセティックテストに取り込む（インシデント駆動の網羅率向上）。

シンセティックテストは導入しただけでは効果が出ず、合成データの偏りや評価指標の運用設計で頻繁につまずく。 当社が AI 導入支援で見てきた典型的な失敗パターンと、その回避策を整理する。

最も多いのが「合成データだけで品質を判断する」失敗である。LLM が生成したテストケースは、その LLM が得意な表現に偏りやすい。結果として「シンセティックテストでは合格だが、本番ユーザーの自然な日本語では失敗」というギャップが生まれる。

対策は、必ず合成データと実データの両方で評価し、スコア差をモニタリングすることだ。差が一定以上開いたら、合成データの分布が本番から乖離しているサインとして再生成する。具体的には四半期ごとに本番ログから 50〜100 件をサンプリングし、シンセティックテストと並行採点する運用が現実的である。

もう一つの典型的な失敗は、PoC で華々しい数字を出したものの、運用フェーズで誰もテストを回さなくなるパターンだ。原因は2つあり、一つは Judge コストが高すぎて毎日回せないこと、もう一つは合格ラインが厳しすぎて常に失敗扱いになり感覚が麻痺することだ。

対策は、評価セットを「フル」と「スモーク」に分けることである。スモーク版は 30〜50 件の代表ケースのみで、毎デプロイで自動実行する。フル版は週次・月次でリリース判定に使う。さらに合格ラインは段階的に上げる前提で初期は緩めに設定し、運用が定着してから引き上げると失敗扱いの慣れを防げる。

Q1: シンセティックテストと従来の unit test / e2e test はどう使い分ける？

unit test や e2e test は決定的なソフトウェアの正しさを保証する手法で、入力と期待値が固定的だ。シンセティックテストは AI の非決定性を前提にした品質「分布」の評価で、合格は「期待スコアの達成率」で判定する。同じプロジェクトで併用するのが基本で、AI 部分だけシンセティックテスト、周辺の API は従来テスト、というすみ分けが扱いやすい。

Q2: 合成データを生成する LLM は、評価対象の AI と同じモデルでよい？

非推奨である。同じモデルで生成と回答を行うと、モデル特有の癖がテスト入力にも応答にも入り込み、本来検出すべき弱点が見えなくなる。テストケース生成と本番モデルは別系統（別ベンダー、別世代）にし、Judge もさらに別モデルにする三層分離が望ましい。

Q3: シンセティックテストは何件くらいテストケースを用意すればよい？

ユースケースの広さによるが、立ち上げ時は機能品質 100 件・安全性 100 件・ロバスト性 100 件の計 300 件を目安にする。CI で毎回回すスモーク版は 30〜50 件、フル評価は 1,000 件規模を半年〜1 年で目指す形が現場感覚に合う。

Q4: 多言語サービスでは言語ごとにシンセティックテストを作るべき？

作るべきである。同じ意図の入力でも、言語によってモデルの応答品質や安全性挙動は大きく変わる。当社では日本語・英語・タイ語・ラオス語など、サービスが対応する全言語で並行にシンセティックテストを回し、言語間スコア差を可視化することを推奨している。

シンセティックテスト（Synthetic Test）は、合成データで作ったテストケースを LLM-as-a-Judge で自動採点し、AI システムの機能品質・安全性・ロバスト性を継続的に評価する仕組みである。 実データだけでは網羅できない非決定性とエッジケースをカバーし、規制対応・回帰検知・運用品質の三方を支える基盤となる。

導入は「評価対象の定義 → シンセティックテストケース生成 → Judge での採点 → CI/CD 組み込み」の4ステップが基本で、合成データのバイアスと運用継続性に注意すれば、PoC 止まりにせず本番品質保証に乗せられる。Judge の設計や Judge プロンプトの組み立て方については「LLM-as-a-Judge とは？AI 出力を AI で評価する手法とハルシネーション検知の実装」を併せて確認してほしい。

当社では AI 導入後の継続的な品質保証を、こうしたシンセティックテストと LLM-as-a-Judge を組み合わせた評価ループとしてご支援している。AI システムを単発の PoC で終わらせず、運用に乗せきりたい場合は、評価設計の段階からのご相談が有効だ。