テストデータの作り方｜本番データ利用のリスクとマスキングの実務手順

2026 8/11

2026年8月11日 2026年8月11日

テストケースが正しくても、データが合っていなければ欠陥は見つかりません。
逆に、データを工夫するだけで見つかる欠陥もあります。

一方、手軽だからと本番データをそのまま持ち込む現場もあります。
これは、情報漏えいの経路を増やす行為です。

テストデータは「網羅性」と「安全性」の両立で設計します。
どちらか一方だけでは、テスト工程のリスクが残ります。

この記事では、3つの作り方と選び方を整理します。
マスキングの手順と、外注時の取り扱いまで解説します。

テストデータの良し悪しが、検出できる欠陥を決める

テストデータは、テストケースの入力そのものです。
用意した値の範囲を超える欠陥は、原理的に検出できません。

たとえば、氏名がすべて全角の日本語だけなら、外字や半角の扱いは確認できません。
金額が小さい値ばかりなら、桁あふれも見つかりません。

データが不足すると	見逃す欠陥の例
文字種が偏っている	環境依存文字の文字化け、半角カナの不整合
件数が少ない	一覧の表示遅延、ページ分割の不備
状態が正常系だけ	退会済み、期限切れ、承認待ちでの誤動作
日付が現在付近だけ	年度をまたぐ集計、うるう年、月末の処理

テスト環境の整備が滞ると、データ準備も後回しになります。
環境面の課題は、テスト環境が用意できない｜毎回詰まる構造とPMの一手で扱っています。

テストデータの3つの作り方

作り方は大きく3種類です。
目的とリスクに応じて使い分けます。

方式	内容	長所	短所
本番コピー	本番データをそのまま複製する	実態に近い、準備が速い	個人情報を含み、漏えい時の影響が大きい
加工（マスキング）	本番データの個人情報を置き換える	分布を保ちつつ危険を下げられる	加工の設計と検証に工数がかかる
生成	仕様にもとづき人工的に作る	安全で、境界値を狙って作れる	実態と分布がずれ、想定外の値を再現しにくい

実務では、生成データを基本にします。
そのうえで、性能テストなど分布が重要な場面だけ加工データを使います。

本番コピーをそのまま使う選択は、原則として避けます。
使う場合は、範囲と期間を限定し、承認を記録します。

本番データをそのまま使うリスク

本番データには、氏名、住所、連絡先などが含まれます。
テスト環境は、本番より権限管理が緩いことが多い場所です。

開発端末やクラウド上に、複製が残り続ける
アクセス権限が広く、誰が閲覧したか追えない
テスト中の通知処理で、実在の宛先へメールが飛ぶ
外部委託先へ、そのまま渡ってしまう

実在の宛先への誤送信は、実際に起きている事故です。
メール送信先の差し替えは、環境設定として強制しておきます。

個人情報保護法との関係

個人情報は、あらかじめ特定した利用目的の範囲内で扱います。
テストでの利用が目的の範囲に含まれるかは、事前の確認が必要です。

法には、加工した情報の区分も定められています。
代表的な区分が、仮名加工情報と匿名加工情報です。

区分	考え方	主な制約
仮名加工情報	他の情報と照合しない限り、個人を特定できないように加工する	原則として社内での利用に限られ、第三者提供は制限される
匿名加工情報	個人を特定できず、元のデータを復元できないように加工する	基準に沿った加工と、公表などの手続が必要

いずれも、加工の基準や手続が細かく定められています。
自社の判断だけで進めず、法務や個人情報の管理部門に確認してください。

迷う場合は、そもそも個人情報を持ち込まない設計にします。
生成データであれば、この論点自体が発生しません。

マスキングの実務手順

加工する場合は、手順を決めて再現できる形にします。
担当者が手作業で消す運用は、抜けが起きます。

STEP1｜対象の項目を洗い出す

まず、テーブルと項目を一覧にします。
氏名や住所だけでなく、自由記述欄も対象です。

備考欄や問い合わせ本文には、個人情報が紛れ込みます。
添付ファイルとログも忘れずに含めます。

STEP2｜項目ごとに加工方法を決める

項目の使われ方によって、適した方法が変わります。
すべてを同じ文字で埋めると、テストにならない場合があります。

加工方法	内容	向いている項目
置換	別の値に置き換える	氏名、住所、電話番号
部分マスク	一部を伏せ字にする	口座番号、会員番号
ずらし	一定の規則で値をずらす	生年月日、日時
丸め	粒度を粗くする	年齢、郵便番号
削除	値を空にする	テストで使わない項目

関連する項目は、整合性を保って加工します。
住所と郵便番号がずれると、別の不具合を誘発します。

STEP3｜加工を自動化して繰り返せるようにする

加工処理は、スクリプトとして残します。
データを取り直すたびに、同じ手順で実行できるようにするためです。

手順書だけでは、担当が変わったときに再現できません。
実行ログも保管し、いつ誰が作ったかを追えるようにします。

STEP4｜加工結果を検証する

加工後は、残存を確認します。
「加工したつもり」で残るのが、最も多い事故です。

メールアドレスの形式で検索し、実在ドメインが残っていないか
電話番号の形式で検索し、市外局番が残っていないか
自由記述欄に、氏名らしき文字列が残っていないか
バックアップや一時テーブルに、加工前の値が残っていないか

テストデータ設計で押さえる観点

安全性を確保したら、次は網羅性です。
テスト観点と対応づけて、必要な値をそろえます。

観点	用意する値の例
境界値	桁数の上限と下限、金額の0円と上限額
文字種	半角カナ、絵文字、環境依存文字、記号
状態	有効、無効、退会済み、承認待ち、期限切れ
時間	月末、年度末、うるう年、日付をまたぐ処理
量	0件、1件、大量件数（性能確認用）
関連	親データのみ、子データが大量、参照先が削除済み

観点の洗い出し方は、テスト観点の洗い出し手順｜観点表と抜け漏れ防止で解説しています。

移行を伴う案件では、旧システム由来の異常値も想定します。
詳しくはデータ移行テストの進め方｜移行事故を防ぐ検証設計を参照してください。

テストデータの運用ルール

作ったあとの管理も、品質に直結します。
データが壊れると、失敗の原因が分からなくなります。

初期状態を復元できるようにする：実行前に戻せる仕組みを用意する
担当ごとに範囲を分ける：同じ会員IDを複数人で更新しない
版を管理する：どの版で実施したかを結果に記録する
保管期間と破棄手順を決める：案件終了後に確実に消す

破棄は、口頭の約束では守られません。
期限と方法を、契約書か作業手順に書きます。

外部に委託するときの取り扱い

テストを委託する場合、データの扱いは重要な確認項目です。
委託先での漏えいは、委託した側の責任も問われます。

確認項目	決めておく内容
データの種類	個人情報を渡すか、生成データのみか
保管場所	自社環境か、委託先環境か
受け渡し方法	暗号化、経路、権限の付与範囲
作業者の範囲	誰が閲覧できるか、再委託の可否
終了時の処理	削除の期限、削除の証明方法

最も安全なのは、個人情報を渡さずに済む設計です。
生成データで足りるなら、その前提で依頼範囲を組み立てます。

委託先の体制確認は、テスト代行の情報セキュリティ対策｜発注前に確認すべき7つの重要項目にまとめています。