GTMのウェブコンテナとサーバーサイドコンテナ — 何ができて、何ができないか

Googleタグマネージャー（GTM）には「ウェブコンテナ」と「サーバーサイドコンテナ」という2つの動かし方があります。最近は「サーバーサイド化すれば計測精度が上がる」という話をよく見かけますが、実際にはそこまで単純な話ではありません。この記事では、公式ドキュメントで確認できる事実と、実際にいただいたご相談や当社自身の運用から見えてきたことの両方をもとに、何ができて何ができないのかを整理します。

結論から：ほとんどの会社はウェブコンテナのままでいい

先に結論を書きます。多くの会社にとって、今のウェブコンテナのままで問題ありません。サーバーサイドコンテナは「計測の精度を底上げする魔法の設定」ではなく、サーバーを新たに1台契約して運用する、という結構重たい話です。導入すれば自動的に計測漏れが直るわけではなく、むしろ元からある設定ミスをそのまま新しい仕組みに持ち込んでしまうこともあります。

サーバーサイドを検討する価値があるのは、ごく一部の条件がそろったときだけ

サーバーサイドコンテナを検討する価値があるのは、おおよそ次のような場合です。

• 広告費の規模が大きく、計測精度のわずかな差がそのまま収益に跳ね返る
• 複数の広告媒体に高精度な連携（拡張コンバージョンなど）を本格的に広げたい
• サーバーの構築・監視・障害対応ができる体制がすでにある

逆に言えば、これらに当てはまらないのであれば、まずはウェブコンテナの設定を点検するほうが効果的です。この記事の後半で、実際にあった事例をもとにその理由を説明します。

この記事で扱う範囲

この記事で比較するのは、GTMの「ウェブコンテナ」と「サーバーサイドコンテナ」という2つの仕組みの違いです。Cookieの利用について訪問者から同意を得る「同意モード」については関連する論点として一部触れますが、本格的な解説は別の機会に譲ります。

そもそも何が違うのか

比較表の前に、言葉の意味を押さえておきます。

ウェブコンテナ：訪問者のブラウザの中でタグが動く

普段「GTMを入れる」と言うときに使っているのが、このウェブコンテナです。ウェブサイトに埋め込まれたGTMのコードは、訪問者のブラウザの中で動きます。Google公式の説明でも、ウェブコンテナは「ウェブサイトやアプリ上に存在し、ユーザーの操作を監視して情報を送信するために必要なタグだけをホストするもの」とされています（Server-side tagging overview）。クリックされた、スクロールされた、フォームが送信された、といったブラウザ上の出来事を直接つかまえられるのが特徴です。

サーバーサイドコンテナ：自社が管理するサーバーを一度経由してから送る

サーバーサイドタギングは、計測タグの処理の一部を、ウェブサイトから切り離してクラウド上のサーバーに移す仕組みです。Google公式は「計測タグの実装を、ウェブサイトやアプリからサーバーサイドの処理用コンテナへ移すことを可能にするもの」と説明しています（Server-side tagging（開発者向けドキュメント））。

構成としては、ウェブコンテナ（ブラウザ側）とサーバーコンテナ（クラウド側）の2つを組み合わせて使います。ウェブコンテナから送られたデータはいったんサーバーコンテナで受け止められ、そこから改めてGoogleアナリティクスや広告媒体に送信されます。サーバーコンテナはGoogleが自動でCloud Run上に構築することもできますし、App Engineなど別のプラットフォームに手動で構築することもできます（同上）。

ここで大事なのは、サーバーサイドコンテナはウェブコンテナを置き換えるものではないという点です。Google公式のヘルプにも「サーバーコンテナは、クライアントサイドの構成であればブラウザで実行されていたはずの負荷の高い処理を肩代わりすることで、ウェブコンテナを補完するものである」とはっきり書かれています（Server-side tagging overview）。サーバーサイド化しても、ブラウザ側のウェブコンテナ自体はそのまま動き続けます。

何が変わり、何が変わらないのか

サーバーサイド化で変わるのは「計測データがGoogleや広告媒体に届くまでの通り道」です。訪問者のブラウザから各社へ直接送られていたものが、自社管理のサーバーを一度経由するようになります。これによって、送信前にデータを検証したり、不要な項目を除いたりできるようになります。

一方で変わらないのは、「計測したい出来事」そのものです。クリックされたか、フォームが送信されたか、注文が完了したか、という事実は、どちらのコンテナを使っても変わりません。この「変わらない部分」を後回しにしたままサーバーサイド化を進めると、後ほどご紹介するような問題が起きます。

比較表

実務で差が出る軸だけに絞って整理しました。横に長い表です。スマートフォンでは表を左右に動かしてご覧ください。

「サーバーサイドにすれば計測漏れが全部直る」という誤解

比較表を見ると、サーバーサイドコンテナのほうが優れた仕組みに見えるかもしれません。ただし、「サーバーサイドにすれば今の計測漏れが全部直る」と考えるのは早すぎます。実際には、効くところと効かないところがはっきり分かれます。

構造的に効きやすいもの

Google公式が明言しているサーバーサイドの利点は、主に次の2つです。

1つ目は、送信前のデータ処理です。訪問者から得たデータを、Googleや広告媒体に渡す前に検証・匿名化したり、個人情報に関わる項目だけ除外したりできます。これはウェブコンテナだけでは難しいことで、公式ドキュメントにも「機密情報が内部のデータストアに記録されないようにできる」と説明されています（Transformations）。

2つ目は、クライアント側の負荷軽減です。計測タグを複数の媒体に送っている場合、サーバーサイド化によって「ブラウザからは1本のデータストリームを送るだけ」という構成にできます。

ここで注意が必要なのが、ブラウザのプライバシー保護機能（SafariのIntelligent Tracking Preventionなど）との関係です。「サーバーサイド化すればSafariのCookie制限を回避できる」という話は業界でよく語られますが、今回Google公式のサーバーサイドタギング関連ドキュメントを確認した範囲では、Googleが「ITP」や「Safari」という固有名詞を使ってサーバーサイドタギングの効果を説明している一次情報は見当たりませんでした。Google公式が明言しているのは、「同一オリジンのサブドメインでサーバーを構成すると、サーバー発行のCookieがより長持ちし安全になる」という点までです。ブラウザによってファーストパーティCookieの寿命に制限がかかること自体はGoogleのGA4ヘルプにも記載がありますが、これはブラウザ側（gtag.js）の実装の文脈での説明であり、サーバーサイド化がこの制限をどう変えるかを名指しで解説したものではありません。つまり「効きやすいはず」という業界の見立てと、「Googleが公式にそう言っている」ことは、分けて理解しておく必要があります。

まったく効かないもの

一方で、サーバーサイド化してもまったく解決しない問題もあります。詳しくは次の章で実例を挙げますが、先に種類だけ整理すると次のとおりです。

• 別ドメインへ遷移する導線で、広告のクリックを識別するパラメータがそもそも引き継がれていない、という実装上の漏れ
• 古いタグを停止し忘れたまま新しいタグを追加してしまい、同じ出来事が二重に計測される、という運用ミス
• 拡張コンバージョンの設定を作りかけのまま放置してしまう、という人的な抜け
• 標準の計測機能が対象にしていない種類のリンク（特定の外部サービスへのリンクなど）のクリックが、そもそも計測対象に入っていない

これらはすべて、どちらのコンテナを使っていても起きる種類の問題です。サーバーサイド化はデータの通り道を変えるだけなので、通り道の手前にある実装や設定そのものが間違っていれば、そのまま同じ間違いがサーバー側にも引き継がれます。

むしろサーバーサイド化で増えるリスク

さらに言うと、サーバーサイド化によって新たに増えるリスクもあります。サーバー側とウェブコンテナ側の設定が1か所でもずれると、その食い違いに気づけないまま、データがまるごと記録されなくなることがあります。しかも多くの場合、サーバー自体は正常に動き続けているため、エラーも出ず、気づくのが遅れます。これは当社が自社で運用している計測基盤で実際に経験したことで、次の章で具体的にご紹介します。

実際にあったご相談から見えてきたこと

ここからは、実際にいただいたご相談をきっかけに見つかったこと、そして当社自身のサイトや自社で運用している計測基盤で分かったことをご紹介します。個別のお客様が特定されないよう、内容は一般化しています。

ご相談をきっかけに見つかったこと

あるオンライン通販サイトの計測を見直したケース

「広告経由の注文がきちんと計測できているか確認してほしい」というご相談をいただいたことがあります。調べていくと、原因は一つではありませんでした。

まず、広告のコンバージョン計測タグに、Cookieの保存期間を延ばすための補完設定が入っていませんでした。この設定が抜けていると、特定のブラウザのプライバシー保護機能によってクリックを識別するCookieの寿命が極端に短くなり、注文自体は実際に発生しているのに、広告側のコンバージョン数には反映されないという状態になります。実際に確認すると、計測から漏れていた注文はすべて該当のブラウザからのものでした。

加えて、商品ページから決済専用の別ドメインへ遷移するリンクで、クリックを識別するためのパラメータがそもそも引き渡されていないことも分かりました。さらに棚卸しを進めると、過去に使っていた旧いコンバージョンタグが停止されないまま新しいタグが追加されており、1回の注文で広告側に2件分のコンバージョンが送られてしまう状態にもなっていました。これは広告の自動入札の判断材料を歪めてしまいます。

原因がそれぞれ独立していたため、一つずつ確認しながら順番に直していきました。なお、このサイトには、権限がなく中身を確認できない別のGTM設定も同じページに埋め込まれていました。重複がないとは言い切れない状態で、現状をそのままお伝えしています。

拡張コンバージョンの設定を見直したケース

ある案件で、フォームの入力内容を拡張コンバージョン（Google広告の計測精度を上げる仕組みの一つ）に渡す設定を確認したところ、入力欄をCSS上の指定で直接つかまえる方式になっていました。この方式は、フォームのHTML構造が変わると静かに壊れてしまいます。フォーム側から値を明示的に渡す方式に作り直し、構造が変わっても壊れにくい設計にしました。

診断の中で見つかった「作りかけ」の設定

別のご相談先を診断した際には、拡張コンバージョン用の設定項目は用意されているのに、アカウント側の設定もタグ側の有効化もオフのまま残っている状態を見つけました。実装したつもりで止まっていたケースで、設定を見直して有効化しました。

本番反映の直前で気づいた、他社設定との衝突

GTMの設定を変更するときは、作業前に必ず、いま本番で動いている状態を取得し直すようにしています。あるご相談先でそれをしたところ、別の業者が後から広告計測用のタグを追加していたことが分かりました。もし古い状態を基点にしたまま作業を進めていたら、本番に反映した瞬間にその業者のタグが消えていたはずです。最新の状態を取り直してから作業をやり直し、事故を避けました。

複数店舗を展開するお客様からのご依頼

複数の店舗を同じ形式でGTM設定しているお客様からは、「新しい店舗の設定を追加してほしい」というご依頼をいただくことがあります。あるとき確認してみると、依頼いただいた店舗にはすでに全部の設定が済んでいました。店舗数が増えるほど、どの店舗に何が入っているかの管理が属人化しやすいことが分かり、以降は作業前に必ず現状を確認してから着手するようにしています。

自社サイトで検証していて分かったこと

他人事ではなく、当社自身のサイト（masamedia.co.jp）でも同じように点検しています。電話番号へのリンクと外部サービス（LINE）へのリンクのクリックを、アクセス解析ツールの標準機能（拡張計測機能）に任せていたところ、公開から一定期間、外部サービスへのリンクのクリックが1件も計測されていないことが分かりました。標準機能の対象範囲に収まっていなかったためで、最終的にはGTMで自前のクリック計測タグを組んで解決しています。

当社が自社で運用している計測基盤で起きたこと

当社はGoogle公式のサーバーサイドGTMコンテナそのものを本番導入した実績はまだありません。ここで紹介するのは、同じ発想（訪問者のブラウザから、自社が管理するサーバーを一度経由させる）で、当社が自社で運用している計測基盤において実際に起きたことです。

ある店舗の行動計測で、データベース側の識別名を変更したにもかかわらず、計測タグ側の設定を同時に直し忘れたため、送られてきたデータが「知らないサイトのもの」として扱われ、保存されずに捨てられ続けていました。サーバー自体はエラーも出さず正常に応答し続けていたため、23日間気づけませんでした。

これはまさに、前の章で触れた「サーバーサイド化で増えるリスク」の実例です。ウェブコンテナだけの構成であれば、送信先はGoogleや広告媒体の既存の受け口なので、こうした「自社側の設定ズレでデータがまるごと消える」という種類の事故自体が起きません。自社でサーバーを管理する構成を選ぶのであれば、こうした食い違いに早く気づくための監視の仕組みを、最初から組み込んでおく必要があります。

一方で良い面もあります。既製の行動分析ツールは、データの取得件数や取得期間に制限があり、要素ごとのクリック位置やスクロール到達の分布といった詳細なデータをまとめて取り出すことができませんでした。自社サーバーへ直接データを送る構成に切り替えたことで、この制限がなくなり、必要なだけ詳しく分析できるようになっています。

コンテナの種類と関係なく起きること

どちらのコンテナを使うかに関わらず起きることもあります。GTMの権限設定が原因で本番反映がすぐにできず、その都度手作業での対応が必要になったこともありますし、「本番反映」のような重い操作は、確認なしに自動で実行できる体制にはせず、必ず人が承認を挟む運用にしています。これらは運用体制そのものの課題で、サーバーサイド化しても、運用のやり方が変わらなければ同じことは起き続けます。

導入を検討してよいケース・しなくていいケース

ウェブコンテナのままでいいケース

• 広告費の規模がそれほど大きくなく、計測精度の数パーセントの差が経営判断に影響しない
• 社内にも委託先にも、サーバーを構築・監視できる人員や予算がない
• そもそも基本的な計測（ページビュー、フォーム送信、電話タップなど）の設定・点検がまだ済んでいない段階
• ランディングページやコーポレートサイト中心で、複数のドメインをまたぐ複雑な導線がない

サーバーサイドコンテナを検討する価値があるケース

• 広告費の規模が大きく、コンバージョン計測の精度の違いがそのまま収益に跳ね返る
• ブラウザ側の制限による計測漏れを切り分けたうえで、それでも一定数の漏れが残っている
• 複数の広告媒体へ、拡張コンバージョンのような高精度な連携を本格的に広げたい
• サーバーの構築・監視・障害対応を担える体制が、自社か委託先にすでにある

判断の前にまずやるべきこと

この記事で紹介した事例の多くは、ウェブコンテナの中身をきちんと点検していれば見つかっていたはずのものでした。サーバーサイド化を検討する前に、まず次のことを確認することをおすすめします。

1. 今のGTM設定に入っているタグを全部洗い出し、重複や古いタグの放置がないかを確認する
2. 計測できているはずのコンバージョンが、実際に広告の管理画面側でも計上されているかを突き合わせる
3. 自社が把握していない別の業者の設定が、同じサイトに同居していないかを確認する

この点検をせずにサーバーサイド化を進めると、今ある抜け（二重計測やパラメータの引き継ぎ漏れなど）をそのまま新しい仕組みに持ち込むだけになってしまいます。

導入判断チェックリスト

• 今のGTM設定を一度も全数点検したことがない → まずは点検から
• 広告費の規模に対して、計測精度の差が経営判断を左右するほど大きい → サーバーサイドを検討する価値あり
• サーバーの構築・監視・障害対応ができる人員や委託先がいない → 導入は時期尚早
• クリックやスクロールなどブラウザ上の操作をきめ細かく計測したい → サーバーコンテナ単独では対応できないため、ウェブコンテナと組み合わせる前提で考える
• 送信前にデータを検証・匿名化したい、特定の項目を外部に送りたくない → サーバーサイドが向いている
• 月額のサーバー費用（目安として1台あたり月額$40〜45程度、構成次第で変動）を継続的に払う判断ができる → 導入の現実的な条件が整っている

参考：もう一つの選択肢も登場しています

ここまで「ウェブコンテナかサーバーサイドコンテナか」という2択で説明してきましたが、Googleは2025年5月8日に「Google tag gateway for advertisers」という仕組みを正式に提供開始しています。以前は「First-party mode」という名前で提供されていたものの改称で、自社ドメイン上の自社インフラ（CDNやロードバランサーなど）を使って、Googleタグをファーストパーティとして配信できる仕組みです。クライアントサイド・サーバーサイドどちらのタグにも対応しており、サーバーサイドコンテナと組み合わせて使うことも推奨されています（公式ヘルプ）。2026年に入ってからもAkamai・Fastly・Google Cloud Platform・Amazon CloudFrontといった主要なインフラとの連携が順次追加されており、まだ発展を続けている仕組みです。今回の記事の比較とは別軸の選択肢として、頭の片隅に置いていただければと思います。

まとめ

GTMのサーバーサイドコンテナは、送信前にデータを検証・加工できる、ブラウザ側の負荷を減らせるといった、公式に裏付けのある利点を持った仕組みです。ただし、ウェブコンテナを置き換えるものではなく、サーバーの契約・運用という新しい負担を抱える判断でもあります。

そして何より、これまでのご相談や当社自身の点検を通じて見えてきた計測漏れの多くは、コンテナの種類とは関係のない実装や設定のミスでした。別のドメインへパラメータが引き継がれていなかったり、古いタグを停止し忘れていたり、設定が作りかけのまま放置されていたりといったものです。こうした問題は、サーバーサイド化しても自動的には直りません。

もし今、計測の精度に不安があるなら、サーバーサイドコンテナの導入を検討する前に、まず今のウェブコンテナの中身を一度洗い出してみることをおすすめします。それだけで見つかる問題が、思いのほか多いかもしれません。