← Reports へ戻る

Claude Codeに変更計画だけ出させる方法

Published 2026年6月22日
Author AI Media Lab
Category ai-technology

いきなり編集させず、変更計画・影響範囲・対象ファイルを先に出させる安全な進め方。計画承認ステップが品質と安全性を大きく向上させます。

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 ポイント

人間が計画を評価するポイント

チェックリスト

計画を受け取ったら、以下をチェックしてください：

計画を修正するステップ

計画に問題が見つかった場合：

「計画ありがとうございます。以下の修正をお願いします：

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 との協働が大きく安全になります。

Claude Codeプロセス計画確認安全性