テストデータに実在の値を入れると、テストのつもりの操作が現実の誰かに届きます。よくあるのは、動作確認のメールが実在のアドレスへ送られる、SMS が実在の携帯番号に届く、といった事故です。本記事では、安全に使える予約済みの範囲と、氏名や住所を作るときの考え方を整理します。
example.com、IPアドレスは 192.0.2.0/24 など、規格で試験用に予約された値を使ってください。予約された範囲は「誰のものでもない」ことが保証されているので、間違って送信しても実害が出ません。
1. ドメインとメールアドレス
RFC 2606 は、文書や試験のために使えるトップレベルドメインと第2レベルドメインを予約しています。これらは実際に誰かが取得することがないため、テストデータに入れて安全です。
| 種類 | 予約されているもの |
|---|---|
| TLD | .test / .example / .invalid / .localhost |
| 第2レベル | example.com / example.net / example.org |
メールアドレスなら taro@example.com のように書きます。よくある間違いは test@test.com です。test.com は実在するドメインであり、予約されていません。同じく sample.com や hoge.com も実在します。「それらしい名前」ではなく、予約されていると規格に書いてある名前を使ってください。
2. IPアドレス
RFC 5737 が文書用の IPv4 アドレス範囲を3つ予約しています。
192.0.2.0/24（TEST-NET-1）198.51.100.0/24（TEST-NET-2）203.0.113.0/24（TEST-NET-3）
IPv6 では RFC 3849 が 2001:db8::/32 を文書用に予約しています。
これらは経路が公開されないので、うっかり接続先として設定しても外部の機器に届きません。逆に、1.1.1.1 や 8.8.8.8 のような「よく知られたIP」をテストデータに入れると、実在のサービスへリクエストが飛びます。私有アドレス（192.168.0.0/16 など）も、そのネットワーク内の実機に当たる可能性があるので試験用の値としては不適切です。
3. 電話番号
日本では、総務省が創作用（ドラマ・小説など）の電話番号として使える範囲を示しています。携帯電話であれば 090-0000-XXXX のように、下4桁の1つ上の桁がすべて0の並びが該当します。固定電話では市外局番に続けて 0570-0XX-XXX のような未使用帯があります。
ここで大事なのは、適当な数字を並べてはいけないという点です。11桁の数字をランダムに作れば、それは高い確率で誰かの実在の番号になります。SMS を送る機能のテストで実在の番号を入れれば、見知らぬ人の携帯に通知が届きます。
もう一点、送信そのものを止める仕組みを併用してください。テスト環境から外部へメールや SMS が出ていかないよう、送信先をすべて開発用の受信箱へ寄せる（メールキャッチャー）か、送信を無効化する設定を入れます。値を安全にすることと、経路を塞ぐことは別の対策で、両方必要です。
4. 氏名と住所
氏名と住所には、規格による予約がありません。ここは方針で決める必要があります。
- 氏名 — 「テスト 太郎」「サンプル 花子」のように、明らかに架空だと分かる姓を使います。実在しそうな姓名をランダムに組み合わせると、必ず実在する人と一致します。同姓同名の人が実在すること自体は避けられませんが、画面や帳票に出たときに架空だと分かることに意味があります。
- 住所 — 番地まで含めて実在の住所を作らないでください。とくに、実在する都道府県・市区町村に架空の番地を足すと、たまたま実在する住所になることがあります。郵便物を出す機能のテストで実在住所が使われると、実際に届きます。架空の町名（「○○市テスト町1-1-1」など）を使うか、番地部分を明らかに不自然な値にします。
- クレジットカード番号 — 決済代行事業者が公開しているテスト用カード番号だけを使ってください。桁数とチェックディジット（チェックディジットとは）を満たす数字を自作すると、実在のカード番号と衝突する可能性があります。
5. 本番データをコピーしない
いちばん手軽に見えて、いちばん危ないのが本番データベースの複製です。「マスキングしてから使う」という運用は、次の理由で失敗しやすいものです。
- マスキング対象の列を追加し忘れる。テーブルは増えていくので、初回に洗い出した一覧は必ず古くなります。
- 自由記述の欄に個人情報が入っている。備考欄・メモ欄・問い合わせ本文は、列名からは判断できません。
- マスキング前のデータが、コピーの途中で一時的に平文で存在する。
安全側に倒すなら、本番データを持ち出さず、テストデータを生成する方向で組み立ててください。本番でしか再現しない不具合を追うためにデータが必要な場合は、対象を1件に絞り、期限を決めて、誰がいつ取得したかを記録する、といった手続きを置きます。「開発用に全件コピー」を常態にしないことが要点です。
ダミーのテキストや住所をまとめて用意したい場合は、テストデータ生成ツールや和文ダミーテキストをお使いください。ブラウザ内で完結し、入力は送信されません。
よくある質問（FAQ）
テスト用のメールアドレスに test@test.com を使ってもよいですか？
使わないでください。test.com は実在するドメインで、試験用に予約されているわけではありません。RFC 2606 が予約しているのは example.com、example.net、example.org と、.test、.example、.invalid、.localhost の各トップレベルドメインです。これらは誰にも割り当てられないため、誤って送信しても実在の相手に届きません。
テストデータの電話番号はランダムな数字でよいですか？
よくありません。ランダムな11桁は高い確率で実在の番号と一致します。日本では総務省が創作用の電話番号帯を示しており、携帯電話では下位の桁が0で埋まる並びが該当します。あわせて、テスト環境から外部へメールやSMSが出ていかないよう送信経路自体を塞いでください。値を安全にすることと経路を塞ぐことは別の対策で、両方が必要です。
本番データをマスキングしてテストに使うのは安全ですか？
運用としては失敗しやすい方法です。テーブルや列は増えていくためマスキング対象の一覧は古くなりますし、備考欄や問い合わせ本文のような自由記述の欄は列名から個人情報の有無を判断できません。コピーの途中で平文のデータが一時的に存在する点も問題です。原則として本番データを持ち出さず、テストデータを生成する方向で設計してください。