GA4の測定IDとは？G-・GT-・GTM-の違いと確認方法

2026年5月28日

著者: 与謝秀作

GA4の測定IDは、Webデータストリームを識別するG-で始まるIDです。Webサイトからのデータを対応する送信先へ届けるために使います。以前の「トラッキングID」を探している場合も、GA4の測定ID、Google tagのID、GTMコンテナIDを分けて確認しましょう。

目的はIDを見つけて貼ることだけではありません。どこへ何が送られるか、既存の実装と重複しないかを確かめることが、使えるデータにつながります。

トラッキングIDを探す前に：GA4で使うIDの種類

次の例はすべて説明用のダミーです。自分のサイトには、管理画面で確認した実際のIDを使います。数字だけのプロパティIDは、WebストリームのG-測定IDとは別です。

表記例	主な役割	確認時の注意
G-EXAMPLE	GA4のWebストリームの測定ID・送信先ID	対象ストリームを確認する
GT-EXAMPLE	Google tagを識別するID	接続された送信先も確認する
GTM-EXAMPLE	Google Tag ManagerのコンテナID	GA4測定IDを入力する欄とは違う
AW-EXAMPLE	Google Adsに関係するID	Analyticsの送信先と混同しない
UA-12345-1	旧Universal AnalyticsのトラッキングID	現行GA4の測定IDとして使わない
123456789	数値のプロパティIDの例	タグの測定IDと同じものではない

Google tagには複数のIDが関連付く場合があり、G-やAW-もタグIDとして使われます。GT-だけが有効という意味ではありません。一つのタグが複数の送信先に接続される場合もあるため、接頭辞だけで構成を決めつけないでください。根拠はGoogle tagと送信先の公式説明です。

G-測定IDを管理画面で確認する

GA4で対象プロパティを選び、管理のデータストリームからWebストリームを開きます。ストリーム詳細に表示された測定IDを確認します。権限や画面構成により項目が見えない場合は、別のIDを推測せず管理者に対象ストリームを確認してください。

分析したい事業・サイトのプロパティであることを確かめる。
Webデータストリームの名前とURLを確認する。
G-で始まる測定IDを控える。
接続されているGoogle tagと送信先を確認する。
既存のサイト実装で使うIDと照合する。

測定IDはWebデータストリームに対応します。「サイトごとに必ず一つ」「プロパティIDと同じ」とは考えないようにしましょう。確認手順と必要権限は測定IDの公式ヘルプを参照できます。

Google tag・GTM・CMSの実装を棚卸しする

新しいタグを追加する前に、直書き、CMSの連携機能、プラグイン、GTMのどこで計測しているかを整理します。複数の方法が見つかっても、それだけで全部が重複しているとは限りません。送信先と発火条件を比べます。

確認する場所	記録すること
サイトに直接置かれたタグ	ID、読み込みページ、page_view等の送信
CMS・連携機能	有効な連携先、入力ID、自動送信されるイベント
GTMコンテナ	Google tag、GA4 Event、トリガー、送信先
画面遷移の実装	SPA等の履歴変更と手動・自動page_viewの関係
同意の仕組み	初期状態、更新の順序、選択の保存と再訪時の状態

削除するタグを決めるのは、この記録から同じ目的・送信先・条件の重複を特定してからです。用途が分からないタグを一括で消すと、必要な計測を失う可能性があります。

現在のGoogle tagとGA4 Eventの役割

GTMのGoogle Analytics: GA4 ConfigurationタグはGoogle tagに置き換えられています。現在の説明では、Google tagにTag ID、GA4 EventタグにMeasurement IDという役割の違いを押さえます。既存のGA4設定タグは自動更新された経緯があり、古い名称が過去資料に残っています。

Google tagは設定や送信先を扱い、GA4 Eventタグは特定のGA4ストリームにイベントを送ります。初期化などのトリガー、設定変数、同意の順序は、サイトの要件と現在の公式手順に合わせて確認します。古い画面名をそのまま探して公開する手順にはしないでください。タグ更新の公式説明と現在の設定ガイドを参照できます。

プレビューで送信先・重複・同意条件を確かめる

Tag Assistantや利用可能なデバッグ画面で、単一の閲覧・操作を行い、何がどの送信先へ届くかを確認します。Realtimeにデータが見えるだけでは、対象ホスト、重複、成果条件まで正しいとは証明できません。

架空の診断例として、同じページを一度表示したとき、直書きとGTMの両方から同じストリームへpage_viewが送られたとします。各送信元と時刻を確認できれば重複の候補になります。一方、別の送信先に一件ずつ送っている場合は、同じデータの二重計測かを目的に沿って判断します。

本番ホストかテスト環境かを記録する。
ページを一度表示し、page_viewの送信元・送信先を確認する。
対象のボタンやフォームを一度操作し、想定イベントを照合する。
同意の未選択・許可・拒否・撤回で、設計した動作になるか確認する。
必要な修正、影響範囲、戻し方を整理してから変更をレビューする。

同意状態のdefaultとupdateの順序などはConsent Modeの公式実装資料に説明されています。選択取得や保存とタグ制御は別の役割です。

データが出ないときの切り分け

直帰率が低いという理由だけで二重計測と診断することはできません。GA4の直帰率は、エンゲージドセッションではなかったセッションの割合です。固定の「20%以下」などを重複判定の基準にせず、実際のイベント送信を確かめます。

症状	次に確認する証拠	原因候補
データが見えない	タグ読込、イベント送信、対象ストリーム、処理時間	ID相違、タグ欠落、同意、遮断、表示遅延
別プロパティに届く	実装IDと送信先の対応	環境やCMS設定の取り違え
同じpage_viewが複数届く	送信元、時刻、同じ操作か	直書きとGTM、SPAの自動・手動送信の重複
同意状態で数が変わる	初期状態と更新後のタグ動作	設計通りの制御か、更新順序の問題か