Claude Codeのplanモード（プランモード）とは？切り替え方・使い方・活用例を解説

Claude Codeのplanモード（プランモード）は、Claudeに「調べて計画を立てるところまで」をさせ、ファイルの編集は計画を承認するまで行わせないモードです。Shift+Tab でモードを切り替えるか、プロンプトの先頭に /plan を付けると使えます。複数のファイルにまたがる変更や、初めて触るコードの調査など、やり直しの手間が大きい作業の前に使うと、手戻りを減らせます。

この記事では、切り替え方、計画を承認するまでの流れ、使うべき場面と使わなくてよい場面、便利な設定、注意点を、Anthropic公式ドキュメント（2026年10月10日確認）にもとづいて解説します。

関連記事Claude Code（クロードコード）とは？できること・料金・使い方を初心者にもやさしく解説【2026年版】 ／ Claude Code 使用量を完全制御する実装ガイド【2026年版】 ／ Claude Code ログイン方法・できない時の対処法｜2026年版ガイド

Claude Codeのplanモード（プランモード）とは

Claude Codeのplanモード（プランモード）は、Claudeがファイルを読み、必要に応じて調査用のシェルコマンドを実行して、変更の計画を書くところまでを行う動作モードである。ソースコードの編集は、利用者が計画を承認するまで行われない。

この分離が実用上の価値を持つ理由は、AIコーディングツールが陥りやすい典型的な失敗パターンに起因する。要件が曖昧なまま実装を開始したAIが、複数ファイルにわたる変更を蓄積し、後からロールバックするコストが増大する——という問題は、自律エージェントの実用上の制約として現場でも頻繁に確認されている。プランモードはこの問題に対して、「考える」フェーズと「実行する」フェーズを明示的に分けることで、人間のレビューポイントを構造的に確保する。

Anthropic公式ドキュメント（code.claude.com/docs/en/common-workflows.md）の”Plan before editing”セクションは、本機能の目的を「変更がディスクに触れる前に計画をレビューする（review changes before they touch disk）」と明記している。これが機能設計の一次情報として最も信頼できる根拠となる。

Claude Codeの全体像についてはClaude Code入門ガイド、インストール手順の詳細はClaude Codeインストール完全解説をあわせて参照されたい。

planモードの切り替え方と使い方

プランモードへの切り替え操作

プランモードへ切り替える方法は主に4つある。いずれもClaude Codeが起動している状態で操作する。

実際にShift+Tabを2回押すと、画面の下に「plan mode on」と表示されます（2026年10月5日、Claude Code v2.1.289で撮影）。

続けて「空のやることを追加できないようにしたい。どう直すか計画して」と頼むと、Claude Codeはファイルを読んで計画を作り、実行してよいかを確認してきます。この時点ではファイルはまだ書き換えられていません。選択肢は「Yes, and use auto mode」「Yes, manually approve edits」「Tell Claude what to change」の3つでした。

方法1：Shift+Tabキー
Shift+Tabを押すたびに、権限モードが順番に切り替わる。autoモードで始まったセッションでは、manual → accept edits → plan の順に進むので、画面下の表示が「plan mode on」になるまで押す。もう一度押すと、計画を承認せずにplanモードを抜けられる。

方法2：プロンプトの先頭に/planを付ける
1回の依頼だけをplanモードで進めたいときは、プロンプトの先頭に /plan を付ける。スラッシュコマンドの体系的な一覧はClaude Codeスラッシュコマンド一覧で確認できる。

方法3：起動時に指定する
claude --permission-mode plan で起動すると、最初からplanモードで始まる。

方法4：既定のモードにする
設定ファイルで defaultMode を plan にする（後述の「planモードの便利な設定」を参照）。

プランモードで実行する基本ステップ

公式ドキュメント”Common workflows”の”Plan before editing”セクションに基づき、実際の操作フローを整理する。

1. プロジェクトルートに移動し、claudeコマンドでClaude Codeを起動する
2. Shift+Tabまたは/planでプランモードへ切り替える
3. 実装したい機能・修正したいバグ・リファクタリング対象を自然言語で記述する
4. Claudeがコードベースを読み取り専用で調査し、変更計画（どのファイルの何をどう変えるか）を出力する
5. 計画を精査し、過不足があれば追加プロンプトで修正を指示する（ファイルは変更されないため何度でも反復できる）
6. 計画が固まったら、確認の画面で承認する。「Yes, and use auto mode」（承認してautoモードで実行）、「Yes, manually approve edits」（承認して、編集を1つずつ確認）、「No, keep planning」（計画を続ける）から選ぶ。承認するとプランモードを抜けて、実装が始まる

計画の確認画面で Ctrl+G を押すと、計画を既定のテキストエディタで開いて、直接書き換えてから進められる。

このフローの核心はステップ5にある。プランモード中はファイルが変更されないため、設計レベルの問題を実装後のロールバックコストを払わずに潰せる。計画を精緻化するための追加質問を重ねても、コードベースへの副作用が一切ない点がエンジニアリング的に重要である。

プロンプト設計の実例

以下にプランモードで実効性の高いプロンプトパターンを示す。指示の粒度と対象スコープを明示することが計画品質に直結する。

# 認証モジュールのリファクタリング計画
/plan
AuthServiceクラスをJWTベースからセッションベースに移行したい。
影響を受けるファイルと変更手順をステップ順に列挙してほしい。
テストコードへの影響も含めること。

# バグ修正前の原因調査
/plan
カート画面で商品追加時にNullPointerExceptionが発生する（スタックトレースは添付）。
原因ファイルと修正箇所の計画を出してほしい。修正は実行しないこと。

# 新機能追加の設計確認
/plan
RESTful APIに新しい/orders/exportエンドポイントを追加したい。
既存のrouter・controller・serviceレイヤーのどこに何を追加・変更するか、
依存関係も含めて計画を立ててほしい。

「修正は実行しないこと」という明示的な制約をプランモード内のプロンプトに加えることで、Claudeが計画提示に留まる意図をより確実に伝えられる。モードの切り替えとプロンプトによる指示の両方で意図を固めることが、実務での安全策として有効である。

planモードの便利な設定：既定にする・保存先を変える・計画だけ上位モデルにする

planモードを既定にする

あるプロジェクトのターミナルのセッションを毎回planモードで始めたい場合は、そのプロジェクトの .claude/settings.json で defaultMode を plan にします。

{
  "permissions": {
    "defaultMode": "plan"
  }
}

VS Code拡張機能から始める会話は、開始時の権限モードにプロジェクト設定を使いません。VS Codeのユーザー設定で claudeCode.initialPermissionMode を plan にします。

計画ファイルの保存先（plansDirectory）

planモードで書かれた計画はファイルとして保存されます。保存先は既定で ~/.claude/plans です。プロジェクトの中に置きたい場合は、設定の plansDirectory に、プロジェクトのルートからの相対パスを指定します。

{
  "plansDirectory": "./plans"
}

計画だけ上位モデルで考えさせる（opusplan）

モデルの指定に opusplan という別名を使うと、planモードの間は opus で考え、実行に移ると自動で sonnet に切り替わります。計画の段階では推論力の高いモデルを使い、実装は効率のよいモデルで進める、という組み合わせです。

出典：Anthropic公式ドキュメント「権限モードを選択する」「設定リファレンス」「モデル設定」（2026年10月10日確認）

planモードを使うべき場面・使わなくてよい場面

プランモードはすべての作業に均一に適しているわけではない。効果が高い文脈と、かえってオーバーヘッドになる文脈を理解したうえで使い分けることが重要である。

プランモードが有効な場面

1. 影響範囲が広いリファクタリング
複数ファイル・複数モジュールにまたがる変更は、全体計画を把握しないまま実装を始めると、中途半端な状態で整合性が崩れるリスクがある。プランモードで依存グラフを可視化してから実装することで、ファイル単位の抜け漏れを事前に排除できる。

2. 未知のコードベースの構造把握
公式ドキュメント”Common workflows”の”Understand new codebases”セクションが示すように、プロジェクト参入初期にプランモードでアーキテクチャ概要を把握する使い方は自然な適合である。この段階ではそもそもファイルを変更する必要がないため、プランモードがデフォルトの適切な状態といえる。

3. バグ修正前の原因仮説の列挙
「どこを直すか」を確定する前に、Claudeにコードベース全体を読ませて原因仮説を列挙させる。誤った箇所を実装段階で変更するリスクを、計画段階で排除できる。

4. 大規模な新機能追加の設計確認
新規エンドポイント・ドメインモデルの導入時に、どのレイヤーに何を追加し既存コードのどこを修正するかを計画として先に文書化できる。計画出力はそのままチームレビューの入力資料として機能する。

プランモードが不要または過剰な場面

単一ファイル内の小規模修正・変数名変更・コメント追加など、影響範囲が自明な作業では計画フェーズを経由するコストが効果を上回る。モード切り替えの分だけ作業速度が落ちるため、作業の複雑度と影響範囲を判断基準として使い分けることが現実的である。

Claude Codeの権限モードの比較

planモードは、Claude Codeの権限モードの1つである。公式ドキュメントの一覧から、対話で使う主な4つを並べる。

モード	確認なしで実行されること	向いている場面
Manual（設定値は default）	読み取りのみ	すべての操作を自分で確認したいとき、慎重に進めたい作業
accept edits（acceptEdits）	読み取り、ファイルの編集、mkdir・touch・mv・cp などの一般的なファイル操作コマンド	内容を確認しながらコードを繰り返し直すとき
plan	読み取り（autoモードが使える環境では、判定の仕組みが承認したコマンドも）	変更の前にコードベースを調べるとき
auto	すべて（裏側で安全性の確認が行われる）	長い作業、確認の回数を減らしたいとき

Claude Code v2.1.283以降、対話型のターミナルとVS Codeのセッションは、autoモードで始まるのが既定になっている。「先に計画を見てから進めたい」ときに、自分でplanモードへ切り替える。

planモードを組み合わせた実践的な進め方

「計画→承認→実行」の3段階フロー

実務で広く採用されているワークフローパターンは、プランモードを起点とした3段階構成である。

1. プランモードで計画を立案：読み取り専用でコードベースを調査し、具体的な変更計画を取得する
2. 計画をレビュー・承認：人間が計画の妥当性・網羅性・設計判断を確認し、必要に応じて修正指示を追加する
3. 通常モードで実装・テスト：承認済みの計画に基づいて実装を実行し、テストで動作を検証する

このフローは公式ドキュメント”Plan before editing”の設計思想を実作業レベルに展開したものである。特に大規模なモノリポや複数チームが関わるコードベースでは、計画ドキュメントをそのままプルリクエストの説明やコードレビューの参考資料として転用できる点が実用的な副次効果となる。

CLAUDE.mdとの連携による品質枠組みの整備

Claude Codeはプロジェクトルートに配置したCLAUDE.mdファイルを読み込み、コーディング規約・アーキテクチャ方針・禁止パターンをコンテキストとして参照する。プランモードで計画を立案する際もCLAUDE.mdの内容が反映されるため、チームの規約に沿った計画が自動的に生成されやすくなる。

さらに、プランモードで初期計画を作成した後、その計画で合意した方針（例：「このプロジェクトではRepositoryパターンを使用する」「テストはユニットとE2Eの両方を必須とする」）をCLAUDE.mdに逆に書き戻す運用も有効である。これにより、以降の作業でClaudeが合意済み方針から逸脱しにくくなり、計画と実装の一貫性を構造的に維持できる。

サブエージェントへの委譲との組み合わせ

公式ドキュメント”Common workflows”には”Delegate research to subagents”というワークフローも記載されている。メインのClaude Codeセッションではプランモードで全体計画を立て、詳細な調査タスク（特定ライブラリの使用箇所の全列挙や、特定パターンのコード検索など）をサブエージェントに委譲することで、メインコンテキストを汚染せずに情報収集できる。大規模コードベースではコンテキスト管理がトークンコストと出力精度の両面に直接影響するため、この分業は無視できない実用価値を持つ。

Agent SDKを用いればPythonやTypeScriptからプログラマティックに同等の動作を実行することも可能である。公式ドキュメント”Agent SDK overview”（code.claude.com/docs/en/agent-sdk/overview.md）によれば、Python向けにはclaude-agent-sdk（Python 3.10以上が必須）、TypeScript向けには@anthropic-ai/claude-agent-sdkが提供されており、allowed_toolsでRead・Edit・Bashなどのツールを制限することで、SDK経由でもプランモード的な読み取り専用の調査動作を実装できる。なお、同ドキュメントには「2026年6月15日以降、サブスクリプションプランでのAgent SDK利用は新しい月次クレジットから消費される」との注記があり、コスト管理の観点で把握しておく必要がある。

CI・自動化パイプラインへの組み込み

公式ドキュメントの”Pipe Claude into scripts”セクションでは、Claude CodeをCI/CDパイプラインに組み込む用途が説明されている。プランモードをこのコンテキストで活用する場合、計画出力をMarkdownまたはJSONとして保存し、プルリクエストのテンプレートや変更影響チェックリストに自動挿入するフローを構築できる。コードレビュー前の影響範囲の可視化を自動化するという用途では、プランモードとCI連携の組み合わせが有効に機能する。

Claude Codeのコスト最適化についてはClaude Code料金・プラン解説およびClaude Code APIコスト詳細も参考にされたい。

実運用でのプランモードの効かせどころ（一次情報）

当メディアの監修者・河合継はClaude Codeを3.5の時代から1年以上、実務で運用してきた。計画と実行を分けるプランモードは、使う場面を選ぶと効果が大きい。

• 変更が大きいほど、先に計画で握る。複数ファイルにまたがる実装やリファクタは、いきなり実行させると意図と違う方向に進んで修正が膨らむ。先に計画を出させて方針を合意してから実行に移すと、手戻りが目に見えて減った。
• 小さな修正にはむしろ使わない。一行直すだけの作業に計画段階を挟むとかえって遅い。プランモードは「やり直しコストが高い変更」に絞るのが、実務でのメリハリだった。
• 計画は「読んで承認する」もの。出てきた計画をそのまま通さず、前提や対象範囲がずれていないか一度目を通してから実行させる。ここでズレを潰しておくと、実行フェーズが一気に安定する。

planモードの限界と注意点

計画精度はコンテキスト品質に依存する

プランモードの出力品質は、Claudeに与えるコンテキストの質と量に強く依存する。コードベースが大規模でファイル数が多い場合、Claudeが1回のセッションで参照できる範囲には物理的な上限があるため、計画に抜け漏れが生じる可能性がある。特定のディレクトリやファイルを明示的に参照させるプロンプト設計、あるいはCLAUDE.mdによるスコープ制限が現実的な対策となる。

また、コードベースのドキュメント化が不足している場合は、Claudeが誤った前提に基づいて計画を立案するリスクもある。計画出力を精査するエンジニアの判断力が最終的な品質保証として機能することは変わらない。

計画と実装の乖離リスク

プランモードで作成した計画は、実装フェーズで状況が変化した際に自動更新されない。計画と実際の実装が乖離する状況は、特に複数ステップにわたる長い作業や、計画立案後に時間をおいて実装を再開した場合に起こりやすい。計画はあくまで出発点であり、実装途中での変化を人間がモニタリングする責任は依然として残る点を認識しておく必要がある。

コスト削減に直結しないケースへの注意

プランモードを経由しても、調査フェーズでのトークン消費は発生する。「計画を立てることでやり直しを減らす」というメリットが実質的なコスト削減につながるかは、作業の性質によって異なる。影響範囲が明確で単純な作業では、計画フェーズ分だけトークン消費が増加する可能性もある。プランモードの使用有無は作業規模・複雑度・リスク許容度を勘案して判断するべきである。

他ツールとの比較における位置づけ

Cursorなど他のAIコーディングツールとのアーキテクチャ上の差異についてはClaude Code vs Cursor比較、OpenAI Codexとの比較はClaude Code vs Codex比較を参照されたい。「AIが自律的に動く前に人間が関与できる接点を明示的に設ける」という設計思想は、Claude Codeのプランモードが色濃く体現している方針であり、ツール選定時の設計哲学の違いとして認識しておく価値がある。

全体的な使い方の整理

Claude Code全般の使い方についてはClaude Code使い方ガイド、SEOや非エンジニア向けの導入事例についてはClaude Code SEO初心者ガイドも参照されたい。Claude Codeの機能全体像についてはClaude Codeとはでも確認できる。

参考文献

• Anthropic, “Choose a permission mode — Claude Code”, https://code.claude.com/docs/en/permission-modes（2026年10月10日確認）
• Anthropic, “Common workflows — Claude Code”, https://code.claude.com/docs/en/common-workflows.md（2026年6月時点）
• Anthropic, “Overview — Claude Code”, https://code.claude.com/docs/en/overview.md（2026年6月時点）
• Anthropic, “Agent SDK overview — Claude Code”, https://code.claude.com/docs/en/agent-sdk/overview.md（2026年6月時点）
• Anthropic, “Quickstart — Claude Code Agent SDK”, https://code.claude.com/docs/en/agent-sdk/quickstart.md（2026年6月時点）
• NaokiIshimura, “Claude Code の Plan Mode 完全ガイド：安全にコードを調査し…”, Qiita, 2026年1月30日, https://qiita.com/NaokiIshimura/items/5fcc70c0a133c1d29ca5
• “Claude CodeのPlan(プラン)モードとは？使い方や活用シーン…”, 侍エンジニアブログ, 2026年5月25日, https://generative-ai.sejuku.net/blog/307946/
• “Claude Code Plan Modeとは？AI開発の失敗を防ぐ設計術！”, AI Rise, 2026年4月3日, https://ai-rise.net/column/claude-code-plan-mode-guide/
• “【2026年最新】Claude Code 料金・無料枠完全ガイド”, QES, 2026年5月8日, https://www.qes.co.jp/media/claudecode/a925

planモードに関するよくある質問

プランモードの切り替え方法は？

ターミナル上でClaude Codeが動作している状態で Shift + Tab を、画面下の表示が「plan mode on」になるまで押すと切り替わります。プロンプトの先頭に /plan を付ける方法や、claude --permission-mode plan で起動する方法もあります。もう一度 Shift + Tab を押すと、計画を承認せずにplanモードを抜けられます。

planモードの間は、コマンドもまったく実行されませんか？

ファイルの編集は行われませんが、調査のためにファイルを読み、シェルコマンドを実行することはあります。autoモードが使える環境では、判定の仕組みが承認したコマンドだけが実行され、使えない環境では、読み取り専用のコマンド以外は実行前に確認を求められます。

計画を承認すると、どうなりますか？

計画ができると、Claudeが進め方を尋ねます。「Yes, and use auto mode」（承認してautoモードで実行）、「Yes, manually approve edits」（承認して編集を1つずつ確認）、「No, keep planning」（計画を続ける）から選びます。承認するとplanモードを抜けて、編集が始まります。Ctrl+G を押すと、計画をテキストエディタで開いて直接書き換えられます。

プランモードが有効な場面は？

複数ファイル・複数モジュールにまたがる影響範囲の広いリファクタリング、未知のコードベースの構造把握、バグ修正前の原因仮説の列挙、大規模な新機能追加の設計確認など、実装前に計画をレビューしたい場面で有効です。

プランモードを使えば必ずコストが下がりますか？

プランモードを経由しても調査フェーズのトークン消費は発生するため、必ずしもコスト削減につながるとは限りません。影響範囲が明確で単純な作業では、計画フェーズの分だけトークン消費が増加する場合もあり、作業規模・複雑度・リスク許容度を勘案して使用を判断する必要があります。