AI機能のエラー時、ユーザーに何を見せる？｜表示文言の設計

社内向けに出したAIの要約機能。ある朝、問い合わせ窓口から転送されてきたメッセージには、こう書いてありました。 「ボタンを押したら『エラーが発生しました』と出て、30分かけて貼り付けた文章が消えました。もう一回やればいいんですか？」

裏側では、タイムアウトもリトライもちゃんと入れていた。なのに、利用者から見えていたのは、たった一行の素っ気ない文だけだった——そんな経験、ありませんか。

これは、あなたの設計が甘かったわけではありません。AI機能を作るとき、エラー処理はどうしても「システムが止まらないこと」が先に立ち、画面に何を見せるかは最後に残りがちです。そして、AIの失敗は普通のシステムより種類が多く、「どう伝えればいいか」の定石もまだ少ない。迷って当然の場所なんです。

結論：AI機能のエラー表示は、どの失敗でも①何が起きたか（責めない言葉で）→②入力は無事か→③次に何をすればいいかの3点を必ず伝えます。そのうえで、失敗を「一時的な混雑」「入力側で直せること」「機能そのものが止まっている」「答えは出たが自信がない」の4種類に分け、種類ごとに文言と次の一手（再試行ボタン・直し方の案内・代わりの手段・確認のお願い）を変えます。まずは入力を消さないことと、「エラーが発生しました」だけの表示をなくすことの2つから始めれば十分です。

エラー表示は、利用者がAI機能に「がっかりする瞬間」に出会う画面です。ここが丁寧だと、失敗しても「まあ、また使ってみよう」と思ってもらえます。

なぜAI機能のエラー表示は「エラーが発生しました」になりがちなのか

普通の業務システムなら、失敗の種類はある程度決まっています。入力チェックに引っかかった、権限がない、サーバーが落ちている。画面の文言も、だいたい定番があります。

AI機能は、ここにAI特有の失敗が上乗せされます。

• 応答が遅すぎて打ち切った（タイムアウト）
• 提供元のレート制限や一時エラーで弾かれた
• 入力が長すぎて一度に扱えなかった
• 提供元の安全上の判断で回答されなかった（内容によって断られる）
• 答えは返ったが、形式が崩れていて使えなかった
• 答えは出たが、中身に自信が持てない（根拠が見つからない等）

裏側ではそれぞれ別の失敗なのに、画面ではまとめて「エラーが発生しました」になる。すると利用者は、もう一度押せばいいのか、文章を直せばいいのか、諦めて手でやればいいのかが分かりません。分からないから、何度も押す（コストが増える）か、問い合わせる（あなたの仕事が増える）か、二度と使わなくなるか、のどれかになります。

裏側の失敗の受け止め方はAI出力が不安定なときのフォールバック設計で整理しました。この記事はその続きで、受け止めた失敗を、利用者にどう伝えるかの話です。

どの失敗でも伝える3つのこと

失敗の種類を分ける前に、どのエラー表示にも共通する土台があります。この3つがそろっていれば、文言が多少ぎこちなくても、利用者は迷いません。

①何が起きたか——責めない言葉で、短く

「何が起きたか」は、利用者が理解できる言葉で、一文で伝えます。

• 避けたい：「Error 429: Too Many Requests」「不正な入力です」
• 伝わる：「いま利用が集中していて、要約を作れませんでした」

ポイントは、利用者のせいにしないことです。「不正な入力」と言われると、人は自分が悪いことをしたように感じます。入力が原因のときでも、「この長さだと、一度に要約できませんでした」のように、事実を淡々と伝えれば十分です。

②入力は無事か——いちばん安心させる一文

冒頭の問い合わせで、利用者がいちばん困っていたのは「エラーが出たこと」ではなく、30分かけた文章が消えたことでした。

AI機能は、長い文章や手間のかかる入力を受け取ることが多い機能です。だから失敗したときは、入力欄の中身をそのまま残す。そして画面でも「入力した内容はそのまま残っています」と一言添える。これだけで、利用者の気持ちはずいぶん落ち着きます。

③次に何をすればいいか——ボタンか、具体的な一手

最後に、次の行動を1つ示します。「もう一度試す」ボタン、「この部分を短くしてみてください」という案内、「手作業の画面はこちら」というリンク。選択肢は多くても2つまでに絞ると、迷わず動けます。

失敗を4種類に分けて、文言と「次の一手」を変える

3つの土台の上に、失敗の種類ごとの中身を載せます。裏側の細かいエラーコードを全部画面に対応させる必要はありません。利用者がとる行動が変わる単位で、4つに分ければ足ります。

それぞれ、少しだけ補足します。

一時的な混雑：再試行ボタンは「連打できない形」で

一時的な失敗は、少し待てば通ることが多いので、再試行ボタンを出すのが親切です。ただし、ボタンを押すたびに即座にAIを呼ぶと、混雑をさらに悪化させ、料金も増えます。押したらしばらく押せなくする、押した回数に上限を設けるなど、裏側のリトライ設計とそろえておきます。

入力側で直せること：「ダメ」ではなく「こうすれば通る」

入力が原因のときは、どう直せば通るかまで書くと、問い合わせがぐっと減ります。「文字数が多すぎます」で止めず、「2〜3回に分けると作れます」まで一歩踏み込む。上限の目安が分かっているなら、入力中に文字数を表示しておくと、そもそも失敗が起きにくくなります。

提供元の安全上の判断で回答されなかった場合も、この種類に入れておくと扱いやすいです。断られた理由は利用者にもシステムにも正確には分からないことが多いので、理由を推測で書かず、「この内容にはお答えできませんでした。表現を変えるか、担当者にご相談ください」のように、次の一手だけを示します。

機能そのものが止まっている：「業務は止まらない」ことを伝える

AIが使えないときに一番知りたいのは、自分の仕事が止まるかどうかです。AI機能の外側に手作業の経路があるなら、そこへの導線を出します。復旧の見込みが分からないときは、無理に時刻を書かず、「復旧したらこの画面でお知らせします」など、分かる範囲のことだけを書きます。

答えは出たが自信がない：エラーにせず「確認のお願い」として出す

4つ目は、厳密にはエラーではありません。でも、AI機能ならではの大事な場面です。答えを黙って出すと、利用者はそれを正しいものとして使ってしまいます。「参考程度です」「ここは確認してください」と、自信のなさを正直に添えるほうが、長い目で見て信頼されます。もっともらしい誤りの見分け方はAIのハルシネーションの見抜き方にまとめています。

画面に出さないもの

エラー表示を丁寧にしようとして、つい出しすぎてしまうことがあります。次のものは、利用者向けの画面には出さず、ログの側に残します。

• スタックトレースや生のエラーメッセージ（利用者には読めず、不安だけが増える）
• 使っているモデル名・プロンプトの中身・内部のURLや設定（攻撃の手がかりになりうる）
• AIが返した壊れた出力そのもの（意味不明な文字列を見せても、誰も得をしない）

その代わり、問い合わせ用の番号（リクエストIDなど）を小さく表示しておくと便利です。利用者が問い合わせるとき、その番号を伝えてもらえば、あなたはログからすぐに該当の失敗を探せます。「何時ごろ、どの画面で……」と聞き取りに時間を使わずに済みます。

明日からやること（小さく始める3つ）

全部の画面を一度に直す必要はありません。効果の大きい順に、まずこの3つから。

1. 失敗しても入力欄を消さない：いちばん利用者を傷つけるのは「入力が消えること」です。ここを直すだけで、問い合わせの空気が変わります。
2. 「エラーが発生しました」を、3点がそろった文に書き換える：まずはいちばん出やすい失敗（多くの場合は一時的な混雑）の1つだけでいい。「何が起きた・入力は無事・次の一手」をそろえます。
3. 画面に問い合わせ用の番号を出し、ログと結びつける：調べるあなた自身が、次から楽になります。

AI機能のエラー表示チェックリスト

画面の設計やレビューのときに、そのまま使えます。【必須】の3つだけ埋まっていれば、最低限は回ります。 残りは余裕があるときに。

• 【必須】失敗しても、利用者の入力内容が消えずに残るか
• 【必須】エラー表示に「何が起きたか」が、利用者に分かる言葉で書かれているか
• 【必須】「次に何をすればいいか」が1つ以上示されているか（ボタン・案内・代わりの手段）
• （余裕があれば）失敗を「混雑／入力側／停止／自信なし」の4種類に分けて、文言を変えているか
• （余裕があれば）再試行ボタンが連打できない形になっているか
• （余裕があれば）入力が原因のとき、「どう直せば通るか」まで書いているか
• （余裕があれば）AIが使えないとき、手作業など代わりの経路への導線があるか
• （余裕があれば）自信のない回答に「確認のお願い」を添えているか
• （余裕があれば）スタックトレース・モデル名・プロンプトなどの内部情報を画面に出していないか
• （余裕があれば）問い合わせ用の番号を表示し、ログと結びつけているか
• （余裕があれば）利用者を責める言葉（「不正な」「誤った操作」など）を使っていないか

最後に

エラー表示の文言を考える仕事は、地味です。仕様書の片隅に一行で書かれ、レビューでもあまり見られません。 でも、利用者がAI機能にがっかりした瞬間に、そっと隣に立ってくれるのは、その一行です。

AIは、これからもときどき失敗します。それは避けられません。 でも、失敗したときに「入力は残っています。少し待ってもう一度どうぞ」と言える画面なら、利用者はまた戻ってきてくれます。今日ひとつ、入力欄を消さないようにする。そこから始めてみましょう。

よければ、こちらも

• AI出力が不安定なときのフォールバック設計｜リトライの型
• AI機能のレスポンスが遅い｜ストリーミングで体感速度を上げる
• 人の確認を挟むAIワークフロー｜HITLの組み方
• 業務システムにAI機能を載せる前に｜要件と期待値の整理

関連用語

• フォールバック
• レート制限
• ハルシネーション
• API
• LLM