デジタル・オムニバス後のCookie同意:何が変わり、いま何を作るべきか

Cookieバナーはインターネットで最も愛されていないUIです。同時に最も監督を受けているもののひとつでもあります。目に見えて、テストでき、何千人もが通報するからです。
2025年11月、欧州委員会はデジタル・オムニバスのパッケージを提案しました。その中には、Cookie同意のルールをeプライバシー指令からGDPR本体へ、新しい第88a条と第88b条として移すという内容が含まれています。三者協議は2026年半ばまで続き、最終条文はまだありません。
いますべてのプロダクトチームが抱えている矛盾がここにあります。現行ルールは依然として有効で、執行も活発ですが、あなたが基準にしているルールは1年か2年のうちに変わる可能性が高い。その間に何をすべきかについての私たちの見方を書きます。
現在地
現在の法状態は、二つの法令のやや居心地の悪い組み合わせです。
eプライバシー指令は端末そのものを扱います。ユーザーの端末機器にデータを保存すること、またはそこから読み取ることには同意が必要です。ただし、ユーザーが明示的に求めたサービスを提供するために厳密に必要な場合を除きます。これはCookie、localStorage、端末フィンガープリント、トラッキングピクセルを対象とします。
GDPRはその後に収集される個人データを扱います。法的根拠、透明性、権利、保存期間。
だから「分析には正当な利益がある」ではCookieの問題は解決しません。法的根拠は処理をカバーします。端末へのアクセスにはやはり同意が必要です。
複数の監督機関が具体化してきた、有効な同意の現行要件:
- 受諾と同じくらい簡単に拒否できること。同じ階層で、同じ見た目のボタンで。
- 不可欠でない目的についてあらかじめ選択しないこと。
- 目的ごとに分離可能であること。
- 誰がデータを受け取るのかを明確に示すこと。
- 付与と同じくらい簡単に撤回できること。
- 真の代替なしにアクセスの条件として受諾を強いる壁を設けないこと。
- 同意の証拠を保存すること。
そして多くのサイトが落ちる実務テスト:ユーザーが選択する前に、不可欠でないものは何ひとつ読み込まないこと。
デジタル・オムニバスは何を変えるか
この提案は実質的な簡素化の試みで、主な内容は次のとおりです。
同意とCookieがGDPRの問題になる。 第88a条は、端末内でのデータ保存とアクセスに関するルールをGDPRに移し、二つの法令の分断を終わらせ、データ保護機関に明確な管轄を与えます。
より広い適用除外。 提案は同意が不要な場面を拡大し、サイバーセキュリティ、一定の条件下でのオーディエンス計測、サービスの機能に必要なものを含めます。細部では最も争いのある部分です。
拒否後6か月の沈黙。 ユーザーが拒否した場合、限られた場合を除き、6か月間は同じ要求を再提示できません。これはバナー疲れを直接狙っています。
機械可読シグナルに法的拘束力。 第88b条は、ブラウザまたはOSレベルで与えられた自動的な同意シグナルを尊重することを義務づけます。アーキテクチャが最も変わるのはここです。
パッケージの他の部分では、個人データの定義、AI学習における正当な利益、データ侵害通知についての明確化も提案されています。これらも確定ではありません。
なぜ待つだけでは駄目なのか
待つことを悪い選択にする理由が二つあります。
第一に、現行の執行は休んでいません。データ保護機関はいまもバナーの一斉調査を行っており、拒否の選択肢がないことは依然として最も多い発見です。「オムニバスを待っていました」は2026年の監査で抗弁になりません。
第二に、提案の方向は、細部が変わってもアーキテクチャを導くには十分に明確です。機械可読シグナル、拒否状態の尊重、目的別の分離は、最終条文がどうであれ、いま作る価値があるものです。
私たちが今日作るもの
現行ルールの下で成立し、想定される変更を小さな修正で乗り切れる同意アーキテクチャを示します。
同意状態をサーバー側の概念にする
最もよくある誤りは、同意をブラウザの関心事として扱うことです。同意プラットフォームがCookieを設定し、スクリプトがそれを問い合わせ、それで終わり。
サーバーが同意に依存する何かをした瞬間にこれは壊れます。パーソナライズ、サーバーサイドのトラッキング、広告プラットフォームへのイベント送信、A/Bの振り分け。これらはブラウザのスクリプトが意見を述べる前に起きます。
同意状態をサーバーがリクエストごとに読める形で保存し、両側の不可欠でない処理すべての前提条件にしてください。
スクリプト読み込みを条件付けする、後からブロックしない
ブロックは後付けの手当てです。同意プラットフォームがそのスクリプトを知っていれば機能し、知らなければ静かに失敗します。
代わりに、同意状態が判明して肯定であるまで、不可欠でないスクリプトがDOMに存在しないようにタグの読み込みを組み立ててください。通常は、目的別の同意を読んで対応するタグを注入する小さなローダーになります。
そうするとテストは単純になります。クリーンなプロファイル、ネットワークタブ、クリックなし、第三者へのリクエストなし。監督機関が走らせるのと同じテストです。
ベンダーではなく目的をモデル化する
47社のベンダーを列挙するバナーは悪いUIで、保守も大変です。四つの目的を列挙するバナーは読めますし、ベンダーが変わっても正しいままです。
ベンダーの対応づけは目的の下に置き、ユーザーが最初に見る選択肢にはしないでください。ユーザーはベンダー一覧に到達できる必要がありますが、それは第二階層で構いません。
問い合わせ可能な同意ログを作る
誰が同意したか、どの目的に、いつ、どのバージョンのバナーから、そして状態がいつ変わったかに答えられなければなりません。現在の状態ではなくイベントログとして保存してください。現在の状態は、あるイベントが記録されたときに何が有効だったかを教えてくれません。
これは提案されている6か月ルールを簡単にする理由でもあります。タイムスタンプ付きの拒否イベントがあれば、沈黙期間の実装は条件をひとつ足すだけです。
機械可読シグナルに備える
第88b条が現在の形で通らなくても、方向は明確です。同意レイヤーは複数の入力を受け取れるように設計してください。UIでの選択、保存された過去の選択、外部シグナル、そしてそれらに明確な優先順位を与える。
実務的には、同意を解決するロジックが関数としてひとつの場所にあり、バナーのコンポーネントツリーに散らばっていない、ということです。
不可欠なものを切り分けて理由を述べる
不可欠と分類したCookieのそれぞれについて、なぜ不可欠なのかを書いてください。セッション、ロードバランシング、CSRFトークン、言語選択。これらは簡単です。分析はそうではありません。ファーストパーティ分析と呼んでいてもです。
このリストは最初に尋ねられるものであり、オムニバスが通った場合に拡大された適用除外の恩恵を受けられるかどうかも決めます。
よく見る誤り
拒否ボタンが第二階層にある。 いまだにです。執行案件で最も多い単一の発見です。
同意がサーバーサイドのトラッキングを覆っていない。 ブラウザの制限のためサーバーサイドのイベント送信に移行し、それを同意に接続しなかった。いまやユーザーが何を選ぼうとイベントは出ていきます。
訪問のたびに同意がリセットされる。 通常はCookieの有効期間かドメイン設定の誤りです。ユーザーは同じ問いに延々と答えさせられ、これこそ提案された沈黙期間が終わらせようとしているものです。
撤回が隠されている。 受諾がワンクリックで、撤回にはプライバシーポリシーをたどる必要があるなら、それは同じくらい簡単ではありません。
同意の証拠がない。 プラットフォームがダッシュボードを見せてくれるが、自社のシステムには何もない。ベンダーを変えれば証拠は消えます。
下請けベンダーが静かに現れる。 タグ管理で追加したマーケティングツールが、他に三つ連れてきます。バナーのベンダー一覧を更新する人はいません。
現実的なタイムライン
デジタル・オムニバスが採択されれば、適用前に移行期間があり、その後に各国機関がガイダンスを出すと見込まれます。実務的には、しばらくは現行ルールで評価されるということです。
私たちが顧客に伝えているのは、現行ルールに沿って作るが、変更が書き直しではなく設定で済むように作る、ということです。目的別の分離、イベントベースのログ、サーバー側の状態、そして解決関数ひとつが、その柔軟性を与えてくれます。
これが他とどこで交差するか
同意の基盤はバナーだけの話ではありません。パーソナライズ、分析、広告、そしてますますAI機能を左右します。プロダクトがAIを使うなら、AI法の透明性義務が独自の告知レイヤーを加えますが、ユーザーから見れば同じ会話です。何が起きているか、誰が決めるか、どう伝えるか。
土台は依然としてGDPR本体で、それはウェブサイトのGDPRガイドで通しています。規制の全体像は2026年EUデジタル規制ガイドにあります。
手助けが必要なら
私たちは欧州で事業を行う企業向けに、同意アーキテクチャ、タグ管理、分析パイプラインを構築しています。実務上はほとんど配管工事です。同意状態を必要な場所へ届け、出すべきでないものが出ていかないようにすること。
office@c9group.dev までご連絡いただくか、EU市場参入のページをご覧ください。
私たちは法的助言を行いません。何が不可欠で何がそうでないかは弁護士への問いであり、私たちはその答えのまわりにシステムを作ります。