Claude Codeに「ちょっとリファクタしといて」と頼んだら、頼んでもないファイルまで書き換えられて青ざめた経験、ありませんか。私も最初は「ついでに直しておきました」のオンパレードで、git diffを見るたびに胃が痛くなっていました。
そんな悩みを物理的に解決するのがplan modeです。読み取り専用で計画だけを立てさせる仕組みなので、AIの暴走を未然に防げます。私自身、複数ファイルにまたがる改修ではplan modeを必ず通すようにしてから、手戻りが体感で半分以下になりました。
この記事では、Claude Codeを日常的に使っているエンジニア向けに、plan modeの正体・4つの起動方法・実践テクニック・落とし穴までを実体験ベースで解説します。読み終える頃には「いつ・どう使うか」の判断軸が手に入っているはずです。
Claude Codeのplan modeとは？3分でわかる結論
plan modeとは、Claude Codeを「読み取り・調査・計画」だけに制限する特殊モードです。ファイル編集もコマンド実行も発生しないので、AIが勝手にコードを書き換える事故をゼロにできます。
つまり、いきなり実装させるのではなく「設計レビュー」を挟むイメージです。複数ファイルに影響する改修や、本番に近い環境を触る作業で特に効きます。
plan modeの定義と「読み取り専用」の本質
plan modeはClaude Codeに搭載されている権限モードの1つで、書き込み系のツール(Edit・Write・Bashの破壊的コマンド)を全て無効化します。代わりに使えるのは、Read・Grep・Glob・WebFetchといった調査系ツールだけ。
「読み取り専用」と聞くと制約のように感じますが、これは制約ではなく安全装置です。プロンプトを書き間違えても、コードベースに傷を残さない。私はこの性質を「Claude Codeのドライラン」と呼んでいます。
通常モード・accept editsモードとの違い
Claude Codeには大きく3つのモードがあり、権限の強さが段階的に違います。表で並べると違いが一目でわかります。
| モード | 編集 | Bash実行 | 承認 | 向いている場面 |
|---|---|---|---|---|
| plan mode | 不可 | 不可 | 計画提示時に1回 | 設計レビュー・本番影響あり |
| 通常モード | 可 | 可 | 都度確認 | 普段使い |
| accept edits | 可 | 可 | 自動承認 | 使い捨てスクリプト |
accept editsは「全部YES」で進むので速い反面、暴走リスクが高い。plan modeはその真逆で、最初に計画を承認するまでは絶対に何も動かないという棲み分けです。
なぜplan modeを使うのか｜3つの本質的メリット
plan modeのメリットは「事故防止」だけではありません。設計の質・チームレビュー・コストの3方向で効いてきます。私が現場で実感した順に並べると、次の3つです。
AIの「ついで修正」を物理的に防げる
通常モードでClaude Codeに依頼すると、頼んでない箇所まで「ついでに整えました」と書き換えられることがあります。意図的な親切なんですが、レビュー側からするとノイズでしかありません。
plan modeなら計画段階で「このファイルを触ります」と宣言される仕組みなので、想定外の変更を事前に削れます。私は一度、認証ミドルウェアの修正依頼で別モジュールのリネームまで提案されたことがあり、計画段階で気づけて事なきを得ました。
認識のズレを実装前に潰せる
AIとの認識ズレは、実装が進んでから気づくと致命傷です。500行書かれた後に「いや、そういう意味じゃなくて…」となるダメージは経験者ならわかるはず。
plan modeを通すと、設計図ベースで議論できます。「このクラス分割は要らないので削って」「テストはこっちの方針で」と、文字数で言えば実装の10分の1のやり取りで方向修正が完了します。
トークンとレビュー時間を節約できる
意外と語られないのが、トータルのトークン消費がむしろ減るという点です。失敗実装→ロールバック→再実装の往復を消せるので、平均すると安く済みます。
レビュー側の負荷も同じで、計画段階で承認するロジックなら、git diffを読む前に方向性の合意が取れている状態になります。チーム開発でClaude Codeを併用しているなら、ここの効果が一番デカいです。
plan modeの起動方法4パターン｜状況別の使い分け
plan modeへの入り方は1つではなく、4つの手段が用意されています。手軽さと再現性のトレードオフがあるので、シーンに応じて使い分けるのが正解です。
Shift+Tabで切り替える(最も手軽)
セッション中にShift+Tabを2回押すだけでplan modeに入れます。8割のケースはこれで済みます。
もう1回押すとaccept editsに進む3段階トグルなので、押しすぎ注意。プロンプト下部にモード表示が出るので、入力前に必ず確認する癖をつけておくと安心です。
/planコマンドで切り替える
プロンプトに/planと打つ方法もあります。ショートカットを覚えていない時や、リモートからSSHで繋いでいてキーバインドが効きにくい時に便利です。
# セッション中にplan modeへ移行
> /plan動作はShift+Tabと同じですが、コマンドなのでスクリプトや手順書に書き残せるのが利点です。
CLI起動時に--permission-mode planを指定
セッションの最初からplan modeで開きたい場合は、起動オプションを使います。
claude --permission-mode plan本番DBに繋がっているリポジトリや、CIから呼ぶヘッドレス用途で重宝します。「うっかり通常モードで開いて事故」という事象自体を防げるので、危険な作業ディレクトリではエイリアスを切っておくのもアリです。
settings.jsonでデフォルト化する
プロジェクト単位で常時plan modeにしたい場合は、設定ファイルに書き込みます。
{
"permissions": {
"defaultMode": "plan"
}
}チームで「ここはplanから入る」という規約を共有できるのが強みです。逆に個人の試行錯誤リポジトリで設定すると、毎回承認が走って邪魔になります。プロジェクトの性格で使い分けてください。
plan modeを最大化する5つの実践テクニック
plan modeは「ただ起動すればOK」ではなく、組み合わせ次第で精度が大きく変わります。私が日常的に使っている5つのテクニックを紹介します。
Extended Thinkingと組み合わせて精度を上げる
「think hard」「ultrathink」などの思考強化ワードをプロンプトに入れると、計画の解像度が一段上がります。複雑なリファクタリングでは、これを入れる入れないで提案の質が体感で2倍違います。
欠点はトークン消費が増えること。普段使いには重いので、設計レベルで悩ましい案件にだけ振りかけるのがコスパ的に正解です。
plansDirectoryで計画をGit管理する
承認した計画はファイルとして残しておけます。plansDirectoryを指定すると、自動的に指定パスへ保存される仕組みです。
PRに計画書を添付してレビュー資料にしたり、後日「なんでこう実装したっけ」と振り返るときの議事録として活きます。私は.claude/plans/に集約してGit管理しています。
CLAUDE.mdに前提条件を書いておく
毎回同じ説明をするのは時間の無駄なので、プロジェクトのルール・命名規約・ディレクトリ構成はCLAUDE.mdに書いておきます。plan modeは起動時に自動でこれを読むため、計画の前提が揃った状態でスタートできます。
逆にCLAUDE.mdが薄いプロジェクトでplan modeを使うと、「そのファイルは使ってませんよ」みたいな指摘を毎回しないといけません。投資対効果がデカい初期整備です。
サブエージェントと併用して並列調査する
大規模リポジトリで「どこに何があるか」を調べる時は、サブエージェント(Explore agent等)に分担させて並列調査するのが効きます。plan mode本体は計画立案に集中させ、調査はサブに任せる構成です。
これをやり始めてから、20万行クラスのコードベースでも10分以内に方針が固まるようになりました。並列度を上げるとトークンは増えますが、人間の待ち時間が短くなる方が価値が高い場面が多いです。
計画を承認前にClaude自身に批評させる
地味に効くのが「この計画の弱点を3つ挙げて」と続けて聞く技です。Claude Codeは自分の出力を冷静に評価するのが意外と得意で、こちらが気づかない穴を出してくれます。
セルフレビューを1ターン挟むだけで、実装後の手戻りが目に見えて減ります。コードレビュアーが社内に1人いると思って雑談感覚で投げるのがコツです。
plan modeを使うべき場面・使わなくていい場面
plan modeは万能ではなく、軽い作業に毎回挟むとオーバーヘッドになります。私の中での判断軸を共有します。
必ず使うべき｜複数ファイル横断・本番影響あり
3ファイル以上に影響する改修、認証・決済・DBスキーマ周り、初見のリポジトリで方針を立てる場面。ここはplan modeを通さないと事故率が一気に跳ね上がります。
「短いお願いで済む」と思った時ほど影響範囲がデカいケースが多いので、自分の中で「3秒迷ったらplan mode」とルール化しておくと判断が楽です。
使わなくていい｜単発調査・タイポ修正
「このREADMEのtypoを直して」「特定の関数の使用箇所を教えて」みたいな単発タスクは通常モードで十分。plan modeを挟むと承認1回分の手間が余計にかかります。
あと、お試しで挙動を確認したい新規ライブラリの素振り。ここでplan modeを使うと「動かして覚える」サイクルが回らないので逆効果です。
plan modeのよくある落とし穴と対処法
便利なplan modeにも、踏みがちな地雷があります。私が実際に踏んで痛い目を見た3つを共有しておきます。
計画を斜め読みで承認してしまう
plan modeの最大の罠は、承認画面で「だいたい合ってそう」とエンターを押してしまうことです。読まないなら使う意味がないのに、慣れてくるとサボりがち。
対処法は、計画を一度ファイルに保存してエディタで開く運用にすること。ターミナル上でスクロールしながら読むより、見落としが減ります。
セッション長期化でコンテキストが圧縮される
計画を立てた後、長々と雑談していると、コンテキスト圧縮で計画の細部が消えることがあります。実装に入った時に「あれ、計画と違うコード書いてる」となる典型パターンです。
対処は2つ。1つはplansDirectoryで計画を残してから新セッションで実装させる。もう1つは長時間セッションを避けて、計画と実装を別ターンに区切る運用です。
plan modeのまま実装に移らない
承認したつもりが、まだplan modeのままで「実装してください」と言ってもツールが動かない、というパターン。プロンプト下のモード表示を見逃すと10分くらい無駄にします。
対処は承認後にShift+Tabで通常モードへ戻すか、計画承認のUIから「進める」を選ぶ。気づかないうちにモードがズレている感覚は、慣れるまでは何度か喰らうので諦めも大事です。
よくある質問(FAQ)
plan modeに関して質問されることが多い項目をまとめます。詰まったらここから探してみてください。
plan modeでもbashコマンドは実行できる？
原則として実行できません。Bashツール自体が無効化されるため、lsのような読み取り系も含めて止まります。ファイル確認はReadやGlobで代替する設計です。
plan modeを抜けるショートカットは？
Shift+Tabをもう1度押すと通常モードに戻ります。計画を承認するフロー(「Yes, and start」など)を選んだ場合は、自動的に通常モードへ遷移する挙動です。
plan modeで使うモデルは変えられる？
変えられます。/modelコマンドで切り替え可能で、Opusを計画専用に当てるOpus Plan Mode的な運用もできます。計画だけ高性能モデル、実装はSonnetという二段構えは費用対効果が高いです。
VSCode拡張やヘッドレスでも使える？
使えます。VSCode拡張ではUI上のモード切り替えから選択でき、ヘッドレス利用時は--permission-mode planを起動オプションに渡せばOK。CI連携で安全に解析だけ走らせる、といった用途と相性がいいです。
まとめ｜plan modeは「急がば回れ」の最強ツール
plan modeは、Claude Codeを使う上で最もコスパの良い安全装置です。最初は「ひと手間増えて面倒」に感じますが、慣れると逆に「これなしで本番ブランチを触るの怖い」とすら思うようになります。
まずは今日のタスクで1回、Shift+Tabを2回押すところから始めてみてください。失敗してもファイルは無傷なので、気軽に試せます。慣れた頃には、plan modeなしの開発が考えられなくなっているはずです。
