ダミーデータ生成ツール
ブラウザ内で生成され、送信されることはありません。氏名は架空のもので、電話番号は予約された555-01xx帯、IPアドレスはRFC 5737の文書用ブロックを使用しています。実在の人物やホストの情報は含まれません。
入力した内容が保存・記録・共有されることはありません。
必要なフィールドを定義して、現実的なダミーデータを最大1,000行、JSON・CSV・SQLのINSERT文として生成します。処理はすべてブラウザ内で行われ、実在する個人情報は一切使用しません。
使い方
- 各フィールドに名前を付け、値の種類を選びます。
- 行数と、JSON・CSV・SQLのいずれかを選びます。
- 「生成」を押し、結果をコピーします。
予約済みの範囲が重要な理由
生成される値はすべて、架空の用途のために正式に確保された範囲から取られています。これは細かいこだわりではなく、安全に実行できるテストスイートとそうでないものを分ける違いです。
電話番号は+1-555-01xxを使います。これは北米番号計画（NANP）が架空用途に予約している100番号分のブロックです。555のそれ以外の番号は何年も前に実際の割り当て用に開放されたため、555ならどれでもよいという昔の習慣はもう安全ではありません。メールアドレスとURLには、RFC 2606で予約され、誰にも登録されないことが保証されているexample.com、example.org、example.netを使います。IPアドレスは、ルーティングされないRFC 5737のドキュメント用ブロックから取っています。
これが防ぐ事故はよく知られており、今も繰り返し起きています。もっともらしいアドレスだらけのフィクスチャでテストを実行して実在の人に本物のメールを送ってしまう、負荷テストが実在の電話番号に発信してしまう、シードしたステージング環境のデータベースが本番のSMTPリレーにつながってしまう、といったものです。誰にも届かないフィクスチャは、手順ではなく構造でこれを解決します。
本当にバグを見つけるフィクスチャ
どれも無難なデータは扱いやすい反面、あまり役に立ちません。名前はすべて6〜10文字、文字列はすべてASCII、任意項目はすべて埋まっている。そんなデータで作ったテストは通りますが、本番で何が起きるかについては何も教えてくれません。
基本のデータセットができたら、手作業で追加する価値のあるケースがあります。NULLを許容するすべての列に空文字列とNULLを入れること（処理の経路が異なるため）。アポストロフィやハイフン、非ラテン文字（日本語を含む）を含む名前（文字コードのバグや安易なエスケープが表面化する場所です）。列の長さちょうどの値と、1文字超える値。月末、年末、2月29日、夏時間の切り替え日といった境界の日付。一意だと思い込んでいた項目の重複値。小さなレコードの中に1件だけ混じった巨大なレコード。
生成データは、量と形をすばやく用意するのに向いており、ページネーション、並べ替え、インデックスの挙動、表示の確認に必要なのはまさにそれです。一方、正しさの検証に必要なのは扱いにくい行で、それは生成ツールが偶然作ってくれるのを期待するより、意図して書くほうがたいてい確実です。
3つの出力形式
出力先がコードならJSONを選びます。APIのフィクスチャ、モックサーバー、シードスクリプト、テストが起動時に読み込むファイルなどです。レコードは、指定したフィールド名をキーとするオブジェクトの配列として出力されます。
CSVは一括インポートの経路に向いています。スプレッドシート、データベースのCOPY、管理画面のアップロードフォームなどです。読み込む前に表としてデータを目で確認したい場合にも適しています。受け取る側ではCSVのいつもの注意点が当てはまります。型を推測するツールは、数値に見えるものを勝手に解釈します。
SQLは、指定したテーブル名に対するINSERT文を1行ずつ出力します。ドライバーやスクリプトなしでどのクライアントでも実行できます。文字列値は引用符を二重にしてエスケープし、数値はそのまま、真偽値はTRUEとFALSEで書き、単純な単語でない識別子は二重引用符で囲みます。大量のシードデータなら出力をトランザクションで囲むとよいでしょう。トランザクション外で1,000件の文を個別に実行すると、ほとんどのデータベースで遅くなります。
本番データの匿名化で代用しない
現実的なテストデータが必要なとき、本番データベースのコピーを取って個人情報の項目を消すという近道に惹かれがちです。これがなぜ何度も失敗するのかを理解しておく価値があります。
氏名とメールアドレスを削除しても、データセットは匿名にはなりません。郵便番号、生年月日、性別といったありふれた属性の組み合わせや、いくつかのタイムスタンプと位置情報の組み合わせは、特定の1人に絞り込めることが多く、匿名とされたデータセットの再識別に関する研究は数多く、結論も一貫しています。しかも個人情報を消したコピーは、アクセス制御が弱く、開発者の閲覧範囲が広く、誰も把握していないバックアップがある環境に置かれた、本番そのままの精度のデータセットです。
スキーマから生成すれば、この種の問題をまるごと避けられます。データは正しい形を持ちながら出どころがないので、ステージング環境から漏れても何も起きていない事故で済みます。本番に近い分布が本当に必要な場合、正当化できる方法は、レコードを加工することではなく、統計をモデル化してそのモデルから生成することです。
列を埋めるのではなくデータセットを設計する
現実的なテストデータはランダムなデータではなく、形が本番と一致しているデータです。実際のテーブルは偏っています。ほとんどの顧客は注文が1件で、ごく一部が数千件を持ちます。ほとんどのドキュメントは短く、1つだけ極端に大きい。ほとんどのセッションは1分で終わり、いくつかは1日続きます。すべての顧客がちょうど3件ずつ注文を持つようなフィクスチャでは、注文が4000件ある顧客で破綻するクエリは永遠に表に出てきません。
量が重要なのも同じ理由です。ページネーション、ソート、インデックスの挙動は50行では見えず、5万行ではっきりします。短いリストなら一瞬で描画されるページも、現実的なデータでは数秒かかることがあります。想定より1桁多いデータを生成することは、いちばん安上がりな負荷テストです。
3つめは参照整合性です。注文には実在する顧客が、コメントには投稿が必要で、子レコードには妥当な日付を持つ親が必要です。顧客が登録する前に置かれた注文は、あとでそれを元に作るレポートすべてを混乱させる行になります。
シード、決定性、再現性
実行のたびに新しいランダムデータを生成するテストは、ときどき失敗します。そして散発的な失敗は、常に失敗するものより厄介です。誰も再現できないからです。ふつうの作法は固定シードを使うことです。毎回同じ並びになるので、失敗は再現でき、bisect にも意味が出ます。
これはデータに変化が欲しいという要求と衝突します。多くのチームが落ち着く妥協点は、シードをテスト出力に表示する、シード付きのジェネレーターです。必要なときには再現でき、時間の経過とともに多様にもなり、まれな組み合わせが何かを壊したときには、ログに残ったシードがそれをそのまま再構成してくれます。
シードスクリプトは冪等であるべきでもあります。2回流しても、全テーブルが倍になるのではなく、同じ状態になるべきです。実際には、先に truncate するか、自然キーで upsert することを意味します。再シードのたびにデータベースを作り直さなければならない開発者は、再シードそのものを避けるようになり、古くなったローカルのデータはそれ自体がひとつのバグの温床です。
フィクスチャ、ファクトリ、スナップショット
主なパターンは3つあり、それぞれ解く問題が違います。フィクスチャはテストの前に読み込む静的なファイルで、予測しやすく読みやすい一方、スキーマを変えるたびに全ファイルを直すことになるので保守が面倒です。ファクトリは妥当なデフォルトとテストごとの上書きでオブジェクトをコードから組み立てるので、テストは気にするフィールドだけを書けば済みます。最近のテストスイートで広く使われている手法です。
スナップショットは関数の出力を記録し、それが変わらないことを検証します。描画やシリアライズには非常に向いていますが、誰も差分を読まないときには危険です。バグをそのまま固定してしまう更新済みスナップショットは、大規模なスイートでよくある失敗の形です。
このツールが作るような生成データは、その3つすべての土台に位置します。性能やページネーションを現実的にする数千行という量の部分を埋め、一方で扱いにくい個別のレコードは手で書きます。先月に本番を壊したケースは、ジェネレーターが再現してくれることを期待するより、明示的に書き下ろす価値があるからです。
本番データのコピーがうまくいかない理由
本番のダンプを取って名前を消すのは、現実的なデータを得るいちばん早い道に見えますが、これは手続きの問題ではなく構造の問題で失敗します。直接的な識別子を取り除いてもデータセットは非識別化されません。郵便番号、生年月日、性別といったありふれた属性の組み合わせは、しばしば1人だけに一致します。匿名とされたデータセットの再識別に関する研究は数多く、結論も一貫しています。
運用上の問題はそれとは別で、同じくらい深刻です。洗浄済みのコピーは、アクセス制御がより緩く、開発者の閲覧範囲が広く、誰も管理していないバックアップが残る環境に置かれた、忠実度そのままの本番データセットです。GDPR では仮名化されたデータも依然として個人データであり、規制の対象です。これは法的助言ではなく一般的な観察であり、詳細は管轄地域と自社のデータ保護責任者によります。
スキーマから生成すれば、この種の問題を丸ごと回避できます。データは正しい形をしているのに来歴はまったく持たないので、ステージングからの流出は何も起きていない事案になります。本番に近い分布がどうしても必要なら、擁護できるやり方は、統計をモデル化してそのモデルから生成することであり、実在のレコードを加工することではありません。
出力を必要な場所へ読み込ませる
データベースなら、SQL 出力はドライバーなしでどのクライアントでも実行でき、トランザクションで包むと大きなシードが劇的に速くなります。トランザクションの外で1000件の文を個別に流すのは、ほぼどのエンジンでも遅いからです。PostgreSQL に限れば、行数が数千を超えた時点で CSV からの COPY が INSERT 文を大差で上回ります。
アプリケーション向けなら、たいてい JSON が適切な出力先です。テストが起動時に読み込むフィクスチャファイル、モックサーバーのレスポンス、ORM が読み込むシードスクリプトなどです。フィールド名は設定したとおりそのまま出てくるので、モデルのプロパティ名に合わせておけばマッピングの手間が省けます。
CSV は人が関わる経路のための形式です。取り込み前に目視するスプレッドシート、管理画面のアップロードフォーム、一括インポートツールなどですね。ただし受け取り側での CSV のいつもの注意点は忘れないでください。型を推測する取り込み側は、数値に見えるものについて勝手に判断しますし、参照番号の先頭のゼロがその典型的な犠牲者です。
よくある質問
- 生成したデータをリポジトリにコミットしても安全ですか？
- はい、そのように設計しています。氏名は架空のプールから選ばれ、電話番号は北米番号計画がフィクション用に予約している+1-555-01xx帯、メールアドレスとURLはRFC 2606が予約するexample.com系、IPアドレスはRFC 5737の文書用ブロックを使用します。実在のホストに接続したり、実在の番号に発信したりすることはありません。
- AIアシスタントにテストデータを頼むのではだめですか？
- 3行程度ならそれで十分です。ただしスキーマを固定して500行必要な場合は、再現性と正確な列名が求められ、それは生成ツールの領分です。フィールドの種類を1つ変えて再生成するほうがプロンプトを書き直すより速く、出力が端末の外に出ることもありません。
- ダミーデータ、テストデータ、モックデータの違いは何ですか？
- 実務上は同じものを指し、このページはそのすべてに対応します。重要なのは形式です。名前と型を持つ構造化されたレコードであり、レイアウトを埋めるだけでデータベースやAPIに読み込めないLorem ipsumのようなダミーテキストとは役割が異なります。
- SQL出力はどう使いますか？
- 入力したテーブル名に対する素のINSERT文が1行につき1文出力されるため、どのSQLクライアントでもそのまま実行できます。文字列はクォートを二重にしてエスケープし、数値はクォートせず、真偽値はTRUE・FALSEとして出力します。通常の識別子でない列名やテーブル名は二重引用符で囲みます。
- なぜ上限が1,000行なのですか？
- JSONで1,000行はすでに約100KBのテキストになり、テキストエリアで扱うと動作が重く感じ始める境目だからです。それ以上必要な場合は複数回に分けて生成してください。ID列は毎回1から振り直されるため、1つのテーブルに読み込む場合は調整が必要です。
- 乱数の品質はどうですか？
- crypto.getRandomValuesと棄却サンプリングを使用しており、当サイトのパスワード生成やUUID生成と同じ偏りのない乱数源です。架空の都市名にそこまでの品質は不要ですが、乱数の実装を1つに保てば、正しく実装すべき箇所も1つで済みます。
最終更新:
操作手順、期待した結果、実際の結果を記載してください。秘密情報や個人情報は削除してください。