（メタ説明/要約） 複雑な案件ほど"全体計画→詳細計画→実装→振り返り"の粒度を間違えると迷走します。本稿では、Claude Code と Codex を組み合わせた「フェーズ承認制（Phase-by-Phase Approval）」運用を紹介。全体は骨子だけ、フェーズ単位で計画→承認→実行→AARのループを回すだけ。プロンプトの即使いテンプレと、逸脱を防ぐガードも付けています。
この記事で解決できること
- 大規模・複雑な開発で、AIエージェントの"暴走"や"やり直し地獄"を防ぐ
- 設計〜実装〜学びの流れを、常にフェーズ単位で可視化する
- 承認の単位を明確化して、意思決定とロールバックを楽にする
結論：やることは"これだけ"
- 全体計画は骨子だけ作らせる（承認しない）。
- フェーズXの詳細計画を作らせる。
- フェーズ単位で承認→実行→AAR（事後報告）。
- 次フェーズへ。同じループを繰り返す。
ポイントは「全体を細かく決めない」。実行承認は必ずフェーズ単位に限定します。
なぜ迷走するのか（背景）
- 全体計画の解像度が高すぎる：初期の"仮説"に過剰拘束され、環境差異や依存のズレで崩壊。
- 承認の境界が曖昧：どこまでOKなのか不明で、AIが"親切"に範囲外まで動く。
- 事後報告が散在：ログがない／差分が粗い／成果物の"所在"が曖昧で、再現・ロールバックが難しい。
フェーズ承認制は、承認の粒度をフェーズに固定して、上記をすべて潰します。
Claude Code × Codex：役割の切り分け
- Claude Code（作業者） 実装・編集・コマンド実行。各ステップ前に「実行予定」を宣言し、あなたの合図で1ステップずつ進む。
- Codex（参謀） 設計レビュー、代替案、リスク指摘、チェックリスト。基本は Analyze-onlyで開始し、必要時のみRead許可。
この二人体制で、「手を動かす」と「考える」を分離。衝動的な実装を防ぎます。
運用フロー（標準ループ）
0) 全体計画＝骨子だけ（承認しない）
- フェーズは3〜6個に分解。
- 1フェーズ＝「目的→主要成果物→主要リスク」だけ。
- 実装手順やファイル名はここに入れない。
1) フェーズ計画（詳細化）
- 入力（前提/必要ファイル/環境）
- 出力（成果物/変更対象/成功判定テスト）
- 手順（最大7ステップで一行ずつ）
- リスクと回避策（3つ以内）
- 所要時間の相対見積（S/M/L）
2) 承認→実行（Claude Code）
- 各ステップ前に「実行予定コマンド／編集対象／差分の要旨」を宣言。
- 毎ステップ停止→"続行"合図で再開。
- スコープ外に触れそうなら即停止して質問。
3) AAR（事後報告）
- 実行ログ（実コマンド、変更ファイル、差分の要旨）
- 成果物の所在（パス/ブランチ/ビルド出力）と起動確認方法
- 想定と実測の差（時間/難易度）
- 学び（次フェーズに活かす1点）
- 次フェーズへの前提条件チェック（満/不満）
コピペで使えるプロンプト集
全体計画（骨子のみ：誰にでも最初に投げるやつ）
この案件の全体計画を"骨子だけ"提示してください。
- フェーズは3〜6個に分解
- 各フェーズは一行で「目的→主要成果物→主要リスク」を記述
- 実装手順・コマンド・具体ファイル名は禁止（骨子のみ）
最後に「承認待ち：はい」を付けて出力
フェーズ計画の要求（詳細化）
フェーズ《X》の詳細計画を作成。
含めること：
1) 入力（必要ファイル/前提/環境）
2) 出力（成果物/変更対象/成功判定テスト）
3) 手順（最大7ステップ、各1行で）
4) リスクと回避策（3件以内）
5) 所要時間の相対見積（S/M/L）
ここでは実装・編集は禁止。最後に「承認待ち：はい」を付けて。
承認と実行指示（Claude Code向け）
フェーズ《X》の詳細計画を承認。範囲外の作業は禁止。
各ステップの前に、必ず
- 実行予定コマンド
- 編集対象ファイル
- 差分の要旨
を宣言してから着手。毎ステップで停止し、私の「続行」で次へ。
完了後はAAR（実行ログ/成果物の所在/起動確認/想定vs実測/学び/前提条件チェック）を提出。
参謀レビュー（Codex向け）
フェーズ《X》の詳細計画をレビュー。
以下4点を簡潔に：
- 見落としやすい依存関係
- 競合する手段（代替案は1つまで）
- ロールバック案
- テストの宿題
実装は禁止。
逸脱ガード（Claude Code向け）
以下に該当する場合は即停止して報告→質問：
- 変更予定外のファイルに影響が出る
- テストが失敗して暫定修正が必要
- 見積（S/M/L）を1段階以上超えそう
報告フォーマット：
「停止理由→想定リカバリ→私への質問」
フェーズ「完了条件」チェックリスト
- 成果物の所在が具体（パス/ブランチ/出力ディレクトリ）
- 検証手順が自走可能（指示をコピペ実行で再現できる）
- ロールバック一行方針がある（例：
git checkout -p/revert等の具体） - 外部依存（API鍵・CI設定等）の準備責任と手順が明記
- テスト結果がYes/Noで判定できる
よくある失敗と回避
- 全体計画が詳細すぎる → 骨子に制限。「目的/成果物/リスク」以外はフェーズで初めて書く。
- フェーズ計画の言葉が曖昧 → 「整備する・準備する」は禁止。何をどこに置くかを書く。
- 参謀に案を出させすぎる → 代替案は常に1つまで。意思決定を鈍らせない。
- 実装の連続自動進行 → 毎ステップ停止をプロンプトで強制。合図がない限り進ませない。
ミニFAQ
Q. 全体計画を承認しないのはなぜ？ A. 序盤の"仮説"を未来にまで引きずらないため。環境や要求は動く。承認はフェーズ単位が正義。
Q. フェーズの粒度は？ A. 1〜2日で終わる規模が扱いやすい。長くても1週間以内を目安に分割。
Q. ログや差分の粒度は？ A. 「何を、どこで、どう変えたか」が人間に追える最小単位。ファイル名と差分の要旨は必須。
Q. CodexにReadをいつ渡す？ A. "参謀の洞察が足りない"と感じた時だけ一時的に。常時Readは与えないのが原則。
導入のコツ（すぐ効く3点）
- テンプレを固定：本稿のプロンプトをそのまま使う。
- 停止ポイントを明示：毎ステップ停止は"運用ルール"として宣言。
- AARを資産化：AARは次フェーズの前提条件に直結。履歴＝設計知として残す。
まとめ
- 全体は骨子だけ。承認しない。
- フェーズ計画→承認→実行→AARのループだけで進める。
- Codexは参謀、Claude Codeは手を動かす実装者。
- スコープ逸脱は即停止→質問。
- 成果物の所在・検証・ロールバックを常に明文化。