アプリが壊れたとき、何と伝えるべきか：人が本当に理解できるエラーメッセージの書き方

どんなアプリも、時には壊れる。インターネットが切れる、サーバーが一瞬つまずく、誰かが電話番号の欄に文字を混ぜて入力する。こうしたことを完全に防ぐことはできない。だが、あなたが唯一コントロールできるもの——それがエラーメッセージだ。何かがうまくいかなかったときにアプリが表示するテキストのことで、この一文があるかないかで、ユーザーが肩をすくめてもう一度試すか、静かに「このアプリは壊れている」と判断して二度と戻ってこないかが分かれることが多い。

AIで作られたアプリの多くは、まさにこの瞬間でつまずく。ビルダーが不注意だったからではなく、エラーメッセージというものが、実際に目の前で誰かに何かが起きるまで、誰も気にかけない部分だからだ。デフォルトのままだと、アプリはたいてい最悪な二つのうちどちらかを表示する。何も表示しないか、恐ろしげな専門用語の塊を見せるか。この両方を直していこう。

アプリが黙って失敗したり、怖いエラーを表示したりするのはなぜか?

アプリの壊れ方には二通りある。何かが失敗したときに何も言わないか、普通の人には読めない技術的なエラーを表示するかだ。どちらもユーザーを推測状態のまま放置し、その推測こそが人を諦めさせる原因になる。

沈黙の失敗。 ここではマヤと呼ぶことにするフリーランサーが、自身の写真ビジネス用に予約フォームを作った。あるクライアントが「予約を確定する」をタップすると、ボタンが一瞬点滅して……何も起きなかった。確認画面もなく、エラーもなく、読み込み中の表示すらない。予約はできたのか? クライアントは確信が持てず、もう一度予約してしまった。結果、マヤは同じ枠に二件の予約と、混乱した顧客を抱えることになった。アプリがクラッシュしたわけではない。保存処理が失敗しただけなのに、アプリは何も言わなかったので、目の前にいた人には現実がどうなっているのか知る術がなかったのだ。

怖い専門用語エラー。 もう一つの失敗パターンは、より声高で、ある意味さらにたちが悪い。地域の募金活動をボランティアで運営していたある人が、スプレッドシートをアップロードしようとして、赤い枠に「Error 500: Internal Server Error」と表示された画面に行き着いた。彼女はそれを「自分が何かを壊してしまった」と受け取った。もう一度試すことも、助けを求めてメールを送ることもせず、ただタブを閉じた——そのメッセージが、問題は自分のせいであり、これ以上触るのは危険かもしれないと感じさせるものだったからだ。

どちらのユーザーも、ごくありふれた、回復可能な問題に遭遇しただけだった。それでも二人とも離脱してしまったのは、アプリのエラーメッセージが何も語らないか、恐ろしいことを語るかのどちらかだったからだ。

良いエラーメッセージとは何か?

良いエラーメッセージは、平易な言葉で四つの小さなことを伝える。何が起きたか、それが誰の問題か、次に何をすべきか、そしてユーザーの作業内容を失わせないこと。

何が起きたかを伝える ——「予約を保存できませんでした」であり、沈黙でも 500 でもない。
誰の問題かを伝える —— たいていは正直に言えば「こちら側の問題です」であり、そう伝えることが相手を落ち着かせる。
次に何をすべきかを伝える ——「少し時間をおいてもう一度お試しください」や「インターネット接続を確認して再度お試しください」。
相手の作業内容を失わせない —— 入力していた内容は、メッセージが表示された時点でもフォームにそのまま残っている。

これだけだ。長々とした謝罪文も、見出しに据えられたエラーコードも、責任のなすりつけもいらない。先ほどの三つの失敗例を書き直してみよう。

❌ (何も起きない) → ✅「ただいま保存できませんでした。入力内容はそのまま残っています——もう一度『確定する』をタップしてお試しください」
❌ Error 500: Internal Server Error → ✅「ファイルのアップロード中に、当方の側で問題が発生しました。お客様のせいではありません。少し時間をおいて、もう一度お試しください」
❌ Invalid input → ✅「その電話番号は正しくないようです——555-123-4567のように10桁で入力してください」

最後の例が、具体的な項目を指し示し、正しい形の見本まで示していることに注目してほしい。「Invalid input」では、相手はどこが悪いのか探し回るしかない。「その電話番号は10桁である必要があります」なら、何を直せばいいかがはっきり分かる。

どのアプリのエラーから直すべきか?

起こりうるすべての失敗に専用のメッセージを用意する必要はない。典型的なアプリでうまくいかないことのほとんどは、次の三つでカバーできる。保存や送信の失敗、アプリが処理できない入力、そしてこちら側で起きた不具合だ。

保存や送信の失敗。 信頼を最も損なうパターンだ。なぜなら、ユーザーは正しい手順をすべて踏んだのに、それがうまくいったのかどうか確信が持てないからだ。成功は必ず確認し、失敗は必ず説明する。相手を推測のまま放置してはいけないし、入力した内容を消してもいけない。

「入力された内容を処理できません」(バリデーション)。 これは本当の意味でのエラーではなく、単なる行き違いだ。ユーザーがその項目から離れた瞬間に検知し、該当の項目を明確に指し示し、正しい形式の例を示すこと。送信ボタンを押させてから、赤字だらけの壁を見せつけるようなことはしないように。

「こちら側で何かが壊れました」。 サーバーやネットワークの本当の問題だ。それが自分たちの側の問題であることを伝え、落ち着いたトーンを保ち、再試行の手段を用意する。ユーザーにはあなたのサーバーを直すことはできないのだから、直さなければならないような気持ちにさせてはいけない。

さりげなく効く三つの習慣

失敗への対応がうまいアプリと、そうでないアプリを分けるポイントがいくつかある。

生のエラーコードだけをメッセージ全体として表示しない。 コードはサポート用に小さな文字で下に添えておいてもいい。だが、人間が最初に読む見出しは、一文であるべきで、ERR_CONN_RESET であってはならない。
ユーザーを責めない。「入力内容に誤りがあります」は刺さるが、「その日付は過去のようです——来月のことでしょうか?」は助けになる。情報としては同じでも、受け取る印象はまったく違う。
入力内容は必ず保持する。 アプリが再読み込みされたり保存に失敗したりしたときにフォームが空になってしまうと、ちょっとしたつまずきが、十分間もかけて入力し直す羽目になる大事件に変わってしまう。人は保存の失敗を許してくれる。だが、同じ作業を二度させられることは許してくれない。

AIビルダーに、より良いエラーメッセージを書かせるには?

これらの大部分は、一度の指示でまとめて実現できる。下のようなプロンプトを貼り付ければ、あなたのAIビルダーが上記の平易な言葉のルールをアプリ全体に適用してくれる。

「保存やアップロードが失敗したとき、黙って失敗させず、技術的なエラーコードも表示しないでください。何が起きたかを伝え、もう一度試して大丈夫だと伝え、ユーザーがすでに入力した内容を保持する、短くて親しみやすい平易な言葉のメッセージを表示してください。フォームの項目については、ユーザーがその項目から離れた時点で検証を行い、正しい形式の例とともに具体的なメッセージを表示してください」

その後、次の三つのケースで何が起きるかを説明させてみよう。インターネットが切れている場合、必須項目が空欄の場合、サーバーが遅い場合だ。どれか一つでも「何も表示されない」「生のエラーが表示される」という答えなら、それが次に直すべき箇所だ。

アプリのエラーメッセージをどうテストするか?

Wi-Fiを切って、アプリを開き、メインの操作をやってみる——テストはそれだけで、二分もかからない。

予約を入れる、メモを保存する、ファイルをアップロードする。何が表示されるかを見る。普通の人が理解できる内容を伝えていただろうか? 入力した内容は失われなかっただろうか? 次にWi-Fiを戻し、今度はわざと項目にでたらめな値を入力してみる。同じ問いをもう一度。

ほとんどのアプリは、最初はこのテストに落ちる。それでいい——直すべき場所がまさにそこだと分かるからだ。すべてのエラーメッセージを完璧にする必要はない。あなたのアプリで最も頻繁に起きている不具合を一つ見つけ、まずはそのメッセージを、思いやりがあり、わかりやすく、正直なものにすることから始めよう。次に実際の誰かがそこに行き着いたとき、その人は立ち去るのではなく、もう一度試してくれるはずだ——そして、もう一度試してもらえること、それこそがすべてなのだから。