2026/11/05 · アクセス解析

GA4のform_submitが実際の問い合わせより多い・二重になる原因｜拡張計測機能のフォーム操作をオフにすべきかの判断とGTMで計測し直す手順

Q: formstartとformsubmitの違いは？form_startの方が多いのは異常？

formstart は、セッション内でフォームに最初に触れたときに1回発火するイベントです。formsubmit は送信操作を数えるイベントなので、formstart のほうが多いのは正常です。異常なのは、formsubmit が実際の問い合わせ件数を上回る場合です。

GA4のform_submitが実際の問い合わせ数より多い・二重になる原因を4系統に分け、探索レポートで見分ける方法を解説します。拡張計測機能のフォーム操作をオフにすべきかの判断表と、GTMで送信成功だけを数え直す手順、キーイベントやGoogle広告CVの付け替え方までまとめました。

この記事のポイント

GA4のform_submitが多い主因は、拡張計測機能が送信の成功ではなく試行を数え、フォーム以外も拾う仕様にある。

多い原因はMetaピクセル由来・送信失敗の試行・二重送信・再送信の4系統で、form_destinationとform_idで切り分けられる。

拡張計測機能のフォーム操作は設定で精度を上げられないため、主要CVに使っているならオフにしてGTMで計測し直すのが妥当である。

キーイベントとGoogle広告のCVは、新旧を並行計測して件数を確認してから、メインからサブへの順で付け替える。

GA4の form_submit が、フォームの通知メールの件数より明らかに多い。そのキーイベントを広告の入札に使っていたとしたら、成果報告もスマート入札も、実態より甘い数字を前提に動いていることになります。

ここで「設定のどこかを直せば合う」と考えてしまうのが、よくある落とし穴です。拡張計測機能のフォーム操作には、対象フォームや送信成功の条件を指定する項目がありません。直す対象は設定ではなく、計測の作り方そのものになります。

この記事では、form_submit が多くなる仕組み、原因を5分で切り分ける手順、フォーム操作をオフにするかの判断、Google タグマネージャー（GTM）での計測し直し、キーイベントと Google広告の付け替えまでを順に説明します。2026年時点の仕様を前提にしています。

フォームの件数が合わない、広告担当の夜

GA4のform_submitが実際の問い合わせより多くなるのはなぜ？

Google アナリティクス 4（GA4）の拡張計測機能は、フォームの送信が成功したかどうかではなく、ブラウザ上でフォームの送信操作が行われたことを数えます。そのため入力エラーで弾かれた試行も、フォームではない仕組みが作った一時的な送信も、form_submit として記録されます。

拡張計測機能とは、GA4の web データストリームで有効にすると、タグの追加なしにスクロールや外部リンクのクリック、フォームの操作などを自動計測する機能です。手軽な反面、何を数えるかは Google 側の固定ルールで決まります。

form_startとform_submitが発火する条件

form_start は、セッション内で訪問者が初めてフォームに触れたときに1回発火します。form_submit は、ブラウザ上でフォームの submit イベントが起きたときに発火します。

つまり form_start が form_submit より多いのは正常です。気にすべきは、form_submit が実際の問い合わせ件数を上回るときのほうです。

どちらのイベントにも form_id、form_name、form_destination、form_length、form_submit_text といったパラメータが付きます。後の切り分けで使うのは、主に form_id と form_destination です。

設定で精度を上げられない仕様上の限界

Optimize Smart の解説記事では、拡張計測のフォーム操作には対象フォームや送信成功を条件にする設定がないため、誤検知を設定で直せないと指摘されています。そのうえで、主要なCVは GTM で送信成功を条件に送り、拡張計測は使わないか補助に留める分け方が勧められています。日本の実務でも同じ構造なので、この考え方はそのまま使えます。

MeasureSchool の解説では、さらに逆方向の問題も挙げられています。Ajax で送るフォームや iframe 内のフォームは拾えないことがあります。多く出る誤検知と少なく出る取りこぼしが同時に起きるわけです。件数がたまたま合っていても、中身が正しいとは限りません。

form_submitが多い原因は4系統｜どれに当たるかの見分け方

図1: form_submitが増える4系統の見分け方

form_submit が多くなる原因は、Metaピクセル由来、送信失敗の試行の計上、GTMや直書きタグとの二重送信、リロードや戻るボタンによる再送信の4系統に分かれます。複数が重なることも珍しくありません。

Metaピクセル由来（form_destinationがfacebook.com/tr）

Metaピクセルは、動作の過程で一時的なフォームを作って facebook.com/tr へ送信し、すぐに消すことがあります。Analytics Mania の記事では、これを GA4の拡張計測や GTM のフォーム送信トリガーがフォーム送信として拾い、フォームのないページでも form_submit が出ると説明されています。

見分けは簡単で、form_destination が facebook.com/tr を含んでいれば、この系統です。Meta広告と併用している日本の中小サイトで起きやすい一方、日本語ではあまり説明されていません。Metaピクセル側の挙動を確かめたい場合は、Metaピクセルのイベント反映の切り分けも参考になります。

入力エラーや送信失敗の試行まで数えている

必須項目の未入力などで送信できなかったときも、submit イベント自体は起きています。このため、1人の訪問者が3回エラーを出してから送れば、form_submit は3件になります。

form_destination が自社のフォーム送信先で、form_id も自社フォームのものなのに件数だけ多い場合は、この系統を疑います。フォームの入力チェックが厳しいサイトほど差が開きやすい傾向があります。

GTMや直書きタグとの二重送信

GTMのタグと、サイトに直書きした gtag.js のタグの両方が form_submit を送っていると、1回の送信が2件になります。拡張計測が自動で送るものに加えて、GTM側でも同名のイベントを作っているケースも同じです。

同じ秒に同じ form_id の form_submit が2件並ぶなら、この系統です。切り分けの詳細は GA4イベントが重複計測される原因と切り分けにまとめています。

近年はもう一つ増えています。DEV Community の記事では、Measurement Protocol でサーバー側からリードを送りつつブラウザ側のタグも残すと、ほとんどのリードを二重に数えると指摘されています。送信元を一つに決めるのが原則です。サーバーサイド GTM や CRM 連携を進める企業が増えれば、日本でも同じ事態が起きるはずです。

リロードや戻るボタンによる再送信

送信後のページでリロードしたり、ブラウザの戻るボタンで戻って再送信したりすると、実際の問い合わせは1件でも form_submit が増えます。サンクスページ条件の計測でも、リロードで page_view が増えて同じことが起きます。

この系統を疑う目安は、同じ訪問者が短時間に同じ page_location で繰り返し発火している状態です。本当に問い合わせが重複して届いているなら、スパムの可能性もあるので、スパム送信が止まらない時の対処と合わせて確認してください。

探索レポートでform_idとform_destinationを並べる手順

手順は次のとおりです。

管理画面の「カスタム定義」で、form_id と form_destination をイベントスコープのカスタムディメンションとして登録する（未登録だと探索レポートに出てこない。登録以前のデータには遡って反映されない）
「探索」で空白のレポートを作り、ディメンションに「イベント名」「form_id」「form_destination」「ページの場所（page_location）」を入れる
指標に「イベント数」を入れ、イベント名を form_submit に絞る
件数の多い行から、次の表のどれに当たるかを見る

見え方	疑う系統
form_destination が facebook.com/tr	Metaピクセル由来
自社フォームの送信先で、問い合わせ件数より多い	送信失敗の試行
同時刻に同じ form_id が2件ずつ	二重送信
同一ユーザーが同じページで反復	再送信

登録前のデータを今すぐ見たい場合は、DebugView で実際にフォームを送信し、パラメータを直接確認するのが早いです。

拡張計測機能のフォーム操作はオフにすべき？判断表

拡張計測機能のフォーム操作は、主要な問い合わせ件数やキーイベントの根拠として使っているなら、オフにして GTM で計測し直すのが基本です。設定で精度を上げる手段がない以上、残す理由があるのは分析の補助として使う場合に限られます。

オフにしてよいサイトの条件

次の表で、自社がどれに当たるかを確認してください。

状況	判断
form_submit をキーイベントや広告CVに使っている	すぐオフ（GTMで計測し直す）
Metaピクセルを使っていて facebook.com/tr が混ざる	すぐオフ
件数は参考値としてしか使わず、CVは別イベントで取っている	条件付きで残す
form_start を離脱分析に使いたい	残して、form_submit だけキーイベントから外す

「ケースによる」で迷う場合は、上から順に当てはめてください。最初の2つのどちらかに当たれば、迷わずオフです。

オフにすると消えるもの・残るもの

フォーム操作をオフにすると、form_start と form_submit の自動計測が止まります。過去に溜まったデータは残ります。GTM で自作したイベントや、他の拡張計測（スクロール・外部リンクのクリック等）は影響を受けません。

見落としやすいのは、これらのイベントを前提にしたレポートや、オーディエンス、キーイベントの設定です。オフにした瞬間に件数がゼロになるので、先に代替の計測を用意しておく必要があります。順番は後述します。

form_startを離脱分析に残したい場合

form_start だけを分析に使いたいときは、拡張計測のフォーム操作は残したまま、キーイベントのマークだけを form_submit から外します。ただし、フォーム操作は一括でオン・オフするものなので、form_submit だけをオフにすることはできません。

Metaピクセル由来の form_submit が混ざる問題は残るため、探索レポートでは form_destination で除外して見てください。分析の純度を優先するなら、form_start も GTM で自作する選択肢があります。

フォーム操作をオフにする手順

設定をオフにして、DebugViewで確認

フォーム操作は、GA4 のデータストリームの設定画面にある拡張計測機能の歯車から、「フォームの操作」のトグルをオフにするだけで止まります。

GA4の管理画面を開き、「データストリーム」から対象の web ストリームを選ぶ
「拡張計測機能」の歯車アイコンを押す
「フォームの操作」のトグルをオフにして保存する

反映の確認には DebugView を使います。自分の端末をデバッグ状態にしてフォームを送信し、form_start と form_submit が出ないことを見てください。反映までに少し時間がかかることがあります。DebugView に何も出ないときは、DebugViewにイベントが表示されない時の確認手順を見てください。

オフにした日付は必ず記録しておきます。これを忘れると、数か月後に「この日を境に件数が落ちた」と誰かが原因探しを始めます。

GTMでフォーム送信を正確に計測し直す手順

送信成功だけを数えるには、Google タグマネージャー（GTM）で、フォームの種類に合った「成功の合図」を条件にしたイベントを作ります。拡張計測の自動検知に頼らず、成功を示す事実を自分で選ぶ作業です。

サンクスページがある場合：ページビュー条件

送信後にサンクスページへ遷移するフォームなら、最も確実で壊れにくい方法です。GTM で「ページビュー」トリガーを作り、条件に Page Path が「/thanks/」を含む、などの条件を指定します。そのトリガーで、GA4 イベントタグ（イベント名 generate_lead）を発火させます。

注意点は、サンクスページを直接開いたりリロードしたりすると、再び計測されることです。完全に防ぐなら、ページのリファラや送信時の一時データを条件に加える方法がありますが、まず実用上は、サンクスページが検索エンジンにインデックスされない設定にしておく程度で十分なケースが多いと言われます。

Ajaxフォーム（Contact Form 7など）：成功イベント

Contact Form 7 のような Ajax 送信のフォームは、ページ遷移がなく、ブラウザの submit イベントとも結果が一致しません。そのため拡張計測も GTM のフォーム送信トリガーも当てになりません。代わりに、送信成功時に Contact Form 7 が出す wpcf7mailsent イベントを使います。

GTM のカスタム HTML タグに、次のようなコードを入れ、全ページで発火させます。

<script>
document.addEventListener('wpcf7mailsent', function (e) {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'cf7_mailsent',
    cf7_form_id: e.detail.contactFormId
  });
}, false);
</script>

そのうえで、GTM に「カスタムイベント」トリガー（イベント名 cf7_mailsent）を作り、GA4 イベントタグを紐づけます。入力エラー時は wpcf7mailsent が出ないため、送信成功だけが数えられます。なお、発火しないときの原因は GTMのフォーム送信トリガーが発火しない原因と対処で整理しています。

iframeや外部フォーム：要素の表示やpostMessage

iframe で埋め込まれた外部フォームは、親ページ側から中身が見えません。選択肢は2つあります。

完了メッセージの要素が表示されたことを、GTM の「要素の表示」トリガーで拾う（同一ドメイン内のフォームのみ）
外部フォームのサービスが postMessage で完了を通知してくれるなら、その通知をカスタムイベントとして受ける

外部ドメインのフォームで、どちらも使えないなら、サンクスページ側にリダイレクトする設定ができないかをサービスの設定で確認してください。それも難しい場合は、サービス側の完了通知（メールや管理画面の件数）を正とし、GA4 は補助指標に留める割り切りも現実的です。

イベント名はgenerate_leadを推奨する理由

自作するイベント名は、form_submit ではなく generate_lead を勧めます。generate_lead は GA4 の推奨イベントで、見込み顧客の獲得を表す名前として定義されています。

form_submit は拡張計測が自動で付ける名前なので、既存のデータと意味が混ざります。別の名前にしておけば、新旧の件数を並べて比較でき、キーイベントの付け替えも安全に進められます。

キーイベントとGoogle広告のコンバージョンを付け替えるときの注意点

図2: 新旧並走から付け替えまでの4ステップ

付け替えの鉄則は、新しい計測を先に走らせて件数を確認し、確認が取れてから旧計測を外すことです。順番を逆にすると、広告のスマート入札が学習していたコンバージョンが突然消え、入札が乱れるおそれがあります。

新旧を並行計測して件数を突き合わせる

まず generate_lead を GTM で送り始め、GA4 側で generate_lead をキーイベントとしてマークします。この時点では form_submit のキーイベントも残します。

1〜2週間ほど並走させ、generate_lead、form_submit、フォームの通知メールの件数を並べて見ます。generate_lead が通知メールの件数とほぼ一致していれば、新計測は信頼できます。

Google広告でメインからサブへ切り替える順番

Google広告にインポートしているコンバージョンは、「メインのアクション」と「サブのアクション」に分けられます。メインに設定したものが、入札の最適化に使われます。

順番は次のとおりです。

generate_lead のキーイベントを Google広告にインポートし、最初はサブで並走させる
件数と傾向が確認できたら、generate_lead をメインに切り替える
旧 form_submit をサブに下げる（メインから外す）
数週間様子を見てから、不要なら旧コンバージョンを削除する

「含める」「含めない」の考え方はコンバージョンの「含める」「含めない」の判断で扱っています。切り替え直後は学習のために入札が不安定になる場合があるため、予算の大きな変更や CR の差し替えと同じ週には重ねないのが安全です。連携が反映されないときは、GA4キーイベントがGoogle広告に反映されない時の対処を確認してください。

過去の過大値はレポートに注記する

過去の form_submit は、あとから修正できません。オフにした日、generate_lead に切り替えた日を、レポートの脚注や運用メモに残してください。

月次報告では、「この日以降、CVの定義が送信成功に変わったため、前月比は参考値」と明記するのが誠実です。件数が落ちたように見えても、実態が悪化したわけではありません。

計測し直した後に件数が合っているか確かめる方法

通知メールと件数がぴたり一致

検収は、DebugView でその場の動作を確かめ、フォームの通知メール、CRM の件数と、期間単位で突き合わせる、という二段構えで行います。どちらか一方だけでは見落としが出ます。

DebugView では、自分でテスト送信して generate_lead が1回だけ出ること、入力エラーの段階では出ないこと、Metaピクセル由来の form_submit が出ないこと（オフにしていれば出ない）を確認します。

次に、1〜2週間分の generate_lead の件数を、通知メールの件数と CRM の登録件数に並べます。数件のずれは、広告ブロッカーや同意バナーによる計測漏れで起きるため、完全一致を求めすぎないことです。ずれが大きいなら、二重送信か取りこぼしのどちらかを疑います。

よくある質問

Q：form_startとform_submitの違いは？form_startの方が多いのは異常？

form_start は、セッション内でフォームに最初に触れたときに1回発火するイベントです。form_submit は送信操作を数えるイベントなので、form_start のほうが多いのは正常です。異常なのは、form_submit が実際の問い合わせ件数を上回る場合です。

Q：フォーム操作をオフにすると過去のform_submitデータは消える？

過去のデータは消えず、修正もされません。オフにした日付はレポートに注記して、前後の件数を単純比較しないようにしてください。

Q：フォームがないページでform_submitが出るのはなぜ？

Metaピクセルが一時的に作るフォームが原因のことが多いです。form_destination が facebook.com/tr になっていないかを、探索レポートか DebugView で確認してください。

Q：form_submitをそのままキーイベントにしても良い？

過大計測の恐れがあるため、推奨しません。送信成功を条件にした generate_lead を GTM で作り、そちらをキーイベントに付け替えるほうが安全です。

Q：Contact Form 7でform_submitが計測されない・多いのはなぜ？

Contact Form 7 は Ajax で送信するため、ブラウザの submit イベントと送信結果が一致しません。そのため、取りこぼしと過大計測が同時に起きます。送信成功時に出る wpcf7mailsent イベントを GTM で受けて計測してください。

真策堂では、GA4・GTM・Google広告のコンバージョン設計について、こうした観点で相談を受けています。計測の見直しや、広告成果の数字が信用できないといったお悩みがあれば、お気軽にご相談ください。

Contact

広告運用・マーケティングのご相談はこちらから
お問い合わせフォーム・公式LINEのどちらでもOK

お問い合わせフォーム公式LINEで相談