Webエラーハンドリング設計の考え方：UXでストレスを減らし信頼を守る実務ガイド

Webのエラーは「できれば起きてほしくない」一方で、プロダクトが成長するほど確実に増えます。ネットワークは揺れ、端末性能はまちまちで、ブラウザやOSの差も残り、外部APIや決済・配送のような依存先は常に変動します。さらにユーザー側の入力は、誤字や途中送信、想定外のコピペ、通信切断、タブの復帰など“揺れ”を前提にせざるを得ません。だからこそエラーハンドリングは「例外対応」ではなく、日常運用で必ず通る体験の一部として設計しておく必要があります。エラーが出た瞬間に体験が停止してしまうのか、それともユーザーが落ち着いて復帰できるのかで、プロダクトの信頼は大きく分かれます。

エラー体験の難しさは、ユーザーが内部状態を確認できない点にあります。送信は完了したのか、保存は反映されたのか、注文は確定したのか、支払いはどうなったのか。ここが見えないままだと、ユーザーは最悪のケース（データ消失・二重請求・個人情報漏洩など）を想像しやすくなり、不安から連打・再送・更新・別端末といった行動に走ります。その結果、実際に状態不整合や二重処理が発生し、サポートの問い合わせも増えます。つまり「分からない状態」はUXだけでなく、実装と運用にもダメージを与える構造になっています。本稿では、予防→表示→文言→404/500→アクセシビリティ→実装→計測改善を一本の判断軸でつなぎ、現場で迷いにくい形に整理します。

1. WebエラーハンドリングをUXの中核として捉える

エラーハンドリングを「最後にメッセージを付ける作業」と捉えると、どうしても薄い告知で終わりやすくなります。しかし実務では、エラーが起きる場所はたいてい“最も重要なフロー”です。保存、投稿、決済、予約、アップロード、権限付与のような行為はユーザーの目的が最大化している瞬間であり、同時に外部要因や非同期処理の影響を受けやすい領域でもあります。ここでの失敗は「少し不便」ではなく、「このサービスは信用できない」という評価に直結しやすいので、エラー体験はプロダクト品質の根幹として扱う必要があります。良いエラー体験は、普段のUIがどれだけミニマルでも「状態が見えて、復帰できる」という安心感をユーザーに与えます。

もう一つ重要なのは、エラーが“起きたこと”よりも“起き方”で評価される点です。同じ通信失敗でも、入力が保持されていて再試行が安全なら、ユーザーは「一時的な障害」として受け止められます。逆に、入力が消え、何が起きたかが分からず、再試行が危険そうなら、ユーザーは「壊れた」「怖い」「もういいや」と感じます。つまりエラーハンドリングは、ユーザーの心理と行動を安定させる設計であり、結果として二重処理や問い合わせを減らす“安全装置”でもあります。UX・実装・運用の境界をまたぐ設計テーマとして捉えると、投資の優先順位がブレにくくなります。

1.1 エラーを「体験の途切れ」ではなく「分岐」として設計する

エラーは停止に見えますが、設計上は“分岐”として扱うと自然に強くなります。入力エラーは「正しい入力へ導く分岐」、権限エラーは「ログインや権限付与へ導く分岐」、通信エラーは「再試行や後で続けるへ導く分岐」、在庫切れは「代替商品や入荷通知へ導く分岐」です。分岐として考えると、ユーザーが知りたい情報（何が起きたか／なぜ起きたか／次に何ができるか）が必然的に決まり、単なる告知で終わりにくくなります。さらに、分岐には“出口”が必要なので、ボタンやリンク、入力保持、代替導線のような具体的手段まで含めて設計する発想になります。

分岐設計で特に意識したいのは「ユーザー目的の保持」です。エラー後にフォームがリセットされる、カートが消える、編集内容が失われる、といった体験は復帰コストが高く、心理的にも「また失敗するかも」という不安を増やします。逆に、入力保持、下書き保存、やり直しの短距離化、復帰の安全性が担保されていると、同じエラーでも“軽い段差”に変わります。ユーザーは完璧に理解できなくても「戻れる」と感じられれば前に進めます。分岐としてのエラーは、復帰の短さがそのまま信頼の強さに変換される領域です。

1.2 「エラーが出ること」より「エラーが分からないこと」がUXを壊す

ユーザーが最も嫌うのは、エラーそのものより「今どうなっているのか分からない」状態です。UIが無反応だと、ユーザーは待つのではなく操作を増やして解決しようとします。連打、戻る、更新、別端末、別ブラウザ、同じ操作の再実行。こうした行動は“ユーザーの努力”に見えますが、システム側では重複リクエストや不整合を引き起こしやすく、事故率を上げる方向に働きます。つまり曖昧さは、体験の問題であると同時に、システムを不安定にする問題でもあります。

説明は長くする必要はありません。短くても「送信中」「失敗」「入力は保持」「注文は未確定」「再試行できます」といった判断材料が揃っていれば、ユーザーは落ち着けます。逆に、丁寧さを狙って曖昧表現（「問題が発生しました」「処理に失敗した可能性があります」）を並べると、不安を増やしてしまいます。言える範囲で断言し、言えない範囲は「確認中」「数分後に反映」など見通しを出す。曖昧さを減らすほどユーザーの行動は安定し、問い合わせも減り、結果としてプロダクト全体の評価が上がりやすくなります。

2. Webエラーハンドリング設計の目的を「設計目標」に落とす

エラーハンドリングが弱いプロダクトでは、目的が「エラーを表示する」で止まっていることが多いです。しかし実務で必要なのは、その先にある成果、つまり「復帰できる」「誤操作が減る」「信頼が保たれる」「改善につながる」を設計目標として定義することです。目的が明確になると、どのUIを使うか（インラインかモーダルか）、どの情報を載せるか（原因の粒度、影響範囲、次の行動）、どこまで裏側の整合が必要か（冪等性、状態遷移、再試行の安全性）が判断しやすくなります。特に高リスク領域（決済・注文・データ保存）は、見た目のメッセージより「状態の一貫性」と「復帰の安全性」が価値の中心になります。

もう一つ重要なのは、目的がユーザー向けだけではないことです。運用や開発が「再現できる」「優先度が付けられる」「改善できる」形にすることも、エラーハンドリングの目的に含めると強くなります。ユーザーの画面で丁寧に案内しても、裏側で原因が追えなければ同じ問題が繰り返され、結局ユーザーの不満は増えます。エラー体験は“守り”に見えますが、観測と改善の仕組みまで含めると、プロダクトの進化を加速する“攻め”の設計にもなります。エラーハンドリングをUXと運用改善の橋として捉えると、投資対効果が高い領域になります。

表の読み方：UIはユーザーの判断を支える“表面”で、実装・運用は再試行や状態表示を成立させる“土台”です。たとえば「再試行ボタン」は、サーバ側で冪等性がないと危険なボタンになりますし、「注文は確定していません」という断言は、状態遷移の設計が曖昧だと嘘になります。逆に、土台が整っていればUIは簡潔でも強く、ユーザーは迷いにくくなります。

3. Webでエラーを「起こさせない」予防設計（Prevention）

予防設計は「ユーザーを縛る」ことではなく、「ミスしやすい状況を先回りで減らす」ことです。入力フォーマットが分からない、必要情報が足りない、無効な操作ができてしまう、確認が不足して破壊的操作を実行してしまう。こうした摩擦が残っていると、ユーザーは“自分が悪い”と感じる前に、プロダクトへの信頼を失いがちです。予防は、ユーザーのストレス軽減だけでなく、問い合わせ削減や運用コスト削減にも直結するので、最初に投資する価値が高い領域です。特にフォームや入力が多いプロダクトでは、予防設計がそのままCVRや完了率に影響します。

予防を強くするコツは、フォームだけに閉じないことです。処理中を見せる、連打を防ぐ、段階的に情報を出す、権限要求のタイミングを正しくする、外部依存の失敗を吸収する。こうした“体験全体の予防”が整うと、ユーザーは「このサービスは状況を説明してくれる」「失敗しても戻れる」と感じ、自然に行動が安定します。結果としてエラーがゼロにならなくても、エラー体験が“怖い出来事”になりにくくなります。エラーを減らすより先に、エラー時の不安を減らす設計が効くことも多いです。

3.1 入力ミスを減らす「制約」と「支援」のバランス

入力制約を強くしすぎると、ユーザーは窮屈に感じて離脱します。逆に緩すぎると、送信後にまとめてエラーが出て修正負担が増えます。現実的なバランスは、まず入力を短くし、次に候補を出し、次に自動補完し、その場で気づかせる、という順で支援を積み上げることです。特にモバイルでは、入力モードやオートコンプリートを適切に指定するだけでミスが減り、入力速度も上がります。ユーザーは“正しい入力”より“早く終わる入力”を求めがちなので、支援は速度の改善として効きます。

さらに「失敗しても戻れる設計」も予防です。入力保持、下書き保存、戻る導線、途中保存などがあると、ユーザーは安心して入力でき、結果としてミスも減ります。予防を「失敗を許さない」方向に寄せると、ユーザーは試行錯誤できず詰まりやすくなります。逆に「失敗しても復帰できる」方向に寄せると、体験は柔らかくなり、完了率も上がりやすくなります。予防は“厳格さ”ではなく“復帰のしやすさ”で作ると、長期的に強い設計になります。

• 予防として効きやすい施策（フォーム）
  • 入力項目の削減（必須を最小化し、後で補完できる設計にする）
  • 選択肢化（自由入力を減らし、候補を提示して迷いを減らす）
  • 自動整形（全角/半角、ハイフン、空白、不要記号を吸収する）
  • インラインバリデーション（その場で気づかせ、修正距離を短くする）
  • 入力保持（エラー後も値を消さず、再入力コストをゼロに近づける）

<!-- モバイルで効きやすい入力支援例 --> <label for="email">メールアドレス</label> <input  id="email"  type="email"  name="email"  autocomplete="email"  inputmode="email"  placeholder="例：[email protected]"  aria-describedby="email-help" /> <small id="email-help">連絡用のメールアドレスを入力してください。</small>

3.2 破壊的操作は「確認」より「取り消し」で守る

確認ダイアログは安全そうに見えますが、頻度が高い操作に毎回挟むと、ユーザーは読まなくなり形骸化します。実務で効きやすいのは「取り消し（Undo）」で安全性を担保し、フローを止めない設計です。削除・取消・解除のような操作は、直後に短時間の取り消しを出すことで誤操作の損失を大きく減らせます。これにより、ユーザーは「怖いから触らない」状態になりにくくなり、結果として機能の利用率やタスク完了率も上がりやすくなります。安全は、行動を止めるのではなく行動を支える方向で設計すると体験が良くなります。

ただし、取り消しが成立するには“状態が壊れない裏側”が必要です。サーバ側で即時削除して復元できない設計だと、Undoは嘘になります。ユーザーはUIの約束が守られない瞬間に強い不信を抱きます。UIだけ先に作るのではなく、論理削除、猶予期間、復元可能な状態管理など、実装側の設計とセットで整えると事故が減ります。UndoはUIパターンというより、システムの設計姿勢を露出させる機能だと考えるとブレにくくなります。

// トーストでUndoを出す例（疑似） function showUndoToast(message, onUndo, durationMs = 5000) {  const toast = document.createElement("div");  toast.innerHTML = `    <span>${message}</span>    <button id="undo">元に戻す</button>  `;  toast.querySelector("#undo").onclick = () => {    onUndo();    toast.remove();  };  document.body.appendChild(toast);  setTimeout(() => toast.remove(), durationMs); }

3.3 二重送信・二重決済を“UIと実装”の両方で防ぐ

「送信ボタンを無効化する」だけでは二重処理は防げません。通信が遅いとユーザーは戻る・更新・別端末など別行動を取るため、UI側の防止は簡単にすり抜けます。だからサーバ側の冪等性（同じリクエストを何度受けても結果が一つになる）と、状態遷移の整合（注文→決済→確定などが矛盾しない）が重要になります。UI側では処理中表示と二重押し防止を行い、サーバ側では冪等キーや重複排除で守る。このセットが揃って初めて「再試行」が安全な行動になります。安全に再試行できる設計は、ピーク時や障害時に強いプロダクトの必須条件です。

二重処理は“ユーザーが悪い”のではなく、“不安が行動を増やす”構造から生まれます。だからこそUIは、処理中・成功・失敗を明確にし、「今は触らなくていい」とユーザーが理解できる形にする必要があります。さらに「失敗したが入力は保持されている」「注文は未確定なので再試行できる」といった断言ができるほど、ユーザーは落ち着きます。二重処理を防ぐ設計は、技術だけでなく心理の制御でもあると捉えると、UIと実装の接続が強くなります。

• 二重処理を減らすための基本セット
  • UI：処理中表示、ボタン無効化、進捗表示、成功/失敗の明示、再試行の安全性提示
  • API：冪等キー、重複排除、状態遷移の一貫性、タイムアウト後の復帰シナリオ
  • 運用：重複検知ログ、異常アラート、返金/取り消しの手順、ユーザーへの説明テンプレ

4. Webエラー表示のUI設計（場所・タイミング・視覚）

エラーの見せ方は「何を書くか」より「どこに出すか」「どれくらい残すか」「どの程度強く見せるか」で体験が決まります。エラーが起きた場所と無関係な位置にメッセージを出すと、ユーザーは原因を探してスクロールし、修正に時間がかかり、結果として離脱します。反対に、問題点の近くで、短い説明と次の行動が揃っていれば、ユーザーは迷わず復帰できます。エラーは注意を奪う情報なので、強く出しすぎれば作業が止まり、弱すぎれば気づかれません。重要度によって強度を階層化し、必要な時だけ強く、普段は静かに、という設計が現実的です。

Webは非同期処理が多いので、ユーザーが「今は処理中なのか」「失敗なのか」「成功なのか」を誤解しやすいです。この誤解が二重操作を生むので、エラー表示は“状態管理UI”として設計します。状態を見える化し、復帰導線を残し、必要な情報が消えない。さらに、エラーが複数ある場合は「今どれを直せばいいか」の優先順位が必要になります。ユーザーは正しい順序で直してくれるとは限らないので、UI側で“修正の道筋”を作るほど、復帰が速くなり体験が安定します。

4.1 エラー表示場所の選定（インライン／トースト／モーダル／ページ）

インライン表示は、フォームや入力に紐づくエラーで最も強いパターンです。視線移動が少なく、どこを直せばいいかが直感的に分かります。さらに上部に要約（エラー一覧）を置くと、長いフォームでも迷子になりにくくなります。一方でトーストは軽微な通知に向きますが、消えると困る情報（復帰が必要な失敗）には不向きです。モーダルは強制力が高いので、決済確定のように“止める価値がある”場面に限定しないと、ユーザーの流れを壊します。ページ全体のエラー（404/500）は回遊導線と安心感をセットにしないと、離脱の加速装置になります。

補足：同じ「失敗」でも、ユーザーが“今すぐ直すべきもの”と“放置してもよいもの”が混ざると混乱します。軽微な失敗まで強いUIで出すと、画面が常に緊急状態になり、重要エラーの重みが消えます。逆に重要エラーをトーストで流すと、見落として事故が増えます。エラーの強さは“重要度の階層”として設計するほうが安定します。

4.2 色・アイコン・強調（色だけに頼らない）

赤は分かりやすい一方、乱用すると「常に危険」な印象になり疲労を増やします。実務では色を“意味の固定”として使い、強調は太字・アイコン・枠線・配置の近さなど複数手段で分散させるほうが壊れにくいです。色覚多様性の観点でも、色だけで状態を区別すると情報が欠落します。エラーは気づかせる必要はありますが、脅す必要はありません。警告と案内のバランスが取れているほど、プロダクトの人格（信頼感）が安定します。

• 視覚表現でありがちな事故
  • 色だけで区別してしまい、意味が伝わらない
  • 重要でないエラーまで強く出して、画面が常に緊急状態になる
  • エラーが出た場所から遠い位置に表示して、ユーザーが迷子になる
  • アイコンや装飾が多すぎて、本文よりUIが目立つ

5. Webエラーメッセージの書き方（内容設計）

エラーメッセージは「丁寧に書く」ほど良いわけではありません。ユーザーが必要としているのは、長い説明ではなく、原因の要約と復帰の具体手順です。特に重要操作では、曖昧な表現が不安を増幅します。「失敗したかもしれません」ではなく、「失敗しました／完了していません／再試行できます」のように、言える範囲で状態を断言するほうが信頼につながります。逆に技術コードや専門用語を出すと、理解が止まり、問い合わせに直行しやすくなります。メッセージは“ユーザーの行動を前に進めるための短い道標”だと考えると、必要な情報が自然に絞られます。

文章はUIとセットで設計します。入力欄の直下に出るなら短く、画面上部の要約なら一覧性を優先し、詳細は展開やヘルプリンクに逃がす。メッセージ単体で完結させようとすると冗長になり読まれません。短くても迷わない構造を作ることが重要です。また、同じ種類の失敗で文言が揺れると、ユーザーは毎回学び直すことになります。文言のテンプレ（構造、トーン、粒度）を持つと、プロダクト全体の信頼が積み上がります。

5.1 「状況→理由→次の一手」の三点セットで書く

• 状況：何が起きたか（ユーザーの言葉で）
• 理由：なぜ起きたか（理解できる粒度で）
• 次の一手：どうすれば良いか（行動に落とす）

例： 「アップロードに失敗しました。 ファイルサイズが上限（5MB）を超えています。 サイズを小さくするか、別のファイルを選択してください。」

この三点セットは、長文にしなくても“復帰の判断”に必要な情報が揃うのが強みです。逆に、理由が不明な障害は無理に原因を断定せず、「通信が不安定な可能性」「時間をおいて再試行」といった“安全な行動”へ誘導するほうが誠実です。ユーザーは原因の技術的詳細より、次に何をすれば前に進めるかを求めています。

5.2 責めないトーンと誠実な断言を両立する

ユーザーを責める表現（「正しく入力してください」）は短い割に攻撃的に聞こえやすいです。代わりに「〜が必要です」「〜すると進めます」のように、前進を示す表現にするとストレスが減ります。一方で、決済や注文のように不安が大きい領域では、優しさを“曖昧さ”にしないことが重要です。「注文は確定していません」「支払いは完了していません」など、状態が言えるなら断言し、言えないなら「確認中です」「結果が分かり次第表示します」と見通しを出します。断言できないのに断言すると、後で矛盾が発生し信頼を失います。トーンは柔らかく、状態は誠実に、が基本です。

6. Webの404/500エラー画面設計（離脱を防ぐ導線）

404や500は、ユーザーにとって“迷子”や“不安”が最大化しやすい画面です。ここで何も案内がないと、ユーザーは「このサイトは信用できない」と判断しやすく、そのまま離脱します。逆に、検索・カテゴリ・人気ページ・サポート導線が整っていれば、404は「探索の再開地点」に変わります。つまり404/500は、単なる失敗の表示ではなく、体験をつなぎ直すための再起動ポイントとして設計できます。特にSEOや広告からの流入が多いサイトでは、404の品質がそのまま機会損失に直結します。

404/500は運用改善の入口でもあります。リンク切れが多いならリダイレクトやサイト内リンク修正が必要ですし、500が多いなら特定機能や外部依存の耐障害性を見直すべきです。ユーザーの離脱を防ぎながら、運用側が学習できる情報（エラーID、URL、時間帯、環境）を集められると、改善サイクルが回りやすくなります。404/500は“最後のページ”ではなく、“戻ってくるためのページ”として設計すると、必要な要素が決まりやすくなります。

6.1 404ページ（Not Found）を「探索の再開地点」にする

404で大切なのは、謝ることより“戻り方”を示すことです。ユーザーは目的があって来ているので、最短で目的に戻れる導線が必要です。検索バーがあるだけで回収率は上がりやすく、カテゴリや人気ページがあれば、目的が曖昧だったユーザーも再探索できます。さらに「このページは移動した可能性」が高いなら、関連候補（似た記事、似たカテゴリ）を出すと良いです。404は“迷子の救助”なので、救助装備（検索・ナビ・ホーム・サポート）を最小セットとして揃えるのが実務的です。

• 最低限置きたい要素（404）
  • 検索バー（最短で目的に戻す）
  • 主要カテゴリ／人気ページ（迷子の回収）
  • ホームへ戻る導線（安全な退避）
  • 問題報告（URLを添えて送れる）

<!-- 404ページの最小構成例 --> <h1>ページが見つかりません</h1> <p>URLが間違っているか、ページが移動した可能性があります。</p> <form action="/search">  <input name="q" placeholder="サイト内検索" />  <button>検索</button> </form> <nav>  <a href="/">ホームへ戻る</a>  <a href="/category/popular">人気カテゴリ</a>  <a href="/support">サポート</a> </nav>

6.2 500ページ（Server Error）では「安全性」と「再試行の設計」を優先する

500系は「支払いはどうなった？」「送信は反映された？」の不安が強いので、言える範囲で安全性を示すのが重要です。たとえば決済直後なら「二重請求は発生しません」「注文状況はマイページで確認できます」といった“確認手段”を提示するだけでも安心につながります。再試行は、ただボタンを置くだけではなく、再試行して良いタイミング（すぐ／数分後）や代替手段（別決済、サポート）を明示すると、無駄な連打が減ります。重要なのは、ユーザーが“危険な行動”を選ばないように導くことです。

また、500の表示は「内部で起きていることを隠す」のではなく、「ユーザーに必要な範囲だけを誠実に伝える」設計が信頼につながります。原因を断定できないなら断定しない。ただし「次にどうすれば良いか」は必ず残す。ユーザーは原因の詳細より“復帰の道筋”を求めています。そこが用意されているだけで、500は離脱ポイントから復帰ポイントに変わります。

6.3 メンテナンス／障害告知は「見通し」を出す

メンテ中は原因の詳細より「いつ復旧するか」「何が使えないか」「代替手段はあるか」が重要です。復旧見込みと更新頻度が分かると、ユーザーは待つ判断ができます。逆に見通しがないと、何度もアクセスして失敗し、ストレスが増えます。告知は“ユーザーの時間を守るUI”として設計すると、必要な情報の優先順位が自然に決まります。特にB2Bや業務用途では、復旧見込みの提示は信頼の中核になります。

7. Webエラーのアクセシビリティ設計（見える・伝わる・操作できる）

アクセシビリティは「追加で対応する項目」ではなく、エラー時の復帰を成立させるための必須条件です。色だけの区別は見落としを生み、スクリーンリーダーで読めないエラーは復帰不能になります。特にフォームは、エラーが複数出たときに「どこから直せばいいか」が分からなくなりがちなので、フォーカス移動・要約・各項目のエラー紐づけが重要です。アクセシビリティを整えると、支援技術利用者だけでなく一般ユーザーの復帰も速くなります。つまりアクセシビリティは“全体の使いやすさ”に直結します。

非同期エラーが多いアプリでは、読み上げが過剰に騒がしくならない制御も必要です。重要なエラーだけを通知し、軽微な通知は静かに表示する。エラーの強さの階層化はアクセシビリティにも直結します。ユーザーの注意を奪いすぎると作業が止まりますし、通知が多すぎると重要なものが埋もれます。アクセシビリティは“情報設計”そのものなので、エラーの頻度や重要度に応じて通知戦略を決めると、体験が安定します。

7.1 フォームエラーの基本パターン（ARIA）

<label for="zip">郵便番号</label> <input id="zip" aria-describedby="zip-error" aria-invalid="true" /> <p id="zip-error" role="alert">  郵便番号は7桁で入力してください（例：1234567）。 </p>

7.2 アクセシビリティ観点チェック（エラー周り）

8. Webエラーハンドリングをデザインシステムと実装で統一する

エラー表現が画面ごとに揺れると、ユーザーは復帰方法を毎回学び直すことになります。これは小さな違和感として蓄積し、長期的には信頼と効率を落とします。だからエラーは、デザインシステムの一部としてコンポーネント化し、トークン（色・余白・アイコン）、文言ルール（構造・トーン）、挙動（表示位置・消える条件・再試行の仕様）を統一するのが理想です。統一の価値は見た目ではなく、復帰導線と状態表現の一貫性です。ユーザーが「この表示が出たらこうすればいい」と学習できるほど、復帰は速くなりストレスは減ります。

実装面では、エラーを分類してUIへマッピングできるようにすると、例外が増えても破綻しにくくなります。さらに予期せぬ例外で画面が真っ白になる事故を防ぐために、エラーバウンダリのような落ち先を用意しておくと、ユーザー体験の崩壊を止められます。落ち先の画面は、ただ謝るのではなく、再読み込み・サポート・エラーIDの提示で復帰を支える設計にします。デザインシステムと実装の統一は、運用フェーズで効きます。リリース回数が増えるほど「毎回同じ基準で守れる」ことが価値になります。

// Reactの簡易エラーバウンダリ例（UI崩壊を防ぐ） class ErrorBoundary extends React.Component<  { children: React.ReactNode },  { hasError: boolean; errorId?: string } > {  state = { hasError: false, errorId: undefined };  static getDerivedStateFromError() {    return { hasError: true, errorId: crypto.randomUUID() };  }  componentDidCatch(error: unknown) {    console.error("UI例外", error, this.state.errorId);  }  render() {    if (this.state.hasError) {      return (        <div role="alert">          <h1>表示に問題が発生しました</h1>          <p>再読み込みで解決する場合があります。解決しない場合はサポートへご連絡ください。</p>          <p>エラーID：{this.state.errorId}</p>          <button onClick={() => location.reload()}>再読み込み</button>        </div>      );    }    return this.props.children;  } }

9. Webエラー発生後に「価値提供」へつなげる設計

エラーはユーザーの行動を止めますが、同時に「何に困っているか」が最も明確になる瞬間でもあります。だからエラーは、適切に設計すれば支援のチャンスになります。入力エラーなら候補提示、通信エラーならオフライン導線、404なら検索や人気導線、決済エラーなら別手段や注文確認の誘導。こうした支援は、ユーザーを追加の手間に追い込まず、短距離で前進させるほど効果が出ます。ここで“次にできること”が提示されていれば、ユーザーは離脱ではなく継続を選びやすくなります。

大切なのは、ヘルプへ丸投げしないことです。ヘルプ記事へ飛ばすだけだと、ユーザーは探し直しを強いられます。エラー文の近くに再試行・編集・別手段・問い合わせが置かれ、必要なら状況情報が添付される。このように“その場で解決へ向かう導線”を作ると、エラーは離脱ではなく復帰の入口になります。エラーは不快な出来事ですが、設計次第で「このサービスはちゃんとしている」という信頼の積み上げにもなります。困ったときに助けてくれる体験は、平常時の便利さより強く記憶されることがあります。

• エラー後の「前に進める」導線例
  • 「再試行」＋「別手段」＋「後で続ける」
  • 「入力を自動修正」＋「例を表示」＋「該当欄へジャンプ」
  • 「注文状況を確認」＋「履歴ページへ」＋「問い合わせ（ID付き）」

10. Webエラーを計測して「減らす」改善ループへ接続する

表示が丁寧でも、同じエラーが繰り返し起きれば体験は悪化します。だからエラーハンドリングは「守る」だけでなく「減らす」まで含めると強くなります。実務で見るべきはエラー率だけではありません。エラー後に復帰できたか（復帰率）、エラー後に離脱したか（離脱率）、同一操作の連打や重複処理が起きていないか（二重処理兆候）も重要です。特に重要導線（購入、送信、保存）ほど、エラー後離脱率の改善は直接的に成果へ効きます。エラーの“数”よりエラーの“結果”を追うほうが、改善が実務に直結します。

観測の設計はUIの設計と同じくらい重要です。相関IDがないと、サポートとログが結びつかず再現できません。どの画面・どの操作・どの環境で起きたかが分からないと、改善が後回しになります。エラーを“再現できる形”で残すだけで、改善スピードが上がり、結果としてユーザーのエラー体験も減ります。計測は「怒られたくないから」ではなく、「同じ苦しみを減らすため」にあると捉えると、現場で回る設計になります。

// 相関ID付きで「観測できる失敗」にする例 async function postWithErrorId(url, payload) {  const errorId = crypto.randomUUID();  try {    const res = await fetch(url, {      method: "POST",      headers: {        "content-type": "application/json",        "x-error-id": errorId,      },      body: JSON.stringify(payload),    });    if (!res.ok) throw new Error(`HTTP ${res.status}`);    return await res.json();  } catch (e) {    console.error("送信失敗", { errorId, url, e });    const err = new Error("送信に失敗しました。時間をおいて再試行してください。");    // @ts-ignore    err.errorId = errorId;    throw err;  } }

• 改善ループで追うと効きやすい指標
  • エラー発生率（全体・機能別）
  • エラー後復帰率（再試行成功、修正完了）
  • エラー後離脱率（重要導線ほど重要）
  • 同一操作の連続実行（連打、再送の兆候）
  • 問い合わせ率（エラー種別別に結びつける）

まとめ

Webのエラーハンドリングは、単なる失敗通知ではなく、ユーザーの目的を最後まで守るためのナビゲーション設計です。エラーは例外ではなく、必ず起こり得る分岐として前提化します。そのうえで「何が起きたのか」という透明性と、「次に何をすればよいのか」という復帰導線を、できるだけ短い距離で提示することが重要です。曖昧な文言や責任を感じさせる表現を避け、責めないトーンで説明することで、不安や不信感を抑えられます。さらに、表示ルールや操作パターンを一貫させ、アクセシビリティにも配慮することで、エラー時でも迷いにくい体験を保てます。

同時に、UIだけでなく実装側の整合も不可欠です。冪等性を確保して二重送信を防ぎ、状態遷移を明確に設計し、通信断や途中離脱が起きても破綻しない構造にしておくことで、復帰可能性は高まります。加えて、相関IDやログ設計を通じてエラーを追跡し、復帰率や離脱率を計測すれば、エラーは改善ループの入口になります。エラーを「なくす」ことよりも、「壊れない・戻れる・学べる」構造を積み上げることが、持続可能なWeb体験を支えます。