問い合わせフォームのエラーメッセージ設計｜バリデーション・表示タイミング・文言ルール

フォームのエラーメッセージは、単なる警告ではありません。入力ミスが起きたあとに、どこを直せば送信完了まで戻れるかを伝えるための案内です。ここが曖昧だと、入力途中の離脱につながります。

このページでは、問い合わせフォームのエラーメッセージを、何を必須にするか、いつ・どこに表示するか、どう書くか、入力内容をどう保持するか、どのエラーを先に見直すかに分けて説明します。ブラウザーとサーバーの判定、通信失敗や二重送信への対応まで、画面上の案内と受付処理を一つの流れで扱います。

エラーメッセージは「間違いの指摘」ではなく「修正の案内」です

フォームでは、エラーが出ること自体をゼロにはできません。大切なのは、エラーが出たあとに利用者が迷わず直せることです。設計時は次の順番で検討します。

• その項目は本当に必須なのか
• どのタイミングでエラーを見せるのか
• 何が問題で、どう直せばよいかをどう書くか
• よく出るエラーをどのログで把握するか

文言だけでなく、受付条件や表示タイミングも見直します。修正できない条件を要求していれば、丁寧な案内文へ変更しても利用者は送信を完了できません。

バリデーションエラーと、通信・受付処理の失敗を区別します

バリデーションエラーは、入力値が定めた受付条件を満たしていない状態です。何の条件に合わなかったかを分けると、利用者が修正する項目と、システム側で調べる問題を区別できます。

• 必須条件：受付や返信に必要な情報が未入力になっている。
• 形式条件：メールアドレス、日付、文字数などが受け付ける形式に合っていない。
• 範囲・整合条件：数量や選択項目の組み合わせが、業務上の受付条件を満たしていない。

通信が途切れた場合やサーバーで処理できなかった場合に、入力内容の修正を求めても解決しません。後述するように、入力の問題、処理の失敗、受付結果が不明な状態で案内を変えます。

途中離脱が増えやすいのは、エラーの厳しさより「戻しにくさ」です

1. どこが問題か分からない

ページ上部に「入力内容を確認してください」とだけ出ると、利用者は自分で該当箇所を探す必要があります。スマートフォンでは特に負担が大きくなります。

2. 文言が抽象的すぎる

「入力値が不正です」だけでは、形式の問題なのか、未入力なのか、桁数なのか分かりません。修正方法まで見える文言にした方が親切です。

3. 一度のミスで再入力が増える

1項目のエラーで他の入力内容まで消えると、離脱の直接原因になります。メッセージ設計は入力保持と切り離せません。

画面イメージ：エラー表示と見直しメモの並べ方

下の画面例は、左に利用者が見る入力エラーの表示、右に運用側の文言ルールと見直し候補を並べています。ログの43件・27件・9件は説明用の架空の数値です。件数だけで原因や改善効果を判断するものではありません。

バリデーション設計では、最初に「その項目は本当に必須か」を見直します

初回の受付や返信で使う情報を確認し、欠けると何の作業ができないかを項目ごとに説明します。必須・任意・後から確認・削除の判断例は、問い合わせフォームの項目設計で扱います。

エラーを表示するタイミングと位置を決めます

フォームでは、入力中に出した方がよいものと、送信時にまとめて返した方がよいものがあります。表示タイミングを分けると、必要以上に急かしている印象を抑えられます。

場面	向いている内容	考え方
入力中	入力例、文字数、使用できる形式などの補助	まだ入力途中の値を、完成した回答として判定しないようにします。
入力後	メール形式、桁数など、項目単位の確認	入力欄を離れた時などに確認します。エラー後の修正をいつ再確認するかも決めます。
送信時	未入力、全体の不足、組み合わせ不整合など	全体を見ないと判断できないものは送信時にまとめて返す方が自然です。

表示位置	表示する内容	役割
項目の直下	対象欄の原因と修正方法	該当箇所を探さずに直せるよう、エラー文を入力欄の近くに表示します。
画面上部の要約	エラー件数や対象項目の一覧	スマホでは項目が縦に長くなるため、要約が全体把握を助けます。

送信時に複数のエラーが出る場合は、上部で件数と対象項目を示し、各入力欄の直下で具体的な修正方法を伝えます。上部の項目名から該当欄へ移動できるリンクや、最初のエラー欄へのフォーカスも検討対象です。

色だけでエラーを伝えず、項目名と修正方法をテキストで示します。読み上げ環境でも入力欄と説明の関係を把握できるようにします。W3Cのフォーム通知ガイドでも、項目ごとの案内と全体の通知を扱っています。入力中の表示を詳しく検討する場合は、即時バリデーションの設計を参照できます。

文言には「何が問題か」と「どう直すか」を記載します

エラーメッセージは短いほど良いとは限りません。次に取るべき行動まで示せば、利用者は迷わず再送できます。

1. 対象項目を入れる
   「メールアドレス」「電話番号」など、どこを直すのかが分かる形にします。
2. 問題の種類を示す
   未入力、形式、文字数のどれが原因かを示し、修正箇所を特定できるようにします。
3. 必要なら例を添える
   メールアドレスや電話番号など形式が伝わりにくい項目では、入力例が迷いを減らします。

「〜を入力してください」「〜の形式を確認してください」のように文末の型を数種類に決めておけば、担当者ごとの表現差を抑えられます。

抽象的な文言	修正方法が分かる文言	伝える条件
入力エラーです	郵便番号は7桁で入力してください	日本の郵便番号を受け付ける例です。海外住所も扱う場合は、国ごとの形式を確認します。
形式が違います	電話番号は数字で入力してください	数字のみを受け付ける仕様の例です。ハイフンや国番号を許容する場合は、文言も合わせます。
入力内容に問題があります	メールアドレスの「@」前後を確認してください	対象欄と確認箇所を示します。

よくある項目ほど、エラーの出方にあわせて書き方を変えた方が実用的です

入力エラーは、メッセージを出す前の入力補助でも減らせます

同じエラーが繰り返される場合は、警告文だけでなく入力方法も確認します。形式が決まっている情報は、利用者が入力規則を推測しなくてもよい画面にします。

1. 端末に合う入力方法を指定する
   メールアドレス、電話番号、数字などに合う入力種別やキーボードを使います。
2. 選択肢で回答できる項目は手入力を減らす
   問い合わせ種別や都道府県など、候補が決まっている項目はラジオボタンや選択欄を検討します。
3. 入力例と条件をエラー前に示す
   文字数、利用可能な記号、日付形式など、誤りが多い条件を入力欄の近くに記載します。

ブラウザーは入力を補助し、サーバーは受付条件を確認します

ブラウザーでは、その場で直せる形式や文字数を案内します。最終的な受付では、サーバー側でも必須・形式・範囲・組み合わせの条件を確認します。ブラウザーのチェックは回避できるため、画面上の判定だけでは受付条件を保証できません。MDNのフォーム検証ガイドも、サーバー側での検証が必要であることを説明しています。

• 条件を一致させる：画面ではハイフンを許容しているのに、受信側では拒否する、といった違いをなくします。
• 任意と条件付き必須を区別する：任意の空欄は受け付け、入力されている場合に形式を確認します。選択内容によって必須になる項目は、同じ条件を受信側にも適用します。
• 表示時点と受付時点を区別する：予約枠など変化する情報は、最終受付時にも確認します。「選択可能」と表示したことを、予約確定と同じ意味にはしません。
• 表示用の値を信頼しない：hidden項目や画面に表示した金額・区分も、受信側で正当性を確認します。再計算する値と、有効性を確認する識別子を分けます。

入力形式の確認だけでは、迷惑送信対策やアクセス権の確認を代替できません。拒否した理由は調査できる形で記録し、画面には利用者が取れる操作を案内します。内部の判定条件や機密情報をそのままエラー文へ出さないようにします。

エラー後は、問題のない入力内容を残します

送信時に一部の項目がエラーになっても、修正対象ではない入力まで消す必要はありません。サーバー側で入力値を再表示する場合は、HTMLへの出力時にエスケープ処理を行います。

保持する場所と期間、受付完了後の削除方法はフォームの用途ごとに決めます。添付を引き継ぐ場合も、ブラウザーから渡された識別子だけで他の利用者のファイルを参照できないことを確認します。詳しくはファイル添付・アップロードの設計で扱います。

入力エラー・通信失敗・二重送信で、次の操作を変えます

利用者へのメッセージは、システムが確認できた状態に合わせます。通信が途切れた時点では、サーバーで登録されたか分からない場合があるため、常に「送信されていません」とは案内できません。

確認できた状態	案内する内容の例	受付処理で決めること
入力値が受付条件を満たさない	対象欄・原因・修正例	修正対象と保持する値を決め、修正後に再確認します。
送信中	処理中であることと、結果が出るまで待つ案内	画面の連続操作を抑え、サーバー側でも同じ送信の重複登録を防ぎます。
通信が途切れ、受付結果が不明	受付結果を確認できていないこと	同じ送信を識別して受付結果を照合するか、問い合わせ先へ確認できる方法を用意します。無条件の再送を促しません。
未受付であることが確認できた処理失敗	現在は処理を完了できないことと、再試行・連絡方法	再試行できる条件と保持期間を決めます。入力内容の誤りとして扱いません。
受付済みの同じ送信を再度受信	受付済みであることと、確認できる受付情報	追加登録せず既存の結果を返す設計を検討します。同じ本文という理由だけで、別の正当な問い合わせを重複扱いしないようにします。

「同じ送信」の識別方法、識別子を保持する期間、修正後に新しい送信として扱う条件を決めます。入力エラーの後は修正して進め、受付済みの再送では重複登録せず、結果不明の場合は確認へ進めるようにします。完了画面や自動返信は、受付が成立した状態に合わせて表示・送信します。

ログで、文言と項目設計のどちらを直すべきか判断します

同じ項目でエラーが多発していても、原因が文言不足とは限りません。入力方法、必須設定、許容形式のどこに原因があるかを分けて調べます。

• 項目名
• エラー種別
• 発生回数
• 発生タイミング

発生回数を見る時は、1回の操作を数えるのか、同じ入力機会で何度出ても1件と数えるのかを決めます。条件付き項目では表示対象になった入力を基準にし、ブラウザーとサーバーで同じエラーを二重計上しないようにします。

項目名やエラー種別で分析できるようにし、氏名、メールアドレス、問い合わせ本文などの入力値そのものをアクセス解析へ送らない設定にします。受付に必要な記録と、画面改善のための計測は保存先・閲覧者・保存期間も分けて確認します。

まとめ

問い合わせフォームのエラーメッセージは、対象項目・原因・修正方法を伝える案内です。必須条件、表示タイミング、入力補助、値の保持を決め、ブラウザーとサーバーで受付条件を一致させます。

通信失敗や受付結果が不明な状態は、入力エラーと分けて扱います。利用者が修正・確認・再試行のどれに進めばよいかを明示し、同じ送信を重複登録しない処理と、個人情報を含めない改善用の計測を確認します。