← 記事一覧へ

ブログ

サーバーサイドGTM（sGTM）が正しく動いているか確認する方法

公開 2026-07-15

サーバーサイドgtm 確認sgtm 設定 確認サーバーサイドタグ 動作確認server side tagging 確認

「サーバーサイドGTM（sGTM）を入れたけれど、本当にサーバー経由で計測できているのか自信がない」——これはsGTMを導入したチームでとても多い不安です。ブラウザに直接タグを貼る従来の方式と違い、sGTMは間にサーバーが1段挟まるぶん、どこで止まっているのかが見えづらくなります。設定したつもりでも、サーバーがリクエストを受け取っていなければ、GA4も広告も何も記録されません。

こんな症状に心当たりはありませんか？

  • sGTMに切り替えてから、GA4のイベントが 減った・止まった
  • ブラウザの通信を見ても、自社ドメインのタグ付けサーバーにリクエストが飛んでいない
  • sGTMのプレビューに、リクエストが 1件も届かない
  • 従来のGA4は動いていたのに、transport_url を設定した瞬間に計測が消えた

この記事では、sGTMが正しく動いているかを確認する手順と、見るべきポイント、そしてよくある失敗を実務目線で整理します。

確認の前に：sGTMは「どこを」通っているのか

sGTMの確認でつまずく最大の原因は、データの流れを1本の線としてイメージできていないことです。sGTMでは、ブラウザから直接GA4へ送るのではなく、間に自社ドメインのサーバー（タグ付けサーバー）が入ります。まずはこの流れを押さえてください。

段階 何が起きるか よくある落とし穴
① 送信 ブラウザが一次ドメインのタグ付けサーバー（例 gtm.example.com）へ送る transport_url 未設定でGoogleへ直送のまま
② 受信 サーバー上のコンテナ（Cloud Run等）がリクエストを受け取る コンテナが未デプロイ／URLが誤り
③ 転送 サーバーがGA4・広告・Metaへ振り分けて転送する クライアント／タグのマッピング誤り

ポイントは、sGTMには「Webコンテナ（ブラウザ側）」と「サーバーコンテナ（サーバー側）」の2つがあることです。ブラウザ側でタグが発火していても、送信先がサーバーに向いていなければ従来どおりGoogleへ直送されているだけで、「sGTMを通っている」ことにはなりません。sGTMの狙いは、この一次ドメイン経由でCookieを一次化し、ITP（Safariのトラッキング防止）や広告ブロッカーの影響を受けにくくすることにあります。だからこそ**「サーバーを通っているか」自体を確認する**必要があります。

手順1：ブラウザの送信先（transport_url）を確認する

まず、ブラウザがどこへ送っているかを見ます。ここが自社のタグ付けサーバーに向いていなければ、そもそもsGTMは始まりません。

  1. 確認したいページを開き、開発者ツールの「Network（ネットワーク）」タブを開く
  2. フィルタに collect と入力する
  3. ページ操作で飛ぶ /g/collect リクエストの送信先ドメインを見る
  4. 送信先が gtm.example.com のような自社の一次ドメインになっているかを確認する（google-analytics.com や analytics.google.com のままなら未設定）

送信先を自社ドメインへ向けているのは、GA4設定タグ（またはGoogleタグ）の transport_url パラメータです。ここが空欄・誤記だと、ブラウザはGoogleへ直送し続けます。

つまずきやすい例： transport_url にサーバーコンテナのURLを入れたのに、そのサブドメインのDNSがサーバーを指していないと、リクエストは届かず失敗します。送信先ドメインが正しくても、そのドメインが本当にサーバーに解決されるかは別問題です。

手順2：サーバーコンテナがデプロイされ受信しているか

送信先が自社ドメインになっていても、その先のサーバーコンテナが動いていなければ受け取れません。

  • タグ付けサーバー（Cloud Runなどのホスティング）がデプロイ済み・稼働中か
  • タグ付けサーバーのURL（例 https://gtm.example.com）にアクセスして、正常な応答が返るか
  • 手順1で見た送信先ドメインと、実際にデプロイしたサーバーのドメインが一致しているか

分かること： サーバーが存在し、リクエストを受け付けられる状態か（②）。 分からないこと： そのリクエストを受けて、GA4や広告へ正しく転送できているか（③は次の手順で見ます）。

つまずきやすい例： コンテナのデプロイは完了していても、コンテナ設定に必要な**コンテナ設定ID（Container Config）**を入れ忘れていると、サーバーは起動しても中身が空で、受信しても何も処理しません。「起動している」＝「設定が入っている」ではありません。

手順3：sGTMのプレビューで受信〜転送を追う

sGTMにはサーバー側専用のプレビューモードがあります。ここが確認の中心です。

  • sGTM（サーバーコンテナ）の管理画面で「プレビュー」を起動する
  • 対象サイトを別タブで開いて操作し、プレビュー画面にリクエストが届くかを見る
  • 届いたリクエストに対して、GA4タグ・広告タグなどが発火しているか、送信先（Outgoing HTTP Requests）が意図どおりかを確認する

分かること： サーバーがリクエストを受信し、各配信先へ転送している（②→③の一連）。ここまで見えて初めて「sGTMを通っている」と言えます。

つまずきやすい例： プレビューにリクエスト自体が届かない場合は、サーバー側ではなく手前（手順1・2）の問題です。逆に、届いているのにGA4タグが発火しないなら、クライアントやトリガー、マッピングの設定ミスを疑います。「届かない」と「届くが転送されない」で原因の切り分け先がまったく変わります。

手順4：ファーストパーティCookieの有効期限と広告ブロッカー耐性を確認する

プレビューでデータの流れは確認できますが、sGTMの主要なメリットである「Cookieの有効期限の延長」と「広告ブロッカーの影響軽減」は別途検証が必要です。

SafariでCookieの有効期限を確認する

Safariで対象サイトを開き、開発 > Webインスペクタを表示 > ストレージ > Cookie を確認します。トラッキングCookie（_ga、_gcl_aw、またはsGTMで設定したカスタムCookie）を探し、有効期限を見ます。

  • 1〜2年先になっていれば、サーバーによってファーストパーティとして正しく設定されています。
  • 7日先になっている場合、SafariのITPによって制限されています。これは通常、タグ付けサーバーのサブドメインのIPアドレスがメインドメインのIPと一致しておらず、Safariが「CNAMEクローク」と判定して有効期限を短縮しているためです。

ChromeではこのITPの挙動は再現しないため、見落としやすいポイントです。関連：SafariのITPでコンバージョンが失われる問題。

広告ブロッカーを有効にしてテストする

ブラウザで広告ブロッカー（uBlock Origin、AdGuardなど）を有効にし、サイトを読み込んでNetworkタブを確認します。

  • /g/collect リクエストが自社のファーストパーティドメインに届いているか
  • sGTMのプレビューにリクエストが引き続き表示されるか

主要なフィルタリスト（EasyPrivacy、AdGuard）は、sgtm. や gtm. のようなよく使われるsGTMサブドメインのパターンをブロック対象にし始めています。サブドメインがブロックされている場合は、推測されにくいサブドメイン名への変更を検討してください。広告ブロッカーの影響について詳しくは広告ブロッカーによるピクセルブロックとその対策をご覧ください。

Cloud Runのログで本番環境のサイレント障害を確認する

プレビューはあくまでデバッグツールであり、見ていないときの本番環境の状態は分かりません。sGTMには組み込みの稼働状況ダッシュボードがないため、本番環境の障害は能動的に監視しない限り気づけません。

Google Cloud Consoleで Cloud Run > タグ付けサービス > ログ（またはLogs Explorer）を開き、以下を確認します。

  • ErrorまたはWarningレベルのエントリ — タグの転送失敗、変数の設定ミス、配信先エンドポイントへのタイムアウトなどが記録されていることがあります。
  • リクエスト量の急減 — DNS変更、証明書の期限切れ、コンテナのスケーリング問題など、プレビューモードでは発見できない原因が考えられます。
  • logToConsole の出力 — Loggerタグや logToConsole APIを使用するカスタムテンプレートの出力は stdout ログに出力されます。Logs Explorerで logName: "stdout" でフィルタしてください。

エラー率やリクエスト数に対して Cloud Monitoringアラートを設定し、コンバージョン数の減少で数日後に気づくのではなく、問題発生時に通知を受けられるようにしましょう。

sGTMでの「よくある失敗」

sGTMを通っていないとき、原因はだいたい次に集約されます。上から順に疑ってください。

1. transport_url を設定していない

最頻出です。Webコンテナ側のGA4設定タグ（Googleタグ）に transport_url を入れないと、ブラウザはGoogleへ直送し続け、サーバーは一切通りません。

2. サーバーコンテナが未デプロイ／停止している

ホスティング（Cloud Run等）にコンテナをデプロイしていない、あるいは停止している場合。手順2でURLに応答があるかを確認します。

3. 一次ドメイン（サブドメイン）のDNSが未設定

gtm.example.com のようなサブドメインを用意しても、DNSがサーバーを指していなければリクエストは届きません。DNS設定と証明書（HTTPS）の有効性を確認します。

4. マッピング・クライアントの設定ミス

サーバーは受信しているのに、GA4クライアントが有効化されていない、タグのトリガー条件が合っていない、といった設定ミスで転送されないケース。手順3のプレビューで転送状況を追います。

「手元の確認だけでは分からないこと」

上記の手順はどれも有効ですが、自分の手元で1回操作して確認するやり方には、構造的な限界が2つあります。

  1. 自分の環境＝本番のユーザー環境ではない。 sGTMの主目的の一つは、ITP（SafariのITPでコンバージョンが失われる問題）や広告ブロッカーの影響を減らすことです。ところが、確認する自分のブラウザがChromeで拡張機能もオフだと、まさに回避したかった条件を再現できません。Safari実機や別環境で崩れる欠損は、手元の1パターンでは見えないことがあります。
  2. 広告クリックがからむコンバージョンは確認が難しい。 「広告経由でも本当にサーバー経由で計測されるか」をきちんと見ようとすると、ライブ広告をクリックして経路を再現する必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。

サーバーを1段挟むぶん、sGTMは「手元では動くのに、本番の実ユーザー条件で欠ける」問題が起きやすい構造だといえます。だからこそ、本番の実際の経路で確認することが重要になります。

確実に確認するためのチェックリスト

まずは無料・手軽にできる範囲から、順番に潰していきましょう。

  • ブラウザの送信先（/g/collect）が自社の一次ドメインになっているか（transport_url）
  • そのサブドメインのDNSがサーバーを指し、HTTPSが有効か
  • サーバーコンテナ（Cloud Run等）がデプロイ済み・稼働中か
  • コンテナ設定ID（Container Config）が正しく入っているか
  • sGTMのプレビューにリクエストが届くか
  • 届いたリクエストでGA4・広告タグが発火し、転送されているか
  • 転送先（GA4のプロパティ、広告のコンバージョンID）が意図どおりか
  • Safari実機など、本番の実ユーザー条件でも欠けていないか
  • Safariで、トラッキングCookieの有効期限が1〜2年先になっているか（ITPで7日に制限されていないか）
  • 広告ブロッカーを有効にしても、リクエストが自社のタグ付けドメインに届いているか
  • Cloud RunのログにError/Warningエントリやリクエスト量の急減がないか

よくある質問（FAQ）

Q. sGTMを入れたのにGA4のイベントが減ったのはなぜ？ A. よくあるのは、transport_url を設定した瞬間にブラウザの送信先が自社サーバーへ切り替わったものの、そのサーバー（コンテナのデプロイ・DNS）が整っておらずリクエストが行き止まりになっているケースです。手順1〜3で、送信先・受信・転送の順に確認してください。

Q. ブラウザ側でタグが発火していればsGTMは動いている？ A. いいえ。Webコンテナ側のタグが発火していても、送信先がGoogleのまま（transport_url 未設定）なら、従来の直送でありサーバーは通っていません。送信先が自社ドメインか、そしてサーバーが受信しているかまで見て初めて判断できます。

Q. sGTMのプレビューにリクエストが届きません。 A. サーバー側ではなく手前の問題である可能性が高いです。①transport_url の設定、②サブドメインのDNS、③コンテナのデプロイ状況を確認してください。プレビューに届かない＝サーバーまで到達していない、と切り分けられます。

Q. GA4は動いているのに、Google広告のコンバージョンだけ来ません。 A. sGTMのサーバーコンテナで、GA4は転送できていても広告側のタグ・マッピングが設定されていない、という切り分け漏れが典型です。プレビューで、広告用の配信（Outgoing Request）が実際に出ているかを確認します。関連してGoogle広告のコンバージョンが計測されない場合の確認も参考になります。

Q. Metaや拡張コンバージョンもsGTM経由で確認できますか？ A. 考え方は同じで、プレビューで各配信先への転送を追います。個別の検証はMeta CAPI（コンバージョンAPI）の確認や拡張コンバージョンが正しく送られているかの確認、全体像はGA4コンバージョン計測ガイドもあわせてご覧ください。

まとめ：発火ではなく「サーバーを通って転送されるか」まで見る

sGTMの確認は、ブラウザ側のタグ発火だけでは不十分です。大事なのは、送信先が自社ドメインに向き（①）、サーバーが受信し（②）、GA4や広告へ正しく転送される（③）——この一連が本番でつながっているかまで踏み込むことです。手前で止まっていれば、ブラウザ側がどれだけ正常でもデータは記録されません。

ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、実際に送信されるタグ付けサーバーへのリクエストを傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、サーバーサイド計測の入口を確認してみてください。