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

⚠️ はじめに

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

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

📌 先に全体像：Cookie同意の実装は「4つの層」に分けると迷いません

①〜③を正しくやっても、④を知らないと「バナーは出ているのに裏で動いている」状態が残ります。IT+ もスキャンで17件見つけました（第7章）。

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個が未分類でした（その後のスキャンで wg-slugs も出たので、下の表は5件）。中身を見て、こう分類しました（Studio＋Weglotの組み合わせなら同じCookieが出るはずなのです。バナーは英語表示なので説明も英語で入れます）

※ Weglot 公式は wg-translations・wg-slugs を「必須（Necessary）」に分類しています。IT+ では、確認した表示範囲では JS を止めても翻訳が表示されることを踏まえ、運用方針として Preferences に置き、同意を得てから JS を読み込んでいます（第7章(b)）。

※ wg-translations-v・wg-search-form は Weglot の公式一覧には無い項目です。Cookiebot のスキャン結果と Weglot の JS のソースで確認しました。有効期間は公式の仕様として示されているものではありません。

📎 「Cookie」という言葉の範囲に注意

Cookiebot などの CMP は、HTTP Cookie だけでなく localStorage・sessionStorage・IndexedDB も「Cookie」として数えます。上の表の5件のうち HTTP Cookie は wg-search-form の1件だけで、残りはブラウザのストレージです（studio_analytics_session_id は sessionStorage、Weglot の3件は localStorage）。Studio の公式ヘルプが「アナリティクスは Cookie を使用しない」と書いているのは HTTP Cookie の話で、嘘ではありません。ただし EU の当局（EDPB）は「Cookie かどうか、個人データかどうか、保存期間の長短にかかわらず、端末に情報を保存・読み出せば同じルールの範囲」としています（Guidelines 2/2023）。「Cookie を使っていないから対象外」とは言えない、と押さえておいてください。

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

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

↓　そのタグの目的の説明

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

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

2. 「誰に出すか」を絞る ― 英語ページ × EEA・英国・スイスの32カ国

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

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

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

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

• 英語が同じアドレス内のフォルダ（example.com/en/ のようなサブディレクトリ）の場合：条件を「パスが /en で始まるとき」（正規表現なら ^/en(/|$)）にする（同じホスト名なので、ホスト名条件では英語だけを切り出せないため）。/en だけのアドレスを取りこぼさず、/blog/en/… のような別の階層を拾わないための書き方です。直アクセスとページ移動の両方で確認してください。

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

(2) EEA・英国・スイスの32カ国だけを対象にする ― 地域の設定

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

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

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

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

この「32カ国」は EU/EEA（30）＋ イギリス（GB）＋ スイス（CH）です（この記事では以下、まとめて「EU圏」と呼びます）。実際の国コードを1つずつ指定します（"EEA+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ピクセル等） で分かれます（Clarity は2025年からGoogleの同意モードを読むようになりましたが、IT+は同意前の通信をゼロにする基準で、GTM側でも止めています）。実装で一番つまずくポイントです。

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

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

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

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

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

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

• B. 非Google系（Clarity・HubSpot・SNSピクセル等） ツールごとに同意の受け取り方が違います。Clarity は2025年からGoogleの同意モードの信号を自動で読み、拒否ならCookieを置かずに動きます（Microsoft公式）。一方、HubSpotやSNSピクセルのように同意モードを読まないツールもあります。IT+は「同意前は通信そのものを発生させない」を基準にしたので、Clarityも含めてGTM側で起動を止める設定にしました（Cookiebot公式も、同意前にデータを送りたくない場合は、同意モード対応のタグにも追加同意チェックを付けるよう案内しています）。

• ❌ 間違った設定（"やってる風"）：同意モードを読まないタグが、ページが開いた瞬間にCookieを書き込み、通信を始めてしまう。

• ⭕ 正しい設定（「追加同意チェック」を設定済み）：GTMがトリガーの時点の同意状態を見て、同意がなければタグを実行しない。Cookieも通信も発生しません。

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

• 「すべて同意」：Google系は通常のCookie計測に切り替わる。追加同意チェックで止めていたタグは、トリガーが次に立ったとき（IT+の構成では次のページ移動かリロード）から動く（第4章の補足）。

• 「拒否」：Google系はCookieを使わない信号だけを送り続け、非Google系は最後まで動きません。

💡 大企業がConsent Modeを徹底するのは、Google系を「完全に止める（Basicモード）」のではなく「Cookieを使わない状態で動かし続ける（Advancedモード）」ことで、計測を止めずに、取りこぼしを推定で補えるから。一方、同意モードを読まないツールは、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+はタグのURLを自分で指定する必要があったため、連携を使わずGTMで設定しています。

⚠️ 追加同意チェックで止めたタグは、IT+ の構成では同じページの中で復活しませんでした

GTM の追加同意チェックは、トリガーが立った瞬間の同意状態で判定します。Cookiebot の公式手順では、こうしたタグの「All Pages」トリガーを、Cookiebot が同意のたびに送るカスタムイベント cookie_consent_update のトリガーに置き換えることになっています。All Pages のままだと、初回訪問で同意した直後のページではタグが動かないためです（Cookiebot 公式）。

IT+ は All Pages を残したまま、cookie_consent_update を2本目のトリガーとして足す構成にしています。Cookiebot は英語ページだけで読み込んでいるので、単純に置き換えると日本語ページで cookie_consent_update が発生せず、タグが動かなくなるからです。この構成で IT+ の本番サイトを実測すると、dataLayer 上は「同意状態の更新」→「イベント」の順で流れているのに、同意ボタンを押した直後のページではタグが動かず、次のページ移動またはリロードから動きました（2026年9月）。原因は特定できていません。

・解析タグなら、同意直後の1ページ分の計測が落ちるだけなので、IT+ は許容しています

・言語スイッチャーのように「画面に見えるもの」をこの方式で止める場合は要注意。同意した直後の1ページだけ表示されません

・回避の候補として、日本語側は「ページビュー（ホスト名が www のとき）」、英語側は cookie_consent_update、の2本に分ける構成が考えられます（英語側だけ公式の置き換えと同じ形になります）。IT+ ではまだ試していません

これをして初めて、バナーの表示と実際の動きが一致します。

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）」の条件が満たされ、次にトリガーが立ったとき（IT+の構成では次のページ移動かリロード）からClarityが動き始めます（GA4には追加同意チェックを付けていないので、同意前もCookieを使わない信号を送り、同意後にCookieを使った計測へ切り替わります＝第3章の表）。

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

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

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

検証チェックリスト

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

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

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

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

• 追加同意チェックを付けたタグ：同意前にClarity・HubSpotの通信が発生していないこと。同意後（IT+の構成では次のページ移動かリロード）に動くこと。

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

• 拒否 → ページ再読み込み → 同意 の順で試し、同意後に非Google系タグが動くことを確認する。Cookiebot 公式のとおりトリガーを置き換えた構成なら同意直後のページで、IT+ のように All Pages を残した構成では次のページ移動またはリロードで動くのを確認しました（第4章の補足）。戻り訪問は再読み込み後に動くこと。

• 同意 → 撤回 も試す。追加同意チェックは起動の条件で、動き出したスクリプトを止める仕組みではないので、撤回した後に通信と保存がどう変わるかを見る（EEA からの接続が要ります）。

• 開発者ツールの Application で Cookies だけでなく Local Storage / Session Storage も見る。CMP はこれらも「Cookie」として数える（第7章）。

• Cookiebot の月次スキャンレポートで「Blocked until accepted by user: No」の行を数える。スキャナーは EU 域内から来るので（第7章）、EU圏だけにバナーを出す設定でも、この判定はそのまま「同意前に動いているもの」の一覧になる。

地域の出し分け

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

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

gcs の見方（同意状態の確認）

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

• gcs=G100 ＝ 広告も解析も拒否（同意前）。リクエスト自体は飛んでいる＝Cookieを使わない信号（cookieless ping）だけを送っている状態。

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

📌 補足：この gcs（G100→G111）で確認できるのは同意状態です。AdvancedモードではGoogle系のタグ自体は動き続けるので、「止まっている」ことの証明にはなりません。Google系がCookieを書いていないかは、あわせてApplicationのCookiesを見てください。（厳密には最新仕様 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の観点もあるため、最終的には弁護士などの専門家にご確認ください。

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

なお、この設定・検証をまるごと任せたい場合は、多言語サイト制作サービスでも承っています。

7. 今回のGTM設定では制御できなかった3つの場所 ― スキャンで見つかった17件の正体

第1〜6章の設定をすべて終えた IT+ の英語サイトを、Cookiebot が毎月自動で行うスキャン（スキャナーの IP は公式に公開されていて、IT+ が調べた範囲では EU 域内・ドイツのデータセンターのものでした）にかけたところ、「Blocked until accepted by user: No」＝同意前に動いていると判定された項目が 17件 ありました。GTM の設定は正しかったのに、です。調べると原因は3つに分かれ、いずれもGTM の外にありました。同じ Studio サイトなら同じことが起きるので、まとめておきます。

(a) Studio の「埋め込み」ブロック — 別オリジンの iframe の中は親ページから制御できない（12件）

一般のサイトなら、外部の iframe は Cookiebot の手動マークアップ（src を data-cookieblock-src にして data-cookieconsent を付ける）で、同意まで読み込みを保留できます。ところが Studio の埋め込み（Embed）ブロックに貼った HTML は、Studio が用意する別オリジンのサンドボックス iframe（studioiframesandbox.com）の中で描画されます。この iframe は Studio 側が生成するので、こちらでマークアップを付けられる要素ではなく、CMP の自動ブロックも GTM の同意設定も中には届きません。IT+ の場合、会社紹介ページの YouTube 埋め込み3本から、Cookie 7・IndexedDB 4・localStorage 1 の計12件が同意前に動いていました。

そこで対処は埋め込み URL 側で行いました。

• YouTube：https://www.youtube.com/embed/動画ID → https://www.youtube-nocookie.com/embed/動画ID に差し替える。

• ⚠️ YouTube の差し替えでは www. を落とすとつながりません（youtube.com は www. 無しでも動くので混同しやすい）。共有リンクに付く ?si=… は共有時に付くパラメータなので外します。

• 差し替え後、再生前にスキャンで検出される保存項目（Cookie・IndexedDB・localStorage）は0件になりました（実測）。再生ボタンを押した後は YouTube 側の Cookie が付きます。再生に必要な処理と、それ以外の追跡は別で、再生を押したことが後者への同意になるわけではありません。ここまで止めたい場合は、同意後に埋め込みを読み込む作りが要ります。

• Vimeo：再生前は Cookie を置きません（実測）。再生後の追跡も止めたい場合は URL に ?dnt=1（すでに ? がある場合は &dnt=1）を付けます。Vimeo 公式では、Cookie を含むセッションの追跡を止め、動画統計も止まります。ただし動作に必要な Cookie は残ります。

(b) head に直書きした外部ツールの JS — 多言語ツールも同意の対象（4件）

Weglot（多言語ツール）の JS を Studio の head に直書きしていると、ページを開いた瞬間に 翻訳のキャッシュ（wg-translations 等）をブラウザに保存し（localStorage 3件と Cookie 1件）、これが Preferences（機能性）カテゴリの4件として出ました。GTM の外にあるので、当然 GTM の同意設定は効きません。

ポイントは、サブドメイン方式の Weglot では、ページは Weglot のサーバー（プロキシ）側で訳された状態で返ってくるということ。JS は言語スイッチャーの表示、翻訳キャッシュ、ページ表示後に生成される要素の翻訳を担います。IT+ で JS を止めて確かめたところ、止めた状態と動かした状態で、日本語の残り字数に差はありませんでした（2026年9月・6ページ）。

そこで IT+ は、head の2行を消して GTM のカスタム HTML に移し、functionality_storage（Preferences）の追加同意チェックを付けました。EU圏で拒否した人だけ言語スイッチャーが出ない、というトレードオフです（英語ページに来ている人なので影響は小さいと判断）。Studio の head に残したまま、Cookiebot の手動マークアップ（type="text/plain" と data-cookieconsent）で同意まで止める方法もあります（IT+ では試していません）。

<script>
(function () {
  if (window.__wgState) return;                 // 読み込み中・読み込み済みなら何もしない
  window.__wgState = 'loading';
  var s = document.createElement('script');
  s.src = 'https://cdn.weglot.com/weglot.min.js';
  s.async = true;
  s.onload = function () {
    Weglot.initialize({ api_key: 'wg_あなたのAPIキー' });
    window.__wgState = 'ready';
  };
  s.onerror = function () {                     // 失敗したら次の機会にやり直せるようにする
    window.__wgState = null;
    s.parentNode && s.parentNode.removeChild(s);
  };
  document.head.appendChild(s);
})();
</script>

• <script src> と Weglot.initialize を並べて貼ると、GTM 経由では読み込み前に initialize が走って Weglot is not defined になります。onload の中で initialize してください。

• 先頭の __wgState は二重読み込みの防止です。トリガーが複数ある構成では、読み込み中にもう一度タグが評価されることがあるため、「読み込み中」「読み込み済み」を分けて持ち、失敗したら解除します。

• タグの「配信オプション」は既定の「イベントごとに1度」のままにしてください。IT+ では「1ページにつき1度」でも「イベントごとに1度」でも、同意ボタンを押した直後のページではタグが動きませんでした（実測・原因は未特定）。二重読み込みはコード側で防ぐので、配信オプションで抑える必要はありません。

• 同意した直後のページでは、スイッチャーは出ません（次のページ移動・リロードから出ます）。IT+ の構成では、cookie_consent_update を2本目のトリガーとして足しても変わりませんでした。原因は特定できていません（第4章の補足）。同意済みで戻ってきた人は、Cookiebot が読み込みの最初に同意を復元するので最初から出ます。

(c) プラットフォームに内蔵された解析 — 運営者側に停止設定がない（1件）

最後の1件が studio_analytics_session_id。Studio の内蔵アナリティクスが使うセッション識別子です。分けて書きます。

• 公式ヘルプの説明：「Cookie を使用しません」「個人情報は含まれない」「利用はダッシュボード内に限定」「現在、データ送信の停止（オプトアウト）はできません」

• IT+ の実測：Studio 本体のスクリプトが sessionStorage に書き、タブを閉じると消える。送信先は analytics.studiodesignapp.com

• 分からないこと：送られたデータの、Studio 側での保存期間（タブを閉じて消えるのはブラウザ側だけです）

GTM の外、しかもサイト公開基盤そのものなので、サイト運営者側の設定では止められません。これは Studio に限った話ではなく、プラットフォーム型のサービスでは基盤側が独自の識別子を置くことがある、という一般的な論点です。

どう扱うかは、最終的には各社の判断になります。狙う市場・業種・リスクの許容度で変わり、EU の中でも国によって基準が違うためです（例：フランスの CNIL は条件付きで解析Cookieを同意免除としています）。この記事は IT+ が自社サイトで何をしたかの記録で、法的な助言ではありません。

IT+ の扱いはこうしました。

• Cookiebot 上のカテゴリは Statistics のままにする。「必須（Necessary）」に入れ直せばスキャンからは消えますが、停止手段が無いものを必須と呼ぶのは筋が通らないので、やりません

• 「利用者情報の外部送信について」の公表ページに注記を書く（何を・どこへ・ブラウザ側の保存はタブを閉じるまで・この項目については個別の停止設定を用意していない）。あわせて Cookiebot の Cookie 宣言にも同じ説明を英語で入れました

• EU の考え方も見ておくと、EU の前身の作業部会（Article 29 Working Party）は2012年に、ファーストパーティの集計だけに使う解析を「明確な説明・利用者が止められる手段・匿名化」があれば低リスクと整理しました。ただし同意の免除とはしていません。Studio 内蔵解析には利用者・運営者が止める手段がないため、この条件にも当てはまりません。つまり公表は「何が動いているかを隠さない」ための対応で、同意が不要になるという意味ではありません。同意の要否は別に判断が要ります

結果

「GTM の設定を正しくやる」は必要条件で、十分条件ではありませんでした。埋め込み・head・プラットフォーム内蔵の3か所は、スキャンレポートを見ないと気づけません。第6章のチェックリストに、月次スキャンの見方を足しました。

(c) のように「自分では止められないもの」は、隠すより公表ページに書いて残す。私たちはそうしました。ただし、それで済んだという意味ではありません。

関連記事

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

• 【実例】小規模ホテルのサイトを、Studio×多言語×宿泊予約×Cookie同意で作ってみた（無料ツール中心） ― 本記事の実装を、実際のサンプルサイトで形にした実例。無料CMPでどこまでできるか。

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

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

※掲載のツール名・画面・仕様は2026年6月時点、第7章と第4章の補足は2026年9月時点の実測です（GTMの［同意設定］は2026年9月時点でもBETA表記。UI・仕様は変わります）。最新は各サービスの公式情報をご確認ください。 ※本記事は法的助言ではありません。具体的な対応は弁護士等の専門家にご相談ください。