GA4のタグ設置方法|Googleタグ・GTMと二重計測の確認
2026年6月21日
著者: 与謝秀作
GA4のタグ設置は、測定IDを貼り付けて終わる作業ではありません。既存のCMS連携や広告タグを確認し、目的のGA4へ必要なイベントが重複せず届くことを確かめます。GTMへ切り替える場合も、直接設置したスクリプトを無条件に削除せず、送信先を調べてから移行します。以下は2026年10月11日確認の公式手順に沿った進め方です。
GA4・Googleタグ・GTMと各IDの役割を整理する
GA4プロパティは収集したデータとレポートを扱う管理単位、ウェブストリームはサイトからのデータの入口、Googleタグは収集と送信を担う仕組みです。GTMはタグを管理・公開するためのツールで、GA4そのものではありません。Analyticsの公式導入手順でも、プロパティとストリーム、データ収集を分けて設定します。
対象 | 確認する識別情報 | 用途 |
|---|---|---|
GA4プロパティ | 数字のプロパティID | レポートと管理対象を選ぶ |
ウェブストリーム | G-で始まる測定ID | 目的のGA4送信先を確認する |
Googleタグ | タグIDと接続された送信先 | 複数の送信先や共通設定を確認する |
GTMコンテナ | GTM-で始まるコンテナID | サイトで使うタグの管理単位を確認する |
IDの文字列だけで判断せず、管理画面で名前と対象サイトも照合します。同じブランドに複数のプロパティがある場合、テスト用へ送っていないかを確認してください。Googleタグを置いたからといって、すべての広告成果や業務上の成功が自動的に計測されるわけではありません。
既存タグを調べてCMS・直接設置・GTMを選ぶ
サイトの設定画面、テンプレート、プラグイン、GTMを調べて既存の設置経路を一覧にします。管理しやすい方法は、サイトの規模だけでなく編集権限や保守担当によって変わります。GTMを使うだけで精度が上がる、といった選び方は避けます。
方法 | 向いている管理条件 | 先に確認すること |
|---|---|---|
CMSの公式・対応連携 | CMSの管理担当が設定を保守できる | 別プラグインやGTMとの重複 |
Googleタグの直接設置 | 共通テンプレートを管理できる | 更新時の保持と戻し方 |
GTM | タグの検証・版管理・公開担当がいる | コンテナ権限と既存タグの送信先 |
たとえば、既にCMS連携でGA4が動いているサイトへGTMを導入する場合、まず目的が「追加イベント」なのか「基盤の切替」なのかを決めます。前者と後者では残す設定が違います。切替前の値、影響する送信先、問題時に戻す版を控えてから進めましょう。
CMS連携または直接設置でGoogleタグを導入する
- 対象のウェブストリームを選び、管理画面でGoogleタグの設置案内を開く。
- CMSが対応する連携なら、そのCMSの案内に従ってIDやタグを設定する。
- 直接設置なら、対象の各ページで開始<head>タグの直後にGoogleタグ全体が出力されるよう配置する。共通テンプレートを使う場合は、個別ページやプラグインで同じ送信先のタグを重ねて出力しない。
- 設置経路、担当、変更日と元に戻す方法を記録する。
公式の直接設置案内も各ページの開始<head>直後を指定しています。WordPress等では、親テーマのheader.phpを直接編集するとテーマ更新で変更が失われる場合があります。専用連携や子テーマなども含め、保守できる方法を選んでください。「どこへ貼っても動く」「この方法なら必ず安全」とは考えず、実際の出力と送信を検証します。
既存Googleタグが広告などにも使われているなら、同じスクリプトを重ねて追加する前に送信先を確認します。作業の目的はタグの本数を増やすことではなく、必要な送信経路を明確にすることです。
GTMでGoogleタグとInitializationを設定する
Google公式のGTM手順ではGoogleタグを作り、対象のタグIDを設定してInitializationのトリガーを使います。古い手順にある通常のPage ViewのAll Pagesと区別し、現在の画面で初期化の対象を確認してください。
- 対象サイトのGTMコンテナと作業スペースを選ぶ。
- 新規タグの種類をGoogleタグにし、対象のタグIDを入力する。
- 必要な共通設定とInitializationのトリガーを確認する。
- 後続のイベントタグとの関係を調べ、Previewで検証する。
- 担当者が変更内容と版を確認して公開する。保存だけでは公開完了としない。
同意状態を設定する処理は、Googleタグやイベントの処理との順番が重要です。トリガーの公式説明でConsent InitializationとInitializationの役割を確認します。単にすべてのタグを同じ初期化トリガーへ集めればよい、という意味ではありません。
公開前後に同意・送信先・イベントを確認する
下表は架空サイトの受け入れ確認例です。page_viewの送信方法やSPAの画面遷移などは、実装仕様に合わせて期待値を決めます。1回の操作で何件送るかを記録し、同じ送信先への意図しない重複を調べます。
テスト | 確認すること | 失敗の候補 |
|---|---|---|
初回ページ表示 | 対象ホスト・測定ID・想定page_view | CMSとGTMの二重送信 |
SPAで1画面移動 | 新画面が仕様どおり計測される | 自動処理と独自処理の競合 |
フォームエラー | 完了イベントを送らない | ボタンクリックを成功扱い |
受付成功と再読込 | 成功条件と重複処理 | 同じ成功を複数回送る |
同意拒否・許可 | 選択と実装方式に合う動作 | 同意状態の更新漏れ |
同意モードは選択に応じてタグの動作を変える仕組みで、同意取得そのものを代行しません。DebugViewで受信とパラメータを確認しつつ、同意状態等で見えない場合があることも考慮します。公開後は実際に配信中の版で同じテストを繰り返します。
二重計測と移行時の削除対象を判断する
重複を見つけたら、どの経路が同じ送信先へ同じイベントを送っているかを特定します。CMS連携とGTM、直貼りとGTM、拡張計測と独自SPA処理などが調査対象です。一方、別の送信先へそれぞれ1件送ることは、同じ送信先の二重計測とは分けて考えます。
GTMへ移行するときにgtag.jsを必ず全削除するのは危険です。広告や別プロパティ、旧UAから接続したGA4等を支えている可能性があります。残す送信先を確認し、重複する処理を置き換え、変更後の受信を確認して切替を完了します。旧環境を引き継いだ場合はUA終了後の記事も参照してください。
最後に、公開版、測定ID、対象ホスト、期待イベント、同意、認証やアプリへの遷移、未確認事項を引き継ぎます。完了イベントの回数と登録人数は同一ではありません。事業成果の報告には、受付成功と重複を扱う仕様まで確認する必要があります。
次に確認する内容


