sdgx 評価：表形式合成データ生成フレームワークの設計と採用判断

sdgx が埋めようとしている穴は何か

表形式データの合成は、画像生成ほど道具が揃っていない。行と列の型が混在し、カテゴリ列の水準数が数千に達し、欠損値の扱いも列ごとに違う。sdgx はこの領域に絞ったフレームワークで、README は「specialized framework designed to generate high-quality structured tabular data」と位置づけている。想定読者は、本番データをそのまま共有できないが、その統計的性質は保ったデータセットが欲しい開発者だ。README は用途としてデータ共有、モデル訓練とデバッグ、システム開発とテストを挙げ、合成データは「does not contain any sensitive information」であるため GDPR や ADPPA のような規制の対象外になると説明している。ただしこれは法的評価ではなく、プロジェクト側の主張として読むべき部分である。実際の適法性は元データの性質と利用目的に依存し、この README だけでは判断できない。

Data Processor とメタデータ層という設計の重心

sdgx の構成で特徴的なのは、生成モデルそのものより前後の変換層に設計の重心が置かれている点だ。2024年5月30日にマージされた Data Processor モジュールは、Datetime 列のような型をモデルに渡す前に変換し、離散型として扱われるのを避ける。生成後は逆変換して元の形式に戻す。欠損値の処理もこの層が担い、プラグイン方式で拡張できると README は説明している。メタデータ層（sdgx.data_models.metadata）は単一テーブルと複数テーブルの記述に対応し、データ型の自動推論を行う。2024年11月には列間の関係を自動検出し、関係を明示的に指定できるようになったとリリース情報にある。つまり sdgx は、モデルを差し替え可能にしつつ、型変換と列間制約という表形式固有の厄介ごとを一箇所に集める方向で作られている。この分割は理にかなっているが、裏返すと Data Processor の変換規約を理解しないと生成結果の型が期待とずれる。

CTGAN と SingleTableGPTModel は何を共有しているか

sdgx は系統の異なる二つの生成経路を持つ。一つは GAN 系の CTGAN で、2023年12月の v0.1.0 に含まれ、リポジトリの benchmarks ディレクトリで SDV との比較結果が公開されているという。README の記述では、SDG はメモリ消費が少なく、訓練中のクラッシュを避けられたとされている。数値の詳細は benchmarks 側を参照する必要があり、この記事では確認していない。もう一つは sdgx.models.LLM.single_table.gpt.SingleTableGPTModel で、こちらは二つの機能を持つ。第一がデータなしの合成生成、つまり訓練データを必要とせずメタデータだけから合成データを生成する経路である。第二がオフテーブル推論で、既存の表に含まれない列を推論して補う。LLM 経路の価値は、GAN 系では苦手な「学習データがそもそも存在しない」状況を扱える点にある。両者を同じメタデータ記述の上に載せているのが sdgx の一貫性であり、モデル選択を後から変えられる余地を残している。

導入コマンドと設定の入口

パッケージ名は sdgx で、PyPI の sdgx プロジェクトとして公開されている。Python の対応バージョンは PyPI の classifiers に基づくバッジで示されており、pip でのインストールが想定される。README はインストール手順の本文を今回の抜粋に含んでいないため、正確なコマンドとバージョン指定は公式ドキュメント（synthetic-data-generator.readthedocs.io）で確認する必要がある。設定面では sdgx.data_models.metadata が単一テーブル・複数テーブルのメタデータ記述とデータ型の自動推論を担い、列の型や列間の関係をここで指定する。Data Processor はモデルに渡す前の型変換と生成後の逆変換、欠損値処理を担当し、プラグインとして差し替えられる。README が案内する Colab 例は三つあり、LLM のデータ合成、LLM のオフテーブル推論、十億行規模を想定した CTGAN のそれぞれに対応する。導入検討時はこの三つを順に動かし、自分のデータ型で自動推論がどこまで効くかを先に見るのが早い。

向かないケースと、ドキュメントが薄い部分

sdgx は表形式に特化している。画像、音声、自由記述テキストの生成が主目的なら、このフレームワークを選ぶ理由はない。もう一つの境界は前処理の制御権だ。Data Processor が型変換と欠損値処理を引き受ける設計は便利だが、変換規約が期待と合わない場合、生成結果の列型や値域がずれる。規約を読まずに使うと、生成物が元データの分布から離れていることに気づきにくい。README の記述は機能追加の告知が中心で、各モデルの失敗モードや、カテゴリ列の水準数が増えたときに精度がどう落ちるかといった限界には触れていない。CTGAN のベンチマークも SDV との比較が benchmarks ディレクトリにあるという案内にとどまり、条件や再現手順の説明はこの抜粋からは確認できない。LLM 経路についても、生成に使うモデルの指定方法やコスト、外部 API 依存の有無は README の抜粋からは読み取れない。ここは採用前に自分で確かめる領域である。

SDV との違いは抽象化の置き場所にある

比較対象として最も分かりやすいのは SDV だ。sdgx 自身の README が benchmarks で SDV と比較している。両者とも表形式の合成データ生成を掲げ、CTGAN 系のモデルを持つが、設計の重心が違う。SDV はメタデータによるスキーマ定義とモデル群を前面に出し、前処理はモデル側に吸収される傾向がある。sdgx は Data Processor という独立した変換層を置き、型変換と逆変換、欠損値処理、列間関係の検出をそこに集める。この違いは、生成モデルを差し替えても前処理の挙動を保ちたい場合に効く。逆に、前処理を自分で書きたいチームにとっては、間に挟まる層が邪魔になることもある。もう一つの差は LLM 経路の扱いだ。sdgx は SingleTableGPTModel を第一級のモデルとして同じメタデータ層に載せ、訓練データなしの生成とオフテーブル推論を提供する。ここは GAN 系だけでは埋まらない用途であり、sdgx を検討する動機として最も具体的である。

ライセンスとメンテナンスの見え方

ライセンスは Apache-2.0 で、リポジトリの LICENSE に置かれている。Apache-2.0 は商用利用を含む利用を許容し、特許条項と変更の明示といった条件を伴う。ここから先は法的助言ではないが、生成物の権利や元データの由来に起因するリスクは、ライセンス条項とは別に検討する必要がある。合成データが規制対象外になるという README の説明は、元データの機微性と生成方法に依存する主張であり、ライセンスが保証するものではない。メンテナンス面では、リポジトリはアーカイブされておらず、最終 push は 2026年8月31日、直近のリリースは 0.2.4（2024年12月3日）である。0.2.2 から 0.2.4 までが 2024年11月から12月に集中しており、その後はコミットが続いている一方でリリース間隔は空いている。0.x 系である点も含め、API が固定された安定版として扱うより、追従前提で使うほうが現実的だ。

編集部の結論

sdgx は、表形式データの合成を GAN 系モデルと LLM の両方で試したいチーム、とくに学習データを用意せずメタデータから生成する経路（SingleTableGPTModel の off-table inference）に関心がある場合に向く。逆に、画像やテキストなど表形式以外が主目的の案件、あるいは前処理を自前で完全に制御したい案件では、Data Processor の変換規約を先に読む必要があり、導入コストに見合わない可能性がある。最初に確認すべきは、README が案内する Colab 例で SingleTableGPTModel の入出力形式を実際に動かし、自分のメタデータ定義（sdgx.data_models.metadata）で期待する列型推論が得られるかどうかである。

公式情報源

1. hitsz-ids/synthetic-data-generator on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases