Claude Code Plan Modeの使い方｜手戻りを防ぐ計画術

Claude CodeのPlan Modeは、いきなり実装を走らせたときに意図と違うコードが大量に入り、数十ファイルの手戻りに追われる失敗を避けるための読み取り専用モードです。
実際に全面やり直しになった経験があると、先に計画を固めてから進める価値はすぐに腑に落ちます。
起動も手軽で、Shift+Tabを2回押すか/planと打てば入り、画面下部に⏸ plan mode onが出るので、前提知識がなくてもすぐ試せます。
explore→plan→implement→commitの流れに組み込めば、計画を読んで承認する習慣が身につき、承認(yキー)の直前に確認する姿勢まで自然に整うでしょう。

Plan Modeとは何か：実装前に計画を立てる読み取り専用モード

Plan Modeは、Claude Codeの権限モードの中でも読み取りに徹する設定です。
ファイルの探索や内容確認はできますが、編集や書き込み、状態を変える操作は行わず、実装の前に計画だけを固めます。
だからこそ、既存コードを壊す不安を抱えずに、今ある構成を安全に見渡せます。

通常モード・auto-acceptモードとの根本的な違い

通常モードは、内部で方針を考えたらすぐに動き出し、最初の書き込みで許可を求める流れです。
auto-acceptモードはその確認すら飛ばして、編集を前提に前進します。
Plan Modeはその対極にあり、まず文章で計画を見せ、承認が出るまで止まる。
この停止が、ただの遅さではなく、方針を合わせるための余白になるのです。

承認前の段階ではEdit・Writeツールがロックされます。
つまり、Claudeは現状を把握したうえで実装方針を整理し、ユーザーがGOを出すまで一切の変更を入れません。
意図を取り違えたまま大量のコードを書かれて、レビューより書き直しのほうが時間を食った場面では、この差がそのまま効いてきます。
先に文章で確認できれば、直す場所は設計の段階にとどまりやすいでしょう。

読み取り専用だからこそ既存コードの調査に向く

Plan Modeの強みは、読むことに集中できる点です。
ファイルの読み取りと探索だけに絞られているので、依存関係の確認、設定の流れ、複数ファイルのつながりを落ち着いて追えます。
20ファイル規模の改修でも、まず全体像を見てから当たり所を決められるため、場当たり的に手を入れて壊す心配がありません。
調査の精度が上がるほど、実装の迷いは減っていきます。

また、承認するまでコードは1行も変わりません。
この「変えない時間」があるから、既存挙動を壊しやすい境界や、見落としやすい例外条件を先に洗い出せます。
Plan Modeで方針を文章として固めたあと、実装が一発で通って体感の速度が逆に上がる、そんな成功談は珍しくないはずです。
急がば回れ、である。

なぜ計画フェーズが手戻りを減らすのか

手戻りが減る理由は、方向修正のタイミングが実装前に来るからです。
書き始めてから違和感に気づくと、直すのはコードだけではありません。
レビューの往復、差分の巻き戻し、説明のやり直しまで発生します。
Plan Modeなら、その負担を計画の段階へ押し戻せます。

運用の核は、explore→plan→implement→commit の流れにPlan Modeを組み込むことです。
大規模変更ほど、次の30分以内に実装できる粒度へ計画を分けておくと、判断がぶれません。
さらに、実装前に方針を揃えておけば、複数ファイルのリファクタリングでも着手後の迷走を避けやすくなります。
走り出す前に揃える、この一手が効くのです。

Plan Modeの起動と解除：Shift+Tabと/planコマンド

Plan Modeは、Claude Codeで「読むだけ」に切り替えてから実装方針を固めるためのモードです。
読み取りと探索だけに限定されるので、EditやWriteでコードを書き換える前に論点を洗い出せます。
先に計画を文章で確認できるぶん、20ファイル規模の改修でも手戻りを抑えやすい流れになります。

Shift+Tabでモードを循環させる

最も手軽なのは、セッション中にShift+Tabを押して切り替える方法です。
押すたびにAsk before edits、Edit automatically（auto-accept）、Plan modeの順で循環するため、Plan modeが出るまで続けます。
初回に1回だけ押してauto-acceptに入ってしまい、そのまま編集が走って焦ったことがありますが、Plan modeに入る前の段階だと読み取り専用にはまだなっていません。

起動に成功すると、ターミナル下部に⏸ plan mode onと表示されます。
ここが現在モードを見分ける唯一の確実な目印なので、切り替え後は必ず目視で確認しましょう。
Edit・Writeツールがロックされ、承認するまでコードは1行も変わらないので、方針が固まる前に誤った変更が広がる心配がありません。

/planコマンドで直接入る方法

キーボード操作がやりにくいなら、入力欄に/planと打つだけでPlan Modeに入れます。
手順書やスクリプトにそのまま書き起こしやすく、再現性を保ちやすいのも利点です。
Plan Modeでは現状のコードを読み、実装案を文章としてまとめ、承認待ちの状態で止まります。

この「先に考えてから動く」流れが、なぜ手戻りを減らすのかは明快です。
計画フェーズで方向修正できれば、巨大な差分を一気に書き進めてから崩れる場面を避けられます。
承認の前に論点が見えるので、実装より先に設計の粗さを潰していけるでしょう。

起動できないときのフォールバック

Windowsでは、Shift+Tabがautoとdefaultしか循環せず、Planが出ない不具合が報告されています。
その場合は/planに切り替えるのが確実です。
v2.1.0以降ならAlt+Mでも代替できるので、ショートカットが通らない環境でも止まりません。

解除は、もう一度Shift+Tabを押してデフォルト状態に戻すだけです。
実装を始めたいタイミングで素早く抜けられるため、Plan Modeで方針を固めたあと、そのままAuto側へ移って作業を進めやすくなります。
Windowsで何度押してもPlanにならず、/planコマンドに切り替えて解決した実例もあり、困ったときほど入力方式を変える発想が役に立ちます。

計画を承認する4つの選択肢の使い分け

計画が出たら、まず危険度で進め方を分けます。
信頼できる定型作業なら auto mode で一気に始め、変更の確認を挟みたいなら accept edits、初見の重要変更なら各編集を手動確認しながら進めるのが安全です。
承認の押し方ひとつで実行のされ方が変わるので、勢いで選ばず、どこまで機械に任せるかを先に決めておきましょう。

auto / accept edits / 手動確認の選び方

auto mode は、すでに流れが読めていて、途中で止める必要がほぼない作業に向きます。
実装の型が固まっている修正や、細部より速度を優先したい場面ではおすすめです。
accept edits は、提案された変更をまとめて受けつつ開始したいときに使いやすく、計画の筋道は認めるが細部の暴走は避けたい、という場面に合います。
各編集を手動確認しながら開始するモードは、初回の大きな改修やテストが絡む案件で選ぶべきで、途中で止めて軌道修正しやすいのが利点です。

auto mode で承認した直後、想定外にテストファイルまで書き換えられて冷や汗をかいたことがありました。
あのときは「動くならよい」と思って押したのが失敗で、確認を挟まない承認は変更範囲を見誤りやすいと痛感しました。
安全策は単純で、定型なら auto、初見なら手動確認、という割り切りです。
迷うなら後者を選びましょう。

計画をその場で修正してから実行する

計画に引っかかる点があれば、その場で「ステップ3を〜に変更」と伝えて再計画させてから承認します。
全体を否定する必要はなく、1か所の修正だけで結果が整うことは少なくありません。
実際、ステップを1つ直しただけで、余計な差分が消えて実装の見通しが一気に良くなったことがあります。
承認は腹落ちしてからで遅くないのです。

Ctrl+G が使えるなら、承認前に計画をエディタで直接直してから実行できます。
長い計画ほど、文言の1行差が実装の大差になります。
細部を整えてから進めるほうが、あとで直す手間は小さくなるでしょう。

yキー承認前に必ず確認すべきこと

yキーを押した瞬間に計画の全変更が一気に実行されるため、本文を読まずに承認すると誤りまでまとめて入ります。
確認すべきなのは、変更対象が想定したファイルだけか、テストや補助ファイルまで触れていないか、そして意図しない置換が混ざっていないかの3点です。
ここを見れば、あとで戻す作業をかなり減らせます。

承認前は、計画全体を1回読むだけで済ませず、気になる行を指で追ってみてください。
少しでも違和感が残るなら、そこで止めるのが正解です。
勢いで y を押すより、1分長く見直すほうが結果的に速い。
こういう場面では、慎重さこそ近道になります。

explore→plan→implement→commitワークフローの実践

Plan Modeは、調査・計画・承認・実装を順番に踏ませることで、手戻りを実装前に吸収する進め方です。
Boris Chernyの使い方でも、まずPlan Modeで開始して既存コードを読み、計画を往復で詰め、固まった段階でauto-acceptに切り替えてから実装させる流れが標準になります。
ほとんどのセッションをこの形で始めるだけで、意図ずれはかなり早い段階で見つかるでしょう。

explore：既存コードを調査させる

最初のexploreでは、Plan Modeのまま既存コードを読ませます。
読み取り専用の段階で関連ファイルの構造、呼び出し元、影響範囲をつかめるため、まだ触っていないコードに対して不用意な変更を入れずに済みます。
いきなりimplementから入ると、仕様の入口だけ見て進めてしまい、後から別のモジュールに波及していたと気づくことがありました。
exploreを挟むと、その事故が目に見えて減ります。

ここでのポイントは、正解を急がないことです。まず現状を把握し、その場で判断材料を揃える。そうしてから次へ進むだけで、実装の精度は上がるのです。

plan：計画を往復で詰める

planでは、調査結果をもとに計画を出させ、それを往復で詰めます。
一発で完璧な計画は出ないので、修正指示を返し、再計画させ、必要ならさらにもう一度詰める。
三往復ほど重ねると、実装の順序、変更対象、確認観点がかなり具体的になり、どこで崩れやすいかまで見えてきます。
ここで承認を急がないことが、後の安定性を決めます。

実際、長い実装を三往復で固めてから渡したときは、auto-acceptに入った後の作業が最後まで手戻りなく進みました。
途中で迷いが出ないので、実装は速いし、修正のための差し戻しも起きにくい。
ポイントは3つ。
計画を文章で明確にすること、曖昧な前提を残さないこと、そして承認前に違和感を潰し切ることです。
そこまで詰めてから進めればよいでしょう。

implement→commit：auto-acceptに切り替えて実装・確定

計画が固まったら、ここで初めてauto-acceptに切り替えてimplementへ進めます。
Boris Chernyの典型的な運び方でも、Plan Modeで開始し、計画を往復で詰めたあと、実装段階だけを自動化するのが自然です。
切り替えのタイミングを前倒ししないことが肝心で、承認前に書き換えを走らせると、検討中の前提までコードに焼き付いてしまいます。
commitはその最終確定であり、実装の結果を固定する段階だと考えるとわかりやすいです。

この流れを続けると、Plan Modeは単なる確認モードではなく、実装の品質を上げるための入口になります。
ほとんどのセッションをPlan Modeから始めるだけで、実装前に意図ずれを潰せる。
結果として、後戻りの少ない進め方が習慣になるのです。

大規模変更で手戻りを防ぐ計画の作り方

20ファイル規模の機能を1つの計画に詰め込むと、途中でコンテキストが埋まり、最初に置いた前提と後半の判断が噛み合わなくなります。
だからこそ、計画は30分以内に実装できる粒度へ切り、Plan Modeを複数回に分けて進めるのが有効です。
大きな変更ほど、最初から最後まで一気通貫で考えようとしないほうが、むしろ一貫性は保ちやすくなるのです。

計画は30分で実装できる粒度に区切る

1セッションで全機能をまとめて計画させたとき、途中から指示がぶれた経験があると、分割の意味がよくわかります。
最初は設計の筋が通っていても、会話が長くなるほど細部の整合性を取るための余白が減り、論点の優先順位まで崩れやすいからです。
そこで、次の30分以内に手を動かせる範囲だけを1チャンクにし、終わったら次のPlan Modeへ進める運用に変えると、論点が散らずに済みます。
おすすめです。

この切り方の利点は、作業単位が小さいことではなく、各チャンクの前提が新鮮なまま保たれる点にあります。
ひとつの計画に詰め込みすぎると、比較したい選択肢や未解決の制約が積み上がっていきますが、30分単位なら「今この場で決めること」だけに焦点を絞れるでしょう。
複雑な機能ほど、複数のPlan Modeセッションに分けて進めてみてください。

extended thinkingで設計判断を深める

Plan Mode中にAlt+T、MacではOption+Tでextended thinkingを有効化すると、設計判断とエッジケースの掘り下げ方が変わります。
単に案を並べるだけでなく、どの境界条件で破綻するか、どこにトレードオフがあるかまで踏み込んで考えやすくなるためです。
アーキテクチャ変更では、この差がそのまま手戻りの少なさにつながります。

実際、アーキテクチャ変更の計画でthink harderを足したとき、見落としていた分岐条件を計画段階で拾えました。
実装してから気づくと修正範囲が広がりますが、設計の段階で拾えれば、後工程の迷いはほとんど残りません。
Plan Modeは「何をするか」を決め、extended thinkingは「どう考えるか」を深める。
この役割分担が噛み合うと、複雑な変更でも流れが整います。

thinkフレーズとPlan Modeを組み合わせる

「think harder + plan mode: 〜の移行戦略を作って」のように、思考フレーズと計画指示を一緒に置くと、深い推論と体系的な計画を同時に引き出しやすくなります。
特に移行戦略や土台の組み替えでは、順序、互換性、失敗時の戻し方が絡み合うため、単発の要件整理だけでは不足しがちです。
そこで、まず考え方を深くし、そのうえで計画を具体化する流れが効いてきます。

この組み合わせが優れているのは、思考の深さと進め方の明確さを別々に担保できるからです。
Plan Modeだけだと手順は見えても、判断の根拠が浅いまま残ることがあります。
逆に思考だけを深めても、実行順がぼやける。
両方を重ねると、設計の穴を見つけながら、30分単位で前進できる計画になるでしょう。
おすすめです。

計画書を残してコンテキストを節約する上級術

Plan Modeで残した計画はMarkdownとして保存され、既定では ~/.claude/plans に置かれます。
ランダム生成されるファイル名は形容詞・動名詞・名詞の組み合わせなので、あとから見返しても識別しやすいのが利点です。
会話の途中で計画が長くなっても、まずはファイルへ退避させるだけで流れが崩れにくくなります。

計画の保存先（~/.claude/plans）を把握する

Plan Modeで作った計画がどこに残るかを先に押さえておくと、運用は一気に安定します。
デフォルトの保存先は ~/.claude/plans で、Markdown形式のまま蓄積されるため、後から開いても構造が読みやすいままです。
会話の中で毎回再説明するより、最初から保存先を意識しておくほうが、計画の劣化を防ぎやすいでしょう。

ファイル名が形容詞・動名詞・名詞の組み合わせでランダム生成される点も見落とせません。
人手で名付け直さなくても、複数の計画を並べて管理しやすく、似た案件が増えたときの取り違えを減らせます。
長時間の作業では、名前があるだけで記憶の補助輪になるのです。

SPEC.md・plans/に書き出して再利用する

長い計画本文は、会話に置いたままだと後半で輪郭がぼやけやすくなります。
SPEC.md や plans/ ディレクトリへ書き出しておけば、計画を会話メモリから切り離せるので、コンテキストを節約しながら内容を保てます。
実際、長時間セッションで会話後半ほど方針がにじんだ経験があり、SPEC.md に逃がす運用へ切り替えてからは、手戻りが目に見えて減りました。

再利用しやすいのも強みです。
途中でセッションが切れても、計画書を読み込ませれば続きから再開できますし、実装途中で迷ったときも原点に戻れます。
ポイントは、計画を会話の流れではなくファイルに置くことだと考えておくことです。

計画書をチームで共有・引き継ぐ

ファイル化した計画は、個人のメモを超えて引き継ぎ資料になります。
何を変えるか、なぜその順番なのかが文書として残るため、レビューのたびに口頭で補足する負担が減ります。
チームメンバーが同じ方針で作業を続けやすくなり、属人化も抑えやすいでしょう。

リポジトリに計画書が残っていると、後から参加した人も判断の筋道を追えます。
別の人が見ても着地点が変わりにくいので、作業のぶれを小さくできます。
会話の熱量に頼らず、文書を軸に進めてみてください。

Plan Modeでよくあるつまずきと対処

Plan Modeは、読み取りと探索だけに作業を絞り込み、EditやWriteを通さずに計画を固めるためのモードです。
先に文章で手順と修正方針を提示して承認を待つので、20ファイル規模の改修でも途中で方向がずれにくくなります。
だから実装後のやり直しが減り、迷いなく作業を進めやすくなるのです。

Shift+TabでPlanに入れないとき

WindowsではShift+Tabを押してもautoとdefaultしか回らず、Planが出ない場面に何度も出くわしました。
画面の切り替えを待ちながら30分消えていき、ようやく /plan を打つと一瞬で解決したときの脱力感は強烈です。
v2.1.0以降ならAlt+Mでも確実に切り替えられるので、反応が鈍いときはキー操作を粘るより、モードを直接指定したほうが早いでしょう。

Plan Modeでは、表示される計画を読むところから始めます。
ここでEdit・Writeツールは使えず、コードは1行も動かないため、先に「どう直すか」を見てから進められるのが利点です。
操作前に画面下部の表示を見て、⏸ plan mode on になっているかを必ず確認してみてください。

Plan Modeを解除して通常作業に戻る

解除できない気がしても、もう一度Shift+Tabを押せばデフォルトに戻ります。
循環の順序を覚えておけば、どこで止まっているのかを見失いません。
モード表示を目視する習慣がつくと、Planのまま次の編集に進もうとして戸惑う回数が減ります。

承認の前後で挙動が変わる点も見落としやすいところです。
Planでは文章で提案し、yキーで承認した瞬間に実行へ進みます。
止めたいタスクがあるなら、最初から各編集を手動確認するオプションで始めておくほうが安全です。

承認後の暴走を防ぐ事前設定

『承認したら止められない』のは仕様だと理解しておくと、操作が雑になりません。
yキーを押したあとに思い直しても、その場で全変更が走るため、事前に確認点を分けておく設計が効きます。
特に複数ファイルをまたぐ作業では、最初に調査対象のファイルを明示してから再計画させると、計画の密度が上がるでしょう。

計画が薄いと感じたら、extended thinkingを足すのも有効です。
Plan Modeはそもそも方向修正のための場なので、実装に入る前にズレを潰せます。
20ファイル規模の改修で戻り道を減らしたいなら、ここで一度立ち止まる使い方がいちばん。