ux-error-recovery

エラーリカバリースキル

このスキルの動作（最初にお読みください）

これは生成型のスキルです。Claude のデフォルトのエラー処理はまさにアンチパターンです。すなわち「問題が発生しました」と書き、送信時にのみ検証し、ユーザーを責め（「無効な値が入力されました」）、すべてのエラーを同じ重大度で扱い、全大文字で叫んだりコードを漏らしたりし（「Error 403: Forbidden」）、404 から戻る手段を提供せず、そもそもエラーを防ぐことなど考えもしません。優れたエラーリカバリーはこれを覆します。その最初の一手はエラーを防ぐことです（ほとんどのエラーは制約、マスク、デフォルト値によって設計で排除できます）。次に、避けられないエラーをリカバリー可能にします。つまり、何が起きたのか、次に何をすべきかをユーザーに伝え、セーフティネットを提供し、行き止まりを決して残しません。そこでこのスキルは次をゲートします。

1. 重要度、エラーの発生源、そしてジャーニーのどの地点でエラーが起きるかを明確にする — これらが、どれだけの摩擦、確認、エスカレーションが正当化されるかを決めます。
2. 常に真であるコアを適用する — まず防ぐ、中断せずに検証する、リカバリー可能なメッセージを書く、セーフティネットを提供する、決して行き止まりにしない。
3. 文脈依存の判断（確認 vs. 取り消し、検証のタイミング、ユーモア、AI の劣化／信頼度、透明性 vs. セキュリティ）をトレードオフとともに浮き彫りにする。

その後、検証のために ux-heuristics-audit、ux-accessibility-audit、ux-aesthetics-audit、ux-microcopy-audit、ux-dark-patterns-audit、および（モバイルの場合）ux-mobile-responsiveness-audit にハンドオフします。

スコープと構成（docs/orchestration-policy.md §9 による）：このスキルはエラー／失敗／リカバリーの体験 — エラー状態、メッセージの作り込み、検証の挙動、取り消し／確認、劣化、エラーページ — を所有し、より低いスコープのスキルを再導出するのではなく構成します。コア子スキル（リカバリー体験の一部として構築）： ux-inputs-and-forms による入力フィールドの解剖学。サブパートを所有するピア（委譲）： トースト／通知の種類と頻度は ux-notifications-and-toasts へ、確認モーダルの仕組みは ux-modals-and-dialogs へ（到達した場合、それらが当該サブパートを所有します）。ダウンストリーム（提案はするが自動構築はしない）： ux-empty-states による初回利用／結果なし／クリア後の空画面、ux-login-signup によるパスワードリセットフロー、ux-settings による保存状態の確認、ux-contact-support によるエラー発生地点でのヘルプ／問い合わせ。継承し、再生成しない： 既存のデザインシステムがある場合、色／タイプ／スペーシングはそのトークンから取得します — ゼロから設計する場合にのみ、それらを設定します。

---

ステップ 0 — 設計前にコンテキストを確立する

不明な場合は質問し、回答なしで進める場合は前提を明示します:

• これが失敗すると何が起きるでしょうか? エラー処理は現実世界の結果に合わせる必要があります。風船の色の提案が間違っているのは軽い失望で済みますが、安全でない食品の推薦、誤った口座への送金、完全削除は重大な害となります。リスクが低ければ遊び心のある失敗も許されますが、リスクが高い場合は詳細な説明、保守的なデフォルト、取り消し、そして人間へのエスカレーション経路が求められます。リスクが不明確なときは、利便性よりも慎重さを選びましょう。
• これはうっかりミスでしょうか、それとも勘違いでしょうか? うっかりミスは、システムを理解しているユーザーによる自動操縦的な失念です(「返信」ではなく「全員に返信」をクリックするなど)。これは制約、提案、適切なデフォルト、取り消しで修正します。勘違いは誤ったメンタルモデルから生じ、通常は新しいユーザーに多く見られます(アイコンが不明瞭なため削除ではなくアーカイブしてしまうなど)。これはより明確なラベル、ガイダンス、そしてユーザーとシステムのメンタルモデルのギャップを埋めること(リサーチを通じて発見する)で修正します。わかりにくいシステムをユーザーが「そのうち覚える」と想定してはいけません。ユーザーは離れてしまいます。
• エラーはジャーニーのどこで発生するでしょうか? 設計が異なる 3 つの領域があります: 入力/バリデーション(フォームのフィールド)、システム/AI の失敗(サーバー、ネットワーク、または誤った予測)、ナビゲーション(404、壊れたリンク)。それぞれに独自のリカバリー手段が必要です。
• プラットフォーム。 モバイルでは予防がより重要になります — 制約のあるキーパッド、入力マスク、OTP の自動入力、より大きなタッチターゲット、そしてキーボードの上に表示されたままになるエラーテキストです。

---

常に適用する核心(ほぼすべてのエラー体験に当てはまる正解)

1. 処理する前に予防する

• 入力を制約する。 誤った値が入力できないように境界を設定します: 電話番号/カード番号フィールドには数値キーパッド、営業時間内のみの時間ピッカー、無効な選択肢はグレーアウト。
• 寛容な形式 + 入力マスクを使う。 ユーザーが自然だと感じる方法で入力できるようにし、入力に合わせて整形します(スペース/括弧/ハイフンを追加し、不要な文字を除去する)。マスクは形式を表示し、適用もするため、電話番号、日付、カード番号の混乱を減らせます。
• ほとんどのユーザーが望むものに合った合理的なデフォルトを設定する — ただし、ユーザーよりビジネスに有利なデフォルトは決して使わないこと(事前にチェックされたサブスクリプションは、親切なデフォルトではなくダークパターンです)。
• 記憶の負担を軽減する。 常に見える進行中のサマリー(複数区間のフライト、複数ステップの予約)を保ち、ユーザーが画面を切り替えずに済むよう SMS コードを自動検出します。長々とした説明よりも、明確でざっと目を通せるラベルとヒントを。

2. 中断せずにバリデーションする

• バリデーションはフォーカスが外れた後に行い、キーストロークごとでも送信時のみでもないようにします。 ユーザーがフィールドへの入力を終えてフォーカスを移すまで待ってから指摘します。「送信」をクリックするまでエラーを表示しないフォームは、離脱されてしまいます。
• 要件ベースの入力(新しいパスワード)では、リアルタイムが例外です — 各ルールが満たされるたびにチェックマークを表示し、ユーザーが推測しなくて済むようにします。
• 入力が実際に有効になるまで、エラー状態を表示したままにします — ユーザーが再入力を始めた瞬間ではありません。フィールドがデフォルト/成功に戻るのは値が本当に合格したときだけであり、ユーザーは自分が修正している内容のコンテキストを保てます。

3. 責めるのではなく、回復を促すメッセージを書く

• すべてのメッセージを次の構造にします: 何が起きたか → なぜ重要か → 次に何をすべきか。(「入力したコードが一致しません。受け取れませんでしたか? コードを再送する。」)問題ではなくアクションを先頭にします(「画像認識に失敗しました」ではなく「明るい場所や別の角度で試してください」)。
• 平易で人間的な言葉。 専門用語やコード、「不正/制限されています」といったロボットのような言い回しは避けます。短く — 1〜2 文に。人はストレスを感じているときはさらに読みません。
• 正確に、決して曖昧にしない。 「エラーが発生しました」は誰の助けにもなりません。フィールド名と修正方法を明示します。
• 礼儀正しく。決してユーザーを愚かに感じさせない。 責めたり、見下したりしないこと。
• すべて大文字は使わない — 怒鳴っているように読め、読解速度を 13〜20% 低下させ、低視力やディスレクシアのユーザーのアクセシビリティを損ないます。
• メッセージはそれが関係するもののそばに置く — 見落とすバナーの中ではなく、フィールドの隣に。

4. セーフティネットを用意する

• 可逆的な操作には元に戻す機能を。 すぐに使えて明白なものにします(「元に戻す」ウィンドウ)。これにより、取り返しのつかないミスへの不安が取り除かれ、ユーザーが気軽に試せるようになります。
• 本当に破壊的・不可逆的な操作には確認を求める — 中断の度合いは、後悔の度合いに見合わせます。確認を多用しすぎるとダイアログ疲れを引き起こし、ユーザーは読まなくなります。確認ボタンは場所を離して配置し、ダブルタップで誤って確定されないようにします。
• 失敗時には作業を保持する。 システムや AI の処理が失敗したとき、ユーザーに最初からやり直させないでください。入力を保持し、確認が必要な箇所を強調し、手動での引き継ぎにコンテキストを引き継ぎます。

5. 行き止まりを作らない

• あらゆるエラーには先へ進む道を用意する — 再試行、ホームへ戻る、検索、または関連リンク。これはニールセンの「ユーザーがエラーを認識し、診断し、回復できるように支援する」です。
• 404 は壁ではなく、復帰の場です。 ページが存在しない理由を率直に、申し訳なさを込めて説明し、ブランドイメージを保ち、明確な出口を提示します。検索入力欄、および/または役立つリンクの短いリストです(URL のスペルチェックで近い候補を表示)。すっきりと保ちましょう — 簡潔なコピー + 検索で十分です。
• エラーの瞬間にヘルプを提供する。 次のステップが「ヘルプを求める」ことなら、適切なチャネルをその場でリンクします(サポート体験自体は ux-contact-support に委ねます)。

---

文脈依存の判断（表面化させ、自動適用しない）

それぞれについてトレードオフとステップ0に紐づく推奨を提示し、ユーザーに判断を委ねます。これらすべてをデフォルトで適用するのは誤りです。

判断	適用する場合	避ける／適応させる場合	デフォルトの推奨
確認 vs. 取り消し	不可逆で影響の大きい操作を確認する（アカウント削除、恒久的なデータ損失）	リスクの低い／可逆的な操作を確認する（ダイアログ疲れ）。真に不可逆な操作を「取り消し」だけに頼る	可逆的な操作には取り消しを。確認は影響の大きい場合のみ — 可能なら取り消しも併せて提供する
バリデーションのタイミング	複雑な要件入力（パスワード）にはリアルタイム。単純なフィールドにはフォーカスを外したとき	通常のフィールドで入力途中にバリデーションする。送信時にのみバリデーションする	原則はフォーカスを外したとき。パスワード形式の入力にはリアルタイム
コピーにおけるユーモア／個性	親しみやすいコンシューマーブランド、リスクの低いエラー、404	リスクの高い状況（金融、医療、セキュリティ）、またはユーザーがサポートを求めて来たとき	ブランドに合わせる。機能的な導線を主軸に。迷ったらジョークは省く
AI／モデルの信頼度表示	ユーザーの判断を変え、リスクが高い場合（医療）	意味のない精度（85.8% 対 87%）で、行動を変えずノイズだけを加える	行動につながる場合のみ表示。一般向けには生のパーセンテージよりカテゴリ（高／中／低）や N-best を優先
段階的な機能低下／フォールバック	機能や AI が部分的に失敗しうる — 能力を段階的に下げ、ブラックアウトではなく手動への切り替えを提供する	危険な瞬間に突然すべて手動へ引き継ぐ。能力が低下したことを隠す	グレースフルに機能低下させ、コンテキストを保持し、手動の導線を提供する。リスクが高い場合は常に人によるエスカレーション経路を
説明における透明性 vs. セキュリティ	ユーザーが理解するに値する通常の制約	悪意ある行為者にシステムの悪用方法を教える詳細（スパムフィルター、認証失敗）	脆弱性を明かさずに善意のユーザーの次の行動を導く。悪用者には「退屈な」失敗を
エラー時の「学習にご協力ください」フィードバック	素早く二者択一で、実際に対応する（そして対応したことをユーザーに伝える）	復旧を妨げる、または何にもつながらない見せかけの収集	軽量かつ解決後に。パートナーシップとして提示し、「苦情を報告」とはしない。任意
404 の充実度（イラスト／インタラクティブ性）	ブランドに利点があり、ページが煩雑にならない	無理なジョークや煩雑さが認知負荷を高め、出口を埋もれさせる	簡潔でブランドに沿ったコピー + 検索 + 主要リンク。視覚要素／インタラクティブ性は本当にブランドに合う場合のみ追加

リスクの高い文脈（金融、医療、セキュリティ、破壊的／不可逆的な操作）では、複数のデフォルトが同時に反転します。より保守的なデフォルト、可能な場合は取り消しを伴う必須の確認、ユーモアより真剣なトーン、明示的な人によるエスカレーション、そしてセキュリティを意識した（完全に透明ではない）説明です。

---

結果を検証する（オーケストレーション）

ハンドオフでは、各レンズをそのインストール可能なスキルの name で指定します。呼び出せるのは、そのスキルがインストールされている場合のみです。インストールされていない場合でも、このスキル自体の中核にこれらのルールがすでに含まれているため、ブロックせずにそのまま進めてください。

生成または修正を行った後は、完了と宣言するのではなく、結果を監査レンズに引き渡してください。これらは候補のレンズです。姿勢は docs/orchestration-policy.md で設定するか、全体を ux-design-review 経由でルーティングしてください。ここでは、heuristics、microcopy、dark-patterns は Tier A（自動実行）、accessibility、aesthetics、mobile-responsiveness は Tier B（提示） です。既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は使用状況に絞り込まれます。mobile-responsiveness はモバイルの場合にのみ適用されます。ユーザーが特定の目的でこのスキルを呼び出した場合は、その範囲を尊重してください。

• ux-heuristics-audit (Tier A) — エラーの防止、「ユーザーがエラーを認識し、診断し、回復できるように支援する」、システム状態の可視性（修正されるまでフィールドはエラー状態のまま、失敗は表面化される）、およびユーザーの制御と自由（元に戻す、404 からの脱出）。
• ux-accessibility-audit (Tier B — 提示、デザインシステムがある場合は絞り込み) — エラーを色だけでなく複数の手段で伝える（赤だけではなくアイコンやテキスト）、エラーテキストをそのフィールドにプログラム的に関連付ける、フォーカスをメッセージへ移動する、すべて大文字にしない、エラー状態や成功状態で十分なコントラストを確保する。
• ux-aesthetics-audit (Tier B — 提示、デザインシステムがある場合は抑制) — すっきりとした 404／エラーページ、警報的になりすぎず気づきやすいエラー状態、テキストの壁を作らない。
• ux-microcopy-audit (Tier A) — このスキルはコピーに焦点を当てます。何が起きたか／なぜか／次にどうするかの構造、アクションを先に示す表現、平易な人間の言葉、責めない丁寧なトーン、専門用語やコードを使わないこと。
• ux-dark-patterns-audit (Tier A) — エラーに固有の罠：キャンセルや削除の確認におけるコンファームシェイミング、ビジネスに都合よく設定されたデフォルト、誤ったダブルタップを誘発する位置に置かれた確認ボタン、破壊的な操作がワンクリックでできるのに「元に戻す」を隠す、ユーザーに罪悪感を与えるように枠付けされたフィードバック。摩擦と確認はユーザーを守るためのものであり、決してユーザーを罠にかけるものではありません。
• ux-mobile-responsiveness-audit (Tier B — 提示) — 制約のあるキーパッド、マスクと OTP の自動入力、キーボードに隠れないエラーテキスト、再試行／元に戻す／確認のコントロールにおけるタッチターゲットのサイズ。

監査で矛盾が表面化した場合（たとえば、ビジネス側がすべてのアクションに厳しい「本当によろしいですか？」の壁を求める、または罪悪感を煽るキャンセル確認を求めるなど）、一次タスクへと引き戻して解決してください。ユーザーはすでに何かうまくいかない事態に対処しているところです。摩擦を減らし、明確な進む道を示し、エラーの瞬間を決してユーザーを操作するために使ってはいけません。

---

よくある do/don't パターン

❌ しないこと	✅ すること
「エラーが発生しました」/「Error 403: Forbidden」	何が起きたか → なぜ重要か → 次に何をすべきかを、平易な言葉で
送信を押したときだけ検証する	フォーカスが外れたときに検証する（パスワードはリアルタイムで）
再入力した瞬間にエラー状態を消す	値が実際に有効になるまで表示したままにする
ユーザーを責める。すべて大文字	丁寧で、行動を先に示し、文頭のみ大文字、フィールドのそばに
すべてのエラーを同じ深刻度で扱う	摩擦をリスクに合わせる — 可逆的なものには元に戻す、確認は重大な結果を伴うものだけ
すべてを確認する	取り消せない操作のために確認を取っておき、ダイアログ疲れを避ける
ステップが失敗したときにユーザーの作業を失う	入力を保持し、確認が必要な箇所を強調し、手動での引き継ぎにコンテキストを引き継ぐ
ユーザーを元いた場所に送り返すだけのそっけない 404	説明 + 検索 + 役立つリンクを、ブランドに沿って、すっきりと
事前にチェックされた/操作的な「デフォルト」、キャンセルダイアログでの罪悪感の煽り	役立つ、ユーザーの利益になるデフォルト、敬意ある確認
予防を怠り、エラーが起きてから対処するだけ	制約し、マスクし、デフォルトを設定して、エラーが起きないようにする
確認せずに出荷する	ヒューリスティクス + アクセシビリティ + 美的感覚 + マイクロコピー + ダークパターン（+ モバイル対応）に引き継ぐ

---

出典レッスン（Uxcel）

• 入力エラーの表示
• 問題メッセージの書き方
• ユーザーエラーの本質
• 優雅な失敗のデザイン
• 404 ページをデザインするための 11 のベストプラクティス
• セーフティネットと元に戻す
• よくあるパターン