coastdigitalgroup/coastai-skills

エラーおよびステータスシステム

目的

エラーおよびステータスシステムは、Webサイトの「アンハッピーパス」、つまりシステムレベルで何か問題が発生した瞬間を設計するための方法論を提供します。フォームレベルのバリデーションやコンテキストバナーとは異なり、このシステムは全ページまたはサイト全体の状態を処理します。これにより、障害が明確さ、共感、そして明確な「脱出方法」をもって伝えられ、技術的な問題が発生した際のユーザーのフラストレーションや離脱を防ぎます。

ユースケース

• 404 Not Found: ユーザーが存在しないURLに移動した場合。
• 500 Server Error: 重大なバックエンド障害によりページの読み込みが妨げられた場合。
• メンテナンスモード: サイトが更新のために意図的にオフラインになっている場合。
• オフライン状態: Webアプリケーションでユーザーが接続を失った場合。
• アクセス拒否 (403): ユーザーに特定のリソースを表示する権限がない場合。

使用すべきでない場合

• フォームバリデーション: フィールドレベルのエラーには form-design-system を使用してください。
• コンテキスト通知: ブロックしない更新や軽微なエラーには banner-and-alert-system を使用してください。
• 空のリスト: ページが正しく読み込まれたがデータが含まれていない場合は empty-state-system を使用してください。
• ローディング状態: 標準的なコンテンツ取得には skeleton-state-system を使用してください。

入力

1. エラーの種類: クライアントエラー (4xx)、サーバーエラー (5xx)、またはシステム状態 (メンテナンス) ですか？
2. 技術的コンテキスト: システムは、機密データを漏洩せずに、なぜ失敗したかを説明できますか？
3. 回復経路: ユーザーにとって最も可能性の高い次のステップは何ですか？
4. ブランドトーン: ブランドの声は、ユーモラスですか、プロフェッショナルですか、それとも厳密に技術的ですか？
5. システム制約: オフライン状態は、特定のローカルファーストアクションをサポートする必要がありますか？

出力

1. ステータスページの構造: エラーメッセージ、視覚的なアンカー、および回復アクションのための定義されたレイアウト。
2. メッセージ階層: 見出し（何が起こったか）と説明（次に何をすべきか）の標準。
3. 回復計画: 特定のエラーに合わせたリンク、検索入力、またはヘルプリソースのマップ。
4. オフラインUI仕様: 接続が失われたときのインターフェースの変更方法に関するルール。

ワークフロー

1. 障害の重大度を分類する

エラーの影響を判断します:

• 低 (404/403): 1つのURLに限定されます。サイトは正常です。リダイレクトに焦点を当てます。
• 高 (500): システム全体またはページを破壊します。サイトは苦戦しています。安心感とサポートに焦点を当てます。
• システム (メンテナンス): 意図的なダウンタイムです。期待管理に焦点を当てます（例：「午後2時に戻ります」）。
• 接続 (オフライン): 環境の障害です。状態の保持に焦点を当てます（例：「変更はローカルに保存されました」）。

2. 回復経路を確立する

すべてのエラーページには「脱出方法」が必要です:

• 「ホーム」ボタン: 絶対最小要件。
• スマート提案: 404の場合、人気ページへのリンクまたは検索バーを提供します。
• 「更新」トリガー: 5xxエラーの場合、リクエストを再試行するための目立つ方法を提供します。
• サポートリンク: 永続的な問題の場合、ヘルプセンターまたはステータスページへの直接パスを提供します。

3. 視覚的構造を設計する

エラービューに visual-hierarchy-system を適用します:

• 視覚的アンカー: ブランドに合わせたイラストやアイコンを使用して、障害の影響を和らげます。
• 明確な見出し: ステータスコード（「404エラー」）の代わりに「人間らしい」見出し（例：「そのページが見つかりません」）を使用します。
• 控えめなメタデータ: 技術コード（例：エラーID: 12345）は小さく低コントラストに保ち、ユーザーではなくサポートチーム向けにします。

4. 「人間第一」のメッセージングルールを適用する

ユーザーを遠ざける技術的な専門用語を避けます:

• 悪い例: 「500 Internal Server Error: Connection reset by peer.」
• 良い例: 「サーバー側で問題が発生しました。現在修正に取り組んでいます。」
• 悪い例: 「404 Resource not located.」
• 良い例: 「このページは道に迷ってしまったようです。」

5. レスポンシブ適応を計画する

• 全ページ vs モーダル: エラーがビューポート全体を占めるべきか（404/500では標準）、固定バナーとして表示されるべきか（オフライン状態では一般的）を決定します。
• 中央揃えレイアウト: エラーページではコンテンツを中央揃えにすることが多く、スキャン作業を最小限に抑え、ユーザージャーニーにおける「一時停止」を強調します。

判断ルール

• 「直接経路」ルール: エラーページを行き止まりにしないでください。特定の提案がない場合は、常に「ホームに戻る」と「検索」オプションを含めてください。
• 404での検索: サイトに100ページを超えるページがある場合、404ページには検索バーを必須で含める必要があります。
• メンテナンスの透明性: メンテナンスモードの場合、常に復旧予定時刻またはステータスページへのリンクを提供してください。
• オフライン時の永続性: オフライン時には、データ損失を防ぐために、機能しないアクション（例：「送信」ボタン）を視覚的に「グレーアウト」するか無効にしてください。

制約

• アクセシビリティ: エラーページは、なじみのある道案内を提供するために、サイトのグローバルナビゲーションとフッターを（可能な限り）維持する必要があります。動的なステータス変更（オフラインになるなど）の場合は、aria-live="assertive" 領域を使用して、変更を即座に通知します。
• 応答性: エラーページは可能な限り復元力がなければなりません。システムがすでに苦戦している場合に読み込みに失敗する可能性のある、重いアセットは避けてください。
• ブランディング: エラーページは、サイトの一部のように見える必要があり、汎用的なブラウザやサーバーのデフォルトページのように見えてはいけません。

よくある障害パターン

• 「行き止まり」: リンクのない404ページ。ユーザーはブラウザの戻るボタンを使用するか、離脱せざるを得ません。
• 「専門用語の壁」: 生のスタックトレースやデータベースエラーを表示し、ユーザーを混乱させ、セキュリティ情報を漏洩する可能性があります。
• 「責任転嫁」: 発見の失敗に対する責任を負う代わりに、ユーザーが何か間違ったことをしたことを暗示するメッセージング（例：「無効なURLを入力しました」）。
• スタイルの不一致: サイトの他の部分とは異なるフォント/色を使用するエラーページ。壊れているか悪意があるように見えます。

検証基準

• すべてのエラー状態 (404、500 など) に、明確で人間が読める見出しがある。
• 少なくとも1つの主要な回復アクション（例：「ホームに戻る」）が存在する。
• 404ページの場合、発見のために検索バーまたは人気ページへのリンクが提供されている。
• 技術的なメタデータ (エラーID) は存在するが、階層は低くなっている。
• 接続の変化 (オフライン) は ARIA ライブリージョンを通じて通知される。
• 視覚的なスタイルは、コアブランド/デザインシステムと一貫性を保っている。
• メンテナンスページは「復旧予定」または「ステータスページ」へのリンクを提供している。