EUのePrivacy Regulation案は成立していません。それでもCookie、端末情報、メール施策、GDPR、加盟国法への対応は残るため、企業法務・プライバシー実務として確認すべき論点を整理します。
EUのePrivacy Regulation案は成立していません。
規則案の撤回後も、Cookie、端末情報、通信データ、メール施策、GDPR対応は残ります。
eプライバシー規則EUへの対応では、まず「2017年提案のePrivacy Regulation案は成立していない」という前提を確認します。この理解は、近い将来の新規則だけを待つのではなく、現行のePrivacy Directive、加盟国実装法、GDPR、判例、監督機関実務で日々のWeb、アプリ、広告、メールを管理するために重要です。ここでは、規則案の状況、現行法の位置づけ、企業が最初に読み取るべき実務課題を整理します。
2026年6月7日現在、ePrivacy Regulation案は施行待ちの規則ではありません。一方で、Cookie、端末内情報、通信メタデータ、位置データ、電子メールマーケティング、同意管理、ベンダー管理は、現行法制に基づく確認が求められます。
次の比較一覧は、対応の出発点になる5つの結論を表します。規則案の有無だけを見るとリスクを見落としやすいため、各項目の左側で前提を確認し、右側で企業が読み取るべき実務行動を確認します。
ePrivacy Regulation案が近く直接適用されるという前提で、全社プロジェクトを設計しないことが出発点です。
ePrivacy Directive、加盟国実装法、GDPRを組み合わせて、Cookie、端末情報、電子メール、通信データを確認します。
端末への保存や端末内情報へのアクセスは、個人データ該当性とは別にArticle 5(3)で問題になります。
EU向け商品、SaaS、アプリ、広告、行動追跡、EU子会社や代理店との連携があれば検討対象になります。
技術棚卸し、同意管理、透明性、ベンダー管理、証跡化を、法務、マーケティング、開発、監査で管理します。
2017年提案から2025年撤回までの流れを、現行実務へ読み替えます。
次の時系列は、ePrivacy Regulation案がどのような経緯で撤回に至ったかを表します。年月の順番を追うことで、企業が「成立待ち」から「現行法の精査」へ視点を切り替える理由を読み取れます。
電子通信における私生活の尊重と個人データ保護を扱い、ePrivacy Directiveを置き換え、GDPRを補完する構想でした。
通信の秘密、安全保障、Cookie同意の負担、広告業界への影響、児童保護政策との関係など、多数の争点が残りました。
合意見込みの乏しさと、近年の立法に照らした提案の古さが撤回理由として示されました。
欧州議会の立法資料でも、当該ファイルは撤回済みとして整理されています。
次の一覧は、「eプライバシー規則EUへの対応」という表現が実務で指す3つの意味を整理します。どの意味で議論しているかを分けることが、社内説明やプロジェクト設計の混乱を避けるために重要です。
| 意味 | 現在の位置づけ | 企業が読み取ること |
|---|---|---|
| 規則案への将来準備 | 撤回済みであり、施行待ちではありません。 | 新規則だけを待つ計画は見直します。 |
| 現行法に基づく整備 | Cookie、端末情報、通信データ、メール施策は引き続き規制対象です。 | 実務対応の中心に据えます。 |
| 将来変化への備え | データ、AI、サイバー、広告透明性の規制再編は続きます。 | 技術棚卸し、契約管理、監査証跡を継続的に更新します。 |
Directive、Regulation、GDPR、端末内情報、同意の違いを実装判断に接続します。
次の用語一覧は、法形式と技術対象の違いを表します。用語を混同すると、CookieやSDKの同意要否、取得後の個人データ処理、加盟国法確認の順番を誤りやすいため、各行で対象と実務上の読み方を確認します。
| 用語 | 概要 | 実務上の読み方 |
|---|---|---|
| ePrivacy Directive | 電子通信分野の個人データ処理とプライバシー保護を扱う指令です。 | 加盟国が国内法へ実装するため、EU法本文と主要対象国の国内法を確認します。 |
| ePrivacy Regulation | EU加盟国で直接適用される規則として提案されました。 | 成立していないため、現時点の直接適用ルールとして扱いません。 |
| GDPR | 個人データ処理の基本原則、法的根拠、権利対応、越境移転、制裁などを定めます。 | 端末アクセス後の保存、分析、広告利用、共有、移転を確認します。 |
| 端末装置・端末内情報 | Cookie、localStorage、SDK、広告ID、ピクセル、フィンガープリンティングなどが含まれ得ます。 | Cookieという名称だけでなく、端末への保存・アクセスの有無を棚卸しします。 |
| 同意 | 自由、特定、情報提供、曖昧でない意思表示、明確な積極的行為が求められます。 | 事前チェック、閲覧継続、スクロールだけに依拠しない設計にします。 |
次の重要ポイントは、Cookie以外の技術まで対象が広がる理由を表します。端末から得る情報の種類が多いほど、単なるプライバシーポリシー修正では足りないことを読み取れます。
端末への保存や、端末内情報へのアクセスが問題になります。Planet49判決も、保存・アクセス対象の情報が個人データか否かでArticle 5(3)の解釈は変わらないと整理しています。
対象技術は、HTTP Cookie、localStorage、sessionStorage、IndexedDB、モバイルアプリSDK、IDFA、AAID、ピクセルタグ、Webビーコン、タグマネージャー経由の第三者タグ、端末・ブラウザ属性の組合せによる識別、IoT機器、スマートTV、車載端末、ウェアラブル端末の識別子まで広がり得ます。EDPBの技術的適用範囲に関するガイドラインも、Cookieだけを見れば足りるという発想から離れる必要性を示しています。
端末・通信レイヤーと個人データ処理レイヤーを分けると、確認順序が明確になります。
次の判断の流れは、WebサイトやアプリでタグやSDKを使うときに、どの法令を先に見るかを表します。上から順番に確認することで、GDPRの正当な利益だけで端末アクセスを片付けてしまう誤りを避けられます。
Cookie、SDK、ピクセル、広告ID、フィンガープリンティングを確認します。
必要性が限定される場合だけ例外を検討します。
事前同意、情報提供、拒否、撤回、同意ログを整えます。
必要技術でも、目的、期間、提供者を説明します。
GDPRの法的根拠、透明性、権利対応、DPIA、委託、越境移転を確認します。
次の比較表は、現行法で見る主な規律領域を表します。条文ごとの対象と企業側の関心を並べることで、Cookie以外にも通信の秘密、トラフィックデータ、位置データ、メール施策が残ることを読み取れます。
| 領域 | 主な条文 | 実務上の関心 |
|---|---|---|
| 通信の秘密 | Article 5(1) | 通信内容、トラフィックデータの傍受、監視、保存、録音、ログ取得を確認します。 |
| Cookie・端末内情報 | Article 5(3) | Cookie、localStorage、SDK、ピクセル、フィンガープリンティングを確認します。 |
| トラフィックデータ | Article 6 | 通信経路、時刻、通信量、課金、マーケティング、付加価値サービスを確認します。 |
| 位置データ | Article 9 | モバイルアプリ、物流、配車、店舗来訪分析、IoT、ウェアラブルを確認します。 |
| 加入者名簿 | Article 12 | 公開ディレクトリ、検索、掲載、訂正、撤回を確認します。 |
| ダイレクトマーケティング | Article 13 | メール、SMS、電話、FAX、オプトイン、ソフトオプトイン、配信停止を確認します。 |
| 執行・制裁 | Article 15a | 加盟国ごとの制裁、差止、調査権限、国境を越える協力を確認します。 |
日本企業では、EU拠点の有無だけで判断するとリスクを見落とします。EU向けEC、EU言語・通貨・配送、EU向けSaaS、アプリ、オンライン講座、デジタルコンテンツ、EU域内ユーザーの広告・解析トラッキング、EU子会社や販売代理店からの見込み顧客リスト、EU向け採用・投資家・B2Bリード獲得サイト、メールマガジンやウェビナー案内があれば、適用可能性を検討します。
同意が必要な技術と例外になり得る技術を分け、CMPとポリシーを実装へ落とし込みます。
次の分類表は、Cookieや類似技術を目的別に分けたものです。分類により同意要否や事前ブロックの設計が変わるため、左から技術の種類、中央で代表例、右で同意の考え方を読み取ります。
| 分類 | 例 | 同意の考え方 |
|---|---|---|
| 厳格に必要なCookie | ログイン維持、ショッピングカート、セキュリティ、負荷分散、ユーザーが求めた設定保存 | Article 5(3)の例外に該当し得ます。ただし透明性は必要です。 |
| 機能Cookie | 言語設定、UIカスタマイズ、チャット機能 | 不可欠か利便性目的かを個別に判断します。多くは同意対象になり得ます。 |
| 解析Cookie | Google Analytics、Matomo、Adobe Analyticsなど | 加盟国ガイダンスに差はありますが、EU横断運用では事前同意を前提に設計することが多いです。 |
| 広告Cookie | リターゲティング、行動ターゲティング、広告効果測定 | 原則として事前同意が必要です。 |
| SNS・外部プラグイン | SNSボタン、埋め込み動画、第三者ピクセル | 第三者アクセス、共同管理、越境移転を含めて確認します。 |
| フィンガープリンティング | 端末やブラウザ属性の組合せによる識別 | Cookieを使わなくてもArticle 5(3)の問題になり得るため棚卸し対象です。 |
次の要件一覧は、同意バナーとCookieポリシーを設計するときの実装上の確認点を表します。各行の要件と運用ポイントを対応させることで、形式的な表示ではなく、同意前の発火制御と証跡化まで確認できます。
| 要件 | 実装上のポイント |
|---|---|
| 事前同意 | 同意前に広告・解析タグを発火させず、タグマネージャーで事前ブロックします。 |
| 積極的行為 | 事前チェック済みボックス、単なる閲覧継続、スクロールだけに依拠しません。 |
| 粒度 | 広告、解析、機能、SNSなど目的別に同意を取得します。 |
| 同じ容易さ | 同意と拒否を同じ階層、同程度の容易さで提示します。 |
| 撤回容易性 | フッターなどから常時設定変更と撤回ができるようにします。 |
| 情報提供 | 目的、期間、第三者アクセス、提供先、ベンダー、保存期間を明示します。 |
| 証跡 | 同意日時、バージョン、同意範囲、地域、表示文言、撤回履歴を保存します。 |
| 誘導的設計の回避 | 拒否を隠す、色や文言で誘導する、過度に複雑にする設計を避けます。 |
次の一覧は、CMPを導入した後に確認する運用項目を表します。ツールの有無ではなく、実際の発火、カテゴリ設定、地域別挙動、同意ログ、ベンダー一覧、アプリSDK、サーバー側処理、拒否・撤回の容易さを読み取ることが重要です。
同意前に第三者タグが発火していないか、ブラウザ開発者ツールやスキャンツールで確認します。
技術確認広告タグを必要Cookieへ誤分類していないか確認します。
注意EU、英国、スイス、米国州法、日本など、地域ごとの表示と発火条件を文書化します。
地域同意ログの粒度と、CMP上のベンダー名と実際に発火する提供者の一致を確認します。
証跡iOS、Android、広告ID、アトリビューションSDK、サーバーサイドタグも棚卸し対象に含めます。
SDKCookieポリシーには、名称、提供者、ドメイン、ファーストパーティかサードパーティか、利用目的、カテゴリ、保存期間、有効期限、第三者アクセス、個人データとしての処理目的と法的根拠、国外移転、撤回方法、ブラウザやアプリ設定での制御方法、改定日、同意バナー文言のバージョンを整理します。
Article 13、端末アクセス後のGDPR、EU代理人、制裁を同じ管理表に入れます。
次の比較表は、電子メールマーケティングで確認する対象を表します。取得経路と国別要件を分けて見ることで、B2Bであっても自由に送れるとは限らない点を読み取れます。
| 確認対象 | 実務で見ること |
|---|---|
| Article 13の原則 | ダイレクトマーケティング目的の自動発信、FAX、電子メールは、原則として事前同意を確認します。 |
| ソフトオプトイン | 商品・サービス販売の文脈で取得した顧客連絡先について、自社の類似商品・サービス案内に使える余地を国別に確認します。 |
| 拒否機会 | 取得時と各メッセージで、無料かつ容易に拒否できる機会を明確に提供します。 |
| B2Bメール | 法人宛でも、宛先が個人である場合や加盟国法が厳しい場合は注意します。 |
| リスト管理 | 同意日時、取得経路、同意文言、ブランド、目的、配信停止、代理店提供リストの根拠を記録します。 |
次の4段階は、端末アクセス後にGDPRの検討へ進む順番を表します。段階ごとに見る法令を分けることで、端末アクセスの許容性と取得後の個人データ処理を混同しないようにします。
ePrivacy Directive Article 5(3)と加盟国法で、保存・アクセスの可否を確認します。
Cookie ID、閲覧履歴、広告イベント、位置情報、ログインIDなどが個人データに当たるか確認します。
目的、法的根拠、透明性、権利対応、保存期間、DPIA、セキュリティを確認します。
共同管理、処理者契約、第三国移転、補完的措置を確認します。
次の制裁関連の比較表は、GDPRとePrivacy領域の執行リスクを表します。数値上限と加盟国差を並べることで、EU横断の運用では国別リスク評価も必要になることを読み取れます。
| 領域 | 上限・特徴 | 実務上の対応 |
|---|---|---|
| GDPR | 違反内容に応じて、1,000万ユーロまたは全世界年間売上高2％、2,000万ユーロまたは全世界年間売上高4％のいずれか高い額が上限になります。 | 処理記録、同意証跡、DPIA、越境移転、委託契約を説明できる形にします。 |
| ePrivacy Directive領域 | 加盟国が有効、比例的、抑止的な制裁や調査権限、差止権限を定めます。 | 対象国ごとのCookie、メール、通信データ規制と監督機関実務を確認します。 |
| EU代理人 | EU拠点がなくても、GDPR Article 3(2)に該当する処理ではArticle 27の代理人指定が問題になります。 | EU向けEC、SaaS、アプリ、広告トラッキング、リード獲得で見落とさないようにします。 |
前提確認から棚卸し、分類、同意管理、ベンダー管理、監査まで段階的に進めます。
次の時系列は、日本企業がeプライバシー規則EU対応を現行法ベースで進める順番を表します。各段階の目的と成果物を追うことで、単なるCookieバナー導入ではなく、運用統制として整備する流れを読み取れます。
規則案は撤回済みでも、Cookie、メール、通信データ、端末情報の規制は残ることを、経営、法務、マーケティング、IT、セキュリティで共有します。
EU向けWebサイト、アプリ、ランディングページ、EC、SaaS、サポートサイト、採用サイト、投資家向けサイト、Cookie、タグ、SDK、CRM、MA、広告、解析、ベンダー、証跡を一覧化します。
端末アクセスの有無、厳格必要性、同意要否、個人データ処理、法的根拠、第三者提供、共同管理、委託、国外移転、プロファイリングを分類します。
必要Cookie以外の事前ブロック、同意・拒否・詳細設定、目的別・ベンダー別選択、撤回、同意ログ、Cookieポリシーとの一致、アプリ権限との整合を実装します。
CMP、解析、MA、CRM、CDP、DMP、クラウド、アプリSDK、決済、サポートツールについて、処理者、共同管理者、独立管理者、移転先、契約条項を確認します。
新規タグ承認、タグマネージャー権限、定期Cookieスキャン、CMPレビュー、マーケティング研修、開発者向けSDK基準、内部監査、M&Aレビューへ組み込みます。
法務だけでなく、マーケティング、IT、監査、経営、取引先管理を横断します。
次の役割一覧は、部門別に見る確認ポイントを表します。どの部門が何を担うかを分けることで、法務文書と実装・運用のずれを減らすことができます。
ePrivacy Directive、加盟国法、GDPRの適用関係、Cookieポリシー、プライバシーポリシー、CMP契約、広告代理店契約、データ処理契約を確認します。
法令データマッピング、処理記録、DPIA、LIA、同意ログ、透明性、権利行使、EU代理人やDPOとの連携を整えます。
記録同意前発火の防止、拒否ユーザーの除外、リード同意範囲、配信停止反映、代理店のタグ追加管理を担います。
広告Cookie、localStorage、SDK、タグの実発火、CMP連携、ログ保存、アクセス権限、暗号化、削除機能を整えます。
実装Cookieポリシーと実発火の一致、同意前発火、同意ログ、新規タグ承認、苦情や権利行使の記録をレビューします。
監査次の契約確認表は、ePrivacy・GDPR関連契約で見る条項を表します。条項ごとの確認ポイントを読むことで、同意撤回時の処理停止や無断タグ追加禁止など、一般的な秘密保持条項だけでは不足する部分が分かります。
| 条項 | 確認ポイント |
|---|---|
| データ処理条項 | 処理目的、データ種類、データ主体、期間、指示、削除・返却を確認します。 |
| 再委託 | 事前承認、再委託先一覧、変更通知、同等義務を確認します。 |
| 同意管理 | 取得主体、文言、同意ログ、撤回時の処理停止を確認します。 |
| タグ管理 | 無断タグ追加禁止、発火条件、監査権、変更管理を確認します。 |
| 共同管理 | 役割分担、透明性、権利行使窓口、責任分担を確認します。 |
| 国外移転 | 移転先、移転根拠、補完的措置、移転影響評価を確認します。 |
| セキュリティ・侵害通知 | 暗号化、アクセス管理、ログ、脆弱性管理、侵害通知を確認します。 |
| 監査・終了時 | 情報提供、証跡提出、是正措置、データ削除、バックアップ、タグ削除を確認します。 |
M&Aでは、EU向けWebサイト・アプリ、Cookie、SDK、ピクセル、タグ、CMP設定、同意ログ、ポリシー版管理、広告・解析・CRM・MA・CDP契約、共同管理者・処理者整理、EU代理人、データ主体権利対応、監督機関対応、侵害通知、メールリスト取得根拠、買収後に利用できないデータの有無を確認します。内部監査では、Cookieスキャン結果、CMP設定画面、同意ログサンプル、タグマネージャー変更履歴、新規タグ承認記録、DPA、ポリシー改定履歴、DPIA、LIA、研修記録、配信停止反映ログ、インシデント対応記録を証跡として確認します。
よくある誤解を、一般的な制度説明として整理します。
一般的には、2026年6月7日現在、2017年提案のePrivacy Regulation案は撤回済みと整理されています。現行実務では、ePrivacy Directive、加盟国実装法、GDPR、CJEU判例、EDPBや各国監督機関ガイダンスを見る必要があります。
一般的には、不要とはいえません。Cookieや端末内情報への保存・アクセスは、ePrivacy Directive Article 5(3)および加盟国実装法が引き続き問題になります。広告、解析、リターゲティング、SNS連携では、事前同意、情報提供、同意ログが重要です。
一般的には、完了したとは整理しにくいです。GDPRは個人データ処理の一般的枠組みですが、ePrivacy Directiveは通信の秘密や端末内情報アクセスを特別に扱います。端末アクセスは、個人データ該当性にかかわらず問題になり得ます。
一般的には、GDPR上の正当な利益だけで端末アクセスの同意を不要にできるとは限りません。加盟国ガイダンスによって限定的な解析の例外が検討される場合もありますが、EU横断運用では保守的に事前同意を前提に設計することが多いです。
一般的には、安全とはいえません。Article 5(3)はCookieという名称ではなく、端末装置への情報保存や端末内情報へのアクセスを問題にします。SDK、localStorage、ピクセル、広告IDなども棚卸し対象です。
一般的には、国によって判断が変わります。法人宛メールでも、宛先が個人である場合や加盟国実装法が厳しい場合があります。取得経路、同意文言、配信停止導線、国別規制を確認する必要があります。
一般的には、EU向けWebサイト、アプリ、広告、メール施策の棚卸しから始めます。Cookie、広告タグ、解析タグ、アプリSDK、CRM、MA、配信リスト、同意ログ、ポリシー、ベンダー契約を確認します。
一般的には、監督機関、裁判、苦情対応、内部監査で説明できる粒度が求められます。同意日時、対象、目的、表示文言、ポリシー版、ユーザー識別子、国・地域、撤回履歴を設計します。ただし、ログ自体も個人データになり得るため、保存期間とアクセス権限を定めます。
一般的には、一律に単純化することは避ける必要があります。不要な広告トラッキング同意をサービス利用の条件にする場合、同意の任意性が疑われます。代替手段、対価モデル、目的、必要性、拒否時の影響を慎重に検討します。
一般的には、無視できません。データ、AI、サイバーセキュリティ、消費者保護、デジタル市場、広告透明性に関する規制は重層化しています。変更に耐えるため、棚卸し、同意管理、契約管理、監査証跡、法令モニタリングを整備します。
名称に引きずられず、現行法に基づくデジタルプライバシー統制として整えます。
eプライバシー規則EUへの対応を考える際の落とし穴は、撤回済みのePrivacy Regulation案だけを見てしまうことです。2026年6月7日現在、同案は成立していません。しかし、実務負担が消えたわけではなく、現行のePrivacy Directive、加盟国実装法、GDPR、CJEU判例、EDPBおよび各国監督機関ガイダンスに基づく整備が必要です。
企業法務としては、規則案撤回を社内共有し、EU向けWebサイト、アプリ、広告、メールを棚卸しし、Cookie、SDK、タグ、端末識別子を分類します。そのうえで、同意が必要な技術には事前ブロック、同意取得、撤回、証跡を整備し、取得後の個人データ処理についてGDPR対応を行います。ベンダー、広告代理店、CRM、MA、CMP、クラウド契約を見直し、内部監査、教育、変更管理、M&Aデューデリジェンスへ組み込みます。