synthetic data（合成データ）の作り方：LLM学習・評価・テストの実践ガイド

プロバイダーのドキュメントと出力の利用条件は、2026年10月22日に確認しています。 以下のサポートチケット例と試行用データの件数は、説明のために作成したものです。実際のモデル実験の結果ではありません。

合成データとは？synthetic dataの基本と用途

合成データ生成とは、目的を定めて人工的なレコードや事例を作ることです。大規模言語モデル（LLM）を使う開発者にとっては、仕様と少数の利用承認済みの例をもとに、問い合わせ、質問と回答のペア、情報抽出の例、会話などのテキストを生成する方法を指すことが多いでしょう。

運転シミュレーターを思い浮かべてください。実際の道路で同じ状況に出会うのを待たずに、難しい交差点を繰り返し練習できます。しかし、シミュレーターでうまく走れたからといって、その交差点が実際の交通でどの程度現れるかは分かりませんし、どんな道路にも対応できる証明にもなりません。合成データセットでも、練習で網羅できる範囲と、現実についての根拠は分けて考える必要があります。

生成方法によっても役割は異なります。ルールベースの生成器は、「注文合計を各明細の合計と一致させる」といった指示に従います。表形式データの合成器は、列をまたぐパターンを学習します。LLMは、プロンプトと与えられたコンテキストを条件に文章を生成します。これらを組み合わせ、コードで整合性のある注文を作り、その注文に対する顧客の苦情をLLMに書かせることもできます。

合成データと、レコードのマスキングも別物です。顧客の名前を置き換えても、その人に起きた出来事の詳細は残ります。データ拡張は、質問の言い換えなど、既存の例に手を加える方法であり、派生した例は元のデータとの関係を保っています。どちらの処理も、それだけでプライバシーを確保したり、独立した根拠を作り出したりするものではありません。

評価用データでは、期待する回答を独立に検証します

アプリケーション開発では、合成データによる評価は、情報の欠落、指示の矛盾、対応範囲外の依頼、珍しい言い回しなど、既知の失敗パターンを試すのに向いています。ここでいう評価とは、システムの挙動を繰り返し確認できるテストです。

たとえば、アカウントの問題が曖昧なときに、サポートアシスタントが確認を求める必要があるなら、曖昧な問い合わせを意図的に生成します。そのうえで、期待する対応がポリシーに合っているかを人が確認します。生成器の回答に自信が感じられるというだけで、それを正解にしてはいけません。

利用が許可された実際のやり取りがあれば、そこから別の評価セットを用意します。実データを使えない場合は、業務に詳しい人に、独立して事例を作成してもらいます。それによって仕様への適合性は確認できますが、本番環境の利用者全体に対する精度までは分かりません。

ファインチューニングでは、具体的な挙動を学習させます

モデルを用途に合わせて調整する場合、合成した例は、手元のデータに不足している出力形式、分類ルール、応答スタイルを示すのに役立ちます。ファインチューニングとは、例を使った学習によってモデルを更新することです。

出発点は、観察できる失敗にします。たとえば、曖昧なチケットをモデルが繰り返し請求担当に振り分けてしまう場合です。レビュー済みの曖昧な事例を追加し、学習や調整に使っていない例で、調整後のモデルと既存のベースラインを比較します。学習ファイルが大きくなったこと自体は、成功の指標にはなりません。

タスクと合否判定用のデータセットが固まったら、ファインチューニングの手順を使って進めます。問題が、事実に関するコンテキストの不足や変化にあるなら、生成した回答で知識を覚えさせる前に、アプリケーションへ渡すコンテキストを改善してください。

ソフトウェアテスト用の合成データを生成するには

ソフトウェア開発で合成テストデータを作る目的は、アプリケーションのルールを実際に検証することです。フィールドの欠落、重複送信、極端な文章の長さ、不正な状態遷移、データベースの関連レコードなどを扱います。

購入手続きのテストでは、注文、顧客、支払いの関係に整合性が必要です。計算まで言語モデルに任せる必要はありません。制約はコードで実装し、配送先住所と食い違う配送メモなど、自然な文章に意味がある部分でLLMを使います。

データセットを購入する担当者は、どの用途のために作られたものかを確認すべきです。デモに適したデータセットが学習にも役立つとは限りませんし、学習用コーパスがそのまま評価セットになるわけでもありません。

実践例：シードからレビュー済みの候補を作る

まず、生成器に聞かなくても正しい回答を説明できる、範囲の狭いタスクを選びます。ここでは、架空のサポートチケットを billing、access、human_review に振り分けるための候補データを作ります。

架空のポリシーは単純です。支払いや請求書の問題は請求担当へ、サインインやパスワードの問題はアクセス担当へ、内容が不明確な問い合わせや両方の問題を含む問い合わせは人による確認へ回します。顧客が書いていない事実は推測しません。

合成データの例：ラベルを明示した6つのシード

説明用に作成した以下のシードで、分類の境界を示します。

• 「カードに二重で請求されました。」→ billing
• 「請求書に記載されているプランが違います。」→ billing
• 「リセット用リンクの有効期限が切れています。」→ access
• 「パスワードをリセットした後、サインインできません。」→ access
• 「支払ったのにサインインできません。」→ human_review
• 「まだ使えません。」→ human_review

最後のような例は、分類が明らかな例と同じくらい重要です。判断できないという結果も正当だと生成器に伝えるからです。Few-shotプロンプティングのガイドでは、一般的な指示だけでは曖昧になりがちなルールを、例でどう伝えるかを説明しています。

検証を通った候補は、たとえば次のような形になります。これは説明用のレコードであり、実際に取得したAPI出力ではありません。

{
  "case_id": "billing-frustrated-indirect-a",
  "text": "Another invoice with the wrong plan, seriously?",
  "proposed_label": "billing",
  "policy_reason": "The customer identifies an invoice problem."
}

重要な成果は、由来を追跡でき、レビューを終えた事例です。最初の生成で要求件数がすべて返ったかどうかは二の次です。目標件数を満たすためだけに、品質の低いセルを補充してはいけません。

合成データ生成ツールでできること：ドキュメントを読む

ツールは、工程のどこを担うかで選びます。モデルAPIは、コードからモデルの出力を要求するためのインターフェースです。バッチサービスは、そのリクエストの実行をスケジュールします。データセット用ライブラリは生成とフィードバックを整理し、表形式データの合成器は構造化データの関係を学習します。どれを使っても、合格基準を決める必要はなくなりません。

生成AIで合成データを作る：バッチAPIの役割

OpenAI APIのBatchでは、JSONLファイルで送信したリクエストを非同期に処理できます。JSONLは、1行につき1つのJSONオブジェクトを記述する形式です。ドキュメントでは、一意の custom_id が必要とされ、出力の順序が入力順と異なる可能性があると説明されています。識別子で結果を対応付け、失敗や生成の未完了を確認してから、候補データとしてパースします。OpenAI Batchのドキュメント。

AnthropicのClaude APIには、独立したMessagesリクエストを処理するMessage Batchesがあります。結果は成功、エラー、キャンセル、期限切れに分かれ、各結果と入力は custom_id で結び付きます。運用上の注意点は、バッチが受理されたことと、すべての例の処理が完了したことは別だという点です。データセット全体を生成し直すのではなく、識別子を使って未完了の処理を再試行します。Claudeのバッチ処理ドキュメント。

GoogleのGemini APIでは、リクエストオブジェクトを直接含める方法と、JSONLファイルをアップロードする方法でBatchを利用できます。ファイル方式のリクエストには、対応する結果を識別する key を付けます。大規模なオフラインデータセットにはファイル方式を使います。ドキュメントに記載された処理時間は目標なので、対話的なワークフローを即時完了に依存させないようにしてください。Gemini Batchのドキュメント。

以下は、リンク先のドキュメントで確認した、ジョブの分割に関わるバッチの制限です。複数のジョブを通じて作成できるデータセット全体の上限ではありません。

バッチのリクエストと候補の例は、別の単位です。成功したリクエストごとに複数の候補が返るなら、両方の件数を追跡します。通信エラーだけでなく、パースの失敗、応答拒否、出力の途中切れも記録します。HTTPレスポンスが成功しただけでは、そのデータを学習用の1行として使えるとは限りません。

Distilabel：生成とフィードバックを整理する

Distilabelは、合成データとAIフィードバックのためのフレームワークです。生成、評価、データ処理のステップを組み合わせてパイプラインにします。ドキュメントでは、分類、抽出、対話、指示データの生成といった用途が説明されています。使い捨てのスクリプトが、複数の生成・フィルタリング工程に膨らんできたときに役立ちます。Distilabelのドキュメント。

このプロジェクトはApache-2.0ライセンスを採用しています。リポジトリには、元の開発者はプロジェクトを離れ、コミュニティの協力者が保守を担っているとも記載されています。採用するバージョンを固定し、検証してください。実務上の課題として残るのは評価器です。モデルの判断をワークフローに組み込んでも、その判断が独立したものになったり、正しくなったりするわけではありません。Distilabelのリポジトリ。

Faker：言語モデルを使わずにテストデータを用意する

Fakerは、プロバイダーを通じて架空のデータを生成するPythonパッケージです。ロケールの指定や乱数シードに対応しています。自然言語の推論よりも、値を制御したフィールドが必要な場合に、アプリケーションのテスト用フィクスチャを作るのに役立ちます。リポジトリでは、ライセンスはMITとされています。Fakerのドキュメント、Fakerのリポジトリ。

業務上の関係は、自分でコードに落とし込む必要があります。住所、日付、取引を別々に生成しても、現実的な顧客履歴にはなりません。可能な限りテスト用に予約された識別子やドメインを使い、生成したフィクスチャがメッセージ送信などの本番処理を引き起こさないようにします。

Synthetic Data Vault：テーブルとその関係をモデル化する

Synthetic Data Vault、略してSDVは、表形式データの合成と統計的な評価を提供します。ドキュメントには、単一テーブル、系列データ、関連する複数テーブルを扱う方法が記載されています。学習済みの合成器は、与えられたデータから学習します。利用が許可された元データセットが必要であることに変わりはありません。SDVのドキュメント。

SDVの GaussianCopulaSynthesizer は、古典的な統計手法で列の分布や関係を学習します。CTGANSynthesizer は、生成器と、それに対抗する識別器を使って学習するモデルである敵対的生成ネットワークを利用します。どちらも、データと、その構造を記述したメタデータを入力として受け取ります。これらは表形式データの合成器であり、汎用のチャットモデルではありません。Gaussian Copulaのドキュメント、CTGANのドキュメント。

課題は、タスクに必要な特性をどこまで保てるかです。列の分布が似て見えても、まれな組み合わせ、テーブル間のルール、後段のモデルの挙動が維持されている証拠にはなりません。子レコードと親レコードを結ぶ外部キーなど、アプリケーションが依存する関係を検証してください。

合成データ生成器は、何が不足しているかで選びます

言語表現のバリエーションが足りないなら、モデルAPIを使います。生成とフィードバックを再現可能な形で管理する価値が、依存関係を増やす負担を上回るなら、Distilabelを追加します。フィクスチャの値を制御したいならFakerを選びます。テーブル間の統計的な関係が重要で、モデル化が許可された元データを持っているなら、SDVを検討します。

ラベル付けのポリシーが曖昧な問題を、より大きな生成器の購入で解決しようとしてはいけません。それは、ここで紹介したどのツールを使うよりも前に解決すべき問題です。

生成した出力を学習に使う場合、利用規約はどうなっているか

ほかのモデルの学習に使う例を生成するモデル、つまり教師モデルを選ぶ前に、出力の利用制限を確認します。以下は、前述した3社のホスト型LLMプロバイダーの標準規約の要約です。個々の学習プロジェクトが条件を満たすと判断するものではありません。

• OpenAI： Services Agreementは、出力を競合するAIモデルの開発に使うことを制限しています。明記された例外には、主な用途がデータのカテゴリ分け、分類、整理であり、第三者に配布されず、商用提供もされないモデルと、OpenAIが指定するサービスを使ったモデルのカスタマイズがあります。Services Agreement。
• Anthropic： Commercial Termsでは、Anthropicが明示的に承認した場合を除き、競合するAIモデルの学習を含め、競合する製品やサービスを構築する目的でサービスにアクセスすることを禁じています。Commercial Terms。
• Google： Gemini APIのAdditional Termsは、サービスを競合モデルの開発に使うことを禁じています。また、Google Search Groundingの条項では、Grounded ResultsやSearch Suggestionsを使った学習が別途禁止されています。Gemini APIの利用規約。

ライブラリのソフトウェアライセンスは、そのライブラリが呼び出すモデルの利用規約、モデルの重みのライセンス、元の例に対して自分が持つ権利とは別の問題です。出力の所有権だけでは、これらすべての問題に答えは出ません。

テストデータのプライバシーは、別途検証が必要です

合成されたデータであることは、プライバシーの保証にはなりません。機密レコードを未承認の生成サービスにコピーした場合、後から架空に見える代替データを作っても、その開示を取り消すことはできません。

Stadler、Oprisanu、Troncosoによる合成データ公開の研究では、評価対象のモデルによって、プライバシー上の利点と有用性が異なることが示されています。実務上の教訓は、「合成」という言葉を匿名性の証明とみなさず、公開するデータと生成プロセスを評価することです。USENIXの研究論文。

ソフトウェアテストの目的を満たせるなら、承認されたスキーマとポリシーをもとに書いた架空のシードを優先します。実際の統計的パターンを保つ必要がある場合は、承認された環境で元データを扱い、生成データセットからどのような情報が明らかになり得るかを評価します。

直接的な識別子、コピーされた文章、まれな組み合わせ、相手がすでに知っているかもしれない情報との照合可能性を確認します。名前を変えても、特徴的な出来事、場所、日付を残せば、本人を特定できる場合があります。機微なデータを公開する際は、少数の目視確認と重複検査だけでは不十分です。想定する脅威と提供先に見合ったプライバシー評価が必要です。

プロバイダー自身が学習にデータを使うかというポリシーと、自分が出力を学習に使えるかという権利は、別の話です。たとえばGeminiの無料サービスの規約は、機微な情報を送信しないよう注意を促しています。一方、有料サービスのデータ利用条件では、プロンプトと応答をGoogle製品の改善に使わないとしています。また、EEA、スイス、英国では、無料での利用にも有料サービスのデータ利用ルールが適用されます。Geminiのデータ利用条件。

プロバイダーが学習に使わないと約束していても、ローカルで実行していても、できあがったデータセットを安全に共有できる証明にはなりません。公開前の審査が終わるまで、来歴情報とアクセス制御を維持します。

合成データへの期待は、どこから過剰になるのか

最も大きな誤解は、生成する行数を増やせば、根拠の不足を埋められるというものです。生成データは練習の幅を広げ、失敗をあぶり出せますが、同じ思い込みを大規模に再生産することもあります。

表現が違っても、状況は同じかもしれません

文章がすべて異なるデータセットでも、ごく少数の状況を繰り返しているだけかもしれません。フィルタリング後に、業務ルール、曖昧さ、失敗パターンのどれが残っているか、シナリオの網羅範囲を追跡します。

チケットの例では、請求書への苦情を何度繰り返しても、請求とアクセスの両方に関わる問い合わせの不足は補えません。類似度の高い例をレビューし、採用した例だけでなく除外した例も確認します。品質フィルターが厳しすぎると、追加したかった難しい事例を、気付かないうちに取り除いてしまうことがあります。

言い換えてもバイアスは残ります

偏りのあるシードを言い換えれば、その前提まで消えるとは限りません。文体、方言、つづりの正確さ、関係する利用者層をまたいで、ラベルの選び方を確認します。ポリシー上の根拠がなければ、不満を示す問い合わせや誤字の多い問い合わせを、別の宛先に振り分けるべきではありません。

判断に無関係な属性だけを変えた対応する事例を、レビュアーに比較してもらいます。ラベルが変わったら、シード、プロンプト、フィルターをまとめて調べます。生成器と評価器が、同じ誤りを強め合うこともあります。

モデルの自己採点は、もっともらしく見えてしまいます

Zhengらは、LLMを評価者として使った場合に、提示順、冗長さ、自己優遇に関するバイアスがあることを報告しています。モデルは、測りたい特性ではなく、言葉遣いや見せ方を高く評価する場合があります。LLM-as-a-judgeの研究。

答えを機械的に検証できる箇所では、結果が一意に決まるルールで確認します。主観を伴う評価では、人の判断を基準に評価器を調整し、可能な範囲で生成器の正体を伏せ、判断が食い違う例をレビューします。評価器のプロバイダーを変えれば、共通する依存要因を減らせることはありますが、誤りが互いに独立になる保証はありません。

LLM-as-a-judgeのガイドでは、スコアを信頼する前に評価器を確認する方法を説明しています。合成データ生成では、どの例を学習上の正解とするかを評価器に決めさせる前に、この確認を済ませます。

モデル崩壊は特定のリスクであり、すべてに当てはまる結論ではありません

Shumailovらは、生成データを使った再帰的な学習を研究し、元の分布のうち出現頻度が低い部分が失われ得ることを示しました。これは、元の根拠となるデータを、モデル自身から派生したデータで繰り返し置き換えることに注意が必要だと示しています。ただし、レビュー済みでタスクに特化した合成データによるファインチューニングが、必ず失敗するという証明ではありません。Natureの研究論文。

利用が許可された元の根拠となるデータを保持し、まれな事例を意図的に残し、後段の挙動を手を加えていないベースラインと比較します。この評価を代替できる、合成データと実データの万能な混合比率はありません。

次の開発で、何を変えるべきか

不足している事例を具体的に挙げ、正しい挙動を書き、安定したルールに照らして生成候補をレビューできるなら、今すぐ着手できます。小さな組み合わせ表から始め、役立つ事例が増えるセルだけを広げます。

レビュアーの間で正解ラベルが一致しない場合や、独立した合否判定用のセットがない場合は、ファインチューニングを待ちます。先にポリシーと評価の問題を解決してください。

目的がデータベースへのデータ投入、境界値の確認、取引の整合性の検証であれば、通常のフィクスチャを使います。より単純なデータでは試せない挙動がある箇所にだけ、生成した文章を追加します。

次のリリース前に、学習や調整に使っていない同じ事例で、ベースラインと変更後のシステムを比較します。サポートの振り分けなら、誤った振り分けやエスカレーションの見落としをカテゴリ別に調べます。狙った挙動が改善し、ほかの箇所で許容できない悪化が起きない場合に限り、その合成データを使い続けます。

合成データについてよくある質問

AIシステムの構築と評価に役立つ実践ガイドを、ニュースレターで受け取ることができます。