はじめに
Claude Code のようなAIコーディングエージェントに実装を任せるとき、「仕様書を渡していきなり実装させる」のではなく、まず実装計画書を作らせて、それをレビューしてから実装させるという2段階のワークフローを試してみました。
実際に手元の改修案件（既存画面への機能追加）で、仕様書からClaude Codeに実装計画を作成させ、その計画をレビューしたうえで実装を実行させる、という流れを踏んでみたところ、思っていた以上にメリットが大きかったので、その内容を共有します。
2段階のワークフロー：計画作成 → レビュー → 実装
流れとしてはシンプルで、次の2段階に分けています。
- 仕様書（Excelの概要書）とベースにするコーディングルールを渡し、「実装計画を作成して。まだコードは書かないで」とプロンプトを投げる
- 出てきた実装計画（Markdown）を人がレビュー・修正指示し、OKを出したうえで「この計画に沿って実装して」と指示する
いきなり「実装して」と投げると、コード差分だけがどさっと返ってくるため、方針が正しいかどうかはコードを読み込んで初めて分かります。一方で計画を挟むと、コードを読まなくても「何を」「どこに」「どう変えるつもりか」を先に文章で確認できます。
「計画を作って」とだけ伝えると、そのまま実装まで進めようとすることがあります。「計画書の作成までで止めて」と明示するのがポイントです。
実際に出てきた実装計画のセクション構成
Claude Codeに作らせた実装計画は、だいたい次のようなセクション構成になっていました（実際のものを抽象化して再構成した例です（機能追加））。
# ○○画面 機能追加 実装計画
対象: ○○画面
## Context（背景・目的）
- どの画面にどんな機能を追加するか。
- 実装の背景と最終目標はなにか。 など
## 実装方針
### 1. ○○ボタンの追加
- 既存画面の構成を踏襲しつつ、既存UIに合わせて調整
- 種別ごとにアイコンの出し分け条件を明記
### 2. 不要表示の削除
- 削除対象のパネル・変数・呼び出し箇所を列挙
### 3. ポストバックの解消
- 現状のサーバー側ロジックをJavaScript側に移植する方針を明記
## 変更ファイル / 変更しないファイル（参照のみ）
## 確認事項（実装時の判断、方針として進めてよいか）
- 既存踏襲か新規実装か迷う点を、判断理由つきで列挙
## 検証方法
- ビルド確認
- 確認の手順を番号付きで列挙
このように、「背景」「方針」「変更範囲」「判断が分かれる点」「検証方法」が一枚のドキュメントにまとまっている状態です。
実装計画を挟むことで得られた6つのメリット
1. コードを読まずに方針レビューができる
実装計画は自然言語で書かれているため、差分を読み込まなくても「このアイコンはFAXの場合は出さない」「既存の共通処理はそのまま流用する」といった方針レベルの妥当性を確認できます。レビューのコストが大きく下がりました。
2. 手戻りを実装前に潰せる
計画段階で方針の誤り（例えば「本来は共通クラス化すべきところを個別ページに複製する方針になっている」など）に気づけると、コードを書き直すコストをまるごと避けられます。実装後にレビューで指摘するのに比べて、修正コストが桁違いに小さいです。
3. 「確認事項」として判断の分かれ目が可視化される
今回の計画には「確認事項（実装時の判断、方針として進めてよいか）」というセクションがあり、AIが実装方針として複数の選択肢がありうると判断した箇所が、理由つきで列挙されていました。これにより、人間が承認すべきポイントがどこかが明確になり、「勝手に決められて後で困る」という事態を防げます。
4. スコープが固定される
「変更するファイル」「変更しない（参照のみの）ファイル」が計画に明記されるため、実装時にAIが意図せず関係ないファイルまで触ってしまう、といったスコープの逸脱を事前に防げます。実装フェーズでのプロンプトも「この計画通りに」と一言で済むため、指示がぶれません。
5. 検証観点が実装前に言語化される
自動テストが無い改修では特に、「何を確認すれば実装が正しいと言えるか」を実装前に手順として洗い出しておけると、実装後の確認漏れを防げます。今回も、画面の見た目・機能ごとの確認手順が番号付きで列挙されており、そのまま受け入れテストの手順書として使えました。
6. ドキュメントとして残る
実装計画は実装後も「この改修で何をなぜ変えたか」を説明する資料として残ります。レビュー用の一時的なメモではなく、後から見返せる設計記録になる点も地味に便利でした。
うまく機能させるために意識したポイント
- 「まだ実装しないで」と明示する：計画作成の指示だけだと、そのまま実装まで進めようとすることがあるため、「計画書の作成までで止めて」と明確に伝えるようにしました。
- 既存コードを読ませてから計画を作らせる：仕様書だけでなく、参照元となる既存実装も読み込ませたうえで計画を書かせると、「既存の書き方・命名規則に合わせる」といった暗黙の方針まで計画に反映されました。
- 判断が分かれる点は聞かせる：「実装方針で複数の選択肢がありうる箇所は、確認事項として理由つきで列挙して」と依頼に含めると、前述の「確認事項」セクションが自然に出てくるようになりました。
- 計画をレビューしてから実装を指示する：計画に対して修正コメントを入れ、合意が取れた段階で初めて実装フェーズに進むようにしました。
まとめ
仕様書からいきなり実装させるのではなく、間に「実装計画書の作成」というワンクッションを挟むことで、レビューのしやすさ・手戻りの少なさ・スコープの明確さ・検証観点の言語化・ドキュメントとしての再利用性、といった複数のメリットが得られました。
特に既存踏襲のルールが多い改修や、自動テストが整っていない画面の改修では、「計画を人がレビューできる形で先に出させる」という一手間が、結果的に実装全体のスピードと安全性の両方を底上げしてくれる感触があります。AIコーディングエージェントを使った開発フローに、ぜひ取り入れてみてください。