この記事の目次
すみません、指示を誤読しました。出力全体をコードフェンスで囲まず、`---` から始まる生のMarkdownのみを返す必要があるため、以下に正しい形式で出力し直します。
---
slug: claude-code-plan-mode-guide
title: Claude Codeのプランモードとは？仕組みと使いどころを整理する
description: Claude Codeのプランモード（Plan Mode）の仕組みと起動方法、使うべき場面、他の権限モードとの違いをまとめて解説します。
keyword: Claude Code プランモード
publishDate: 2026-08-22T07:00:00+09:00
cluster: ext
uniqueValue: Plan Modeを使うべき場面を「作業特性」で判断する軸と、他の権限モードとの位置づけの違いを分けて整理し、判断チェックリストとチーム運用時の共有テンプレ例を提示する点。
---
Claude Code（AnthropicのAIコーディングエージェント）を触り始めると、必ずと言っていいほど耳にするのが「プランモード（Plan Mode）」という言葉です。名前から何となく機能は想像できても、いつ使うべきか、他のモードとどう違うのかまで正確に説明できる人は多くありません。本記事では、Plan Modeの仕組みから起動方法、使いどころ、他の権限モードとの使い分けまでを順に整理します。
## Plan Mode（プランモード）とは何か？何をしてくれる機能なのか
Plan Modeは、ファイルの編集や実行を行わず、コードベースの調査と計画の提示だけに動作を限定する読み取り専用のモードです。承認を挟まずにコードが書き換わってしまう事態を防ぐために用意されています。
Claude Codeは通常、指示を受け取ると必要に応じてファイルを直接編集し、コマンドを実行します。これは作業が速く進む一方で、意図と違う変更が加わったり、修正の範囲が思ったより広がったりするリスクも伴います。プランモードはこのリスクを抑えるための仕組みで、まず調べて、まず考えて、まず提案する、という順番を強制します。
### 通常モードとの違い
通常モードでは、Claude Codeは指示の内容に応じて随時ファイルを編集し、必要なコマンドを実行しながら作業を進めます。編集は基本的にその場で反映されるため、作業のテンポは速くなります。
一方プランモードでは、ファイルの読み取りや検索、依存関係の確認といった調査は行えますが、書き込みや実行は行いません。かわりに、調査結果を踏まえた作業計画をテキストとして提示し、それを読者が確認してから次のステップに進みます。編集そのものを止めるわけではなく、編集の「前段」を独立させる仕組みだと捉えると分かりやすいです。
### 「計画を立てるだけ」で終わらない理由
Plan Modeは計画を出して終わる機能ではありません。提示された計画を読者が承認すると、そのままClaude Codeが実装フェーズに進む前提で設計されています。
つまりプランモードは「様子見のためのモード」ではなく、「合意形成のステップを間に挟む実装フローの一部」です。計画の内容に違和感があれば、その場で修正を伝えられますし、方向性がずれていれば通常モードに戻る前に軌道修正できます。エージェントがどのように調査や判断を進めているかという前提は、[Claude Codeの仕組み](/blog/claude-code-how-it-works/)で扱った内容とも重なります。
## プランモード（Plan Mode）はどうやって始めるのか？
Plan Modeの起動方法は、利用しているインターフェース（CLI、VS Code拡張など）によって操作が異なります。ここでは公式ドキュメントで確認できる範囲の操作方法のみを紹介します。
インターフェースごとの細かい挙動は更新されることがあるため、実際に操作する際は各インターフェースの最新のドキュメントも確認しておくと安心です。
### CLI版での起動方法
CLI（コマンドラインで操作するインターフェース）版のClaude Codeでは、対話中にモードを切り替えるキー操作や、起動時にモードを指定する方法が用意されています。具体的なキー操作やコマンドの表記はバージョンによって変わることがあるため、公式ドキュメントの記載で最新の操作方法を確認しておくと安心です。CLI操作全般は[Claude CodeのCLI操作ガイド](/blog/claude-code-cli-usage-guide/)でひととおり確認できます。
また、設定ファイルであらかじめプランモードを既定の動作にしておくことも可能です。個人の作業で標準化したい場合は、[設定ファイル（settings.json）の書き方](/blog/claude-code-settings-json-guide/)に設定項目がまとまっています。
### VS Code拡張での操作
VS Code拡張版のClaude Codeでも、モードを切り替える操作がエディタ上のUIやコマンドパレットから行えます。表示や操作の呼び方はCLI版と多少異なる場合があり、拡張版特有の操作感は[VS Code拡張の使い方](/blog/claude-code-vscode-extension-guide/)で個別に取り上げています。
### Web版での扱い
Web版でPlan Modeがどこまでサポートされているか、操作方法がCLI版・拡張版とどう違うかは、この記事の執筆時点では断定を避けます。Web版はインターフェースの更新頻度が高い領域なので、最新の対応状況は[Claude Code Web版ガイド](/blog/claude-code-web-version-guide/)を直接あたるのが確実です。
## どんな場面でプランモード（Plan Mode）を使うべきか？
この節では、次の節（他の権限モードとの使い分け）とは異なり、モード体系全体の話ではなく「今取り組んでいる作業そのものの特性」で判断する軸を扱います。
判断材料は大きく2つです。作業の影響範囲がどれくらい広いか、そして自分がそのコードベースにどれくらい慣れているかです。この2軸で考えると、迷ったときの判断がぶれにくくなります。
| 判断軸 | Plan Modeが向いている状態 | Plan Modeが無くても困らない状態 |
| --- | --- | --- |
| 影響範囲 | 複数ファイルや複数モジュールにまたがる変更 | 1ファイル・数行程度の局所的な変更 |
| 慣れ度 | 初めて触るコードベース、把握しきれていない設計 | 普段から触っていて構造を把握できている領域 |
| 変更の性質 | 設計判断やAPIの変更を伴う | 誤字修正やコメント追加などの軽微な調整 |
| やり直しのコスト | 差し戻しに手間がかかりそう | すぐに元に戻せる |
### 使うと安心できる作業の特徴
複数ファイルにまたがる変更や、初めて扱う設計に手を入れる作業では、実装前に計画を確認できることが安心材料になります。自分の理解とClaude Codeの理解がずれていないかを、コードが書き換わる前に照らし合わせられるためです。
新しい機能の追加や、既存の処理を大きく作り替えるような場面では、たとえ小さく見える指示でも影響範囲が広がりやすいので、一度プランモードを挟んでおくと後戻りのコストを抑えられます。
### 使わなくても困らない作業の特徴
誤字の修正やコメントの追加、すでに何度も触っていて構造を把握しているファイルへの軽微な変更であれば、Plan Modeを挟まなくても大きな支障は出にくいです。影響範囲が狭く、間違っていてもすぐに気づいて直せる作業では、通常モードのテンポの良さを優先しても問題は起きにくいでしょう。
自分の作業がどちらに近いか判断に迷ったときは、次のようなチェックリストで確認してみてください。
- この変更は1ファイルで完結するか、それとも複数ファイルに波及するか
- このコードベースの設計を自分は説明できるか
- 想定と違う結果になったとき、すぐに元の状態へ戻せるか
- 実装後にレビューする時間を確保できているか
「複数ファイルに波及する」「戻すのに手間がかかる」側に当てはまる項目が多いほど、プランモードを挟む価値は高くなると考えてよいでしょう。
## 他の権限モードとどう使い分けるか？
前節が作業そのものの特性で判断する話だったのに対し、この節ではClaude Codeが持つモード体系全体の中でPlan Modeがどこに位置するかを整理します。
Claude Codeには、編集や実行のたびに承認を求めるモードから、あらかじめ許可した範囲の操作を自動で進めるモードまで、複数の権限運用の考え方があります。Plan Modeはその中でも、編集そのものを行わず調査と提案に限定するという点で、他のモードと役割が異なります。
### 自動承認寄りのモードとの違い
自動承認寄りの運用は、あらかじめ許可した操作をClaude Codeが都度確認なしに進めるものです。作業のテンポは上がりますが、その分「何が行われたか」を後から把握する負担が増えます。
プランモードはこれとは逆の方向性で、実装に入る前の段階で立ち止まる仕組みです。どちらが優れているという話ではなく、作業の性質や自分の確認したい粒度に応じて選ぶものだと捉えておくとよいでしょう。
### モードを切り替える判断のタイミング
作業の途中でモードを切り替えることも珍しくありません。プランモードで計画を確認したあとに実装フェーズへ進み、そこから先は通常モードや自動承認寄りの設定で進める、という組み合わせ方もよく使われます。
逆に、通常モードで作業を始めてみて、想定より変更範囲が広いと感じた時点でプランモードに切り替え、一度立ち止まって計画を整理し直す、という使い方も有効です。切り替えるたびに立ち止まっていては作業が進まなくなるため、変更の見通しが立たなくなったと感じた節目で挟む、くらいの頻度感で十分です。
## プランモードを使った基本的な進め方は？
Plan Modeでの作業は、調査、計画提示、承認、実装という4段階の流れで進みます。この流れを押さえておけば、自分の作業にそのまま当てはめて実践できます。
まずClaude Codeがコードベースを調査し、関連するファイルや依存関係を確認します。次にその調査結果をもとにした作業計画が提示され、読者はその内容を確認します。問題なければ承認して実装フェーズに進み、修正したい点があればその場でフィードバックを伝えます。
### 計画を確認するときに見るべきポイント
計画を読むときは、変更対象のファイルが想定と一致しているか、変更の順序に無理がないか、自分が気づいていなかった副作用への言及があるかを確認するとよいでしょう。
計画が抽象的すぎて判断できない場合は、承認する前に「具体的にどのファイルのどの部分を変えるのか」を追加で確認するのも有効です。指示の出し方そのものを見直したい場合は、[プロンプトの書き方ガイド](/blog/claude-code-prompt-writing-guide/)が手がかりになります。
### 計画に修正を加えたいときの伝え方
計画に修正を加えたいときは、変更してほしい箇所と理由をセットで伝えると、意図が正しく反映されやすくなります。「この部分は変えないでほしい」「この処理は既存の関数を使い回してほしい」のように、具体的な制約を添えるイメージです。
漠然と「もっと良くして」と伝えるよりも、何を維持し何を変えてほしいかを言語化したほうが、承認後の実装がぶれにくくなります。
## 計画通りに進まなかったときはどうすればいいか？
計画を承認して実装が進んだ結果、想定と違う出来上がりになることもあります。その場合は、実装をいったん差し戻し、どこで認識がずれたのかを踏まえて計画を練り直すという考え方で対処します。
これは特別な操作というより、Plan Modeを含めたエージェントとの作業全般に共通する基本姿勢です。一発で正解にたどり着くことを前提にせず、やり直しを織り込んだ進め方をしておくと、想定外の結果が出ても落ち着いて対応できます。
### やり直しを前提にした付き合い方
差し戻しが発生したときは、何が原因でずれたのかを振り返ることが次の計画の精度につながります。指示があいまいだったのか、調査の段階で見落としがあったのか、切り分けておくと同じずれを繰り返しにくくなります。
実装がうまく進まない原因は、計画そのものの問題とは別に、実行環境や設定に起因することもあります。そうしたエラーの切り分け方は[エラー・トラブルシューティングガイド](/blog/claude-code-error-troubleshooting-guide/)で整理しています。
## チームでプランモードを使うときに気をつけることは何か？
チームでプランモードを使う場合、個人利用と違って計画を他のメンバーと共有し、レビューを受ける場面が出てきます。ここでは公式ドキュメントで確認できる範囲の事実と、読者が任意で行える運用の工夫を分けて説明します。
計画の保存やファイル出力に関する具体的な仕様は、バージョンやインターフェースによって扱いが変わる可能性があるため、この記事では断定しません。チームで運用する際は、以下のような工夫を任意で取り入れると共有がしやすくなります。
### 計画をレビューしてもらう際の共有方法（確認できた範囲で）
Claude Codeが提示した計画のテキストをそのままコピーし、プルリクエストの説明欄やレビュー依頼のコメントに貼り付けておくと、実装前にチームメンバーが内容を確認できます。次のような簡単なテンプレートを用意しておくと、共有の手間を減らせます。実装予定の計画（Plan Mode出力）
対象: <変更対象のファイルやモジュール> 背景: <なぜこの変更が必要か> 計画の要約: <Claude Codeが提示した計画の要点> レビュー観点: <特に確認してほしい点>