LLMで合成データ(synthetic data)を作る｜評価セットと学習データを、実データが無いところから立ち上げる

評価データを作ろうとして、最初につまずくのは「そもそも材料が無い」という壁です。まだリリース前でログが無い、ログはあるが個人情報だらけで開発環境に持ち出せない、想定している困ったケースは月に数件しか来ない。この記事は、その壁に対して「データそのものをLLMに作らせる」という選択肢を、実務の判断材料として整理します。評価データセットの立ち上げと、ファインチューニング用データづくりの両方を扱いますが、主題は一点に絞ります。データが無い、または少ないときに、どう作り、どう疑うか、です。

なぜLLMでデータを作るのか#

理由は「面倒だから」ではありません。データが構造的に手に入らない場面が、実務にはいくつもあります。

• 実データが少ない。リリース前や社内限定の機能では、そもそも入力ログが数十件しかありません。
• 機密で使えない。実データはあっても、個人情報や取引先情報を含むため、開発環境や外部APIに持ち出せません。
• レアケースが集まらない。誤字だらけの質問、範囲外の依頼、断るべき依頼といった「困ったケース」は、頻度が低いぶんログには数件しか現れません。評価したいのは、まさにそこです。
• 評価セットに本番データを入れたくない。評価用データセットはCIやリポジトリに置いて共有したいのに、本番の生データはその置き場に置けません。

Microsoftの公式ドキュメント(現在はFoundry(classic)ポータル向けのレガシー記事として提供されています)も、Azure AI Evaluation SDKのSimulator(プレビュー)を「本番データが無い状態で、典型的なユーザークエリに対するアプリケーションの応答をテストするための、エンドツーエンドの合成データ生成機能」と位置づけています。安全性評価向けには、敵対的なやり取りを生成するAdversarialSimulatorが別に用意されています。ベンダー側も「本番データが無い時期の埋め合わせ」という位置づけで提供している、と読めます。

評価用と学習用では、要件が違う#

同じ「LLMに作らせたデータ」でも、用途が変われば求める性質が変わります。ここを混ぜると、どちらにも中途半端なデータができます。

評価用は「入力を作る」仕事、学習用は「出力を作る」仕事だと考えると整理しやすいです。評価用では、入力さえ現実に似ていれば、正解ラベルは人が付けても構いません(むしろそのほうが安全です)。学習用では、出力の質が上限を決めます。

作り方の型#

手法名は無数にありますが、実務で使う型は多くありません。

1. シード実データからの言い換え・拡張#

手元にある少数の実データを種(シード)にして、言い換えや条件変更で増やします。Self-Instructは、人が書いた175件のシードタスクから出発して、モデル自身に新しい指示を書かせ、52,000件の指示と82,000件の入出力インスタンスを作った研究です。少数の実データがある場合は、まずこの型から始めるのが素直です。

拡張の方向を制御したい場合は、WizardLMのEvol-Instructが参考になります。既存の指示を段階的に書き換えて複雑にする「in-depth」と、まったく別の指示へ広げる「in-breadth」の2方向を分けている点が実務でも使えます。難しくするのか、範囲を広げるのか、を意識せずに「もっと作って」と頼むと、似た難易度の似た話題ばかりが増えます。

2. 属性の組み合わせによる条件付き生成#

もっとも制御しやすいのがこの型です。軸をこちらで先に決め、その組み合わせで生成させます。

RAG評価ツールのRagasは、この考え方をペルソナとして実装しています。文書からナレッジグラフを作り、そこに役割(ペルソナ)を掛けて質問を生成します。既定のクエリ配分は単一ホップ0.5、マルチホップ(抽象)0.25、マルチホップ(具体)0.25で、簡単な参照だけでなく複数文書をまたぐ質問も混ざるように設計されています。ペルソナをナレッジグラフから自動生成する関数も用意されています。

3. 失敗例の逆生成#

「正しい入力を作って正しく答えられるか見る」だけでは、評価は甘くなります。先に失敗の型を言葉にして、その失敗を引き起こす入力を作らせる、という逆向きの作り方が効きます。

• 「主語が抜けていて、どの製品の話か特定できない質問」
• 「社内でしか通じない略語が2つ以上入っている質問」
• 「答えが規程に書かれていないのに、あるかのように尋ねる質問」
• 「本来は断るべき、個人情報の開示を求める依頼」

失敗の型は、運用中に見つかったインシデントから起こすのがもっとも現実的です。1件の実際の失敗から、同じ型の合成ケースを10件作る。この形なら、種は実データ由来なので現実から離れすぎません。

4. 文書を起点にしたQA生成(RAG向け)#

RAGの評価では、答えの根拠となる文書がすでに手元にあります。文書のチャンクを渡して「この箇所だけを根拠に答えられる質問と、その答え」を作らせれば、質問・正解・根拠の3点セットが同時に得られます。DeepEvalのSynthesizerは、この流れをコンテキスト構築 -> 入力生成 -> フィルタリング -> 進化(Evol-InstructとWizardLMに着想を得た複雑化) -> スタイリングという段階に分けています。フィルタリングが進化より前に置かれているのは、最初のフィルタを通ったデータはその後の進化やスタイリングで品質が落ちない、という前提を置いているためだと公式ドキュメントは説明しています。フィルタリングでは批評役のLLMが「単体で理解できるか(self-containment)」「意図が明確か(clarity)」を0から1で採点し、既定のしきい値0.5未満は再生成されます。既定3回の再試行を経てもしきい値に届かない場合は、その中で最もスコアの高いものが採用されます。

5. ルールベースでの正解ラベル付与#

生成した入力に対する正解を、LLMに答えさせるのではなく、決定的な処理で付ける方法です。分類なら「この条件を満たす入力を作って」と条件側から生成すれば、ラベルは条件そのものです。抽出タスクなら、先に構造化データを用意し、そこから自然文を生成すれば、元の構造化データがそのまま正解になります。

正解が機械的に決まるデータは、評価の信頼性が段違いです。作れる範囲は限られますが、作れるところは必ずこの型に寄せる価値があります。

品質をどう担保するか#

生成したデータは、そのままでは使えません。Self-Instructの公式リポジトリには、生成データについて「200件の指示を無作為に分析したところ、46%のデータ点に問題があり得ることが分かった」という注記があり、注意して使うよう明記されています。研究として成果を出した手法でも、素の生成データの半分近くには何かしら問題があるということです。

重複と多様性を機械的に測る#

「多様に作って」と頼んでも多様にはなりません。生成のたびに、既存データとの類似度を測って落とす処理を組み込みます。Self-Instructでは、既存のどの指示ともROUGE-Lの類似度が0.7未満である場合にのみ、新しい指示を採用しています。

実務では次のあたりを見ます。

• 完全一致・正規化後一致の重複率
• 既存データとの最大類似度(表層のn-gram一致でも、埋め込みのコサイン類似度でもよい)
• 語彙の広がり(異なり語数、頻出語の偏り)
• 先ほどの軸の組み合わせ表で、どのマスが空いているか

指標の絶対値より、生成のバッチを重ねたときにこれらが悪化していないかを見るほうが役に立ちます。多様性は、生成を重ねるほど落ちていくのが普通です。

人手レビューは全数ではなく標本で#

全件を人が見るなら合成データの意味が薄れます。現実的なのは標本レビューです。無作為に一定割合を抜き、「そもそも日本語として成立しているか」「現実に起こり得る入力か」「正解ラベルが正しいか」を確認します。ここで不合格率が高ければ、生成プロンプトを直して作り直します。件数を増やすのはそのあとです。

加えて、レビューで落とした事例は捨てずに残してください。「こういうものは要らない」という反例は、次の生成プロンプトの制約として直接使えます。

LLM-as-a-judgeで選別する場合の限界#

生成したデータの取捨選択をLLMに任せる設計は一般的で、DeepEvalのように既定機能として組み込んでいるツールもあります。ただし、判定する側のモデルにも癖があります。評価データの選別に使う場合、この癖はデータセットの偏りとして固定されます。

落とし穴#

生成モデルと評価モデルが同じだと点が甘くなる#

Panicksseryらの研究は、LLMが自分自身の生成物を認識する能力を持ち、その自己認識の強さと自己選好バイアス(自分の出力を高く採点する傾向)の間に線形の相関があること、さらに自己認識を強めるファインチューニングを施すとバイアスも強まるという因果関係を報告しています。

これは合成データの文脈で二重に効きます。モデルAでデータを作り、モデルAで採点し、モデルAを評価する。この三つがそろうと、点数は現実より高く出やすくなります。少なくとも、データ生成に使うモデルと採点に使うモデルは分けるのが無難です。

合成データでの評価は、本番と乖離する#

MIMDEの研究では、人手データと合成データの2つのデータセットで20のモデルを評価し、洞察抽出の能力については強い相関(0.71)が見られた一方で、合成データは文書レベルの分析の複雑さを捉えられなかったと報告されています。

つまり「モデル同士の相対的な優劣を見る」用途にはある程度使えるが、「本番でどれだけ通用するか」の絶対的な水準を測る用途には向かない、と読むのが妥当です。合成データでのスコアは、順位付けの参考にはなっても、受け入れ判定の根拠にはなりません。

モデル崩壊(model collapse)の議論#

Nature誌に2024年7月に掲載されたShumailovらの論文は、生成されたデータで再帰的に学習を繰り返すと、元の分布の裾が消えていく不可逆な欠陥が生じることを示しました。この現象はLLMだけでなく、変分オートエンコーダやガウス混合モデルでも起こるとされています。

ただし、この議論には続きがあります。Gerstgrasserらの研究は、各世代で実データを合成データに置き換える設定なら崩壊が起きるが、実データを残したまま合成データを累積していく設定では崩壊が回避されることを示しました。実務への含意は明確です。実データを捨てて合成データに置き換えるのは危険で、実データに合成データを足す形にとどめるほうが安全だ、ということです。

教師モデルの利用規約#

他社のモデルの出力を、自社モデルの学習に使ってよいかは規約次第です。たとえばAnthropicのCommercial Terms of Serviceは、使用制限の条項で「競合する製品やサービスを構築するためにサービスにアクセスすること(競合するAIモデルを学習させることを含む)」を禁じています。一方で、オープンウェイトのモデルには出力の再利用を明示的に認めるものもあります。Llama 3.1のコミュニティライセンスは、Llama Materialsやその出力を使って学習・改良したAIモデルを配布する場合、そのモデル名の先頭に「Llama」を含めることを求めています(条件付きで許容している例です)。

実データを種にするときの個人情報#

シード拡張は強力ですが、種が実データである以上、個人情報の扱いがついて回ります。英国ICOのPETsガイダンスは、合成データについて「匿名かどうかは、モデルの元にした個人情報が合成データ自体から推測できるかによる」とし、生成手法によってはモデル反転攻撃・メンバーシップ推論攻撃・属性開示のリスクがあると指摘しています。また、元データの偏りは合成データにも引き継がれるとも述べています。

日本の法制度がそのまま同じ枠組みというわけではありませんが、「合成にすれば自動的に個人情報でなくなる」という前提は置かないほうが安全です。実務としては、種にする前の段階で個人情報を機械的に落としておくのが最も確実です。

向いている場面と、向かない場面#

向いている場面は次のとおりです。

• 評価セットのブートストラップ。ゼロから最初の数十件を用意し、変更の前後を比較できる状態を作る
• カバレッジの穴埋め。頻度が低くて実ログには数件しか無いケースを、意図的に厚くする
• 回帰テストの拡張。既知の失敗1件を種に、同型のケースを増やして再発を検知する
• 学習データの形式そろえ。出力フォーマットの統一など、形が決まっているものを量産する

向かないのは次の場面です。

• 本番投入の受け入れ判定。最終的な合否は実データで測ります
• 実際の利用者の言い回しの分布を知りたいとき。合成データは書き言葉に寄ります
• 事実の正しさが問われる領域の正解づくり。生成された「正解」自体が誤っているリスクを持ち込みます
• 実データを一切残さず、合成データだけで学習を回し続ける設計

Anthropicの公式ドキュメントは、評価の設計原則として、タスク固有であること、採点を自動化できる形にすること、そして「量を質より優先する」ことを挙げています。少し精度の低い自動採点でも件数が多いほうが、少数の高品質な手作業評価より良い、という考え方です。合成データが効くのは、まさにこの「件数を確保する」側面です。逆に言えば、質が本質的に問われる部分は代替できません。

小さく始める手順#

よくある質問#

まとめ#

合成データは、データが無い時期に判断を止めないための足場です。作り方の型は限られていて、軸を決めて条件付きで生成し、重複を機械的に落とし、標本を人が見る、という地味な工程の積み重ねで質が決まります。逆に、生成から採点まで同じモデルに任せ、実データを一切見ないまま運用を続けると、数字だけが良くなっていきます。足場は足場として使い、実データが入り始めたら、静かに比率を下げていってください。

本記事の固有事実は、各論文の原著(arXiv・Nature)、Ragas・DeepEval・Microsoft Learn・Claude Platform Docsの公式ドキュメント、Anthropic・Metaの規約原文、英国ICOのガイダンスで確認しています。規約・ドキュメントは改定されるため、実際の判断にあたっては利用時点の原文をご確認ください。