開発会社とのキックオフが終わり、要件定義が進み始めた頃、ふとこんな依頼を受けて手が止まった経験はないでしょうか。「動作確認のためサンプルデータをください」「テスト環境の準備をお願いします」。本番の顧客情報をそのまま渡してもよいのか、何を加工すればよいのか、どこから手をつければよいのか。社内法務に聞いても「契約で縛っているから大丈夫」程度の回答しか返ってこず、判断がつかないまま持ち帰った──。
非エンジニアの発注者にとって、この場面はリスクと実務の板挟みになりやすいポイントです。データを渡さなければ開発は進みませんが、本番データを安易に提供して情報漏洩が起きた場合、契約があったとしても委託元である自社が法的責任を負います。一方で「全部マスキング」「全部新規作成」を求めると、開発スケジュールが大幅に遅延します。
本記事では、開発会社にサンプルデータとテスト環境を渡す前に、発注者がやるべき準備手順を実務目線で整理しました。データを渡す法的構造の整理から、渡してよいデータの見分け方、非エンジニアでも実施できるマスキング手法、クラウドアカウントの安全な受け渡し、開発終了後の後始末まで、一連のフローを社内承認資料に使える形でまとめています。
エンジニアでなくても判断できる粒度で書いていますので、社内の関係者と一緒に読み合わせて、自社のケースに当てはめながら準備を進めてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
開発会社に本番データをそのまま渡してはいけない理由
最初に整理しておきたいのは、「秘密保持契約（NDA）を結んでいれば本番データを渡してもよい」という発注者によくある誤解です。実際には、契約の有無にかかわらず、委託元である発注者には個人データの安全管理に関する責任が残ります。
「委託」と「第三者提供」の違い
個人情報保護法では、開発会社にデータを渡す行為を「第三者提供」（第27条）と「委託」（第27条第5項）の二つに区別しています。
区分 | 本人同意 | 該当例 |
|---|---|---|
第三者提供 | 原則必要 | データの利用権限を相手に渡し、相手の事業のために使わせる |
委託 | 不要 | 発注者の業務（システム開発）の一環として開発会社にデータ処理を委ねる |
システム開発の文脈でサンプルデータを渡すのは、多くの場合「委託」に該当します。委託であれば本人同意は不要ですが、その代わりに発注者には別の責務が課されます。
委託契約があっても発注者が負う責任
個人情報保護法第25条は、個人データの取扱いを委託する事業者に対し、委託先への「必要かつ適切な監督」を義務付けています。具体的には、(1) 適切な委託先の選定、(2) 委託先との契約締結、(3) 委託先での取扱状況の把握──の三つが監督義務の中核です（個人情報保護委員会ガイドライン）。
つまり、NDAを結んだから終わりではありません。委託先で漏洩が起きた場合、監督義務を果たしていなかった委託元（発注者）が責任を問われる構造になっています。
本番データを渡したことで起きうる事故パターン
監督義務を意識しないまま本番データを渡すと、次のような事故が起こります。
- 開発会社のテスト用データベースが誤って外部公開され、本番の顧客情報が流出
- 開発会社の担当エンジニアが、退職時に持ち出した私物PCにデータをコピーしたまま放置
- 開発会社が再委託した先（フリーランス・オフショア企業）で情報が漏れる
- 開発検証のため、テスト用CSVを社内Slackに添付してしまい、本来アクセス権のない人物が閲覧
いずれのケースも「契約書には書いてあった」では収まりません。本記事では、こうした事故を防ぐために発注者が何をすべきかを順に整理します。
渡してよいデータ・ダメなデータを見分ける判断フレーム
「個人情報を含むデータは全部NG」と機械的に判断すると、開発に必要な現実的なデータが何も渡せません。重要なのは、データ項目ごとに「機微度」「業務上の必要性」「代替手段の有無」の三層で判断するフレームを持つことです。
データの3区分と該当例
社内のデータを次の3区分で棚卸ししてください。
区分 | 該当データ例 | 取扱方針 |
|---|---|---|
個人情報 | 氏名・住所・電話番号・メールアドレス・顔写真・マイナンバー | 原則として加工せず渡さない |
機密情報 | 売上明細・取引先別収益・人事評価・契約金額・社員番号 | 業務上の必要性を精査し、必要に応じてマスキング |
一般情報 | 商品マスタ・カテゴリ分類・ステータスコード・地域コード | そのまま提供可能 |
判断に迷うのは「準個人情報」と呼ばれるグレーゾーンです。たとえば購入履歴は単体では個人を特定できませんが、顧客IDと紐付くと特定可能になります。自由記述コメントには氏名や勤務先が混入していることもあります。
開発フェーズ別に必要なデータ量・粒度
開発フェーズによって必要なデータの量と粒度は異なります。
フェーズ | 必要なデータ | 件数の目安 |
|---|---|---|
要件定義 | 業務理解のためのサンプル（数件のCSV） | 10〜50件 |
単体テスト | 機能ごとの境界値・異常値を含むデータ | 機能あたり数十件 |
結合テスト | テーブル間の整合性が取れたデータ | 数百〜数千件 |
受入テスト | 本番に近いボリュームと多様性 | 数千〜数万件 |
要件定義の段階で本番相当のデータ量は不要です。「とりあえず全件渡す」のではなく、フェーズごとに必要最小限を渡す原則を徹底してください。
判断チェックリスト
データを渡す前に、次の問いに答えられるか確認します。
- このデータは「本物」が必要か、それとも形式（カラム構造）が分かれば十分か
- 何件必要か。100件で足りるか、1万件必要か
- 誰がアクセスするか。開発会社のどの役職・どのチームメンバーまでか
- 渡したデータは開発終了後にどうなるか（削除・保管期間）
- 万一漏洩した場合、自社にどの程度の影響があるか
この5問に即答できないデータは、開発会社に渡すべきではありません。社内で答えを準備してから提供する流れを作ってください。
テスト用サンプルデータの3つの準備方法
ここからは具体的な準備方法に入ります。非エンジニアの発注者が現実的に選びうる方法は、大きく3つあります。それぞれコストと現実味のバランスが異なるため、開発フェーズと予算に応じて選択してください。
なお、次の章では「方法B: 本番データを加工して使う」を深掘りします。方法AやCを選んだ方は、次の章は飛ばして「テスト環境とクラウドアカウント」の章に進んでも問題ありません。
方法A: ダミーデータをゼロから作成する
実在しない架空のデータを生成する方法です。最も安全で、社内承認も得やすい選択肢です。
- フェイクデータ生成サービス（テストデータ生成サイト・ライブラリ）の活用
- Excelの
RANDBETWEEN関数やCHOOSE関数を組み合わせた架空データの量産 - 業務システムの「サンプル登録」機能を使って数十件投入する
メリットは個人情報保護法の対象外になる点、デメリットは本番の業務特性（よくある入力パターン、頻出する不正値）が再現されにくい点です。要件定義や単体テスト段階では十分に機能します。
方法B: 本番データを加工して使う
本番データから個人を特定できる情報を取り除いて使う方法です。マスキング・匿名化と呼ばれます。
- 氏名・住所・電話番号などを置換またはダミー値に変換
- 顧客IDをハッシュ化または連番に振り直す
- メールアドレスのドメインを例示用ドメイン（
example.com）に統一
メリットは業務の実態に近いデータでテストできる点、デメリットは加工に手間がかかり、加工が不十分だと個人特定リスクが残る点です。詳細手順は次の章で扱います。
方法C: 既存システムのサンプル機能を流用する
CRMや業務システムには、デモ用・トレーニング用のサンプルデータが組み込まれていることがあります。これをエクスポートして開発会社に渡します。
- Salesforce・kintone・freee などSaaSのデモデータ機能
- 業務システムベンダーが提供するサンプルCSV
- 過去の研修・展示会で使った架空データセット
メリットは加工コストがほぼゼロな点、デメリットはサンプルが少量で開発要件を満たさない場合がある点です。
どの方法を選ぶか
3つの方法を、コスト・現実味・納期で比較すると次の通りです。
観点 | 方法A: ゼロから作成 | 方法B: 本番データ加工 | 方法C: 既存サンプル流用 |
|---|---|---|---|
法的リスク | 低 | 中（加工品質次第） | 低 |
準備コスト | 中 | 高 | 低 |
業務実態の再現性 | 低 | 高 | 低〜中 |
推奨フェーズ | 要件定義・単体テスト | 結合テスト・受入テスト | 要件定義 |
実務では「要件定義は方法C、結合テスト以降は方法Bで本番相当」など、フェーズによって使い分けるのが現実的です。
個人情報を匿名化するマスキングの実施手順
ここでは方法B（本番データの加工）を深掘りします。専用ツールを導入しなくても、Excel・Googleスプレッドシートの基本機能で実施できる範囲を中心に解説します。
マスキングの4手法
代表的なマスキング手法は次の4つです（マスキング手法の解説）。
手法 | 概要 | 該当データ例 |
|---|---|---|
置換 | 別の固定値に置き換える | 氏名 → 「顧客A」「顧客B」 |
乱数化 | ランダム値で上書き | 電話番号 → 架空の番号 |
シャッフル | 列内で値を入れ替える | 住所列を行間でランダム入替 |
部分マスク | 一部だけ伏せる | メール → |
業務要件に応じてこれらを組み合わせます。たとえば氏名は「置換」、メールアドレスは「部分マスク」、電話番号は「乱数化」というように使い分けます。
Excel/スプレッドシートでできる加工例
非エンジニアでも実施できる具体的な操作は次のようなものです。
- 氏名列の置換: 別シートに「顧客A〜Z」の連番を用意し、
VLOOKUPまたはINDEX+MATCHで元データの氏名を置き換える - 電話番号の乱数化:
="090-"&TEXT(RANDBETWEEN(1000,9999),"0000")&"-"&TEXT(RANDBETWEEN(1000,9999),"0000")のような式で架空番号を生成 - 住所のシャッフル: 住所列のみ別の並び順で行入れ替えし、氏名と住所の組み合わせを壊す
- 自由記述コメントの削除: 特定キーワード（氏名・社名）を含む行をフィルタで除外
- 日付の丸め: 誕生日を「年月のみ」に丸めて日を削除する
加工後は必ず別ファイルとして保存し、元データと取り違えないようファイル名にも _masked などの接尾辞を付けてください。
テーブル間の参照整合性を壊さないコツ
複数テーブルにまたがるデータを加工する際に最も注意すべき点が、テーブル間の参照整合性です。
たとえば「顧客テーブル」と「注文テーブル」を渡す場合、顧客テーブルの顧客IDを別の値に置き換えるなら、注文テーブルの顧客IDも同じルールで置換しなければなりません。
実務では次の手順で進めます。
- 顧客IDの変換表を別シートに作成（旧ID → 新ID）
- 顧客テーブルの顧客IDを変換表で置換
- 注文テーブル・購買履歴テーブルなど関連する全テーブルにも同じ変換表を適用
- 加工後のデータで「ある顧客の注文をすべて取り出す」操作が成立するか目視確認
この整合性を壊すと、開発会社側で「テストデータが壊れていて結合テストにならない」と差し戻されます。
専用マスキングツールが必要になる場合
次のいずれかに該当する場合は、Excelでの手作業ではなく専用マスキングツールの導入を検討してください。
- データが数万件を超え、Excelで開けない・処理が極端に遅い
- データベース直接（MySQL・PostgreSQL等）から抽出する必要がある
- 加工ルールを毎月繰り返し適用する必要がある（定期テスト・本番リフレッシュ）
- 監査対応で加工処理のログを残す必要がある
導入判断はコスト次第ですが、年間で延べ100件以上の加工作業が発生する場合はツール化の費用対効果が出やすくなります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
テスト環境とクラウドアカウントの準備（発注者が行う手続き）
データの準備が整っても、それを動かすテスト環境の準備が抜けるとリスクは残ります。ここでは発注者が「何を行うか」のアクションに絞って整理します。具体的な設定手順（IAMポリシーのJSON記述など）は開発会社に委ねてかまいませんが、発注者として確認・指示すべきポイントは押さえておく必要があります。
テスト環境のパターンと発注者責任
テスト環境には大きく3パターンあり、責任の所在が異なります。
パターン | 環境の所有者 | 発注者の主な責任 |
|---|---|---|
自社用意 | 発注者 | アカウント発行・権限管理・データ管理 |
開発会社用意 | 開発会社 | 環境のセキュリティ要件指定・データ取扱の監督 |
共有クラウド | 共有 | 領域分離の確認・退場時の削除手配 |
どのパターンでも、データを置く側（多くは発注者）が責任を持ちます。開発会社が用意した環境であっても、本番データを渡す場合は環境の安全性を発注者として確認する義務があります。
クラウドアカウントを発行するときの確認ポイント
自社のAWS・GCPアカウントを開発会社に貸す場合、発注者が確認・指示すべきポイントは次の通りです。設定作業は社内インフラ担当または開発会社に依頼してかまいません。
- 開発会社の担当者ごとに個別のIAMユーザーを発行する（共有アカウントの使い回しは禁止）
- 必要最小限の権限のみ付与する（本番環境への書き込み権限は与えない）
- 多要素認証（MFA）を必須化する
- アクセス元を社内・開発会社のIPに制限する（VPNまたはIPホワイトリスト）
- アクセスログを取得し、定期的に確認する
これらは発注者が「やってほしい」と伝える項目であり、実装は技術担当に任せられます。「最小権限」「MFA」「ログ取得」の3点だけでも指示できれば、リスクは大きく下がります。
VPN・IP制限・アクセスログの設定
リモートで作業する開発会社とのやり取りでは、誰がいつアクセスしたかを記録できる仕組みを整えます。発注者として次の点を依頼します。
- VPN接続またはIPホワイトリスト方式でアクセス元を制限する
- アクセスログ（誰が・いつ・どこから・何を操作したか）を最低3か月保管する
- 異常検知（深夜の大量データダウンロード等）が起きた場合の通知ルールを決める
これらの設定の詳細は開発会社や社内インフラ担当に任せますが、「ログを取得する」「アクセス元を制限する」という方針は発注者として明示してください。
SaaSアカウントの発行手順
CRM・MA・会計などのSaaSをテスト利用させる場合は、本番テナントとは別のサンドボックス環境または別テナントを用意します。
- 本番テナントの権限を共有しない（読み取り専用権限であっても本番に触らせない）
- サンドボックス環境を発行する（Salesforceの開発者組織、kintoneのテスト環境など）
- ログイン履歴を週次で確認する
- 開発終了時にアカウントを即時無効化する
SaaSは「アカウントを発行してパスワードを伝えるだけ」で済んでしまうため、退場時の停止が忘れられがちです。次の章で扱う「廃棄」とセットで運用してください。
開発会社へのデータ受け渡し時に確認すべきこと
データと環境が整っても、受け渡しの手続きで漏れがあると意味がありません。ここでは契約・記録の観点で必要なチェック項目を整理します。
NDAと個人情報取扱特約の違い
NDA（秘密保持契約）は機密情報の漏洩を防ぐ一般的な契約ですが、個人データを扱う場合はそれだけでは不十分です。
契約種別 | 対象 | 必要な場面 |
|---|---|---|
NDA | 全ての機密情報 | あらゆる業務委託 |
個人情報取扱特約 | 個人データ | 個人情報を渡す全ての委託 |
個人情報取扱特約には、安全管理措置の内容・再委託の可否・漏洩時の報告義務・契約終了時のデータ返却または削除──などを明記します。NDAしか結んでいない場合は、追加で取扱特約を締結するか、NDA内に該当条項を盛り込んでください（業務委託契約書の個人情報保護条項）。
受け渡し時のチェックリスト
データを実際に渡すタイミングで、次の項目を確認します。
- 受け取る担当者の氏名・部署・連絡先を書面で確認した
- データの保管場所（クラウド・社内サーバー・PC）を確認した
- アクセスできる人の範囲を確認した
- 使用端末（個人PC不可・会社支給端末のみ等）を確認した
- 利用期間と廃棄予定日を書面で確認した
- 再委託の有無と、再委託先の管理体制を確認した
これらは「契約書に書いてあれば確認済み」ではなく、口頭でのヒアリングと書面の両方で確認する必要があります。
受領記録・提供記録の作成と保管
個人情報保護法では、個人データを第三者に提供した場合、提供記録の作成・保管が原則として求められます（一定期間、原則3年）。委託の場合は記録義務の対象外ですが、自社の管理上、次の情報を社内ログとして残すことを推奨します。
- 提供日
- 提供したデータの種類と件数
- 提供方法（暗号化USB・クラウドストレージ等）
- 受け取った担当者の氏名
- 利用目的
- 廃棄予定日
これは万一の漏洩時に「何が漏れたか」を即座に把握するためにも重要です。Excelの台帳でかまいませんので、毎回更新する習慣を作ってください。
開発終了後のテストデータ・環境の後始末
プロジェクトが終わった後の「後始末」は、競合の解説記事でも触れられていない盲点です。「データを削除しました」と口頭で済ませず、証跡を残して締めくくります。
テストデータの削除確認
開発終了時には、次の手順でデータの削除を確認します。
- 開発会社にデータ削除完了報告書を提出してもらう（削除日・削除担当者・削除対象を明記）
- クラウドストレージ・データベース・PC内のローカルコピーを含めて削除済みであることを確認
- バックアップからの削除も忘れずに依頼する
- 必要に応じて削除画面のスクリーンショットを取得してもらう
- 社内の提供記録台帳に削除完了日を記入する
削除完了報告書のフォーマットは、契約書のひな型に付属していることが多いので、契約段階で確認しておくと滞りなく進みます。
クラウドアカウントとSaaSアカウントの停止
開発会社の担当者が使っていたアカウントは、プロジェクト終了の翌営業日までに停止します。
- AWS・GCPのIAMユーザーを無効化（削除は監査ログ保全の観点で1〜3か月後）
- VPNアカウントの無効化
- SaaSのユーザーアカウントを無効化または削除
- 共有していたパスワードを変更（特に管理者アカウント）
「無効化」と「削除」は使い分けます。監査ログ保全のため、しばらくは無効化状態で残し、一定期間後に削除する運用が一般的です。
保守・運用フェーズに引き継ぐ場合
開発が終わっても保守契約で同じ開発会社が継続する場合、テストデータ・環境のルールを再定義します。
- 保守作業に必要な最小権限への絞り込み（開発時と比べて権限を縮小）
- 本番データへのアクセスが必要な場合の追加同意・特約の締結
- 月次・四半期での権限見直し（不要なアカウントの停止）
- インシデント発生時の連絡フローの再確認
開発フェーズの権限がそのまま保守フェーズに残ると、退職した担当者のアカウントが生き続けるなどの事故につながります。フェーズ移行時の権限見直しは必ず実施してください。
まとめ｜発注者がやるべきことの全体像
ここまで、開発会社に渡すサンプルデータとテスト環境の準備について、発注者の責務を5つのフェーズに分けて解説してきました。最後に全体像を整理します。
フェーズ | 発注者がやること |
|---|---|
1. 法的整理 | 委託と第三者提供の違いを理解し、委託先監督義務を認識する |
2. データ準備 | 渡してよいデータを判断し、必要に応じてマスキングを実施する |
3. 環境準備 | クラウドアカウント発行・最小権限・MFA・ログ取得を指示する |
4. 受け渡し | NDA + 個人情報取扱特約を締結し、受領記録を作成する |
5. 後始末 | データ削除確認・アカウント停止・保守フェーズへの権限見直し |
このフローを踏むことで、開発会社に「こういう形でデータと環境を準備します」と自信を持って提案でき、社内承認の説明資料としても使えるはずです。
最も重要なのは、「契約しているから大丈夫」ではなく「監督責任は自分にある」という前提に立つことです。本記事のチェックリストを社内の関係者と共有し、開発フェーズごとに見返してください。
なお、本記事では発注者の実務手順に焦点を絞ったため、個人情報保護法そのものの詳細解説、契約書面の具体的な条文例、開発会社へのキックオフ準備の進め方など、隣接領域には立ち入りませんでした。これらのテーマについては、別途専門の記事や法務担当者・弁護士への相談を通じて補完していただければと思います。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
