Cookieバナーで拒否した後、何を確認する？表示・保存・通信を分けて調べる方法

最初に、対象のタグと確認条件をそろえる

どのタグが、どの選択で、どう動く予定なのかを先に確かめます。タグとは、アクセス計測や広告などのためにページへ組み込む処理です。同意を管理する仕組みは、バナーのボタンで選んだ内容を保持し、対象の処理へ伝えます。この仕組みや、Googleへ同意状態を伝える「同意モード」が導入されているかは、見た目だけでは分かりません。

制作担当に、対象ページ、バナーの製品や自作の仕組み、計測・広告などの対象タグ、地域による動作の違いを確かめてもらいます。タグを一括管理するGoogle Tag Managerを使っていても、その外にページへ直接組み込まれた処理があれば、それも対象を分けます。「Googleの確認画面が正常」という理由で、管理外のすべての処理まで正常とは扱えません。

この三つがそろうと、結果を比べる対象が定まります。たとえば会社の方針があるのに、導入した設定がまだ分からない場合は、先に設定内容を調べます。期待する動作が未確定のまま、通信の有無だけに合否を付けないためです。

過去の選択が混ざらない検証条件を用意する

以前の「許可」が保存された状態でページを開くと、初めて開いた人の「選択前」と同じ条件にはなりません。制作担当が管理する検証環境などで、保存済みの選択の扱いを決め、選択前・拒否後・許可後をそれぞれ確認します。同じページ、地域条件、ブラウザと版、対象タグの構成を記録し、条件を変えた場合は別の結果として残します。

別セッションをどう用意するか、どの保存領域を初期状態に戻すかは、実際のバナーの仕組みに合わせます。普段のログインや業務用ブラウザの保存内容をまとめて消す操作を、一般的な確認手順として始める必要はありません。プライベート閲覧を使う場合も、通常の閲覧と保存・制限の条件が異なることを明示し、通常環境の結果へ読み替えないようにします。

Googleの同意モードの確認方法は、会社の方針に応じた初期状態、操作後の更新、タグごとの同意条件を分けています。以下のGoogle向けの手順も、実際にその構成を使っている場合に適用します。

拒否後の画面・選択・タグ状態を分けて読む

「拒否」が表示されたことと、タグへ拒否の状態が伝わったことは別の確認です。まず、選択前の表示を記録し、次に押したボタンと直後の表示を記録します。保存済みの選択を表示する機能がある場合は、その表示も別に読みます。ただし画面に「拒否」と出るだけでは、実際の永続保存や、すべてのタグへの反映までは証明できません。

拒否を押した後、何が変わったと分かるでしょうか。下の図では、一つのボタン操作から、画面、選んだ内容、タグの状態、通信の確認先へ分けているところを見てください。対応線は確認する場所の関係であり、設定が正しく動いたという成功の流れではありません。

説明図の原画を開く

図の読み取りは「画面が閉じたから全部完了」ではなく、「表示は分かったが、ほかの欄はまだ調べる必要がある」です。タグの状態が分かっていなければ、次節のように初期状態と操作後の更新を確認します。通信の種類が分からなければ、通信一覧の該当行へ進みます。選択前・拒否後・許可後の記録を、修正前後の成功例としてつなげないことも大切です。

架空の記録では、同じ項目を近くで見比べる

次の補足は、同じ製品紹介ページの三つの状態を説明用に分けたものです。ブラウザの版、地域、導入製品や実際の初期化手順は確認されていません。この例そのものを同条件で実測した結果にはせず、見る項目と判断の境界を読むために使います。

拒否後の「通信が見えた」は、実要求を取得した記録ではありません。許可後の通信が未確認であることも、通信がなかったという意味ではありません。表示として書かれた内容と、まだ取得していない状態を分けることで、不足している確認を具体的に選べます。

Googleのタグでは初期状態と更新を確認する

Googleの同意モードを導入している場合は、Tag Assistantで、ページを開いたときの状態と、ボタン操作後の更新を分けて確認します。Tag Assistantは、Googleのタグの動作を調べるための道具です。Google以外のタグや独自実装に、そのまま同じ確認画面があると考えないでください。

1. 対象ページの検証セッションを開始する。

   制作担当が対象の構成でTag Assistantを接続します。接続できない状態では、その画面だけを根拠にタグの不存在や停止を判断しません。

2. 最も早い同意イベントで初期状態を見る。

   Summaryで最初のConsentイベントを選び、API Callの設定、または対象タグのConsentタブのOn-page Defaultを読みます。「初期状態」は、訪問者が選ぶ前に対象タグへ渡す条件です。

3. 拒否・許可の操作後の更新を見る。

   対象の操作を記録し、直近のConsentイベントやOn-page Updateを確認します。最初の設定と後の更新を混ぜず、どの操作がどの状態へ対応したかを読みます。

4. 対象タグの動作と必要な同意条件を照合する。

   Tagsで対象タグを開き、呼び出されたか、同意条件によって制限されたかを確かめます。画面に「発火」とあっても、保存やサーバー側の処理まで完了した意味にはしません。

この隣り合う二つの状態と、実際のタグの動作を対応させます。たとえば選択の表示は「拒否」になっているのに、対象の同意状態を確認できない場合は、表示を根拠に更新済みとはせず、バナーから同意状態を伝える処理を制作担当へ確認します。原因が特定できるまでは、製品の不具合や特定の設定ミスと断定しません。

Googleの確認画面では、Cookie保存に関わる analytics_storage と ad_storage、広告へのデータ利用などに関わる ad_user_data と ad_personalization など、同意の種類を区別します。ボタンの「許可」という一語だけに置き換えず、対象タグがどの条件を読むかまで確認します。

参照：Tag Assistantで初期状態・更新・タグ動作を確認する公式手順、同意モードの設定と選択の保存の説明。ここでは確認方法を説明しており、実サイトの設定変更は行っていません。

通信の記録とCookieの保存を別に見る

通信はページから送られる要求、Cookie保存はブラウザに置かれた情報です。この二つは別に見ます。Chromeの開発者向け画面では、Networkで通信の記録、ApplicationのCookiesで対象の保存内容を調べられます。Cookieは、ログイン状態や設定などを保持するために使われる小さな情報で、すべてをアクセス計測だけに使うわけではありません。

下の図は、同じページに対して通信の行を見る場所と、Cookieの保存を見る場所を分けています。通信の矢印の先に「保存成功」を付けず、要求が見えたことと保存の確認を別に読むところが要点です。

説明図の原画を開く

要求の名前だけで結果を決めず、送信先、種類、発生した時点、対象タグの同意状態を合わせます。Cookieの欄では対象の保存元を選び、名前・ドメイン・パスなどから、その情報が何に対応するかを制作担当と照合します。ある保存元の一覧に見えないだけで、別の保存元やほかの保存方式にも情報がないと広げないようにします。

Networkは、記録していた範囲の結果として読む

Networkは開発者向け画面が開いて記録している間の要求を観察します。ページを開く前から記録する必要があるか、再読み込み前後を残すかを決め、フィルターで対象を隠していないか確かめます。ページ移動をまたいで見る場合はPreserve logで記録を保持し、どの読み込み・どの操作に属する行かを区別します。記録開始が遅かったり、対象を絞り込んでいたりする場合、行が見えないことは「送られなかった」という結論にはなりません。

要求のCookiesと、Applicationにある保存情報も別です。送信時に付いたCookie、応答で保存しようとしたCookie、ブラウザが保存を制限した情報を取り違えないようにします。通信行があることだけから、サーバーで処理された、Cookieが書き込まれた、計測成果として集計されたと判断しません。

拒否後でも、方式によって通信はあり得る

Googleの同意モードには基本と高度な実装方式があり、高度な方式では、拒否の状態でもCookieを使わない計測の通信があり得ます。基本の方式では同意前のタグの読み込みを制限するなど、動作が異なります。そのため「拒否後はすべての通信がゼロ」が、どの構成でも正しい判定基準になるわけではありません。

一方で、「同意状態の通信らしいから、すべて問題ない」と逆方向に決めることもできません。実際に配置されたタグと方式、会社が案内する動作、送られる情報の範囲を確認して初めて照合できます。法的な判断が必要な場合は、対象地域・情報・利用方法などを整理して適切な専門家へ確認し、この技術的な記録だけで適法と表示しないようにします。

参照：Chromeの通信記録と絞り込み、Cookieの保存元と項目の確認、Googleの基本・高度な同意モードと通信の説明。

分かったことと未確認を分けて次の対応を決める

一件の観察を、期待した動作と比べて、不足している確認へつなげます。すべてを「正しいか不明」で終えず、分かった場所から順に切り分けます。次は今回の架空記録を読む場合の判断です。実際の修正結果ではありません。

制作担当へは、たとえば「製品紹介ページの拒否後は選択表示まで確認できています。対象タグの初期状態と更新、要求の種類、Cookie保存は何と照合できますか」と具体的に伝えられます。実際の相談では対象ページ、操作した時点、ブラウザと地域条件、期待する動作と観察結果を添えます。画面や通信記録を共有するときは、個人情報や認証に関わる値をそのまま公開しない扱いを決めてください。

実設定に問題があると確認できた場合は、制作担当が影響範囲を確認して必要な修正を行い、同じ条件で選択前・拒否後・許可後を再確認します。案内文の説明と実際の設定が違う場合も、文だけを都合よく書き換えず、会社が意図する動作を確かめてどちらを直すか決めます。変更前の記録は残し、別条件の結果と混ぜません。

計測や外部サービスの利用目的など、ページで何を案内するかも整理する場合は、ページの使い方に応じて利用条件や用途の案内を分ける方法も参照できます。案内の場所を整えることと、今回のタグ・通信の確認は、別の作業として進めます。

まとめ：拒否後に見る一件から確認を始める

Cookieバナーの確認は、「拒否を押せた」「通信があった」という一つの結果で終わりません。対象の構成と期待する動作を確かめ、選択前・拒否後・許可後ごとに、表示、選択の保存、同意状態、通信、Cookie保存を分けて照合します。

今日まず行うことは、拒否後の一件について「確認できた欄」と「まだ見ていない欄」を分けることです。Googleの同意モードを使う場合はその公式の確認方法を使い、構成が分からなければ先に制作担当へ確認します。未確認を成功・失敗・原因へ補わず、次に見る場所を具体的に決めてください。

自社サイトの案内と実装の対応を整理したい場合は、対象ページと現在の確認状況を相談するところから進められます。