問い合わせフォームの項目設計｜必須・任意の決め方と記入例

Webサイトの設計をイメージしたAI生成画像です。実際の顧客や実績の写真ではありません。

メールで初回相談を受けるなら、返信先と相談内容を起点に、名前など受付に使う情報を加えます。電話・住所・予算は、初回に必要かを確認して必須・任意・後で聞くに分けましょう。この記事では、架空の相談窓口の完成例から、項目表と入力案内を作る手順を解説します。

問い合わせフォームに置く項目と、必須にする基準

メールで初回の相談を受けるフォームなら、まず「返信先のメールアドレス」と「相談内容」を用意し、名前や会社名などを受付の運用に合わせて加えます。電話番号、住所、予算、希望日時は一律に必須にせず、初回の受付で使う理由を確認して決めます。これは一般的な相談窓口を作るときの出発点であり、すべての業種に共通する最少項目数ではありません。

最初の作業は、今ある項目を一つずつ並べて「空欄だと、最初の返事の何ができなくなるか」を書くことです。メールで返せるのに電話番号も必須、相談して決める予算なのに金額が必須、といった組み合わせがないかを確認します。必要な情報が決まっている予約や正式な申込みは、気軽な初回相談とは分けて設計してください。

W3Cのフォーム解説は、処理に必要な情報だけを求め、無関係な入力や過剰な入力を避ける考え方を示しています。単に項目を消すのではなく、受付に必要な情報を確保しつつ、まだ答えられない質問を初回から強制しないための判断に使えます。

出典：Forms Tutorial | Web Accessibility Initiative (WAI) | W3C

任意化と削除は別の選択です。たとえば対象サイトのURLは、新規制作ならまだ存在しなくても、改修相談では役に立ちます。「任意・既存サイトがある場合」と書けば、分かる人から受け取り、ない人も相談できる設計になります。空欄の意味を担当者が理解できるよう、フォームの説明と受け取った後の扱いをそろえます。

本記事は、項目表と案内文を決めて制作担当へ渡したい方が対象です。問い合わせが少ない原因をサイト全体から調べる場合や、送信件数をGA4で計測する場合は、末尾の関連記事で別の手順を確認できます。ここではフォームに到着した人が何を入力し、どう直して送れるかに絞ります。

記入例：初回相談の項目表を完成させる

架空の「事務所向け家具修理の相談窓口」を例にします。受付担当はまずメールで状況を聞き、修理できるかと正式な見積もりはその後に確認する運用です。写真や寸法がなくても初回相談は受け付ける、電話返信は希望者だけ、という前提で項目を決めます。実在する顧客事例や、送信率が改善した実績ではありません。

同じ家具修理でも、最初から訪問枠を予約する窓口なら項目は変わります。対応地域を判断するために市区町村が必要な場合や、当日の連絡先が必要な場合は、その理由と聞くタイミングを記載します。上の表をそのまま採用するのではなく、自社が最初の返信で何を決めるかに置き換えてください。

条件によって必須になる項目は、戻った場合も決める

例の電話番号は、電話返信を希望した場合だけ必要です。希望を取り消したら電話番号が空欄でも送れる、確認画面から戻って選び直しても同じ動きになる、というところまで仕様にします。画面では任意なのに保存処理が必須として扱うと、利用者は直す理由が分からないまま止まります。

さらに、電話希望を取り消した後の入力済み番号をどう扱うかも決めます。この例では、不要になった番号を送信内容や通知へ含めない設計とします。画面上で消えたから送られないはず、と推測せず、制作担当へ受付結果の確認を依頼します。実際のフォームを変更する際は、現在の連絡方針や利用目的を把握する担当者と合意してから進めます。

入力欄の説明と選択肢を決める

項目名が決まったら、入力する人に見せる言葉を作ります。「詳細」「備考」だけでは、どの程度書けばよいか判断しづらくなります。上の例なら「修理したい家具と、困っている状態」を説明として添え、必要以上の専門知識がなくても書けるようにします。

たとえば相談内容の記入例は、「会議室の椅子の座面が破れています。型番と寸法はまだ分かりません。修理の相談はできますか」とします。これは説明用の架空の文章です。読者が実際に知っている範囲で入力してよいことが伝わり、担当者も次に尋ねる情報を判断できます。

項目名・入力例・補足説明を分ける

項目名は入力後も見える位置に残します。入力欄の中の薄い文字はプレースホルダーと呼ばれ、記入すると消えることがあります。W3Cは、プレースホルダーをラベルの代わりにしないことを説明しています。必須条件や書き方の注意を欄の中だけに置かず、入力後にも確認できる形にします。

出典：Form Instructions | Web Accessibility Initiative (WAI) | W3C

ラベルは項目を識別する名前です。見た目として入力欄の近くに置くほか、実装上も欄と対応させます。W3Cは、label要素のforと入力欄のidを一致させる方法などを示しています。担当者へは「見出しのような文字を置く」だけでなく、「読み上げやキーボード操作でも、どの欄か分かる状態」を確認してもらいます。

出典：Labeling Controls | Web Accessibility Initiative (WAI) | W3C

選択肢は、社内の部署名より利用者が判断できる言葉で考えます。担当者の振り分けに問い合わせ区分を使うなら、「修理の相談」「対応中の件」「その他」など実際の受付内容に合わせて整理します。「その他」を設ける場合は、その受け先も決めます。どれを選んでも同じ担当が同じ対応をするなら、区分を設ける必要があるかも検討できます。

数字や日付を答えられない段階には「未定」という回答が役立つ場合があります。ただし、空欄・未定・対象外は意味が違います。希望時期が未定なのか、質問を見ていないのかで後の確認が変わるため、担当者がどう扱うかも設計表へ書きます。回答を増やすためだけに、利用者が適当な数値を入れるしかない欄を作らないようにしましょう。

エラーから修正できる案内を用意する

入力を間違えた人が、自分で修正できることもフォーム設計の一部です。エラー文は「問題がある項目」と「直すこと」をセットで書きます。「入力内容を確認してください」という表示だけでは、どの欄へ戻ればよいか分かりません。

W3Cの通知の解説は、短く理解しやすい説明、該当項目の特定、修正方法、対象欄へ移れるリンクなどを案内しています。画面上部にエラーをまとめる場合も、各欄の近くに説明を置く方法と組み合わせます。色やアイコンを付けるだけで終わらせず、文章でも伝わることを確認します。

出典：User Notification | Web Accessibility Initiative (WAI) | W3C

この文例は、形式の確認と本人確認を分けています。メールアドレスが形式上正しくても、本人のアドレスであることや、実際に受信できることまでは分かりません。「メールアドレスが確認できました」と表示するなら、何を確認した状態なのかを実装担当とそろえます。

入力途中と、送信時のチェックを分ける

メールアドレスを入力している途中は、@やドメインがまだ書かれていないことがあります。そのたびに警告を大きく出すと、まだ入力中なのに修正を求められます。W3Cも、入力中の即時表示が適切でない場面を説明しています。欄から移動した時や送信操作をした時など、どの時点で案内するかを決め、操作を妨げないか確かめます。

出典：User Notification | Web Accessibility Initiative (WAI) | W3C

電話番号の区切り文字などは、業務上の必要性を確かめてから制限します。W3Cは、同じ情報の異なる表記をできるだけ受け入れることを勧めています。表示例どおりに書いたのに拒否される、ハイフンの有無を何度も直させる、といった不整合がないかが確認の出発点です。

出典：Validating Input | Web Accessibility Initiative (WAI) | W3C

画面側のチェックは、利用者が誤りに気づく助けになりますが、それだけで受付条件を守れるとは限りません。W3Cはサーバー側でも検証する必要を示しています。必須・任意・条件付き必須のルールを画面と受付処理でそろえ、未入力の任意項目が原因で受付できなくならないようにします。

出典：Validating Input | Web Accessibility Initiative (WAI) | W3C

エラーで戻ったときに、問題のない相談内容まで消えていないかも確認します。再入力を減らすための保持方法は、扱う情報と利用端末に合わせて決めます。入力を永続保存する機能を無条件に追加するのではなく、まず修正中の画面で必要な内容を保てるかを制作担当へ相談してください。

確認・完了画面を受付の動きに合わせる

確認画面を付けるかは、見直す内容と誤送信した場合の影響から決めます。短い初回相談なら、入力画面で全項目を確認して送る設計も選択肢です。一方、予約や正式な申込みを扱う場合は、内容や条件を確かめる機会を十分に用意します。ここでは契約や決済の設計を一般の相談フォームと同じに扱いません。

ボタンの文言も次の画面に合わせます。確認画面へ進むなら「入力内容を確認する」、そこで受付処理を行うなら「相談内容を送信する」といった違いです。ボタンを押した時点で何が確定するかを、入力欄の前の説明、ボタン、完了案内で一致させます。

家具修理の例なら、完了案内は「修理のご相談を受け付けました。担当者が内容を確認し、ご入力のメールアドレスへご連絡します。電話返信をご希望の場合は、記入いただいた番号へご連絡します」と書けます。修理の可否・訪問日・料金はまだ確定していないので、「ご予約が完了しました」とは表示しません。

返信までの目安を載せる場合は、実際に対応できる日数と休業日の扱いを確認してから具体的に記入します。「すぐ返信」「必ず翌日」などを、安心感を出すためだけに足してはいけません。担当が不在のときに誰が確認するか、目安を過ぎても連絡がない場合にどこを案内するかも、公開前に決めます。

受付保存、担当者への通知、自動返信、担当者の実際の返信は異なる処理です。画面で受付が完了したことと、すべてのメールが到着したことを同じにしないでください。通知が届かなくても受付が残る設計なら、一覧を確認する運用が必要です。保存機能のない方式なら、どこで受信を確認するかを明確にします。

設計表を制作担当へ渡し、公開前に照合する

制作担当に渡す設計表には、対象URL、フォームの目的、各項目の名称と入力方法、必須条件、説明、エラー文、受け取り後の用途をまとめます。受付担当と制作担当が同じ表を読むと、「画面は任意だが社内では必須のつもりだった」という食い違いを見つけられます。

送信を伴う試験は、担当者と通知先・テストデータ・確認する時間を決めてから行います。本番の問い合わせや営業対応に混ざらない方法を用意し、既存の有効な試験記録がある場合は、変更箇所に応じて確認範囲を絞ります。この記事の点検のために、第三者の窓口へ試しに送信する必要はありません。

検査結果は「合格」「不具合」「未確認」を分けて残します。スマホで表示を見ただけなら、受付まで確認済みとはしません。反対に、通知メールが届いても入力欄が使いやすいとは限りません。どの操作をどの環境で確かめたかが分かると、公開判断と修正依頼を具体的に進められます。

公開後は、フォームを見た人、入力を始めた人、受付できた相談を区別して確認します。数字を比べるときは期間・流入経路・対象フォームをそろえ、検証アクセスや迷惑送信を分けます。少数の増減だけで改善効果を決めず、受付担当が追加確認した理由も記録すると、次に直す項目を判断する材料になります。

アクセス解析へは氏名、メール、電話、相談本文などの入力値を送らず、受付の管理情報と分けて扱います。問い合わせボタンのクリックだけを相談件数と呼ばないことも大切です。詳しい計測の設計は、関連記事のGA4確認手順に沿って整理してください。

よくあるご質問