この記事はクラウドワークスグループ Advent Calendar 2024 シリーズ1の19日目の記事です。

はじめに

エラーメッセージの内容を考える際、個人的に既存の例を参考にすることが多いですが、もしその既存のメッセージが「悪いエラーメッセージ」であった場合、それを無意識に流用してしまうリスクがあります。

常に疑いを持ち、エラーメッセージの設計を見直すことが重要です。そのためには、改めて 「エラーメッセージとはこうあるべき」という基本的な概念を定期的に見直す必要がある と考えました。特に、普段はわかっているつもりでも、見返してみることで、よりユーザーに寄り添ったメッセージを意識することで様々なメリットを得ることが可能です。

「当たり前だけど、見返してみたらもっとよくできるのでは」と思う場面で参考となる記事があればと思い、この内容を書くに至りました。

エラーメッセージの基本

以下はエラーメッセージの重要な観点となります。

問題の原因を明示しているか
解決策を提供しているか
安心感を与えられているか

悪いエラーメッセージの例

エラーメッセージの内容が不十分・不適切だと、ユーザーのフラストレーションが増す原因となってしまいます。

曖昧な表現
- 例：エラーが発生しました
- 問題点: 原因も解決策も不明で、ユーザーのフラストレーションを助長する
専門用語の多用
- 例：StackOverflowException
- 問題点: 一般ユーザーには内容が理解できない
無責任な態度
- 例：予期しないエラーが発生しました。もう一度試してください。
- 問題点: 問題解決の責任をユーザーに丸投げしている印象を与えます。

良いエラーメッセージの条件

以下の条件を意識することが重要と考えます。

具体性：何が問題であるのかを具体的に伝える。※
- 例: 10文字以内で入力してください
親切である：ユーザーに対して配慮のある言葉を選ぶ。
- 例: 処理中に問題が発生しました。お手数ですが、もう一度お試しください。それでも解決しない場合はサポートまでお問い合わせください。
解決策の提示：解決方法を明確に案内し、必要に応じてリンクを設置する。
- 例: ネットワーク接続が切れています。Wi-Fiまたはモバイルデータ通信を確認してください。

よく見るメッセージですが、改めて見るとこんなに簡潔的な内容でも、上記条件をすべて満たしていることがわかります。

※例外　[セキュリティに配慮]

場合によっては、攻撃者にヒントを与えてしまい、攻撃を容易にしてしまうため、具体的な内容を避けること=良いエラーメッセージとなる場合もあります。
例えば、以下のようなケースです：

NG：パスワードが違います、 ユーザーIDが違います
OK：メールアドレスまたはパスワードが正しくありません

参考：体系的に学ぶ安全なWebアプリケーションの作り方第2版脆弱性が生まれる原理と対策の実践

結論

エラーメッセージとは、ユーザー体験の向上やサービスの信頼性を高める上で欠かせない要素 です。
適切なエラーメッセージは、以下のようなポジティブな影響をもたらします。

ユーザー満足度の向上
サポート工数の削減
システムの信頼性向上

一方で、内容の具体性については、セキュリティリスクを慎重に考慮し、適切なバランスを取ることが求められます。

今後も、日常的に他のサービスのエラーメッセージを観察し、良い例や改善のヒントを学びながら、自身の設計に反映していきたいと考えています。ユーザー目線を忘れず、使いやすく信頼されるサービスを提供できるよう、継続的に改善を重ねていきます。

おまけ

ChatGPT様に大喜利を仕掛けてみました。

「こんなエラーメッセージは嫌だ！」

「おっと、またやっちゃったね！君、ほんとドジだなぁ」
「エラー発生！でも君、もう気にしないんだろ？勝手にやって！」
「システムが混乱してます。私も君の状態が理解できません」
「プログラムが暴走中。あなたも一緒に逃げて！」
「エラー！あれ、もう一度試す？それとも諦める？」
「データが壊れてます。でも大丈夫、だって人生も壊れてるでしょ？」

「こんなエラーメッセージがあったら面白いのになあ〜」

「エラー発生！でも、君がどうしても直したいなら、ちょっとだけ魔法をかけてあげようか？」
「うーん、うまくいかなかったか。でも大丈夫、君にはまだ未来がある！」
「システムが停止しました。でも、君はまだ働き続けてるから、がんばれ！」
「なんと、エラーの原因は未解決。まるで人生みたいだね！」
「エラー発生！でも心配しないで、私たちは一緒にいられるから」
「接続エラー！まるで君の友達のように、いつもこんな時だけ現れるんだ」