法人向け問い合わせフォームの作り方｜必須項目・入力エラー・確認・完了後導線を設計

監修: 菊地 将（リブランディング株式会社）

法人向け問い合わせフォームを作るとき、先に入力欄を並べると「営業には情報が足りない」「利用者には入力が重い」「送信後の振り分けができない」といったズレが起こりやすくなります。最初に決めるべきなのは項目数ではなく、問い合わせを受けた後に誰が何を判断し、どこへ情報を渡すかです。その流れから必要項目を逆算し、必須・任意、入力ルール、エラー、確認、個人情報の扱い、完了画面、CRM通知までを一つの要件として固めます。この記事では、一般的な法人向けフォームを公開前に設計する順番を整理します。

法人向け問い合わせフォームは「受け取った後」から逆算して設計する

フォーム設計の起点は、画面ではなく問い合わせ後の業務です。営業、サポート、採用、協業など複数の窓口があるなら、誰が受信し、何を見て担当を決め、どの情報をCRMやSFAへ登録するのかを先に決めます。

フォーム単体ではなく、記事から問い合わせまでの流れ全体を整理したい場合は、記事からリード獲得までの集客導線全体もあわせて確認してください。

フォームの入力項目は、問い合わせ後の担当振り分けや初回対応に必要な情報から逆算すると整理しやすくなります。

W3CのForms Tutorialでも、フォームは簡潔にし、処理を完了するために必要な情報だけを求めることが推奨されています。つまり「取れる情報は全部取る」のではなく、「初回対応に必要か」で項目を判断する考え方が基本です。

問い合わせ前に最低限、次の5点を決めておくと設計がぶれにくくなります。

• 問い合わせの種類
• 初回対応する部署・担当者
• 初回返信に必要な情報
• CRM・SFAへ保存する情報
• 自動返信と社内通知で伝える内容

この5点が決まってから、入力項目へ落とし込みます。

必須項目と任意項目は「初回対応に必要か」で分ける

必須にする基準は、「あると便利か」ではなく「ないと初回対応が成立しないか」です。営業があとで確認できる情報まで必須にすると、利用者に余計な入力を求めることになります。一方、振り分けや返信に不可欠な情報を任意にすると、社内側で確認作業が増えます。

項目数や必須項目が離脱にどう影響するかは、資料請求フォームの入力負担に関する調査でも確認できます。

一般的な法人向け問い合わせフォームでは、次のように整理できます。

この表は固定の正解ではありません。たとえば電話での折り返しを前提とする相談窓口なら電話番号の重要度は上がります。反対に、まずメールで内容を確認する運用なら任意にできます。

項目ごとに「何に使うのか」を書けない場合は、初回フォームから外せないか検討します。

入力仕様はラベル・形式・補助説明まで要件にする

入力欄の名称だけでは、実装要件として不十分です。各項目について、ラベル、必須・任意、入力形式、文字数、入力例、自動入力、エラー条件まで決めます。

W3Cは、入力欄にラベルや必要な説明を用意し、必須・任意や入力形式を利用者が理解できるようにすることを示しています。また、プレースホルダーだけを項目名の代わりにするのではなく、フォーム部品と対応したラベルを用意することが重要です。

氏名、会社名、メールアドレスなどは、ブラウザーの自動入力を活用できるようHTMLの autocomplete 属性も検討します。MDNでは、autocomplete によりブラウザーへ入力内容の種類を伝え、自動入力を支援できると説明しています。

入力仕様書に最低限入れる項目

• 画面に表示する項目名
• 必須・任意
• 入力形式または選択肢
• 最小・最大文字数
• 入力例や補足説明
• エラーになる条件
• CRM・SFA側の保存先項目
• 社内通知に含めるか

制作会社や開発担当へ依頼する場合も、この状態まで決めて渡すと「画面は完成したが営業運用に使えない」という手戻りを減らせます。

入力エラーは「どこが、なぜ違うか」を文字で示す

エラー設計では、赤枠にするだけでなく、該当項目と修正方法を文章で伝えます。WCAG 2.2では、自動検出した入力エラーについて、エラー箇所を特定し、内容をテキストで説明することが求められています。修正方法が分かる場合は、その手掛かりも示します。

エラー箇所を示すだけでなく、何を修正すれば送信できるのかまで文章で伝える設計が必要です。

入力チェックは、利用者がその場で気づけるクライアント側の処理と、送信された値を安全に扱うサーバー側の処理を分けて考えます。OWASPは、JavaScriptによるクライアント側の検証だけでは回避され得るため、サーバー側でも入力検証を行うよう推奨しています。

エラー後に入力済みの内容がすべて消える設計も避けます。修正対象以外の情報を残し、利用者が同じ内容を何度も入力しなくて済むようにします。

確認画面は一律必須にせず、問い合わせの性質で決める

確認画面は、すべての問い合わせフォームに必須とは限りません。短い相談フォームでは、入力画面でエラーを十分に防げるなら、そのまま送信する設計も選べます。

一方、長い自由記述、ファイル添付、複数の選択条件などがあり、送信前に全体を見直す価値が高いフォームでは確認画面が役立ちます。

確認画面を設ける場合は、次の点を要件にします。

• 入力内容を項目名とセットで一覧表示する
• 「修正する」と「送信する」を明確に分ける
• 修正画面へ戻っても入力値を保持する
• 確認のために同じ情報を再入力させない
• 二重送信を防ぐ

WCAG 2.2の「Redundant Entry」でも、同じ手続きの中で以前入力した情報を再び求める場合は、自動入力または選択できる状態にすることが求められています。

個人情報は送信前に利用目的を確認できる状態にする

法人向けフォームでも、氏名やメールアドレスなど個人情報を取得する場合は、利用目的の扱いを設計段階で確認します。

個人情報保護委員会は、ホームページ上の入力画面を含む書面で本人から直接個人情報を取得する場合、原則として利用目的を明示する必要があるとしています。また、ネットワーク上で取得する場合は、送信ボタンを押す前などに利用目的が目に留まる配置、または1回程度の操作で利用目的を確認できるリンクを設けることが望ましいとしています。

ここで重要なのは、「同意チェックボックスを置けば終わり」と考えないことです。問い合わせへの返信だけでなく、別サービスの案内、メール配信、第三者提供など別の用途でも利用するなら、その利用目的と必要な同意方法を自社のプライバシーポリシー、法務方針に合わせて確認します。

実装要件には、少なくとも次を含めます。

• 取得する個人情報
• 利用目的
• プライバシーポリシーへの導線
• 同意チェックの要否
• データの保存先と閲覧できる担当者
• 外部フォーム・CRMへ送信する場合の取扱い

完了画面と自動返信で「送信できたか」を明確にする

送信ボタンを押した後に画面が変わらないと、利用者は送信できたか判断できません。完了画面では、受付が完了したことと、その後の流れを明確に伝えます。

完了画面で決めておきたいのは次の内容です。

• 問い合わせを受け付けたこと
• 返信方法
• 返信時期を案内する場合の文言
• 自動返信メールが届かない場合の確認事項
• 必要に応じたFAQや関連情報への導線

自動返信メールも、送信者が入力したメールアドレスが正しいかを確かめる手掛かりになります。ただし、問い合わせ本文に機密情報が含まれる可能性がある場合は、その内容をそのままメールへ転載するかどうかも事前に決めます。

CRM通知は「フォームの後工程」ではなく設計時に決める

フォームが送信できても、社内で受け取れなければ問い合わせ対応は始まりません。CRM・SFAやメール通知を使う場合は、フォーム項目と社内処理を同時に設計します。

問い合わせ種別、通知先、担当振り分け、CRMへの保存までをフォーム公開前に一続きで設計します。

最低限、次の対応表を作ります。

フォーム側のラベルとCRM側の項目名が一致していなくても問題ありませんが、どの値をどこへ保存するかは実装前に固定します。

問い合わせ種別を部署振り分けに使うなら、選択肢を追加・変更したときの通知ルールも合わせて管理します。

公開前は入力からCRM到着まで一連でテストする

公開前テストでは、見た目だけでなく「入力→送信→完了→通知→CRM登録」まで通して確認します。フォーム単体の動作確認では、完了画面は出たのに社内通知が届かない、CRMの項目がずれているといった問題を見落とすためです。

公開前テストは送信成功だけで終わらせず、社内通知とCRMへの正しい登録まで一連で確認します。

reCAPTCHAを使う場合は、ブラウザー側へ表示するだけでなく、Googleの仕様に沿ってサーバー側でレスポンストークンを検証する実装まで確認します。

公開後の到達数、入力開始、エラー、完了率などを使った離脱診断は、フォームを「作る工程」とは分けて考えた方が整理しやすくなります。公開後の監査は、フォーム離脱を監査する方法で確認してください。

よくある質問

法人向け問い合わせフォームは何項目にすべきですか？

一律の項目数ではなく、初回対応に必要かどうかで決めます。返信、担当振り分け、CRM登録に使わない情報は、任意化や後日の確認に回せないか検討します。

項目数そのものより、各項目の利用目的を説明できる状態にすることが重要です。

確認画面は必ず必要ですか？

必須ではありません。短い問い合わせで入力画面上のエラー防止が十分なら省く設計も可能です。

長い自由記述や添付など、送信前に全体を見直す価値が高い場合は確認画面を設けます。採用する場合は、修正時に再入力させないことも要件にします。

個人情報の同意チェックボックスは必須ですか？

フォームで重要なのは、取得する個人情報の利用目的を送信前に確認できるようにすることです。

個人情報保護委員会のガイドラインでは、ホームページの入力画面で本人から直接個人情報を取得する場合、原則として利用目的の明示が必要とされています。同意チェックの要否は、取得情報の使い方や自社の法務方針に応じて判断してください。

まとめ

法人向け問い合わせフォームは、入力欄からではなく「送信後に誰が何をするか」から逆算すると設計しやすくなります。

初回対応に必要な情報を選び、必須・任意、入力仕様、エラー、確認、個人情報、完了画面、自動返信、CRM通知を一つの要件として整理してください。

公開前には入力からCRM到着まで通してテストします。公開後の離脱率分析やGA4イベント設計は別工程とし、まずは問い合わせを正しく受け取り、担当者が迷わず初動へ移れる状態を作ることが先です。

公開前の確認事項を手元で整理しながら進めたい場合は、無料ダウンロードページの関連資料も活用できます。

参考文献・データ元

‹ 親記事: オウンドメディアの集客導線とは？記事からリード獲得までを設計する全体像とCTA・リードマグネット・フォーム最適化の基本