「フォームまでは見られているのに問い合わせが増えない」「入力項目を減らすべきか、説明を増やすべきか分からない」。そんな悩みを持つWeb担当者の方へ、フォーム離脱を入力前の不安・入力中の負担・送信時のつまずきに分けて点検する方法を紹介します。
まずは、フォームを開いた人が入力を始めないのか、入力を始めた人が送れないのかを切り分けます。アクセスの獲得やサービス説明も含めて見直したい場合は、ホームページに問い合わせが来ない原因のチェック表から全体を確認できます。
フォーム離脱は4つの段階に分けて調べる

フォームの閲覧数と送信ボタンのクリック数だけでは、どこで困ったかを判断しにくくなります。入力開始・送信操作・受付完了を、同じ出来事として数えないことが最初の改善です。
| 段階 | 考えられるつまずき | 先に確認すること |
|---|---|---|
| フォームを見る | 相談条件や連絡後の流れが分からない | 対象・必要な情報・返信の流れが伝わるか |
| 入力を始める | 必須項目が多い、書く内容に迷う | 項目の必要性、ラベル、入力例 |
| 送信を操作する | エラー箇所が見つからない | エラーの場所と直し方、入力内容の保持 |
| 受付が完了する | 送れたか分からず操作を繰り返す | 受付完了の表示と、実際の受付記録 |
この分類は改善のための設計例です。どの問題があるかは、自社フォームの動作確認と計測結果で判断します。根拠のない「平均離脱率」を目標にするより、同じフォームを同じ条件で比較できる状態を整えましょう。
入力前の不安は、フォームの手前で解消する

入力前には「まだ検討段階でも相談できるか」「どんな情報が必要か」「送信した後に何が起きるか」といった疑問があります。これらの説明が見つからないと、入力の操作に問題がなくても相談をためらうことがあります。
- 相談の対象:受け付ける相談内容を、具体的な例で示す。
- 準備する情報:分からなくても相談できる項目と、必須の情報を分ける。
- 連絡の流れ:返信方法や時期は、実際に約束できる範囲で案内する。
例えば「詳しくお問い合わせください」だけでなく、「利用したい場所や案内したい内容を、分かる範囲でお知らせください」と説明すると、書く内容を考えやすくなります。実態を確認せずに「営業連絡はしません」「必ず翌日返信します」と約束することは避けます。
入力中の負担は、項目数と説明をセットで見直す

項目を減らす前に、それぞれを誰が何のために使うか確認します。初回対応に必要な情報と、相談が進んでから確認できる情報を分け、必須にする理由を説明できる項目に絞ることを検討します。
| 点検する場所 | 確認の観点 | 見直し例 |
|---|---|---|
| 入力項目 | 初回の対応に必要か | 後で確認できる情報は任意または後段へ |
| ラベル | 入力を始めても項目名が見えるか | 入力欄とは別に分かりやすい項目名を表示 |
| 必須・任意 | 入力前に違いが分かるか | 表記を統一し、判断しやすい位置へ |
| 自由記述 | 何を書けばよいか想像できるか | 相談内容の例を短く添える |
| 入力形式 | 形式の指定が必要以上に厳しくないか | 受け入れられる表記や補足説明を見直す |
W3Cのフォーム解説でも、入力欄の目的を示すラベルと、入力欄との対応付けが説明されています。実装を確認するときは、W3Cの入力欄ラベルの解説を参考に、見た目だけでなく支援技術にも項目名が伝わるか確認します。
送信エラーは「場所」と「直し方」を伝える

「入力内容に誤りがあります」だけでは、利用者が修正する箇所を探すことになります。エラーが起きた項目を示し、必要な修正を短く説明します。
分かりにくい例:「入力内容が不正です」
見直し例:「メールアドレスを確認してください。入力例:name@example.com」
説明は実際の検証条件に合わせて作ります。修正のために前の画面へ戻った際、入力した内容が消えないかも確認してください。W3Cのエラー・完了通知の解説では、問題の内容と直し方を明確に伝えること、送信成功も利用者へ知らせることが整理されています。
送信ボタンを押した後まで確認し、受付が完了したことを利用者に伝えましょう。完了メッセージが表示されても、管理側に受付記録が残っているかは別途確認が必要です。
GA4では入力開始と受付完了を分けて計測する

Googleの拡張計測機能では、フォーム操作に対して form_start と form_submit が用意されています。公式の定義では、前者はセッションで初めてフォームを操作したとき、後者はフォームを送信したときのイベントです。設定やパラメータはGoogle公式の拡張計測機能イベントで確認できます。
ただし、サイト独自のフォームや送信処理でも想定どおりに記録されるかは、実際に検証してください。送信操作のイベントを、そのまま「相談の受付が成功した人数」と扱わず、受付完了画面や管理側の記録と照合します。氏名・メールアドレス・自由記述などの個人情報を、イベントの値として送らないようにします。
入力開始後の離脱を評価するなら、同じフォーム・同じ集計条件で「入力を始めた人のうち、受付完了まで進めなかった割合」を確認します。単純なイベント回数の割り算では、連打・再送信・重複計測の影響を受けることがあります。未取得はゼロと区別し、計測方法を整えてから改善前後を比較しましょう。
スマートフォンで確認する5つの項目

- キーボードを開いても、項目名や説明が隠れないか。
- 文字を拡大しても、横にはみ出さずに入力できるか。
- エラーのある入力欄へ戻り、修正できるか。
- 送信ボタンや同意欄を無理なく操作できるか。
- 送信後に受付完了が分かり、二重送信を防げるか。
これは確認のためのチェックリストです。デスクトップの画面を狭める検証に加えて、実機でのキーボード表示や通信状況も確認すると、操作中の問題を見つけやすくなります。
ピタリーはフォーム入力前の疑問を案内する選択肢

フォームの手前で繰り返し聞かれる質問がある場合は、FAQや会話形式の案内を設ける方法があります。ピタリーでは、キャラクターのカスタマイズ、FAQ・応答設定、Webでの案内などを相談できます。案内できる回答と、人へ確認する質問の分け方は、問い合わせ対応を自動化する範囲の判断表も参考になります。
フォーム自体のエラー修正や受付処理の改善は、フォーム側で行う必要があります。ピタリーを置くだけで入力中の離脱を解消できる、というものではありません。公開済みのFAQや資料への案内を整えたいときに、自社に合う使い方を検討します。
回答の整備や更新担当を含む運用は、問い合わせ対応を効率化する役割分担と手順で解説しています。ピタリーの機能・設置方法・料金条件は相談時点で確認し、開発中や提供予定の機能を導入の前提にしないようにします。
よくある質問

フォームの項目を減らせば改善しますか?
項目数だけでは判断できません。入力前の不安、各項目の必要性、説明、エラー、完了通知を分けて確認します。初回対応に必要な情報は残し、任意や後段に回せるものを検討します。
フォーム離脱率の平均値を目標にすべきですか?
フォームの用途や、閲覧・入力開始・完了のどれを分母にするかで変わります。同じ定義で自社の改善前後を比較する方法を優先します。
チャットボットとフォーム改善はどちらが先ですか?
入力中のエラーならフォームを修正します。入力前の質問が未解決ならFAQや会話案内も検討します。つまずいている段階に合わせて対策を選びましょう。
出典・確認先

参考資料・関連情報
執筆・編集:村上 卓斗 / 最終確認:2026.10.29
お問い合わせ 