2026/6/23
［ 初回公開日：
2026/6/23
］
【GTM×Cookiebot】Studio多言語サイトでCookie同意バナーを「正しく」制御する実装ガイド
⚠️ はじめに
「バナーは出ているのに、裏ではCookieが動いている」――この**"やってる風"が一番危ない**、というのが前編（戦略・判断編）の結論でした。本記事は、それを避けて正しく止めるためのGTM設定マニュアルです。
※本記事は実装の考え方の整理であり、法的助言ではありません。何がどこまで必要かは各社の事情で変わります。最終判断は必ず弁護士などの専門家にご相談ください。本記事の内容にもとづく対応について、当社は責任を負えません。
1. Studioでの実装の前提（公式手順との整合）
Studioでは、Studio単体ではCookie同意バナーは出せません。 これはStudioの公式ヘルプにも明記されています。CMP（同意管理プラットフォーム）をGoogleタグマネージャー（GTM）経由で導入します。
Studioが公式に手順を出しているのが Cookiebot です。
公式手順の流れ（要約）：
Cookiebotでアカウント作成（無料）
ドメインを登録
Domain Group ID をコピー
GTMで「Cookiebot CMP」テンプレートを追加し、IDを貼り付け
トリガーを「Consent Initialization」に設定
📌 補足：Studio公式ヘルプ自身も「GDPR・CCPA・個人情報保護法への準拠を保証するものではない」と明記しています。ツールを入れれば自動で合法になるわけではなく、何が必要かは自社で（専門家とともに）判断するのが前提です。
ここまでが土台。ここから「正しく止める」中身に入ります。
2. Google系と非Google系で、システムの動きはまったく違う
GTM経由で同意バナー（CMP）を入れたとき、ブラウザの裏側では「バナー管理人（CMP）」と「コントロールタワー（GTM）」が連携しています。そして通信の流れは、**Google系タグ（GA4・Google広告）**と、**それ以外の非Google系タグ（Microsoft Clarity・HubSpot・各種SNSピクセル等）**で、完全に分かれます。ここが実装で一番つまずくポイントです。
時系列で見る、ページが開いてからの流れ
Step 1｜ページ読み込み開始（GTMが最初に起動） ユーザーがアクセスした瞬間、GTMが最優先で「同意の初期化（Consent Initialization）」を走らせます。
Step 2｜まずは一律「拒否」を宣言 バナーが画面に出る前に、CMPがGTMへ「この人は新規訪問者。まだ何も押していないので、初期状態は**すべて拒否（denied）**で扱って」と伝えます（サイト表示に必須の security_storage だけは例外的に許可）。
Step 3｜各タグの読み込み ― ここで運命が分かれる
A. Google系（GA4・Google広告） Google系には「Google Consent Mode（同意モード）」という通信のしくみが最初から備わっています。「今は拒否状態」というデータを受け取ると、タグ自体は動くが、Cookieは1つも書き込まず、Cookieを使わない匿名の信号（pings）だけをGoogleへ送ります。＝賢く自制してくれる。
B. 非Google系（Clarity・HubSpot・SNSピクセル等） これらには、その「賢さ」がありません。GTMが「今は拒否状態」と言っていても理解できないため、設定次第で挙動が変わります。
❌ 間違った設定（"やってる風"）：拒否状態を無視して、ページが開いた瞬間に勝手にCookieを書き込み、通信を始めてしまう。バナーは出ているのに裏で動いている、という最悪の状態。
⭕ 正しい設定（GTMの「追加の同意」を設定済み）：GTMがタグの実行直前で「待った」をかけ、同意が出るまでタグを完全フリーズ（保留）。Cookieも通信も発生しません。
Step 4｜ユーザーがボタンを押す（確定）
「すべて同意」を押した：CMP→GTMへ「許可（granted）」が通知され、Google系は通常のCookie計測に切り替わり、保留していた非Google系タグも一斉に発火します。
「拒否」を押した：Google系は匿名信号（pings）だけを送り続け（Cookieは作らない）、非Google系は最後まで一切動きません。
まとめ（挙動の違い）
タグの種類 | 同意前の挙動 | 拒否時の挙動 |
|---|---|---|
Google系（GA4 / Google広告） | タグは動くが、Cookieは作らず匿名信号（pings）だけ送る | 匿名信号の送信を継続（モデリングに利用）。Cookieは作らない |
非Google系（Clarity / HubSpot等） | GTMの「追加の同意」でタグの実行そのものをフリーズ | 最後まで起動しない。Cookieも通信もゼロ |
💡 大企業がConsent Modeを徹底するのは、Google系タグを「完全に止める（Basicモード）」のではなく、「Cookieなしの匿名状態で動かし続ける（Advancedモード）」ことで、法令を守りつつ"取りこぼし"をAIの推定（モデリング）で補えるからです。一方、非Google系はGTM側で明示的に止めない限り暴走する――これが実装上いちばん重要な注意点です。
3. 落とし穴を塞ぐ ― 「追加の同意チェック」の設定方法
では、非Google系タグの暴走をどう止めるか。GTMの各タグの設定で「Require additional consent for tag to fire（タグ発火に追加の同意を必要とする）」を仕込みます。
以下は、IT+が自社サイトで実装した Microsoft Clarity の設定画面です。
ポイントは3つ：
Tag Type：Clarityのトラッキングコード（Custom HTML）。
Triggering（一番下）：
All Pages（全ページ）になっている。＝放っておくとページが開いた瞬間に動く。Consent Settings (BETA)：
Require additional consent for tag to fire→analytics_storageを指定。
この3番目が"鍵"です。トリガーが全ページでも、GTMは「このClarityタグは analytics_storage（統計用Cookie）の許可が出るまで動かしてはいけない」と判断し、ユーザーが同意するまでClarityのコードを1文字も実行しません。
実装するときは、この「追加の同意」を外部ツールの数だけ（Clarity・HubSpot・Metaピクセル等）、1つずつ丁寧に仕込みます。「どのタグに、どの同意（
analytics_storageかad_storageか…）が必要か」を明示的に紐付ける。これをして初めて、**「法的に嘘のない同意バナー」**が完成します。
4. バナーの「4つのボタン」とGTM変数の対応
Cookiebotのバナーに並ぶ4つのトグル――Required / Preferences / Statistics / Marketing。これらは見た目だけのものではなく、裏側でGTMの「同意タイプ（Consent Types）」という変数と1対1で連動しています。ユーザーがトグルをON/OFFすると、対応する変数が granted（許可）/ denied（拒否）にリアルタイムで書き換わります。
対応表（Cookiebot公式の既定マッピング）
バナーの表記 | 連動するGTMの同意タイプ | 意味・目的 | 該当ツールの例 |
|---|---|---|---|
Required（必須） |
| サイトを正しく・安全に表示するために必須 | Studioの基本システム、reCAPTCHA等のセキュリティ、ECの「カート維持」 |
Preferences（機能性） |
| 言語・表示などユーザーの選択を記憶 | 多言語切替（WOVN等）、チャットボット、ダーク/ライトモードの記憶 |
Statistics（統計） |
| アクセス数・サイト内行動の計測・分析 | GA4、Microsoft Clarity、HubSpotのアクセス解析 |
Marketing（マーケティング） |
| 広告配信・リマーケ・成果（コンバージョン）計測 | Google広告、Metaピクセル、LINE広告、HubSpotの広告・メール追跡 |
⚠️ よくある間違い①：第2章でも触れた
functionality_storageは Preferences（"必須"ではありません）。security_storageだけがRequiredに入り、既定で許可されます。 ⚠️ よくある間違い②：Marketingはad_storageだけに紐づけないこと。ad_user_data・ad_personalizationも合わせて紐付けないと、拡張コンバージョンやオーディエンス配信が静かに壊れます。
どこで設定しているのか（2か所の連携）
Cookiebot側＝Cookieの自動仕分け：Cookiebotに自社ドメインを登録するとロボットが自動スキャンし、「これはGA4だからStatistics」「これはMetaピクセルだからMarketing」と、各Cookieを4カテゴリに自動で振り分けます。
GTM側＝鍵の割り当て：ユーザーがバナーで「Statisticsを許可」すると、Cookiebot→GTMへ信号が飛び、第3章で設定した「追加の同意（
analytics_storage）」の条件が満たされて、ClarityやGA4が初めて発火します。
つまり「バナーのStatisticsボタン」＝「GTMの analytics_storage という鍵」。この鍵を各タグに前もって指定しておくことで、ボタンがONになったときだけ、正確にタグが起動する――という制御になります。
5. まとめ ― 実装後に必ずやる「検証」
実装は、設定して終わりではありません。**「本当にEUからだけバナーが出るか」「同意前にタグが止まっているか」**を、自分の目で確かめます。IT+が実際に行った検証手順です。
※これは検証の一例です。法的リスクがありますので、必ず法務担当者やエンジニアの方と自社として必要な検証が必要になります。
キャッシュを使わない状態で見る：シークレットウィンドウ or 新規プロファイル（CDN/ブラウザのキャッシュが残ると古い挙動を見てしまう。公開後はCDNのキャッシュをパージしてから）。
トラッカーブロック系の拡張機能はオフにして検証する（広告ブロッカー等が動いていると、タグが拡張機能側で止められ、CMPの挙動と切り分けできなくなる）。
地域の出し分けを確認：VPN（例：ロンドンに接続）でEU圏からのアクセスを再現し、英語ページでバナーが出ること／日本からのアクセスでは出ないこと（geo-targetingを使う場合）。
Google系の同意状態を確認：同意前は
gcs=G100（denied）、「すべて同意」後にgcs=G111（granted）へ変わること（ネットワークログのGoogleタグ送信で確認）。非Google系がフリーズしているか確認：同意前に、ブラウザのネットワークタブでClarityやHubSpotの通信が発生していないこと。同意後に初めて発火すること。
計測が継続しているかの確認：（geo＋国内ノーゲートの構成なら）日本からの通常アクセスでGA4/Clarityが計測できているか。
この検証まで通して初めて、「やってる風ではない、正しく動く同意バナー」と言えます。
関連記事
多言語Studioサイトの「Cookie同意バナー」、どこまでやる？ ― 中小企業のための現実的な考え方 ― 本記事の前編（戦略・判断編）。そもそもどこまでやるべきか、費用、EU市場との関係。
※掲載のツール名・画面・仕様は2026年6月時点のものです（GTMの「追加の同意」はBETA機能。UI・仕様は変わります）。最新は各サービスの公式情報をご確認ください。 ※本記事は法的助言ではありません。具体的な対応は弁護士等の専門家にご相談ください。
この記事を書いた人
