GA4で問い合わせ計測を正しく行う初期設定｜中小企業サイト編

2026年10月15日カテゴリー: AI×技術コンサルティング

タグ:GA4コンバージョン計測アクセス解析Webサイト改善DX推進

GA4を入れたのに「問い合わせが何件あったのか正確に分からない」という相談は、製造業の中小企業サイトで驚くほど多い課題です。本記事では、GA4の問い合わせ計測がずれる典型パターンを整理したうえで、サンクスページ方式を軸にした確実な初期設定の手順を解説します。設定後に実件数と照合する検証方法まで押さえれば、サイト改善や広告投資の判断を数字で行える土台ができます。

なぜGA4の問い合わせ計測は「なんとなく合わない」のか

私たちはAIのPoC（効果検証）を支援する立場上、「計測が正しくないと、どんな分析も改善も意味を持たない」という場面を日常的に見ています。センサーデータの異常検知でも、そもそもセンサーの取り付けがずれていれば精度の議論は無意味です。Webサイトの問い合わせ計測もまったく同じ構造で、GA4の画面に数字が出ていること自体は、正しく測れていることを何も保証しません。実際に製造業のお客様のサイトを拝見すると、次のような状態が頻繁に見つかります。

GA4の「form_submit」イベントをコンバージョンとして見ているが、実際の問い合わせメール件数の3倍の数字になっている
問い合わせフォームが外部サービス（別ドメイン）で、送信完了がGA4にまったく記録されていない
社内や制作会社からのテスト送信が本番の件数に混ざっている

特に1つ目は深刻です。GA4の拡張計測機能が自動で記録するform_submitは、検索ボックスの送信や、入力エラーで弾かれた送信まで拾うことがあり、「問い合わせ完了」の件数としてはほぼ使えません。ここを鵜呑みにすると、広告費の判断やページ改善の優先順位をすべて誤った数字の上で行うことになります。

計測設計の第一歩は「何を1件と数えるか」を決めること

AI PoCの現場では、モデルを作る前に「何を不良品と定義するか」「どの状態を異常と呼ぶか」を関係者で合意します。これが曖昧なままだと、精度95%という数字が出ても誰も判断に使えません。問い合わせ計測も同様に、設定作業の前に定義を固めるのが失敗しない順序です。中小企業のサイトであれば、最低限次の3点を決めておけば十分です。

何を問い合わせと数えるか：フォーム送信完了のみか、電話タップや資料ダウンロードも含めるか
どの時点を完了とみなすか：送信ボタンのクリックではなく、送信完了（サンクスページ到達）を基準にする
除外する対象：社内IP、制作会社、テスト送信は数えない

たとえば外観検査装置や設備監視システムを扱うB2Bサイトなら、「フォーム送信完了」と「技術資料のダウンロード」を別々のイベントとして計測し、前者だけをキーイベント（旧コンバージョン）にする、といった設計が現実的です。電話番号タップは営業時間外の誤タップも多いため、参考指標として別管理にするのが無難です。

GA4で問い合わせ計測を設定する具体的な手順

ここからは、もっとも確実でメンテナンスしやすい「サンクスページ方式」を軸に手順を説明します。フォーム送信後に「お問い合わせありがとうございました」という完了ページ（例：/contact/thanks/）へ遷移する構成であれば、この方式が第一選択です。

手順1：サンクスページを用意し、直接アクセスを防ぐ

フォーム送信後の遷移先として専用URLのサンクスページを用意します。すでにある場合も、Google検索からの流入やブックマーク経由で直接開かれないよう、noindex設定を入れておきます。直接アクセスが混ざると件数が水増しされるためです。

手順2：GTMでサンクスページ到達時にイベントを発火させる

Googleタグマネージャー（GTM）で、ページパスが/contact/thanks/に一致したときにGA4イベントを送信するタグを作成します。イベント名はGA4の推奨イベントであるgenerate_leadを使うと、後々のレポートや広告連携で扱いやすくなります。

トリガー：ページビュー、Page Pathが/contact/thanks/に等しい
タグ：GA4イベント、イベント名generate_lead

GTMを使っていない小規模サイトなら、GA4管理画面の「イベントを作成」機能で、page_viewかつページパスがサンクスページに一致する条件からgenerate_leadを生成する方法でも代替できます。

手順3：キーイベントとして登録する

GA4の管理画面で「イベント」一覧にgenerate_leadが表示されたら（反映に最大24時間程度かかります）、キーイベントのトグルをオンにします。これで各レポートや探索機能で「問い合わせ」を軸にした分析ができるようになります。

手順4：DebugViewと実件数で二重に検証する

設定直後にGTMのプレビューモードとGA4のDebugViewで、テスト送信1件に対してイベントが1回だけ発火することを確認します。そのうえで重要なのが、翌月に実際の問い合わせメール件数とGA4の件数を突き合わせることです。誤差が1〜2割以内に収まっていれば実用上は十分、それ以上ずれるなら重複計上や計測漏れを疑います。

検証の目安
      - GA4件数 ÷ 実件数 が 0.9〜1.1 → 問題なし
      - 1.2以上 → 重複発火、直接アクセス、テスト送信の混入を疑う
      - 0.8以下 → 外部フォームの計測漏れ、タグ未発火を疑う

つまずきやすい3つのポイントと対処法

外部フォームサービスを使っている場合

フォームが別ドメインのサービス上にある構成では、サンクスページも外部ドメインになり、そのままでは計測できません。対処は2つで、フォームサービス側でGA4の計測ID設定やクロスドメイン設定が可能か確認するか、送信完了後に自社ドメインのサンクスページへリダイレクトする構成に変更するかです。後者のほうがトラブルが少なく、制作会社への依頼内容としても明確です。

自社・関係者のアクセスが混ざる

問い合わせが月10件前後の中小企業サイトでは、テスト送信2〜3件の混入が2〜3割の誤差になります。GA4の内部トラフィック定義で社内IPを除外し、制作会社にもテスト時はデバッグモードを使うよう依頼しておきます。件数が少ないほど除外設定の効果は大きい、という点は見落とされがちです。

form_submitとの二重管理

拡張計測のform_submitを残したまま両方をキーイベントにすると、レポート上の件数が実態と大きく乖離します。キーイベントはgenerate_leadに一本化し、form_submitはキーイベントから外すか、拡張計測の設定自体をオフにしておくのが安全です。実際の支援先で見た例では、設定を見直す前はGA4の件数が実件数の約3倍に膨らんでいましたが、サンクスページ方式への切り替えと除外設定で、翌月から誤差1割以内に収まりました。

GA4計測値と実際の問い合わせ件数の推移（設定見直し前後の例）

グラフを読み込み中...

6月末にform_submit依存からサンクスページ方式へ切り替え、内部トラフィック除外を設定した例。7月以降はGA4の件数と実件数の誤差が1割以内に収束している。

次の一歩：今月の実件数との突き合わせから始める

最初にやるべきことは、新しいツールの導入でも高度な分析でもなく、先月の問い合わせメールを数えて、GA4の数字と並べてみることです。ここで乖離があれば、本記事の手順1〜4を順に見直してください。この突き合わせは一度やれば終わりではなく、四半期に1回程度の定期チェックにしておくと、サイトリニューアルやフォーム変更時の計測漏れにも早く気づけます。正しく数えられるようになって初めて、「どのページ経由の問い合わせが多いのか」「技術資料のダウンロードは商談につながっているのか」という次の分析に進めます。これは私たちがAI PoCで常にお伝えしている「正しいデータの取得が、あらゆる改善の前提」という原則そのものです。外観検査のAI化でも、Webサイトの改善でも、測れないものは改善できません。まずは今月、実件数との照合から始めてみてください。