GA4や広告を使うホームページのCookie同意｜導入前に確認する計測と表示

GA4やGoogle広告のタグが入っているからといって、すべてのホームページで同じCookie同意バナーを表示すればよいわけではありません。最初に確認するのは、どのタグが、何のために、どこへ情報を送り、利用者がまだ選んでいないとき、許可したとき、拒否したときにどう動くべきかです。バナーは方針を示して選択を受け取る画面であり、タグの発火制御やポリシーの記載まで自動で整えるものではありません。

法的に同意が必要か、通知・公表など別の対応で足りるかは、対象地域、提供しているサービス、送信する情報、送信先での扱いによって変わります。必要に応じて弁護士などの専門家へ確認したうえで、Web担当者と制作会社は、タグの棚卸し表、同意状態ごとの発火表、画面とポリシーの文案、テスト項目を一つの仕様へまとめます。この記事では、導入前にその四つをどうつなげるかを整理します。

Cookie同意の要否を「GA4を使うか」だけで決めない

GA4は標準的な実装でファーストパーティCookieを使い、ユーザーやセッションを区別します。Googleの公式ヘルプでは、_gaはユーザーの区別、_ga_<container-id>はセッション状態の保持に使うと説明されています。ただし、Cookieがファーストパーティかサードパーティかという分類だけで、必要な対応が一意に決まるわけではありません。広告タグ、埋め込み動画、チャット、ヒートマップ、外部フォームなどが同じページで動いていれば、ブラウザから複数の事業者へ情報が送られる可能性があります。

日本では、Cookieなどの端末識別子が個人情報に当たらない場合でも、通常は個人関連情報に該当し得ると個人情報保護委員会が説明しています。また、一定の電気通信役務では、利用者に関する情報を外部へ送信させる際の通知・公表などを定める外部送信規律があります。海外からのアクセスや海外向け事業がある場合は、対象国・地域の制度やGoogleのポリシーも確認が必要です。「日本の会社だから不要」「GA4だけなら必ず不要」「広告を使うなら全サイトで同じバナー」といった一律の判断は避けます。

導入方針を決める前に、次の四点を社内で確認します。

• 主な訪問者はどの国・地域にいるか。海外向けページや越境ECがあるか
• サイトが提供する機能は何か。閲覧だけか、会員、予約、決済、投稿などがあるか
• 解析・広告・外部サービスへ何を送るか。送信先で他の情報と結び付く可能性があるか
• 自社として、必要最小限の計測、詳細な分析、広告最適化のどこまでを行うか

この確認を行うと、「全訪問者に同じ動作を適用する」「地域ごとに初期状態を変える」「分析と広告を別々に選べるようにする」など、実装すべき方針が見えてきます。法務判断と実装判断を混ぜず、法務・事業・計測の三者で合意した方針を制作仕様へ落とします。

まず作るのはCookie一覧ではなくタグの送信台帳

ブラウザに保存されるCookie名だけを集めても、タグの全体像は分かりません。Cookieを使わずに通信する仕組みや、ページ表示時に外部サーバーへ送るスクリプトもあるためです。棚卸しの単位は「Cookie」より「タグ・機能・送信先」にします。

確認箇所はページのソースコードだけではありません。Googleタグマネージャーの全コンテナ、WordPressのプラグイン、テーマ設定、広告媒体の管理画面、外部予約・決済・チャット、動画や地図の埋め込み、サーバーサイドタグ、フォーム完了ページまで見ます。古い担当者が直接埋め込んだタグや、停止した施策のタグが残っていることもあります。タグマネージャーだけを見て「全件確認済み」としないことが大切です。

棚卸し表には、少なくとも次の列を用意します。

項目	記録する内容	判断に使う場面
タグ・機能名	GA4、Google広告、動画、チャットなど	抜け漏れと担当者の確認
設置場所	GTM、テーマ、プラグイン、外部サービスなど	修正方法と作業範囲の確認
利用目的	アクセス解析、広告計測、機能提供、不正防止など	同意カテゴリと表示文の整理
送信する情報	ページURL、端末情報、識別子、入力情報など	法務確認と最小化の検討
送信先	自社、Google、その他の事業者	外部送信先とポリシーの確認
最初の発火条件	全ページ、特定ページ、操作後、完了時など	同意前に動く可能性の確認
同意カテゴリ	必須、分析、広告、機能など	バナー選択と発火制御の対応
管理責任者	社内担当、代理店、制作会社など	追加・変更時の承認経路

「必須」「分析」「広告」「機能」といったカテゴリ名は、CMPの初期設定をそのまま採用せず、自社のタグと説明が一致するように決めます。たとえば、問い合わせフォームの送信に必要なセキュリティ機能と、フォーム到達者を広告へ送るタグは同じページにあっても目的が異なります。ページ単位ではなくタグ単位で分けなければ、拒否時に必要な機能まで止めたり、広告タグだけ残したりする事故が起こります。

目的が説明できないタグ、管理者が分からないタグ、使っていない媒体のタグは、同意設計へ組み込む前に削除候補へ分けます。不要なタグを残したまま複雑な同意制御を追加すると、テスト項目と保守負担だけが増えます。

表示文はポリシーとタグの動作から逆算する

同意バナーの文章を先に作ると、「サービス向上のためCookieを利用します」のような抽象表現になりがちです。利用者が選べる内容と、実際のタグ動作を決めてから、画面に必要な説明を逆算します。

バナーの初期画面では、短い文章の中に利用目的、選択肢、詳細説明への導線を入れます。すべての送信先や保存期間を狭い画面へ詰め込む必要はありませんが、「分析のため」「広告の効果測定のため」など、選択の違いが分かる表現は必要です。詳細画面またはCookieポリシーには、カテゴリ、主なツール、送信情報、送信先、目的、保存・選択の扱いを整理します。

プライバシーポリシー、Cookieポリシー、外部送信に関する公表ページを分けるか一つにまとめるかは、サイトの情報量と法務方針によります。どの形でも、次の矛盾を残さないようにします。

• バナーでは「分析を拒否できる」と書いているのに、GA4が同意前から通常発火している
• 詳細画面では広告カテゴリがあるのに、Google広告タグが分析カテゴリへ入っている
• ポリシーに記載のない動画・地図・チャットが外部通信している
• 「拒否しても利用できる」と書いているのに、必須機能まで停止してフォームが送れない
• 一度選んだ後に変更できると書いているのに、設定画面へ戻る導線がない

画面設計では、同意だけを目立たせ、拒否や設定変更を見つけにくくしないことも重要です。「すべて許可」「すべて拒否」「設定する」の役割を明確にし、スマートフォンでもボタンや説明が隠れないか確認します。同意の記録期間、再表示の条件、タグを追加したときの再選択、利用者が途中で撤回した場合の扱いも仕様に含めます。

同意前・許可・拒否を一枚の発火表にする

実装で最も重要なのは、同意状態ごとのタグ発火を一枚の表にすることです。バナーの画面遷移図だけでは、ページを開いた直後に何が動くか、拒否した後に何が止まるかを確認できません。

基本となる状態は、初回訪問でまだ選択していない「同意前」、分析または広告を「許可」、それぞれを「拒否」、過去の選択を「変更・撤回」の五つです。分析と広告を別々に選べる場合は、組み合わせも増えます。次のような表を作り、タグごとに期待動作を記録します。

利用者の状態	必須機能	GA4	Google広告	その他の分析・広告
初回・未選択	サービス提供に必要な範囲だけ動作	方針に沿った初期状態	方針に沿った初期状態	原則として個別確認
分析のみ許可	動作	分析用の許可状態	広告用は拒否状態	分析カテゴリだけ動作
広告も許可	動作	設定どおり動作	設定どおり動作	許可カテゴリだけ動作
すべて拒否	必要な範囲だけ動作	拒否時の仕様を維持	拒否時の仕様を維持	停止または限定動作
設定を撤回	動作	次の送信から拒否状態	次の送信から拒否状態	保存済み選択を更新

表の「方針に沿った初期状態」を曖昧なまま制作会社へ渡してはいけません。Googleの同意モードには、同意が得られるまでGoogleタグ自体をブロックする基本的な実装と、タグを読み込んだうえで初期値を拒否にし、拒否時は限定的に動作させる高度な実装があります。どちらを選ぶかは、適用されるルール、社内方針、計測要件を合わせて判断します。高度な実装を選んだから法的要件を満たす、基本的な実装なら必ず安全、という関係ではありません。

Googleタグマネージャーを使う場合は、通常のページビュータグより前に同意の初期状態を設定します。Googleの公式ドキュメントは、ユーザーが選択する前にデフォルトの同意状態を設定し、操作後に同意状態を更新する流れを示しています。CMPを非同期で読み込むと、同意設定より先にタグが動くことがあるため、読み込み順と待機処理も確認します。

Google同意モードは利用者の選択を保存する機能そのものではありません。CMPまたは自社の仕組みで選択を保存し、次のページ表示でも正しい状態を設定する必要があります。バナーが消えたことをもって実装完了とせず、ページ遷移後、再訪問時、別ページからの直帰流入でも同じ状態が再現されるかを確認します。

GA4と広告の同意項目をカテゴリ名に正しく結び付ける

Googleの同意モードv2では、主に四つの同意タイプを扱います。

• analytics_storage：分析に関連するCookieなどの保存
• ad_storage：広告に関連するCookieなどの保存
• ad_user_data：広告目的でユーザーデータをGoogleへ送ること
• ad_personalization：パーソナライズ広告への利用

バナー側に「アクセス解析」「広告」「パーソナライズ」などのカテゴリがあっても、四項目との対応が自動的に正しくなるわけではありません。CMPの設定、GTMの同意設定、Googleタグのコード、広告媒体側の設定をつなげて確認します。広告の保存を拒否していても、ユーザーデータ送信やパーソナライズの値が許可のまま残るような対応漏れを避けます。

GA4だけを使うサイトでも、Google広告との連携、オーディエンス作成、コンバージョンのインポート、Googleシグナルなどの設定によって、分析と広告の境界が変わります。逆に、広告を出していても、どのコンバージョンをWebタグで送るか、拡張コンバージョンを使うか、外部予約サイトへ遷移するかで実装範囲は異なります。製品名だけで分類せず、実際のデータ用途を確認します。

見落としやすいのが、サブドメイン、別ドメインのカートや予約、外部フォーム、サンクスページです。トップページでは同意状態が正しくても、遷移先で別のタグが先に発火したり、同意状態を引き継げず新しいユーザーとして計測されたりすることがあります。対象ドメインの一覧と、同意選択をどこまで引き継ぐかを仕様に含めます。

サーバーサイドタグを使う場合も、ブラウザから自社サーバーへ送った後に何をどこへ転送するかを棚卸しします。「サーバー経由だから同意設計の対象外」とは限りません。ブラウザ側の発火、サーバー側の転送、広告媒体側の受信を分け、拒否状態が最後まで維持されるかを確認します。

公開前テストは画面・発火・計測差の三層で行う

同意バナーのテストで「表示された」「ボタンが押せた」だけを確認しても、タグの誤発火は見つかりません。テストは、画面表示、技術的な発火、レポート上の計測差の三層に分けます。

画面では、初回表示、スマートフォン、スクロール、キーボード操作、詳細設定、拒否、再設定、言語・地域別表示を確認します。バナーが問い合わせボタンやフォーム送信を隠さないか、拒否しても必要なページを閲覧できるか、設定変更の入口が全ページから見つかるかも見ます。

発火では、ブラウザの保存領域とネットワーク通信、Googleタグマネージャーのプレビュー、Tag Assistantを使います。Tag Assistantでは、最初の同意イベントでデフォルト値が設定されているか、利用者の操作後に値が更新されたか、各タグが必要な同意タイプを確認して発火したかを検証できます。少なくとも次のシナリオを、新しい状態から繰り返します。

1. 未選択のままページを閲覧し、別ページへ移動する
2. すべて許可し、ページビューと主要イベントを実行する
3. すべて拒否し、同じ操作を行う
4. 分析だけ許可し、広告だけが止まるか確認する
5. 許可後に設定を撤回し、次の送信から状態が変わるか確認する
6. フォーム送信、購入、予約など主要コンバージョンを完了する
7. サブドメイン、外部カート、別ドメインへ移動する
8. 再訪問時に前回の選択が正しく再現されるか確認する

計測差の確認では、導入前後のGA4や広告管理画面の数値が一致することを合格条件にしません。拒否や限定動作を設計すれば、取得できるイベント数やユーザー数は変わります。大切なのは、仕様どおりの差か、実装ミスによる欠損かを区別できることです。

公開日をGA4や社内レポートへ記録し、導入前の比較期間を決めます。全体値だけでなく、ブラウザ、端末、地域、流入元、主要ページ、コンバージョン別に変化を見ます。広告のクリック数は変わらないのにWeb側のコンバージョンだけ急減した、特定ブラウザだけセッション開始が減った、同意後のイベントが二重送信された、といった差は実装確認の手掛かりになります。

テスト表には、操作手順、期待する同意状態、発火してよいタグ、発火してはいけないタグ、確認画面、実測結果、担当者、確認日を記録します。制作会社、広告代理店、社内担当が別々に「問題なし」と判断するのではなく、同じ合格条件を共有します。

導入後に崩れやすい箇所まで運用ルールへ入れる

公開時に正しくても、新しい広告タグやプラグインを追加した後に同意制御を通らなくなることがあります。Cookie同意は一度設置して終わる部品ではなく、タグ変更の承認工程です。

よくある崩れ方は、次のとおりです。

• 新しいタグを「全ページ」トリガーで追加し、同意条件を設定し忘れる
• WordPressのプラグイン更新で外部スクリプトが追加される
• 広告代理店がGTMへタグを追加したが、Cookieポリシーが更新されない
• CMPのカテゴリ名を変更し、同意モードとの対応が外れる
• サンクスページだけ別テンプレートで、初期同意設定が読み込まれない
• 設定変更用リンクをデザイン変更時に削除する
• テスト環境と本番環境でタグIDや発火条件が異なる

これを防ぐには、タグ追加の申請項目へ「目的・送信情報・送信先・同意カテゴリ・ポリシー更新・テスト担当」を入れます。サイト改修、広告媒体追加、フォーム変更、CMP更新、法務方針変更のタイミングでは棚卸し表とテスト表を更新します。

計測担当だけに運用を任せるのも危険です。バナー文言は広報・法務、タグ発火は制作・開発、広告用途は広告担当、利用目的と保存方針は事業責任者が関わります。最終的に誰が新しいタグを承認し、誰が本番公開後を確認するかを決めておくと、担当者の異動や代理店変更があっても設計を維持できます。

制作会社へ渡すときは「ツール名」より期待動作を伝える

制作会社へ「Cookieバナーを入れてください」「Consent Mode v2にしてください」とだけ依頼すると、法務方針や計測要件を制作側が推測することになります。CMPの選定やコード実装を任せる場合でも、発注側が決めることと制作側へ相談することを分けます。

発注側で用意したいのは、対象地域と法務方針、タグの送信台帳、分析・広告の利用目的、利用者へ提示する選択肢、主要コンバージョン、関係するドメインです。制作会社には、現在の設置場所調査、CMPや自社実装の比較、GTMと同意モードの設定、画面制作、ポリシー反映、テスト手順の整備を相談できます。

完成条件は「バナーが表示されること」ではなく、未選択・許可・拒否・撤回の各状態で、画面、タグ、計測が合意した仕様どおりに動くことです。公開後のタグ追加方法と再テストの範囲まで決めれば、広告や解析を続けながら利用者の選択を保てます。

まとめ｜同意画面と計測を同じ仕様で確認する

GA4や広告を使うホームページのCookie同意は、バナーの有無だけで判断しません。法的判断は専門家へ確認しつつ、利用しているタグ・目的・送信先を棚卸しし、同意前・許可・拒否・撤回の発火を表にします。その表を画面文言、ポリシー、Google同意モードの設定、公開前テストへつなげます。

導入前に四つの成果物――送信台帳、発火表、表示・ポリシー文案、テスト表――をそろえておくと、制作会社や広告代理店との認識差を減らせます。見た目、タグの動作、レポートの差を同じ合格条件で確認することが、同意設計を形だけで終わらせないための基準です。