テストデータの作り方｜マスキングと準備の実務

2026 8/13

2026年8月13日 2026年8月13日

テストの計画は立てたのに、いざ実行しようとすると「使えるデータがない」。受託開発の現場では、こうした足踏みが珍しくありません。

機能はできている、テストケースも書いた。それでも本番相当のデータが手元になければ、正常系すら十分に確認できません。個人情報を含む本番データはそのまま持ち出せず、かといってダミー値を手で1件ずつ作るのも骨が折れます。

テスト技法の分野で知られるBoris Beizerは、トランザクションを扱うテストではテストに使うリソースの30〜140%が、テストデータの生成・収集・抽出に費やされると指摘しています（Lee Copeland『ソフトウェアテスト技法』で紹介）。テストデータの準備は、テスト作業の「おまけ」ではなく、工数の主役になりうる領域です。

この記事では、テストデータの作り方を、要件の整理から作成手段の選び方、本番データを使う場合の個人情報の扱い、そして作った後の管理・後片付けまで、受託開発の実務に沿って解説します。専任のQAを置きにくい体制でも回せる段取りに落とし込むことを狙いとしています。読み終えたときに、次の案件で使い回せる自分なりの準備手順の形が見えているはずです。

なぜ受託開発でテストデータの準備は難しいのか

テストデータの用意が後回しになりがちなのには、受託開発ならではの理由があります。まずは「なぜ難しいのか」を言語化しておくと、対策の優先順位が付けやすくなります。

一番の壁は、本番データをそのまま使えないことです。氏名・住所・メールアドレスといった個人情報を含むデータは、テスト利用のために安易に持ち出せません。開発環境やテスト環境は本番ほど守りが固くないことも多く、情報の取り扱いには相応の配慮が要ります。

次に、テストに耐えるだけの「代表性」と「網羅性」が求められます。数件のきれいなデータでは、実運用で起きるばらつきや例外を再現できません。文字化けしそうな文字、極端に長い値、空欄、想定外のコード値など、本番には想定外が詰まっています。開発中に自分たちで入れた「田中太郎」「テスト太郎」ばかりのデータでは、こうした揺れをまず踏めません。

さらに、環境ごとにデータが必要になります。単体・結合・システム・受入と、テストのフェーズや環境が分かれるほど、それぞれに合ったデータセットを用意し直す手間が積み上がります。ある環境で作り込んだデータを別環境へ持っていく際に、IDの重複や参照先の不整合でつまずくことも珍しくありません。

兼任中心のテスト体制では、この準備工数が「見えないコスト」として担当者に集中しがちです。特定の人の手元にだけデータ生成の手順が残り、その担当が別案件に移った瞬間、誰も同じデータを再現できなくなる。これは受託開発でよく起きる属人化の典型です。

難しさの要因	具体的な中身	放置した場合のリスク
本番データが使えない	個人情報を含み持ち出しに制約がある	情報漏えい・利用目的の逸脱
代表性が足りない	きれいな数件しかなく例外を再現できない	本番でのみバグが顕在化
網羅性が足りない	境界値・異常値・大量データが不足	想定外の入力で不具合発生
環境ごとに必要	フェーズ・環境ごとに作り直す	準備工数の増大と属人化

加えて、スケジュールの圧迫も準備を難しくします。受託開発では、開発が遅れた分のしわ寄せがテスト工程に集まりがちです。データ準備は「テストの前準備」という位置づけのため、締め切りが迫ると最初に削られ、結果として手近なデータだけで済ませてしまう。この妥協が、リリース後のバグとして跳ね返ってきます。

こうした要因は、どれか1つではなく重なって効いてきます。だからこそ「どんなデータが要るのか」を先に定義し、そのうえで作り方を選ぶ順序が大切になります。要件を決めずにいきなり本番データやツールに手を伸ばすと、量はあるのに肝心のバグを踏めないデータが出来上がってしまいます。準備の質は、着手前の一手間で決まると考えておくとよいでしょう。

テストデータに求められる5つの要件

作り方の話に入る前に、そもそも「良いテストデータとは何か」を押さえます。要件が曖昧なままだと、後工程で「何件・どんなデータを・どの手段で用意するか」の判断がぶれてしまいます。

テストデータに求められる代表的な観点は、次の5つです。

正常系データ：仕様どおりの入力で、想定どおりに処理が通ることを確認するための素直なデータ
異常系データ：必須項目の欠落、桁あふれ、不正なコード値など、エラー処理を確認するためのデータ
境界値データ：入力の上限・下限や桁の変わり目など、不具合が集中しやすい境目のデータ
大量データ：件数が増えたときの性能・表示崩れ・タイムアウトを確認するための量のあるデータ
本番相当のばらつき：実データにある文字種・長さ・空欄・重複などの「揺れ」を再現したデータ

不具合は仕様の境目に潜みやすいため、境界値と異常系のデータをどれだけ用意できるかが、テストの実力を左右します。

抽象的なままだとイメージしにくいので、会員登録フォームを例に、5つの観点が具体的にどんなデータになるかを並べてみます。

観点	会員登録フォームでのデータ例
正常系	正しい形式の氏名・メールアドレス・規定を満たすパスワード
異常系	メール欄が空、パスワードが規定文字数未満、記号のみのメール
境界値	パスワードが最小桁ちょうど、最大桁、最大桁+1文字
大量	10万件規模の会員レコードでの一覧表示・検索・並び替え
ばらつき	旧字体・絵文字・全角空白・非常に長い住所を含む氏名

このように分解すると、必要なデータの「種類」と「件数感」が具体的に見えてきます。

大量データについては、単に件数を増やせばよいわけではない点に注意します。同じ値ばかりを大量に並べても、実運用の負荷やばらつきは再現できません。件数を稼ぐと同時に、値の分布にも幅を持たせることが大切です。たとえば会員一覧なら、登録日が特定の日に偏らないよう散らす、氏名の長さにばらつきを持たせる、といった配慮が、表示崩れや並び替えの不具合を炙り出します。

境目の値をどう選ぶかは、テスト設計の技法とセットで考えると迷いません。入力の上限・下限やその前後をどう突くかは境界値分析のやり方とテストケースの作り方で整理しています。

また、無数の入力を「代表値」に絞り込む考え方も欠かせません。どの値を1件で代表させるかの判断は同値分割法での有効・無効同値の見つけ方が参考になります。テストデータは、この2つの技法で導いた値を、具体的なレコードに落とし込む作業だと捉えると設計しやすくなります。

逆に言えば、技法で洗い出した観点が抜けていると、どれだけデータの件数を増やしても品質は上がりません。まず観点を固め、その観点を満たす最小限のデータを用意し、必要に応じて量を足していく。この順序を守るだけで、準備の手戻りはぐっと減ります。要件定義とデータ作成は、別々の作業ではなく地続きだと意識しておきましょう。

テストデータの作り方｜4つの選択肢と使い分け

テストデータの作り方には、大きく4つの選択肢があります。どれか1つが正解ではなく、テストの目的やデータの機密度に応じて組み合わせるのが実務的です。

代表的な4手段の特徴を、まず一覧で比較します。

作り方	主な用途	メリット	注意点
手動作成	少数の正常系・特定の異常系	意図した値をピンポイントで作れる	件数が増えると非効率・属人化
データ生成ツール	大量データ・組み合わせ網羅	大量・多様なパターンを高速生成	業務的にありえない値が混じる
本番データのマスキング/匿名化	本番相当のばらつき再現	実運用の揺れを再現しやすい	個人情報の加工と管理が必須
合成データ	個人情報を避けつつ本番風	機密を持ち出さずに済む	実データ特有の例外は再現しにくい

手動作成とデータ生成ツール

手動作成は、狙った境界値や特定の異常系を1件だけ確実に用意したいときに向きます。Excelやスクリプトで直接値を打ち込むため、意図がそのまま反映されます。一方で、数百件・数万件の規模になると現実的ではありません。手作業で作ったデータは、なぜその値にしたのかが本人以外に伝わりにくいという弱点もあります。

データ生成ツールは、組み合わせや大量データを一気に作れるのが強みです。氏名・住所・日付などを一定のルールで大量に吐き出せます。組み合わせの網羅では、オールペア法のようにパターンを絞る考え方が役立ちます。ただし、機械的に生成した値には「実際の業務ではあり得ない組み合わせ」が混じります。生成ツールを使うときは、制約条件で無効な組み合わせをあらかじめ除外する設計が欠かせません。

手動と生成ツールの分かれ目は、件数と再現の必要性です。数十件までで、値の意図が明確なら手動が速い。数百件を超える、あるいは何度も同じデータを作り直す見込みがあるなら、最初にスクリプト化しておいたほうが後々の工数を抑えられます。目安として、同じデータセットを3回以上作り直しそうなら、生成を自動化する価値が出てきます。

マスキング/匿名化と合成データ

本番データのマスキング/匿名化は、実運用のばらつきを最も忠実に再現できる手段です。長年の運用で蓄積された「想定外のデータ」がそのまま手に入るため、机上では思いつかない不具合を踏めます。反面、個人情報の扱いという最大の論点が伴います。これは次章で詳しく扱います。

合成データは、実在の個人情報を持ち出さずに本番風のデータを用意する考え方です。氏名や住所を「それらしい」ダミーとしてルールから生成するため、機密面のリスクを抑えられます。近年はデータの統計的な傾向だけを模倣する生成手法もありますが、まずはルールベースの生成でも十分実用になります。機密度が高い案件ほど、まず合成データで賄えないかを検討すると安全側に倒せます。

合成データの弱点は、実データにしかない「想定外」を再現しにくいことです。運用の中で自然に溜まった不正な文字コードや、過去の仕様変更で生まれた中途半端なデータは、ルールから作った合成データには現れません。この穴を埋めるには、本番で実際に起きた不具合のデータをサンプルとして手元に控えておき、合成データに意図的に混ぜ込むと効果的です。

実務では、これらを混ぜて使うのが基本です。骨格は合成データやツール生成で量を確保し、狙った境界値だけを手動で足す。そのうえで、どうしても本番相当の揺れが必要な部分だけをマスキングしたデータで補う。こうした組み立てが現実的です。どの手段を主役にするかは、扱うデータの機密度が高いほど合成データ寄りに、実運用の再現性が重要なほどマスキング寄りに、と考えると判断がぶれません。

本番データを使うときの個人情報の扱い

本番データは魅力的ですが、個人情報を含む以上、扱いを誤ると重大なリスクになります。ここは断定を避けつつ、実務で外さないポイントに絞って整理します。

前提として、氏名・住所・連絡先などを含むデータは個人情報にあたります。テスト目的での利用や、開発環境・外注先への持ち出しには、利用目的や安全管理の観点で配慮が必要です。詳しい制度は個人情報保護委員会の法令・ガイドラインで確認できます。情報セキュリティ全般の実務指針は、IPA（情報処理推進機構）が発信するデジタル領域の情報も参考になります。

マスキングの主な手法

よく使われる加工がマスキングです。値の一部または全部を別の値に差し替えることで、そのままでは個人を識別しにくくします。マスキングにはいくつかの型があり、項目の性質に応じて使い分けます。

手法	内容	向く場面	注意点
置換（ダミー化）	実値を形式の合ったダミー値に置き換える	氏名・住所など表示項目	ダミーの形式を実データに合わせる
ナル化・固定化	値を空や固定値にする	テストに不要な機密項目	必須項目だと処理が止まる
部分マスク	一部だけ伏字にする（先頭以外を伏せる等）	メール・電話番号	桁や形式から推測される場合がある
シャッフル	列内で値を並べ替える	分布を保ちたい項目	行間の整合性が崩れやすい
生成（合成）	ルールに基づき新規に作り直す	個人情報を持ち出せない場合	実データ特有の例外が出ない

ここで注意したいのが、参照整合性です。顧客IDのようなキー項目をマスキングで変えると、関連するテーブル間のつながりが壊れることがあります。キー項目を加工するときは、全テーブルで同じルールに一貫して変換しないと、データの整合性が崩れます。

さらに、マスキングをしても、他の情報と照合して個人を特定できる状態なら、依然として個人情報として扱う必要があります。伏字にしたつもりでも、生年月日や地域の組み合わせから個人が絞り込めるケースがあるためです。

見落としやすいのが、本番データを「とりあえずコピーしただけ」の検証環境です。加工を後回しにして本番のコピーを置いたまま作業を進めると、その環境自体が個人情報の保管場所になってしまいます。検証環境は本番ほど監視やアクセス制御が行き届かないことも多く、コピーした瞬間からリスクが発生していると考えるべきです。本番データを扱うなら、コピーと加工はワンセットで行うのが原則です。

仮名加工情報と匿名加工情報の違い

個人情報保護法には、加工の程度に応じた制度として「仮名加工情報」と「匿名加工情報」があります。両者は目的も利用条件も異なるため、混同しないことが大切です。

区分	加工の考え方	主な利用イメージ
マスキング（実務手法）	値の一部・全部を伏字やダミーに置換	テスト用に見た目を隠す簡易対応
仮名加工情報	他の情報と照合しない限り個人を識別できないよう加工	主に事業者内部での分析・利用
匿名加工情報	個人を識別できず、かつ元データを復元できないよう加工	定められた基準を満たせば第三者提供も可能

仮名加工情報は、原則として第三者への提供が想定されておらず、事業者内部での利用が中心です。匿名加工情報は、より厳しい基準を満たすことで、本人の同意なく第三者提供できる余地があります。テスト用途では、社外の委託先にデータを渡すかどうかで、どちらの制度が関わるかの見え方が変わってきます。社内の環境だけで完結するのか、外注先へ持ち出すのかを、加工方針を決める前にはっきりさせておきましょう。仮名加工情報と匿名加工情報は「元に戻せるか」「第三者に渡せるか」で性格が大きく異なります。それぞれの具体的な加工基準は、個人情報保護委員会のガイドライン等で定められているため、実際に制度として運用する際は原典の確認が欠かせません。

外注先へのデータ受け渡し

実務でとくに注意したいのが、外注先へのデータ受け渡しです。テストを社外に委託する場合、個人情報を含むデータをそのまま渡すのは避けたい場面が多くなります。安全側の選択肢を挙げます。

個人情報を含む項目は、そもそも渡さない（合成データや十分に加工したデータに置き換える）
どうしても本番相当が必要な場合は、加工の基準と管理方法を事前に取り決める
受け渡し経路・保管場所・削除タイミングを契約や手順で明確にする
テスト完了後のデータ削除を、受け渡し前に約束事として決めておく

外注前のデータ準備や受け渡しの段取りは、テスト全体の準備と一体で考えると漏れが減ります。依頼前に何をそろえるべきかはテスト代行を依頼する前の準備で押さえる段取りにまとめています。個人情報の取り扱いは、迷ったら「渡さない・持ち出さない」を初期設定にするのが安全です。

テストデータの作り方を支える管理と後片付け

データは作って終わりではありません。テストデータの作り方を仕組みとして回すには、作った後の管理と後片付けまで含めて設計する必要があります。ここが弱いと、同じデータを二度と再現できず、テストの信頼性そのものが揺らぎます。

再現性を高めるデータの外部化

まず重視したいのが再現性です。「あのとき通ったテスト」を後から同じ条件で再実行できることが、回帰テストや不具合の再現調査で効いてきます。逆に、環境に手作業で少しずつ足していったデータは、環境をリセットした瞬間に失われます。

テスト自動化の実務でも、データをスクリプトに直接書き込むのは避けるべきだとされています。林尚平『ソフトウェアテスト自動化の教科書』では、データをスクリプトの外のファイルに置き、そこから読み込む設計が推奨されています。データに変更が入ったとき、スクリプトを触らずにファイルの差し替えだけで済むためです。

この考え方は、自動化に限らず手動テストでも有効です。投入するデータをCSVや投入スクリプトとして独立させておけば、いつでも同じ初期状態を作り直せます。テストデータを外部ファイルとして独立させると、再現性と保守性が一気に高まります。

管理と後片付けで押さえる観点

管理で押さえたい観点を整理します。

バージョン管理：どの版のデータでテストしたかを記録し、機能の版とひも付ける
生成手順の保存：手作業ではなく、生成スクリプトや手順書として残し誰でも再現できるようにする
環境との対応付け：どの環境にどのデータを投入したかを一覧化する
アクセス管理：機密を含むデータは閲覧・保管の範囲を限定する
後片付け（削除）：テスト完了後にデータを確実に削除し、放置による漏えいリスクを断つ

アクセス管理も、ルールを決めるだけでは形骸化しがちです。誰がどのデータに触れられるかを最小限に絞り、機密を含むデータは共有フォルダに置きっぱなしにしない。こうした運用は、面倒に思えても事故が起きたときの影響範囲を大きく左右します。とくに複数案件を並行する体制では、案件ごとにデータの置き場所と権限を分けておくと、取り違えや意図しない共有を防げます。

とくに後片付けは見落とされがちです。テストが終わった環境に個人情報を含むデータが残り続けるのは、それ自体がリスクになります。開発が一段落した検証環境が、いつの間にか本番相当のデータを抱えたまま放置される、というのはよくある光景です。「使用後に削除する」までをテスト手順の一部として明文化しておきましょう。

データにも「寿命」があると考えると、後片付けの判断がしやすくなります。作ったデータをいつまで保持し、いつ削除するかをあらかじめ決めておく。この考え方は、機能の版が変わればテストデータも作り直す、という運用ともかみ合います。古い版のデータを漫然と残すと、どれが最新なのか分からなくなり、誤ったデータでテストしてしまう事故につながります。

再現性・バージョン・後片付けの3点は、テスト計画の段階で決めておくと後で慌てません。計画への落とし込み方はテスト計画の立て方と計画書の違いも参考にしてください。準備・実行・片付けまでを1つの流れとして計画に書き込んでおくと、担当者が変わっても運用が途切れません。

テストデータ準備の実践ステップとチェックリスト

ここまでの内容を、月曜から動かせる手順に落とし込みます。専任QAがいない体制でも、次の順で進めれば大きく外しません。

STEP1 目的の確定：どのテスト（正常系・異常系・性能など）のためのデータかを1行で書き出す
STEP2 要件の洗い出し：正常系・異常系・境界値・大量・ばらつきの5観点で必要なデータを列挙する
STEP3 手段の選定：機密度と件数から、手動・生成ツール・マスキング・合成データを組み合わせる
STEP4 加工と生成：個人情報を含む場合は加工方針を決め、生成手順を残しながら作る
STEP5 管理と後片付け：投入先・版・削除タイミングを記録し、完了後に削除まで実施する

会員登録機能での進め方の例

流れをイメージしやすいよう、会員登録機能を題材に当てはめてみます。まずSTEP1で「新規登録の入力チェックと大量表示の性能を確認する」と目的を1行で定めます。

STEP2では、氏名やパスワードの境界値、必須項目が空のパターン、10万件規模の会員一覧といった必要データを洗い出します。STEP3で、境界値と異常系は手動で数十件、大量データは生成ツールで一括、というように手段を割り振ります。

STEP4では、本番の会員データを使いたい場合に氏名やメールをマスキングし、顧客IDは全テーブルで同じルールに変換します。ここで、会員に紐づく注文履歴やポイント残高のテーブルも同じ変換ルールをかけないと、会員と履歴のつながりが切れてしまいます。加工は関連テーブルをまとめて対象にするのが鉄則です。

最後にSTEP5で、投入したデータの版と環境を記録し、検証が終わったら環境ごとデータを削除します。削除まで終えて初めて、その回のテストが「片付いた」状態になります。この一連を一度テンプレート化すれば、次の案件でも土台を使い回せます。案件ごとにゼロから考えるのではなく、前回の手順書を叩き台に差分だけ直す、という進め方が現実的です。

準備の抜け漏れを防ぐために、着手前に次のチェックリストを確認してください。