エラーメッセージの設計｜ユーザーに伝わる文字数と表現

エラーメッセージは、ユーザーが問題に直面した瞬間に表示されるテキストです。この瞬間のコミュニケーションが適切であれば、ユーザーは問題を解決して操作を続行できます。不適切であれば、混乱と不満を招き、サービスからの離脱につながります。この記事では、ユーザーに伝わるエラーメッセージの文字数と表現方法を解説します。

エラーメッセージの文字数目安

エラーメッセージは短すぎると情報不足、長すぎると読まれません。エラーの種類に応じた適切な文字数を設定することが重要です。

エラーメッセージの基本構造は「何が起きたか + どうすればよいか」の 2 要素です。原因だけを伝えて解決策を示さないメッセージは、ユーザーを途方に暮れさせます。

良いエラーメッセージの 3 原則

ユーザーに伝わるエラーメッセージには、共通する 3 つの原則があります。

1. 何が起きたかを平易に説明する: 技術用語を避け、ユーザーが理解できる言葉で状況を伝える。「500 Internal Server Error」ではなく「サーバーで問題が発生しました」
2. なぜ起きたかを簡潔に示す: 可能であれば原因を伝える。「入力されたメールアドレスの形式が正しくありません」
3. どうすればよいかを具体的に案内する: 解決策や次のアクションを明示する。「@ を含むメールアドレスを入力してください」

この 3 要素を 1 つのメッセージに収めると、40〜80 文字程度になります。すべてを 1 文に詰め込む必要はなく、2〜3 文に分けて読みやすくすることも有効です。

エラーメッセージのトーンとスタイル

エラーメッセージのトーンは、サービス全体のブランドイメージと一致させることが重要です。ただし、どのようなトーンであっても、以下の点は共通して守るべきです。

• ユーザーを責めない: 「入力が間違っています」ではなく「入力内容を確認してください」
• 専門用語を使わない: 「認証トークンが無効です」ではなく「ログインの有効期限が切れました。再度ログインしてください」
• 曖昧な表現を避ける: 「エラーが発生しました」だけでは、ユーザーは何をすればよいか分からない
• ユーモアは慎重に: 404 ページでは許容されるが、決済エラーでは不適切

エラーメッセージの文字数は文字数カウントスで確認し、簡潔さを保ちながら必要な情報を漏れなく伝えましょう。

フォームバリデーションのベストプラクティス

フォーム入力のバリデーションメッセージは、エラーメッセージの中で最も頻繁にユーザーの目に触れるものです。リアルタイムバリデーション (入力中に即座にフィードバック) を採用すると、ユーザー体験が大幅に向上します。

バリデーションメッセージは 15〜40 文字に収めます。フォームフィールドの近くに表示されるため、長いメッセージはレイアウトを崩す原因になります。「必須項目です」「8 文字以上で入力してください」「有効なメールアドレスを入力してください」のように、具体的かつ簡潔な表現を心がけます。

成功状態のフィードバックも忘れずに設計します。入力が正しい場合にチェックマークや緑色のボーダーを表示することで、ユーザーは安心して次のフィールドに進めます。

システムエラーと 404 ページの設計

システムエラーや 404 ページは、ユーザーが最も不安を感じる場面です。この場面でのメッセージ設計が、ユーザーの離脱を防ぐ最後の砦になります。

404 ページでは、60〜120 文字のメッセージに加えて、トップページへのリンク、検索機能、人気ページへのリンクを提供します。ユーザーが目的の情報にたどり着ける代替手段を必ず用意しましょう。

システムエラー (500 系) では、復旧の見込みや代替手段を伝えることが重要です。「現在メンテナンス中です。30 分後に再度お試しください」のように、具体的な時間を示すとユーザーの不安が軽減されます。

意外と知らないエラーメッセージのトリビア

Windows の「ブルースクリーン」(BSOD) は、世界で最も多くの人が目にしたエラーメッセージとされています。Microsoft は Windows 8 以降、技術的なエラーコードの代わりに悲しい顔の絵文字 ":(" を表示するようにデザインを変更しました。これは「技術用語ではなく感情で共感する」というエラーメッセージ設計の転換点でした。

もう一つ興味深いのは、GitHub の 404 ページです。「This is not the web page you are looking for」というスター・ウォーズのパロディは、エラーページにユーモアを取り入れた成功例として広く知られています。ただし、ユーモアが許容されるのは 404 ページのような「致命的でないエラー」に限られ、決済エラーやデータ消失のエラーでは不適切です。

なぜエラータイプごとに文字数が異なるのか

入力バリデーション (15〜40 文字) が短いのは、フォームフィールドの直下に表示されるため、長いメッセージはレイアウトを崩すからです。一方、404 ページ (60〜120 文字) が長めなのは、ページ全体を使って代替手段 (トップページへのリンク、検索機能) を提示する余裕があるためです。

システムエラー (40〜80 文字) は、「何が起きたか」「いつ復旧するか」「代替手段はあるか」の 3 要素を含める必要があり、この情報量を収めるには 40 文字以上が必要です。80 文字を超えると、ユーザーがパニック状態で読み切れなくなるため、上限も設定されています。

よくある失敗パターン

• エラーコードだけを表示する: 「Error 0x80070005」のような技術的なエラーコードは、開発者以外には何の意味も持ちません。エラーコードを表示する場合は、必ず平易な説明文を併記しましょう
• ユーザーを責める表現を使う: 「入力が間違っています」「不正な操作です」のような表現は、ユーザーに罪悪感を与えます。「入力内容を確認してください」「この操作は現在利用できません」のように、中立的な表現に置き換えましょう
• 解決策を示さずに原因だけを伝える: 「ネットワークエラーが発生しました」だけでは、ユーザーは何をすればよいか分かりません。「ネットワーク接続を確認し、再度お試しください」のように、必ず次のアクションを提示します

プロが実践するエラーメッセージ設計テクニック

• エラーメッセージの「トーンマトリクス」を作成する: エラーの深刻度 (低・中・高) とユーザーの感情状態 (焦り・困惑・怒り) の 2 軸でマトリクスを作り、各セルに適切なトーンを定義します。軽微なバリデーションエラーはカジュアルに、決済エラーは丁寧かつ具体的に、という使い分けが可能になります
• エラーの「予防」をメッセージより優先する: 最良のエラーメッセージは「表示されないエラーメッセージ」です。入力制限をリアルタイムで表示する (残り文字数カウンター)、無効な選択肢をグレーアウトする、自動補完で入力ミスを防ぐなど、エラーが発生しない UI 設計を優先しましょう
• エラーログとユーザー向けメッセージを分離する: 開発者向けの詳細なエラー情報 (スタックトレース、リクエスト ID) はログに記録し、ユーザーには平易なメッセージだけを表示します。ただし、サポートに問い合わせる際に必要な「エラー ID」は、ユーザー画面にも小さく表示しておくと便利です

まとめ

エラーメッセージは、ユーザー体験を左右する重要な UI 要素です。「何が起きたか + どうすればよいか」の 2 要素を基本に、エラータイプに応じた適切な文字数で設計しましょう。バリデーションは 15〜40 文字、操作エラーは 30〜60 文字、システムエラーは 40〜80 文字を目安に、文字数カウントスで文字数を確認しながら、ユーザーに寄り添うメッセージを作成してください。