2026年の合成テストデータ：シード付き、安全、再現可能

合成データは人からサンプリングされるのではなく、ルールから生成されます。名前リストから組み立てられた名前、国別フィクスチャから組み立てられた住所、予約済みブロックからの電話番号、予約済みドメインのメールアドレス。いずれも製造されたものであり、実在の対象を指すものはありません。再現性がランダムノイズとの違いを生みます。シードなしの出力はレビュー、差分比較、再生ができないからです。

匿名化された本番データは合成データではありません。実在の行をマスキングしても同じ分布が残り、多くの場合同じ再識別リスクも残ります。ドメインを保持したままマスキングされた EMAIL 列は、依然として雇用主を漏らします。テストに本番同様の形のデータが必要なら、それは集約とアクセスに関する別の議論であり、ジェネレーターが正直に提供できるものではありません。

コミットされたフィクスチャファイルには利点が1つあります。検査が簡単なことです。問題はいくつかあります。スキーマが変わっても誰も更新しないため、ドリフトします。リポジトリを肥大化させます。どのバージョンが最新か誰も分からなくなるまでプロジェクト間でコピーされます。そして、いつの間にか誰もがテストする唯一のデータになり、スイートは2021年に誰かが入力した値だけをカバーするようになります。

シード付き生成は入力を小さく、出力を大きく保ちます。シードとジェネレーターのバージョンがフィクスチャです。必要に応じて再生成し、レビュー用に最初と最後のレコードだけをスナップショットし、ジェネレーター出力の変更は再ベースラインを必要とする意図的な変更として扱います。唯一の要件はジェネレーターを固定することです。アルゴリズムが変わったアップグレード版ジェネレーターは、同じシードでも新しいデータセットになるからです。

いくつかの標準は、ドキュメントとテスト用に値を予約しています。それを使うことはスタイルの好みではなく、保証された無害なフィクスチャと、誰かのものかもしれないフィクスチャの違いです。予約済みブロックは安定しており、広く文書化され、ほとんどのバリデーターが構文的に正常なものとして受け入れます。

メールには、予約済みで登録できない .test 配下のドメイン、たとえば example.test を使います。北米番号計画の電話番号には、555-0100 から 555-0199 のブロックがフィクション用に予約されています。IP アドレスには、IPv4 では 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24、IPv6 では 2001:db8::/32 がドキュメント用範囲です。MAC アドレスには、ドキュメント用範囲が 00-00-5E-00-53-00 から 00-00-5E-00-53-FF で、U/L ビットを設定したローカル管理アドレスもフィクスチャに安全です。

ほとんどのシステムは複数のエンティティを必要とします。注文には顧客、配送先住所、請求先住所があり、スキーマが強制する方法で3つが一致しなければなりません。請求先住所が米国にあり、配送先住所が日本にある場合、税計算と配送業者の選択がその組み合わせを受け入れなければ、テスト対象の動作とは無関係な理由でテストが失敗します。

行ではなく関係を生成します。子シードを親シードから導出し、注文とその住所が1つの単位として再現可能になるようにします。どのフィールドが一致しなければならないかを意図的に決めます。配送先と請求先の国は通常同じ、郵便番号はフィクスチャの都市と一致、通貨は国と一致。これらの制約をファクトリにエンコードし、壊れたフィクスチャが3層下のアサーションではなく生成時に失敗するようにします。

このサイトは社会保障番号、支払カード番号、IMEI または IMSI の値、Bluetooth デバイスアドレス、シリアル番号を生成しません。各拒否には理由があります。SSN は米国で法的に制限された識別子です。カード番号には Luhn チェックサムがあるため、もっともらしいものは素朴なバリデーターを通過し、その後サポートチケットに貼り付けられる可能性があります。IMEI にはチェックディジットと割り当てレジストリがあります。Bluetooth アドレスは MAC 形式を共有しますがベンダーの意味を持たず、生成されたものは MAC ツールが避けるように設計されている混乱を招きます。

同じ理由がチェックサムやレジストリを持つあらゆる識別子に当てはまります。テストに本当に必要な場合は、ジェネレーターではなく、プロセッサまたは発行機関が公式に公開したテスト値を使用してください。そうすれば、テストパターンを認識する人には明らかに偽物であり、スクリーンショットがコンプライアンスレビューの対象になることもありません。

テスト時に100レコードを生成するのは安価です。1000万レコードはそうではなく、テストセットアップ内で行うと実行時間を支配します。大量ボリュームは一度だけ分離されたストアに事前計算し、シードをマニフェストに記録し、ジェネレーターをホットパスから外します。中程度のボリュームでは、行ごとではなく単一バッチで生成します。行ごとのセットアップが実際のコストであることが多いからです。

決定性にはパフォーマンスの側面もあります。並列ワーカーが単一の逐次ジェネレーターを共有してはいけません。インターリーブによってどのワーカーがどのレコードを得るかが変わるからです。各ワーカーに実行シードとワーカーインデックスから導出した独自のシードを与え、スケジューリングに関係なくデータセットが安定するようにします。これにより、スイート全体を再実行せずにワーカー3の失敗を再現できます。

優れた合成データの危険は、本物に見えることです。生成されたすべてのレコードにマーカーを付けます。フィクスチャフラグ、専用テナント、example.test のメール、555-01xx 範囲の電話。それらのレコードがメール送信、支払い取得、分析への流入を行うことをブロックします。本番 CRM に到達したデモ顧客は、営業担当者が気づくのを待つサポートインシデントです。

また、コンプライアンスのために保持されるログや、公開されるスクリーンショットから生成データを遠ざけます。値が誰も記述していなくても、読者は画像からそれを判断できず、後で説明する方が今ラベルを付けるより高くつきます。スクリーンショットに現実的な住所を表示する必要がある場合は、ドキュメント範囲の値を使い、目に見える「サンプルデータ」キャプションを追加します。

生成されたデータセットを共有環境で使用する前に、4つの質問に答える必要があります。どこから来たのか、再生成できるのか。すべての値が予約済みまたはローカル管理範囲にあるか。スキーマ制約と参照ルールを満たしているか。そして、人間の読者が顧客と誤認しないようにラベル付けされているか。

いずれかの答えが「いいえ」なら、データセットは準備できていません。これは意図的に厳格です。誤った答えのコストは非対称だからです。再生成には数分かかる一方、収益レポートに合成顧客がいると四半期にわたって意思決定を歪める可能性があります。チェックリストは wiki のコメントではなく、レビューの一部として実行してください。