Studio多言語サイトでCookie同意バナーを「正しく」制御する実装ガイド GTM×Cookiebot : Cookie同意バナー【後編】

⚠️ はじめに

「バナーは出ているのに、裏ではCookieが動いている」――この**"やってる風"が一番危ない**、というのがCookie同意バナー【前編】（戦略・判断編）の結論でした。本記事は、それを避けて正しく止めるためのGTM設定マニュアルです。

※本記事は実装の考え方の整理であり、法的助言ではありません。何がどこまで必要かは各社の事情で変わります。最終判断は必ず弁護士などの専門家にご相談ください。本記事の内容にもとづく対応について、当社は責任を負えません。

1. Studioでの実装の前提（公式手順との整合）

Studioでは、Studio単体ではCookie同意バナーは出せません。 これはStudioの公式ヘルプにも明記されています。CMP（同意管理プラットフォーム）をGoogleタグマネージャー（GTM）経由で導入します。

Studioが公式に手順を出しているのが Cookiebot です。

• 📄 Cookiebot を利用して Cookie 利用の同意モーダルを実装する | Studio Help

公式手順の流れ（要約）：

1. Cookiebotでアカウント作成（無料）

2. ドメインを登録

3. Domain Group ID をコピー

4. GTMで「Cookiebot CMP」テンプレートを追加し、IDを貼り付け

5. トリガーを「Consent Initialization」に設定

↓　GTMに「Cookiebot CMP」テンプレートを追加し、Consent Initializationで発火させる

📌 補足：Studio公式ヘルプ自身も「GDPR・CCPA・個人情報保護法への準拠を保証するものではない」と明記しています。ツールを入れれば自動で合法になるわけではなく、何が必要かは自社で（専門家とともに）判断するのが前提です。

Cookiebotの自動分類と「未分類」の手当て（IT+の実例）

Cookiebotはサイトをスキャンして、各Cookieを自動で4カテゴリ（必須／機能性／統計／マーケティング）に振り分けます。GA4・Google広告・Microsoft Clarity・YouTube などよく知られたタグは自動で正しく分類されます。ただし、新しい・ツール固有のCookieはデータベースに無く「未分類（Unclassified）」として残り、人が手で分類する必要があります（未分類のままだとブロックもされません）。

実際、IT+の英語サイトをスキャンしたら 49個中4個が未分類でした。中身を見て、こう分類しました（Studio＋Weglotの組み合わせなら同じCookieが出るはずなのです。バナーは英語表示なので説明も英語で入れます）

↓　Cookiebotスキャン結果。49個中4個が未分類（Studio・Weglotのcookie）

↓　「未分類（Unclassified）」を各Cookieを自動で4カテゴリ（必須／機能性／統計／マーケティング）に振り分ける

↓　そのタグの目的の説明

ポイントは2つ。①明らかなものは業界の定番どおり（解析＝Statistics、言語＝Preferences 等）。②"どちらか迷う"ものは自社で判断します。判断の鉄則は 「迷ったら必須（Necessary）に入れない」＝必須は"無いとサイトが壊れるもの"だけにし、追跡系を必須に入れて同意を回避しないこと（最終判断は専門家へ）。

ここまでが土台。ここから「誰に出すか」と「正しく止める」中身に入ります。

2. 「誰に出すか」を絞る ― 英語ページ × EU圏32カ国

公式手順そのままだと、バナーは全ページ・全地域に出ます。IT+では、費用と実務のバランスから「英語ページに来た、EU圏の人だけ」に絞っています。これは (1)ページの絞り込み と (2)地域の絞り込み という、2段階の設定です。

(1) 英語ページだけに出す ― 発火条件を絞る

⑤の「Consent Initialization」トリガーに、「英語の部分のときだけ発火する」条件を加えます（または英語限定のトリガーを用意します）。やり方は多言語の構成で2通り：

• 英語が別アドレス（en.example.com のようなサブドメイン）の場合：条件を「ホスト名（Page Hostname）が英語アドレスのとき」にする。

• 英語が同じアドレス内のフォルダ（example.com/en/ のようなサブディレクトリ）の場合：条件を「URLのパスに /en/ を含むとき」にする（同じホスト名なので、ホスト名条件では英語だけを切り出せないため）。

↓　英語ドメインのときだけ発火する条件を付ける（IT+の例＝ホスト名で判定）

(2) EU圏（32カ国）だけを対象にする ― 地域の設定

英語ページに絞ったうえで、さらに「EU圏の人だけ」を対象にします。ここは2つの設定が別の仕事をしています。

① タグを止める対象を地域で決める（GTM・無料・ここが本体） GTMのConsent Modeで、地域ごとの初期状態を設定します。

• その他の地域（global）＝ granted（許可）：日本などからのアクセスはタグが普通に動く。

• EU圏32カ国＝ denied（拒否）：同意するまでタグを止める。

この「32カ国」は EU/EEA（30）＋ イギリス（GB）＋ スイス（CH）。実際の国コードを1つずつ指定します（"EEA27+GB+CH" と文字で書くのではなく、下記コードを入力）：

AT, BE, BG, HR, CY, CZ, DK, EE, FI, FR, DE, GR, HU, IE, IT, LV, LT, LU,
MT, NL, PL, PT, RO, SK, SI, ES, SE, IS, LI, NO, GB, CH

↓　その他＝許可／EU圏32カ国＝拒否（同意まで停止）

なぜイギリス・スイスも入れるのか：オプトイン同意が法的に求められるのはEU/EEAだけでなく、イギリス（PECR）、さらに広告・クロスサイトのトラッキングCookieについては**スイス（FDPICの2025年ガイドライン）**も該当するため。"流入が多い国"ではなく"オプトイン同意が要る国"で線を引いています。

② バナーを見せる地域を絞る（Cookiebot・有料・任意） バナーの表示自体もEU圏だけにしたい場合は、Cookiebot側の地域設定（geo-targeting＝Premium機能）で同じ32カ国を選びます。無料のままなら、バナーは英語ページの訪問者全員に出ます（①でEU圏のタグは止まっているので、これでも筋は通ります）。

⚠️ 実務の落とし穴：Cookiebotの地域選択で、キプロス（Cyprus）は「Europe」ではなく「Asia ＞ Western Asia」の下にあります。EU/EEAだけのつもりでも1カ国漏れやすいので注意。

↓　「EU and EEA only」という選択はあるのですが、それだと今回の対象となる32カ国は入っておらず、「EU and EEA only」+ UK + スイス という選択をするためには1つずつチェックが必要でした・・・w

つまり「どのページに出すか（発火条件）」「どの地域のタグを止めるか（GTMのConsent Mode・無料）」「どの地域にバナーを見せるか（Cookiebotのgeo・有料）」は、それぞれ別レイヤーの設定です。

3. Google系と非Google系で、システムの動きはまったく違う

「誰に出すか」を絞ったら、次は「同意するまで、本当にタグが止まっているか」。ここで、通信の流れは Google系タグ（GA4・Google広告） と 非Google系タグ（Microsoft Clarity・HubSpot・各種SNSピクセル等） で完全に分かれます。実装で一番つまずくポイントです。

↓　同意前後のタグの動き（Google系と非Google系）

時系列で見る、ページが開いてからの流れ

Step 1｜ページ読み込み開始（GTMが最初に起動） ユーザーがアクセスした瞬間、GTMが最優先で「同意の初期化（Consent Initialization）」を走らせます。

Step 2｜まずは一律「拒否」を宣言 バナーが画面に出る前に、CMPがGTMへ「初期状態はすべて拒否（denied）で扱って」と伝えます（サイト表示に必須の security_storage だけは例外的に許可）。

Step 3｜各タグの読み込み ― ここで運命が分かれる

• A. Google系（GA4・Google広告） 「Google Consent Mode」というしくみが最初から備わっています。「今は拒否」と受け取ると、タグ自体は動くがCookieは1つも書き込まず、Cookieを使わない匿名の信号（pings）だけをGoogleへ送ります。＝賢く自制する。

• B. 非Google系（Clarity・HubSpot・SNSピクセル等） その「賢さ」がありません。GTMが「今は拒否」と言っても理解できないため、設定次第で挙動が変わります。

• ❌ 間違った設定（"やってる風"）：拒否を無視し、ページが開いた瞬間に勝手にCookieを書き込み、通信を始めてしまう。

• ⭕ 正しい設定（「追加の同意」を設定済み）：GTMが実行直前で「待った」をかけ、同意が出るまでタグを完全フリーズ。Cookieも通信も発生しません。

Step 4｜ユーザーがボタンを押す（確定）

• 「すべて同意」：Google系は通常のCookie計測に切り替わり、保留していた非Google系も一斉に発火。

• 「拒否」：Google系は匿名信号（pings）だけを送り続け、非Google系は最後まで動きません。

💡 大企業がConsent Modeを徹底するのは、Google系を「完全に止める（Basicモード）」のではなく「Cookieなしの匿名状態で動かし続ける（Advancedモード）」ことで、法令を守りつつ取りこぼしをAIの推定で補えるから。一方、非Google系はGTM側で明示的に止めない限り暴走する――これが最重要の注意点です。

4. 「追加の同意チェック」で非Google系を止める

非Google系タグの暴走を止めるには、GTMの各タグの設定で「Require additional consent for tag to fire（タグ発火に追加の同意を必要とする）」を仕込みます。

以下は、IT+が自社サイトで実装した Microsoft Clarity の設定画面です。

↓　Clarityタグに「追加の同意（analytics_storage）」を指定

ポイントは、トリガーが All Pages（全ページ）でも、GTMが「このタグは analytics_storage（統計用Cookie）の許可が出るまで動かしてはいけない」と判断し、同意するまでコードを1文字も実行しないこと。

この「追加の同意」は、外部ツールの数だけ1つずつ仕込みます。HubSpotも同じ設定をします。

↓　HubSpotにも同じ要領で「追加の同意」を設定（ツールの数だけ繰り返す）

※HubspotのタグはStudio管理画面から設置できるのですが、IT+はとある理由によりもともとGTMにて設定していました

※厳密には、トリガーを「All Pages」だけにすると、初回訪問者がページ表示後に同意した場合にその初回ページだけ計測が漏れる、といった細かい論点もあります（"同意更新"時に発火するトリガーの併設などで回避）。ただし実装の細部で影響も限定的なため、本記事では深入りしません。

これをして初めて、「法的に嘘のない同意バナー」が完成します。

5. バナーの「4つのボタン」とGTM変数の対応

Cookiebotのバナーに並ぶ4つのトグル――Required / Preferences / Statistics / Marketing。これらは見た目だけでなく、裏側でGTMの「同意タイプ（Consent Types）」と1対1で連動しています。ユーザーがON/OFFすると、対応する変数が granted / denied に書き換わります。

↓　IT+のCMPバナー（4つのトグル）

⚠️ つまずきやすい点①：functionality_storage は Preferences（"必須"ではありません）。Requiredに入るのは security_storage だけで、既定で許可されます。

⚠️ つまずきやすい点②：Marketingは ad_storage だけに紐づけないこと。ad_user_data・ad_personalization も合わせないと、拡張コンバージョンやオーディエンス配信が静かに壊れます。

どこで設定しているのか（2か所の連携）

1. Cookiebot側＝Cookieの自動仕分け：ドメインを登録するとロボットが自動スキャンし、「これはGA4だからStatistics」「これはMetaピクセルだからMarketing」と4カテゴリへ自動で振り分けます。

2. GTM側＝鍵の割り当て：ユーザーが「Statisticsを許可」すると、Cookiebot→GTMへ信号が飛び、第4章で設定した「追加の同意（analytics_storage）」の条件が満たされ、ClarityやGA4が初めて発火します。

「バナーの Statistics ボタン」＝「GTMの analytics_storage という鍵」。この鍵を各タグに前もって指定しておくことで、ボタンがONになったときだけ正確にタグが起動します。

6. まとめ ― 実装後に必ずやる「検証」

設定したら終わりではありません。**「本当にEUからだけバナーが出るか」「同意前にタグが止まっているか」**を自分の目で確かめます。

検証チェックリスト

• キャッシュを使わない状態で見る：シークレットウィンドウ／新規プロファイル（公開後はCDNのキャッシュをパージしてから）。

• トラッカーブロック系の拡張機能はオフにする（広告ブロッカーが動いていると切り分け不能になる）。

• 地域の出し分け：VPN（例：ロンドン）でEU圏を再現し、英語ページでバナーが出ること／日本からは出ないこと。

• Google系の同意状態：同意前は gcs=G100、「すべて同意」後に gcs=G111 に変わること。

• 非Google系のフリーズ：同意前にClarity・HubSpotの通信が発生していないこと。同意後に初めて発火すること。

• 計測の継続：日本からの通常アクセスでGA4/Clarityが計測できていること。

地域の出し分け

↓　VPNにてEU圏（ロンドン）からアクセス → バナーが出る

↓　日本からのアクセスだと英語ページでもCookie同意バナーが表示されていない

gcs の見方（Google系が正しく止まっている証拠）

開発者ツールの Network で、GA4の送信（collect）の中の gcs を見ると、同意状態が確認できます。gcs は G1 ＝Consent Modeが効いている印 ＋ 2桁（1桁目＝広告用 ad_storage／2桁目＝解析用 analytics_storage、1=許可・0=拒否）。

• gcs=G100 ＝ 広告も解析も拒否（同意前）。リクエスト自体は飛んでいる＝Cookieなしの匿名信号だけ送っている証拠。

• gcs=G111 ＝ 広告も解析も許可（「すべて同意」後）。

📌 補足：この gcs（G100→G111）で「同意するまでGoogleタグが止まっている」ことは確認できます。基本はこれで十分です。（厳密には最新仕様 Consent Mode v2 の細かい項目を見る gcd という別パラメータもありますが、専門的なので本記事では深入りしません。）

↓　同意前 → gcs=G100（Cookieゼロの匿名信号）

↓　「すべて同意」後 → gcs=G111（通常計測に切替）

📌 補足：このサイト（IT+）の前提 IT+では、多言語の翻訳を固定ページだけに設定し、ブログ等は翻訳対象から除外しています。そのため、CMPバナー（とConsent Mode）が動くのは「英語ページ × EU圏32カ国からのアクセス」のときだけです。日本語ページやブログなど、それ以外のページは「EU圏を狙っていない＝CMP同意バナーは不要」という判断にしています。

だから gcs が見えるのもその条件のときだけ。日本語ページやブログで gcs が出ない＝壊れているわけではなく、「そのページはゲートしていない（国内向けとして全タグを動かす）」という設計どおりです（逆に、バナーを出している英語ページで gcs が出ないなら、Google系タグに同意モードが繋がっていない不具合のサインです）。

⚠️ ただし、この「どのページ・どの地域を対象外にするか」という線引きこそ、まさに各社の判断が必要な部分です。EUを狙っているか（targeting）だけでなく、行動モニタリングやePrivacyの観点もあるため、最終的には弁護士などの専門家にご確認ください。

この検証まで通して初めて、「やってる風ではない、正しく動く同意バナー」と言えます。

関連記事

• 多言語Studioサイトの「Cookie同意バナー」、どこまでやる？ ― 中小企業のための現実的な考え方 : Cookie同意バナー【前編】 ― 本記事の前編（戦略・判断編）。どこまでやるべきか、費用、EU市場との関係。

• Studioで多言語サイトはつくれる？ ― 対応方法と選び方、公開後の注意点

• STUDIOでの多言語対応！Weglotを使った手順とポイント

※掲載のツール名・画面・仕様は2026年6月時点のものです（GTMの「追加の同意」はBETA機能。UI・仕様は変わります）。最新は各サービスの公式情報をご確認ください。 ※本記事は法的助言ではありません。具体的な対応は弁護士等の専門家にご相談ください。