非エンジニア向け Claude Code 自動構築における

リスク・破壊・コンテキスト浪費 完全対策ガイド

作成者: Manus AI
対象: 非エンジニア・AI初心者が要件定義〜SDD自動構築を行うすべてのケース
根拠: 既存対策ファイル群（7ファイル）の全棚卸し診断 + Anthropic公式資料 + 業界標準

0. 診断結果サマリー：既存対策の現状評価

既存ファイル群（enhanced_development_failure_risk_loop_report.md、research_failure_risk_mitigation_report.md、review_test_reresearch_loop_templates_complete.md 等）を全棚卸しした結果、以下の評価となった。

結論：3つの重大な抜け穴が存在する。
コンテキスト枯渇対策、コスト管理、「完了誤認による破壊」への対策が不十分であり、これらが「システムが完成しないままお金とコンテキストが無駄になる」ケースの主因となっている。

1. リスク・破壊パターンの完全分類

非エンジニアが要件定義〜SDD自動構築で失敗するパターンは、次の5層に分類できる。

層A：設計前の失敗（最上流）

設計に入る前の段階で発生する失敗であり、後続のすべてに影響する。

層B：文書構築中の失敗

要件定義書・仕様書・SDD等を作成する過程で発生する失敗。

層C：実装中の失敗

Claude Codeが実際にコードを書く段階で発生する失敗。

層D：検証・レビュー中の失敗

層E：運用開始後の失敗

2. 最重要：3つの重大な抜け穴と完全対策

抜け穴①：コンテキスト枯渇・セッション切断（最も頻繁に発生）

何が起きるか： 要件定義〜SDD構築は会話が長くなる。Claudeは会話が長くなるにつれて前半の指示を忘れ、矛盾した回答をしたり、同じことを繰り返したり、途中で止まったりする。セッションが切れると、それまでの文脈がすべて失われ、最初からやり直しになる。

既存対策の状態： non_engineer_claude_code_requirements_master_summary.md に「コンテキスト枯渇への言及」はあるが、具体的な防止手順が未定義。

完全対策：CLAUDE.md + 進捗ファイル設計

プロジェクト開始時に必ず CLAUDE.md（Claude Codeがセッション開始時に自動で読むファイル）を作成し、以下を記載する。

# プロジェクト概要
目的：[一文で記載]
現在のフェーズ：[Phase番号と名前]
完了済みフェーズ：[リスト]
次に実施すること：[具体的な次のタスク]
絶対にやってはいけないこと：[禁止事項リスト]

加えて、progress.md を毎フェーズ終了時に更新し、「どこまで完了したか」を外部ファイルに保存する。セッションが切れても、次のセッション開始時に CLAUDE.md と progress.md を読ませるだけで文脈が復元される。

フェーズ分割の上限サイズ：

1つの会話セッションで扱うタスクは「1機能・1成果物・1フェーズ」を上限とする。たとえば「要件定義書を作る」と「仕様書を作る」は別セッションにする。これにより、コンテキスト枯渇が発生しても被害が1フェーズに限定される。

抜け穴②：コスト管理・トークン浪費防止（金銭的損失の直接原因）

何が起きるか： 要件定義の自動構築は、リサーチV1→V2→レビュー→再リサーチのループを繰り返す。このループが収束せずに回り続けると、コンテキストとAPIコストだけが消費され、何も完成しない。特に「Redが解消されないまま再リサーチを繰り返す」パターンが最も危険。

既存対策の状態： コスト管理に関する記述がほぼ存在しない。

完全対策：ループ上限とコスト停止条件

以下の「ループ停止ルール」を全プロジェクトに適用する。

さらに、各フェーズの開始時に「このフェーズで何を完了とするか」を1文で宣言させる。完了条件が不明なまま進めることを禁止する。

抜け穴③：「完了誤認による破壊」（最も気づきにくい）

何が起きるか： 非エンジニアは「AIが動くコードを出力した」＝「完成した」と誤解しやすい。しかし、動くコードと安全に運用できるコードは別物である。この誤解で本番投入し、データが消えたり誤配信が走ったりする。

既存対策の状態： RYGゲートは存在するが、「動いた」を「完成した」と誤解するパターンへの具体的な防止策が薄い。

完全対策：完了定義チェックリスト（Done Definition）

実装完了を宣言する前に、以下の全項目を確認する。

完了定義チェックリスト（Done Definition）
□ dry-runで期待通りの動作を確認した
□ 本番データ・本番APIに一切触れていない
□ 失敗時のrollback手順を実際に試した
□ 誤配信・重複投稿・二重課金が発生しないことをテストした
□ kill switchが機能することを確認した
□ ログが正しく記録されることを確認した
□ 人間の承認なしに本番操作が走らないことを確認した
□ Evidence Matrixの全根拠が最新状態である
□ CodexレビューでのすべてのBlockerが解消されている
□ Opusレビューでの運用リスクがすべてGreenまたはYellowである
□ 未解決のRedが存在しない

この11項目のうち1つでも未チェックの場合、「完了」と宣言してはならない。

3. 既存対策の確認：充実している部分

以下の対策は既存ファイルで充実しており、追加対策は不要である。

Codex/Opus二重レビューの役割分担は enhanced_development_failure_risk_loop_report.md で完全に定義されている。Codexが実装・CI・テスト・破壊的変更を検証し、Opusが要件・運用・事業リスク・代替案を評価する分担は適切である。

RYGゲート判定は research_failure_risk_mitigation_report.md と enhanced_development_failure_risk_loop_report.md の両方で詳細に定義されており、Green条件・Yellow条件・Red条件・NO-GO条件が明確である。

外部API・規約リスクへの対策は research_failure_risk_mitigation_report.md で詳細に定義されており、公式API確認・規約確認・代替手段調査・手動介入点の設計が含まれている。

再リサーチループのテンプレートは review_test_reresearch_loop_templates_complete.md で完備されており、Intent Sheet・Evidence Matrix・Research Brief・Requirement ID Ledgerが揃っている。

4. 完全対策の統合フロー

以上の診断を踏まえ、既存対策と新規追加対策を統合した完全フローを示す。

[開始]
  │
  ▼
【事前設定】CLAUDE.md作成 + progress.md初期化
  │ ← 抜け穴①の対策
  ▼
【Phase 0】入力受付 → Intent Sheet → 必須5項目チェック
  │ ← 層Aの対策
  ▼
【Phase 1】リサーチV1：実現可能性確認
  │ → NO-GO? → 停止 + 代替案提示
  ▼
【Phase 2】ユースケースレベル判定 + スコープ凍結宣言
  │ ← 層A-3の対策
  ▼
【Phase 3】リサーチV2：テンプレート充填
  │ → フェーズ完了チェック → progress.md更新
  ▼
【Phase 4】11成果物の生成
  │ → 根拠IDなし項目フラグ → 矛盾検出チェック
  ▼
【Phase 5】Codexレビュー（実装・テスト・破壊リスク）
  │
  ▼
【Phase 6】Opusレビュー（要件・運用・事業リスク）
  │
  ▼
【RYGゲート判定】
  ├── Green → 完了定義チェックリスト確認 → 合意 → 実装開始
  ├── Yellow → 条件付き進行 + 期限設定
  └── Red → 再リサーチ（最大3回上限）← 抜け穴②の対策
              │
              └── 3回でも解消しない → 設計変更 + 代替案提示

[実装フェーズ]
  │ → 本番接続禁止フラグ確認
  │ → dry-run実施
  │ → kill switch動作確認
  │ → 完了定義チェックリスト（11項目）← 抜け穴③の対策
  ▼
[完了]

5. 月次運用チェック（運用開始後の対策）

システムが稼働し始めた後も、以下の月次チェックを実施する。

6. 対策の完全性評価（診断後）

上記の追加対策を適用した後の評価。

7. 非エンジニア向け要約：「これだけ守れば壊れない」5つのルール

技術的な詳細を理解しなくても、以下の5つを守るだけで、「お金とコンテキストが無駄になる」リスクを大幅に減らせる。

ルール1：1回の会話で1つのことだけを頼む。
「要件定義書を作って、仕様書も作って、SDDも作って」を一度に頼まない。1つ完了したら次に進む。

ルール2：「動いた」と「完成した」は別物だと覚える。
AIがコードを出力しても、完了定義チェックリストの11項目が揃うまで本番に投入しない。

ルール3：Redが3回解消しなかったら設計を変える。
同じ問題に3回再リサーチしても解決しない場合、その方向性を諦めて別の方法を探す。これが最もコストを節約する判断である。

ルール4：CLAUDE.mdとprogress.mdを必ず作る。
これがあれば、セッションが切れても次の会話で「どこまで進んだか」をAIに伝えられる。

ルール5：本番に触れる前に必ずdry-runを実施する。
dry-runとは「実際には送らない・投稿しない・課金しない」状態でテストすることである。これを省略しない。

参考：既存対策ファイルとの対応関係