Claude Codeで最近やってること：/investigate→/plan→/implement→/test の4フェーズ開発
mizoiです。
最近の開発は Claude Code を相棒にしていて、雑に指示すると破綻しがちなので、4フェーズで分けて進める運用に落ち着きました。
結論、これにしてから
- 目的がズレにくい
- 変更がでかくなりにくい
- テストまで辿り着く確率が上がる
の3つが改善しました。
なぜフェーズ分けが効くのか
Claude Codeは強いんですが、いきなり「これ実装して」だと
- 前提を誤解したまま進む
- 影響範囲が広がる
- テストが置き去りになる
が起きやすいです。
そこで 人間がやってる開発の流れを、そのままコマンドとして固定化します。
自分の運用：4フェーズの役割
1) /investigate（調査）
目的：現状把握と影響範囲の特定
ここでは「コードは書かない」。代わりに以下を出させます。
- 関連ファイル一覧
- 現状の挙動（どこで決まってるか）
- 変更すると壊れそうな箇所（依存）
- 最小の修正ポイント候補
例プロンプト
- 「このバグの原因をコードベースから調査して、関係ファイルと原因候補を3つ挙げて」
- 「この機能追加で影響が出る画面/API/モデルを洗い出して」
2) /plan（設計）
目的：やることを小さく分割して順序を決める
ここで「実装タスク」を粒度小さめにします（PR単位くらい）。
- 変更内容（箇条書き）
- 差分が出るファイル
- 既存仕様と矛盾しないか
- エッジケース
- テスト観点（後で効く）
例プロンプト
- 「上の調査結果を元に、最小変更で実装する計画を作って。手順とファイル単位の差分案を出して」
- 「リスクがある箇所と、回避策も書いて」
3) /implement（実装）
目的：計画通りにだけコードを書く
ここで初めて実装。重要なのは「盛らせない」こと。
- 計画にない改善は入れない
- 差分を小さく
- コミットしやすい塊で
例プロンプト
- 「planの手順1だけ実装して。差分は最小で。変更理由もコメントで残して」
- 「必要なら既存の命名規則に合わせて」
4) /test（検証）
目的：壊れてないことを確認して、次の手に繋げる
ここを独立させるだけで「テストしない」をかなり防げます。
- 追加/更新すべきテスト（unit/widget/e2e）
- 手動確認手順（チェックリスト）
- 想定される回帰ポイント
- ログ確認ポイント
例プロンプト
- 「この差分で必要なテスト観点を列挙して。手動確認チェックリストも作って」
- 「CIで落ちそうなところを先に教えて」
実際に回すときのテンプレ（コピペ用）
/investigate
- 目的：◯◯を直す/追加する
- 現象：◯◯が起きる
- 期待：◯◯になるべき
- 制約：既存仕様は壊さない、差分最小、影響範囲を先に洗う
/plan
- 方針：最小変更 / 影響範囲限定
- 手順：1.〜 2.〜 3.〜
- 変更ファイル：
- テスト：unit / widget / 手動
/implement
- planの手順1だけ
- 追加の改善提案は今回は不要（別PR）
/test
- 影響範囲の回帰チェック
- 手動チェックリスト
- 必要ならテスト追加
よくある失敗と対策
-
いきなりimplement → 調査が抜けて爆発
→ investigateを必須にする -
planがふわっとしてる → 実装が盛られる
→ “ファイル単位”で差分を固定する -
testが後回し → 結局やらない
→ testフェーズを独立タスクにする
さいごに
この4フェーズ運用は、Claude Codeに限らず「AIコーディング全般」で効く型だと思ってます。
次は、自分の実例（バグ修正 or 機能追加）をこの流れで丸ごと紹介してみる予定です。