Plan Mode（プランモード）とは？Claude Codeの読み取り専用モードで安全に計画立案する仕組み・使い方を完全解説

Q: Plan Modeから戻った後、計画を変更できますか？

承認後にユーザーが追加の指示を出せば、Claudeはそれに従って計画を修正します。途中で再度Plan Modeに戻ることも可能です。

Q: Plan Modeはどのファイルを読みましたか？

Claudeは計画提示の際、参照したファイルをReadツールの履歴として残します。Claude Codeのセッションログを確認すれば追跡できます。

Q: Plan Modeで計画を立てたあと、別のセッションで実装するには？

計画を含む会話ログをコピーするか、計画をMarkdownファイルとして保存しておく方法があります。新セッションでは保存した計画ファイルを参照させれば引き継ぎが簡潔です。

Plan Modeとは

Plan Mode（プランモード）とは、AnthropicのClaude Codeに搭載されている特殊な動作モードで、Claudeに「コードを変更せず、計画だけを立てる」よう強制する機能である。Plan Modeに入ると、Claudeは読み取り系のツール（Read・Grep・Globなど）と思考だけを使って現状を把握し、これから行う作業の手順をユーザーに提示する。コードの編集や破壊的なシェルコマンドは一切実行されない。

身近な例えで言えば、Plan Modeは「先に設計図を見せてから工事を始める大工」のような振る舞いだ。いきなり壁を壊し始めるのではなく、まず「ここを撤去してこの梁を入れます」と説明し、施主が承認してから初めて工具を握る。実務では、複数ファイルにまたがるリファクタや、本番に近いコード、データベーススキーマの変更など「失敗したくない」変更で重宝する。

Plan Modeの読み方

プラン・モード

プランニング・モード

Plan Modeの仕組み

Plan Modeに入ると、Claude Codeは内部的に「許可されているツール」のリストを切り替える。具体的には、ファイルを書き換えるEditツール、新規作成するWriteツール、状態を変えるBashツール（ファイル削除・git push・パッケージインストールなど）が無効化される。一方で、Read（ファイル読み取り）、Grep（検索）、Glob（パターン一致）、AskUserQuestion（質問）などの読み取り・対話系ツールはそのまま使える。重要なポイントですが、これは単なるプロンプトの工夫ではなく、ツール権限のレベルで強制されているため、Claudeが「うっかり」コードを書き換えることはありません。

Plan Modeへの入り方

Plan Mode起動の3つの方法

Shift+Tab×2
キーボード切替

/plan
スラッシュコマンド

Plan側パネル
デスクトップ版GUI

Plan Modeに入ると、画面下部のステータスバーに「⏸ plan mode on」と表示される。2026年4月14日にリリースされた新Claude Code Desktopでは、専用のPlan側パネルが追加され、計画と会話を並べて表示できるようになった。承認・却下のボタンも一画面で操作できるため、複雑な変更を視覚的に管理しやすい。実務では、Shift+Tab×2が最も素早いので、慣れてくるとこれを多用することになる。

Plan Modeを抜けるタイミング

計画が固まったら、ユーザーが明示的に承認することでPlan Modeを抜け、通常モードに戻る。承認の方法は、「approve」「進めて」などの自然言語、もしくはGUI版なら「Approve」ボタンを押すだけだ。Plan Modeを抜けたあとは、Claudeはたった今示した計画に沿ってEdit・Write・Bashなどを実行できる。覚えておきたいのは、計画と実行で別セッションになる必要はなく、同じ会話の中でモードだけが切り替わるという点だ。

Plan Modeの使い方・実例

基本的な使い方（Quick Start）

Claude Codeを起動して、Shift+Tabを2回押すか /plan と入力する。あとは普段どおりタスクを依頼すれば、Claudeは計画モードで応答する。

# Claude Codeターミナルでの典型的なPlan Mode利用フロー
$ claude
> [Shift+Tab x2 で plan mode on]
⏸ plan mode on
> ユーザー認証をJWTからセッションCookieに移行したい

[Claudeがコードを読んで分析]
[計画を提示: 1) 影響箇所のリスト 2) 移行手順 3) ロールバックプラン]

> approve

[Plan Mode解除、通常実装に移行]

よくある実装パターン

パターンA: 探索的リード（Read-Only Exploration）

> [Plan Modeで]
> このリポジトリの認証フローを把握したい。コードに触らずに整理して

[Claudeはファイルを読んで関係図を提示]
[ユーザーは内容を確認したらPlan Modeのまま終了。または通常モードに戻ってメモ作成]

向いているケース: 新しいコードベースに参加したばかりで全体像を掴みたい場合。Claudeに変更を加えさせたくないので安全。

避けるべきケース: 単なる関数定義の確認など、READMEを読めば済むレベルの軽い質問。Plan Modeを使うほどではない。

パターンB: 多ファイル横断リファクタの事前承認

> [Plan Modeで]
> ロギングをconsole.logからpinoライブラリに移行する。影響ファイルと手順を出して

[Claudeが grep で console.log を全件検索 → 移行手順を提示]
> approve and proceed
[Plan Mode解除 → 計画通りに実装]

向いているケース: 影響範囲が広く、全件確認してから着手したい変更。3ファイル以上にまたがる場合は基本これ。

避けるべきケース: 1ファイル1関数の局所的な修正。Plan Modeを使うとオーバーヘッドのほうが大きい。

パターンC: スキーマ変更・本番影響のある作業

> [Plan Modeで]
> usersテーブルにemail_verified_atカラムを追加する移行計画を立てて。
  既存データのバックフィル戦略も含めて

[Claudeが既存マイグレーションを読んで計画を提示]
[ユーザーが慎重にレビュー → 修正点を指示]
> approve final plan
[Plan Mode解除 → マイグレーションファイル作成]

向いているケース: DB マイグレーション、認証・認可の変更、APIの破壊的変更。事故ったら戻せない作業。

避けるべきケース: ステージング環境のお試し作業。スピード重視の場面でPlan Modeはノイズになる。

アンチパターン: Plan Modeを毎回必ず使う

# 過剰利用の例
- typoの修正を依頼 → Plan Modeで詳細計画 → 1行修正
- READMEの追記 → Plan Modeで構成案 → 数行追加

Plan Modeは「失敗したら高くつく変更」のための保険であって、すべての変更を計画フローに通すと開発速度が下がる。経験則として、変更が3ファイル以下・100行以下・テストで容易に検証できる範囲なら、通常モードのままで十分なことが多い。注意しておきたいのは、Plan Modeを濫用するとClaudeの計画提示が形骸化し、ユーザーも惰性で「approve」を連打する習慣がついてしまう点だ。

Plan Modeのメリット・デメリット

メリット

事故防止: 大規模変更が始まる前に内容を確認できる。本番影響のある変更でとくに価値が高い
不慣れなコードベースの把握: 読み取り専用で動くため、新人エンジニアが安心して質問できる
レビュー体験の向上: 計画の段階で議論できるので、実装後のリワークが減る
監査ログとして使える: 計画と承認が会話に残るため、誰がいつ何を承認したか追跡しやすい
セキュリティ上の安全弁: 機密ファイルを誤って書き換えるリスクをコードレベルで遮断する

デメリット

速度低下: 単純な変更でも一段階増えるため、生産性が落ちる場面がある
承認の形骸化: 毎回承認していると「読まずにOK」する習慣がつく可能性
計画と実装の乖離: Claudeが計画通りに動かないケースもごく稀にあり、過度に信頼すると裏切られる
学習コスト: いつPlan Modeを使うべきかの判断は経験を要する

Plan Modeと通常モード・サブエージェントの違い

Claude Codeには複数の「実行モード」がある。Plan Mode・通常モード・サブエージェントの3つは、特に混同されやすい。下記の比較表で整理する。

観点	Plan Mode	通常モード	サブエージェント
主な用途	計画立案・読み取り	通常の実装作業	特定タスクの委任
書き込み権限	なし	あり	設定次第
起動方法	Shift+Tab×2 / `/plan`	既定	Taskツール経由
セッション	同一セッション	同一セッション	独立セッション
典型的なシーン	大規模リファクタ事前確認	日常的な実装	大量ファイルの並列調査

つまり、Plan Modeは「同じ会話内で書き込み権限だけを止める安全弁」、サブエージェントは「別セッションでタスクを切り出す並列実行手段」。両者は併用可能で、Plan Modeで計画を承認したあと、実装フェーズでサブエージェントに細かい調査を投げる、といった使い方も実務では多い。

Plan Modeに関するよくある誤解

誤解1: 「Plan Modeに入ればClaudeが絶対にコードを書き換えない」

なぜそう誤解されるのか: 「Plan＝計画」という名前から、Plan Modeを抜けるまでClaudeが完全に手を出さないと考える人が多い。また、ステータスバーの「⏸」アイコンが「停止中」のように見えるため、より強い保証だと感じてしまう。実際には承認後に通常モードに戻る仕組みである。

正しい理解: Plan Modeはあくまで「現在のターン」だけ書き込みを止める仕組みで、ユーザーが承認して通常モードに戻れば、Claudeは普通にコードを書き換えられる。書き込みを永続的に禁止したい場合は、Plan ModeではなくClaude Codeのsettings.jsonでツール権限を制限するのが正しい方法だ。

誤解2: 「Plan Modeはコードレビュー機能と同じ」

なぜそう誤解されるのか: 「人間が承認するまで先に進まない」フローはGitHubのプルリクエスト（PR）レビューに似ており、これと混同されやすい。「PRレビュー」「Plan Mode」ともに承認ボタンが出るため、見た目の類似が誤解を生む背景がある。

正しい理解: PRレビューは「すでに書かれたコード」を確認する仕組みだが、Plan Modeは「これから書くコードの設計」を確認する仕組みだ。実装が始まる前に方向性を直せるので、PRレビューよりもさらに上流のチェックポイントと言える。両者は補完関係で、どちらか一方では代替できない。

誤解3: 「Plan Modeは大規模変更でしか役に立たない」

なぜそう誤解されるのか: Anthropic公式ドキュメントが「3ファイル以上の変更で推奨」と書いているため、小規模な変更には不要と考える人が多い。実際にはコードベースに不慣れな人ほどPlan Modeの恩恵が大きく、規模ではなく「自分の理解度」で使い分けるべきという観点が見落とされやすい。

正しい理解: 実は1ファイル変更でも、コードの背景がわからない場合はPlan Modeで一度全体像を確認したほうが安全だ。新人エンジニアやOSSコントリビュータのように「コードベースの理解度が低いとき」ほどPlan Modeの恩恵が大きい。規模よりも「自分の理解度」を基準に使うのがコツだ。