エラーから回復できる (Error Recovery)

「エラーが発生しました。」——この一文だけが表示されたとき、ユーザーは何をすればいいのかわかりません。ページを再読み込みすればいい？入力が間違っていた？サーバーの問題？——ユーザーは手がかりなく途方に暮れ、多くの場合そのまま離脱します。

よくある失敗は「エラーが出たことは伝えるが、どうすればいいかは伝えない」設計です。「パスワードが違います」は何が間違っているかを伝えますが、「パスワードを忘れた場合はこちら」がなければ、ユーザーは次のアクションに迷います。エラーメッセージは「報告書」ではなく「道案内」でなければなりません。

エラーを完全に防ぐことはできません。ネットワーク障害、入力ミス、予期しない操作——エラーは必ず起きます。だからこそ「エラーが起きた後にどう回復させるか」の設計が、ユーザーの信頼を守る最後の砦になります。

1. 原則の定義

エラーから回復できる（Error Recovery）とは、エラーが発生した際に「何が起きたか」「なぜ起きたか」「どう直すか」を明確に伝え、ユーザーが迷わず元の状態または目的の状態に戻れるよう設計する原則。

本質は「エラーを終点にしないこと」です。エラーメッセージは問題の報告ではなく、次のアクションへの案内です。ニールセンのヒューリスティクス第9原則「エラーの認識・診断・回復の支援」に対応します。

2. いつ使うか（適用場面）

特に重要になるケース

• フォーム送信エラー: 入力内容に問題があった場合、どのフィールドの何が問題かを具体的に示し、修正方法を提示する。
• ネットワーク・サーバーエラー: 通信失敗時は「再試行」ボタンを提供し、ユーザーが自力で回復できるようにする。
• 404・権限エラー: 「ページが見つかりません」だけでなく、トップページや検索への導線を提供する。
• 決済・重要フローの失敗: 入力内容を保持したまま、失敗した理由と次のステップを明確に伝える。

トレードオフが起きる場面

• セキュリティとの兼ね合い: ログインエラーで「メールアドレスが存在しません」と伝えると、アカウント存在確認に悪用される。「メールアドレスまたはパスワードが違います」という曖昧な表現が必要な場合もある。
• 詳細なエラー情報の開示: 技術的なエラー詳細（スタックトレースなど）はデバッグに役立つが、一般ユーザーには混乱を招く。開発者向けと一般ユーザー向けを分けて設計する。

3. なぜ重要か（設計判断の核）

エラーメッセージは「問題の報告書」ではなく、「次のアクションへの道案内」である。

設計判断の基準

• 「このエラーメッセージを読んだユーザーは、次に何をすればいいか分かるか？」→ 分からなければ具体的なアクションを追加する。
• 「エラーが起きた後、ユーザーはどこに戻ればいいか？」→ 入力内容の保持・再試行ボタン・代替手段を設計する。

優先順位の考え方

• 1. 入力内容の保持（最優先）: エラー後に入力内容が消えることは最悪のUX。エラーが起きても入力済みデータは必ず保持する。
• 2. 具体的な原因と解決策: 「エラーが発生しました」ではなく「〇〇が正しくありません。△△してください」と伝える。
• 3. 次のアクションへの導線: 「再試行」「パスワードを忘れた場合」「サポートに問い合わせる」など、ユーザーが取れる行動を提示する。

例外条件

• セキュリティ上の理由で詳細を伝えられない場合（ログインエラーなど）は、曖昧な表現でも許容される。ただし代替手段（パスワードリセットなど）は必ず提供する。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

これがないと、ユーザーはエラーから回復できません。

エラー後に入力内容が保持されているか: フォーム送信エラー後、入力済みの内容がすべて消えていないか？ユーザーに再入力を強いることは最悪のUX。
エラーの場所が明確か: 複数フィールドのフォームで、どのフィールドにエラーがあるかが視覚的に（色・アイコン・スクロール）明示されているか？
次のアクションが提示されているか: エラーメッセージに「どうすれば解決するか」の具体的な手順または代替手段が含まれているか？

理想ライン（Better - できると強い/プロの品質）

「エラーが起きても迷わない」状態です。

エラーメッセージが人間の言葉で書かれているか: 「Error 500」「INVALID_INPUT」などの技術的コードではなく、「入力内容に問題があります。メールアドレスを確認してください」のような自然な言葉で書かれているか？
再試行が1クリックでできるか: ネットワークエラーなど、ユーザーに非がないエラーには「再試行」ボタンを提供し、最初からやり直さなくて済むようにしているか？
エラーの深刻度が視覚的に伝わるか: 致命的なエラー（赤）・警告（黄）・情報（青）を色とアイコンで区別し、ユーザーが優先度を判断できるか？

5. UI例

同じエラーでも、メッセージの設計でユーザーの回復率が大きく変わります。

改善プロセス

1. エラーメッセージの棚卸し: サービス内の全エラーメッセージをリストアップし、「次のアクションが分かるか」「入力内容が保持されるか」を一つずつ確認する。
2. エラーの3要素を確認: 各エラーメッセージに「何が起きたか」「なぜ起きたか」「どう直すか」の3要素が含まれているかチェックする。
3. 代替手段の設計: ユーザーが自力で解決できないエラー（サーバー障害など）には、サポートへの導線・ステータスページへのリンクを必ず追加する。

6. 関連リンク

• 関連リファレンス（理論）: 防衛的デザイン, 防衛的デザインとエラー回避
• 用語集（定義）: 防衛的デザイン, フェイルセーフ, アンドゥ・リドゥ
• 関連するUI原則（横）: 誤操作を防ぐ (Error Prevention), フィードバック (Feedback), ユーザーコントロール (User Control)
• 関連するUIコンポーネント: Toast（トースト通知）, Textarea（テキストエリア）, File Upload（ファイルアップロード）

7. まとめ

今日から直せる一手 担当しているサービスのログインエラーメッセージを確認してください。「エラーが発生しました」だけなら、「メールアドレスまたはパスワードが正しくありません」＋「パスワードを忘れた場合はこちら」に変えてください。それだけでユーザーの回復率は大きく上がります。

チームに共有するなら一言 「エラーは終点ではなく、分岐点だ。ユーザーを次のアクションに案内せよ。」