通信・プライバシー系

DM・退会機能・外部データ連携で確認すべきこと。ユーザーのデータが動くなら確認対象

「ユーザー同士がメッセージを送り合えるようにしたい」「サポートチームが問い合わせ内容を確認できるようにしたい」「退会したユーザーのデータを後から参照できるよう論理削除にしておきたい」。いずれも開発現場でよく出てくる要件です。しかしこれらはすべて、「通信の秘密」や「個人情報の取り扱い」に関わる法的なリスクを持っています。

この領域は、実装が完了してから問題が発覚すると、機能そのものの作り直しが必要になります。管理画面のアクセス制御も、退会時に何を消して何を残すかも、テーブルをどう分けるかという設計判断に食い込むからです。通信とプライバシーは、設計段階で決まります。

こんな言葉が仕様に出たら

DM / チャット / メッセージ / 非公開グループ
管理画面から閲覧 / 監視 / 通報対応
タグ / SDK / 計測 / アナリティクス（1行足すだけでも対象）
退会 / 論理削除 / deleted_at / データ保持
外部連携 / CRM / メール配信 / 海外サーバー

機能別の確認事項

実装しようとしている機能	主な確認事項
DM・チャット機能	サービスの主機能か、付随機能かで届出の要否が変わる（2023年6月施行の改正電気通信事業法）。メッセージが中心なら届出が必要な可能性が高く、問い合わせチャット等の付随機能なら不要とされるケースもある。付随機能として始まってもSNS的な比重が増えると途中から必要な状態に変わるため、再判定するフローを持つ
管理者によるDM閲覧機能	業務上の理由があっても、同意なき閲覧は通信の秘密（第4条）の侵害になりうる。規約末尾の包括同意だけでは不十分とする見解が有力。「原則閲覧不可・例外的に閲覧可能な手続きを設ける」構造をシステムで強制する。閲覧操作の監査ログを残す
アナリティクスタグ・SDKの埋め込み	2023年改正の外部送信規律により、「どこの誰に何を送っているか」の通知・公表義務がある。プライバシーポリシーやCookieポリシーに送信先のサービス名・提供情報・目的を記載する。タグマネージャー経由の追加は把握漏れが起きやすい
退会機能の実装	論理削除は「削除」にならない。2022年改正で「保有の必要がなくなった場合」も消去請求（第35条）の対象に。消すデータ（識別子）と残すデータ（法定保存義務のある取引記録）を別テーブル・別ストレージに分離し、退会時に識別子を `NULL` でマスキングする
外部CRM・メール配信サービスへのデータ連携	第三者提供（第27条）に該当しうる。「同意取得」か「委託」かを連携ごとに整理する（委託なら管理・監督義務が生じる）。デバッグログやテストで本番データを外部に渡す経路が見落としやすい。海外サーバーなら移転先の国名等の公表が必要

このカテゴリの勘所

論理削除は「削除」ではありません。 deleted_at にフラグを立てるだけの設計は、参照整合性の維持や誤削除からの復元という点で実務上は合理的です。しかし個人情報保護法の観点では、データはまだそこに残っています。退会したユーザーから「私のデータが残っているのでは？」と指摘されたとき、法的な根拠を持って説明できるかが問われます。

求められているのは物理削除ではなく、「特定の個人を識別できなくなること」です。 ここを取り違えると「全部消すしかない」という極論になりますが、そうではありません。識別子カラム（メールアドレス・氏名・住所など）をマスキングし、法的な保存義務があるデータ（電子帳簿保存法による取引記録の7年保存など）は別テーブルに分けておく。これが現実的な落としどころです。個人を識別できない形に加工すれば、それはもはや個人情報ではないため、分析目的での保持もできます。

「タグを1行入れるだけ」に法的な意味があります。 フロントエンドエンジニアが <script> タグを追加する行為は、法的に見れば「ユーザーの行動データを外部に送信する仕組みを設置する」行為です。実装の前に「これを入れると何がどこに送られるか」を把握し、プライバシーポリシーへの反映が済んでいるかを確認するフローを持ってください。同じ理由で、通信の秘密に関する同意も「規約に書いてあるから大丈夫」では済みません。

あわせて確認

退会時にポイント残高を扱うなら → 退会時のポイント残高返金（現金払い戻しは原則禁止）
企画段階の確認漏れは → フェーズ1：機能企画・要件定義時
消すデータ・残すデータの設計は → フェーズ2：設計時
タグ・SDK追加のたびに → フェーズ3：実装時