--- name: error-classification description: > ソフトウェアにおける非正常状態(Error, Defect, Fault, Failure)の分類と定義を提供する。 JIS規格・JSTQB・Bertrand Meyer等の複数の標準に基づき、各概念の違いを明確化し、 適切なエラー設計・障害対策の判断を支援する。エラー設計、障害分析、コードレビュー、 テスト設計時に用語の混乱を防ぎ、正確な分類に基づく対処戦略の選択に使用。 対象言語: 言語非依存。 トリガー:「ErrorとFaultの違い」「DefectとBugの関係」「障害と故障の区別」 「エラーの分類」「Failureとは何か」「非正常状態の設計」「エラー用語の定義」 「エラーと欠陥の違い」「faultとfailureの違い」 といったエラー分類・用語定義関連リクエストで起動。 --- # Error, Defect, Fault, Failure 分類ガイド ソフトウェアの非正常状態を正確に分類し、適切な対処戦略を導く。 ## なぜ分類が重要か Error, Defect, Fault, Failure は混同されやすいが、それぞれ異なる概念であり、対処戦略も異なる。用語を曖昧に使うと、設計判断を誤る原因となる。 ## 規格別定義の比較 | 種別 | Error(エラー) | Defect(欠陥) | Fault(障害) | Failure(故障) | |------|----------------|---------------|--------------|----------------| | **JIS X 0014:1999** | 値または状態の不一致(人的過誤を含まない) | - | 機能単位の能力の縮退・喪失を引き起こす異常な状態 | 要求された機能を遂行する機能単位の能力がなくなること | | **JIS Z 8115:2000** | 値または条件の不一致(人的過誤を含む) | - | 機能を遂行不可能なアイテムの状態 | アイテムが要求機能達成能力を失うこと | | **JSTQB** | 間違った結果を生み出す人間の行為 | 機能が実現できない原因となる不備(Bug含む) | 欠陥(Defect)と同義 | 期待した機能から逸脱すること | | **Bertrand Meyer** | 開発中になされた誤った決定 | 意図した振る舞いからシステムが逸れる原因となる特性 | 実行中に意図した振る舞いから逸れるイベント | - | | **JIS Q 9000:2006** | - | 意図された用途に関連する要求事項を満たしていないこと | - | - | ## 実用的な解釈 ### 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(故障) → 機能喪失。ユーザーに影響 ``` ## 設計への適用 ### 分類に基づく対処戦略 | 分類 | 対処戦略 | 実装パターン | |------|---------|-------------| | **Error** | 呼び出し元で対処 | Either/Result型、バリデーション | | **Defect** | 即座に検出・停止 | アサーション(require/assert)、事前条件チェック | | **Fault** | 隔離と回復 | Error Kernel、Let it crash、サーキットブレーカー | | **Failure** | 予防と冗長化 | フェイルオーバー、冗長構成、監視・アラート | ### 判断フロー ``` 非正常状態が発生 ↓ 呼び出し元で想定・対処可能か? ├─ YES → Error(エラー) │ → Either/Result型で表現 └─ NO ↓ 本来発生してはいけない状態か?(契約違反) ├─ YES → Defect(欠陥) │ → アサーションで即座に停止 └─ NO ↓ 機能が遂行不可能な異常状態か? ├─ YES → Fault(障害) │ → 隔離・監視・再起動 └─ 機能達成能力を喪失 → Failure(故障) → フェイルオーバー・冗長化 ``` ### `error-handling` スキルとの関係 本スキルは非正常状態の**分類と概念定義**を扱う。具体的な実装パターン(Either/Result型の使い方、言語別ライブラリ等)は `error-handling` スキルを参照。 | 観点 | 本スキル | error-handling スキル | |------|---------|---------------------| | 焦点 | 概念の分類・定義 | 実装パターン | | 対象 | Error/Defect/Fault/Failure全体 | 主にErrorの処理 | | 用途 | 設計判断・用語統一 | コーディング・レビュー | ## レビューチェックリスト - [ ] エラーハンドリングコード内で、Error/Defect/Fault/Failureが適切に区別されているか - [ ] 想定内のError(バリデーション等)をResult型で表現しているか - [ ] Defect(契約違反)をアサーションで検出しているか - [ ] ErrorとDefectを混同して同じハンドリングをしていないか - [ ] Faultに対する隔離・回復戦略が存在するか - [ ] 例外を「何でもcatch」して、Defectを握り潰していないか ## 関連スキル(併読推奨) このスキルを使用する際は、以下のスキルも併せて参照すること: - `error-handling`: 分類に基づくエラー処理の実装パターン(Either/Result, 例外等) - `aggregate-design`: 集約操作における不変条件違反とドメインエラーの区別 - `domain-building-blocks`: 値オブジェクト構築時のエラー分類