新たな失敗パターン発生時の対処フロー — 完全解説

対象： 成長型ハーネスを適用したプロジェクトで、未知の失敗パターンが発生した場合
目的： 失敗を最短時間で収束させ、ハーネスに学習させ、次回以降の再発を防止する
準拠： IEEE 1044:2009（ソフトウェア異常分類）・Google SRE インシデント管理

全体フロー（4フェーズ）

Phase 1：検知・初動（0〜5分）
    ↓
Phase 2：原因特定・収束（5〜60分）
    ↓
Phase 3：ハーネスへの学習（収束後・15分）
    ↓
Phase 4：予防策の有効化（次セッション開始時・5分）

Phase 1：検知・初動（0〜5分）

失敗の種類を判断する

まず「どの種類の失敗か」を3秒で判断します。

種類別・最初に使うプロンプト

種類A（バグ）→ P-02を使う：

【P-02：バグ調査】
以下のエラーが発生しました。
原因を特定してください。コードを変更する前に必ず原因を説明してください。

エラーメッセージ：
[ここにエラーをそのまま貼り付ける]

発生した操作：
[何をしたときに起きたか]

直前の変更：
[最後に変更したファイルとその内容]

種類B（設計崩壊）→ P-13を使う：

【P-13：スペックドリフトチェック】
SRS（要件定義書）と現在の実装を比較してください。

SRS_[プロジェクト名].md を読んで、
現在の実装が仕様と一致しているか確認してください。

乖離している箇所をすべてリストアップし、
優先度（高・中・低）を付けてください。

種類C（データ破壊）→ 緊急プロンプトを使う：

【緊急：データ破壊対応】
データが破壊された可能性があります。
以下の順番で対応してください。

1. 現在のデータ状態を確認する（変更は一切しない）
2. バックアップファイルの存在を確認する
3. 破壊の範囲を特定する
4. 復旧手順を提示する（実行はしない）

確認が完了するまでファイルやDBを変更しないでください。

種類D（セキュリティ侵害）→ 即時停止プロンプトを使う：

【緊急：セキュリティ問題】
セキュリティ上の問題が発生しました。
開発を一時停止して以下を確認してください。

1. 問題の内容：[症状を記述]
2. 影響範囲の特定（どのファイル・機能・データが影響を受けるか）
3. 外部への漏洩リスクの評価
4. 修正手順の提示（実行はしない）

修正前に必ず確認を取ること。

種類E（コンテキスト枯渇）→ P-07を使う：

【P-07：セッション切り替え】
コンテキストが枯渇しています。
新しいセッションに切り替えます。

以下を実行してください：
1. 現在の作業状態をdocs/progress.mdに書き出す
2. 未完了タスクをリストアップする
3. 次のセッションで最初に読むべきファイルを指定する
4. セッションを終了する

progress.mdの書き出しが完了したら「切り替え準備完了」と言ってください。

種類F（テスト改ざん）→ テスト検証プロンプトを使う：

【テスト整合性チェック】
テストコードが改ざんされた疑いがあります。
以下を確認してください。

1. tests/ディレクトリ内のファイルの最終変更日時を確認する
2. テストコードの内容を確認し、実装コードの動作を正しく検証しているか確認する
3. テストが「常に成功するように書き換えられていないか」を確認する
4. 問題があれば、テストを元の状態に戻す手順を提示する（実行はしない）

Phase 2：原因特定・収束（5〜60分）

原因特定の3ステップ

ステップ1：仮説を立てる（Claude Codeに任せる）

P-02の回答を受け取ったら、Claude Codeが提示した「原因の仮説」を確認します。

仮説が正しいか確認するために、
以下の方法で検証してください（コードは変更しない）：

[Claude Codeが提示した仮説を引用]

検証方法を提示してください。

ステップ2：修正前に影響範囲を確認する

【P-03：修正前の影響範囲確認】
修正を実行する前に以下を確認してください。

修正対象：[ファイル名・関数名]
修正内容：[変更する内容]

この修正が影響する可能性のある他のファイル・機能をすべてリストアップしてください。
影響範囲が確認できたら修正を実行してください。

ステップ3：修正後の確認

修正が完了しました。
以下を確認してください。

1. 修正したファイルのテストを実行する
2. 影響範囲として挙げたファイルのテストも実行する
3. E2Eシナリオ（SC-001〜SC-003）を実行する
4. すべてのテストが通ったことを確認してから「修正完了」と報告する

収束の判断基準（RYGゲート）

3回ルール（同じ修正を3回試みても解決しない場合）

【3回ルール：アプローチ変更プロンプト】
同じアプローチで3回試みましたが解決しませんでした。
アプローチを根本から変えてください。

これまでの試み：
1. [1回目の修正内容と結果]
2. [2回目の修正内容と結果]
3. [3回目の修正内容と結果]

別の原因の可能性を3つ挙げて、
それぞれの検証方法を提示してください。

Phase 3：ハーネスへの学習（収束後・15分）

新しい失敗パターンをハーネスに記録する

収束後、必ず15分以内に以下のH-UPDATEプロンプトを実行します。

【H-UPDATE：新失敗パターンの記録】
今回発生した失敗パターンを成長型ハーネスに記録してください。

## 今回の失敗の概要
- 失敗の種類：[A〜Fの種類]
- 発生した状況：[何をしていたときに起きたか]
- 症状：[どんなエラー・問題が起きたか]
- 原因：[根本原因]
- 解決方法：[どうやって解決したか]
- 発見方法：[どうやって気づいたか]
- 発見までの時間：[分]
- 被害：[失われた作業時間・データ等]

## 記録先ファイル
以下のファイルを更新してください：

1. ~/claude-harness/knowledge/failure_patterns.md
   → FP-[次の番号] として追記する

2. ~/claude-harness/templates/CONSTRAINTS.md.template
   → C-[次の番号] として禁止事項に追加する

3. ~/claude-harness/templates/CLAUDE.md.template
   → 必要であれば検知プロンプトを追加する

更新が完了したらテンプレートバージョンを上げてください（例：v1.2 → v1.3）。

記録の書き方（failure_patterns.md への追記フォーマット）

## FP-[番号]：[失敗の名前]

**発生日：** YYYY-MM-DD  
**プロジェクト：** [プロジェクト名]  
**種類：** [A〜Fの種類]  
**緊急度：** [高・中・低]

### 症状
[どんなエラー・問題が起きたか。具体的に]

### 根本原因
[なぜ起きたか。表面的な原因ではなく根本原因を]

### 解決方法
[どうやって解決したか。次回同じ問題が起きたときに使える手順]

### 予防策
[次回から最初に設定すべきこと]

### 変換した禁止事項
→ CONSTRAINTS.md.template の C-[番号] として追加済み

禁止事項への変換フォーマット（CONSTRAINTS.md.template への追記）

## C-[番号]：[禁止事項の名前]

**禁止：** [具体的に何をしてはいけないか]

**理由：** [なぜ禁止か。FP-[番号]の失敗から学んだ]

**対処：** [この状況が発生した場合、代わりに何をすべきか]

**検知方法：** [この問題が起きていないか確認する方法]

Phase 4：予防策の有効化（次セッション開始時・5分）

次のプロジェクトで禁止事項を引き継ぐ

新しいプロジェクトを開始するとき、H-NEWプロンプトを実行すると、更新されたCONSTRAINTS.md.templateが自動的にコピーされます。

【H-NEW：新プロジェクト開始】
新しいプロジェクトを開始します。
~/claude-harness/templates/ から最新のテンプレートをコピーしてください。

プロジェクト名：[プロジェクト名]
プロジェクトパス：~/projects/[プロジェクト名]/

コピーするファイル：
- CLAUDE.md.template → CLAUDE.md
- CONSTRAINTS.md.template → CONSTRAINTS.md
- AGENTS.md.template → AGENTS.md
- RULES.md.template → RULES.md
- progress.md.template → docs/progress.md

コピーが完了したら、CLAUDE.mdのPART Aを書き換えてください。

実例：FP-004「非同期処理の競合状態」の場合

実際に起きた状況

症状：テストは通るが、本番環境で断続的にデータが欠落する
種類：A（バグ）
発見：本番移行後3日目
被害：2時間のデバッグ時間

Phase 1で使ったプロンプト（P-02）

【P-02：バグ調査】
以下のエラーが発生しました。

エラーメッセージ：
データが断続的に欠落する（エラーメッセージなし）

発生した操作：
複数ユーザーが同時にデータを保存したとき

直前の変更：
なし（本番移行後3日目に発覚）

Phase 3で記録した内容（failure_patterns.md）

## FP-004：非同期処理の競合状態

**発生日：** 2026-05-26
**プロジェクト：** Substack自動配信システム
**種類：** A（バグ）
**緊急度：** 高

### 症状
複数ユーザーが同時にデータを保存すると、一部のデータが欠落する。
エラーメッセージは出ない。テスト環境では再現しない。

### 根本原因
非同期処理でのデータ書き込みに排他制御がなかった。
テストは単一ユーザーのシナリオしか想定していなかった。

### 解決方法
1. データ書き込み処理にミューテックスロックを追加する
2. E2Eシナリオに「同時アクセス」シナリオを追加する

### 予防策
設計段階でE2Eシナリオに「同時アクセス」シナリオを必ず含める

### 変換した禁止事項
→ CONSTRAINTS.md.template の C-005 として追加済み

Phase 3で追加した禁止事項（CONSTRAINTS.md.template）

## C-005：同時アクセスシナリオの省略禁止

**禁止：** E2EシナリオにSC-CONCURRENT（同時アクセス）シナリオを含めずに
本番移行してはならない

**理由：** 単一ユーザーのテストのみでは競合状態を検出できない（FP-004）

**対処：** E2E_SCENARIOS_TEMPLATE.md のSC-CONCURRENTセクションを
必ず実装してから本番移行すること

**検知方法：** 本番移行前チェックリストのPRE-010「同時アクセステスト完了」
を確認すること

対処フローの全体まとめ

新しい失敗が発生
       ↓
【Phase 1】種類を判断（3秒）→ 対応プロンプトを選ぶ（30秒）
       ↓
【Phase 2】原因特定 → 影響範囲確認 → 修正 → テスト確認
       ↓
【Phase 3】H-UPDATEで failure_patterns.md と CONSTRAINTS.md.template を更新
       ↓
【Phase 4】次のプロジェクトで H-NEW を実行 → 禁止事項が自動引き継ぎ
       ↓
次のプロジェクトでは「この失敗が最初から防止された状態」で開始

失敗対処の原則（非エンジニア向け）

原則1：焦らない
失敗は「学習の機会」です。焦って次々と修正を試みると、問題が複雑になります。まず「種類の判断」から始めてください。

原則2：変更前に必ず確認する
「修正してみたら別の問題が起きた」を防ぐために、変更前に必ず影響範囲を確認します。P-03の「修正前の影響範囲確認プロンプト」を使ってください。

原則3：3回ルールを守る
同じアプローチで3回試みても解決しない場合は、アプローチを根本から変えます。「もう1回だけ」は禁物です。

原則4：必ずハーネスに記録する
収束後15分以内にH-UPDATEを実行します。「後でやろう」は「永遠にやらない」と同義です。

原則5：失敗は恥ではない
ハーネスに記録された失敗パターンの数は「経験値」です。10件の失敗パターンを持つハーネスは、10件分の失敗を防止できます。

文書バージョン：v1.0 | 作成日：2026-05-26 | 準拠：IEEE 1044:2009 / Google SRE インシデント管理