「退会した会員のデータは、いつ消しているんですか」
納品からちょうど半年後、システムを使い始めた総務担当者からそう聞かれて、答えに詰まった経営者がいる。会員制のオンラインサービスを新規に立ち上げ、半年かけてベンダーと二人三脚で仕様を詰め、ようやくリリースまでこぎ着けたシステムだった。会員登録、決済、マイページ、問い合わせ管理と、必要な機能はひと通り揃っている。だが「退会」という導線は用意していたのに、退会後のデータをどう扱うかという仕様が、どこにも書かれていなかった。
調べてみると、退会ボタンを押した会員は画面上「退会済み」の表示になるだけで、氏名も住所も購入履歴も、データベースにはそのまま残り続けていた。個人情報保護法は、利用目的を達成した個人データについて、遅滞なく消去する努力義務を事業者に課している。会員から消去を求められれば、応じなければならない場面も出てくる。ところが、そもそも消去する機能自体がシステムに存在しない。結局、追加要件を整理し、ベンダーに見積もりを取り直し、テストを経てリリースするまでに、さらに二カ月と数十万円がかかった。
この経営者を責めるつもりはまったくない。むしろ、これは特別に不注意な人に起きた事故ではなく、システム開発という不慣れな領域に足を踏み入れた人なら誰にでも起こり得る、構造的な見落としだ。専門外の法律と専門外の技術、そのどちらとも向き合いながら仕様を決めなければならない発注担当者は、静かに、しかし確実に高い壁の前に立たされている。この記事は、その壁を越えようとしている人のための、実務の地図だ。
なぜシステム発注時に個人情報保護の要件が抜け落ちやすいのか
個人情報を扱うシステムの発注で要件が漏れる理由は、単純な不注意ではない。構造的な原因が、少なくとも三つある。
一つ目は、法律の話とシステムの話が、別の言語で語られているということだ。個人情報保護法のガイドラインには「利用目的の特定」「安全管理措置」「第三者提供の制限」といった言葉が並ぶ。一方、システムの要件定義書には「画面遷移」「テーブル設計」「API仕様」といった言葉が並ぶ。この二つの言語を橋渡しできる人間が、発注側にもベンダー側にも常にいるとは限らない。法務担当者は仕様書を読み込まず、エンジニアは条文を読み込まない。その隙間に、要件がすっぽり落ちる。
二つ目は、見た目に現れない機能ほど後回しにされるという、開発現場の力学だ。会員登録画面、検索機能、決済画面といった「使う人の目に見える機能」は、要件定義の早い段階で必ず話題に上る。しかし、退会後のデータ消去処理や、誰がいつどのデータを閲覧したかを記録するログ機能は、画面上には現れない。見えないものは、忘れられやすい。開発の優先順位を決める会議で、真っ先に削られるのも、こうした裏方の機能であることが多い。
三つ目は、発注担当者自身が「個人情報保護はベンダーが当然やってくれているはず」と思い込んでしまうことだ。実際には、ベンダーは発注者から明示的に要求された機能を作る。個人情報保護法への対応は、業種や取り扱うデータの性質によって必要な対応が変わるため、ベンダーが先回りしてすべてを盛り込んでくれるとは限らない。特に見積もりを安く抑えたいという事情がベンダー側にあれば、明示されていない要件は自然と削られる。発注者が「言わなかったこと」は、多くの場合「ないもの」として扱われる。これは、法律を知らない人が悪いのではなく、法律とシステムの間に立つ仕組みが、どの現場にも十分に用意されていないという話だ。
だからこそ、発注担当者に求められているのは、弁護士のような専門知識ではない。法律の言葉をシステムの言葉に翻訳し、仕様書に落とし込むという、地味だが決定的に重要な橋渡しの役割だ。この橋を架けられる担当者は、社内で驚くほど重宝される存在になる。
システム設計に組み込むべき基本的な要件
ここからは、個人情報を扱うシステムの設計に、一般的な実務として組み込まれることが多い要件を紹介する。個別の法解釈が必要な判断は弁護士に確認する必要があるが、システムの土台として押さえておくべき考え方は、非エンジニアでも十分に理解できる。
利用目的を明示し、その範囲内でしかデータを使わない仕組み
個人情報を取得するときは、何のために使うのかをあらかじめ本人に伝えなければならない。会員登録フォームの近くに「ご登録いただいた情報は、商品の発送および関連するご案内のために利用します」といった一文を置くのは、その最低限の実践だ。
システム側で意識すべきなのは、この利用目的が形だけの文言で終わらないようにすることだ。たとえば会員登録時に「商品発送のため」とだけ説明していたメールアドレスを、後から始めたメルマガ配信に無断で流用する、といったことが起きないよう、データの用途ごとに区分けして管理できる設計にしておくと安全だ。マーケティング用の同意欄を別に設ける、データベース上でも用途別にフラグを持たせる、といった工夫が該当する。
アクセス制御 — 見られる人と見られない人を明確に分ける
顧客の個人情報に、社内の誰もが自由にアクセスできる状態は、最も基本的で、最も見落とされやすいリスクだ。営業担当者が経理データを見られる必要はないし、アルバイトスタッフが全会員の住所を一覧できる必要もない。
設計上は、職務に応じてアクセスできる情報の範囲を制限する「権限管理」の仕組みを組み込む。管理者権限、一般スタッフ権限、閲覧のみ権限といった段階を用意し、それぞれの権限でどこまでの個人情報を見られるかを定義しておく。これは退職者のアカウントを即座に無効化できる仕組みとセットで考えると、より実効性が高まる。
データの暗号化 — 盗まれても読めない状態にしておく
暗号化とは、データを一定の規則で変換し、正しい鍵を持つ者だけが元の情報を読めるようにする技術だ。万が一データベースに不正アクセスされても、暗号化されていれば、盗まれた情報がそのまま悪用されるリスクを大きく下げられる。
特にパスワードやクレジットカード情報、マイナンバーのような機密性の高い情報は、保存時の暗号化に加えて、通信時にも暗号化された経路(https通信)を使うのが実務上の標準だ。発注時には「保存データの暗号化」「通信の暗号化」の両方が仕様に含まれているかを、具体的に確認する必要がある。
消去・訂正への対応 — 本人の求めに応じられる仕組み
個人情報保護法では、本人から自分のデータの開示、訂正、消去などを求められた場合に、事業者が対応する仕組みを整えておくことが求められている。冒頭の失敗例のように、退会したのにデータが残り続ける、住所変更を申し出たのにシステム上は反映されない、といった状態は、この対応義務を果たせていないことになる。
設計上は、退会処理と同時にデータを消去または匿名化するバッチ処理、本人からの訂正依頼を受け付けて反映する管理画面といった機能を、最初から要件に含めておく必要がある。
発注仕様書に盛り込むべき具体的なチェック項目
ここまでの内容を、実際に発注時に使えるチェックリストの形に落とし込む。仕様書やRFP(提案依頼書)を作成する段階で、以下の項目が盛り込まれているかを確認してほしい。
- 取得する個人情報の項目と利用目的が、一覧として明文化されているか
- 利用目的ごとにデータの用途を区分し、目的外利用を技術的に防ぐ設計になっているか
- 会員登録画面やフォームに、利用目的を明示する文言が組み込まれているか
- 職務や役割に応じたアクセス権限の段階が設計されているか
- 退職者・異動者のアカウントを速やかに無効化できる運用フローがあるか
- パスワードなど機密性の高い情報が保存時に暗号化される設計になっているか
- 通信経路がhttpsなど暗号化された方式で統一されているか
- 退会・解約時のデータ消去または匿名化の処理が、機能として明記されているか
- 本人からの開示・訂正・消去の求めに対応する管理画面や運用手順があるか
- 誰が・いつ・どの個人データにアクセスしたかを記録するログ機能が含まれているか
- 外部サービス(決済代行、メール配信、分析ツールなど)への個人情報の受け渡しが整理され、委託先の管理方法が明記されているか
- バックアップデータの保管期間と、消去依頼があった際にバックアップにも反映する運用が定められているか
この十二項目を、要件定義の初期段階でベンダーと一緒に確認するだけで、リリース後に慌てて追加開発するという事態は、かなりの確率で防げる。仕様書に一行書き加える手間と、リリース後に機能を作り直す手間とでは、コストも心理的な負担もまったく違う。
万が一の漏洩に備えた設計上の考慮点
どれだけ丁寧に設計しても、情報漏洩のリスクをゼロにすることはできない。だからこそ、漏洩が起きないための設計と同じくらい、漏洩が起きてしまったときに何が起きたのかを特定できる設計が重要になる。
実際に漏洩事故が起きた企業の対応を見ていると、最初に直面する壁は「何が起きたか分からない」という状態だ。どのデータが、いつ、誰によって、どこまで持ち出されたのかが分からなければ、監督機関への報告も、影響を受けた本人への通知も、正確に行うことができない。この初動の遅れが、被害をさらに大きくする。
設計段階で組み込んでおくべき考慮点は、次のようなものだ。
- 誰がどのデータにいつアクセスしたかを記録するアクセスログを、改ざんされにくい形で一定期間保存する
- 大量のデータが一度にダウンロードされるなど、通常と異なる操作を検知できる仕組みを検討する
- 個人情報を扱うシステムとそれ以外のシステムを、ネットワーク上である程度分離しておく
- 漏洩の疑いが発生した際に、影響範囲(対象者数、対象項目)を短時間で特定できるよう、データの持ち方をあらかじめ整理しておく
これらは高額な専門システムを導入しなければ実現できないものではない。多くは、標準的な開発の中で「ログを残す」「権限を分ける」という設計思想を最初から仕様に含めておくだけで対応できる。後から付け足そうとすると、システムの根幹に手を入れる大工事になりやすいというのが、この分野の厄介なところだ。
よくある失敗パターン
最後に、実際の現場でよく見られる失敗のパターンを共有したい。自社のシステムに当てはめて、思い当たる節がないか確認してみてほしい。
退会データが消えない
冒頭で紹介した事例そのものだ。退会処理は画面上のステータス変更にとどまり、実データは残り続ける。会員から消去を求められて初めて、消去する機能がないことに気づくというケースが多い。
アクセスログが存在せず、漏洩時に原因を特定できない
不正アクセスの疑いが発覚しても、誰がいつそのデータにアクセスしたかを記録する仕組み自体がなく、被害範囲を絞り込めない。結果として、被害の疑いがある対象を実際よりも広く見積もらざるを得ず、通知や対応のコストが不必要に膨らむ。
委託先への提供範囲が曖昧なまま外部サービスと連携している
決済代行やメール配信ツールなど、外部サービスに個人情報を渡す設計になっているにもかかわらず、どの項目をどこまで渡しているかが社内で整理されていない。委託先での管理体制を確認しないまま連携を始め、後になって委託先の管理状況を把握していなかったことが問題になるケースもある。
退職者のアカウントが放置されている
異動や退職があっても、システムのアカウントが無効化されないまま残り続ける。権限が生きたままのアカウントは、外部からの攻撃対象にもなり得る、静かに積み上がるリスクだ。
紙の同意書とシステムの設計が対応していない
入会時に紙の同意書で利用目的への同意を取っていても、その同意の範囲とシステムが実際にデータを使っている範囲が一致していない。契約書上の建前と、システムの実態がずれてしまっている状態だ。
これらの失敗に共通するのは、どれも「悪意」から生まれたものではないということだ。目の前の納期、目の前の予算、目の前に見えている機能を優先した結果、静かに積み残されてしまった宿題にすぎない。だからこそ、最初の仕様書の段階で光を当てておくことに、大きな意味がある。
まとめ
個人情報保護法への対応は、法律の専門知識がなければ手を出せない領域のように見えて、実際にはシステムの仕様書に落とし込める具体的なチェック項目の積み重ねだ。利用目的を明示すること、アクセスできる人を絞ること、データを暗号化すること、消去や訂正の求めに応じられる仕組みを持つこと、そして万が一のときに何が起きたかを追跡できるログを残しておくこと。どれも、非エンジニアの発注担当者が理解し、仕様書に書き込める言葉に翻訳できるものばかりだ。
冒頭の経営者は、追加開発を終えたあと、こう振り返っていた。「最初の打ち合わせで、退会したデータをどうするか一言聞いていれば、それだけで済んだ話だった」。専門外の法律用語に気後れする必要はない。必要なのは、法律を暗記することではなく、この記事で挙げたようなチェック項目を手元に置き、ベンダーとの打ち合わせで一つひとつ確認していく姿勢だ。
法律とシステムという、二つの専門領域の間に立たされる発注担当者の仕事は、地味で、評価されにくい。それでも、この橋渡しを丁寧にやり遂げた人が守っているのは、単なるデータではなく、そのシステムを信頼して情報を託してくれた顧客一人ひとりの安心そのものだ。壁を越えて働くというのは、まさにこういう仕事のことを言うのだと思う。