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

Review Lens

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

Instructions

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

Guardrails

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

LAB Cross-Check

状態は 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）— 実装層のロールバック手順設計