なぜClaude Codeへの一括依頼は破綻するのか｜フェーズ分割の設計
Claude Code に長い作業を一度に頼むと、途中から前提が崩れ、手戻りに追われることがある。これはモデルの能力不足ではなく、工程設計の不在が原因だと考えている。長いタスクを成果物・ゲート条件・停止規約で刻み、各区切りで人間の承認を挟む——本稿はその「フェーズゲート方式」を、筆者が実際に運用しているゲート定義と承認履歴の実物とともに整理する。
一括依頼が破綻する構造
「設計から実装まで一気にやって」と頼むと、モデルは計画と実装を同時に進める。このとき最初のほうで置いた前提が一つ誤っていると、その誤りに乗って後続のコードが積み上がる。人間が気づく頃には複数のファイルが書き換わっており、どこまで戻せば正しい状態に着地するのかが分からなくなる。手戻りのコストは、進んだ距離に比例して膨らむ。
もう一つの破綻要因が「先回り実装」である。まだ確定していない後工程を、モデルが良かれと思って先に書いてしまう。仕様が固まる前のコードは、確定後にほぼ捨てることになる。つまり一括依頼の失敗は、モデルが賢くないから起きるのではなく、途中で立ち止まって前提を確認する仕組みが無いから起きる。刻めば防げる問題を、刻まずに丸投げしていることが本質である。
フェーズゲートの構成要素
フェーズゲート方式は、長工程を複数のフェーズに割り、各フェーズの末尾に「ゲート」を置く。要素は三つである。
第一に成果物。各フェーズは「進捗」ではなく、ファイルやドキュメントという確認可能な実体を必ず一つ産む。設計フェーズなら設計文書、調査フェーズなら調査ノート、といった具合に、次のフェーズが依存できる形で残す。
第二にゲート条件。フェーズを通過してよい条件を、可能な限り機械検証できる形で先に書いておく。たとえば開発中の別プロジェクト（Claude Code のセッションログビューワ）では、索引構築フェーズのゲートをこう定めている。
実データ全量で索引構築が完走、再構築の冪等性確認、pytest（壊れ行・巨大行・未知 type）通過
「だいたい動く」ではなく、実データ全量・冪等性・テスト通過という、YES/NO で判定できる条件になっている点が要である。
第三に停止規約。ゲートを人間が承認するまで、モデルは次のフェーズに手をつけない。同プロジェクトの停止規約は次のとおり。
現在フェーズは docs/phase-plan.md の記載が正。フェーズ外の先回り実装は禁止（例: Phase 1 中に API エンドポイントを書かない）
加えて、ゲート審査はレビュー専用のサブエージェントを実装セッションとは別コンテキストで走らせ、その結果を添えて人間の承認を得る。生成した本人が自己採点しない構造にすることで、承認の質を保っている。
実例 — 記事制作ワークストリームのゲート
この記事を含む doand.tech の記事制作は、それ自体がフェーズゲート方式で回っている。ワークストリームはリポジトリ適応 → サイト要件整備 → 素材インベントリ → 記事計画 → 記事サイクルという段で構成され、各段の末尾に G0a・GB・G0・G1・記事ゲートが置かれている。
たとえば記事1本を公開判定にかける「記事ゲート」の条件は、docs/hub-articles/articles-phase-plan.md に次のように定義されている。
記事ゲート条件（記事ごと・人間承認）
- [ ] コード・コマンド例がすべて code-example-contract 準拠（抜粋元パス or 検証記録あり）
- [ ] 揮発情報（モデル名・CLI・設定キー）に確認日、frontmatter に verified_env
- [ ] 内部リンクがすべて解決表内
- [ ] 外部既出と本文が重複していない（reviewer が照合）
- [ ] reviewer の blocker 指摘ゼロ、文字数が目安 ±30% 以内いま読んでいるこの記事も、公開前にこの5項目で審査される。ゲート条件が具体的であるほど、審査は主観論争ではなく照合作業になる。
承認の記録は、会話の中に流さず成果物側に残す。同ファイルの進捗表はこうなっている（メモ列は省略）。
| ゲート | 状態 | 承認日 |
|---|---|---|
| G0a（適応） | 承認 | 2026-07-15 |
| GB（サイト要件） | 承認 | 2026-07-16 |
| G0（素材） | 承認 | 2026-07-16 |
| G1（計画） | 承認 | 2026-07-16 |
| 記事 01〜12 | 未 | |
| 中間（6本） | 未 | |
| 審査リクエスト | 未 |
この表のとおり、計画（G1）までは承認済みで記事はまだ「未」——本稿はその記事フェーズの成果物として書かれている。承認履歴をファイルに残すのは、セッションをまたいで作業を再開できるようにするためでもある。同ワークストリームの再開規約はこう定めている。
再開時に読むのは本ファイル＋直近フェーズの成果物のみ。会話履歴に依存しない。承認記録は下の進捗表に追記する。
会話履歴が消えても、フェーズ計画と直近成果物さえあれば文脈を復元できる。ゲートと成果物は、暴走を止めるだけでなく、長期の作業を継続可能にする土台でもある。
運用で見えた失敗パターン
方式を運用していると、崩れ方にも型があることが分かってきた。
一つ目はゲート飛ばし。承認前に次フェーズのコードを書き始めてしまうと、停止規約が空文化する。これは前述の「フェーズ外の先回り実装は禁止」を明文でルール化しておくことで抑える。
二つ目は承認の形骸化。未達の項目を曖昧にしたままゲートを「なんとなく通す」と、後で必ず崩れる。開発中の別プロジェクト（メディアサイト）では、機械検査 → コンプライアンスレビュー → 人間承認 → 日付追記、という手順をコマンド化し、条件付きで通す場合は保留事項を明示的に列挙している。実際のログには「未達・別途（ゲート保留事項）」として、CI の前提やデプロイ戦略の実機確認待ちが残されていた。通す／通さないの二択にせず、何が残っているかを可視化することで、なし崩しの通過を避けている。
三つ目は計画の黙示的変更。作業を進めると当初のゲート条件が現実に合わなくなることがある。このとき条件を勝手に緩めず、計画変更もゲートを通す。同プロジェクトでは、フェーズのゲート条件自体を見直した際も、計画ファイルを人間承認を得て改訂してから先に進めている。ゲートを守る運用と直す運用の両方に承認を挟むことが、方式を形だけにしない条件だと考えている。
よくある質問
小さなタスクでもゲートは要るのか。 不要である。1コミットで戻せる作業に承認を挟むのは過剰で、かえって速度を落とす。刻む価値は、手戻りコストが承認コストを上回る長工程でこそ出る。
Plan Mode との違いは。 Plan Mode は着手前に計画を提示して承認を得る Claude Code のモードである（2026-07-16 時点）。対してフェーズゲートは、計画・実装・検証を複数回くり返し、その各回に成果物と停止を置く運用そのものを指す。両者は排他ではなく、各フェーズの入口で Plan Mode を使うと相補的に働く。
まとめ
Claude Code への一括依頼が破綻するのは、モデルの能力ではなく工程設計の問題である。長工程を成果物・ゲート条件・停止規約の三点で刻み、各ゲートで人間の承認を挟めば、暴走は止まり、手戻りは局所化し、作業はセッションをまたいで継続できる。ゲート条件は機械検証できる形で先に書き、承認履歴は成果物側に残す——これが方式を形骸化させないための要点である。フェーズの入口で使う「計画一式を先に生成する」スキャフォールド駆動や、モデル・effort の配分については別記事で扱う。