Claude Codeに指示を出すと、すぐにファイルの編集やコマンドの実行が始まります。しかし、大規模なリファクタリングや設計判断が必要な場面では、いきなりコードを変更されると困ることがあります。/planコマンドを使えば、Claude Codeを「分析・設計のみ」のモードに切り替え、実際のファイル変更なしに計画を立てられます。
この記事でわかること
大規模なリファクタリングや設計判断が必要な場面で、コード変更なしにAIと計画を立てる方法を解説します。/planコマンドを使えば、影響範囲の分析から実行計画の作成まで、安全に設計フェーズを進められます。
- /planコマンドの仕組みと、通常モードとの違い — /planは、ClaudeCodeに「コードの変更や副作用のある操作を一切行わず、分析と計画の提示のみを行う」よう指示するコマンドです。
- 大規模リファクタリングやアーキテクチャ変更を安全に計画する手順 — 数十ファイルに影響するリファクタリングを、いきなり実行するのはリスクが高い作業です。
- チームレビュー用のプラン共有と、計画→実行のワークフロー — /planの出力結果は、チームメンバーとの設計レビューに直接活用できます。
対象読者: チーム開発で設計レビューを重視するエンジニア、大規模な変更前に影響範囲を安全に分析したい方
/planコマンドとは
/planは、Claude Codeに「コードの変更や副作用のある操作を一切行わず、分析と計画の提示のみを行う」よう指示するコマンドです。
通常のClaude Codeは、指示を受けると即座にファイルの編集、コマンドの実行、テストの実行といったアクションを起こします。/planモードでは、これらの実行を抑制し、「何をどう変更すべきか」の設計書だけを出力します。変更の影響範囲が大きい作業や、チームでレビューしてから実行したい場面で威力を発揮します。
基本的な使い方
planモードの有効化
/plan
/planと入力すると、以降のClaude Codeの応答が「計画モード」に切り替わります。このモードでは、ファイルの読み込みや分析は行いますが、ファイルへの書き込みやコマンドの実行は行いません。
planモードでの指示
/plan このNext.jsプロジェクトをPages RouterからApp Routerに移行する計画を立ててください
引数として分析・設計の対象を指定します。Claude Codeは対象のコードベースを読み込み、移行ステップ、影響範囲、注意点を含む計画を出力します。
通常モードとの比較
| 項目 |
通常モード |
/planモード |
| ファイルの読み込み |
実行する |
実行する |
| コードの分析 |
実行する |
実行する |
| ファイルの編集 |
実行する |
実行しない |
| コマンドの実行 |
実行する |
実行しない |
| テストの実行 |
実行する |
実行しない |
| 出力内容 |
変更結果 |
計画・設計書 |
/planモードでもファイルの読み込みと分析は行われるため、実際のコードベースに基づいた精度の高い計画が得られます。机上の空論ではなく、実コードを踏まえた実行可能な計画です。
実務での活用パターン
パターン1: 大規模リファクタリングの事前計画
数十ファイルに影響するリファクタリングを、いきなり実行するのはリスクが高い作業です。/planで事前に全体像を把握してから実行に移ります。
Before(planなしで直接実行):
「認証ロジックをsrc/auth/に集約してください」と指示すると、Claude Codeが即座にファイルの移動・編集を開始。途中でimportパスの修正漏れが発生し、ビルドエラーが連鎖する。
After(/planで事前計画):
/plan 認証ロジックをsrc/auth/に集約する計画を立ててください。移動対象ファイル、影響を受けるimportパス、テストファイルの修正箇所を一覧にしてください
Claude Codeが出力する計画:
- 移動対象: 8ファイル(具体的なパス一覧)
- 影響を受けるimport: 23箇所(ファイルパスと行番号)
- テスト修正: 5ファイル(モックパスの変更)
- 推奨実行順序: Step 1〜4の段階的移行
この計画をレビューしてから、通常モードで「この計画に従って実行してください」と指示することで、漏れのない安全なリファクタリングが可能になります。
パターン2: 技術選定・アーキテクチャ設計
新機能の実装前に、複数のアプローチを比較検討する場面で活用します。
Before(planなしで直接実行):
「状態管理を導入してください」と指示すると、Claude Codeが特定のライブラリ(例: Zustand)を選択して即座に実装を開始。後からRedux Toolkitの方が適切だったと判明し、やり直しになる。
After(/planで比較分析):
/plan このプロジェクトに状態管理を導入する場合、Zustand、Redux Toolkit、Jotaiの3つのアプローチを比較してください。既存コードとの親和性、学習コスト、バンドルサイズへの影響を含めてください
Claude Codeが出力する比較:
| 観点 |
Zustand |
Redux Toolkit |
Jotai |
| 既存コードとの親和性 |
高い(hooks中心の設計と合致) |
中程度(ボイラープレート追加が必要) |
高い(atom単位で段階導入可能) |
| 影響ファイル数 |
12ファイル |
18ファイル |
8ファイル |
| バンドルサイズ増加 |
+2.9KB |
+11.2KB |
+3.5KB |
この比較結果をチームで議論し、合意の上で実装に進めます。
パターン3: バグの影響範囲調査
本番環境でバグが報告された際、修正前にバグの影響範囲を正確に把握する必要があります。
Before(planなしで直接修正):
「このバグを修正してください」と指示すると、Claude Codeが表面的な症状だけを修正。根本原因が別の箇所にあり、数日後に別の形で同じバグが再発する。経営データの可視化やコンテンツマーケティングを含め、Claude Codeの業務活用に関心のある方はぜひ参考にしてください。
After(/planで影響範囲調査):
/plan src/api/users.tsのgetUser関数でnullが返るバグについて、根本原因と影響範囲を調査してください。同じパターンが他のファイルにも存在するか確認してください
Claude Codeが出力する調査結果:
- 根本原因: データベースクエリの結果がundefinedの場合のフォールバック処理が欠落
- 同一パターンの存在箇所: 5ファイル(具体的なパスと行番号)
- 推奨修正方針: 共通のnullチェックユーティリティを作成し、5箇所すべてに適用
根本原因と影響範囲を把握した上で修正に着手することで、再発を防ぐ包括的な修正が可能になります。
計画から実行へのワークフロー
/planで作成した計画を、実際の実装に移すためのワークフローです。
Step 1: /planで計画を作成
/plan [作業内容の説明]
Step 2: 計画内容をレビュー
出力された計画を確認します。以下の観点でチェックします。
| チェック項目 |
確認内容 |
| 影響範囲 |
変更対象のファイルと行数は妥当か |
| 実行順序 |
依存関係を考慮した順序になっているか |
| リスク |
破壊的変更やデータ損失のリスクはないか |
| テスト |
テストの追加・修正が考慮されているか |
| ロールバック |
問題発生時の復旧手順は明確か |
Step 3: 計画を修正(必要に応じて)
計画に不足や修正がある場合は、/planモードのまま追加の指示を出します。
/plan Step 2のデータベースマイグレーションについて、ロールバックスクリプトも計画に含めてください
Step 4: 通常モードで実行
計画が確定したら、通常モードに戻して実行を指示します。
先ほどの計画に従って実行してください。Step 1から順番に、各ステップ完了後に結果を報告してください
チームレビュー用のプラン共有
/planの出力結果は、チームメンバーとの設計レビューに直接活用できます。
プルリクエストの事前設計
大きな変更をプルリクエストとして提出する前に、/planで設計を固めておくと、レビュアーの負担が軽減されます。
/plan この機能追加について、プルリクエストの説明文として使える形式で計画をまとめてください。変更の背景、技術的アプローチ、テスト方針を含めてください
出力された計画をそのままプルリクエストのdescriptionに使えます。
設計ドキュメントの自動生成
/planの出力を整形して、ADR(Architecture Decision Record)やRFC形式のドキュメントにすることも可能です。
/plan 認証基盤のリアーキテクチャについて、ADR形式(Status、Context、Decision、Consequences)で計画を整理してください
関連コマンドとの組み合わせ
/plan + /compact の大規模分析
大規模なコードベースを分析する際、/planの出力がコンテキストを圧迫することがあります。/planで計画を作成した後、/compactで分析途中のログを圧縮し、計画の要点だけを残して実行フェーズに移るフローが効果的です。
/plan + /diff の変更確認
計画に基づいて実装した後、/diffで実際の変更内容を確認し、計画通りに実装されているかを検証します。計画と実装のズレを早期に発見できます。
/plan + カスタムコマンド
よく使う計画テンプレートをカスタムコマンドとして定義しておくと、チームで統一された計画フォーマットを運用できます。例えば.claude/commands/plan-migration.mdに「マイグレーション計画テンプレート」を定義しておけば、/plan-migration Pages Router → App Routerのように呼び出せます。
あわせて読みたい
まとめ
/planコマンドは、Claude Codeの「考えてから動く」を実現する機能です。大規模リファクタリング、技術選定、バグの影響範囲調査など、いきなりコードを変更すべきでない場面で、ファイル変更なしに設計と計画を立てられます
実践にあたっては、以下のポイントを押さえておくことが大切です。
- 計画をチームでレビューしてから実行に移すワークフローを導入することで、手戻りのリスクを大幅に削減し、変更の品質と安全性を両立できます
- *Claude Codeの全コマンド一覧はClaude Codeチートシートをご覧ください
- AI活用の全体像はAI活用完全ガイドで解説しています
よくある質問(FAQ)
Q1. /planモードでもファイルの読み込みは行われますか?
はい、行われます。/planモードはファイルの「書き込み」とコマンドの「実行」を抑制しますが、ファイルの読み込みと分析は通常通り行います。そのため、実際のコードベースに基づいた精度の高い計画が得られます。
Q2. /planで作成した計画を、そのまま実行させることはできますか?
できます。/planで計画を作成した後、通常モードに戻して「先ほどの計画に従って実行してください」と指示すれば、計画通りに実装が進みます。ステップごとに確認を入れたい場合は、「各ステップ完了後に結果を報告してください」と追加で指示します。
Q3. /planの出力が長すぎて読みきれない場合はどうすればよいですか?
/planの指示を具体的にすることで、出力範囲を絞れます。「全体の移行計画」ではなく「Step 1の認証モジュール移行のみ」のように、スコープを限定した指示を出してください。また、「箇条書きで簡潔にまとめてください」と出力形式を指定することも有効です。
Q4. /planは非エンジニアでも使えますか?
使えます。/planモード自体はコードを変更しないため、非エンジニアが「この機能を追加するとどのくらい影響がありますか?」といった調査目的で利用しても安全です。出力内容は技術的になりますが、Claude Codeに「非エンジニアにもわかる形式で説明してください」と追加指示することで、わかりやすい形式にできます。Claude Codeの非エンジニア活用については「Claude Codeの導入ガイド」も参考にしてください。