【GTM／GA4】Cookie同意バナーの実装で使う「同意モード」「同意の初期化トリガー」とは何か？その仕組みと実装のポイントを徹底解説

GTMで「同意の初期化」トリガーや、タグの「同意設定」の項目を見かけたけれど、何に使うのかよく分からない。あるいは、Cookieバナーを入れるタイミングで「同意モードに対応しておいて」と頼まれて、どこから手を付ければいいか迷っている。この記事は、そういう状況の方に向けて書いています。

先に要点を書いておくと、同意モード（Consent Mode）は、Cookieの利用にユーザーが同意したかどうかで、GA4や広告タグの動きを切り替える仕組みです。ただ、GTMの設定だけでは完結しません。GTMに対応した同意ツール（CMP）と組み合わせるのが前提になります。ここを最初に押さえておくと、そのあとの設定の見通しがだいぶ良くなるかなと思います。

この記事で分かるのは、次のようなことです。

• 同意ツールが必要な理由と、「同意の初期化」トリガーの役割・注意点
• 実装の流れと、正しく動いているかの確認方法
• 同意モードv2で追加された「ad_user_data」「ad_personalization」
• 「基本実装」と「詳細実装」で、同意を拒否されたときの挙動がどう変わるか
• CMPを使わずにコードで書く場合の「default」と「update」

全体を順番に読んでもらっても、いま困っているところから読んでもらっても大丈夫だと思います。自分のサイトの設定と見比べながら確認してもらえるといいかなと。

そもそも「同意モード（Consent Mode）」とは？

GTMの「同意モード」とは、ユーザーのCookie利用に関する同意状況に応じて、各種タグの挙動を自動的に調整するための仕組みです。

たとえば、ユーザーが広告用Cookieを拒否した場合、Google広告のタグは通常のデータを送信しないよう制御されます。一方、Googleアナリティクスのような解析タグも同意状況に応じて挙動を変え、必要に応じて匿名のデータ送信に切り替えることが可能です。

GTMの同意モードには「GTMに対応した同意ツール」が必須

バナーを出す役はGTMではなく同意ツール

GTM単体には、ユーザーに同意を求める機能や、その同意内容を管理する機能は備わっていません。GTMの同意モードを正しく動作させるには、GTMに対応したCookie同意管理ツール（CMP: Consent Management Platform）を導入することが必須条件です。

なぜ対応したツールが必要なのか？

以下の理由があります：

• GTMの同意モードは、あくまで「同意状況に基づくタグの制御機能」**であり、ユーザーにバナーを表示したり、同意の取得を行う機能は含まれていません。
• 同意ツールが、ユーザーから取得した同意情報をGTMに連携することで初めて、「同意モード」は機能を発揮します。
• GTMは、同意ツールからの情報をもとに、タグの発火を許可または制御します。ツール非対応の場合、この連携ができず、同意状況に応じた制御は一切できません。

同意モードでできることの具体例

たとえば、同意を拒否したユーザーの数を計測したいと考える場合でも、同意ツールからGTMへの情報連携がなければ、拒否されたかどうかをGTM側では認識できません。

つまり、以下のようなステップを踏む必要があります。

1. GTM対応の同意ツールを導入し、ユーザーに同意を求める。
2. 同意ツールが取得した同意状況をGTMに渡す設定を行う。
3. GTMのタグ側で「同意設定」を構成し、ユーザーの同意状況に応じて発火するかどうかを決める。

キーとなる「同意の初期化」トリガーとは？

図1: 同意の初期化トリガーの発火順序

2023年以降、GTMには新しく「同意の初期化（Consent Initialization）」というトリガーが追加されました。

同意の初期化トリガーの挙動と役割

同意の初期化トリガーの挙動と役割は以下のとおりです。

• GTMで最も早く発火するトリガー
• ページビューや初期化トリガーよりも先に動作
• gtm.init_consent イベントがベース
• 役割：Cookie同意ツールを他のタグよりも早く起動させる

これにより、ページの表示前に同意情報を取得・設定することが可能になります。

同意の初期化トリガーの注意点

「同意の初期化」トリガーは、あくまで同意ツールのタグを起動するためのものであり、計測タグ（GA4など）をこのトリガーで発火させるのは非推奨です。理由は以下のとおりです。

• 同期的にタグが動作し、ページの読み込み速度に影響を与える可能性がある
• 同意情報がまだ確定していない段階で計測を始めてしまう恐れがある

実装の流れ：同意モードを正しく設定する手順

以下に、実際の設定手順を簡単にまとめます。

STEP

GTMに対応した同意ツールのタグをインポート

• GTMのコミュニティテンプレートギャラリーから、Cookie同意ツール（例：Cookiebot、OneTrustなど）のテンプレートをインポート
• トリガーとして「同意の初期化（Content Initialization – All Pages）」を選択

STEP

同意ツールタグ内の設定

• バナーの表示設定、同意カテゴリの構成、同意の保存方法などを設定
• ツールがGTMに同意情報を送信できるように構成

STEP

各タグに「同意設定」を追加

• GA4やGoogle広告のタグなどには、詳細設定から「同意設定」を追加
• analytics_storage や ad_storage など、必要な同意タイプを指定し、「同意が得られていない場合はタグを発火させない」ように設定

STEP

カスタムイベント対応 (必要に応じて)

• 「組み込み同意チェック」に対応していないタグの場合、同意後のイベント（例：consent_update）をカスタムトリガーとして使い、特定のタグを発火させる設定も可能です。

まとめ：GTMの同意モードを正しく使うには？

GTMの同意モードは、「同意ツール」とセットで使うことで初めて効果を発揮します。

「同意の初期化」トリガーを使って、ページ表示前に同意ツールを起動することが最重要。

各タグに「同意設定」を適切に構成し、ユーザーの選択に応じた発火制御を行いましょう。

同意モードv2で追加された「ad_user_data」「ad_personalization」

記事内で触れている ad_storage / analytics_storage は、いわゆる同意モードv1の頃からある同意タイプです。その後、Google広告まわりでは新しく2つの同意タイプが加わりました。

• ad_user_data：ユーザーデータを広告目的でGoogleに送信してよいか
• ad_personalization：パーソナライズ広告（リマーケティング等）に利用してよいか

この2つを含めた実装が「同意モードv2」と呼ばれるもので、EEA（欧州経済領域）と英国のユーザーに対してGoogle広告の機能を使う場合、2024年3月以降は必須とアナウンスされています。対応していないと、EEA向けのリマーケティングリストへの追加や拡張コンバージョンなど、ユーザーデータを前提とした機能が使えなくなる、という位置づけです。

ここで見落としやすいのが、CMP側とGTM側の両方がv2に対応している必要があるという点。同意ツールのテンプレートが古いバージョンのままだと、ad_storage は連携されるのに ad_user_data は送られていない、という中途半端な状態が起こり得ます。導入済みのサイトでも、テンプレートのバージョンを一度確認しておくといいかなと思います。

なお、日本国内のみを対象にしたサイトについては、GDPRの直接の対象ではないため必須ではありません。ただ、越境で少しでもEEAからのアクセスがあるサイトや、海外向け広告を回す予定があるサイトなら、先に組んでおく方が後で慌てずに済むはずです。

「基本実装」と「詳細実装」で、拒否されたときの挙動が変わる

図2: 基本実装と詳細実装の違い

同意モードには実装方式が2種類あり、どちらを選ぶかで「同意を拒否されたユーザー」の扱いがかなり変わります。

基本実装（Basic Consent Mode） 同意を得るまでGoogleタグそのものを読み込ませない方式です。拒否した場合、タグは一切発火せず、Googleへのデータ送信もゼロになります。記事内のSTEP3で紹介している「同意が得られていない場合はタグを発火させない」設定は、この考え方に近い形です。

詳細実装（Advanced Consent Mode） タグ自体は最初から読み込み、同意状況をパラメータとして付けたうえで、拒否時にはCookieを使わない匿名のping（Cookieless ping）だけを送る方式です。個人を識別する情報は送られませんが、「拒否したユーザーがいた」という事実はGoogle側に伝わります。

この違いが効いてくるのがコンバージョンの計測です。詳細実装ではCookieなしのシグナルが残るため、Googleのコンバージョンモデリング（統計的な推定による補完）の対象になり得ます。基本実装ではそもそも信号が届かないので、拒否したユーザー分は素直に欠測になります。

プライバシー面で厳格に振るなら基本実装、計測精度を優先するなら詳細実装、という整理になるかと思います。どちらが正解というより、サイトの方針と法務判断次第の選択です。

実装後、正しく動いているかを確認する方法

プレビューで同意状態をひとつずつ確認

同意モードは「設定したつもりで動いていない」が起こりやすい領域なので、実装したら必ず挙動を確認したいところです。確認の切り口は主に3つあります。

1. GTMプレビューモードで同意状態を見る プレビューを起動すると、画面上部に「Consent」タブが表示されます。ここで各イベント時点の ad_storage や analytics_storage などが granted / denied のどちらになっているかを追えます。バナーで「拒否」を押したときにdeniedへ切り替わるか、「同意する」でgrantedへ変わるかを、実際にクリックしながら見ていきます。

2. ネットワークリクエストの gcs パラメータを確認する ブラウザの開発者ツール（Network）でGoogleへのリクエストを開くと、gcs というパラメータが付いています。これは同意状態を表す値で、G111 なら両方許可、G100 なら両方拒否、といった具合に読めます。v2の同意タイプについては gcd パラメータ側に含まれます。バナー操作前後でこの値が変わっていれば、同意情報がタグまで届いている証拠になります。

3. Google Tag Assistant / 各プロダクトの管理画面 Tag Assistantでも同意状態の確認ができますし、Google広告の管理画面には同意モードの実装ステータスを示す表示があります。「タグは動いているのに広告側で未実装扱いになっている」というケースは、CMPからの連携が抜けているサインだと考えられます。

あわせて見ておきたいのが発火順序です。同意情報が届く前にGA4のタグが走ってしまうと、実際には同意しているのにdenied扱いで送信される、といったズレが起きます。記事内で触れている「同意の初期化」トリガーでCMPを最速で起動させるのは、まさにこのズレを防ぐためのものになります。プレビューモードでは、CMPのタグが本当に一番上に来ているかまで見ておくと安心かなと思います。

CMPを使わずにコードで書く場合の「default」と「update」

GTMに対応したCMPを使うのが基本ですが、自社で作ったバナーを使っている場合や、どんな処理が裏で動いているのか理解しておきたい場合は、同意モードのコマンドそのものを知っておくと役に立つと思います。同意モードは、大きく分けて2つの命令で動いています。

• default：ページ読み込み時の初期状態を宣言する
• update：ユーザーがバナーで選んだあと、その内容に書き換える

gtag.jsで書くと、次のような形になります（値はあくまで例です）。

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>

バナーで「同意する」が押されたら、gtag('consent', 'update', {...}) で該当する項目を granted に変えます。

見落としやすいポイントは次の3つかなと思います。

• defaultはGoogleタグより前に実行する：順番が逆になると、初期状態が決まる前に計測が始まってしまいます。GTMで扱う場合は、上で紹介した「同意の初期化」トリガーで動かすのがこの位置にあたります
• wait_for_update：バナーの読み込みが遅いときに、タグがupdateを待つ時間（ミリ秒）です。短すぎると、同意したのにdeniedのまま送信される、ということが起こり得ます
• regionで地域ごとに初期値を変えられる：region パラメータに国コードを指定すると、「EEAと英国だけdeniedで始め、それ以外はgranted」のように分けられます。国内向けのサイトで、海外からのアクセスにだけ厳しめに対応したい場合に使える設定です

GTMのコミュニティテンプレートにも、このdefault / updateをGUIで設定できる同意モード用のテンプレートがあるので、コードを直接書くのに抵抗がある場合はそちらを検討してもいいかなと思います。

GTMの「同意の概要」で、タグごとの設定漏れを洗い出す

タグの数が多いコンテナでは、「どのタグに同意設定を入れたか」を1つずつ開いて確認するのはかなり手間がかかります。そこで便利なのが、GTMのコンテナ設定にある「同意の概要を有効にする」という項目です。

これをオンにすると、タグ一覧の画面に盾のようなアイコンが表示され、タグが次のように分類されて見えるようになります。

• 同意が未設定：まだ何も設定していないタグ
• 追加の同意は不要：同意状態を気にせず発火させてよいと明示したタグ
• 追加の同意が必要：特定の同意タイプがgrantedのときだけ発火するタグ

GA4やGoogle広告のタグには、もともと「組み込み同意チェック」が入っているので、追加設定をしなくても同意状態に合わせて動きます。気にしたいのはむしろ、Meta広告やヒートマップツールなど、Google以外のタグです。これらは組み込みチェックがないため、放っておくと同意を拒否されても発火してしまう可能性があります。

同意の概要画面では複数のタグをまとめて選んで同意設定を入れられるので、未設定のタグが残っていないか、一度通して確認しておくと安心かなと思います。

導入後、GA4やGoogle広告の数字はどう見えるか

同意モードを入れたあとに「ユーザー数が減った」「コンバージョンが落ちた」と感じるケースは少なくないと思います。これは設定ミスとは限らず、仕組みから見て自然に起きる変化であることも多いです。

GA4の場合 拒否したユーザーのデータは、基本実装なら届かず、詳細実装でもCookieなしのpingとして扱われるため、通常のユーザーとしてはカウントされません。詳細実装で一定の条件を満たすと、GA4の行動モデリングによって欠けた部分が推定で補われます。これを反映させるには、GA4の管理画面の「レポート用識別子」を「ブレンド」にしておく必要があります。条件（日数やイベント数の基準）はGoogleのヘルプに記載されているので、自分のプロパティが対象になるかは一度確認しておきたいところです。

Google広告の場合 詳細実装なら、コンバージョンモデリングで一部が補完される可能性があります。ただ、モデリングが反映されるまでには時間がかかることもあるので、導入直後の数字だけで判断しない方がいいかなと思います。

いずれにしても、導入前と導入後の数字をそのまま並べて比べないことが大事だと思います。比較するときは、同意モードを導入した日を注釈として残しておくと、あとから振り返るときに「施策やCRの影響なのか、計測の仕組みが変わった影響なのか」を切り分けやすくなるはずです。