エラー処理は表示ではなく、失敗後の立て直し設計

1. エラー処理を「表示処理」と見ると設計を誤る

エラー処理を「失敗したときにメッセージを出すこと」だと捉えると、設計は浅くなります。

たとえば、保存に失敗したら通知を出す。通信に失敗したらアラートを出す。この発想自体は間違いではありません。ただ、それだけで終わると、重要な判断が抜けます。

• なぜ失敗したのか
• 誰がそれを解決できるのか
• 次に何を起こすべきなのか

ユーザーに「失敗しました」とだけ伝えても、ユーザーは次の行動を選べません。 自分が入力を直すべきなのか、待つべきなのか、ログインし直すべきなのかが分からないからです。

つまり、表示だけのエラー処理は、失敗の通知まではできます。一方で、失敗からの「回復」は設計できません。

ここを誤ると、UIは一見ちゃんとして見えます。しかし異常時に触ると、同じ文言・同じ再試行・誰が直すべきか分からない導線など、設計の粗さがそのまま出ます。

2. エラー処理とは何か

まず、この記事で扱うエラー処理の範囲をはっきりさせます。

ここで言うエラー処理とは、UIやアプリケーション設計の中で、失敗を検知したあとに原因を整理し、次に動く主体と行動を決めることです。 雑に言うと、失敗後の立て直し方を決める設計です。

正確には、次のような判断を含みます。

• ユーザーの入力ミスなのか
• 認証や権限の問題なのか
• ネットワークの一時的な問題なのか
• 外部サービスとの連携切れなのか
• サーバー側の不具合なのか

これらを全部まとめて「エラーです」と扱うと、原因の切り分け・次の主体・回復導線まで雑になります。原因が違えば、次の行動も変わるからです。

たとえば投稿文が未入力なら、入力欄へ戻して修正箇所を示すべきです。ログイン切れなら再ログインへ案内する。サーバー障害なら、ユーザーに何度も再投稿させるより、状態を保持して調査できる形で記録するほうが重要です。

つまり、エラー処理の本体は「失敗を出すこと」ではありません。失敗したあとに、どう回復させるかを決めることです。

3. エラーは3つの観点で分解すると扱いやすい

エラーは、ひとまとめに「何か失敗した」と見ないほうが扱いやすいです。 少なくとも、次の3つに分解すると設計判断が安定します。

• 原因は何か
• 誰が次に動くか
• 次に何をするべきか

たとえば、投稿ボタンを押して失敗した場合でも、中身は分かれます。

見た目はすべて「投稿失敗」です。でも、設計上は別物です。

ここを分けないと、全部に同じ文言を出し、全部に同じ再試行ボタンを置くことになります。 実装は楽ですが、実務上は回復設計としてかなり弱いです。なぜなら、ユーザーが直せる問題と、ユーザーには直せない問題が混ざるからです。この混在を放置すると、ユーザーに不要な操作を押しつけます。

4. 最初に決めるべきは「誰が次に動くか」

3つの観点の中でも、最初に決めるべきなのは「誰が次に動くか」です。

理由は単純で、ここが決まれば UI・再試行・ログ・導線の方針がひとつながりに決まります。

具体的には、次のように分けます。

• ユーザーが動く
• システムが動く
• 開発側が動く

投稿文の未入力なら、次に動くのはユーザー。 必要なのは「エラーです」という通知ではなく、どこを直せばよいかが分かる表示です。

外部サービスとの連携切れでは、次に動くのはユーザーです。 「投稿に失敗しました」だけでは足りません。どの連携が切れているか、どこから再連携できるかが分かる導線が必要です。

通信の一時不良では、まずシステム側で吸収できるかを見ます。 即座にユーザーへ失敗を返すより、短い内部再試行を行うほうが自然なことがあります。 ただし、内部再試行を選べるのは条件があります。同じ操作を再送しても重複や副作用が増えないこと、短時間で終わること、回数に上限があること。これらを満たすときだけです。

サーバー障害なら、最終的に動くのは開発側。 ユーザーに再投稿を連打させるより、入力内容を失わせず、調査できるログを残すほうが大事です。そのログも、投稿本文などユーザー入力を丸ごと保存するのではなく、必要最小限のエラー情報・request ID・時刻・状態などに絞るべきです。

ここを曖昧にすると、本来システム側で吸収すべき失敗をユーザーに押しつけます。 逆に、ユーザーが直すべき入力ミスを内部で何度も再試行することもあります。どちらも設計としてズレています。

エラー処理でまず決めるべきなのは、原因名のラベルではありません。 この失敗のあと、誰に次の行動を持たせるかです。

5. 原因ごとに、次の行動は変わる

エラー処理の難しさは、同じUI操作でも失敗理由が複数あることです。 そのため実装時には、原因ごとに表示・状態保持・再試行・記録の扱いを分ける必要があります。

たとえば「投稿できない」という失敗を考えます。

投稿文が未入力のときに見るべきなのは、入力欄へ戻せるか、修正箇所を近くに出せるか、投稿内容を消さずに保てるかです。 全体通知だけを出しても、ユーザーは何を直せばよいか判断しにくくなります。

ログイン切れでは、再ログインへ誘導する前に、投稿途中の内容を保持できるかを確認します。 ログイン後に入力が消えていたら、修正コストが高く、離脱や問い合わせにつながりやすいです。

外部サービスとの連携切れでは、再連携の導線をどこに出すかが問題になります。 設定画面に誘導するか、投稿フォームの近くに出すか。導線の設計次第で、再連携まで辿り着けるかどうかが変わります。

通信の一時不良では、ユーザーにすぐ操作させるとは限りません。 再試行しても重複投稿などの副作用が出ない設計が成り立っていて、短時間かつ回数制限つきの再試行で回復するなら、システム側で吸収するほうが自然です。ただし、長く待たせるなら待機中であることは伝えるべきです。

サーバー側の不具合では、ユーザーができることはほとんどありません。 「もう一度お試しください」だけで逃がすと、ユーザーは同じ操作を繰り返す。 重複投稿、状態のズレ、問い合わせ増加——これが連鎖しやすいです。 開発側が追えるように、request ID・発生時刻・レスポンス状態・失敗した処理名などを残し、ユーザー入力そのものは必要以上に記録しない設計が必要です。

実務上は、原因ごとに少なくとも次の判断を置くべきです。

• ユーザーが修正できるか
• システムが自動で回復できるか
• 開発側が調査すべきか
• 入力内容や操作状態を保持する必要があるか
• 再試行させてよいか
• 記録する情報は必要最小限に絞れているか

この判断があると、エラー文言も自然に決まります。逆に、この判断がないまま文言だけ整えると、見た目だけ丁寧な弱いUIになります。

6. エラー処理の質は、そのままUXの質になる

エラー処理は地味なわりに、UX（ユーザー体験）への影響はかなり大きいです。

原因を分け、誰が次に動くかを決め、再試行やログの扱いまで整理しておくと、失敗時の feedback が明確になり、次の操作の予測可能性が上がります。 失敗した瞬間に、次に何をすればよいかが見えるからです。

正常時は、多少設計が粗くても動いて見えます。 短時間で作った試作品や、勢いで組んだコードでも、成功パターンだけならそれっぽく見えることがあります。

一方で、異常時は作りの雑さがそのまま露出します。 ユーザーは「何が起きたのか分からない」「自分が直せるのか分からない」「待つべきか押し直すべきか分からない」という状態になります。これはかなり不安です。

正直に言うと、アプリを使っている側からすると、失敗したこと自体よりも、次にどうすればよいか分からないことのほうがつらいんですよね。

逆に、設計されたエラー処理は、失敗後も「何をすればよいか」が読み取れる状態を保ちます。

• 直すべき入力箇所が分かる
• 一時的な失敗は裏で吸収される
• 再ログインや再連携が必要なら導線がある
• 失敗しても入力内容や状態が消えない
• ユーザーが解決できない問題では、無駄な操作を要求しない

エラーが起きないことは理想です。でも現実には無理があります。 ネットワークは不安定になりますし、認証は切れます。外部サービス連携も失効します。

だから評価されるのは、失敗しないアプリだけではありません。 失敗したときに破綻しないアプリです。

エラー処理は補助機能ではなく、UXそのものです。

7. まとめ：「失敗しました」で終わらせないための判断基準

エラー処理を「失敗時のメッセージ表示」と捉えると、設計はそこで止まります。

実務で考えるべきなのは、次の3つです。

• 原因は何か
• 誰が次に動くか
• 次に何をするべきか

特に重要なのは、最初に「誰が次に動くか」を決めることです。 ここが決まれば、ユーザーに修正させるのか、システムで吸収するのか、開発側で調査するのかが見えてきます。

最後に、判断基準を置いておきます。

• ユーザーが直せる失敗なら、修正箇所と次の操作を示す
• システムが回復できる失敗なら、必要以上にユーザーへ投げない
• 開発側が調査すべき失敗なら、ユーザーに無駄な再操作をさせない
• どの失敗でも、入力内容や作業状態をできるだけ失わせない
• 文言を整える前に、失敗後の行動を決める
• 失敗後に、ユーザー・システム・開発側の誰が動ける状態になっているかを見る

失敗を知らせるだけなら、実装は簡単です。ただ、それだけでは失敗後に誰も動けないので、機能として弱いです。

エラー文言がきれいでも、失敗後に誰も動けないなら設計としては足りません。 失敗したあとにどう立て直すか、誰が次の行動を取れる状態になっているかまで決めて、はじめて実用レベルのエラー処理になります。 そしてその設計の質は、そのまま異常時のUXの質になります。