Pre-mortem 失敗シナリオ分析

Pattern declaration

Primary pattern: Reviewer Secondary patterns: Inversion Why: 失敗シナリオ分析はチェックリスト型評価が主だが、設計判断を含まない変更では実行を止めるゲートが必要

Goal / 目的

• 変更が「6ヶ月後にインシデントを引き起こした」と仮定し、その根本原因を逆算することで、生存バイアスや楽観バイアスを排除し、設計の致命的欠陥を事前に発見する。
• 通常のリスク分析では浮上しない「見落としがちな失敗経路」をあぶり出す。
• 既定 CI レビューでは自動発火しない（/challenge 等の明示呼び出し向け）。

Non-goals / 扱わないこと

• 既知のベストプラクティス違反の指摘（それは既存スキルの役割）。
• 実装の細部（コードスタイル、命名規則など）への言及。
• すべての変更に対する網羅的なリスク列挙（重大な失敗シナリオに集中する）。

Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限りNO_REVIEWを返す。

• 差分に設計判断を含む変更がある（ADR、設計ドキュメント、アーキテクチャ変更）
• 変更が機械的なもの（誤字修正、フォーマット、コメントのみ）ではない
• テストコードやフィクスチャのみの変更ではない
• inputContextにdiffまたはfullFileが含まれている

ゲート不成立時の出力: NO_REVIEW: pre-mortem — 設計判断を含む変更が検出されない

False-positive guards / 抑制条件

• すでにADRやデザインドキュメントでリスクと緩和策が明記されている項目は重複指摘しない。

Rule / ルール

分析フレームワーク

1. 仮想失敗宣言: 「この変更は6ヶ月後に深刻な障害を引き起こした」と断定する。
2. 逆算推論: その障害に至る具体的な因果連鎖を3つ以上構築する。
3. 隠れた前提の発掘: 変更が暗黙に依存している前提条件を列挙する。
4. ドミノ効果の追跡: 1つの前提が崩れたとき、何が連鎖的に壊れるかを追う。

失敗カテゴリ（優先順）

1. データ破損・不整合: スキーマ変更、マイグレーション、状態管理の欠陥
2. 障害の伝播: 依存サービスの停止、タイムアウト未設定、リトライ暴走
3. スケーラビリティの壁: 暗黙のO(n²)、メモリリーク、接続プール枯渇
4. 運用不能: ログ不足、ロールバック不可、監視の盲点
5. セキュリティ劣化: 権限昇格の経路、入力検証の抜け穴

制約

• 失敗シナリオは最大 5 件。最も致命的なものを優先。
• 各シナリオには必ず「崩れる前提」「因果連鎖」「検証方法」を含める。
• 推測は推測として明示する（「可能性がある」「〜の場合に限り」）。

Evidence / 根拠の取り方

• 失敗シナリオは差分の具体的な行に紐づける（<file>:<line>）。
• 因果連鎖は差分→既存コード→外部依存の順で追跡可能にする。
• 「なぜこの前提が崩れうるか」の根拠を示す（類似インシデント、既知の制約など）。

Output / 出力フォーマット

すべて日本語。

(pre-mortem):1: [要約] この変更の最大リスクは〈1文〉

<file>:<line>: [失敗シナリオ1] <タイトル>
  崩れる前提: <この変更が暗黙に依存していること>
  因果連鎖: <前提崩壊 → 中間事象 → 障害>
  検証方法: <この失敗を事前に防ぐ/検知する方法>

<file>:<line>: [失敗シナリオ2] ...

Good / Bad Examples

Good

src/lib/review-engine.mjs:45: [失敗シナリオ] LLMプロバイダのレート制限変更による全レビュー停止
  崩れる前提: OpenAI APIのレート制限が現在の値で維持される
  因果連鎖: レート制限引き下げ → リトライ上限到達 → 全PRレビューがタイムアウト → CIブロック
  検証方法: レート制限をモック環境で1/10に設定し、グレースフル・デグラデーションを確認

Bad

src/lib/review-engine.mjs:45: APIが落ちるかもしれない

（因果連鎖なし、検証方法なし、具体性なし）

評価指標（Evaluation）

• 合格基準: 失敗シナリオが差分に紐づき、「崩れる前提」「因果連鎖」「検証方法」の3要素が揃っている。
• 不合格基準: 差分と無関係な一般的リスク、根拠のない不安の列挙、検証方法の欠如。

人間に返す条件（Human Handoff）

• ビジネス要件の変更やステークホルダー判断が必要な失敗シナリオ。
• リスク受容（accept）の判断が必要な場合。
• 失敗シナリオの影響範囲が他チーム/他サービスに及ぶ場合。