「サーバーサイドGTMを導入すると決めたが、何から手をつければいいのか分からない」——構築の情報は断片的で、どの順番でやるかが分かりにくいのが実情です。
本記事では構築の流れを順に解説し、つまずきやすい箇所と構築後に必要な準備まで扱います。
導入すべきかどうかをまだ判断していない場合は、先に「【2026年版】サーバーサイドGTMとは？仕組み・費用・導入判断の基準を解説」を読んでください。 広告費の規模と運用体制によっては、導入しないほうがよいケースがあります。
記事のポイント
- 構築前に用意すべきもの
- Cloud Run でサーバーを作る手順
- 独自サブドメインの設定（ここを省くと効果が大きく減る）
- ウェブコンテナ側の変更
- 動作確認の方法
- 構築後に必要な運用の準備
目次
- 構築前に用意するもの
- 全体の流れ
- ステップ1: サーバーコンテナを作成する
- ステップ2: サーバーをプロビジョニングする
- ステップ3: 独自サブドメインを設定する
- ステップ4: ウェブコンテナの送信先を変更する
- ステップ5: 動作確認
- つまずきやすい箇所
- 構築後に必要な準備
- よくある質問
- まとめ
構築前に用意するもの
| 必要なもの | 備考 |
|---|---|
| GTMの管理者権限 | サーバーコンテナの作成に必要 |
| GCPプロジェクト | 課金を有効にしておく |
| DNSを操作できる権限 | サブドメインのレコード追加に必要 |
| GA4の編集者権限 | 送信先の変更に必要 |
| インフラを分かる担当者 | マーケ担当だけでは完結しない |
最後の項目が実質的な前提条件です。 GCPの設定・DNS・SSL証明書・スケーリングの調整が発生するため、情報システム部門または開発チームの関与が必要になります。
全体の流れ
1. GTMでサーバーコンテナを作成
2. GCP（Cloud Run）でサーバーをプロビジョニング
3. 独自サブドメインを割り当て、DNSを設定
4. ウェブコンテナのGA4タグの送信先を、そのサブドメインへ変更
5. 動作確認
6. 各媒体のサーバーサイドタグを追加（Meta CAPI など）3を省略すると、導入のメリットが大きく減ります。 後述します。
ステップ1: サーバーコンテナを作成する
- GTMの管理画面で「コンテナを作成」
- コンテナ名を入力
- ターゲットプラットフォームで「サーバー」を選択
- 「作成」
既存のウェブコンテナとは別に、新しくサーバー用のコンテナを作ります。 ウェブコンテナを置き換えるわけではありません。
ステップ2: サーバーをプロビジョニングする
コンテナ作成後、タグ付けサーバーの設定を求められます。
- 「Google Cloud Platform で自動的にプロビジョニングする」を選択
- GCPプロジェクトを選ぶ（または新規作成）
- リージョンを選択する — 日本向けなら
asia-northeast1（東京） - デプロイを実行する
自動プロビジョニングを選ぶと、Cloud Run にサーバーが構築されます。
インスタンス数の設定に注意
初期設定では常時起動のインスタンス数が多めに設定されることがあります。 これが費用に直結します。
Cloud Run のコンソールから、最小インスタンス数を必要最小限に調整してください。トラフィックを見ながら段階的に増やすのが安全です。
「思ったより高額だった」の原因は、ほぼここです。
ステップ3: 独自サブドメインを設定する
このステップが最も重要です。
自動プロビジョニングで払い出されるのは 〜.run.app のようなGCPのドメインです。このまま使うと、自社サイトから見て別ドメインになり、ファーストパーティ扱いになりません。
独自ドメインのサブドメインを割り当ててください。
手順
- 使うサブドメインを決める（例:
metrics.example.com、gtm.example.com） - Cloud Run の「カスタムドメインを管理」から、そのサブドメインをマッピングする
- 指示されたDNSレコード（A / AAAA / CNAME）を、自社のDNSに追加する
- SSL証明書が自動発行されるのを待つ（数十分〜数時間かかることがある）
- ブラウザでそのサブドメインにアクセスし、GTMの応答が返るか確認する
サブドメインでなければならない理由
metrics.example.com は example.com と同じ登録可能ドメインです。 そのため、このサーバーが発行するCookieはファーストパーティCookieとして扱われます。
別ドメイン（example-metrics.com など）では、サードパーティCookieになり、導入の効果が大きく損なわれます。
サードパーティCookieの現状は「【2026年最新】サードパーティCookieは廃止されたのか？Chromeの方針撤回と今やるべきこと」で解説しています。
ステップ4: ウェブコンテナの送信先を変更する
サーバーが動いたら、ブラウザ側からそこへデータを送るよう変更します。
- ウェブコンテナ（従来のGTM）を開く
- GA4の設定タグ（または Google タグ）を開く
- 設定フィールドに
server_container_urlを追加し、ステップ3のサブドメインを値に指定する - プレビューモードで確認してから公開する
サーバーコンテナ側には、GA4のクライアント（受信側）が既定で入っています。 受け取ったデータをGA4へ転送する設定を確認してください。
段階的に切り替える
いきなり全トラフィックを切り替えないでください。 まず一部のページやテスト環境で確認し、データが正しく届くことを確認してから広げます。
ステップ5: 動作確認
3つを確認します。
| 確認 | 方法 |
|---|---|
| サーバーに届いているか | サーバーコンテナのプレビューモードでリクエストを確認 |
| GA4に届いているか | GA4の「レポート」→「リアルタイム」 |
| 数値が従来と大きくずれていないか | 切り替え前後の日次データを比較 |
3つ目を必ず行ってください。 切り替え後にセッション数が半減した、といった事故は実際に起こります。1〜2週間は並行して監視してください。
つまずきやすい箇所
| つまずき | 原因 | 対処 |
|---|---|---|
| サブドメインで応答しない | DNS未反映 / SSL証明書の発行待ち | 数時間待つ。DNSレコードを再確認 |
| 費用が想定より高い | 最小インスタンス数が多い | Cloud Run の設定を見直す |
| データが届かない | server_container_url の指定ミス | プレビューモードで確認 |
| 効果が感じられない | サブドメインを設定していない | ステップ3を実施 |
| 一部の媒体だけ計測が落ちた | サーバーサイドタグの設定漏れ | 媒体ごとにタグを追加する |
「効果が感じられない」の大半は、サブドメインを設定していないケースです。
構築後に必要な準備
構築して終わりではありません。 ここを軽視すると、後で運用が破綻します。
1. 監視とアラート
計測サーバーが落ちると、計測が止まります。 ブラウザ上のタグなら各サービス側の問題でしたが、サーバーサイドでは自社の問題です。
Cloud Run のエラー率とレイテンシに対して、アラートを設定してください。
2. 設定内容のドキュメント化
構築した担当者が異動・退職すると、触れる人がいなくなります。 これは実際によく起こります。
- サーバーコンテナの構成
- サブドメインとDNSの設定
- 各媒体のタグとアクセストークンの管理場所
- 障害時の切り戻し手順
最低限これらを残してください。
3. 切り戻し手順の用意
問題が起きたときにウェブコンテナ経由の計測へ戻せるようにしておきます。 server_container_url を外せば従来の構成に戻りますが、その手順を事前に確認しておくことが重要です。
4. 各媒体のサーバーサイドタグを追加する
GA4だけでなく、Meta CAPI などもこの基盤で実装できます。手順は「【2026年版】Metaコンバージョン APIの設定方法｜重複排除の設定と計測精度の確認手順」で解説しています。
よくある質問
Q. マーケティング担当だけで構築できますか？
A. 難しいです。GCPの設定・DNS・SSL証明書・スケーリング調整が必要で、情報システム部門または開発チームの関与が前提になります。
Q. 独自サブドメインの設定は必須ですか？
A. 技術的には必須ではありませんが、設定しないと導入の効果が大きく損なわれます。 〜.run.app のままでは別ドメイン扱いになり、Cookieがファーストパーティとして扱われません。
Q. 費用が想定より高くなりました。
A. Cloud Run の最小インスタンス数を確認してください。常時起動するインスタンスが多いと、トラフィックが少なくても費用が発生します。必要最小限から始めて、負荷を見ながら調整してください。
Q. 切り替えたらセッション数が減りました。
A. 設定ミスの可能性があります。server_container_url の指定、サーバーコンテナのクライアント設定を確認してください。切り替え後1〜2週間は数値を並行して監視することをおすすめします。
Q. 構築後に必要なことは何ですか？
A. 監視とアラートの設定、設定内容のドキュメント化、切り戻し手順の用意です。とくにドキュメント化は重要で、構築担当者がいなくなると誰も触れなくなるケースが実際にあります。
Q. 構築すればCVRは上がりますか？
A. 上がりません。計測できるコンバージョン数は増えますが、それは見えていなかった成果が見えるようになっただけです。ページ表示速度の改善による間接効果はありますが、CVR改善が目的ならLPを直すほうが早く効きます。
まとめ
サーバーサイドGTMの構築について、要点を整理します。
- 前提条件はインフラを分かる担当者がいること。マーケ担当だけでは完結しない
- 流れは「サーバーコンテナ作成 → プロビジョニング → サブドメイン設定 → 送信先変更 → 確認」
- 最小インスタンス数の設定が費用に直結する。 必要最小限から始める
- 独自サブドメインの設定が最重要。
〜.run.appのままでは効果が大きく減る - SSL証明書の発行には時間がかかる（数十分〜数時間）
- いきなり全トラフィックを切り替えない。 段階的に、1〜2週間は並行監視
- 「効果が感じられない」の大半はサブドメイン未設定
- 構築後は監視・ドキュメント化・切り戻し手順の3点を用意する
- 構築してもCVRは上がらない
CVR改善ならDejam！計測基盤の構築と並行して、成果を増やす
Dejamは、LP制作・ヒートマップ分析・ABテスト・AI自動解析をオールインワンで提供するCVR改善特化ツールです。「計測基盤の構築に数か月かけたが、成果が変わらない」という事態を避けるための、改善そのものを支援します。
Dejamが選ばれる理由
- ワンプロダクトで完結: LP制作・ヒートマップ分析・ABテストをすべて単一ツールで実施
- 月額3万円〜利用可能: オプティマイズプラン月額3万円〜 / CMSプラン月額5万円〜 / オールインワン月額12万円〜
- ユーザー課金なし: 何名で使っても追加費用は発生しない
- ISMS認証取得: ISO/IEC 27001:2022 & JIS Q 27001:2023認証取得済み
- 毎週アップデート: 市場トレンドとユーザーリクエストに応じて機能を毎週拡充
- 権威ある実績: 代表がダイレクトアジェンダで2連覇。LPO顕彰制度「LPO AWARD」主催者
Dejamの主要機能
- LP/記事LP制作: ノーコード・コードの切り替えに対応。AIで生成したコードを直接取り込み可能
- ヒートマップ: 5種類（クリック/クリックイベント/熟読/滞在/離脱）。データ保存期間無制限
- ABテスト: デザイン変更テスト・リダイレクトテスト・ポップアップテストの3種類。AIが自然言語でテストコードを自動生成
- 自動解析: どのコンテンツがCVRに貢献しているかAIが自動解析。ゴールデンルート機能でページ遷移の最適パスも特定
- 広告ダッシュボード: Google広告・Meta広告など複数媒体のデータとLPのCVRを1画面で確認
サーバーサイドGTMの構築には数か月と継続的な運用体制が必要です。その間もLPの改善は進められます。Dejamはタグ1本で導入でき、インフラの運用は発生しません。
