Error, Defect, Fault, Failure 分類ガイド

ソフトウェアの非正常状態を正確に分類し、適切な対処戦略を導く。

なぜ分類が重要か

Error, Defect, Fault, Failure は混同されやすいが、それぞれ異なる概念であり、対処戦略も異なる。用語を曖昧に使うと、設計判断を誤る原因となる。

規格別定義の比較

実用的な解釈

Error（エラー）

入力値と期待値の相違状態。

• バリデーションエラー（入力値が期待する範囲外）
• ファイルが存在しないなどリカバリ可能な想定内の事象
• 呼び出し元が対処可能

例: ユーザー入力のメールアドレス形式不正、存在しないリソースへのアクセス
対処: Either/Result型で表現し、呼び出し元に判断を委ねる

Defect（欠陥）

要求事項を満たしていない状態。バグを含む。本来発生してはいけないもの。

• 契約（Design by Contract）の不履行
• 呼び出し元が事前条件を満たしていない
• アサーション（表明）で対応すべき

例: null不可の引数にnullが渡された、不正な状態遷移の試行
対処: アサーション（require/assert）で即座に検出・停止

Fault（障害）

機能遂行不可の異常状態。リカバリ不能。

• 呼び出し先のバグまたは責任不明
• システムの異常状態
• Akka/ErlangではError KernelとLet it crashパターンで耐性を持てる

例: DBコネクション枯渇、メモリ不足、外部サービスの完全停止
対処: 障害の隔離（Error Kernel）、監視と再起動（Let it crash）

Failure（故障）

機能達成能力を失った状態。

• Faultが解消されない結果としてシステムが機能を提供できなくなる
• ユーザーから見た最終的な症状

例: サービス全体のダウン、レスポンス不能
対処: 冗長化、フェイルオーバー、サーキットブレーカー

因果関係

Error（エラー）
  → 想定内。呼び出し元で対処可能

Defect（欠陥）
  → 本来あってはならない。アサーションで検出
  → 修正されなければ Fault を引き起こす

Fault（障害）
  → 異常状態。リカバリ困難
  → 継続すると Failure に至る

Failure（故障）
  → 機能喪失。ユーザーに影響

設計への適用

分類に基づく対処戦略

判断フロー

非正常状態が発生
    ↓
呼び出し元で想定・対処可能か？
    ├─ YES → Error（エラー）
    │         → Either/Result型で表現
    └─ NO ↓
        本来発生してはいけない状態か？（契約違反）
        ├─ YES → Defect（欠陥）
        │         → アサーションで即座に停止
        └─ NO ↓
            機能が遂行不可能な異常状態か？
            ├─ YES → Fault（障害）
            │         → 隔離・監視・再起動
            └─ 機能達成能力を喪失
                → Failure（故障）
                → フェイルオーバー・冗長化

error-handling スキルとの関係

本スキルは非正常状態の分類と概念定義を扱う。具体的な実装パターン（Either/Result型の使い方、言語別ライブラリ等）は error-handling スキルを参照。

レビューチェックリスト

• エラーハンドリングコード内で、Error/Defect/Fault/Failureが適切に区別されているか
• 想定内のError（バリデーション等）をResult型で表現しているか
• Defect（契約違反）をアサーションで検出しているか
• ErrorとDefectを混同して同じハンドリングをしていないか
• Faultに対する隔離・回復戦略が存在するか
• 例外を「何でもcatch」して、Defectを握り潰していないか

関連スキル（併読推奨）

このスキルを使用する際は、以下のスキルも併せて参照すること：

• error-handling: 分類に基づくエラー処理の実装パターン（Either/Result, 例外等）
• aggregate-design: 集約操作における不変条件違反とドメインエラーの区別
• domain-building-blocks: 値オブジェクト構築時のエラー分類