最終更新: 2026-08-16

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

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

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

エラーメッセージの基本構造は「何が起きたか + どうすればよいか」の 2 要素です。原因だけを伝えて解決策を示さないメッセージは、ユーザーを途方に暮れさせます。エラーに直面したユーザーは、作業が止まった苛立ちと「自分が何か壊したのではないか」という不安を同時に抱えており、腰を据えて長文を読む状態にはありません。だからこそメッセージは通常のテキストよりも短く、一読して次の行動が決まる構造にする必要があります。

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

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

1. 何が起きたかを平易に説明する: 技術用語を避け、ユーザーが理解できる言葉で状況を伝える。「500 Internal Server Error」ではなく「サーバーで問題が発生しました」。認知負荷理論の観点では、専門用語は外的認知負荷 (extraneous cognitive load) を増大させ、問題解決に使える認知リソースを奪います
2. なぜ起きたかを簡潔に示す: 可能であれば原因を伝える。「入力されたメールアドレスの形式が正しくありません」。原因の提示は、ユーザーのメンタルモデル (システムの動作に対する内的な理解) を修正し、同じエラーの再発を防ぐ効果があります
3. どうすればよいかを具体的に案内する: 解決策や次のアクションを明示する。「@ を含むメールアドレスを入力してください」。直し方まで書かれていれば、ユーザーは推測や試行錯誤をせずに 1 回で修正できます。原因の説明で終わっているメッセージは、「では何を直せばよいのか」を考える手間をユーザー側に残し、その分だけ離脱の余地を作ります

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

エラーメッセージ設計の 3 つのアプローチ

実際のプロダクトで使われているエラーメッセージの書き方は、大きく 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 分後に再度お試しください」のように、具体的な時間を示すとユーザーの不安が軽減されます。「しばらくお待ちください」だけでは、5 分後に開き直すべきなのか、今日は諦めるべきなのかを判断できません。時間を約束できない場合でも、状況を確認中であることと次に情報を更新する時刻を書けば、放置されている感覚は避けられます。

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

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

Windows の「ブルースクリーン」(BSOD) は、一般の利用者にまで名前が知られた数少ないエラー画面です。Microsoft は Windows 8 と Windows Server 2012 で画面を刷新し、16 進数のエラーコードを並べる形をやめて、悲しい顔の絵文字 ":(" と平易なエラー名を大きく置く形に変えました。QR コードでサポートページへ誘導する仕組みが加わったのは Windows 10 のバージョン 1607 からです。ただし 2025 年の Windows 11 の更新では、この QR コードと絵文字がともに取り除かれ、レイアウトも見直されました。「技術用語を並べるのではなく、状況を平易に伝えて次の行動に導く」という方向自体は、その後のエラー画面設計に受け継がれています。

404 ページにユーモアやブランドらしさを持たせる工夫は広く行われていて、一言のパロディやイラストで空振りの気まずさを和らげる例は珍しくありません。ただしユーモアが許容されるのは 404 ページのような「致命的でないエラー」に限られ、決済エラーやデータ消失の場面では同じ表現が不誠実に映ります。深刻度が上がるほど、ユーモアよりも「何が保全され、何が失われたか」をはっきり書くことが求められます。

HTTP 404 の由来としては、CERN のオフィス 404 号室に最初の Web サーバーがあったという説がよく語られますが、裏付けのある話ではありません。3 桁のコードという仕組み自体は FTP や NNTP といった先行プロトコルの慣習を引き継いだもので、最初の桁で問題の所在を示す設計になっています。400 番台はクライアント側、500 番台はサーバー側という区分がそれです。

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

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

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

システムエラー (40〜80 文字) は、「何が起きたか」「いつ復旧するか」「代替手段はあるか」の 3 要素を含める必要があり、この情報量を収めるには 40 文字以上が必要です。上限を 80 文字あたりに置いているのは、それを超えると 1 つのメッセージに要素が増えすぎて、焦っている読み手が全部を追えなくなるからです。実務上は「状況」「対処」「次の導線」の 3 つ程度が、一読で持ち帰ってもらえる限界だと考えておくとよいでしょう。それ以上の情報 (問い合わせ手順、既知の障害の一覧、技術的な原因) は本文に足すのではなく、リンク先やヘルプへ逃がします。

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

• 文字数の膨張: 同じ内容でも、日本語は漢字で圧縮が効く一方、ドイツ語やフランス語では語が長く連なって横幅を大きく食います。UI のレイアウトは、想定する言語の中で最も長くなるものに合わせて設計するのが安全です。特に注意したいのは短いラベルで、「保存」「エラー」のような 2〜3 文字の語は訳すと数倍の幅になることがあり、ボタンやトーストの固定幅を突き破ります。翻訳前の文字数だけを見て枠を決めないことが肝心です
• 文化的な配慮: 日本語では「恐れ入りますが」のような丁寧な前置きが自然ですが、英語では冗長に感じられます。各言語の文化的な期待に合わせてトーンを調整しましょう
• テンプレート化の落とし穴: 「{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 文字を目安に、文字数カウントスで文字数を確認しながら、ユーザーに寄り添うメッセージを作成してください。セキュリティ上の情報漏洩、多言語対応時の文字数膨張、アクセシビリティへの配慮も忘れずに、プロダクト全体で一貫したエラーメッセージ体験を構築することが大切です。