個人情報保護法 改正対応 — 業務システムで実装すべき削除請求・利用停止フロー

1. 本人確認の前段フロー

削除請求・開示請求の前に、本人確認を業務システム上で安全に行う必要があります。

メール認証だけでは不十分なケースが増えており、登録時の本人情報との照合 (氏名・生年月日・登録メール・電話番号・直近の取引履歴) を業務システム上で確認できる仕組みを持っておくと、本人確認のやり直しが減ります。第三者なりすましのリスクが高い場合は、登録メール宛のワンタイム・パスコードと組み合わせます。

2. 削除対象の範囲を業務システム上で可視化

本人 1 人の個人情報は、業務システムだけでなく、メール配信ツール・問い合わせ管理・分析ツール・バックアップ・外部委託先など複数の場所に散らばっています。

業務システム上で本人 ID から関連レコード・関連 SaaS・関連委託先を一覧表示できる管理画面を持っておくと、削除請求を受けたときに 「どこに何が残っているか」 を 1 画面で把握できます。これを作っておかないと、削除請求が来るたびに手作業の調査が走ります。

3. 削除実行の二段階承認

削除請求の実行は不可逆な操作なので、業務システム上で 1 人がボタンを押せば即削除、という設計は危険です。

申請担当者と承認者を分け、承認時に削除対象範囲のプレビューを表示し、本人確認の完了状態と削除対象の項目を画面で確認してから実行する二段階承認フローを組み込みます。承認ログは長期保管します。

4. 削除と利用停止の区別

本人請求には 「削除」 と 「利用停止」 の 2 種類があり、業務システム側でも区別する必要があります。

利用停止 (オプトアウト) は、レコードを残したまま marketing_opt_out=true 等のフラグで運用上の利用範囲を制限します。削除はレコード自体を消去するか、匿名化します。フラグ管理が業務システム横断で機能する設計にしないと、メール配信ツール側で利用が継続される事故が起きやすいです。

5. 外部委託先への通知伝播

メール配信・SMS・CRM・分析ツール・問い合わせ管理など、本人情報を委託先に渡している場合、削除請求・利用停止請求が委託先側にも伝播する必要があります。

業務システム上で委託先一覧を持ち、削除請求実行時に委託先 API への削除要求を自動発火する仕組みを入れます。API を持たない委託先には、月次のバッチで本人 ID リストを送付する運用にします。

6. 記録の長期保管

個人情報保護法の対応として、本人請求の受付・処理・完了の記録を、業務システム上で長期保管します。

誰が・いつ・何を・どの範囲で実行したかを操作者・日時・対象・実行内容で残し、書き込み専用の保管先 (S3 + Object Lock 等) に転送して改ざんを防ぎます。委員会等の事業者検査や、本人からの再請求への対応にも必要です。