アプリケーションにおいて「エラー」は避けられません。予期せぬ中断はユーザーにストレスを与えますが、優れたエラーダイアログはそのネガティブな体験を「信頼」に変える力を持っています。
その鍵となるのが、エラーに対する「説明責任（Accountability）」です。
今回は、単なるシステム的な報告で終わらせず、ユーザーを解決へと導くための「伝わるエラーメッセージ」について解説します。
なぜ、そのメッセージは伝わらないのか
エンジニアがエラーハンドリングを実装する際、意識は「原因の特定（デバッグ）」に向きがちです。しかし、その思考がそのままUIに表現されると、以下のような「悪いダイアログ」が生まれます。
エラーが発生しました
予期せぬエラーが発生しました。
終了コード: 0x80040201
[ OK ]
これではユーザーは何が起きたのか理解できず、不安だけが募ります。ユーザーが必要としているのは技術的なログではなく、「次にどうすればいいか」という案内です。
これを解決するためのフレームワークが、UXライティングにおける「3つの説明責任」です。
エラーメッセージの黄金構造：3つの「W」
効果的なエラーメッセージは、以下の3要素を含んでいる必要があります。
- What happened （何が起きたのか？）
- Why it happened （なぜ起きたのか？）
- What the user can do （ユーザーは何ができるのか？）
これらを組み合わせることで、ダイアログは「意味不明な警告」から「役に立つ案内板」へと進化します。
1. What happened：何が起きたのか
まずは事実を伝えます。ポイントは「ユーザーの言葉」に翻訳することです。
エンジニアにとっての Timeout は、ユーザーにとっては「読み込みが遅れている」状態です。「何が失敗したのか」を、ユーザーのアクション（保存、ログインなど）に結びつけて表現しましょう。
- × 技術的:
データベース接続エラーが発生しました - 〇 ユーザー視点:
データを保存できませんでした
2. Why it happened：なぜ起きたのか
次に理由を説明しますが、技術的な詳細ではなく「文脈」を伝えます。
- × 技術的:
NullPointerExceptionにより処理中断 - 〇 文脈的:
システムに一時的な問題が発生しています
理由がユーザー側にある場合（通信環境、入力ミスなど）は明確に伝え、そうでない場合は素直にシステム側の問題であることを認めます。
3. What the user can do：ユーザーは何ができるのか
最も重要なパートです。 「エラーです」で終わらせず、必ず次の一手を提示します。
- 再試行: 「もう一度お試しください」
- 環境変更: 「通信環境の良い場所でお試しください」
- 代替手段: 「時間を置いてアクセスしてください」
ケーススタディ：劇的ビフォーアフター
「3つのW」を使って、無機質なダイアログを改善してみましょう。
ケース1：ファイルアップロード失敗
【Bad UI】
アップロード失敗
エラーが発生しました。(Code: E-503)
[ 閉じる ]
これではユーザーは「再試行すべきか？ ファイルが壊れているのか？」と疑心暗鬼になります。
【Good UI】
ファイルをアップロードできませんでした
ファイルサイズが上限（10MB）を超えているため、処理を完了できません。
サイズを小さくして、もう一度アップロードしてください。
[ OK ]
- What: アップロード不可を明言。
- Why: サイズ超過が原因と明示。
- Action: 「サイズを小さくして再試行」という解決策を提示。
ケース2：インターネット未接続
【Bad UI】
ネットワークエラー
通信エラーが発生しました。
[ 再試行 ]
「通信エラー」だけでは、サーバーダウンか圏外か区別がつきません。
【Good UI】
インターネットに接続されていません
Wi-Fiの設定やモバイル通信状況を確認してから、再度お試しください。
[ 再試行 ]
- Action: 具体的にWi-Fiなどの確認を促しています。
避けるべき「アンチパターン」
良かれと思ってやってしまう、逆効果なパターンもあります。
1. 謝りすぎる
「申し訳ありません」の多用はノイズになります。入力ミス程度の軽微なエラーで毎回謝られると、ユーザーは煩わしさを感じます。
謝罪は「データの消失」や「長時間のサービス停止」など、深刻な事態に限定しましょう。普段は事実と対策を淡々と伝える方が親切です。
2. 「OK」ボタンの罠
エラー時にボタンが「OK」だと違和感があります。状況は「OK（大丈夫）」ではないからです。
ボタンのラベルは、その動作を表しましょう。
- メッセージを閉じるだけなら → [ 閉じる ]
- もう一度試すなら → [ 再試行する ]
3. 過度なユーモア
404ページの「迷子になっちゃいましたね！」のようなユーモアは、エラーを和ませる演出として有効な場合もありますが、決済失敗の場面などでは不適切です。緊急性の高い場面では「明確さ > ユーモア」を徹底し、信頼を損なわないようにしましょう。
実装のヒント
エラーコードは脇役
エラーコード（ERR-001等）は、問い合わせに役立つ場合もあります。表示する際は、主役のメッセージの後に添えるようにしましょう。
汎用メッセージからの脱却
そもそも、APIがエラー分類が適切にできていないと、フロントエンドは気の利いた表示ができません。エラー種別を識別できるAPI設計を行い、それに応じたメッセージが表示できるように構成しましょう。
まとめ
エラーが起きた瞬間、ユーザーの信頼は一時的にマイナスになります。しかし、そこで「何が起きて、どうすればリカバリーできるか」を誠実かつ的確に案内できれば、信頼を取り戻すことができます。
「ユーザーを迷子にさせない」
これを念頭において書かれたエラーメッセージが、システムに血を通わせ、ユーザーとの対話を維持します。
