--- title: 通信・プライバシー系 description: DM・退会機能・外部データ連携で確認すべきこと。ユーザーのデータが動くなら確認対象 sidebar: label: 概要 --- 「ユーザー同士がメッセージを送り合えるようにしたい」「サポートチームが問い合わせ内容を確認できるようにしたい」「退会したユーザーのデータを後から参照できるよう論理削除にしておきたい」。いずれも開発現場でよく出てくる要件です。しかしこれらはすべて、**「通信の秘密」や「個人情報の取り扱い」に関わる法的なリスクを持っています。** この領域は、実装が完了してから問題が発覚すると、機能そのものの作り直しが必要になります。管理画面のアクセス制御も、退会時に何を消して何を残すかも、テーブルをどう分けるかという設計判断に食い込むからです。**通信とプライバシーは、設計段階で決まります。** ## こんな言葉が仕様に出たら - DM / チャット / メッセージ / 非公開グループ - 管理画面から閲覧 / 監視 / 通報対応 - タグ / SDK / 計測 / アナリティクス（**1行足すだけでも対象**） - 退会 / 論理削除 / `deleted_at` / データ保持 - 外部連携 / CRM / メール配信 / 海外サーバー - 海外展開 / 越境EC / グローバル / EUユーザー / 多言語・多通貨対応（**GDPRの域外適用を疑う**） ## 機能別の確認事項 | 実装しようとしている機能 | 主な確認事項 | |---|---| | [DM・チャット機能](/features/privacy/dm-chat) | **サービスの主機能か、付随機能か**で届出の要否が変わる（2023年6月施行の改正電気通信事業法）。メッセージが中心なら届出が必要な可能性が高く、問い合わせチャット等の付随機能なら不要とされるケースもある。**付随機能として始まってもSNS的な比重が増えると途中から必要な状態に変わる**ため、再判定するフローを持つ | | [管理者によるDM閲覧機能](/features/privacy/admin-dm-viewing) | 業務上の理由があっても、**同意なき閲覧は通信の秘密（第4条）の侵害になりうる**。規約末尾の包括同意だけでは不十分とする見解が有力。**「原則閲覧不可・例外的に閲覧可能な手続きを設ける」構造をシステムで強制する**。閲覧操作の監査ログを残す | | [アナリティクスタグ・SDKの埋め込み](/features/privacy/analytics-sdk) | 2023年改正の**外部送信規律**により、**「どこの誰に何を送っているか」の通知・公表義務**がある。プライバシーポリシーやCookieポリシーに送信先のサービス名・提供情報・目的を記載する。**タグマネージャー経由の追加は把握漏れが起きやすい** | | [退会機能の実装](/features/privacy/account-deletion) | **論理削除は「削除」にならない**。2022年改正で「保有の必要がなくなった場合」も消去請求（第35条）の対象に。**消すデータ（識別子）と残すデータ（法定保存義務のある取引記録）を別テーブル・別ストレージに分離**し、退会時に識別子を `NULL` でマスキングする | | [外部CRM・メール配信サービスへのデータ連携](/features/privacy/external-data-sync) | **第三者提供（第27条）に該当しうる**。**「同意取得」か「委託」かを連携ごとに整理**する（委託なら管理・監督義務が生じる）。**デバッグログやテストで本番データを外部に渡す経路が見落としやすい**。海外サーバーなら移転先の国名等の公表が必要 | | [海外（特にEU）ユーザーへのサービス提供とGDPR](/features/privacy/gdpr) | EU居住者を**能動的にターゲットにしている**（EU言語・ユーロ決済・EU配送等）場合、**GDPRが域外適用されうる**（第3条）。単にEUからアクセス可能なだけでは対象外。制裁金は日本法と桁が違い、上限は**全世界売上の4%または2,000万ユーロ**にもなりうる。まず「自分が対象か」を切り分け、対象なら現地専門家・**EU代理人の選任**（第27条）へ | ## このカテゴリの勘所 **論理削除は「削除」ではありません。** `deleted_at` にフラグを立てるだけの設計は、参照整合性の維持や誤削除からの復元という点で実務上は合理的です。しかし個人情報保護法の観点では、データはまだそこに残っています。退会したユーザーから「私のデータが残っているのでは？」と指摘されたとき、法的な根拠を持って説明できるかが問われます。 **求められているのは物理削除ではなく、「特定の個人を識別できなくなること」です。** ここを取り違えると「全部消すしかない」という極論になりますが、そうではありません。識別子カラム（メールアドレス・氏名・住所など）をマスキングし、法的な保存義務があるデータ（電子帳簿保存法による取引記録の7年保存など）は別テーブルに分けておく。これが現実的な落としどころです。個人を識別できない形に加工すれば、それはもはや個人情報ではないため、分析目的での保持もできます。 **「タグを1行入れるだけ」に法的な意味があります。** フロントエンドエンジニアが `