Skip to content
cccskills
FreePublished on GitHub

error-classification

ソフトウェアにおける非正常状態(Error, Defect, Fault, Failure)の分類と定義を提供する。JIS規格・JSTQB・Bertrand Meyer等の複数の標準に基づき、各概念の違いを明確化し、 適切なエラー設計・障害対策の判断を支援する。

エラー設計、障害分析、コードレビュー、 テスト設計時に用語の混乱を防ぎ、正確な分類に基づく対処戦略の選択に使用。対象言語: 言語非依存。

トリガー:「ErrorとFaultの違い」「DefectとBugの関係」「障害と故障の区別」 「エラーの分類」「Failureとは何か」「非正常状態の設計」「エラー用語の定義」 「エラーと欠陥の違い」「faultとfailureの違い」 といったエラー分類・用語定義関連リクエストで起動。

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md7.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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: 値オブジェクト構築時のエラー分類

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、 不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。 以下のいずれかに該当する場合は必ずこのスキルを使用すること: - 集約(Aggregate)の新規設計・実装・リファクタリング(どの言語でも) - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定(「AとBは同じ集約にすべきか?」「この集約は大きすぎるか?」) - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断(ドメインイベント、結果整合性、Sagaパターン) - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正 キーワード例:集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、 エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを 検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を 使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時に トランザクション境界の問題を検出する場合に使用。 対象言語: 言語非依存(Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて)。 トリガー:「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」 「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」 「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」 といったトランザクション境界関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル(deprecation cycle)の 制度化、互換層の局所化(Adapter/Strangler Fig)、契約テスト(CDC)による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存(Java, TypeScript, Go, Python, Rust等すべて)。 トリガー:「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合(永続化、JSON変換など)に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。 これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。 コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。 トリガー:「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」 「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造(ドメイン層、 ユースケース層、インターフェースアダプタ層、インフラストラクチャ層)に基づく。特にインフラ層は 横断的関心事(ロギング、設定管理)のみ、永続化やRPCはインターフェースアダプタ層に配置すべき という原則を適用する。トリガー:「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」 「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。 一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

CQRS/ESが集約の境界定義とモデリングに与える影響を解説する。CQRSを導入すると集約は コマンド実行に必要な最小限の状態のみ保持すればよくなり、読み取り責務はリードモデルに 委譲できる。大きすぎる集約の軽量化、集約境界の再定義、イベントによる状態管理を支援する。 集約設計、CQRS導入時のモデリング見直し、パフォーマンス問題の解決時に使用。 対象言語: 言語非依存。 トリガー:「CQRSで集約が変わる」「集約が大きすぎる」「集約にメッセージ1000件」 「集約の更新が重い」「CQRS導入で集約を見直す」「集約を軽量化したい」 「集約にクエリ用データが混ざっている」「集約の境界を再定義」 といったCQRS/モデリング関連リクエストで起動。

The English summary is being prepared. Showing the original description.

j5ik2o/okite-ai80Updated Apr 25, 2026

See all skills by j5ik2o

Report a problem with this skill