「退会したのに、なぜ情報が残っている？」 開発者が見落としがちなデータ管理の盲点：セキュリティ担当者の耳が痛いはなし（1/2 ページ）

退会者のデータや削除済みの画像が、なぜ漏えいするのでしょうか。背景には、再登録への対応や分析などを理由に、データを残し続けるシステム設計があります。業務部門から「データを残してほしい」と頼まれたとき、開発者は何を考慮すべきなのか。保存する項目の絞り込みから、データの分離、保存期限の設定まで、情報漏えいのリスクを抑えるための設計のポイントを解説します。

[伊藤秀明，＠IT]

　2026年9〜10月にかけて、退会済みの利用者や削除済みのデータまで情報漏えいの対象に含まれたと公表する事例が相次ぎました。

　例えば、パーク２４は2026年9月28日、カーシェアサービス「タイムズカー」の約660万件のアカウント情報が取得されたと明らかにし、退会済みの利用者や入会手続きを終えていない人も対象に含まれると説明しました。画像共有サービス「Gyazo」を運営するHelpfeelも9月25日、主に2023年2月以前に削除された画像のメタデータ約1.74億件が流出したと公表しています。

　ここで気になるのは、なぜ退会したはずのアカウントや削除したはずのデータが残り続けているのかという点です。

　開発者にとって、退会したアカウントのデータを保存期間に応じて削除することはシステム設計の基本でしょう。しかし実際の開発現場では、業務部門から「再入会に備えてデータを残してほしい」「退会理由を分析したい」と頼まれることもあります。このような事情から、開発者の判断だけで削除するわけにはいかず、結果として退会フラグを立てただけでデータを残すケースもあるでしょう。

　そういう意味でデータを残すこと自体は問題ではありません。目的や保存期間を決めず、必要以上の情報を複製先も含めて管理し続けることがリスクになるのです。では、退会者のデータを残すと決まったとき、開発者は何を設計に組み込めばよいのでしょうか。漏えいしたときの影響を小さくするために、押さえておきたいポイントを解説します。

筆者紹介：伊藤秀明（AIセキュリティ株式会社　コンサルティング＆ソリューション事業統括本部 シニアマネージャー）

セキュリティ組織の構築、プロジェクト推進、SOC業務など、戦略的視点から技術的な実行まで幅広く手掛けるITシステムコンサルタント。通信、インターネットサービス、医療、メディアなど多様な業界での経験を生かし、業界特有の課題にも対応。クライアントのニーズに応じた柔軟なソリューションを提供し、セキュリティと業務効率の両立を実現するためのプロアクティブなアプローチを重視している。また、講演や執筆活動にも積極的に取り組み、専門知識や実務経験を生かして幅広い層にセキュリティやITシステムに関する知見を共有している。

「退会者のデータを残したい」　業務部門の要求に応えるのは簡単だけど……

　退会者のデータを残したい理由はさまざまです。再入会時にポイントや購入履歴を引き継ぎたい、退会理由や利用期間を分析してサービスの改善に生かしたい、規約違反で退会させた人の再登録を防ぎたい、退会後の問い合わせや返金に対応したいといった要望があります。いずれも事業上の合理性があります。

　法令によって保存が必要な記録もあります。例えば、法人の帳簿書類は原則7年間、一定の場合には10年間の保存が必要です。金融機関などの特定事業者が犯罪収益移転防止法に基づいて作成する確認記録にも、所定の保存期間が定められています。

　ただし保存義務があることと、会員情報一式をそのまま残さなければならないことは別です。何を、どの目的で、いつまで保存する必要があるのかを切り分ける必要があります。

　また退会者のデータであっても、個人を識別できる情報が漏えいすれば、本人への影響や企業の対応が問題になります。個人情報保護法で定める報告対象の事態に該当する場合は、個人情報保護委員会への報告や本人への通知が必要になることもあります。退会済みであることだけを理由に、こうした対応の対象から当然に除外されるわけではありません。

　「退会したのに、なぜ私の情報が残っているのか」。企業は利用者からのこうした疑問にも答えられるようにしておかなければなりません。

DBから消しても、データは残り続ける

　退会者のデータを残すと決まった場合、実装として手軽なのは、会員テーブルのレコードを残したまま退会フラグを立てる方法です。追加の開発を抑えられる一方、退会理由の分析にしか使わないデータにも氏名や住所、メールアドレスなどが残ります。現役会員と同じテーブルにあれば、同じアプリケーションや担当者から参照できる状態が続く可能性もあります。

　さらに、業務部門からの依頼が「残しておいてほしい」というだけで、具体的な用途や保存期間まで決まっていないこともあります。目的が曖昧なままでは、必要な項目も削除時期も決められず、結果として全ての項目を期限なしで保有することになりかねません。

　データが残る場所は、会員テーブルだけではありません。メール配信や顧客管理のSaaS、分析用のデータ基盤、バックアップなどにも複製されている場合があります。本番DBで削除処理を実行しても、複製先まで自動的に削除されるとは限りません。バックアップから復元した際に、削除済みのデータが再び利用可能になる可能性も考慮する必要があります。

　個人情報保護法第22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。利用目的があるデータを保有すること自体が直ちに問題になるわけではありませんが、目的に必要のない項目まで持ち続ければ、漏えい時の影響を広げる要因になります。

　削除の操作だけを見るのではなく、データがどこに保存され、どこに複製され、誰が参照できるのかまで把握することが重要になるでしょう。