エラーメッセージ

エラーメッセージの例（あくまで例示のスクリーンショット）。フロッピーディスクにアクセスしようとし失敗したときに表示される。Ubuntu Linux.

エラーメッセージ（英: Error message）は、予期しない状態が発生したとき表示されるメッセージであり、コンピュータなどの機器で見られる。

概要

エラーメッセージは、アプリケーションソフトウェアやオペレーティングシステムなどのコンピュータプログラムが、エラーの発生などにより、所定の処理を続行できない旨をユーザーに通知する際に表示するものであるが、より広義には自動化された装置が規定の動作を行なえない場合に点灯させるインジケーターや警告ブザーなども、その意味においてはエラーメッセージである。なお本項では特に断りが無い場合は、主にコンピュータの動作においてユーザーに異常がある旨を通知するメッセージについて説明する。

こういったメッセージは、ウィンドウシステムではダイアログボックスを使って表示されることが多い。エラーメッセージが表示されるのは、ユーザーに何らかの対処を期待しているときであり、処理が失敗したことを通知したり、ユーザーの操作が不適切であった場合、またはデータを保持するハードディスクドライブなど記憶装置の空き容量がないことを警告するなどといった重要な事象の通知に使われる。正しいエラーメッセージの設計は、マンマシンインタフェースにおけるユーザビリティその他にとって非常に重要である。

エラーメッセージの言語学

かつて、メモリは非常に貴重であり、エラーメッセージに貴重なメモリ容量を割くことは無駄と考えられていた。そのため、文法的には正しくないエラーメッセージも平気で使われていた。例えば "File not found" は "The file could not be found"（そのファイルは見つからなかった）という意味だが、後者ではメモリを2倍も使用する。

しかし、ムーアの法則に従ってメモリ容量は指数関数的に大きくなっており、現在ではそのような考慮は過去のものとなりつつあるが、過去には前述の理由により、「File not found」が多用されていたが故に、「File not found」が有名になり、たとえ文法上は誤りであったとしても利用者に伝わること、または、互換性を重視するために、コードを流用しているためや、記憶容量の少ないコンピューターの利用も想定されるため等の理由により、現在でも「File not found」が引き続き使用される場合もある。

エラーメッセージの設計

エラーメッセージは、問題発生時にコンピュータとユーザ間の対話を提供するものである。従って、設計にあたってはユーザが状況を明確に素早く理解できるようにして、適切な対処がなされるようにしなければならない。

ユーザビリティの観点

エラーメッセージは、次のような情報を含んでいなければならない。

メッセージID（エラー番号）

多くのアプリケーションでは、エラーの番号が重要な情報となる。例えば、製品サポートに連絡する場合、エラー番号が判っていれば診断と対処方法が容易に判明することが多い。また、エラーメッセージ本体がユーザの理解できない言語であったとしても、番号が判っていれば対処の手掛かりとなる。

タイムスタンプ

エラー発生の日付と時刻を表示すれば、データログを解析する際の手掛かりとなる。

メッセージの分類と重要度

エラーを、自動的に対処可能なエラー、人手で対処可能なエラー、対処不能なエラー、その他に分類する。ユーザに問題の重要度を知らせ、取りうる対処法を知らせる。

詳細（ユーザとプロセス）

エラーのきっかけとなったユーザーを示す情報（ユーザ識別子など）を知らせる。そのユーザが複数のプロセスやタスクを実行していた場合、どのプロセスかを示す情報も必要である（コマンド実行パスなど）。これらも製品サポートが問題を調査する際に重要となる。

短いメッセージと詳細ボタン

表示されるメッセージは明確で簡潔であるべきで、初心者にも理解できる内容でなければならない。その中には、参照番号、エラーの種類、重要度、対処などの基本的情報が含まれている必要がある。それ以上の詳細情報は、詳細ボタンを押下した時点で表示されるようにしておく。

プログラムの状態や設定

エラーを検出した時点（サブルーチン）でエラーメッセージを決めてしまうのではなく、そこに至った過程を考慮してユーザにわかりやすいメッセージにする。例えばフォームへのユーザ入力に問題がある場合、どのフィールドがどのようにまずいのかを示す。また、例えばデフォルトとしているプリンタ設定が間違っている場合、単に "プリンタの準備ができていません" とするのではなく、"プリンタ（エプソン123A）の準備ができていません" のように現在の設定がどうなっているかを示すのがよい。

フォーマット

エラーメッセージのフォーマットは常に一定ではなく、様々な事象に依存して決定される。主な要因は以下の3つである。

技術的制限

エラーメッセージを表示しようとしている機器の技術的制約が第一に考慮すべき点である。表示したいエラーメッセージがその機器でどのような大きさ・形状・スタイルで表示されるかを事前に確認しておく必要がある。

表示される情報の量

エラーメッセージのフォーマットは必要とされる情報の量によって決定される。長いメッセージは目立つが、短いメッセージは他の情報に埋もれて目立たない可能性がある。従って、ウェブサイトでのエラーメッセージが短い場合、別のウィンドウをポップアップさせるとか、別のエラーメッセージだけのページを表示するといったことが考えられる。

ユーザ入力の要否

エラーメッセージと共に、ユーザに何らかの入力（その後の動作の選択肢など）を要求するかどうかによってもフォーマットが変わってくる。

見た目

エラーメッセージの見た目は、ユーザがそれを理解して応答するかどうかに影響する重要な要因である。これに関して、次のような3つの原則がある。

ユーザの注意をひきつける

エラーメッセージの色や大きさ、表示位置などによってユーザが注目する度合いが変わってくる。一般に、色は赤、ボールド体のフォントを使い、全ウィンドウの最前面に表示されるようにすれば、間違いなくユーザがエラーに気づく。感嘆符などを使ったアイコン的なものを入れると、重要性がより理解されやすい。

何が問題なのか説明する

効率的にユーザと対話するには、アプリケーションはユーザと同じ言語を使うべきである。そして、初心者でもわかるように専門用語を使わずに問題を説明する。これは、エラー番号を表示するなと言っているのではなく、エラー番号も適切な文脈の中で示すべきだという意味である（例えば、「ヘルプデスクに連絡してください。なお、エラーコードは 3555 です。」といったような形）。

発生箇所を示し、対策を示唆する

例えば、「フィールド 123A に不正な文字列が入力されました」よりも「郵便番号に不正な文字が含まれています。半角数字以外は入力できません。」の方が明らかにユーザに発生箇所がわかりやすい。メッセージそのもの以外で問題箇所を示す方法もある（問題箇所を強調表示したり、色を変えたりといったこと）。問題箇所を示すことができたら、対処法もユーザの言語で示す。このとき、例を示すのもよいだろう。

ヒューリスティックス

以下に列挙したのは、効果的なエラーメッセージの設計の一般的ガイドラインである。他にもいろいろなガイドラインがあり、これが絶対的なものというわけではない。

• ユーザが問題を把握するのを助けるような情報を提供せよ。
• 正確に。（例えば、"ファイルが見つかりません" よりも "ファイルの拡張子がありません" がよい）
• 問題を判りやすく。（例えば、“ファイルエラー” よりも “ディスクがいっぱいです” がよい）
• 不快感を与えないように。（例えば、“不正な入力” よりも “認識できないコマンドです” がよい）
• 文として完全な形に。（例えば、“キーボードマクロ長すぎ” よりも “キーボードマクロが長すぎます” がよい）
• システムを擬人化しない。

関連項目

• インタラクションデザイン
• マンマシンインタフェース
• ユーザインタフェース設計
• ユーザビリティ
• gettext - ソフトウェアが出力する、エラーメッセージを含むメッセージを国際化するためのライブラリ。