エラーメッセージ設計とは？ユーザーを止めすぎずに伝える考え方

最初に: エラーメッセージ設計は「赤字を出すこと」ではなく「次の行動を作ること」

エラーメッセージ設計とは、ユーザーが入力や操作でつまずいたときに、何が起きたのか、どう直せばよいのか、次に何をすればよいのかを分かる形で伝える設計です。
ただエラー文言を表示するだけでは不十分で、止めるための表示 ではなく 進めるためのフィードバック として考えるのが大事です。

エラー表示が雑だと、ユーザーは次のような状態になりやすいです。

何が悪いのか分からない
どこを直せばいいか分からない
直してもまた同じ画面で止まる
入力内容が消えてやる気をなくす
自分が悪いのか、サービス側の問題なのか判断できない

逆に、良いエラーメッセージは 失敗したこと だけでなく 復帰する道筋 を示します。
GOV.UK Design System でも、エラーは何が起きたかと直し方を明確に伝えるべきだとされていて、W3C の WCAG でも、エラーはテキストで識別でき、修正の助けになることが重要だと整理されています。

この記事では、2026年4月24日時点で GOV.UK Design System、W3C WCAG 2.2、Nielsen Norman Group の公開情報を確認しながら整理しています。

エラーメッセージ設計とは何か

短く言うと、エラーメッセージ設計は ユーザーが失敗から復帰しやすいようにする設計 です。

見るべきは文言だけではありません。
少なくとも次の要素が関係します。

どのタイミングで出すか
どこに出すか
何をどこまで言うか
どの入力を残すか
色や位置だけに頼らず伝わるか

つまり、コピーライティングと UI 設計とアクセシビリティが重なる領域です。

何を伝えるべきか

基本は次の3点です。

1. 何が起きたか

たとえば

メールアドレスが未入力
日付形式が違う
パスワードが短すぎる
権限が足りない

のように、問題の種類を具体的に示します。

2. どこが問題か

フォーム全体が悪いのではなく、どの項目か を分かるようにします。
GOV.UK でも、ラベルの言葉をエラーメッセージに直接含める考え方が紹介されています。

3. どう直せばいいか

ここが抜けると、ユーザーは止まります。
たとえば エラーが発生しました より、メールアドレスを入力してください のほうが次の行動が分かります。

「何が悪いか」だけで終わると弱い

エラー文言でよくある失敗は、原因だけを言って終わることです。

たとえば次の比較です。

弱い例	よりよい例
入力が不正です	メールアドレスの形式で入力してください
必須項目です	会社名を入力してください
エラーが発生しました	送信に失敗しました。時間をおいてもう一度お試しください
権限がありません	この操作は管理者のみ実行できます

ポイントは、抽象語を減らして、行動に変える ことです。

ユーザーを止めすぎないための考え方

ここがこのテーマの本題です。
全部を強く止めれば安全になるわけではなく、ユーザーが進める余地を残したほうがよい場面もあります。

入力中に出しすぎない

1文字打つたびに赤字が出ると、圧迫感が強くなります。
未入力の必須項目は、フォーカスを外したときや送信時に出すほうが自然なことも多いです。

取り返せるミスは優しく戻す

たとえば郵便番号のハイフン、電話番号の空白、前後スペースなどは、サービス側で吸収できるなら吸収したほうが親切です。

サービス側の問題をユーザーの責任にしない

ユーザーが直せない問題まで 入力エラー のように出すと混乱します。
GOV.UK でも、利用者が修正できない問題は field error ではなく、別の案内ページや service problem として扱うべきだと整理されています。

フォームエラーとサービス側エラーは分ける

ここはかなり大事です。

フォームエラー

ユーザーが直せる問題です。

未入力
形式違い
桁数超過
選択漏れ

この場合は、項目の近くに出して、その場で直せるようにするのが基本です。

サービス側エラー

ユーザーが直せない問題です。

サーバー障害
決済サービス障害
タイムアウト
一時的な混雑

この場合は、あなたが悪い ように見せないことが大事です。
やるべきことは、状況説明、再試行の案内、待ち時間の目安、必要なら問い合わせ導線です。

どこに出すべきか

エラーの場所も重要です。

項目の近く

最も基本です。
どの入力に問題があるか分かりやすくなります。

画面上部の要約

項目数が多いフォームでは、上部にエラー要約を出すと見落としにくくなります。
W3C の技法でも、エラー一覧から該当箇所へ飛べる仕組みが有効とされています。

色だけに頼らない

赤くするだけでは足りません。
テキストでも 何が問題か を明示しないと、色覚差やスクリーンリーダー利用時に伝わりにくくなります。

入力内容を消さないのはかなり重要

エラー時に入力内容を全部消すのは、かなり強いストレスになります。
GOV.UK でも、エラー表示時に通った項目も失敗した項目も残すことが推奨されています。

残しておくことで、ユーザーは

どこまで書いたか確認できる
失敗箇所だけ直せる
再入力の負担を減らせる

ようになります。

特に長いフォーム、問い合わせフォーム、会員登録、決済前画面では、この差が大きいです。

良いエラーメッセージの基本パターン

実務では、次の使い分けをしておくとかなり安定します。

未入力

氏名を入力してください
メールアドレスを入力してください

形式違い

メールアドレスの形式で入力してください
日付は YYYY/MM/DD 形式で入力してください

条件違い

パスワードは8文字以上で入力してください
タイトルは50文字以内で入力してください

サービス問題

送信に失敗しました。時間をおいてもう一度お試しください
現在アクセスが集中しています。しばらくしてから再度お試しください

抽象的な 不正です 無効です エラーです だけで終わらせないのがコツです。

アクセシビリティの観点で見るポイント

アクセシビリティの観点では、少なくとも次を見ます。

エラーがテキストで説明されているか
色だけに頼っていないか
ラベルとエラーが結びついているか
キーボード操作で見つけやすいか
画面上部の要約から該当箇所へ移動できるか

W3C WCAG 2.2 でも、Input Assistance の中で、エラーの識別、ラベルや説明、修正支援が重視されています。
つまり、見た目だけ整っていても、伝わらなければ足りません。

よくある失敗

1. 技術者向けの文言をそのまま出す

validation failed unexpected token SQL error のような内部向け表現は、そのまま出さないほうが安全です。
利用者向けには、行動に変換して伝える必要があります。

2. 「不正です」だけで終わる

何をどう直せばよいか分からず、再送信ループになりやすいです。

3. 全部まとめて上にだけ出す

長いフォームでは、上部要約だけだと該当箇所が分かりにくいです。
一覧と項目近くの両方があるほうが親切です。

4. 利用者が直せないことまで入力エラー扱いする

サーバー障害や権限不足を 入力内容を確認してください にしてしまうと、ユーザーは混乱します。

最初に押さえるべきか

最初は次の5つで十分です。

エラーメッセージは 何が悪いか だけでなく どう直すか まで伝える
フォームエラーとサービス側エラーを分ける
項目の近くに出して、必要なら上部要約も使う
入力内容を消さない
色だけに頼らず、テキストで説明する

まとめ

エラーメッセージ設計は、ユーザーを止めるためではなく、失敗から復帰しやすくするための設計です。
大事なのは、何が起きたか、どこが問題か、どう直せばいいかを、ユーザーが次に動ける形で伝えることです。

最初は次の理解で十分です。

エラー表示はフィードバック
抽象語より具体的な行動
ユーザーが直せる問題と直せない問題を分ける

この整理ができると、フォームや操作画面の離脱をかなり減らしやすくなります。

この記事と一緒に読みたい

参考リンク

GOV.UK Design System: Error message
GOV.UK Design System: Validation
W3C WAI: Understanding Guideline 3.3: Input Assistance
W3C WAI: Understanding SC 3.3.1 Error Identification
Nielsen Norman Group: Heuristic Summary