開発・テスト環境の個人情報は、本番と同じように守られているか？
本番の顧客データベースへ入るには、申請と承認が必要です。
一方、不具合を再現するために取り出したデータは、開発用の共有領域に置かれています。氏名を置き換えたから大丈夫だと考え、処理が終わった後も残っています。
これは、開発の進め方を点検するための架空の場面です。レビューで問われたのは、その領域が本番かどうかではありませんでした。住所、連絡先、履歴、識別子を組み合わせたとき、実在の顧客に結び付く情報が残っていないか、という問いです。
必要な保護は、環境の名前より、そこにあるデータと使える権限から決めておきましょう。 開発用という分類は、顧客への影響を小さくしてくれるわけではありません。何を検証するために、どの実データが必要かを説明するところから始めましょう。
公的な事例にも、管理から外れた保存先がある
個人情報保護委員会（PPC）の注意喚起資料「WARNING」には、従業者が個人で管理する領域に業務の個人データを保存し、システムへの不正アクセス時にそこからも漏えいした事例があります。古いデータが残り、被害の対象が広がった点も挙げられています。
これは開発環境の事例と限定されたものではありません。それでも、管理された元データから取り出した後のファイルが、別の運用に置かれるという構造は、開発や分析の作業でも確認する価値があります。
この事例を、開発担当者個人の注意不足という結論だけで終えないことが大切です。元の管理場所からデータを取り出す理由があり、取り出した後のルールが業務に合っていなければ、同じ形の保存が繰り返されます。作業の必要性と管理の方法を一緒に見直す必要があります。
他社の有名な事故名がなければ、自社を点検できないわけではありません。障害調査、移行のリハーサル、デモ、AIの評価などで、元の管理場所から個人情報を取り出す作業があるかを見れば、確認の対象は具体化します。
「氏名を消した」は、何を確認した結果か
想定場面のデータには、氏名以外の項目が残っていたとします。住所、メールアドレス、会員番号、問い合わせ内容のどれかに、個人と結び付く情報が含まれる可能性があります。自由記述の中に本人の連絡先が書かれている場合も、確認対象になります。
ここで避けたいのは、名前を置換したファイルを、直ちに匿名のデータと呼ぶことです。法令上の匿名加工情報などに該当するかは、加工の方法や情報の組み合わせを踏まえた別の判断になります。見た目だけで結論を出さないようにします。
技術チームが示すべきなのは、どの項目をどう変え、その結果として何を再現できるかです。顧客のメールアドレスを使わずに通知処理を確認できるなら、実際の送信先を持ち込む必要は減らせます。逆に、項目間の関係を変えると再現しなくなる問題なら、その関係をどう模擬するかを考えます。
データを隠す作業と、試験を成立させる設計を別々に進めると、現場は実データへ戻りがちになります。必要な再現条件を先に共有し、その条件を保った代替データを作る方が、継続して使いやすい方法になります。
実データが必要だという説明を、一段具体化する
障害の再現には本番データが必要だという要望を、頭から否定する必要はありません。ただし、本番データが必要なのはどの範囲かを、具体的に確かめます。
一件の形式の問題なのか、日付の前後関係なのか、家族や契約をまたぐ対応関係なのか、文字の組み合わせなのでしょうか。必要な条件がわかれば、データ全体を複製せずに試せる可能性があります。必要件数や対象期間も、その条件から絞れます。
PPCのQ&Aは、テストデータとして個人データを必要最小限にし、利用を禁止する方法や、動作確認に影響しない範囲で一部を置き換える方法を例示しています。方法を一つに固定するのでなく、試験の目的と情報の保護を両方満たす考え方として読み取れます。
それでも実データでなければ確かめられない範囲が残るなら、例外の条件を定めます。対象を絞り、利用者と期間を限定し、取り出しと消去の記録を残します。必要性を説明した記録があれば、次回も無条件に同じデータをコピーする運用を避けられます。
守るべきものは、データと「入るための鍵」
開発環境の点検では、ファイルだけに注目しないことも重要です。クラウドやAPI（システム同士が情報や機能をやり取りする窓口）へ入る資格情報（IDやパスワード、接続用の鍵など）が残っていれば、その環境の中で完結しないアクセスにつながる可能性があります。
例えば、試験用の設定ファイルに、本番へ接続できる情報が混ざっていないかを確認します。担当者個人のIDと、自動処理のサービスIDが、どの環境で何ができるのかも確認します。使わなくなった接続や、退任した担当者の権限が残っていないかを確かめます。
これは、そのような不備が特定の企業にあったという指摘ではありません。開発用の資産が何に届くかを追うための、設計と運用の確認です。テスト用のデータが適切でも、強い資格情報が置かれていれば、評価を終えることはできません。
鍵を定期的に変えるという方針も、それだけで十分とは言えません。どこで使っているかが不明だと、変更の影響を恐れて古い鍵を残すことになります。所有者、接続先、許可操作、失効の手順を一緒に管理します。
試験が終わった後に、データがもう一度現れる
想定場面を進めます。開発チームが共有領域のファイルを削除し、問題を解消したと報告します。ところが別の担当者が、障害の再発に備えて保存したアーカイブを持っていたとしたらどうでしょうか。
この時点で、最初の消去の確認だけでは足りなかったことがわかります。元のファイル、複製、変換後のファイル、作業中の出力、バックアップが、同じ単位で管理されていなかったためです。
すべての領域で同じ消去方法や時点を採用できるとは限りません。それでも、すぐに利用を止める場所、次の周期で消去される場所、保持の必要性が残る場所を区別すれば、残存の条件を説明できます。バックアップから復元した際に、消去済みのデータを通常業務へ戻さない運用も確認しておきましょう。
AI Librarium（AIL）が提案するのは、試験の完了条件に、データの取扱いを含めることです。機能の試験に合格したことと、作業用データの利用が終了したことを、それぞれ確認します。その二つが揃えば、次の開発担当者へ説明しやすくなります。
AIの評価では、入力とログも試験データになる
AIの開発で、評価用の質問と期待する回答を準備する場合も同様です。実際の問い合わせを使えば、文章に顧客の氏名や契約内容が含まれているかもしれません。データベースを直接複製していないから対象外、とは考えない方がよいでしょう。
AIへ渡した文章、検索で取得した情報、ツールの実行記録、誤った回答の保存先を含めて、どこに何が残るかを追います。精度を比較するために同じ評価セットを使い続けるなら、そのデータを残す理由と参照できる人も管理する必要があります。
合成データを使う場合も、見た目だけを架空にすればすべての問題を評価できるわけではありません。利用者と会員の対応、権限の違い、許可されない操作など、検証したい条件を再現します。現実の設定との差は未確認事項として残します。
こうして準備した試験データは、AIを速く試すための土台にもなります。都度、実データの利用可否で止まるより、必要な条件を持つ承認済みのデータを使い、例外だけ追加判断する進め方が考えられます。利便性を保ちながら、持ち込む実情報を減らす設計です。
次の試験で、実データへ戻らない条件を整える
冒頭の開発チームが、加工した代替データで試験を進めることに合意したとします。それでも、後日別の不具合が出ると、以前の実データを戻したくなるかもしれません。代替データで再現できる範囲と、できない範囲が共有されていなければ、最初の改善が続かないからです。
そこで、試験データに対応する再現条件を記録します。例えば、同じ会員に複数の予約がある状態、解約した契約と継続中の契約が混在する状態、権限が途中で変わる状態などです。顧客の実名そのものより、関係や状態の組み合わせが重要な試験もあります。
必要な条件が増えたら、元データの全件コピーへ戻る前に、その条件を代替データへ追加できるかを判断します。実情報が必要な例外には、対象と期間を限定した別の手順を用意します。安全な標準の方法と、承認を要する例外が分かれていれば、現場も選びやすくなります。
データを更新する担当者も決めておきましょう。古い仕様の試験データだけが残れば、試験が通ることと現在の業務に合うことが離れてしまいます。仕様変更に合わせて、データの条件と期待する結果を見直します。過去の試験結果を参照するときは、どの条件と版に対する結果かを確認します。
こうした準備は、情報保護のためだけの追加作業ではありません。不具合が起きたとき、同じ条件を再現し、修正後に結果を比較するためにも必要になります。顧客の実情報をむやみに増やさず、試験に必要な構造を持つデータを維持することが、品質の確認にもつながります。
最後に、作業用のログを見直します。代替データへ切り替えても、外部システムへ接続した際の応答に実情報が含まれ、別の記録へ保存されていれば、取扱いは残っています。入力データの確認と、実行中に新たに生まれるデータの確認を分けると、試験全体で確認すべき範囲を把握しやすくなります。
開発レビューに、データの終了条件を持ち込む
次のレビューで、新しい規程を一本追加する前に、直近の試験一件を選んでみてください。どこから何を取り出し、何を再現し、誰が使い、試験後に何が残るかを担当者と追います。
実データを使った理由が、単に以前からそうしているためであれば、代替できる条件を検討します。使う理由が具体的なら、必要な対象と期間を絞ります。消去の記録がなければ、どの保存先を確認するかから決めます。問題を担当者個人の注意力だけに戻さないことが重要です。
本番と同じにする、という言葉も、すべての設備を同一にするという意味ではありません。個人情報と権限に応じた必要な管理を、環境の名称で免除しないという意味です。管理の方法は構成や目的に合わせて選びます。
開発を止めるか、情報保護を諦めるかという二択にする必要はありません。何を試すために何が必要かを明らかにすると、データを減らして試験を続ける選択肢が生まれます。その判断と終了の条件まで残すことが、次の開発にも役立ちます。
参考情報
公表情報の確認基準日：2026年10月22日。具体的な開発場面は架空の例です。法令上のデータ区分と必要な管理は、個別の条件に応じて確認してください。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
