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

エラーメッセージは、ユーザーが問題に直面した瞬間に表示されるテキストです。この瞬間のコミュニケーションが適切であれば、ユーザーは問題を解決して操作を続行できます。不適切であれば、混乱と不満を招き、サービスからの離脱につながります。Nielsen Norman Group の調査によると、ユーザーはエラーメッセージを平均 1.5 秒しか読まないとされており、最初の 5〜7 語にほぼすべての伝達力が集中します。この記事では、認知心理学やユーザビリティ研究の知見を交えながら、ユーザーに伝わるエラーメッセージの文字数と表現方法を解説します。エラーメッセージ設計の基礎を体系的に学びたい方は、UX ライティングの関連書籍も参考になります。

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

エラーメッセージは短すぎると情報不足、長すぎると読まれません。エラーの種類に応じた適切な文字数を設定することが重要です。以下の推奨文字数は、表示コンテキスト (インライン、トースト、全画面) とユーザーの心理状態 (焦り、困惑、不安) の両面から導き出した目安です。

エラーメッセージの基本構造は「何が起きたか + どうすればよいか」の 2 要素です。原因だけを伝えて解決策を示さないメッセージは、ユーザーを途方に暮れさせます。認知心理学では、人間がストレス下で処理できる情報量は通常時の約 60% に低下するとされています。エラー発生時のユーザーはまさにこの状態にあるため、メッセージは通常のテキストよりも短く、構造を明確にする必要があります。

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

ユーザーに伝わるエラーメッセージには、共通する 3 つの原則があります。これらはニールセンの 10 ユーザビリティヒューリスティクスのうち「エラーからの回復を支援する」(Help users recognize, diagnose, and recover from errors) に直接対応する設計指針です。

1. 何が起きたかを平易に説明する: 技術用語を避け、ユーザーが理解できる言葉で状況を伝える。「500 Internal Server Error」ではなく「サーバーで問題が発生しました」。認知負荷理論の観点では、専門用語は外的認知負荷 (extraneous cognitive load) を増大させ、問題解決に使える認知リソースを奪います
2. なぜ起きたかを簡潔に示す: 可能であれば原因を伝える。「入力されたメールアドレスの形式が正しくありません」。原因の提示は、ユーザーのメンタルモデル (システムの動作に対する内的な理解) を修正し、同じエラーの再発を防ぐ効果があります
3. どうすればよいかを具体的に案内する: 解決策や次のアクションを明示する。「@ を含むメールアドレスを入力してください」。ユーザビリティ研究では、解決策を含むエラーメッセージはタスク完了率を最大 50% 向上させるとされています

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

主要サービスのエラーメッセージ設計パターン

Google、Apple、Microsoft の 3 社は、それぞれ異なるアプローチでエラーメッセージを設計しています。各社のパターンを分析すると、自社サービスに適した設計の方向性が見えてきます。

共通しているのは、いずれも「ユーザーを責めない」「次のアクションを提示する」という 2 点です。表現のスタイルは異なっても、エラー回復性 (error recovery) を最優先する姿勢は一致しています。

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

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

• ユーザーを責めない: 「入力が間違っています」ではなく「入力内容を確認してください」。心理学の帰属理論によると、人は失敗の原因を外部に帰属させたがる傾向があります。ユーザーを責める表現は防衛反応を引き起こし、問題解決への集中を妨げます
• 専門用語を使わない: 「認証トークンが無効です」ではなく「ログインの有効期限が切れました。再度ログインしてください」
• 曖昧な表現を避ける: 「エラーが発生しました」だけでは、ユーザーは何をすればよいか分からない。HTTP ステータスコードをそのまま表示するのも同様に不適切です
• ユーモアは慎重に: 404 ページでは許容されるが、決済エラーでは不適切。エラーの深刻度に応じてトーンを使い分けることが重要です

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

HTTP ステータスコード別のエラーメッセージ設計

Web アプリケーションでは、HTTP ステータスコードに応じてエラーメッセージの内容と長さを最適化する必要があります。ステータスコードはあくまで開発者向けの情報であり、ユーザーにはコードではなく状況と解決策を伝えます。

重要なのは、セキュリティ上の配慮です。401 と 403 の区別をユーザーに明示すると、認証済みユーザーの存在やリソースの存在が攻撃者に漏洩する可能性があります。ログインページでは「メールアドレスまたはパスワードが正しくありません」のように、どちらが間違っているかを特定できない表現を使うのが安全です。

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

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

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

バリデーションの表示タイミングにも注意が必要です。フィールドにフォーカスした瞬間にエラーを表示すると、ユーザーはまだ入力を始めてもいないのに叱られた気分になります。推奨されるのは、フィールドからフォーカスが外れた時点 (blur イベント) でバリデーションを実行するパターンです。ただし、パスワード強度のようにリアルタイムフィードバックが有益な場合は、入力中の表示も効果的です。

成功状態のフィードバックも忘れずに設計します。入力が正しい場合にチェックマークや緑色のボーダーを表示することで、ユーザーは安心して次のフィールドに進めます。色だけに頼らず、アイコンやテキストを併用することで、色覚多様性のあるユーザーにも情報が伝わります。

トースト通知 vs インライン表示の使い分け

エラーメッセージの表示方法は、エラーの性質によって使い分ける必要があります。主な表示パターンとその適用場面を整理します。

スクリーンリーダーへの対応も重要です。動的に表示されるエラーメッセージには role="alert" または aria-live="assertive" を設定し、視覚に頼らないユーザーにもエラーの発生が即座に伝わるようにします。トースト通知のように自動消去されるメッセージは、スクリーンリーダーが読み上げる前に消えてしまう問題があるため、重要なエラーにはインライン表示を優先します。

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

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

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

システムエラー (500 系) では、復旧の見込みや代替手段を伝えることが重要です。「現在メンテナンス中です。30 分後に再度お試しください」のように、具体的な時間を示すとユーザーの不安が軽減されます。心理学の不確実性回避の原則に基づくと、「しばらくお待ちください」よりも「約 30 分後に復旧予定です」の方が、ユーザーのストレスを大幅に軽減します。

モバイル環境では画面サイズの制約があるため、エラーメッセージの設計に追加の配慮が必要です。320px 幅のスマートフォンでは、インラインバリデーションメッセージが 2 行以上に折り返されるとフォーム全体のレイアウトが崩れます。モバイルでは 15〜25 文字を目安にし、詳細は「詳しく」リンクで段階的に開示する設計が有効です。

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

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

GitHub の 404 ページ「This is not the web page you are looking for」(スター・ウォーズのパロディ) は、エラーページにユーモアを取り入れた成功例として広く知られています。一方、Amazon の 404 ページには犬の写真が表示され、ブランドの親しみやすさを演出しています。ただし、ユーモアが許容されるのは 404 ページのような「致命的でないエラー」に限られ、決済エラーやデータ消失のエラーでは不適切です。

HTTP 404 ステータスコードの由来には諸説あります。CERN のオフィス 404 号室に最初の Web サーバーがあったという説が有名ですが、実際には HTTP ステータスコードは 1992 年に体系的に定義されたもので、400 番台はクライアントエラーを示すカテゴリとして設計されました。

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

エラーメッセージの最適な長さは、ユーザーの感情状態、問題の複雑さ、表示領域の 3 つの要因で決まります。

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

システムエラー (40〜80 文字) は、「何が起きたか」「いつ復旧するか」「代替手段はあるか」の 3 要素を含める必要があり、この情報量を収めるには 40 文字以上が必要です。80 文字を超えると、ユーザーがパニック状態で読み切れなくなるため、上限も設定されています。認知心理学のマジカルナンバー 7±2 の法則に照らすと、1 つのエラーメッセージに含める情報チャンクは 3〜4 個が限界です。

多言語対応時のエラーメッセージ設計

グローバルなサービスでは、エラーメッセージの多言語対応が避けられません。しかし、単純な翻訳では品質を維持できないケースが多くあります。多言語対応の設計パターンについては、Web アプリケーション設計の技術書で体系的に学べます。

• 文字数の膨張: 英語のエラーメッセージを日本語に翻訳すると、文字数は約 60〜70% に縮小します。逆に、日本語からドイツ語やフランス語に翻訳すると 30〜40% 膨張します。UI のレイアウトは最も長い言語に合わせて設計する必要があります
• 文化的な配慮: 日本語では「恐れ入りますが」のような丁寧な前置きが自然ですが、英語では冗長に感じられます。各言語の文化的な期待に合わせてトーンを調整しましょう
• テンプレート化の落とし穴: 「{field} は必須です」のようなテンプレートは、英語では "The {field} is required" と自然ですが、言語によっては語順や格変化の問題で不自然な文になります。テンプレートの設計時に、対象言語の文法構造を考慮することが重要です
• 右から左 (RTL) 言語: アラビア語やヘブライ語では、テキストの方向が逆になります。エラーアイコンの配置やテキストの整列方向も反転させる必要があります

セキュリティとエラーメッセージ

エラーメッセージは、攻撃者にとって貴重な情報源になり得ます。セキュリティの観点から、以下の点に注意が必要です。

• 情報漏洩の防止: スタックトレース、データベースのテーブル名、内部 API のエンドポイント、サーバーのバージョン情報などをエラーメッセージに含めてはいけません。本番環境では、詳細なエラー情報はサーバーサイドのログにのみ記録し、ユーザーには汎用的なメッセージを返します
• ユーザー列挙攻撃の防止: ログインフォームで「このメールアドレスは登録されていません」と表示すると、攻撃者はどのメールアドレスが登録済みかを特定できます。「メールアドレスまたはパスワードが正しくありません」のように、どちらが間違っているかを特定できない表現を使います
• レート制限のメッセージ: 「あと 3 回でアカウントがロックされます」のような具体的な回数を表示すると、攻撃者にブルートフォース攻撃の残り試行回数を教えることになります。「しばらく時間をおいてから再度お試しください」のように曖昧にする方が安全です

よくある失敗パターン

• エラーコードだけを表示する: 「Error 0x80070005」のような技術的なエラーコードは、開発者以外には何の意味も持ちません。エラーコードを表示する場合は、必ず平易な説明文を併記しましょう
• ユーザーを責める表現を使う: 「入力が間違っています」「不正な操作です」のような表現は、ユーザーに罪悪感を与えます。「入力内容を確認してください」「この操作は現在利用できません」のように、中立的な表現に置き換えましょう
• 解決策を示さずに原因だけを伝える: 「ネットワークエラーが発生しました」だけでは、ユーザーは何をすればよいか分かりません。「ネットワーク接続を確認し、再度お試しください」のように、必ず次のアクションを提示します
• エラーメッセージの使い回し: すべてのエラーに「問題が発生しました。再度お試しください」を表示するのは、ユーザーにとって最も不親切なパターンです。エラーの種類ごとに固有のメッセージを用意しましょう
• 入力値のクリア: エラー発生時にフォームの入力値をクリアしてしまうと、ユーザーは最初から入力し直す必要があります。エラー箇所を強調しつつ、入力済みの値は保持するのが鉄則です

API エラーレスポンスの設計

API のエラーレスポンスは、フロントエンドの開発者とエンドユーザーの両方に情報を伝える必要があります。機械可読なエラーコードと人間向けメッセージを組み合わせた構造が推奨されます。

一般的なエラーレスポンスの構造は、エラーコード (機械可読な一意の識別子)、メッセージ (人間が読める説明)、詳細情報 (バリデーションエラーの場合はフィールドごとのエラー) の 3 層で構成します。エラーコードは HTTP ステータスコードとは別に、アプリケーション固有のコード体系を設計すると、フロントエンドでの条件分岐が容易になります。

API エラーメッセージの国際化では、エラーコードをキーとして各言語のメッセージを管理する方式が効率的です。サーバーサイドでは英語のメッセージを返し、フロントエンドでユーザーのロケールに応じた翻訳を表示する設計が、保守性と拡張性の両面で優れています。

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

• エラーメッセージの「トーンマトリクス」を作成する: エラーの深刻度 (低・中・高) とユーザーの感情状態 (焦り・困惑・怒り) の 2 軸でマトリクスを作り、各セルに適切なトーンを定義します。軽微なバリデーションエラーはカジュアルに、決済エラーは丁寧かつ具体的に、という使い分けが可能になります
• エラーの「予防」をメッセージより優先する: 最良のエラーメッセージは「表示されないエラーメッセージ」です。入力制限をリアルタイムで表示する (文字数カウンターのような残り文字数表示)、無効な選択肢をグレーアウトする、自動補完で入力ミスを防ぐなど、エラーが発生しない UI 設計を優先しましょう。ニールセンのヒューリスティクス「エラーの予防」(Error prevention) はこの考え方を体系化したものです
• エラーログとユーザー向けメッセージを分離する: 開発者向けの詳細なエラー情報 (スタックトレース、リクエスト ID) はログに記録し、ユーザーには平易なメッセージだけを表示します。ただし、サポートに問い合わせる際に必要な「エラー ID」は、ユーザー画面にも小さく表示しておくと便利です
• エラーメッセージのテンプレート化: 大規模なアプリケーションでは、エラーメッセージをテンプレートとして一元管理します。「{action} できませんでした。{reason}。{solution}」のような構造化テンプレートを用意し、各エラーに対してパラメータを埋め込む方式にすると、一貫性の維持と翻訳管理が容易になります
• A/B テストでメッセージを最適化する: エラーメッセージもマーケティングコピーと同様に A/B テストの対象です。異なる文言でタスク完了率やフォーム離脱率を比較し、データに基づいてメッセージを改善します。小さな文言の変更がコンバージョン率に大きく影響することがあります
• 年次のエラーメッセージ棚卸し: 製品内のすべてのエラーメッセージを年に 1 回は棚卸しします。廃止された機能への言及、一貫性のないフォーマット、古い連絡先情報など、放置されがちな問題を発見できます

まとめ

エラーメッセージは、ユーザー体験を左右する重要な UI 要素です。認知心理学の知見が示すように、ストレス下のユーザーが処理できる情報量は限られています。「何が起きたか + どうすればよいか」の 2 要素を基本に、エラータイプに応じた適切な文字数で設計しましょう。バリデーションは 15〜40 文字、操作エラーは 30〜60 文字、システムエラーは 40〜80 文字を目安に、文字数カウントスで文字数を確認しながら、ユーザーに寄り添うメッセージを作成してください。セキュリティ上の情報漏洩、多言語対応時の文字数膨張、アクセシビリティへの配慮も忘れずに、プロダクト全体で一貫したエラーメッセージ体験を構築することが大切です。