問い合わせフォームの改善方法｜離脱を減らす入力項目と確認手順
執筆・監修：株式会社AO
問い合わせページまで来た利用者が送信を完了できないとき、フォームの項目数だけを減らしても解決しない場合があります。入力の目的が分からない、形式エラーを直せない、同意範囲が曖昧、送信できたか判断できない、といった障壁を利用者の操作順に確認する必要があります。本記事では、サイト全体の導線を扱う問い合わせ導線の記事とは分け、フォーム到達後の改善に絞って実務手順を整理します。
この記事で分かること
- 残す項目・任意にする項目・後で聞く項目の判断基準
- ラベル、入力例、autocomplete、エラー表示の確認方法
- 個人情報の同意、確認画面、送信完了画面で伝える内容
- フォーム開始から有効問い合わせまでを測る改善手順
フォーム到達後の「完了できない理由」を改善する
問い合わせ数は、集客、サービスページ、CTA、フォーム、返信体制の掛け合わせです。本記事の対象はフォーム表示から送信完了までです。フォーム到達数そのものが少ない場合は、先にページ内容やCTAを確認します。到達はあるのに完了が少ない場合は、入力開始、エラー、確認、送信完了の各地点を切り分けます。
最初に「短くする」ことを目的にせず、営業・サポートが初回返信を行うために本当に必要な情報を定義してください。足りない情報は返信後に確認できますが、法令・契約・安全上必要な同意や本人確認まで省くことはできません。
離脱を推測せず、操作と記録で切り分ける
| 確認地点 | 起きていること | まず確認すること |
|---|---|---|
| 表示直後 | 入力を始めない | 所要時間、返信目安、必須項目、問い合わせ対象が分かるか |
| 入力中 | 途中で戻る・閉じる | 項目の必要性、モバイル操作、入力形式、入力内容の保持 |
| 送信時 | エラーから復帰できない | エラー箇所・理由・修正例がテキストで示されるか |
| 同意・確認 | 内容に不安を感じる | 利用目的、送信先、プライバシーポリシー、戻った際の保持 |
| 完了後 | 再送・電話が発生する | 受付完了、返信目安、控えメール、緊急時の連絡先 |
入力項目は「今必要か」で3つに分ける
| 区分 | 判断 | 例 |
|---|---|---|
| 必須 | 受付・返信・振り分けに不可欠 | 氏名、返信先、問い合わせ内容 |
| 任意 | あれば初回対応が早いが、なくても受付できる | 会社名、希望時期、参考URL |
| 返信後 | 相談内容に応じて聞き分ける | 詳細予算、システム構成、関係者情報 |
「会社名がないと営業管理しづらい」など社内都合だけで必須にしていないかを確認します。一方、BtoBで担当部署への振り分けに必要など明確な理由があれば残します。改善案ごとに、入力者への負担と受付後の追加確認コストを並べて判断してください。
ラベル・入力補助・エラーを一つの流れで設計する
W3CのWCAG 2.2は、入力を求める場合にラベルまたは説明を提供すること、検出した入力エラーは該当項目を特定してテキストで説明することを示しています。色や枠線だけでエラーを伝えず、「メールアドレスを name@example.com の形式で入力してください」のように、場所・問題・直し方を確認できる表示にします。
- ラベル：placeholderだけに頼らず、入力後も項目名が見える状態にする。
- 入力形式：電話番号のハイフン要否など、独自ルールを減らし、必要なら入力前に例を示す。
- ブラウザ補助：
type、name、autocompleteなど標準属性を適切に設定する。web.devもブラウザ機能を利用する属性と安定したname/idを案内しています。 - エラー：送信後に一覧を示す場合も、各項目の近くに説明を置き、先頭のエラーへ移動できるか確認する。
- 操作領域：チェックボックスや送信ボタンは端末別に押しやすさを確認する。WCAG 2.2のターゲットサイズ最小基準は原則24×24 CSSピクセルで、間隔などの例外があります。
- 状態保持：エラーや確認画面から戻ったとき、機密性に問題のない入力が消えないか確認する。
問い合わせフォーム改善の7ステップ
- 完了条件を決める：送信件数だけでなく、対象サービス、迷惑送信除外、有効問い合わせの定義を決める。
- 利用者として再現する：スマートフォンとPCで、空欄、誤形式、長文、戻る操作、通信遅延を試す。
- 各項目の理由を書く：誰が何に使うかを書けない必須項目は、任意化・統合・返信後確認を検討する。
- 説明と入力補助を直す：ラベル、必須・任意、入力例、autocomplete、キーボード種別を整える。
- エラー復帰を直す：エラーをテキストで説明し、入力値を保ち、修正箇所へ移動できるようにする。
- 同意と完了を明確にする：利用目的とポリシーへの導線、受付番号、返信目安、控えメールを確認する。
- 小さく比較する：複数項目を一度に変えず、一定期間と十分な件数を確保して品質も含めて評価する。
完了率だけでなく、有効問い合わせまで測る
個人情報や入力本文そのものを解析ツールへ送らず、必要なイベントだけを設計します。例として、フォーム表示、入力開始、エラー発生、送信成功を区別し、送信成功はサーバー側の受付結果または固有の完了状態で確認します。クリックだけを成功扱いにすると、通信エラーや入力エラーも混ざります。
- 完了率＝送信成功数÷フォーム表示数
- 開始後完了率＝送信成功数÷入力開始数
- 有効問い合わせ率＝社内定義を満たす問い合わせ数÷送信成功数
- エラー発生率＝エラーが発生したセッション数÷入力開始数
改善で送信が増えても、対象外相談や迷惑送信が急増した場合は成功とは言えません。営業の初回返信時間、追加確認の回数、対象サービスとの一致も併せて確認します。
公開前チェックリスト
- フォームの目的、所要時間、返信目安が送信前に分かる
- 必須項目は受付に不可欠なものに限定され、任意項目が識別できる
- 全入力欄に見えるラベルがあり、必要な形式や例が示されている
- autocompleteなどブラウザの入力補助を妨げていない
- エラーは色だけでなく、項目名・問題・修正方法をテキストで示す
- キーボード、スマートフォン、拡大表示でも操作できる
- 同意対象と利用目的、プライバシーポリシーへのリンクが分かる
- 二重送信を防ぎ、送信成功・失敗を区別して表示できる
- 完了画面と控えメールに受付内容と次の対応が示される
- 解析イベントに氏名、メール、電話、自由記述を含めていない
よくある質問
確認画面は必ず必要ですか？
すべてのフォームに一律で必要とは限りません。入力内容の重要性、誤送信の影響、訂正のしやすさを踏まえて判断します。確認画面を設ける場合は、戻って修正しても入力が消えないこと、確認と送信のボタンを誤認しないことをテストします。
項目数は何個までならよいですか？
一律の正解はありません。項目ごとの利用目的と利用者の負担を確認し、初回受付に不要なものを後へ回します。項目数だけでなく、選択肢の分かりやすさ、入力形式、エラー復帰、モバイル操作も影響します。
電話番号は必須にすべきですか？
初回対応をメールだけで完了できるなら、任意化を検討できます。緊急対応や本人確認など必要性がある場合は、利用目的と連絡方法を明示します。
改善効果はどのくらいで判断できますか？
固定の日数では決められません。季節性、流入元、件数、変更範囲をそろえ、送信成功だけでなく有効問い合わせの品質も確認します。件数が少ない場合は、まず操作テストとエラーログから明確な障害を直します。
参考にした公式情報
- web.dev「Sign-in form best practices」（標準フォーム属性、入力補助、モバイル操作の参考）
- W3C「Understanding SC 3.3.2: Labels or Instructions」
- W3C「Understanding SC 3.3.1: Error Identification」
- W3C「Understanding SC 2.5.8: Target Size (Minimum)」
確認日：2026年10月3日。仕様やガイドラインは更新されるため、実装時に各公式ページを再確認してください。
関連記事・対応サービス
問い合わせ導線とフォームを一緒に点検します
株式会社AOでは、フォーム単体だけでなく、サービスページから送信後の運用までを確認し、優先順位の高い改善案を整理します。現状の離脱箇所が分からない段階でもご相談ください。
無料相談・お問い合わせ