サーバーサイドGTM × Consent Mode v2で広告計測精度を維持する2026年の最適解

はじめに：Cookie規制・同意取得で計測が欠ける課題

「広告は回しているのに、コンバージョンが以前より少なく見える」「GA4と広告管理画面の数字がどんどん合わなくなってきた」。最近、こうした相談がぐっと増えました。原因のひとつが、Cookie規制と同意取得の浸透です。

ブラウザ側ではサードパーティCookieの扱いが厳しくなり、サイト側でも同意管理（CMP）のバナーで「Cookieを拒否」できる導線が当たり前になりました。その結果、ユーザーが計測を拒否したセッションでは、これまで自動的に取れていたデータが取れなくなります。広告のコンバージョン計測が穴だらけになり、機械学習による最適化の精度まで落ちる、というのが今の広告運用が抱える典型的な悩みです。

この記事では、中小ECや個人事業主の方が知っておきたい「Consent Mode v2」と「サーバーサイドGTM」という2つの仕組みを取り上げます。両方を正しく組み合わせると、同意を尊重しながらも、計測の欠落をできるだけ抑えられます。具体的な設定画面の操作は仕様変更が早いので、ここでは「考え方」と「全体の流れ」を中心に整理していきます。

この記事は2026年6月時点の一般的な情報をもとにした解説です。Consent Modeの挙動や法令・ポリシーの要件は地域や時期によって変わります。導入時は必ず最新の公式ドキュメントと、自社の状況に合った要件をご確認ください。

Consent Mode（同意モード）は、ユーザーの同意状態に応じて、GoogleのタグやSDKの計測のふるまいを変える仕組みです。「同意していないユーザーには計測しない」という単純なオン・オフだけでなく、「同意がない場合でも、個人を特定しない形で限定的にシグナルを送る」といった調整ができるのが特徴です。

v2では、広告関連の同意区分として ad_user_data（広告目的でのユーザーデータ利用）と ad_personalization（広告のパーソナライズ）が加わりました。従来の analytics_storage（分析用ストレージ）や ad_storage（広告用ストレージ）と合わせて、用途ごとにより細かく同意状態を表現する形になっています。

基本実装と詳細実装

Consent Modeには大きく2つの実装方法があります。

基本実装（Basic）: 同意が得られるまで、Googleのタグそのものを読み込まない・発火させない方式です。シンプルですが、同意がないユーザーのデータはまったく送られません。
詳細実装（Advanced）: タグは最初から読み込んでおき、同意状態に応じて送信内容を切り替える方式です。同意がない場合でも、Cookieを使わない「同意なしping（Cookieless ping）」と呼ばれる最小限のシグナルを送ることができます。

詳細実装のほうが、同意していないユーザーの行動も統計的に補える余地が大きく、計測の欠落をモデリングで補完できる可能性があります。ただし、その分セットアップや検証の手間は増えます。どちらを選ぶかは、計測の精度と運用負荷、そして自社のプライバシー方針とのバランスで決めるのが現実的です。

どの程度のデータを送るかは、最終的に「ユーザーの同意」と「適用される法令・ポリシー」に従って決まります。技術的に送れることと、法的・倫理的に送ってよいことは別です。判断に迷う場合は専門家への相談も検討してください。

サーバーサイドGTMの役割

もうひとつの主役が、サーバーサイドGTM（sGTM）です。通常のGTM（ウェブコンテナ）はブラウザ上でタグを動かしますが、サーバーサイドGTMは、自社が管理するサーバー上にタグ処理用のコンテナを置き、そこを経由して計測データを各ツールに送ります。

中小ECや個人事業主にとってのメリットは、主に次の3点です。

計測の安定化: ブラウザ拡張機能による広告ブロックや、ブラウザ側のトラッキング制限の影響を受けにくくなります。タグの処理がサーバー側に移るため、クライアント環境のばらつきに左右されにくいのが利点です。
ファーストパーティ化: 自社ドメインのサブドメイン（例: metrics.example.com）経由で計測リクエストを処理することで、ファーストパーティの文脈でデータを扱えます。サードパーティ起点の通信に比べて、Cookieの寿命や扱いの面で安定しやすくなります。
データの整理・最適化: サーバー側で、送信するデータを必要なものだけに絞り込んだり、不要な個人情報を落としたりする処理を挟めます。各広告・分析ツールへ送る前にデータをコントロールできるのは、プライバシー配慮の観点でも有効です。

注意したいのは、サーバーサイドGTMは「同意を無視して計測を取り戻す道具」ではないという点です。あくまで Consent Mode と組み合わせ、同意した範囲のデータを安定して・正確に届けるための基盤と考えてください。

構成と実装の流れ

ここからは、CMPからsGTMまでの全体像を順番に見ていきます。実際の設定UIは各サービスで頻繁にアップデートされるので、操作の細部は必ず公式ドキュメントに従ってください。ここでは流れの理解を優先します。

1. CMP（同意管理）でユーザーの意思を取得する

まず、サイト訪問者に対して同意バナーを表示し、Cookieや計測の利用について意思を確認します。これを担うのがCMP（Consent Management Platform）です。日本国内でも利用しやすいCMPがいくつかあり、GoogleはCMP Partnerプログラムに参加したツールの利用を推奨しています。

CMPの役割は、ユーザーが「許可した／拒否した」状態を取得し、その結果をConsent Modeに渡すことです。

CMPが取得した同意状態を、Consent Modeの「同意区分」に反映します。多くのCMPは、Consent Mode連携機能を持っており、同意の更新があるたびに自動でシグナルを送ってくれます。

イメージとしては、次のような同意状態のデータが、タグの発火判断に使われます（実際の値はCMP・実装方式により異なります）。

// あくまで概念を示すイメージ。実際の記述は公式ドキュメントとCMPの仕様に従う
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
});

// ユーザーが同意したら update でシグナルを更新する
gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted',
});

初期値（default）を「拒否」にしておき、同意が得られたタイミングで「許可」に更新するのが基本的な考え方です。デフォルトの設計を誤ると、同意前にデータが送られてしまうおそれがあるため、ここは慎重に設定します。

3. ウェブGTMからサーバーサイドGTMへ送る

ウェブ側のGTMコンテナは、同意状態を踏まえたうえで、計測イベントをサーバーサイドGTMのエンドポイントへ送信します。GA4タグの送信先を、Googleのサーバーではなく自社のsGTMコンテナに向ける、という構成です。

4. サーバーサイドGTMで処理して各ツールへ配信する

サーバーサイドGTMは、受け取ったデータを整理し、Consentの状態を引き継いだうえで、GA4やGoogle広告などの各ツールへ配信します。ここで、不要なデータを除いたり、送信先を制御したりできます。

全体の流れをまとめると、次のようになります。

ユーザー
  → CMP（同意バナーで意思を取得）
  → Consent Mode（同意状態をタグに反映）
  → ウェブGTM（同意を踏まえてイベント送信）
  → サーバーサイドGTM（自社サーバーで処理・ファーストパーティ化）
  → GA4 / Google広告など各ツール

この4段階がきれいにつながると、「同意を尊重する」ことと「計測精度を保つ」ことを両立しやすくなります。逆に、どこか一箇所でも同意の引き継ぎが切れていると、データが過剰に送られたり、逆にまったく取れなかったりします。設定後の検証（QA）が非常に大切です。

検証はプレビューとデバッグで丁寧に

実装後は、GTMのプレビューモードやTag Assistantといったツールで、同意状態ごとにタグが意図どおり動くかを確認します。「同意した場合」「拒否した場合」「未選択の場合」のそれぞれで、どのデータが送られ、どのデータが止まるのかを目で確かめておくと安心です。

GA4側でデータがうまく入ってこないときの切り分け方については、GA4移行でデータが欠ける問題とGTMでのデバッグ手順でも触れています。あわせて読むと、つまずきやすいポイントが見えてくるはずです。

注意：同意管理・法令・要件は地域と最新仕様を要確認

⚠️ Consent Modeの仕様、同意区分の扱い、CMPの要件、そして関連する法令（プライバシー保護や電気通信に関する各国・地域のルール）は、時期や対象地域によって変わります。とくにEEA（欧州経済領域）向けに広告を出す場合は、Consent Mode v2やCMP連携が事実上の前提になっているなど、地域固有の要件があります。日本国内でも、個人情報の取り扱いに関するルールは継続的に見直されています。この記事の内容は一般的な解説にとどめており、特定の状況での適法性を保証するものではありません。実装・運用にあたっては、必ず最新の公式ドキュメントと、自社に適用される要件を確認し、必要に応じて法務や専門家へ相談してください。

まとめ

Cookie規制と同意取得が当たり前になった今、「同意を尊重しながら、計測の精度をできるだけ保つ」ことが広告運用の前提になりました。そのための有力な組み合わせが、Consent Mode v2とサーバーサイドGTMです。

Consent Mode v2は、同意状態に応じて計測のふるまいを切り替える仕組み。基本実装と詳細実装があり、詳細実装は欠落をモデリングで補える余地が大きい。
サーバーサイドGTMは、計測を安定させ、ファーストパーティの文脈でデータを扱うための基盤。同意を無視する道具ではない。
CMP → Consent Mode → ウェブGTM → sGTM → 各ツール、という流れを途切れさせないことと、同意状態ごとの検証が成否を分ける。

まずはCMPとConsent Modeの連携から整えて、計測の足場を固めるところから始めるのがおすすめです。Cookieに依存しすぎない計測設計の考え方については、Cookieレス時代のEC広告計測とファーストパーティ／BigQuery活用もご覧ください。仕組みの全体像が、より立体的に見えてくると思います。