ステージ3 — 共同構築 (Co-Construction)
計画を承認することで制御力を保ち、実装はエージェントに丸ごと任せる。
このステージの目的
意図とコンテキストが用意できたら、このステージの役割はそれを実際の成果物へ移すことだ。ここで人間がやることはコードを直接書くことではなく、方向を制御することだ。エージェントが提案した計画を承認する関門一つで結果を予測可能な範囲に縛り、実装という反復作業そのものはエージェントに全面的に任せる。この境界が崩れると、人間はコードを一行ずつ検討して速度を失うか、計画なしに実装を任せて制御を失う。
実行順序
- 作業を独立に検証可能な単位に分解する。 一つの単位はそれ自体で完了の可否を判断できねばならない。複数のファイルにまたがっていても「この単位が終わった」を独立に確認できないなら、さらに分割する。
- エージェントに計画を提案させる。 意図文書とコンテキスト資産を根拠に、何をどの順序でどう実装するかをエージェントにまず計画させる。
- 人間が計画を承認する — このステージが関門だ。 コードではなく計画を読み、方向が合っているか、抜けている単位はないか、リスクの大きい領域に触れるかを確認する。承認が形式的なクリックにならないためには、計画を自分の言葉で要約してエージェントに問い返して確認する。要約がずれるなら計画の問題である以前に理解の問題であり、理解できない計画は承認しない。承認なしに実装へ移らない。
- エージェントが実装する。 承認された計画の範囲内でエージェントがコードを書く。計画になかった変更が必要になれば、別途承認を取る。
- 単位ごとに自己点検する。 実装が終わった単位ごとにエージェント自らテストを回すか成果物を再確認し、次の単位へ移る前に最低限の信頼を確保する。
成果物
- 承認された実装計画 — セッションログや計画文書として残す
- 実装されたコードと単位ごとの自己点検記録
計画自体を別ファイルとして残さないとしても、何が承認されたかはコミットメッセージやPR説明から追跡可能でなければならない。
完了基準チェックリスト
- [ ] すべての作業単位が独立に検証可能なサイズに分割されている
- [ ] 実装前に計画が提案され、人間が明示的に承認した記録がある
- [ ] 承認されていない範囲の変更が混ざっていない
- [ ] 並列で進めた単位間の衝突がworktreeやブランチ分離で隔離されている
- [ ] 各単位ごとに最低限の自己点検(テスト実行など)が行われた
よくある誤り
- 計画なしにいきなり実装を指示する。 「これ作って」で始めるとエージェントは隙間を勝手に埋め、結果を検討する段になって初めて方向が間違っていたと気づく。
- 巨大な単一作業単位で進める。 一つの承認で数十のファイルが一度に変わると、計画承認が事実上無意味な形式的手続きに堕する。
- エージェントの出力を読まずに承認する。 計画であれ実装結果であれ、目を通さずに「はい、いいですね」で流すと、関門は存在するが機能しない。
Claude Codeなら
TIP
plan modeで始めると、エージェントがコードを書く前に計画を先に提示し、人がその計画を承認して初めて次のステージへ進む。この流れ自体がステージ3の関門を道具のレベルで強制する。
独立した単位が複数あればサブエージェントを並列に実行して同時に進められる。このとき同じ作業ディレクトリを共有すると衝突するので、git worktreeで各エージェントの作業空間を隔離したうえで、完了した単位から順にマージする。