「Claude に書かせたコードが設計の方向から違っていて、結局最初から書き直してもらう」— この手戻りでトークンを溶かしてしまった経験は、多くの方に覚えがあるのではないでしょうか。私自身、初期は「まず動くものを作ってから直す」スタイルで使っていましたが、案件が複雑になるほど、この進め方は明らかに割に合わなくなりました。
その転機になったのが Claude Code の Plan Mode です。機能説明だけ読むと「実行する前に計画を見せてくれるモード」という地味な印象ですが、実務に組み込むと、トークン消費・レビュー負担・やり直しの回数が目に見えて減ります。ここではPlan Mode を設計フェーズとして独立させる使い方を、具体的なプロンプトとともに紹介します。
Plan Mode とは何か — 普通の実装モードとの違い
Plan Mode は、Claude Code がコードを書き始める前に「これから何をどう実装するか」の計画を提示し、承認を待つモードです。起動方法はシンプルで、Shift + Tab を2回押して ⏸ plan mode に切り替えるだけです（/exit-plan で解除）。
普通の実装モードとの違いは、単に「確認を挟むかどうか」ではありません。もっと本質的な差として、Plan Mode 中はファイルの書き込みや破壊的なコマンドを一切実行しません。読むだけの調査と、Claude の頭の中の設計だけが進みます。つまり「設計の壁打ち専用セッション」として分離できるのです。
この分離が効く理由は、後半で詳しく見ていきます。
Plan Mode に切り替えたい3つのタイミング
私が現場で Plan Mode を使うのは、ほぼ以下のいずれかに該当する場面です。
1つ目は、機能追加の初手。新機能や新しい画面を作るとき、いきなり src/ に触り始めると、既存コードのどの層に挿し込むかで方針がブレます。Plan Mode で「既存のどのファイルを使うか」「新規で切るファイルは何か」「テストはどこに置くか」を先に固めると、実装後の「やっぱり別のモジュールに移したい」がほぼ消えます。
2つ目は、リファクタリング前。壊してはいけないテスト、移行順序、互換性の維持範囲など、事前に合意すべきことが多い作業です。Plan Mode であれば書き込みが発生しないので、「影響範囲をリストアップさせる → 移行順序を交渉する → 承認する」という手順を安心して踏めます。
3つ目は、バグ修正で原因の仮説が複数ありそうなとき。原因特定の前に修正コードを書かせてしまうと、仮説のうち1つだけを検証したログが残り、他の仮説の検討が省略されがちです。Plan Mode なら「まず3つの可能性を調査して、それぞれの確度を述べてください」と頼めるので、検討の抜け漏れを減らせます。
良い計画を引き出すプロンプトの型
Plan Mode を起動しても、「いい感じにお願い」だけでは、抽象的なTODOが返ってくるだけで手戻り削減には直結しません。私が落ち着いたのは、以下の4点をセットで渡すスタイルです。
# Plan Mode での依頼テンプレート
## ゴール
（1〜2文で、機能の受け入れ基準。ユーザー視点で書く）
## 制約
- 既存の型定義を壊さないこと
- 依存追加は package.json の変更を含む場合のみ提案する
- テストは <既存テストの置き場> に追加する
## 調査してほしいこと
- 既存の <類似機能> がどう実装されているか（読むべきファイルを列挙）
- 影響範囲（この変更で触るべきファイル／触ってはいけないファイル）
## 出力して欲しいもの
1. 実装方針（100文字以内）
2. 変更するファイルの一覧と、それぞれの役割
3. テスト計画
4. リスクとトレードオフ（少なくとも1つ）このテンプレートの肝は、最後の「リスクとトレードオフを1つは述べさせる」です。これを明示しないと、Claude はほぼ確実に「問題ありません、計画通り進められます」と答えてきます。無理やりにでもトレードオフを書かせると、現場の知恵で止めるべき設計の粗が浮かび上がります。
Plan Mode を抜ける前に確認する3つのこと
計画を読んで承認ボタンを押す前に、私は以下の3点を必ずチェックしています。
まず 変更ファイルの一覧に「読むだけ」で済むファイルが含まれていないか。Plan Mode は調査と実装の境目が曖昧になりやすく、「参照のために読む」だけのファイルが変更予定に混ざることがあります。ここで気づかないと、無駄な差分でPRが膨らみます。
次に テスト計画に具体性があるか。「既存テストを実行します」だけで済ませている計画は、実装後に「テストを書き足そうとしたら既存の構造と合わず手戻り」が頻発します。どのテストファイルに、どんなケースを追加するかまで落ちているかを確認します。
最後に 破壊的変更の影響範囲が言語化されているか。API シグネチャの変更、環境変数の追加、マイグレーションなど、「他の開発者にも影響する変更」の説明が計画に含まれていなければ、その場で追加で聞き直します。
よくある落とし穴と対処
Plan Mode を使い始めた当初、私が何度もぶつかった失敗が3つあります。
1. 計画が長すぎて読まれない
Plan Mode を歓迎するあまり、毎回大作の計画を出力させてしまうケースです。結論として、1000文字を超える計画は実務で機能しません。テンプレートで「実装方針は100文字以内」と縛っているのはこのためです。長い計画が必要な大規模変更では、フェーズを分割して複数回に分けた方が結果的に速く進みます。
2. Plan Mode で調査しすぎて実装セッションのコンテキストが薄くなる
Plan Mode 中に大量のファイルを読ませると、その情報がコンテキストに入ったまま実装モードに戻ります。一見良さそうですが、実装時に最も必要な「いま書いているファイルの直近の文脈」が相対的に薄まり、精度が落ちることがあります。計画フェーズで読むファイルは、本当に判断に必要なものだけに絞るのが良いようです。Claude Code の長時間セッションで精度を保つ方法で触れた「コンテキスト劣化」は、Plan Mode の使いすぎでも発生します。
3. Plan Mode を抜けた直後に別の話題を混ぜる
計画を承認した直後に「ついでに〇〇も直しておいて」と追加指示を入れると、Claude はその指示を計画外の追加作業として扱うか、計画自体を更新し直すかで迷います。計画は承認した時点で「凍結されたスコープ」として扱い、追加は別の Plan Mode セッションに回すのが結果的に手戻りが少ないです。
Plan Mode とパーミッションモードの組み合わせ
Plan Mode と、Claude Code のパーミッションモード（auto / ask / plan）は混同されがちですが役割が異なります。パーミッションモードは「どのツール呼び出しに確認を挟むか」の設定で、Plan Mode は「実装前に計画を合意するモード」です。両者を組み合わせる実務的な運用は、Claude Code Permission Modes 完全攻略で詳しく書きました。
ざっくりの使い分けとしては、「設計が不透明な段階 → Plan Mode」「設計は決まっていて実装の手数を減らしたい → auto パーミッション」と覚えておくと迷いません。
また、Plan Mode で合意した計画は、承認後のセッションにそのまま引き継がれます。長時間の実装セッションでも、計画で固めた方針を参照し続けられるように、Claude Code セッション管理完全ガイドで紹介しているセッション命名を活用すると振り返りがしやすくなります。
次の一歩
Plan Mode は「機能を知っている」と「実務で効果を出している」の間に、意外と距離がある機能です。この距離を埋める最短ルートは、次に取り組むプルリクエストで、コードを1行も書かせる前に Plan Mode を起動することです。上のテンプレートを貼り付けて、返ってきた計画の粗を指摘する作業を一度やってみると、その後の実装フェーズの速度と精度の違いを体感できるはずです。
「計画を一度も出させずにコードから書き始めていた昨日までの自分」との差が、一番分かりやすい効果測定になります。