エラー画面は「失敗の通知」ではなく、ユーザーを目的に戻すための導線として設計する。本ドキュメントでは、エラーの分類、メッセージの書き方、画面構成、技術的な考慮点、チェックリストをまとめる。
目次
- 基本原則
- エラーの分類と設計方針
- メッセージの書き方
- 画面構成の要素
- フォームのバリデーションエラー
- ビジュアルデザイン
- アクセシビリティ
- 技術・運用面の考慮点
- よくあるアンチパターン
- 設計チェックリスト
- 参考
1. 基本原則
| 原則 | 内容 |
|---|
| 何が起きたかを伝える | 状況を平易な言葉で説明する。「エラーが発生しました」だけで終わらせない |
| なぜ起きたかを伝える（可能な範囲で） | 原因がユーザー側か、システム側かを明確にする |
| 次に何をすればよいかを示す | 再試行・戻る・問い合わせなど、具体的な行動を提示する |
| ユーザーを責めない | 「不正な入力です」ではなく「〇〇の形式で入力してください」 |
| 入力内容・作業状態を失わせない | エラー後もフォーム入力や編集中のデータを保持する |
| 一貫性を保つ | トーン、レイアウト、色、アイコンをサービス全体で統一する |
2. エラーの分類と設計方針
エラーは発生箇所と影響範囲によって、表示方法を変える。
2.1 影響範囲による分類
| 種類 | 例 | 推奨する表示方法 |
|---|
| フィールド単位 | メール形式の誤り、必須項目の未入力 | 入力欄の直下にインラインメッセージ |
| フォーム／操作単位 | 送信失敗、保存失敗 | フォーム上部のサマリー、トースト、バナー |
| コンポーネント単位 | 一部ウィジェットのデータ取得失敗 | そのコンポーネント内に限定したエラー表示（画面全体は壊さない） |
| ページ単位 | 404、403、500 | 専用のエラーページ |
| アプリ／システム全体 | メンテナンス、オフライン、障害 | 全画面表示またはグローバルバナー |
2.2 原因による分類
| 原因 | 例 | ユーザーに求める行動 |
|---|
| ユーザー起因 | 入力ミス、権限不足、期限切れリンク | 修正方法を具体的に示す |
| システム起因 | サーバーエラー、タイムアウト | 謝罪＋再試行、または時間をおいての再アクセス |
| 環境起因 | オフライン、ブラウザ非対応、ストレージ不足 | 環境の確認・変更方法を示す |
| 計画的 | メンテナンス、レート制限 | 復旧予定時刻、待ち時間を示す |
3. メッセージの書き方
3.1 構成の型
[見出し] 何が起きたか（短く）
[本文] 理由と影響（1〜2文）
[アクション] 次にできること（ボタン・リンク）
[補足] エラーID、問い合わせ先など（必要時のみ）
3.2 良い例・悪い例
| 悪い例 | 良い例 | 改善ポイント |
|---|
| エラーが発生しました | 保存できませんでした。通信状況を確認して、もう一度お試しください。 | 何が失敗したか＋次の行動 |
| 不正な値です | 電話番号は半角数字で入力してください（例: 09012345678） | 責めない・正しい形式と例を示す |
| Error 500: Internal Server Error | 一時的な問題が発生しています。しばらくしてから再度お試しください。 | 専門用語を避ける |
| ページが見つかりません | お探しのページは移動または削除された可能性があります。 | 考えられる原因を補足 |
| ログインに失敗しました（パスワードが違います） | メールアドレスまたはパスワードが正しくありません。 | セキュリティ上、どちらが誤りかは明かさない |
3.3 文体ガイドライン
- 専門用語・コードを主文に出さない（ステータスコードやエラーIDは補足情報として小さく表示）
- 否定・命令より、提案・案内の表現を使う
- 一文を短く、結論から書く
- ユーモアは慎重に：404など軽微なケースでは許容されるが、決済失敗・データ消失など深刻なケースでは使わない
- 謝罪はシステム起因のときのみ。ユーザー起因のエラーで過剰に謝らない
- 感嘆符や大文字・赤色の多用で煽らない
4. 画面構成の要素
4.1 専用エラーページ（404 / 500 など）に含めるもの
- サイト共通のヘッダー・ナビゲーション（迷子にさせない）
- わかりやすい見出し
- 短い説明文
- 主要アクション（ホームへ戻る、前のページへ戻る、再読み込み）
- 補助アクション（サイト内検索、よく使われるページへのリンク、問い合わせ）
- エラーID・発生時刻（問い合わせ時にサポートが調査できるように）
- イラスト・アイコン（任意。状況を補足する程度に）
4.2 ステータス別の設計ポイント
| ステータス | 設計ポイント |
|---|
| 400 Bad Request | 入力やリクエスト内容の見直しを促す |
| 401 Unauthorized | ログイン画面へ誘導し、ログイン後に元のページへ戻す |
| 403 Forbidden | 権限がない旨と、権限申請・管理者への連絡方法を示す。リソースの存在自体を隠すべき場合は404を返す |
| 404 Not Found | 検索ボックス、人気ページ、ホームへのリンクを置く。リンク切れの報告手段があるとよい |
| 408 / 504 Timeout | 再試行ボタンを目立たせる |
| 429 Too Many Requests | 待ち時間の目安を示す |
| 500 Internal Server Error | 謝罪＋再試行。ユーザー側の問題ではないことを明示する |
| 503 Service Unavailable | メンテナンス・障害の旨、復旧予定時刻、ステータスページへのリンク |
4.3 アプリ内のエラー状態
- 部分的な失敗は部分的に表示する：一つのAPIが失敗しても画面全体をエラーにしない
- 空状態（Empty State）とエラーを区別する：「データが0件」と「取得に失敗した」は別の表示にする
- オフライン時：オフラインであることをバナーで示し、閲覧可能なキャッシュは表示し続ける。復帰時に自動で再取得する
- リトライ：自動リトライ（指数バックオフ）と手動リトライボタンを組み合わせる
- トーストの使い分け：自動で消えるトーストは軽微な通知のみ。対応が必要なエラーはユーザーが閉じるまで残す
5. フォームのバリデーションエラー
- エラーは該当フィールドの近く（直下）に表示する
- 複数エラーがある場合はフォーム上部にサマリーを出し、各フィールドへのリンクを付ける
- 送信時に最初のエラー項目へフォーカスを移動する
- バリデーションのタイミング
- 入力中にリアルタイムで赤くしない（入力途中でエラー扱いしない）
- フィールドを離れたとき（blur）または送信時に検証する
- エラー表示後は、修正された時点ですぐにエラーを解除する
- 制約は事前に示す：文字数・形式・必須項目は、入力前にラベルやヘルプテキストで伝える
- 入力値を消さない：エラー時もユーザーの入力を保持する（パスワードなど機密項目は例外を検討）
6. ビジュアルデザイン
- 色だけに頼らない：赤色＋アイコン＋テキストの組み合わせで伝える（色覚多様性への配慮）
- コントラスト比：テキストは WCAG AA（通常テキスト 4.5:1 以上）を満たす
- 重要度に応じたレベル分け：エラー（赤）／警告（黄・橙）／情報（青）を一貫して使い分ける
- アイコンの統一：エラー・警告・情報で決まったアイコンを使う
- イラストは控えめに：主要アクションより目立たせない
- レイアウトを崩さない：エラーメッセージ表示でレイアウトが大きくずれないよう、表示領域を考慮する
7. アクセシビリティ
- エラーメッセージを入力欄と関連付ける（
aria-describedby）
- エラー状態の入力欄に
aria-invalid="true" を設定する
- 動的に表示されるエラーは
role="alert" または aria-live でスクリーンリーダーに通知する
- エラーページの
<title> にもエラー内容を含める（例: 「ページが見つかりません | サイト名」）
- エラー発生時にフォーカスを適切な位置（エラーサマリーや見出し）へ移動する
- キーボードのみで全てのリカバリー操作ができるようにする
8. 技術・運用面の考慮点
8.1 セキュリティ
- スタックトレース、SQL、内部パス、サーバー情報を表示しない
- 認証エラーでは、アカウントの存在有無がわからないメッセージにする
- 権限のないリソースは、必要に応じて403ではなく404で応答する
8.2 HTTPステータスとSEO
- エラーページは正しいステータスコードを返す（404ページが200を返す「ソフト404」を避ける）
- 恒久的に移動したページは301リダイレクトを設定する
- メンテナンス時は503と
Retry-After ヘッダーを返す
8.3 エラーページ自体の堅牢性
- 500・503ページはアプリ本体やDB・外部APIに依存しない静的HTMLで用意する
- CSS・画像はインライン化またはCDNなど別経路で配信し、障害時にも表示できるようにする
- SPAではエラーバウンダリ（React の Error Boundary など）で画面全体のクラッシュを防ぐ
8.4 計測と改善
- エラーIDを発行し、画面表示とサーバーログを紐付ける
- エラーの発生件数・種類・発生ページを監視ツールで記録する
- 404の参照元を分析し、リンク切れを修正する
- 頻発するバリデーションエラーは、フォーム設計そのものを見直すシグナルとして扱う
9. よくあるアンチパターン
- 「エラーが発生しました」だけで原因も対処も示さない
- ブラウザ・サーバーのデフォルトエラーページをそのまま表示する
- エラー後に入力内容がすべて消える
- 行き止まりの画面（ナビゲーションも戻る導線もない）
- モーダルの
alert() でエラーを連発する
- 技術的なエラーコードや英語の例外メッセージを主文として表示する
- 一部の失敗で画面全体を真っ白にする
- 深刻なエラー（決済失敗など）で不適切なユーモアを使う
- 再試行ボタンが二重送信（二重決済など）を引き起こす設計になっている
10. 設計チェックリスト
メッセージ
画面・操作
アクセシビリティ・デザイン
技術
参考
- Nielsen Norman Group「Error-Message Guidelines」
- W3C WCAG 2.2（3.3 入力支援：エラーの特定、エラー修正の提案）
- Material Design / Apple Human Interface Guidelines のエラー・アラートに関するガイドライン
- GOV.UK Design System「Error message」「Error summary」コンポーネント