Claude Codeに変更計画だけ出させる方法
はじめに
Claude Codeを安全に使うための最も重要なテクニックは、計画と実装を分離することです。本記事では、「計画フェーズ」でAIに何を出させるか、人間がどう判断するかを詳しく解説します。
なぜ計画フェーズが必要か
計画なしの危険性
❌ 悪い流れ：
「xxx機能を実装してください」
↓
Claude Code が複数ファイルを一度に編集
↓
git diff が 500 行以上
↓
何が変わったか理解できない
↓
テスト失敗したら原因不明
計画ありの安全性
✅ 良い流れ：
「変更計画を出してください（実装は後）」
↓
Claude Code が計画を提示
↓
人間が「この計画で大丈夫か？」を確認
↓
修正が必要なら計画の段階で指示
↓
計画承認後に実装
↓
実装は計画通りで予測可能
計画フェーズで出させるべき内容
テンプレート
タスク: 以下の計画を提示してください。実装はしないでください。
【変更が必要なファイル】
- （ファイル一覧）
- それぞれなぜ変更が必要か
【影響を受ける関数・クラス】
- 変更される側
- 変更による副作用の可能性
【既存テストへの影響】
- 既存テストはそのまま通るか
- 新しいテストが必要か
- テスト項目の提案
【実装ステップ】
- どの順番で変更するか
- ステップごとの git commit イメージ
- リスク（実装中に破綻する可能性）
【代替案の検討】
- この方法以外に実装する方法はあるか
- 各々のメリット・デメリット
具体例1：リファクタリング
タスク: 計画を提示してください。実装はしないでください。
背景: src/utils/validation.ts の validateEmail()、validatePhone()、validatePostal() が
同じパターンを繰り返しており、重複が多い。
要件: 共通パターンを抽出して、コード重複を削除したい。
計画を以下の形式で出してください：
【分析】
- 共通パターンは何か
- 各関数で異なる部分は何か
- 既存テストがカバーしている範囲
【実装案】
- 基本的な実装戦略
- ファイルは追加か既存か
- 各関数をどう変更するか
【テスト戦略】
- 既存テストは全て通るか
- 新しいテストが必要か
- 注意すべき edge case
【リスク】
- この方法で破綻する可能性
- 代替案
具体例2：新機能追加
タスク: 計画を提示してください。実装はしないでください。
要件: ユーザープロフィールに「自己紹介」フィールドを追加したい
スコープ:
- データベーススキーマ
- API エンドポイント（追加と既存の修正）
- フロントエンド（表示と編集フォーム）
- バリデーション
計画を以下の形式で出してください：
【データベース】
- 既存テーブルの修正内容
- migration の内容
- rollback 方法
【バックエンド】
- 新規 API エンドポイント or 既存エンドポイント修正
- バリデーション（文字数制限、XSS 対策など）
- エラーハンドリング
- テストケース
【フロントエンド】
- UI コンポーネントの追加または修正
- フォーム validation
- 文字数カウント表示の有無
【非機能要件】
- ローカライゼーション対応（必要か）
- 監査ログ（必要か）
- 権限チェック（必要か）
【段階的デプロイ】
- フェーズ 1：DB + バックエンド
- フェーズ 2：フロントエンド（新しい API に対応）
- 各フェーズの git commit ポイント
人間が計画を評価するポイント
チェックリスト
計画を受け取ったら、以下をチェックしてください：
- ファイル一覧に漏れがないか
- 影響を受ける関数が全て把握されているか
- 既存テストが全て通るか明示されているか
- リスク（破綻の可能性）が列挙されているか
- 代替案が検討されているか
- 実装順序に依存関係はないか（並行実装可能か）
- 各 commit が小さく分割できるか
- セキュリティ（入力検証、権限、SQL injection など）が考慮されているか
- パフォーマンス（N+1 問題、キャッシュなど）が考慮されているか
計画を修正するステップ
計画に問題が見つかった場合：
「計画ありがとうございます。以下の修正をお願いします：
1. validateEmail の既存テストを 確認してから実装
2. 新しい共通パターン抽出関数はファイル内に作成（別ファイルなし）
3. テストは既存テスト maintenance のみ（新しいテストは不要）
修正後の計画を提示してください。まだ実装はしないでください。」
計画承認後の実装
計画が確定したら、実装フェーズに進みます：
「上記の計画で実装をお願いします。
確認事項：
- git commit は計画で示された通り
- 各 commit ごとに git diff を確認できるサイズ
- テストは全て通る状態
完了後、git diff --stat を含めて完了を報告してください。」
よくある質問
Q: 計画を何度も修正する必要が出ました。これは正常ですか？
A: 正常です。計画フェーズでの修正は、実装後の修正よりはるかに安いです。実装後に大規模修正になるよりは、計画の段階で何度でも修正しましょう。
Q: 複数のファイルを一度に編集する場合、計画は必須ですか？
A: はい。ファイルが増えるほど、計画の重要性は増します。3つ以上のファイルに跨る変更は、必ず計画フェーズを挟んでください。
Q: 計画フェーズにどのくらい時間がかかりますか？
A: 数分から 30 分程度です。実装後に問題が見つかって修正する時間と比べると、遙かに短いです。
まとめ
Claude Codeで失敗しやすい指示の多くは、計画フェーズで防げます。
計画フェーズの効果：
- 予測可能性: 実装後のサプライズが減る
- 品質向上: 設計上の問題を実装前に修正
- テスト戦略: 必要なテストが見落とされない
- リスク低減: 破綻の可能性を事前に検討
ポイント：
- 実装前に必ず計画を出させる
- 「実装はしないでください」と明示
- 計画が承認されてから実装
git diff で小さく確認すると組み合わせることで、Claude Code との協働が大きく安全になります。