プロローグ — 2026年、合成データの第二の春

2018年に合成データを初めて聞いたとき、それは「本物のデータがない時の次善策」のように聞こえた。2019年にCTGAN論文が出た時でさえ、合成データはGAN研究者の玩具に近かった。空気が完全に変わったのは2023年のChatGPT以降である。LLMが新しい学習データを数兆トークン単位で必要とし始め、同時にGDPRとHIPAAの圧力が本物データの流れを止めた。**二つの流れが合流して、合成データの第二の春が始まった。**

2024年8月、合成データ市場は決定的な事件を迎えた — MOSTLY AIがGretelを買収した(報道ベースの情報、正確な取引条件は非公開)。これによりテーブル形式合成データ市場の1位と2位が一つ屋根の下に入った。同年Tonic AIはEphemeral(データベース・クローン)製品を公開し、SyntheaはMITREから独立したオープンソース医療シミュレータとして地位を固めた。LLM側ではAnthropicのConstitutional AI訓練用合成データ・パイプラインが話題となり、Hugging FaceのArgilla買収(2024)でDistilabelが合成データの標準パイプラインとなった。

> **合成データは本物データの代替品ではない。本物データでは届かない場所を埋める道具である。** — プライバシーの壁、希少クラスの空白、敵対的ケース、そしてLLMが渇望する多様性。

本記事で扱う内容:

1. 2026年合成データの地図

2. 合成データが解決する5つの問題

3. テーブル形式合成の数学 — GAN、VAE、Diffusion

4. SDV(Synthetic Data Vault) — MIT発オープンソース

5. CTGAN、TVAE、TabDDPM 中核モデル

6. MOSTLY AI — テーブル形式合成のグローバル・リーダー

7. Gretel AI — Differential Privacyのチャンピオン

8. Tonic AI — Structural、Textual、Ephemeral

9. Hazy、YData、Syntegra — 欧州・ヘルスケア陣営

10. Synthea — 医療合成データの事実上の標準

11. 画像・映像合成 — Omniverse Replicator、Unity Perception

12. LLM合成パイプライン — Distilabel、Magpie、Self-Instruct

13. Constitutional AIとRLAIF — 合成選好データ

14. Fakerライブラリ — Python Faker、Mimesis、Faker.js

15. 構造化出力 — Outlines、Instructor、DSPy

16. 合成データの品質評価

17. プライバシー保証 — Differential PrivacyとMIA

18. 法・規制 — GDPR、HIPAA、K-PIPA、APPI

19. 韓国の合成データ — KAIST、ETRI、NAVER LABS

20. 日本の合成データ — PFN、NTT、NICT

21. どのツールを選ぶか — 意思決定ツリー

22. 参考資料

1章 · 2026年合成データの地図

まず全体像。合成データツールを扱うデータ型で分類すると次のとおりである。

**テーブル形式 (Tabular) — エンタープライズの主流**

- **MOSTLY AI** (オーストリア) — テーブル形式合成データのグローバル・リーダー。2024年にGretelを買収したと報じられた。

- **Gretel AI** (米国) — Differential Privacy + GAN基盤。クラウドAPIとSDK提供。

- **Tonic AI** (米国) — Tonic Structural(RDBMSサブセット)、Tonic Textual(PIIマスキング)、Tonic Ephemeral(DBクローン)。

- **Hazy** (英国) — エンタープライズ、特に金融業界で強い。

- **YData** (ポルトガル) — Synthetic Data + ydata-profiling。

- **Syntegra** — 臨床データ特化。

- **SDV (Synthetic Data Vault)** — MITオープンソース。CTGAN、TVAE、PAR。

**医療・ヘルスケア (Healthcare)**

- **Synthea** (MITRE) — 人口規模の臨床シミュレーション。事実上の標準。

- **HealthShare** (InterSystems) — 医療データ・プラットフォーム。

- **Clinical Synthetic Data Generator** — 米HHS・CMSの合成データ・イニシアチブ。

**画像・映像 (Image/Video)**

- **NVIDIA Omniverse Replicator** — 3Dシミュレーション基盤。

- **Unity Perception** — ゲームエンジンをデータ生成器に。

- **Datagen、Synthesis AI** — 人物の顔・ポーズ合成。

- **AI.Reverie** (Metaが2021年に買収) — 自動運転・防衛。

**LLM・テキスト (Text/Instruction)**

- **Distilabel** (Argilla → Hugging Face) — 合成指示文・選好データの標準パイプライン。

- **Magpie** (Princeton) — モデルの自己指示。

- **Self-Instruct** (Yizhong Wang) — LLM自己生成学習データの始祖。

- **OpenHermes 2.5、OpenOrca、UltraChat** — 合成データセットの代表。

**Faker — 偽の識別子・名前・住所**

- **Python Faker** (joke2k) — 最も広く使われる偽データ。

- **Mimesis** (Python) — Fakerより速く、多言語に強い。

- **Faker.js** — Marak事件後にコミュニティが引き継いだnpmパッケージ。

- **mockaroo.com** — Web UIの偽データ生成器。

**構造化出力 (Structured Output)**

- **Outlines、Instructor、DSPy** — LLMにJSONスキーマを強制する。

この地図が示すのは: **「合成データ」という一語で括られるが、実際には5つの異なる市場である。** テーブル形式のプライバシー保持、医療の人口シミュレーション、LLMの指示文合成、自動運転のシミュレーション — 同じ旗印の下でまったく別の問題を解いている。

2章 · 合成データが解決する5つの問題

合成データを使う理由を5つに整理すると次のとおりである。

**問題1: プライバシー** — GDPR(EU)、HIPAA(米)、K-PIPA(韓国)、APPI(日本)は識別可能な個人情報の移送・共有を厳しく制限する。合成データは統計分布は保つが個人を再識別できないように作られる。「欧州本社が韓国子会社に顧客データを送れない → 合成データを送る」のようなシナリオが最も一般的である。

**問題2: データ希少性** — 自動運転で「車が子供を轢きそうになった」本物データを集めるのは難しい(幸い)。医療では希少疾患は患者数自体が少ない。詐欺検知では陽性クラスが0.1%である。シミュレーションで不足を埋める。

**問題3: クラス不均衡** — 異常検知、詐欺検知、医療診断の陽性クラスは1%未満である。SMOTE、ADASYNのような古典的手法からGAN・VAE基盤のオーバーサンプリングまで、クラス不均衡の解消は合成データの古典的応用である。

**問題4: 増強 (Augmentation)** — 本物データに変形(回転、ノイズ、色変換)を加えて学習データを増やす。画像分野のcutout・mixup、NLPのback-translation・EDAが代表的。狭義の合成データではないが目的は同じである。

**問題5: LLM学習データ** — 2024年以降最も熱い応用。インターネット・テキストは枯渇しつつあり、人間ラベラーは高い。だからLLMが他のLLMのためにデータを合成する。Self-Instruct、Magpie、Constitutional AI、RLAIFがすべてこの流れである。

この5つの問題のどれを解こうとしているか、そしてそのデータがテーブル形式か画像かテキストかによって — 選ぶべきツールが決まる。

3章 · テーブル形式合成の数学 — GAN、VAE、Diffusion

テーブル形式合成のコアは結合分布 P(X1, X2, ..., Xn) を学習しそこから新しいサンプルを抽出することである。2026年現在、3つのパラダイムが競う。

**パラダイム1: GAN基盤 — CTGAN**

CTGANの核アイデア: 条件付き生成器 + モード別正規化

(概念的擬似コード)

class CTGAN:

def fit(self, data, discrete_columns):

1. 連続列はGaussian Mixtureで多峰に分離

self.gmm = fit_gmm_per_column(data)

2. 離散列はone-hot

self.ohe = one_hot(data, discrete_columns)

3. クラス不均衡 → 条件付きサンプリング

self.cond_sampler = ConditionalSampler(discrete_columns)

4. Wasserstein GAN with gradient penalty

train_wgan_gp(generator, critic, epochs=300)

def sample(self, n):

cond = self.cond_sampler.sample(n)

return self.generator(noise, cond)

**パラダイム2: VAE基盤 — TVAE**

TVAEはCTGANと同じ前処理(GMM + one-hot)を使うがデコーダがVAEである。GANより学習が安定し、mode collapseが少ないという利点。

**パラダイム3: Diffusion基盤 — TabDDPM、TabSyn**

TabDDPM(Kotelnikov et al., 2023)は画像で実証されたdiffusionをテーブル形式に応用した。連続はGaussian diffusion、離散はmultinomial diffusion。2024-2025年にTabSyn(Zhang et al.)がlatent diffusionでさらに一歩進んだ。

| モデル | パラダイム | 強み | 弱み |

| --- | --- | --- | --- |

| CTGAN | GAN | 高速サンプリング、業界標準 | 学習不安定 |

| TVAE | VAE | 安定、モード保存 | 多様性↓ |

| TabDDPM | Diffusion | SOTA品質 | サンプリング遅い |

| TabSyn | Latent Diffusion | 品質・速度のバランス | 新参 |

| ARF | Adversarial Random Forest | 小データに強い | 大データ↓ |

産業ツール(MOSTLY AI、Gretel、Tonic)はこれらの**改良版を独自に**持つ。一部は論文化され、一部は営業秘密である。

4章 · SDV (Synthetic Data Vault) — MIT発オープンソース

SDVはMITのDAI Labで2016年に始まったオープンソース・プロジェクトで、2026年現在テーブル形式合成データ・オープンソースの事実上の標準である。単一テーブル、複数テーブル(関係保存)、時系列をすべて扱う。

SDV 単一テーブル合成 (代表例)

from sdv.single_table import CTGANSynthesizer

from sdv.metadata import SingleTableMetadata

1) データロード

real_data = pd.read_csv('customers.csv')

2) メタデータ自動抽出

metadata = SingleTableMetadata()

metadata.detect_from_dataframe(real_data)

3) モデル学習

synthesizer = CTGANSynthesizer(metadata, epochs=300)

synthesizer.fit(real_data)

4) 合成データ1万行を生成

synthetic = synthesizer.sample(num_rows=10_000)

5) 品質評価 — SDMetricsパッケージが同梱

from sdv.evaluation.single_table import evaluate_quality

report = evaluate_quality(real_data, synthetic, metadata)

print(report.get_score()) # 0..1、1に近いほど良い

SDVの強みは**複数テーブル関係保存**である。HMA(Hierarchical Modeling Algorithm)、HSA、GaussianCopulaなどのモデルは外部キー制約を壊さずに親子テーブルを一緒に合成する。時系列はPAR(Probabilistic AutoRegressive)が担当する。

ライセンスはBusiness Source License(MITの派生)である — 非商用・研究用は自由、商用はDataceboが運営するSDV Enterpriseの別ライセンスである。

5章 · CTGAN、TVAE、TabDDPM — 中核モデル比較

3モデルを同じデータ(UCI Adult、n=48,842)で比較すると、公開ベンチで次のような傾向が報告されている。

| 指標 | CTGAN | TVAE | TabDDPM |

| --- | --- | --- | --- |

| 単変量分布 (KS) | 0.05 | 0.04 | 0.02 |

| 結合分布 (TVD) | 0.12 | 0.10 | 0.07 |

| 下流ML F1 | 0.81 | 0.83 | 0.85 |

| 学習時間 | 1x | 1.2x | 5x |

| サンプリング時間 | 1x | 1x | 30x |

**解釈**: TabDDPMが品質では最も良いが学習・サンプリング・コストが大きい。大量合成が必要ならTVAE/CTGAN、品質が絶対ならTabDDPM/TabSynである。実際の産業ツールはデータサイズ・敏感度・生成量に応じて**複数モデルを自動選択**する。

6章 · MOSTLY AI — テーブル形式合成のグローバル・リーダー

MOSTLY AIはオーストリア・ウィーンで2017年に創業した、テーブル形式合成データの最大手である。金融(Erste Group、ING)、保険、通信、そしてEU公共セクターに強い。

**製品ライン**

- **MOSTLY AI Platform** — クラウドSaaSまたはオンプレDocker。Web UI + REST API。

- **mostlyai SDK** — 2024年にオープンソース化したPython SDK。自前環境で合成モデルを学習・実行できる。

- **AI Assistants** — 自然言語で合成作業を指示。

MOSTLY AI オープンソースSDK (代表例)

from mostlyai.sdk import MostlyAI

mostly = MostlyAI(local=True) # ローカル・モード

1) 学習

g = mostly.train(

data='customers.csv',

name='customer-synth-v1',

)

2) 合成

syn = mostly.generate(g, size=50_000)

syn.data().to_csv('synthetic_customers.csv', index=False)

3) 品質レポート — HTMLで出力される

print(syn.report_path)

**技術的特徴**

- 独自のtransformer基盤生成モデル(2023年発表)。テーブル形式でPFNと並ぶtransformer陣営の双璧。

- Differential Privacyをオプションで有効化でき、有効時はε(epsilon)予算を明示する。

- 複数テーブル関係保存、時系列合成のすべてに対応。

2024年のGretel買収報道(メディアベース)で、MOSTLY AIは事実上テーブル形式合成市場の圧倒的1位となった。ただし、2つの製品ラインはしばらくの間別々に運営されている。

7章 · Gretel AI — Differential Privacyのチャンピオン

Gretelは2019年に米国カリフォルニアで創業した合成データ企業である。Differential Privacyを一級市民として扱う点でMOSTLY AIと差別化される。

**製品**

- **Gretel Cloud** — SaaS形式。テーブル形式、テキスト(自由テキストのPII合成)、時系列を扱う。

- **gretel-synthetics** — オープンソースPythonライブラリ。ACTGAN、TimeSeries、LSTM、GPT基盤のテキスト合成モデルを含む。

- **Gretel Tuner** — 合成モデルのハイパーパラメータ自動探索。

Gretel SDKで合成データを生成 (代表例)

from gretel_client import Gretel

gretel = Gretel(api_key='prompt') # または環境変数

project = gretel.projects.create(name='customer-synth')

テーブル形式合成モデルを作成 (Gretelクラウドで学習)

trained = project.create_model_obj(

model_config='synthetics/tabular-actgan',

data_source='customers.csv',

)

trained.submit_cloud()

trained.poll() # 学習完了まで待機

合成データ生成

record_handler = trained.create_record_handler_obj(params={'num_records': 50_000})

record_handler.submit_cloud()

record_handler.poll()

synthetic_df = record_handler.get_artifact_handle('data_preview').download_to_dataframe()

**技術的特徴**

- **Differential Privacy GAN** — DP-SGDでモデル・パラメータの私的情報漏れをεに制限する。

- **PII redaction + synthesisの結合** — テキストで名前・住所をマスキングした後、その位置に偽を埋めるパイプライン。

- **Gretel Tuner** — モデル自動選択。

2024年のMOSTLY AI買収後もGretelブランドは維持されており、APIは互換である。ただし、新機能の追加が一つのラインに統合される時期は2026年現在も進行中である。

8章 · Tonic AI — Structural、Textual、Ephemeral

Tonic AIは2018年にサンフランシスコで創業した、「エンジニアのための合成データ」企業である。MOSTLY/Gretelがデータサイエンティストがモデルを学習するシナリオを前提とするなら、Tonicは**開発者が本番DBの安全な複製を受け取る**シナリオを一級として扱う。

**3つの製品ライン**

- **Tonic Structural** — 本番RDBMS(PostgreSQL/MySQL/SQL Server/Oracle)で外部キー関係を保持しつつサブセット + マスキング/合成。CI/CDパイプラインに統合される。

- **Tonic Textual** — 自由テキストでPIIをNERで検出 + マスキング + 合成置換。医療ノート、コールセンター・トランスクリプト。

- **Tonic Ephemeral** (2024 GA) — 短命データベース・インスタンス。PRごとに合成DBを起動し、PRが閉じればDBも消す。

Tonic Structural ワークスペース設定 (代表例)

workspace: customer-app

source:

type: postgres

host: prod-readonly.example.com

database: app

subset:

root_table: public.customers

target_size: 10%

generators:

public.customers.email:

type: fake_email

public.customers.phone:

type: random_phone

public.orders.notes:

type: tonic_textual # 自由テキストのPII合成

destination:

type: postgres

host: dev-db.internal

database: app_dev

**市場ポジション**

- MOSTLY/Gretelは**データを保護しつつ統計が保たれた合成データセット**を作る(ML学習用)。

- Tonicは**開発/テストのための安全なDB複製**を作る(エンジニアリング用)。

- 2つは同じ単語「synthetic data」を使うが解く問題が違う。

9章 · Hazy、YData、Syntegra — 欧州・ヘルスケア陣営

**Hazy** (英国、ロンドン、2017年創業)

- 金融・公共セクターに強い。英国ONS Secure Research Serviceと協業。

- 独自のGAN派生 + Differential Privacy。閉鎖環境(エアギャップ)デプロイに強い。

- 2024年NatWest、HSBCとの事例が公開されている。

**YData** (ポルトガル、2019年創業)

- **ydata-synthetic** — オープンソース合成ライブラリ。CTGAN、TimeGAN、DragonGAN。

- **ydata-profiling** (旧pandas-profiling) — データ・プロファイリング標準ツール。2022年に合流。

- **YData Fabric** — データ準備・合成・評価の統合SaaS。

**Syntegra** (米国、2020年創業)

- 臨床データ合成に特化。EMR、請求データ、ゲノミクス。

- 独自のtransformer基盤モデル + HIPAA Safe Harbor評価レポートを自動生成。

- Mayo Clinic、Columbiaなどとの協業事例。

この陣営の共通点は**規制産業(金融・医療)に深く入ったドメイン知識**である。一般的なテーブル形式ツールでは処理しにくい、ドメイン特有の検証(例: 臨床コーディングの整合性)を自動化する。

10章 · Synthea — 医療合成データの事実上の標準

SyntheaはMITRE Corporationが2017年に公開したオープンソース医療人口シミュレータで、2026年現在医療合成データの事実上の標準である。テーブル形式モデルが「既存データの分布」を学習するのとは異なり、Syntheaは**臨床ガイドラインを明示的にモデル化した**ルール基盤のシミュレーションである。

**アーキテクチャ**

- **Generic Module Framework** — JSONで定義された臨床モジュール(高血圧、糖尿、妊娠、COVID-19など100以上)。

- 各モジュールは状態機械である: 診断 → 検査 → 治療 → 経過観察。

- 患者は出生から死亡までシミュレートされ、年齢・性別・人種・地域で発症率が変わる。

Synthea 実行 (代表例) - Java jarで動作

マサチューセッツ州の1万人合成患者をFHIR R4形式で出力

java -jar synthea-with-dependencies.jar \

-p 10000 \

-s 1234 \

--exporter.fhir.export true \

--exporter.csv.export true \

Massachusetts

**出力形式**

- FHIR R4 (JSON) — 最も使われる。

- C-CDA — HL7臨床文書。

- CSV — テーブル形式分析用。

- CPCDS — 請求データ。

**限界**

- 本物患者の統計を学習しないので、「分布が本物データと同じ」という保証はない。ガイドライン基盤なのでガイドラインの限界(例: 希少疾患のディテール不足)をそのまま持つ。

- そのため2024年以降登場した流れは**Syntheaで骨格を作り、GAN/diffusionでディテールを埋めるハイブリッド**である。

11章 · 画像・映像合成 — Omniverse Replicator、Unity Perception

**NVIDIA Omniverse Replicator** — 2021年公開。USD(Universal Scene Description)基盤の3DシミュレーションでRGB・セグメンテーション・深度・バウンディングボックスを同時に生成する。自動運転、ロボット・マニピュレーション、倉庫自動化に強い。2024年Isaac Simと統合され、ロボット学習データの標準となった。

**Unity Perception** — ゲームエンジンUnityがデータ生成器に変身。SynthDetのような公開ベースライン・データセットがある。

**Datagen、Synthesis AI** — 人物の顔・ポーズ・表情に特化。自動運転のドライバー監視、AR/VRアバターに使われる。

**AI.Reverie** (Meta買収、2021) — 衛星映像・ドローン映像・防衛シミュレーションに強かったが、Metaが2021年に買収した後、事実上社内ツールとなった。

Omniverse Replicator (代表的擬似コード)

with rep.new_layer():

camera = rep.create.camera()

cube = rep.create.cube(position=(0, 0, 0))

light = rep.create.light()

with rep.trigger.on_frame(num_frames=1000):

with cube:

rep.modify.pose(position=rep.distribution.uniform((-5, 0, -5), (5, 0, 5)))

writer = rep.WriterRegistry.get('BasicWriter')

writer.initialize(output_dir='out/', rgb=True, bounding_box_2d_tight=True)

writer.attach([camera])

rep.orchestrator.run()

画像・映像合成の核心的難しさは**sim-to-real gap**である。シミュレーションが本物と違うと、合成で学習したモデルは現実で失敗する。ドメイン・ランダム化(domain randomization)とドメイン適応(domain adaptation)がこのギャップを減らす中核技術である。

12章 · LLM合成パイプライン — Distilabel、Magpie、Self-Instruct

2023年以降、LLM学習データの渇望が合成データの新領域を開いた。

**Self-Instruct** (Yizhong Wang et al., 2022) — LLM自己生成学習データの始祖。人間が作った小さなシード指示文プールから、LLMが新しい指示文 + 応答を自己生成する。Alpaca、Vicuna、WizardLMがこの流れの直系後継である。

**Magpie** (Princeton, 2024) — Self-Instructをさらに一歩。シードもなしに、チャット・テンプレートのuserトークンだけを入力した後、LLMが勝手に指示文を作りそれに対する答えを作る。Llama-3-Instructで試行され、100万件規模の合成データセットが作られた。

**Distilabel** (Argilla → Hugging Face, 2024) — 合成データ・パイプラインの標準ライブラリ。ノード・グラフで合成ワークフローを組む。

Distilabel — 合成指示文 + 選好データ (代表例)

from distilabel.pipeline import Pipeline

from distilabel.steps.tasks import TextGeneration

from distilabel.llms import OpenAILLM

with Pipeline(name='preference-synthesis') as pipeline:

generator_a = TextGeneration(

name='gen_a',

llm=OpenAILLM(model='gpt-4o'),

)

generator_b = TextGeneration(

name='gen_b',

llm=OpenAILLM(model='gpt-4o-mini'),

)

2つの応答についてGPT-4がどちらが良いか判定 → 選好ペア生成

(省略) JudgeStep ...

distiset = pipeline.run(

parameters={

'gen_a': {'llm': {'generation_kwargs': {'temperature': 0.7}}},

},

)

distiset.push_to_hub('username/synthetic-prefs')

**OpenHermes 2.5、OpenOrca、UltraChat** — すべて合成データセットの代表事例。100万 ~ 数百万件規模の指示文-応答ペア。ライセンスが厄介で商用利用は注意が必要。

13章 · Constitutional AIとRLAIF — 合成選好データ

LLMアラインメント(alignment)で最も高くつくのが人間の選好ラベリングである。だから**合成選好データ**が中核トピックとなった。

**Constitutional AI** (Anthropic, 2022) — モデルが自分の出力を憲法(原則リスト)に照らして批判し、修正する。そうして作った(応答、修正された応答)ペアが選好学習データになる。

**RLAIF (RL from AI Feedback)** (Google, 2023) — RLHFの人間ラベラーの位置にLLM判定者を置く。人間ラベラー比90%以上の一致との結果。

Constitutional AIパイプライン (代表)

1. 初期モデルがユーザー質問に応答する

2. 憲法の原則の一つをランダムに選び、モデルが自分の応答を批判する

3. 批判をもとにモデルが自分の応答を修正する

4. (質問、元の応答、修正された応答) → SFT学習データ

5. (質問、元の応答 vs 修正された応答) → DPO/PPO選好データ

**自己報酬 (Self-Reward)** (Meta, 2024) — 同じモデルが応答者であり判定者でもある自己強化学習。合成データの極端形である。

この流れの核心は**人間なしで段々と良くなるループ**である。ただしモデルが自分の偏見を強化する危険(model collapse、mode collapse)が報告されており、合成データの比率と検証が重要になる。

14章 · Fakerライブラリ — Python Faker、Mimesis、Faker.js

最も軽い合成データは統計学習なしに偽を作るFaker系である。

**Python Faker** (joke2k, 2014~) — 最も広く使われる偽データ・ライブラリ。70以上のlocale。

from faker import Faker

fake = Faker('ja_JP')

print(fake.name()) # 山田 太郎

print(fake.address()) # 東京都新宿区...

print(fake.phone_number()) # 090-1234-5678

print(fake.email()) # taro@example.jp

print(fake.company()) # 株式会社...

**Mimesis** (Python) — Fakerより速く(C拡張一部)、多言語サポートが豊富。

from mimesis import Generic

g = Generic('ja')

print(g.person.full_name()) # 田中 一郎

print(g.address.address())

print(g.business.company())

**Faker.js** (npm) — 2022年1月、原作者Marakが意図的にnpmパッケージを壊した事件(いわゆる「node-ipc」事件の同伴者)の後、コミュニティがforkした@faker-js/fakerが標準となった。元のfakerはnpmでdeprecatedである。

console.log(faker.person.fullName());

console.log(faker.location.streetAddress());

console.log(faker.phone.number());

**mockaroo.com** — Web UIで偽データの列を設計しCSV/JSONでダウンロード。200以上のデータ型。

Faker系の限界: **列間の相関関係が保たれない。** 年齢と職業、都市と郵便番号の相関が偽である。統計が重要ならSDV/MOSTLY/Gretel側へ上がる必要がある。

15章 · 構造化出力 — Outlines、Instructor、DSPy

LLMが合成データを作る時の最大の悩みの種は出力フォーマットである。JSONスキーマを強制するライブラリが合成パイプラインの必須部品となった。

**Outlines** (dottxt-ai) — トークン・レベルでJSONスキーマ/正規表現/文脈自由文法を強制する。logitsをマスクして、誤ったトークンをそもそも生成しないようにする。

model = outlines.models.transformers('meta-llama/Llama-3.1-8B-Instruct')

generator = outlines.generate.json(model, schema='''

{

"type": "object",

"properties": {

"name": {"type": "string"},

"age": {"type": "integer", "minimum": 0, "maximum": 120},

"city": {"type": "string"}

},

"required": ["name", "age", "city"]

}

''')

print(generator('東京に住む架空の人物のプロフィールをJSONで作れ'))

**Instructor** (Jason Liu) — OpenAI/Anthropic APIの上でPydanticモデルをそのまま出力スキーマとして使う。最も人気の抽象化。

**DSPy** (Stanford) — プロンプトを手で書く代わりに、「シグネチャ」を宣言してコンパイラがプロンプトを最適化する。合成データ・パイプラインのメタ・ツール。

これらのツールは合成データ生成器の出力フォーマットを強制し、**パイプラインが決まったスキーマで流れるように**する。合成データの信頼性ベースラインである。

16章 · 合成データの品質評価

合成データの品質は4つの軸で見る。

**軸1: 単変量分布 (Marginal)** — 各列のヒストグラムが本物データと似ているか。KS-test、Total Variation Distance。

**軸2: 結合分布 (Joint)** — 列間の相関・依存が保たれるか。Pearson/Spearman相関行列の差、相互情報量。

**軸3: 下流ユーティリティ (Utility)** — 合成データでMLモデルを学習し本物データで評価したとき精度がどれだけ落ちるか。TSTR(Train Synthetic, Test Real)。

**軸4: プライバシー (Privacy)** — 合成データから元の個人を再識別できるか。Distance to Closest Record(DCR)、Membership Inference Attack(MIA)、Attribute Inference Attack(AIA)。

SDMetricsで合成データを評価 (代表例)

from sdmetrics.reports.single_table import QualityReport

from sdmetrics.single_table import (

NewRowSynthesis, # 本物に完全に同じ行があるか (プライバシー)

BoundaryAdherence, # 列境界の遵守

CategoryCoverage, # カテゴリ・カバレッジ

)

report = QualityReport()

report.generate(real_data, synthetic_data, metadata)

print(report.get_score()) # 0..1、総合スコア

print(report.get_details('Column Shapes')) # 単変量

print(report.get_details('Column Pair Trends')) # 結合

この4軸はトレードオフである。プライバシーを強く保証するとユーティリティが落ち、ユーティリティを極大化すると元を暗記する危険が出る。どこでバランスを取るかが合成データ・エンジニアリングの中核技芸である。

17章 · プライバシー保証 — Differential PrivacyとMIA

**Differential Privacy (DP)** — 2006年にDworkが定義した概念。データセットから一人を抜くか入れても、アルゴリズムの出力分布がほぼ同じであるという保証。(ε, δ)パラメータで強度を表す。

定義 — (ε, δ)-DP

隣接データセット D, D' (1行違い)について、すべての出力集合 S:

Pr[A(D) ∈ S] ≤ e^ε · Pr[A(D') ∈ S] + δ

εが小さいほど強い保証。ε ≤ 1が一般的な推奨。

δは1/nよりはるかに小さくあるべき (例: 1e-6)。

**DP-SGD** (Abadi et al., 2016) — ニューラルネット学習時に勾配にノイズを加えクリッピングしてDPを保証する。合成データ生成モデルに適用される。

**Membership Inference Attack (MIA)** — 攻撃者が「この人は学習データにいたか?」を当てようとする攻撃。合成データでは攻撃者が合成結果だけを見て元のメンバーを推論する。MIA成功率が50%(ランダム推測)に近いほど安全。

**Attribute Inference Attack (AIA)** — 「この人の年齢は知らないが、職業と都市は知っている。年齢を推論できるか?」 合成データの部分公開が他の属性を漏らすかの問題。

**産業的含意** — MOSTLY AIとGretelはDPをオプションで有効化でき、有効時はε予算を明示する。医療・金融など強規制産業はDP-onを事実上デフォルトで使う。ただしεが小さいほどユーティリティが落ちるので、ドメイン別の適正値を決めるのが難しい。

18章 · 法・規制 — GDPR、HIPAA、K-PIPA、APPI

**GDPR (EU, 2018)** — 個人情報の処理・転送に厳しい同意を要求する。合成データが「もはや個人情報ではない」と認められるには再識別が事実上不可能でなければならない。EDPBの匿名化ガイドライン(2014年のArticle 29 WP Opinion 05/2014をEDPBが継承)が基準点である。単一化・連関・推論の3つの危険がすべて低いことが真の匿名の条件である。

**HIPAA (米, 1996)** — Safe Harbor(18の識別子削除)またはExpert Determination(統計専門家が再識別リスクを評価)のいずれかでDe-identification。合成データは通常Expert Determination経路である。Syntegraのようなツールは Expert Determinationレポートを自動生成する。

**K-PIPA (韓国個人情報保護法)** — 仮名情報・匿名情報の概念。仮名情報は同意なしで統計・研究目的に使用可能、匿名情報はさらに自由である。合成データは一般的に匿名情報として分類される方向だが、ケース・バイ・ケースの検討が必要である。2020年データ3法以降、仮名・匿名の法的地位が明確になった。

**APPI (日本個人情報保護法)** — 匿名加工情報の概念。韓国の匿名情報に似るが、作成時に一定の技術的処理基準を満たさねばならない。PPC(個人情報保護委員会)ガイドライン参照。

**米国の州法** — CCPA/CPRA(カリフォルニア)、そして2024年現在20以上の州が独自の個人情報法を可決した。統一連邦法はまだない。

法的ポジショニングの核心: **合成データを「非識別」として認められるには、単に「名前を隠した」ではなく、統計的再識別リスクを客観指標で示さねばならない。** だから合成ツールが自動で作るプライバシー・レポート(DCR、MIA、k-anonymityなど)が法務文書の一部になる。

19章 · 韓国の合成データ — KAIST、ETRI、NAVER LABS

韓国の合成データ・エコシステムは**公共主導 + 大企業自前開発**の二重構造である。

**KAIST · ソウル大 · POSTECH** — CTGAN、TabDDPMラインの後続研究が活発である。2024年にKAISTで発表されたテーブル形式diffusion派生がNeurIPSに採択された事例がある。

**ETRI (韓国電子通信研究院)** — 仮名・匿名情報生成ツールを政府事業として開発する。公共データ開放に活用される。

**NAVER LABS、Kakao Brain** — LLM学習用の合成韓国語データセット。自前モデル(HyperCLOVA X、KoGPTなど)の学習に使われる。

**金融・通信 — マイデータ時代** — 2022年マイデータ本格化以降、仮名・匿名結合データの産業的活用が増え、合成データ需要も大きくなった。新韓銀行、KB国民銀行、KTなどが自前ツールまたは外部ソリューション(MOSTLY/Gretel)を導入した事例が報じられている。

**韓国データ産業振興院(K-DATA)** — 仮名・匿名情報活用案内書、適正性評価ガイドを発行する。合成データの法的位置を整理した主要政府文献。

**医療** — 保健福祉部の医療マイデータ推進(2023~)、国立がんセンター・ソウルアサン病院などの合成EMR試行事業。Syntheaの韓国化(人口統計、発症率、臨床コーディング)が学界の課題である。

20章 · 日本の合成データ — PFN、NTT、NICT

**PFN (Preferred Networks)** — 自動運転・ロボット・シミュレーション・データ。Toyotaとの協業で合成映像データセット構築。

**NTT Data、NTT研究所** — テーブル形式合成データの社内ツール。通信ユーザー分析に活用。外部には一部論文のみで公開される。

**NICT (情報通信研究機構)** — 多言語NLPデータ、音声合成データ。ASTRECの音声合成コーパスが代表。

**RIKEN AIP** — 医療AI用合成EMR研究。日本の医療データの閉鎖性のため、合成が事実上唯一の外部共有手段である分野がある。

**商用導入** — 日本の金融界はMUFG、SMBCが自前ツール + Hazy/MOSTLYの試行。保険は東京海上が合成保険請求データで詐欺検知モデルを学習した事例が報じられている。

**APPI運用** — 匿名加工情報の作成基準が明確なので、合成データがそのカテゴリに入るよう設計するのが現場の標準アプローチである。

**韓国との違い** — 日本は公共部門のデータ開放が韓国より遅く、合成データの動機が「公共データを開放するため」より「民間内部で安全に動かすため」に寄っている。

21章 · どのツールを選ぶか — 意思決定ツリー

| シナリオ | 推奨ツール |

| --- | --- |

| テーブル形式、オープンソース、素早いプロト | SDV (CTGAN/TVAE) |

| テーブル形式、エンタープライズ、クラウド | MOSTLY AI または Gretel |

| テーブル形式、エンタープライズ、オンプレ + DP | MOSTLY AI オンプレ / Hazy |

| 本番RDBMS複製 + マスキング | Tonic Structural |

| PRごとに使い捨てDB | Tonic Ephemeral |

| 自由テキスト(ノート、コールセンター)のPII | Tonic Textual / Gretel |

| 医療EHR人口シミュレーション | Synthea |

| 臨床データ合成(分布基盤) | Syntegra |

| 自動運転・ロボット学習映像 | NVIDIA Omniverse Replicator |

| LLM指示文合成 | Distilabel + Magpie |

| 単純な偽の名前・住所 | Python Faker / Mimesis / Faker.js |

| 偽JSONスキーマの強制 | Outlines / Instructor |

**考慮すべき4つの次元**

1. **データ型** — テーブル、テキスト、映像、時系列のどれ?

2. **目的** — ML学習用? DEV/QA用? データ共有用?

3. **規制** — DPが必須か? HIPAA Safe Harborが必要か?

4. **運営環境** — クラウド可? エアギャップ必須?

この4つを紙に書き、ツール候補をマッピングすると通常2-3個に絞られる。その後POCである。

22章 · 参考 / References

公式文書と主要論文・報告書のみ集めた。

**テーブル形式合成 (公式文書)**

- MOSTLY AI — https://mostly.ai/

- mostlyai オープンソースSDK — https://github.com/mostly-ai/mostlyai

- Gretel AI — https://gretel.ai/

- gretel-synthetics — https://github.com/gretelai/gretel-synthetics

- Tonic AI — https://www.tonic.ai/

- Hazy — https://hazy.com/

- YData — https://ydata.ai/

- ydata-synthetic — https://github.com/ydataai/ydata-synthetic

- Syntegra — https://www.syntegra.io/

- SDV (Synthetic Data Vault) — https://sdv.dev/

- SDV GitHub — https://github.com/sdv-dev/SDV

- SDMetrics — https://docs.sdv.dev/sdmetrics/

**医療**

- Synthea — https://synthetichealth.github.io/synthea/

- Synthea GitHub — https://github.com/synthetichealth/synthea

- HHS Synthetic Data — https://www.hhs.gov/cto/initiatives/innovation/synthetic-data/

**画像・映像**

- NVIDIA Omniverse Replicator — https://developer.nvidia.com/omniverse/replicator

- Unity Perception — https://github.com/Unity-Technologies/com.unity.perception

**LLM・指示文合成**

- Distilabel — https://distilabel.argilla.io/

- Argilla — https://argilla.io/

- Self-Instruct (Wang et al., 2022) — https://arxiv.org/abs/2212.10560

- Magpie (Xu et al., 2024) — https://arxiv.org/abs/2406.08464

- Constitutional AI (Bai et al., 2022) — https://arxiv.org/abs/2212.08073

- RLAIF (Lee et al., 2023) — https://arxiv.org/abs/2309.00267

**Faker**

- Python Faker — https://faker.readthedocs.io/

- Mimesis — https://mimesis.name/

- Faker.js — https://fakerjs.dev/

- Mockaroo — https://www.mockaroo.com/

**構造化出力**

- Outlines — https://dottxt-ai.github.io/outlines/

- Instructor — https://python.useinstructor.com/

- DSPy — https://dspy.ai/

**核心論文**

- CTGAN (Xu et al., 2019) — https://arxiv.org/abs/1907.00503

- TabDDPM (Kotelnikov et al., 2023) — https://arxiv.org/abs/2209.15421

- TabSyn (Zhang et al., 2024) — https://arxiv.org/abs/2310.09656

- Differential Privacy (Dwork, 2006) — https://www.microsoft.com/en-us/research/publication/differential-privacy/

- DP-SGD (Abadi et al., 2016) — https://arxiv.org/abs/1607.00133

**法・規制**

- EDPB Guidelines on Anonymisation — https://www.edpb.europa.eu/

- HIPAA De-identification — https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/

- 個人情報保護委員会(韓国) — https://www.pipc.go.kr/

- PPC(日本個人情報保護委員会) — https://www.ppc.go.jp/

エピローグ — 合成は本物を置き換えない

本記事の一文要約: **合成データは本物データの代替品ではなく、本物では届かない場所を埋める道具である。** プライバシーの壁の向こう、希少クラスの空白、LLMが渇望する多様性 — その場所にだけ合成を入れるべきである。すべての場所を合成で埋めれば、自分の影だけを学習するモデルが残る。

2026年合成データの最大リスクは**model collapse**である。LLMが作ったデータで再びLLMを学習させるループが長くなると、モデルは本物世界の多様性を失う。だから合成と本物の比率、合成データの多様性測定、そして決定的評価用の本物holdoutが — 今後5年の核心エンジニアリング・トピックである。

次の記事候補: **AIモデル評価システム徹底解剖 (Inspect AI・Promptfoo・OpenAI Evals)**、**LLMデータ・キュレーション・パイプライン**、**Differential Privacy 実践**。

> 「合成は本物の写真ではない。本物の統計である。写真を望む場所に統計を入れれば失敗する。統計を望む場所に写真を入れても失敗する。2つは違う道具である。」