Consent Mode v2 と 2026 年 6 月の Google Signals 廃止
2026 年 6 月 15 日、ad_storage が Google スタックにおける広告データの唯一の制御になります。Google Signals の廃止が開発者に何をもたらすのか——そしてこの仕組み一式が、cookie を使わない分析が構築する必要のなかったものである理由を解説します。
2026 年 6 月 15 日、Google は広告データの独立した制御としての Google Signals を廃止します。この日以降、同意管理プラットフォーム（CMP）が送信する ad_storage 同意シグナルが、訪問者レベルのデータが Google Ads に届くかどうかを決める唯一のゲートになります。CMP の設定が誤っていても、その誤りを受け止める Analytics 側のサーバーサイド設定はもう存在しません。
これは静かながら重大な変更です。同意の正しさという負担のすべてを、データ収集の前に訪問者のブラウザで動く JavaScript レイヤーへと移します。このレイヤーが何をしているのかを正確に理解する価値があります。なぜならそれこそ、cookie を使わない設計が決して抱え込まない複雑さだからです。
Consent Mode v2 とは実際に何か
Consent Mode v2 は、ストレージの使用が許可されているかを自社タグに伝えるための Google のフレームワークです。同意バナーではなく——あなたのバナーと Google のタグをつなぐ配線です。CMP は 4 つのシグナルを設定します。
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
});
ad_storageは広告 cookie、デバイス識別子、Google Ads に送られる訪問者レベルのデータを制御します。analytics_storageは client ID を割り当てる Analytics の cookie を司ります。ad_user_dataは Enhanced Conversions のためにメールなどの first-party データをハッシュ化することを許可します。ad_personalizationは Analytics データがパーソナライズ広告ターゲティングに使われるかを決めます。
訪問者が承諾すると、CMP は 2 回目の呼び出しを発火し、該当シグナルを granted に更新します。下流のすべては、この更新が正しく届くかどうかに依存します。
basic と advanced、そして advanced が存在する理由
実装モードは 2 つあり、その違いは法的に重要です。
basic モードでは、同意が得られるまで Google のタグはまったく読み込まれません。拒否されれば何も送信されません。
advanced モードでは、すべてのシグナルが既定で denied の状態でタグが即座に読み込まれ、それでも Google に cookieless pings を送信します——識別子も client ID も保存状態もないリクエストです。Google はこれらの ping の量と、同意した少数派の挙動を用いて、直接観測できないコンバージョンをモデル化します。
advanced モードが存在するのは、同意率が低く、広告主が自分たちの数字を取り戻したいからです。しかし同意前に送られる cookieless ping も、依然として第三者へのデータ送信であり、ePrivacy 第 5(3) 条に対する EDPB の技術中立的な解釈は、cookie を省いたという理由だけでリクエストを免除しません。モデル化コンバージョンには信頼できる数値を出すための最低限の同意済みセッションのプールも必要で、小規模サイトはノイズしか得られません。
6 月 15 日の廃止が取り除くもの
これまで Google Signals は第 2 のゲートとして機能していました。Consent Mode が何を報告しようと、Analytics 上でこれをオフにすれば広告データの共有を制限できました。そのセーフティネットがなくなります。
廃止後は——
- Google Ads は Analytics 側の設定を読まなくなり、CMP が送る Consent Mode シグナルにのみ依存します。
- Google Signals は Analytics 限定の用途——GA4 内部でセッションをログイン済みユーザーに関連付けること——に絞られます。
- IP アドレスは引き続き収集され、リンクされた Ads アカウントへ転送される前に暗号化され、その後は送信先アカウントの設定が引き継ぎます。
実際の影響はこうです。たった 1 回の失敗した gtag('consent', 'update', ...) 呼び出し——競合状態、最初のタグの後に読み込まれる CMP、既定状態を取りこぼすデプロイ——が、今やブロックするつもりだったデータを黙って送信します。GDPR の下ではこれは適法な根拠のない処理であり、サーバーサイドのセーフティネットの撤廃により、流出が封じ込められていたと主張することが難しくなります。
これはまた、近年のガイダンスによれば、広告データの共有方法に対する重大な変更にあたります。EU の訪問者がいるサイトでは、ユーザーへの通知義務を引き起こしうる——期限の後ではなく前に行う価値のあるレビューです。
存在する必要のなかった複雑さ
一歩下がって、準拠した Consent Mode v2 の構成が何を必要とするか見てみましょう。CMP、4 つの同意シグナル、既定状態、タグの読み込みに対して正しく順序付けられた更新呼び出し、法的帰結を伴う advanced か basic かの判断、トラフィックの閾値を超えてのみ機能するモデル化コンバージョン、そして今やセーフティネットなしの単一障害点。
この仕組み一式が存在するのは、識別子——client ID、広告 cookie、ハッシュ化したメール——を使い続けながら、同意法の正しい側に留まるためです。識別子を取り除けば、装置全体は何もないところへと崩れ落ちます。
cookie を使わない tracker には、ブロックすべき ad_storage がありません。広告ストレージを一切設定しないからです。拒否すべき client ID もありません。アイデンティティはエッジのメモリ内で計算され決して逆算されない一方向ハッシュ SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) だからです。生の IP と User-Agent はそのハッシュの計算にのみ使われ、D1 が保存するのは入力ではなくハッシュです。失敗しうる同意シグナルもありません。第 5(3) 条の下で同意すべきものが何もないからです——訪問者のデバイスへのアクセスはページ配信に厳密に必要であり、/collect へ送る 2 KB 未満のスクリプトはストレージを一切読みません。
6 月 15 日の廃止は、「私の Consent Mode は正しく設定されているか」よりも鋭い問いを立てる好機です。そもそもなぜページビューを計測するために同意ステートマシンを動かしているのか、と問うてください。Google が cookieless pings からモデル化するコンバージョンは、あなたが収集を許されたことのないデータの推定値です。識別子なしで、実際に起きたことを数えること——それが常により単純なシステムでした。
Comments
Loading comments…