Google Tag Manager に CMP（Cookie同意管理プラットフォーム） を導入する手順

CMP導入後にアクセス数や広告の計測値が変わったとき、実際の行動変化と設定による欠損・二重送信を区別できないと、施策の評価を誤るおそれがあります。この記事では、同意状態に応じたタグ制御と、意図どおりに計測されているかの確認手順を説明します。

CMP を入れる作業の大半は、バナーの設定ではなく、Google Tag Manager（GTM）の中で起きます。どのタグを、どの同意で、いつ動かすか。ここを決めて作り込まないと、バナーは出ているのに同意前にタグが動く、あるいは同意したのに計測されない、という状態になります。

この記事では、GTM 側の作り方を、次の順で説明します。

1. 先に決めること（オプトインかオプトアウトか、拒否された時に Google へ送信するか）
2. タグの棚卸しと、「同意の初期化」に置くタグ
3. タグごとの同意設定
4. CMP が送るイベントを使って、同意の後に page_view と各タグを動かす方法
5. 確認の方法（gcs の読み方を含む）

先に決めること：オプトインか、オプトアウトか

同意の取り方には、2つの方式があります。

どちらを採るかは、GTM の作業の前に決めます。決め手は、訪問者がいる地域の法律と、会社の方針です。以下は一般的な整理です。法的な助言ではありません。自社への当てはめは、法務の担当者や弁護士に確認してください。

この表は、2026年9月時点の一般的な整理です。各地域の法律は改正が続いています。最新の内容は、一次情報で確認してください。

法令に関する注記： この表は実装方針を考えるための一般的な説明であり、個別のサイトへの適法性を保証するものではありません。対象地域、取り扱う情報、事業の内容によって要件は異なります。適用される法令・施行状況の最新情報を各当局の一次情報で確認し、実際の対応は法務担当者や専門家にご確認ください。

Google の広告と計測の機能を EEA・英国の利用者に使う場合は、法律とは別に、Google の「EU ユーザーの同意ポリシー」が同意の取得を求めています。2024年3月以降は、同意モード（v2）で同意状態を Google に渡していないと、EEA の利用者についてリマーケティングなどの機能が使えません。

会社の方針は、おおむね次の3通りに分かれます。

出し分けは、CMP が訪問者の国を判定して行います。GTM 側の作りは、どの方針でも同じです。この記事の手順で作ると、地域ごとの違いは次の2か所だけで吸収されます。

• 同意のデフォルト設定（手順2）を、地域ごとに変える。オプトインの地域は denied、オプトアウトの地域は granted。
• CMP が、その地域の方式に従って同意状態を更新する。

オプトアウトの地域では、ページを開いた時点で「計測してよい状態」になっているので、page_view はすぐに送られます。以下の説明は、作り込みが多いオプトインを中心に進めます。

もう1つ決めること：拒否された時に、Google へ何も送らないか

Google のタグは、同意モードを使っていると、利用者が拒否した場合でも止まりません。Cookie を読み書きしない形に切り替わり、イベントそのものは Google へ送信されます。Google はこの動作を「高度な同意モード」と呼んでいます。送られたデータは、Google 側での推計（モデリング）に使われます。

会社の方針として、拒否された時はイベント自体を送りたくない場合があります。「拒否したのに通信が出ている」という状態を避けたい場合です。この場合、Google のタグも、非 Google のタグと同じように、同意が無い間は発火させない作りにしなければなりません。Google はこちらを「基本的な同意モード」と呼んでいます。

どちらにするかで、手順3の設定、手順7の止め方、手順8の確認の見方が変わります。GTM の作業の前に決めてください。

完成形

オプトインの地域で、ページを開いてから page_view が送られるまでの順序です。

保存済みの選択がある再訪者は、3 を飛ばして、読み込みの直後に 4〜6 が起きます。

手順1：タグを棚卸しする

トリガーに手を付ける前に、コンテナの全タグが「どのサービスのタグか」を一覧にします。後の手順は、すべてこの一覧を根拠に決めます。

判別は次の順で行います。

1. タグの種類を見る。組み込みのタグは、これで確定します。
2. カスタムテンプレートのタグは、テンプレートの定義を見る。テンプレートの名前とブランド名で、サービスを特定します。
3. カスタム HTML は、必ず本文を読む。送信先のドメインと、グローバル変数の名前で判定します。

コンテナをエクスポートした JSON では、タグの種類は type に入っています。

カスタム HTML の本文で見るドメインの例です。

一覧には、タグ名、種類、サービス、分類に加えて、判別根拠の列を必ず作ります。「種類が GA4 イベント」「本文に connect.facebook.net」のように、何を見てそう判断したかを書きます。

タグ名やトリガー名だけで判断しないでください。実際にあった例では、「トップページ」という名前のトリガーが、全ページで発火していました。名前は、作られた当時の意図を表しているだけです。

判定できなかったタグは「不明」として残し、人が本文を読んで決めます。dataLayer の加工や DOM の操作だけを行うタグは、同意の対象外です。

手順2：「同意の初期化」で動かす2つのタグを置く

次の2つのタグを、「同意の初期化 – すべてのページ」トリガーで動かします。このトリガーは、他のどのトリガーよりも先に発火します。

同意のデフォルト設定には、コミュニティ テンプレート ギャラリーの同意モード用テンプレートが使えます。オプトインの地域の設定は次のとおりです。

地域で方式を出し分ける場合は、Regions を変えたデフォルト設定を、もう1つ追加します。オプトアウトの地域には、granted のデフォルトを設定します。Regions を空にした設定は、どの地域の指定にも当てはまらない訪問者に適用されます。

確認する点が2つあります。

• CMP のタグが「初期化 – すべてのページ」に置かれていないか。「同意の初期化」と「初期化」は、名前が似ていますが別のトリガーです。「初期化」は、「同意の初期化」の後に発火します。既存のコンテナで、CMP のタグが「初期化」で動いている例がありました。
• 2つのタグの順序。同じトリガーで動くタグの順序は保証されません。デフォルト設定のタグに、CMP のタグより大きい「タグ配信の優先度」を付けて、先に動くことを明示します。

手順3：タグごとの同意設定を決める

GTM のタグには「同意設定」があります。タグの編集画面の「詳細設定」の中です。棚卸しの分類に従って、次のように設定します。

Google のタグは、同意状態に応じて自分の動作を変える仕組み（組み込みの同意チェック）を持っています。同意が無ければ、Cookie を読み書きせずに送信します。高度な同意モードでは、この仕組みに任せるので「追加同意は不要」にします。非 Google のタグにはこの仕組みがないので、GTM に止めさせます。

拒否された時にイベント自体を送りたくない場合は、Google のタグも「追加同意は不要」のままにしてはいけません。組み込みの同意チェックは、Cookie を使わない形に切り替えるだけで、送信は止めないからです。表の右の列のとおり、Google のタグにも「追加同意が必要」を設定し、非 Google のタグと同じように GTM に止めさせます。Google タグ（設定のタグ）、GA4 イベント、Google 広告の各タグの、すべてが対象です。1つでも「追加同意は不要」のまま残っていると、そのタグだけは拒否された時にも送信します。

エクスポートした JSON では、次の形になります。

"consentSettings": {
  "consentStatus": "NEEDED",
  "consentType": {
    "type": "LIST",
    "list": [{ "type": "TEMPLATE", "value": "ad_storage" }]
  }
}

「追加同意は不要」は "consentStatus": "NOT_NEEDED"、未設定は "NOT_SET" です。

「追加同意が必要」の動作には、注意が要ります。Google の公式ヘルプは、「タグがトリガーされた時点で、指定した同意タイプがすべて granted の場合にのみ配信される」と説明しています。トリガーが来た時に同意が無ければ、そのタグは配信されません。後から同意が与えられても、自動では配信されません。ページの読み込みで動くタグは、同意の後に来るイベントで発火させる必要があります（手順5、手順6）。

前提知識：GTM の「イベント」と、CMP が送るイベント

手順4から先は、GTM の「イベント」の考え方を使います。先に整理しておきます。

GTM のトリガーは、すべて「イベント」を待っています。ページの読み込みも、クリックも、GTM の内部ではイベントです。プレビュー画面の左側に並ぶ「Container Loaded」「Click」などが、それです。トリガーとは、「このイベントが、この条件で起きたら」という指定です。

イベントは、GTM が用意したものだけではありません。ページ側のスクリプトが、次のコードで自分の名前を付けたイベントを起こせます。

window.dataLayer.push({ event: 'イベントの名前' });

これを、トリガーの種類「カスタム イベント」で待ち受けます。イベントの名前は、決まった単語ではなく、起こす側が自由に付けた文字列です。

CMP は、この仕組みで GTM に合図を送ります。「CMP の準備ができた」「同意状態が変わった」といった合図を、CMP が決めた名前のイベントとして push します。GTM 側は、その名前をカスタム イベント トリガーに書いて待ち受けます。名前は CMP ごとに違うので、手順4で調べます。

手順4：自分の CMP が GTM に何を渡すかを調べる

ここから先は、CMP が GTM に何を渡すかで、作り方が分かれます。CMP の管理画面やドキュメントで、次の2点を調べます。

1. 同意状態を同意モードに反映する機能があるか。あれば、手順3の同意設定が働きます。
2. どんな名前のイベントを、いつ push するか。同意状態が dataLayer の変数に入る場合は、その変数の名前も調べます。

実際に push される内容は、ブラウザで確認できます。コンソールで dataLayer と入力して中身を見るか、GTM のプレビューで、左側のイベント一覧と「データレイヤー」タブを見ます。初回訪問（同意 Cookie を削除した状態）と、同意した後の再読み込みの両方で確認してください。見る点は、イベントが「CMP の準備ができた時」に来るのか、「利用者が選択した時」に来るのかです。

page_view の起点に使えるのは、利用者が同意を選択した後（保存済みの選択がある場合は、その選択が読み込まれた後）に来るイベントです。

公開されているドキュメントから、2つの製品のイベントを例に挙げます。

実際の発火については、ご自身のサイトでご確認ください。 CMP の設定やバージョンによって、イベントが発生するタイミングは異なる場合があります。特に OneTrustGroupsUpdated は、初回訪問・同意の選択後・保存済みの選択がある再訪・同意変更時のそれぞれで、GTM プレビューのイベントと同意状態、実際の送信を確認してください。

カテゴリ ID は、CMP の管理画面で確認します。OneTrust の標準では、C0002 がパフォーマンス（解析）、C0004 がターゲティング（広告）です。

例2のように、見つかったイベントが「準備完了」だった場合は、それとは別に、同意の変更を通知するイベントが無いかを、CMP のドキュメントとサポートで確認します。

手順5：page_view を、同意を選択した後に1回だけ送る

page_view の起点には、CMP が同意の変更後に発生させるカスタム イベントを使います。以下は、イベントと一緒に「許可されたカテゴリ」が dataLayer に渡される CMP の例です。

まず、許可されたカテゴリを読む変数を作ります。

次に、トリガーを作ります。

カテゴリ ID の前後のカンマまで、条件に含めます。C0002 だけだと、C00021 のような別の ID にも一致します。

GA4 の page_view を送るタグは、このトリガーだけで発火させます。「All Pages」は外します。広告用には、,C0004, を条件にしたトリガーを同じ形で作ります。

CMP が同意モードの同意状態だけを更新し、許可されたカテゴリを dataLayer に渡さない場合は、条件の代わりに、タグの同意設定（手順3）で制御します。

呼び出しオプションは「1ページにつき1度」にする

page_view を送るタグの呼び出しオプションは、「1ページにつき1度」にします。利用者が同じページで設定を変え直すと、同意変更のイベントがもう一度来て、page_view が二重に送られるためです。

動作は次のようになります。

SPA のサイトでは動作確認が要る

SPA（画面が切り替わっても、ページが再読み込みされないサイト）でも、同意後に page_view を送る考え方は同じです。CMP が同意の変更後に発生させるカスタム イベントを使います。

ただし、「1ページにつき1度」の「1ページ」は、ページの読み込み1回を指します。SPA では、画面が切り替わってもページは読み込み直されません。そのため、呼び出しオプションを「1ページにつき1度」にすると、page_view が最初の画面でしか送られないケースがあります。SPA のサイトでは、画面を2つ3つと進めて、画面ごとに page_view が送られるかを必ず確認してください。

page_view を送っているタグを漏らさない

page_view を送るのは、GA4 イベントのタグだけではありません。

send_page_view を指定していない Google タグは、既定で page_view を送ります。見落としやすいので、棚卸しの一覧に列を足して確認します。

Google タグと GA4 イベントのタグの両方が page_view を送る設定になっていると、二重に送られます。どちらが送るのかを決めて、もう一方を止めます。

手順6：ページビュー系のトリガーを付け替える。例外も一緒に

page_view 以外にも、ページの読み込みで動くタグがあります。広告のベースコードやヒートマップなどです。これらも、手順5で作ったトリガー（CMP の同意変更のイベントを待つトリガー）へ付け替えます。

「特定のページだけ」のような条件を持つトリガーは、条件を引き継いだ専用のトリガーを作ります。名前は「同意変更 – 元のトリガー名」のようにして、同じ条件のものは共用します。

例外（ブロック）のトリガーも、同じイベントへ付け替えます。GTM の例外は、タグが発火するイベントと同じイベントの上で評価されて、初めて効きます。

例を挙げます。あるタグが「All Pages」で発火し、例外に「SPA の画面（ページビュー型のトリガー）」を持っているとします。発火トリガーだけを同意変更のイベントのトリガーに付け替えると、タグは同意変更のイベントで発火します。ところが、例外はページビューのイベントでしか評価されません。結果として、例外は一度も効かなくなります。エラーは出ません。

発火と例外の両方を、同じイベントのトリガーに揃えてください。

手順7：クリックなどで動くタグを止める

対象は、非 Google のタグです。拒否された時に何も送らない方針（基本的な同意モード）の場合は、クリックなどで動く Google のタグ（GA4 イベント、Google 広告のコンバージョンなど）も、同じ方法で止めます。

クリックやスクロールで動くタグは、トリガーを変えません。止め方は、CMP の同意状態の渡し方によって違います。

• CMP が同意モードの同意状態を更新する場合。手順3の同意設定（追加同意が必要）で止まります。クリックした時点で同意が無ければ、タグは配信されません。
• CMP が許可カテゴリを dataLayer に渡すだけの場合。例外トリガーを追加します。

例外トリガーは、次の形にします。

イベント名を .* にして、すべてのイベントに一致させるのが要点です。理由は手順6と同じです。例外をページビュー型のトリガーで作ると、クリックやカスタム イベントで発火するタグを止められません。

手順8：確認する

公開の前に、GTM のプレビューで確認します。プレビューは、GTM の画面右上の「プレビュー」から入ります。Tag Assistant の「ドメインを追加」から入ると、公開済みのコンテナを検証することになり、未公開の変更は反映されません。

確認する項目です。

• 同意 Cookie を削除して再読み込みし、初回訪問の状態から始める。
• 未選択の間は、page_view も非 Google のタグも配信されていない。
• 同意した後、同じページで page_view が1回だけ送られる。
• 同じページで設定を変え直しても、2回目が送られない。
• 次のページへ進み、page_view が1回だけ送られる。
• すべて拒否した場合、非 Google のタグは「配信されなかったタグ」に入っている。
• 例外を持つタグ（SPA の除外など）が、付け替えの後も除外されている。
• SPA のサイトでは、画面を進めるごとに page_view が送られる。

Google のタグは gcs の値で確認する

非 Google のタグは、配信されたかどうかで判定できます。Google のタグは違います。同意モードを使っていると、同意が無くてもタグは配信され、Cookie を使わない形で送信されます。「配信された」だけでは、同意が正しく伝わったかが分かりません。

そこで、実際に送られたリクエストの gcs を見ます。gcs は、Google のタグがリクエストに付けるパラメータで、送信した時点の同意状態を表します。

見方は次のとおりです。

1. ブラウザの開発者ツールで「ネットワーク」タブを開く。
2. フィルタに collect と入力する。GA4 のリクエスト（google-analytics.com/g/collect）が残る。
3. リクエストを選び、ペイロード（クエリ文字列）の gcs を見る。イベントの名前は en に入っている。en=page_view のリクエストを探す。複数のイベントがまとめて送られた場合、en はリクエストの本文側に入る。

値は G1 の後に数字が2つ続きます。1つ目が ad_storage（広告）、2つ目が analytics_storage（解析）です。1 が granted、0 が denied です。

gcs が付いていないリクエストは、同意モードが働いていない状態で送られています。GTM を通さずにページへ直接書かれた計測タグが、残っている可能性があります。

この記事の設計での、正しい値は次のとおりです。

高度な同意モードでは、G100 のリクエストがあること自体は、不具合ではありません。拒否した利用者がボタンを押せば、そのイベントは G100 で送られます。見るべきなのは、「利用者の選択と gcs が合っているか」と、「page_view が同意の前に送られていないか」の2点です。

拒否された時に何も送らない方針（基本的な同意モード）では、見方が変わります。拒否した状態と未選択の状態で、Google へのリクエストが1件も出ていないことを確認します。G100 のリクエストが1件でもあれば、「追加同意は不要」のまま残っている Google のタグがあります。解析だけを拒否した状態なら、GA4 のリクエストが出ていないことを確認します。Tag Assistant では、そのタグが「配信されなかったタグ」に入っています。

同意モード v2 で加わった ad_user_data と ad_personalization は、gcs には入りません。別のパラメータ gcd に入りますが、書式は Google が公式には説明していません。この2つは、Tag Assistant でイベントを選び、「同意」タブで確認するのが確実です。デフォルトの値と、更新後の値が、項目ごとに表示されます。

この設計で変わる数字

page_view を同意の選択後に送る設計にすると、オプトインの地域では、導入の前後で数字の意味が変わります。導入の前に、関係者へ伝えておくことを勧めます。

• バナーを選択しないまま離脱した訪問と、拒否した訪問は、計測されません。page_view が1件も送られないためです。ページビュー数とセッション数は、導入前より減ります。減った分は、訪問が減ったのではなく、計測の対象から外れた分です。
• 同意した訪問は、1ページ目から計測されます。ランディングページと流入元（utm_*、リファラー、クリック ID）は、1ページ目のものが記録されます。
• 同意前に page_view を送る設計では、ここがずれます。同意前のヒットは Cookie を持ちません（gcs=G100）。同意の後にイベントを送らなければ、Cookie を持つ最初のヒットは2ページ目になります。ランディングページは2ページ目として記録され、1ページ目にしか無い流入元の情報は、セッションに付きません。この記事の設計を採る理由は、これです。

オプトアウトの地域では、ページを開いた時点で送られるので、この変化は起きません。

チェックリスト

• オプトインかオプトアウトかを、地域ごとに決めた。法務の確認を取った
• 拒否された時に Google へ何も送らない方針かどうかを決めた。送らない方針なら、Google のタグもすべて「追加同意が必要」にした
• 全タグの棚卸し一覧があり、判別根拠の列が埋まっている
• 同意のデフォルト設定と CMP のタグが「同意の初期化」で動き、優先度で順序を明示している
• 地域ごとのデフォルト設定が、決めた方式どおりになっている。security_storage が意図した値になっている
• タグごとの同意設定が、棚卸しの分類どおりになっている
• CMP のイベントが「準備完了」か「同意の変更後」かを、初回訪問と再訪の両方で確認した
• page_view を送るタグ（send_page_view が未指定の Google タグを含む）が、同意後のトリガーだけで発火する
• page_view を送るタグが「1ページにつき1度」になっている。SPA のサイトでは、画面ごとに送られることを確認した
• 発火トリガーを付け替えたタグの例外も、同じイベントへ付け替えた
• クリック系の非 Google タグが、拒否した状態で配信されない
• page_view の gcs が G101 か G111 だけになっている。何も送らない方針なら、拒否と未選択の状態で Google へのリクエストが出ていない
• 導入後に数字がどう変わるかを、関係者に伝えた