問い合わせフォームで離脱される7つの原因と改善方法

問い合わせフォームで離脱される原因は、入力項目の多さだけではありません。入力前に必要な時間や送信後の流れが分からない、必須項目や入力形式が伝わらない、エラーを修正できない、スマートフォンで操作しづらい、個人情報の扱いに不安がある、CTAで期待した内容とフォームが一致しない、送信処理が正常に動かないという7つの原因があります。改善するときは、GA4のform_start、form_submit、generate_leadを区別し、フォームを見た人、入力を始めた人、送信操作をした人、受付が完了した人のどこで減っているかを確認します。項目を一律に削るのではなく、離脱地点と原因を特定してから変更することが、問い合わせの量と質を両立させる基本です。
目次
問い合わせフォームの離脱とは?入力開始後に送信されない状態
問い合わせフォームの離脱とは、フォームを表示した、または入力を始めたユーザーが、受付完了まで到達せずページを離れる状態です。「お問い合わせ」ページの閲覧数と送信件数だけを比べても、フォームを見る前に離脱したのか、入力途中で止まったのか、送信エラーが起きたのかは分かりません。フォーム表示、入力開始、送信操作、受付完了を分けて計測する必要があります。
ホームページから問い合わせが来ないとき、検索流入やサービスページの閲覧が不足しているなら、フォームを直す前に集客やCV導線を改善します。一方、問い合わせページへの遷移と入力開始が十分にあるのに完了しない場合は、問い合わせフォームが優先課題です。フォームだけを切り離さず、検索から問い合わせまでの流れの中で判断します。
| 段階 | ユーザーの状態 | 確認する指標 | 主な問題 |
|---|---|---|---|
| フォーム表示 | 問い合わせページを開いた | ページユーザー数 | CTAとの不一致、説明不足 |
| 入力開始 | 最初の項目を操作した | form_startユーザー数 | 項目数、入力負荷、操作性 |
| 送信操作 | 送信ボタンを押した | form_submitユーザー数 | 入力エラー、送信処理 |
| 受付完了 | 正常に受け付けられた | generate_leadユーザー数 | 通信、完了判定、計測不具合 |
| 有効判定 | 事業対象の相談だった | 有効問い合わせ数 | ターゲット、訴求、条件 |
フォーム開始率(%)=form_startユーザー数 ÷ 問い合わせページのユーザー数 × 100
フォーム完了率(%)=generate_leadユーザー数 ÷ form_startユーザー数 × 100
離脱率を示す場合は、どの段階を分母にしたかを必ず明記します。「フォーム離脱率」という名称だけでは、ページ閲覧からの離脱なのか、入力開始後の離脱なのかを区別できないためです。
関連記事:
ホームページから問い合わせが来ない原因は?データでわかる改善方法
問い合わせフォームを改善する前に技術的不具合を確認する
問い合わせフォームの離脱対策では、最初に送信機能が正常に動いているかを確認します。フォームの項目やデザインを改善しても、エラーで送信できない、完了ページが表示されない、通知メールが届かない状態では問い合わせにつながりません。特にCMSやプラグインの更新後、スパム対策の変更後、タグの追加後には、表示上は問題がなくても送信処理だけが止まることがあります。
パソコンとスマートフォン、主要ブラウザ、通常回線とモバイル回線でテストし、入力開始から自動返信メールまでを一連で確認します。テスト送信では、次の項目を記録してください。
- 必須項目を正しく入力すれば送信できるか。
- 入力エラーが起きたとき、該当項目へ戻れるか。
- エラー後も入力済みの内容が残っているか。
- 二重送信を防ぎながら、一度目の送信を妨げていないか。
- 完了ページまたは完了メッセージが表示されるか。
- 管理者通知とユーザー向け自動返信が届くか。
- 迷惑メール判定や受信制限で通知が失われていないか。
- GA4の完了イベントが一回だけ記録されるか。
テスト送信が成功しても、計測イベントが正しいとは限りません。フォームの受付、メール通知、GA4計測を別々に確認し、どの処理が成功したかを区別します。
原因1|入力項目が多い、または初回相談には重すぎる
問い合わせフォームで離脱する代表的な原因は、初回相談に必要のない情報まで必須入力にしていることです。会社名、氏名、メールアドレス、相談内容だけで受付できるにもかかわらず、詳細な予算、希望納期、従業員数、住所、複数のアンケートを必須にすると、入力前に負担が大きいと判断されます。ただし、項目を減らすほど成果が上がると一律に考えることもできません。
営業担当者が初回対応するために必要な項目と、商談後に確認できる項目を分けます。予算や希望時期が案件の受付判断に必要なら、削除するのではなく選択式や任意項目に変える方法があります。自由記述欄には回答例を示し、何を書けばよいか迷わせないようにします。
改善前には、各項目について「この情報がなければ初回返信できないか」を確認してください。回答が「いいえ」であれば、任意化、選択式への変更、初回相談後への移動を検討します。入力項目数ではなく、ユーザーが感じる判断負荷と営業運用の両方から決めることが重要です。
原因2|必須項目・入力形式・所要時間が分からない
フォームを開いた時点で、何を入力するのか、どれくらい時間がかかるのか、どこまでが必須なのかが分からないと、ユーザーは入力を始めにくくなります。「必須」を色だけで示す、電話番号のハイフン有無を送信後に知らせる、自由記述欄の目的を説明しないといった設計は、入力エラーとやり直しを増やします。
W3CのWeb Accessibility Initiativeは、入力欄にラベルまたは説明を設け、ユーザーが求められる情報を理解できるようにすることを案内しています。必須・任意、入力例、文字数、使用可能な文字、日付や電話番号の形式は、入力する前に確認できる位置へ表示します。プレースホルダーだけをラベル代わりにすると、入力後に項目の意味を確認しづらくなるため、画面上に残るラベルを用意します。
フォームの冒頭には「入力項目は5つです」「所要時間は約3分です」「内容を確認後、2営業日以内に返信します」のように、実際の運用に合った目安を示します。根拠のない短時間表示や、守れない返信期限を掲載してはいけません。
原因3|エラーの場所と修正方法が分からない
送信ボタンを押した後に「入力内容に誤りがあります」とだけ表示されても、ユーザーはどこを直せばよいか判断できません。画面上部に戻されて入力欄が見えない、赤色だけでエラーを示す、入力済みの内容が消えるといった状態も離脱につながります。エラーは発生を知らせるだけでなく、修正して送信できるところまで支援する必要があります。
W3Cは、エラーメッセージを理解しやすい文章にし、対応する項目と修正方法を示すよう案内しています。エラーのある項目の近くに「メールアドレスを半角で入力してください」など具体的な文章を表示し、画面上部にもエラーの一覧を設けます。キーボードや読み上げ機能を利用する人がエラーへ移動できるよう、フォーカスやラベルとの関連も確認します。
リアルタイム検証を使う場合は、入力途中で警告を出し続けないようにします。項目からフォーカスが外れた時点や、送信操作をした時点など、修正できるタイミングで通知します。エラー後も、パスワードや決済情報などを除き、入力済みの内容を保持します。
原因4|スマートフォンで入力しづらく、自動入力も使えない
スマートフォンでは、入力欄が小さい、ボタン同士が近い、キーボードで送信ボタンが隠れる、画面の拡大が必要といった問題が離脱を招きます。パソコンで正常に送信できても、スマートフォンでは郵便番号や電話番号の入力時に不適切なキーボードが表示されることがあります。問い合わせの流入デバイスに合わせ、実機で確認することが必要です。
入力欄には内容に合ったtype、name、autocomplete属性を設定し、ブラウザの自動入力を利用できるようにします。氏名、会社名、メールアドレス、電話番号、住所などを毎回手入力させないことは、特にスマートフォンの負担軽減につながります。ラベルと入力欄を正しく関連づけると、ラベル部分も操作対象になり、読み上げ機能や音声入力でも項目を識別しやすくなります。
確認画面を設ける場合は、戻る操作で入力内容が消えないかも確認してください。入力内容を確認できる利点がある一方、ページ遷移が増えることで完了までの手順も増えます。確認画面の有無は慣習ではなく、誤送信リスクと実際の離脱データから判断します。
関連記事:
原因5|個人情報の扱いと送信後の流れに不安がある
問い合わせフォームでは、ユーザーが会社名、氏名、連絡先、相談内容などを企業へ渡します。入力操作が簡単でも、情報の利用目的、返信方法、営業連絡の扱いが分からなければ送信をためらいます。プライバシーポリシーへのリンクを置くだけでなく、フォーム付近で送信後に何が起きるかを簡潔に説明します。
「原則2営業日以内に担当者からメールで連絡します」「入力内容はお問い合わせへの回答に使用します」など、実際の受付体制に沿った文章を掲載します。資料請求後に電話連絡を行う場合や、メールマガジンへ登録する場合は、その事実を事前に分けて示します。問い合わせへの同意と広告配信への同意を一つにまとめず、ユーザーが選択できる設計にします。
会社概要、所在地、担当部署、対応時間、よくある質問、相談事例なども不安の軽減につながります。ただし、フォーム内へ長い説明を追加すると入力欄が見つけにくくなります。詳細は関連ページへ分け、フォーム上では送信判断に必要な要点を示します。
原因6|CTAで期待した相談内容とフォームが一致していない
サービスページでは「無料相談」、記事では「資料を見る」と案内していたのに、遷移先が共通の「お問い合わせフォーム」だけでは、ユーザーは自分の目的に合うか判断できません。フォーム内の選択肢に該当する相談種別がない、CTAで無料と伝えたのに費用説明がない、資料請求なのに詳細な商談情報を求める場合も離脱につながります。
CTAの文言、フォームのタイトル、相談種別、送信ボタン、完了メッセージを一つの体験としてそろえます。「ホームページ改善について相談する」から遷移した場合は、相談種別をあらかじめ選択する、またはフォーム冒頭で対象サービスを明示する方法があります。ユーザーに同じ選択を繰り返させず、どのページから来たかを計測用パラメータで取得します。
フォームを共通化する場合も、問い合わせ種別を選びやすく整理し、営業目的の連絡、採用応募、既存顧客のサポートなど、受付経路を分けます。件数だけでなく、正しい担当部署へ届くことまでをフォーム設計の成果として考えます。
関連記事:
原因7|送信処理・スパム対策・計測に不具合がある
見た目や入力項目に問題がなくても、JavaScriptエラー、外部フォームとの連携、スパム判定、通信タイムアウト、完了ページの設定によって送信が止まることがあります。CAPTCHAが難しく表示される、何度も認証を求められる、送信ボタンを押しても処理中か分からない状態も確認が必要です。
送信中はボタンの連打を防ぎながら、処理中であることを表示します。失敗した場合は入力内容を保持し、再送方法と代替の連絡手段を示します。管理者通知だけに頼ると、メール障害や迷惑メール判定で相談を見落とすため、CMSやフォームサービス側にも送信履歴を保存します。保存する情報、閲覧権限、保持期間は社内ルールに従って設定してください。
計測タグも動作確認の対象です。イベントが二重発火するとフォーム完了率を過大評価し、発火しなければ改善効果を見落とします。テスト環境と本番環境を分け、公開後にも正常送信とイベント数を定期的に確認します。
GA4で問い合わせフォームの離脱地点を確認する方法
GA4の拡張計測機能では、フォームへの最初の操作をform_start、フォームの送信操作をform_submitとして収集できます。Googleは、この二つを比較することで、フォームを入力し始めたユーザーと送信したユーザーを確認できると説明しています。ただし、フォームの構造や送信方式によって自動計測が期待どおりに動かない場合があるため、本番フォームでのテストが必要です。
form_startで入力開始を確認する
form_startは、ユーザーがセッション内で初めてフォームを操作したときのイベントです。フォームページを表示しただけでは発生しません。問い合わせページのユーザー数とform_startユーザー数を比較すると、フォームを見る前または入力前に離脱している割合を確認できます。
フォームが複数ある場合は、form_id、form_name、form_destinationを確認します。これらをレポートで利用するには、GA4でカスタムディメンションの設定が必要です。フォームごとの命名規則を決め、公開後に値が空欄や不統一になっていないか確認します。
form_submitは送信操作として扱う
form_submitは、ユーザーがフォームを送信したときに収集される拡張計測イベントです。ただし、フォームの実装によっては送信操作と受付完了が一致しません。AJAXによる送信、入力エラー、通信障害、完了画面の表示失敗などを想定し、form_submitだけを問い合わせ完了数として使用しない設計が安全です。
generate_leadで正常な受付完了を記録する
Googleの推奨イベントgenerate_leadは、フォームなどを通じてリードが生成されたときに使用します。完了ページの表示、成功メッセージ、サーバーからの正常応答など、受付が成功した条件に合わせて実装します。同じ完了ページを再読み込みしたときに重複しないか、テスト送信一件につき一回だけ記録されるかを確認します。
| 確認結果 | 疑う原因 | 次に行うこと |
|---|---|---|
| ページ閲覧はあるがform_startが少ない | 説明不足、入力前の不安、CTA不一致 | フォーム冒頭と相談内容を見直す |
| form_startはあるがform_submitが少ない | 項目、操作性、入力エラー | 項目別・デバイス別にテストする |
| form_submitはあるがgenerate_leadが少ない | 送信処理、完了判定、計測 | 成功条件とタグ発火を確認する |
| generate_leadはあるが有効相談が少ない | ターゲット、訴求、選択肢 | 相談条件と問い合わせ種別を見直す |
フォームのイベントは、デバイス、ブラウザ、流入元、ランディングページで分けて確認します。全体平均では見えないスマートフォン固有の問題や、特定記事から来たユーザーとの期待不一致を発見しやすくなります。
問い合わせフォーム改善の優先順位
問い合わせフォームの改善は、技術的不具合、送信を妨げるエラー、スマートフォン操作、説明と不安、項目負荷の順に確認します。送信できない不具合がある状態でボタン文言を比較しても、正しい評価はできません。また、複数の項目やデザインを同時に変えると、どの変更が結果に影響したか分からなくなります。
- 正常送信、通知、完了画面、イベント発火を確認する。
- スマートフォンと主要ブラウザで操作する。
- エラーの場所、修正方法、入力保持を確認する。
- 必須項目と初回受付に必要な情報を見直す。
- 返信時期、利用目的、送信後の流れを明示する。
- CTAとフォームの相談内容を一致させる。
- 一つの変更単位で効果を測定する。
アクセス量が少ないフォームでは、短期間の割合が大きく変動します。業界平均との比較だけで合否を決めず、同じフォーム、デバイス、流入条件で変更前後を確認します。フォーム完了率が上がっても有効問い合わせ率が下がった場合は、入力負荷を下げたことで対象外の送信も増えていないかを確認してください。
フォームの部分改善・作り直し・外注を判断する
問い合わせフォームの離脱が確認できても、すぐにホームページ全体をリニューアルする必要はありません。必須項目、説明文、エラー表示、スマートフォンの余白など、問題がフォーム内に限定されていれば部分改善から検証できます。外部フォームサービスやプラグインの制約で修正できない場合は、フォームだけを作り直す方法もあります。
一方、CTAとサービス内容が一致していない、問い合わせ種別が事業構造と合わない、フォーム以外のページもスマートフォンで使いにくい、計測環境が整っていない場合は、サイト全体の情報設計を含めて見直します。外注時にはデザインだけでなく、入力要件、アクセシビリティ、スパム対策、通知、データ保存、GA4イベント、公開後のテストまで依頼範囲を確認してください。
関連記事:
問い合わせフォームを含むホームページ改善をWebaxisが支援します
株式会社ジャリアのWebaxisでは、問い合わせフォームだけでなく、検索流入、サービスページ、CTA、フォーム完了までを一つの導線として確認します。フォーム項目を減らすだけでは解決しない場合も、GA4のイベント、スマートフォンのUI/UX、サービスの訴求、問い合わせ後の運用を整理し、改善範囲を判断します。
「フォームを開かれているのに送信されない」「計測が正しいか分からない」「部分改善とリニューアルのどちらが必要か判断できない」という段階でもご相談いただけます。
問い合わせフォームの離脱に関するよくある質問
問い合わせフォームの離脱は、フォームの項目数だけで判断できません。計測方法、技術的不具合、営業運用を含めて確認する必要があります。ここでは、改善時に判断しにくいポイントを整理します。
Q1. 問い合わせフォームの離脱率に目安はありますか?
一律の目安はありません。フォームの目的、流入元、入力項目、サービス価格、デバイスによって条件が異なります。分母をフォーム閲覧者とするか、入力開始者とするかでも割合が変わるため、定義を固定して自社の変更前後を比較します。
Q2. 入力項目は何個までにすべきですか?
適正な項目数は、初回対応に必要な情報で決まります。不要な必須項目は減らしますが、受付判断に必要な情報まで削ると確認の往復が増えます。任意化、選択式、商談後への移動も検討してください。
Q3. 確認画面はなくした方がよいですか?
必ずしも削除する必要はありません。確認画面は誤送信を防げますが、完了までの手順が増えます。戻ったときに入力内容が消えないかを確認し、実際の離脱と誤入力の状況から判断します。
Q4. form_submitを問い合わせ件数として使えますか?
送信操作と正常受付が一致する実装であれば参考になりますが、すべてのフォームで一致するとは限りません。正常な受付条件に合わせてgenerate_leadを実装し、テスト送信とイベント数を照合します。
Q5. form_startが計測されない原因は何ですか?
GA4の拡張計測が無効、フォームが標準的なHTML構造ではない、同意管理で計測が制限されている、タグ自体が動作していないといった原因があります。Tag AssistantとGA4のDebugViewを使い、実際の操作で確認します。
Q6. 必須項目を減らすと問い合わせの質が下がりませんか?
対象外の送信が増える可能性はあります。フォーム完了率だけでなく、有効問い合わせ率、商談化率、営業担当者の確認負担も併せて確認します。相談条件や対象サービスをフォーム前に明示する方法も有効です。
Q7. スパム対策を強くすると離脱が増えますか?
認証操作が複雑、繰り返し表示される、エラー理由が分からない場合は、正規ユーザーの送信も妨げます。スパム件数と正常送信の両方を確認し、ユーザー操作を増やしすぎない対策を選びます。
Q8. フォーム改善の効果はどれくらいで判断できますか?
必要期間はフォーム開始数によって異なります。変更前の期間と条件を保存し、変更直後は不具合を確認します。その後、十分なform_start数が集まってから完了率と有効問い合わせ率を比較してください。
まとめ|フォームを見た人・始めた人・完了した人を分けて改善する
問い合わせフォームで離脱する原因は、項目数、説明不足、エラー表示、スマートフォン操作、不安、CTAとの不一致、技術的不具合の7つに分けられます。最初に正常送信と通知をテストし、GA4ではform_start、form_submit、generate_leadを区別してください。
改善では、フォーム完了率だけを追わず、有効問い合わせ率や営業運用まで確認します。項目を一律に減らすのではなく、どの段階で止まっているかを特定し、一つの変更単位で検証することが重要です。フォーム以外にも検索流入、サービスページ、CTAの課題がある場合は、ホームページ全体の導線から改善範囲を判断します。

