Google Analytics 4 使い方｜計測を4段階で検収する

Google Analytics 4（GA4）の使い方とは、管理画面のメニューを順番に覚えることではなく、「どの行動が問い合わせにつながったのか」という事業上の問いをeventの設計へ変換し、実装・収集・報告・事業成果の4段階で検収する一連の手順です。

画面の名前や配置は更新のたびに変わります。操作手順を暗記しても、メニューが移動した瞬間に迷子になります。一方で、「propertyにデータが届く仕組み」「eventという計測単位」「レポートに集計されるまでの流れ」という構造は安定しています。実際、Googleの開発者向けドキュメントもeventを4つの分類で説明しており（GA4のイベント解説（Google公式）、2026年7月20日確認）、この構造を軸にすれば画面が変わっても判断は変わりません。

この記事で判断できるようになること

• 自社の環境（CMS連携・直接設置・Googleタグマネージャー）に合ったタグ設置方法を選べる
• 事業上の問いからeventとkey eventを設計し、event台帳として管理できる
• DebugView・Realtime・処理後レポート・フォーム受付・CRMのどこまで確認すれば「計測できている」と言えるかを判断できる
• AIによる最適化や分析へ渡してよい信号かどうかを、定義と証拠で評価できる

本文中の外部リンクは、すべて2026年7月20日の執筆時点で開けることを確認したGoogle公式ドキュメントです。管理画面上の表記が本文と異なる場合は、リンク先の仕様を優先してください。

結論として、問い合わせ計測の土台づくりでは、property・web data stream・Measurement ID・Google tagの関係を整理し、それらを変更できるroleを自分が持っているか先に確かめることが重要です。

4つの構成要素はこうつながる

• property（プロパティ）: 計測データの入れ物。レポートはproperty単位で見ます
• web data stream（ウェブデータストリーム）: そのpropertyへ「どのサイトからデータを集めるか」を定義する単位
• Measurement ID / タグID: データストリームやタグに紐づくID。新しく作成されるGoogle tagは「GT-」プレフィックスを持ち、GA4の「G-」、Google Adsの「AW-」、Floodlightの「DC-」も引き続き使われます。旧Universal AnalyticsのUAタグはGoogle tagと互換性がありません
• Google tag（gtag.js）: サイト側に設置するタグ本体。設置後はgtag()のconfig・event・setという3コマンドで計測を制御します

タグIDの体系とコマンドの定義はGoogle tagの設定ドキュメント（Google公式）（2026年7月20日確認）に記載されています。

設置方法は「常にこれ」ではなく環境で選ぶ

かつては「タグマネージャー経由が推奨」と一律に語られがちでしたが、タグを年に数回しか触らないサイトで管理レイヤーを増やすことが常に正しいとは限りません。逆に、広告タグや計測タグを頻繁に追加する運用があるなら、版管理と公開フローは事故防止に効きます。判断軸は「タグを誰が・どの頻度で変更するか」です。

変更できるroleがあるかを先に確認する

Google Analyticsの管理APIには、viewer・analyst・editor・admin・no-cost-data・no-revenue-dataという6種類のpredefined roleが定義されています（accessBindingsリファレンス（Google公式）、2026年7月20日確認）。外注先が作成したpropertyでも、自社のroleを推測せず、event設計より先にpropertyの管理者と自分のroleを確認してください。

event設計のポイントは、GA4のeventを4つの分類で捉え、事業上の問いに答えるために必要な行動だけをevent台帳へ載せることです。

eventの4分類

GA4のイベント解説（Google公式）（2026年7月20日確認）では、eventは次の4分類で説明されています。

1. 自動収集event: タグを設置すると既定で収集される。first_visit・session_start・user_engagementなど
2. 拡張計測event: 管理画面で拡張計測を有効化すると収集される。scroll・click・file_downloadなど
3. 推奨event: 業種別に名前とparameterが標準化されたevent。標準化された名前で実装することで、レポート機能との連携が見込めます
4. カスタムevent: 上のどれにも当てはまらない行動を自分で定義する

event名を自由に発明する前に、推奨eventに該当がないかを確認する順序が安全です。

拡張計測は「全部オン」ではなく項目ごとに判断する

拡張計測は便利ですが、スイッチを全部入れることが目的ではありません。項目ごとに「この行動はどの事業上の問いに答えるのか」「同意状態や社内のデータ取り扱いルールに照らして収集してよいのか」を確認し、使うと決めた項目だけをevent台帳に載せます。誰も見ないeventを増やすと、後段の検収コストとノイズだけが増えます。

event台帳に置く項目

event台帳はスプレッドシート1枚で始められます。1行1eventで、次の列を持たせてください。

• 事業上の問い（このeventは何を判断するためにあるか）
• event name／trigger（発火条件）／parameters
• 重複条件（連打やリロードをどう数えるか）
• 除外条件（内部・開発トラフィック、テスト送信）
• 同意との関係（同意拒否時にどうなるか）
• 検証方法（DebugViewで何を見れば合格か）
• 責任者と下流照合先（フォーム受付DB・CRMなど）

なお、カスタムparameterは送るだけでは標準レポートや探索に表示されません。カスタムディメンション・カスタム指標として登録する必要があり、登録後にデータがレポートで利用可能になるまで最大48時間かかるとされています（event parametersドキュメント（Google公式）、2026年7月20日確認）。台帳のparameter列には「登録済みか」のチェック欄も足しておくと、後の検収が速くなります。

問い合わせ計測のポイントは、リード生成を表す公式の推奨eventであるgenerate_leadを検討し、「eventとして送ること」と「key eventに指定すること」を別の判断として扱うことです。

generate_leadと後続のリードevent

GA4の推奨eventリファレンス（Google公式）には、リードが生成された際のgenerate_lead、有望なリードと判定した際のqualify_lead、不適格と判定した際のdisqualify_leadが定義されています（2026年7月20日確認）。フォーム送信をgenerate_leadとするのは、実装したtriggerが実際のリード生成と一致すると確認できる場合です。実務上の線引きは2つです。

• クリックをleadにしない: CTAボタンのクリックやフォームの表示は、送信の事実ではありません。generate_leadは送信完了に対応する箇所で発火させます
• 後続eventはCRMの事実と接続できる場合だけ設計する: qualify_leadのようなeventは「基準を満たした」という判定の事実がCRM等に存在して初めて意味を持ちます。判定プロセスがないままeventだけ作ると、誰も更新しない空の指標が残ります

key eventの指定と用語の整理

事業の成功にとって特に重要なeventは、GA4上で**key event（キーイベント）**として指定できます。以前の解説記事によくあった「コンバージョンとしてマークする」という操作は、現在の用語ではこのkey event指定にあたります。仕様上の性質は、Google Analytics Data APIのスキーマ定義が簡潔です。

任意のeventをkey eventとして指定でき、first_openやpurchaseなど一部のeventは既定でkey eventになっています。key eventへの指定は指定時点以降のレポートに影響し、過去のデータは変わりません（Data APIスキーマのisKeyEvent定義（Google公式）、2026年7月20日確認）。

指定しても過去に遡って集計されない以上、key eventの指定は計測開始の初期に済ませる価値があります。あわせて、次の6つは記録される場所も定義も異なるため、同じ「成果」という言葉でまとめないでください。Google Ads側で扱うコンバージョンも広告アカウント側の別概念であり、GA4のkey eventと同義に説明しない運用が安全です。

parameterに個人情報を入れない

event name・parameter・URLには、メールアドレス・電話番号・氏名のような個人を特定できる値を入れない設計にします。仕様上も、たとえばuser_idは最大256文字で、それ自体が個人を特定できる情報（PII）であってはならないと明記されています（configリファレンス（Google公式）、2026年7月20日確認）。問い合わせの中身はフォーム受付側とCRMに置き、GA4には「送信があった」という事実だけを渡すのが安全な分担です。

検収のポイントは、実装証拠・収集証拠・報告証拠・事業証拠の4段階を分けて確認し、どれか一つの画面だけで「計測できている」と判断しないことです。

4段階の検収表

公式の検証ガイドは、DebugViewを有効にするとサイトやアプリを操作しながらeventをリアルタイムに確認できるとし、タグが正しく発火していればRealtimeレポートには数分以内にデータが表示され始めるとしています。一方で、標準レポートの多くのデータは処理に24〜48時間かかるとも明記されています（計測の検証ガイド（Google公式）、2026年7月20日確認）。「Realtimeに自分のアクセスが出たから設定完了」という判定は、4段階のうち2段階目の途中までしか見ていません。設置直後の生存確認としては有効ですが、完了条件にはなりません。

悪い入力をわざと試す

正常系だけの確認では、公開後のずれに気づけません。次の入力を意図的に発生させ、event台帳の重複条件・除外条件が機能するかを見ます。

• 送信ボタンの連打・完了ページのリロード（重複発火として数えていないか）
• 送信失敗（サーバーエラー時にも完了eventが飛んでいないか）
• 同意拒否の状態での送信（どの段階から欠損するか）
• 検証端末・社内・開発環境からのアクセス（除外設定が効いているか）
• botらしき送信（フォーム側の対策と突き合わせる）

差分は「悪」ではなく記録対象

GA4とフォーム受付の件数には、実装、同意状態、ブラウザ環境、bot対策、処理時差などによって差が生じる場合があります。ただし、最初から不一致を正常だと決めません。期間、対象event、タイムゾーン、重複排除条件を固定して突合し、差分を「理由を確認できたもの」と「未確認」に分けます。未確認の差分が残る場合は、実装、除外、同意、受付側の記録を再検査します。ここまで整った計測を、LPの役割と設計を見直す判断材料にします。

AIによる最適化や分析へ計測データを渡す前には、同意状態の影響範囲と、key eventが有効問い合わせにどう接続するかを証拠で確認することが必要です。この2点を最後の受入条件にします。

consent modeは「バナー」ではなく「伝達の仕組み」

consent modeは、ユーザーの同意選択をtagやアプリSDKへ伝え、その挙動を調整する仕組みです。同意を取得するbannerやCMPそのものではありません。consent modeの概念解説（Google公式）は、basicとadvancedの実装を分けています。basicでは同意操作までGoogle tagの読み込みを止め、同意前はGoogleへデータを送りません。advancedでは既定の同意状態を設定してtagを読み込み、同意が拒否された場合はcookieを使わないpingを送ることがあります。モデリングは一定の要件を満たす場合の機能であり、欠損の完全な補完を保証しません（2026年7月20日確認）。

つまりconsent modeを実装しても、法的な適合が保証されるわけでも、未同意ユーザーを完全に計測できるわけでもありません。同意設計には法務判断が含まれるため、個別の適合性は専門家と確認してください。計測側でできるのは、「同意拒否時にどのeventがどこから欠けるか」をevent台帳に書き、欠損を前提にレポートを読むことです。

AIに渡す信号は「量」より「定義」

GA4でkey eventに指定しただけで、任意の自動入札やAI分析へ自動的に「正解データ」として渡るわけではありません。別システムへ連携し、そのシステムが信号を利用する設定では、誤発火、重複、bot、欠損を含む入力が判断へ影響し得ます。連携前のチェックは4つです。

• 定義: key eventは有効問い合わせに対応しているか。CTAクリックやフォーム表示を昇格させていないか
• 誤発火と欠損: 悪い入力テストで重複・失敗送信・除外もれを潰したか。同意拒否による欠損範囲を把握しているか
• 照合: 期間を区切ってフォーム受付・CRMと件数を突き合わせたか
• 判断の残し方: チャネル別の数字が動いたとき、母数・計測の時差・同意状況を確認してから予算を判断する手順になっているか。速報値やチャネル別CVRの一点だけで予算を増減しない

この確認に合格しても、AIによる最適化や分析の成果は保証されません。合格は、その信号を設定済みの分析・最適化へ渡す候補にできるという受入判定です。不合格なら連携を保留し、誤発火、重複、欠損、定義、照合方法を直します。計測の検収は、広告計測ツールの比較やAI活用に進む前の工程です。

GA4の設置・event・key event・検収について、本文で定めた条件を別の実務判断に当てはめるポイントは以下の通りです。

Q1. GA4のタグはGoogleタグマネージャー経由で設置しないとだめですか？

いいえ。設置方法は環境で選びます。Measurement IDを入力するだけで連携できるCMSならその機能で足りる場合がありますし、タグの追加・変更が頻繁なら版管理と公開フローが事故防止に効きます。判断軸は「誰が・どの頻度でタグを変更するか」です。どの方法を選んでも、設置後の4段階検収は同じように必要です。

Q2. 拡張計測の項目はすべてオンにしておくべきですか？

一律のオンは推奨できません。項目ごとに「どの事業上の問いに答えるか」「同意や社内のデータ取り扱いルールに照らして収集してよいか」を確認し、使うものだけをevent台帳に載せます。台帳にない自動eventが増えるほど、検収対象が膨らみ、レポートのノイズも増えます。

Q3. key eventに指定すれば、有効な問い合わせを計測できたことになりますか？

なりません。key eventは「GA4上で重要と指定したevent」であり、記録されるのは送信操作までです。しかも公式仕様上、指定が影響するのは指定時点以降のレポートで、過去データには遡りません（Data APIスキーマ（Google公式）、2026年7月20日確認）。サーバーが受理したか、営業対象として有効か、商談化したかは、フォーム受付とCRMでしか確認できません。

Q4. DebugViewにeventが出ていれば、本番の確認は省略できますか？

省略できません。DebugViewが証明するのは検証端末での実装だけです。本番での受信はRealtimeで、集計は処理後の標準レポートで確認します。標準レポートの多くのデータは処理に24〜48時間かかるとされているため（計測の検証ガイド（Google公式）、2026年7月20日確認）、設置当日に処理後レポートの数字で判断しないことも大切です。

Q5. GA4の問い合わせ数とフォームの受付件数が合いません。どう照合すればよいですか？

まず期間、対象event、タイムゾーン、重複排除条件を固定して件数を並べます。重複発火、送信失敗、同意拒否、内部・開発トラフィック、botを順に確認し、差分を理由確認済みと未確認に分類します。完全一致もしない前提も置かず、未確認の差分が残る場合は実装、除外、同意、受付側の記録を再検査します。

計測の完了条件で重要なのは、「画面に数字が出た」ではなく、実装・収集・報告・事業成果の4段階それぞれの証拠で定義することです。GA4の使い方を「画面の順路」から「検収の順序」へ置き換えると、管理画面が変わっても迷わなくなります。

最後にもう一度、順序だけ

1. property・web data stream・Google tagの関係と、自分のroleを確認する
2. 事業上の問いからeventを設計し、event台帳に載せる
3. 問い合わせにはgenerate_leadを検討し、key event指定は別の判断として初期に済ませる
4. DebugView→Realtime→処理後レポート→フォーム受付・CRMの4段階で検収する
5. 検収を通った信号だけを、AIによる最適化や分析へ渡す

計測は「変更のたびに回す手順」として残す

計測は一度作って終わりではありません。フォームの改修やサイトの更新のたびに壊れます。event台帳と4段階検収を社内の手順として残せるかどうかが、ツールの機能理解よりも成果に効きます。台帳が1枚あれば、担当者が替わっても「なぜこのeventがあるのか」から引き継げます。

くるみは、AIを物量と速度のエンジンに、人の目利きを質の担保にするAIグロースファームとして、計測設計からAIを前提とした改善サイクルの実装までを支援しています。「GA4は入れたが、問い合わせの数字を信じてよいか分からない」という段階のご相談も歓迎します。まずは自社のevent台帳づくりから始めてみてください。