# Failure Point Review

> 自動化フロー・システム統合の障害点を体系的に列挙し、影響度・検知可能性・対応方針を整理する。実装前・リリース前の最終チェックで使う。

- Skill: `thinkyou0714/failure-point-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/failure-point-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/failure-point-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/failure-point-review

---


## Purpose

「動いているときは考えない」障害シナリオを、事前に潰す。
SPOF（単一障害点）・カスケード障害・サイレント障害を発見し、許容できる障害と対処が必要な障害を区別する。

## Use When

- 自動化フローのリリース前
- システム統合（Stripe / Supabase / n8n 等）の設計レビュー
- trigger-action-map の後に障害シナリオを深掘りしたい場合
- 「このフロー、何か見落としていないか」という不安がある場合

## Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

- **対象フロー**: 障害点を確認するフロー・システムの説明
- **依存サービス一覧**: 外部API・DB・メッセージキュー等
- **許容ダウンタイム**: 各コンポーネントの許容停止時間
- **現在の監視**: 今どのような監視が存在するか（ない場合は「なし」と明示）

## Output Contract

以下の順で出力すること。順序を変えない。

1. **論点**: このフローで最も危険な障害点はどこか
2. **根拠**: その論点をそう判断した理由
3. **障害点マップ**: 分類別の障害シナリオ（後述フォーマット）
4. **含意**: 障害パターンが示すアーキテクチャの脆弱性
5. **改善案**: SPOF の解消・検知性の改善・フォールバック追加
6. **代替案**: アーキテクチャを見直して障害リスクを根本的に下げる案
7. **判断材料**: 「対応必須 / 後回し / 受容」を決めるための情報

### 障害点マップ フォーマット

| 障害点 | 種別 | 影響度 | 検知可能か | 対応方針 |
|---|---|---|---|---|
| （障害の説明） | SPOF/タイムアウト/データ破損/サイレント失敗/カスケード | 高/中/低 | 自動/手動/不可 | フォールバック/リトライ/受容/修正 |

種別の定義:

- **SPOF**: ここが止まると全体が止まる
- **タイムアウト**: 応答が遅い・返ってこない
- **データ破損**: 誤ったデータが書き込まれる
- **サイレント失敗**: エラーにならずに失敗している
- **カスケード**: 一部の障害が連鎖して全体に波及する

## Review Lens

- **目的妥当性**: 列挙した障害点がシステムの目的に対して有意か
- **範囲の過不足**: サイレント失敗・カスケード障害を見落としていないか
- **中長期リスク**: 今は発生しないが、スケール時に顕在化する障害がないか
- **LAB全体との整合性**: Stripe / Supabase / n8n のそれぞれの障害パターンを含んでいるか
- **非エンジニア理解可能性**: 「このシステムが止まると何が起きる」を説明できるか
- **他LLM移植耐性**: 障害分類が Claude 固有の基準に依存していないか

## Instructions

1. フローを構成する全コンポーネント（外部API含む）をリストアップする
2. 各コンポーネントに対して「止まったら何が起きるか」を記述する
3. SPOF を特定する（ここが止まると他も全部止まるポイント）
4. タイムアウト・応答遅延シナリオを列挙する
5. データ不整合・二重処理・欠損のシナリオを列挙する
6. サイレント失敗（エラーにならずに正常終了に見える障害）を列挙する
7. 各障害に「検知できるか」「フォールバックがあるか」を確認する

## Guardrails

- 「発生しないだろう」で障害を除外しない
- 「通知する」だけのフォールバックを「対応済み」にしない
- サイレント失敗を「エラーが出ないから問題ない」にしない
- 受容する障害は「なぜ受容するか」の理由を必ず記録する
- 障害対応の最終方針は人間が決定する

## LAB Cross-Check

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | n8n の障害・Webhook の失敗シナリオを含んでいるか |
| データ / 認証 / ログ | — | Supabase / DB の障害パターンを含んでいるか |
| 実装 / 運用フロー | — | 障害検知・復旧手順を実運用で実行できるか |
| 非エンジニア理解可能性 | — | 影響をビジネス言語で説明できるか |
| 会員共有 / 再利用耐性 | — | 障害マップが他フローにも転用できるか |
| 他LLM移植耐性 | — | 障害分類が Claude 固有に依存していないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

- **要件**: 対応必須の障害点の一覧と対応仕様
- **成功条件**: 各障害点に対応済みと判断できる基準
- **失敗条件**: 対応したはずの障害が顕在化した場合の判断基準
- **実行範囲**: 障害対応のために修正してよいファイル・設定・ワークフロー
- **影響範囲**: 障害対応が波及するシステム・機能
- **ロールバック方針**: 障害対応が失敗した場合の戻し方
- **コスト比較**: 各障害対応の工数概算

## Further Reading

- `trigger-action-map` skill — フロー全体の設計確認
- `retry-idempotency-check` skill — リトライ・べき等性の深掘り
- `monitoring-alert-design` skill — 障害検知の監視設計
- `rollback-readiness` skill（lab-data-auth-ops）— データ層のロールバック設計
- `rollback-plan` skill（lab-implementation-flow）— 実装層のロールバック手順設計