Claude CodeのPlan mode（計画モード）とは？入り方・承認・使い方を解説

「Claude Codeに機能の追加を頼んだら、思っていたのと違う方向で、いくつものファイルが書き換えられていた」「頼む前に、どこをどう変えるつもりなのかを先に見ておきたい」と感じたことはないでしょうか。

そうした場面のために用意されているのが、Plan mode（プランモード・計画モード）です。このモードに入ると、Claude Codeはファイルを読んで状況を調べ、「こう変えるつもりです」という計画だけを提示します。こちらが計画を承認するまで、元のファイルは書き換えられません。計画を読んで「ここは違う」と直してから実装に進めるので、やり直しの手間を減らせます。

この記事では、Plan modeで何が起きるのかを最初に整理したうえで、入り方、計画の承認と直し方、計画の質を上げる頼み方、他のモードや設定との関係、活用例、うまくいかないときの対処までを順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。Claude Codeは更新が頻繁で、画面の文言が変わることもあるため、使う前に公式ドキュメントもあわせて確認してください。

Plan modeとは

公式ドキュメントでは、Plan modeを「変更を加えずに、調べて変更案を提示するよう指示するモード」と説明しています。Claudeはファイルを読み、調べるためのシェルコマンド（パソコンに文字で出す命令）を実行し、計画を書きますが、ソースコードなど作業対象のファイルは編集しません。計画を承認するまで、編集は止められたままです。

「頼んだらすぐ作り始める」のがふだんのClaude Codeの動き方です。Plan modeは、その手前に「まず計画を見せてください」という段階を挟むためのモードと考えると分かりやすいでしょう。

通常のモードとの違い

Claude Codeには、Claudeが確認なしにできることの範囲を決める「権限モード」がいくつかあります。通常の確認つきモード（画面上の名前は「Manual」）とPlan modeを比べると、次のようになります。

つまり、Manualは「1つずつ編集を確認しながら進める」モード、Plan modeは「実装の前に、全体の進め方を確認する」モードです。どちらが優れているということではなく、確認するタイミングが違います。

「計画を出して」と頼むだけでは足りないのか

通常のモードでも、「実装の前に、まず計画を文章で出して」と頼むことはできます。それでもPlan modeを使う意味は、次のような違いにあります。

一言で確認したいだけなら、「計画を出して」で足ります。変更が大きく、承認してから進めたいときは、Plan modeを使うほうが確実です。

向いている場面・向かない場面

Plan modeは便利ですが、毎回使うものではありません。公式のベストプラクティスでは、計画には手間（オーバーヘッド）もあると書かれており、次の目安が示されています。

迷ったときは、「間違った方向に進んだとき、戻すのに手間がかかるか」で判断すると決めやすくなります。戻すのに手間がかかりそうな変更ほど、先に計画を見る価値があります。

調査と実装を分ける理由

公式のベストプラクティスは、多くの工夫を「Claudeが一度に覚えておける量（コンテキストウィンドウ）には限りがあり、いっぱいになるほど性能が下がる」という前提から説明しています。会話の内容、読んだファイル、コマンドの出力は、すべてこの中に入ります。

調べものだけで多くのファイルを読ませると、実装に入る頃には、会話の多くがすでに埋まってしまいます。そこで、調査と計画をPlan modeで先に済ませ、計画というまとまった形にしてから実装に入る流れが勧められています。調査の部分をPlanサブエージェントに任せれば、読んだファイルの内容は別の作業スペースに入り、メインの会話には結果だけが戻ります。

非エンジニアの方は、「会話が長くなるほど、Claudeは前の話を取り違えやすくなる。だから、調べる段階と作る段階を分ける」と理解しておけば十分です。

使える画面

Plan modeは、ターミナルで使うClaude Codeだけの機能ではありません。公式ドキュメントでは、次の画面で使えると案内されています。

この記事では、基本の動きが同じ画面は区別せずに説明します。画面ごとに操作が違う場合は、そのつど書きます。

この記事に出てくる言葉

初めて見る言葉が多いので、先に簡単な意味をまとめます。

入り方・抜け方

入り方は、「ずっとPlan modeにする」のか「今回の依頼だけPlan modeにする」のかで変わります。ここでは、ターミナルでの操作を中心に説明します。

手順（ターミナルの場合）

1. Claude Codeを起動する作業したいフォルダでターミナルを開き、claudeと入力して起動します。
2. Shift+Tabを押す画面下の表示が⏸ plan mode onになるまで、Shift+Tabを押します。押すたびにモードが順番に切り替わります。
3. 調べたいこと、やりたいことを書く「この機能を追加したい。変更が必要なファイルと進め方を、計画としてまとめて」のように、依頼を書いて送ります。
4. 計画を読むClaudeがファイルを読み終わると、計画が表示されます。途中で質問が来た場合は、答えます。
5. 承認するか、直す画面に出る選択肢から、進める方法を選びます。直したいときは「No, keep planning」を選んで、直す点を伝えます（詳しくは次の章で説明します）。
6. 実装の結果を確認する承認すると、Plan modeが終わって実装が始まります。できあがった変更を確認します。

公式ドキュメントでは、Shift+Tabを押したときのモードの順番を、通常の確認モード（Manual）→ファイル編集を自動で許可するモード（acceptEdits）→Plan modeと説明しています。なお、Windowsで実行環境の条件によっては、Shift+Tabの代わりにAlt+Mを使うと案内されています。

今回の依頼だけPlan modeにする（/plan）

モードを切り替えるより手軽なのが、/planです。スラッシュコマンド（/で始まる命令）の一種で、使い方は2通りあります。

公式ドキュメントのコマンド一覧には、「説明を付けると、Plan modeに入ってすぐにそのタスクを始める」と書かれています。たとえば「/plan 問い合わせフォームの項目を1つ増やしたい」のように、依頼の先頭に付けるだけで使えます。

VS Code拡張機能では、すでにPlan modeに入っているときに/planだけを送ると、現在の計画が表示されます。また、/plan openで計画のファイルをエディタで開けます。/planがVS Codeで使えるのは、Claude Code v2.1.280以降です。

起動したときからPlan modeにする

最初からPlan modeでClaude Codeを始めたいときは、起動時にオプションを付けます。

claude --permission-mode plan

この指定は、画面なしで実行するclaude -p（非対話モード）でも使えます。たとえば、調べるだけの依頼をスクリプトから投げたいときに便利です。

claude -p "この仕組みが、どのファイルでどう動いているか説明して" --permission-mode plan

画面なしの実行では、Plan modeの編集のブロックは維持されます。調べものの結果を、ファイルに書き出して残したい場合などに使えます。

Plan modeから出る

Plan modeから出る方法は2つあります。

• 承認して出る計画を承認すると、Plan modeは終わり、選んだ選択肢に対応するモードに切り替わって実装が始まります
• 承認せずに出るShift+Tabをもう一度押すと、計画を承認せずにPlan modeから出られます

計画をもう一度立てたくなったら、Shift+TabでPlan modeまで戻るか、次の依頼の先頭に/planを付けます。

画面ごとの違い

基本の動きは同じですが、画面によって、表示や既定のモードの決まり方が少しずつ違います。

• VS Code拡張機能モード表示の名前は「Manual」「Edit automatically」「Plan」「Auto」「Bypass permissions」です。Planでは、VS Codeが計画をMarkdownの文書として自動で開きます。新しい会話の開始時のモードは、claudeCode.initialPermissionMode、最後に選んだモード、permissions.defaultMode、組み込みの既定の順に決まります。ただし、PlanとBypass permissionsは、選んだ会話だけに効きます
• デスクトップアプリCodeタブのモード選択で「Plan」を選びます。選んだモードはフォルダごとに記憶されますが、Planだけは、そのセッション限りです。以前のバージョンでは、「Plan mode」という名前で表示されていました
• Web・スマホclaude.ai/codeのクラウドのセッションでは、Accept edits・Plan・Autoの3つを選べます。クラウドのセッションは、ファイルの編集を最初から許可しているため、「Manual」の代わりに「Accept edits」が表示されます

どの画面でも、「承認するまで編集しない」という動きは共通です。操作に迷ったら、まず/planを試すのが、最も確実です。

いつもPlan modeで始める設定

「このプロジェクトでは、必ず最初に計画を見たい」という場合は、設定で既定のモードをPlan modeにできます。プロジェクトの.claude/settings.jsonに、次のように書きます。

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

この設定は、そのプロジェクトで始めるターミナルのセッションに効きます。VS Code拡張機能は、プロジェクトの設定ファイルを開始時のモードには使いません。VS Codeで既定をPlan modeにしたいときは、VS Codeのユーザー設定でclaudeCode.initialPermissionModeをplanにします。

計画の承認・直し方

Plan modeの一番大事な部分は、計画ができあがったあとです。ここで内容をよく見て、必要なら直してから実装に進めます。

承認画面の選択肢

計画ができあがると、Claudeは計画を表示して「どう進めるか」を尋ねます。公式ドキュメントに載っている選択肢は次のとおりです。

「bypass permissions（権限の確認をすべて省くモード）」を有効にして始めたセッションでは、1つ目の選択肢が「Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session」という表示に変わります。表示の文言は版によって変わることがあるため、画面の選択肢が記事と少し違っていても、上の表のどれに当たるかを読み取れば問題ありません。

承認すると、Plan modeが終わり、選んだ選択肢のモードに切り替わって、Claudeが編集を始めます。承認の操作は、実装を始める合図だと考えてください。

計画の読み方

計画の書式は、公式ドキュメントでは決められておらず、依頼の内容や場面によって変わります。ここでは、読み方のイメージをつかむために、料金表ページの修正を頼んだ場合の計画の例を示します。実際の表示とは異なる、説明用の例です。

【計画（例）】
1. 現状の調査：料金が書かれているファイルは3つ（pricing.html、index.html、faq.html）
2. 変更：pricing.htmlの料金表（基本プラン）を35,000円に変更。index.htmlのトップの料金の目安も同じ金額に
3. 変更しないもの：faq.htmlの旧料金の説明（旧料金のお客様向けの記述のため）
4. 確認：変更したページをブラウザで開いて、金額を目で確認する
5. 懸念点：税込と税抜の表記が混在している。どちらにそろえるか確認したい

読むときは、次の表のとおり、項目ごとに見ると分かりやすくなります。

「懸念点」に書かれた内容は、自分では気づいていなかった論点であることが多い部分です。承認する前に、必ず目を通して、答えられるものは答えておきましょう。

計画を直す

計画を読んで違和感があったときは、承認せずに「No, keep planning」を選び、直したい点を言葉で伝えます。Plan modeのまま会話が続くので、何度でも直せます。

直す理由や前提を一緒に伝えると、Claudeは計画の全体を見直してくれます。「ここだけ消して」のように部分だけを指示するより、前提を伝えたほうが、ほかの手順との整合も取れた計画になります。

計画をテキストエディタで直す（Ctrl+G）

言葉で伝えるより、計画そのものを書き換えたほうが早いこともあります。そのときはCtrl+Gを押します。提示された計画が、ふだん使っているテキストエディタで開き、その場で直接編集できます。保存して閉じると、直した計画をもとにClaudeが進めます。

VS Code拡張機能では、Plan modeで計画ができあがると、VS Codeが計画をMarkdown（見出しや箇条書きを書ける文書形式）の文書として自動で開きます。公式ドキュメントによると、ここにインラインコメント（文書の途中への書き込み）を付けて、Claudeに修正を伝えられます。

計画ファイルの保存先

Plan modeで作られた計画は、ファイルとして保存されます。何も設定していなければ、ホームフォルダの.claude/plans（~/.claude/plans）に置かれます。保存先を変えたいときは、設定のplansDirectoryで、プロジェクトのルートからの相対パスを指定します。

{
  "plansDirectory": "./plans"
}

上の例では、プロジェクト内のplansフォルダに計画が保存されます。プロジェクトの外を指す指定（../plansなど）は使われず、~/.claude/plansに戻ります。計画をチームで共有したり、gitで履歴を残したりしたい場合は、プロジェクトの中に保存先を決めておくと便利です。

承認後のモードの選び方

承認画面の選択肢は、実装中の確認の細かさを決めます。変更の重さと、見直しやすさで選ぶと決めやすくなります。

承認する前のチェックリスト

承認の操作は、実装を始める合図です。迷ったときは、次の点を順に確認してから承認しましょう。

1. 頼んだことが全部入っているか依頼に書いたことが、計画のどこかに対応しているかを見ます。
2. 頼んでいないことが入っていないか頼んでいない整理や、ついでの修正が入っていれば、削ってもらいます。
3. 触るファイルの一覧を見る重要なファイルや、触ってほしくない場所が入っていないかを確かめます。
4. 元に戻せる状態か確認するコミットやバックアップなど、戻せる状態になっているかを確かめます。
5. 承認後のモードを選ぶ重要な変更は「Yes, manually approve edits」、確認を減らして進めたいときは「Yes, and use auto mode」を選びます。

承認画面を出している仕組み

Claude Codeには、Plan modeに関わる道具（ツール）が2つあります。公式ドキュメントのツール一覧では、EnterPlanModeは「コードを書く前に、進め方を設計するためにPlan modeへ切り替える」もの、ExitPlanModeは「計画を提示して承認を求め、Plan modeを終える」ものと説明されています。承認画面を出しているのはExitPlanModeで、この操作は利用者の許可が必要なものとして扱われます。

この仕組みから分かることが1つあります。権限ルールのdenyでExitPlanModeを禁止すると、Claudeは計画を承認のために提示できなくなります。公式ドキュメントでも、その場合は、中断した会話を再開してもPlan modeが復元されないと説明されています。通常は設定する必要のない項目ですが、「計画が出てこない」ときの原因の1つとして知っておくと役立ちます。

計画を承認したあとに起きること

承認したあとの動きも、いくつか押さえておきましょう。

• 承認後は、計画のとおりに実装が始まります。実装の途中でも、Escで止めて指示を足したり、/rewindで巻き戻したりできます
• 計画を承認すると、そのセッションに計画をもとにした題名が自動で付きます（すでに名前を付けている場合を除く）
• Plan modeのまま終わった会話を、あとでclaude --resumeなどで再開すると、Plan modeに戻った状態で始まります（ターミナルの場合）。VS Code拡張機能で復元されるのは、Claude Code v2.1.246以降です

実装がずれたときの止め方・戻し方

承認したあとに「思っていたのと違う」と気づいたときの操作を、公式のベストプラクティスの内容でまとめます。

公式のベストプラクティスでは、同じ点を2回以上直しても改善しないときは、会話の中に失敗した方法が積み重なっていると考え、/clearしたうえで、学んだことを入れた具体的な依頼で始め直すほうが、結果的に早いと説明されています。計画の段階で直すほうが、実装後に直すより手間がかからないのは、Plan modeの大きな利点です。

実装のあとは、できあがった変更を必ず確認します。計画どおりに実装されたかを確かめる方法は、次の章の「確認の方法を先に決めておく」で説明します。

計画を良くする頼み方

Plan modeは、入っただけでは計画の質が上がるわけではありません。計画の良し悪しは、どれだけ具体的に頼めるかで大きく変わります。公式ドキュメントで紹介されている進め方と、頼み方のコツをまとめます。

探索・計画・実装・コミットの4段階

公式のベストプラクティスでは、「まず調べ、次に計画し、それからコードを書く」という4つの段階が推奨されています。いきなり作り始めると、「違う問題を解く」コードができあがることがあるためです。

1. 探索する（Plan mode）まずはファイルを読ませて、現状を理解させます。変更はまだ頼みません。例：「ログインとセッションの管理は、どのファイルでどう処理している？　パスワードなどの秘密情報の扱いも調べて」
2. 計画する（Plan mode）調べた内容をもとに、実装の計画を作らせます。例：「Googleアカウントでのログインを追加したい。変更が必要なファイルと、ログインの流れを計画にまとめて」。必要ならCtrl+Gで計画を直接直します
3. 実装する計画を承認して（またはShift+TabでPlan modeを出て）、実装を進めさせます。例：「計画どおりにログインの追加を実装して。確認用のテストも書いて、全部通るまで直して」
4. コミットする変更を記録します。例：「分かりやすいメッセージでコミットして、プルリクエストも作って」

非エンジニアの方にとっては、特に1と2が重要です。探索の段階で「Claudeが何を読んで、何を理解したか」を確認できるので、前提がずれていれば、実装の前に気づけるからです。

計画に入れてほしいことを伝える

計画を頼むときに、次の要素が入っていると、計画の精度が上がります。公式ドキュメントでも、役に立つ仕様は「関係するファイルや部品を挙げ、範囲外を書き、最後に全体を通した確認の手順がある」ものだと説明されています。

5つをすべて書く必要はありません。ただ、「範囲外」と「確認方法」は、書かないと抜けやすい項目です。計画が大きくなりすぎたと感じたら、範囲外を書き足すだけでも、かなり絞れます。

伝わりにくい頼み方・伝わりやすい頼み方

どの例も、「どこまでやるか」と「どう確かめるか」が書かれています。Plan modeは、計画を見てから直せるモードですが、最初の依頼が具体的であるほど、直す回数は少なくなります。

依頼文の例

そのまま使える形で、依頼文の例を紹介します。ファイル名や条件は、実際の環境に合わせて書き換えてください。

機能を追加するとき

/plan お問い合わせフォームに「ご希望の連絡方法（電話・メール）」の選択欄を追加したい。
・変更が必要なファイルを、理由つきで一覧にする
・今ある入力欄の作りを参考に、同じ書き方にそろえる
・送信先のメールアドレスや、送信のしくみは変えない
・変更後に、既存のテストを実行して確認する手順まで計画に入れる

不具合を直すとき

/plan 会員ページで、ログインしてしばらく経つとエラーになるという報告がある。まず原因の候補を、関係しそうなファイルを読んで洗い出してほしい。原因が特定できていない段階なので、修正案は候補ごとに分けて示して。まだ修正はしないで。

よく分からないコードを理解したいとき

/plan このフォルダの請求書を作る処理が、どのファイルからどの順番で呼ばれているかを、図のようにテキストで説明して。変更の計画ではなく、現状の理解が目的です。

3つ目のように、「計画」を頼まず、現状の説明だけを頼む使い方もできます。Plan modeでは編集がされないため、まだ中身をよく知らないファイルを安心して読ませられます。

質問してもらってから計画する

何を頼めばよいのか自分でもまとまっていないときは、Claudeに質問してもらう方法が有効です。公式ドキュメントでは、大きめの機能では、最初に簡単な依頼だけを書き、AskUserQuestionというClaudeの質問機能を使って「インタビュー」してもらう方法が紹介されています。

[やりたいことを一言で] を作りたい。AskUserQuestionツールを使って、詳しく質問してください。
技術的な実現方法、画面の見え方、例外的なケース、懸念点、トレードオフについて聞いてください。誰でも思いつく質問ではなく、私が気づいていないであろう難しい部分を掘り下げてください。
聞くべきことをすべて聞き終えたら、完全な仕様をSPEC.mdに書いてください。

質問に答えていくと、最後に仕様書のファイルができあがります。公式ドキュメントでは、仕様ができたら新しいセッションを始めて、そこで実装させることが勧められています。新しいセッションは、調べもので使った会話が混ざらず、実装だけに集中できるからです。仕様書が手元に残るので、あとから見直すこともできます。

Plan modeの途中でClaudeが質問してくることも、同じ仕組みです。「A案とB案のどちらにしますか」と聞かれたら、分からないまま選ばず、「それぞれの違いを説明して」と返して構いません。

確認の方法を先に決めておく

公式のベストプラクティスで、最も効果が大きいとされているのが「Claudeが自分で確かめる方法を持たせる」ことです。テストを実行する、ビルド（実際に動く形に組み上げる作業）が通ることを確認する、画面のスクリーンショットを撮って元の見本と比べる、といった確認の手段です。

確認の方法がないと、Claudeは「できたように見えた」時点で作業を終えます。そうなると、間違いに気づく役目は、結局こちらに回ってきます。計画の段階で「最後に何をすれば完了と言えるか」を決めておくと、実装のあとの確認も楽になります。

実装のあとに、計画と照らして確認する

公式のベストプラクティスには、実装が終わったあとに、別のサブエージェントに「計画どおりか」を確認させる方法が載っています。実装した本人（同じ会話）は、自分の考えに引きずられやすいためです。サブエージェントは新しい作業スペースで、変更点と基準だけを見て評価します。

サブエージェントを使って、料金表の変更をPLAN.mdと照らして確認して。計画に書いた変更がすべて入っているか、計画に書いた確認が行われているか、計画の範囲外のファイルが変わっていないかを確かめて。文章の好みではなく、抜けだけを報告して。

ただし、公式でも「抜けを探すよう頼まれたレビューは、問題がなくても何かを報告しがちだ」と注意されています。報告された項目をすべて直そうとすると、必要以上に作り込む原因になります。正しさや、書かれた要件に関わる抜けだけを報告させ、残りは任意と考えましょう。

変更の大きさ別の進め方

変更の大きさによって、計画にかける手間を変えると、無駄が出にくくなります。次の表は、公式ドキュメントの考え方をもとにした、進め方の目安です。

計画をファイルにして、別の場所で実行する

計画はファイルとして残せるので、計画を立てる場所と、実行する場所を分けることもできます。公式ドキュメントには、手元でPlan modeを使って計画を詰め、その計画をリポジトリに保存してpushしたうえで、クラウド上のセッションに実行を任せるという進め方が紹介されています。

claude --cloud "docs/migration-plan.md の移行計画を実行して"

クラウドのセッションは、仕事中に手元のパソコンを閉じても進められます。計画を詰める部分は人が見ながら進め、実行は任せる、という分け方です。クラウド版については「Claude Code on the Web」の記事も参考にしてください。

毎回同じ前提を伝えるのが面倒なときは、プロジェクトのCLAUDE.md（Claude Codeが最初に必ず読む指示書き）に書いておけます。公式ドキュメントには、CLAUDE.mdに「src/billing/以下の変更では、Plan modeを使う」と書く例が載っています。ただし、CLAUDE.mdはClaudeへのお願いであり、守らせる仕組みではない点に注意してください。必ず計画を通したい場合の設定は、後の章で説明します。

他のモードとの違い・設定

Plan modeは、Claude Codeの権限モードの1つです。ほかのモードとどう違うのか、どう組み合わせるのかを整理しておくと、場面ごとの使い分けが決めやすくなります。

権限モードの一覧

公式ドキュメントに載っている権限モードを、確認なしでできることの範囲で並べました。設定ファイルでは、表の「設定値」の欄の名前を使います。

使い分けの基本は、「Plan modeで計画を決める → 承認して、autoまたは確認つきで実装する」という流れです。承認画面の1つ目の選択肢が「Yes, and use auto mode」なのは、計画の承認と同時に、autoモードへ切り替えて実装を始められるようになっているためです。

autoモードとの関係

autoモードは、確認の代わりに「分類器（classifier）」と呼ばれる別のAIが、実行前に操作を審査するモードです。依頼の範囲を超える操作や、見覚えのないインフラへの操作などを止めます。

Plan modeの中でも、この分類器が使われます。公式ドキュメントによると、autoモードが使える状態で、設定useAutoModeDuringPlanが有効（初期値）であれば、Plan modeの間も、調べるためのシェルコマンドは分類器が審査し、確認の画面は出ません。審査を通ったコマンドは実行され、通らなかったものはブロックされます。

分類器を使わず、読み取り専用のもの以外のコマンドを毎回自分で確認したい場合は、useAutoModeDuringPlanをfalseにします。この設定は、ユーザー設定・ローカル設定・組織の管理設定に書けます。リポジトリの設定ファイルから、勝手にオフにされることはありません。

計画だけ別のモデルで動かす（opusplan）

Claude Codeには、計画と実装でモデルを自動で切り替えるopusplanという設定があります。公式ドキュメントでは、Plan modeの間はOpus（難しい推論に強いモデル）、実装に入るとSonnet（速さと効率に優れたモデル）に自動で切り替わると説明されています。

/model opusplan

計画では考える力を、実装では効率を使いたい、という場面に合います。なお、モデルの名前や提供状況は更新されるため、使える選択肢は/modelの画面で確認してください。

サブエージェントとの関係

Plan modeで、Claudeがコードの全体像を調べる必要があるとき、組み込みのPlanサブエージェントに調査を任せます。Planサブエージェントは、読み取り専用の道具だけを持ち、編集はできません。調査の途中でたくさんのファイルを読んでも、その内容は別の作業スペース（コンテキスト）に入るため、メインの会話が散らかりません。

この動きは自動で行われるため、特別な操作はいりません。調査を明示的に任せたいときは、「サブエージェントを使って、認証の仕組みがトークンの更新をどう扱っているか調べて」のように頼めます。サブエージェントの詳しい使い方は「Claude Codeのサブエージェント」の記事をご覧ください。

使用量との関係

公式のコスト管理のページでは、複雑な作業では、Plan modeに切り替えてから実装に入ることが、無駄を減らす方法として紹介されています。Claudeがコードを調べて進め方を提案し、最初の方向が間違っていたときの、やり直しの手間を防ぐためです。

一方で、調査のためにファイルを読めば、その分の会話の文脈は使われます。承認画面に会話の文脈を消す選択肢を追加する設定の説明にも、「計画づくりは、多くの文脈を使うことがある」と書かれています。計画のあとに実装まで同じ会話で続けるなら、この選択肢で文脈を整理してから実装に入ると、計画の内容だけを手がかりに進められます。

Claude Codeの使用量は、利用しているプランの上限に含まれます。確認の方法は「Claude Codeの使用量の確認」の記事を参照してください。

権限ルールと組み合わせる

権限モードは、確認の基本的な範囲を決めるものです。その上に、「権限ルール」を重ねて、特定の操作を事前に許可したり、禁止したりできます。公式ドキュメントでは、次のように説明されています。

• denyルール該当する操作を、すべてのモードで止める。bypass permissionsでも有効
• askルール該当する操作は、どのモードでも確認が出る
• allowルール該当する操作を、確認なしで許可する

Plan modeは「計画を見てから編集する」ためのもので、特定のファイルや操作を禁止する仕組みではありません。たとえば「本番用の設定ファイルは、どのモードでも触らせない」といった決まりは、権限ルールで決めます。ルールは、/permissionsで確認や追加ができます。

開発者向け：Agent SDKでのPlan mode

Claude Codeの仕組みを自社のプログラムに組み込む「Agent SDK」でも、permissionModeにplanを指定できます。公式ドキュメントによると、この場合、ファイルの編集は、許可ルールに当てはまる場合でも自動では承認されず、プログラム側のcanUseToolという処理に回されます。Claudeは、計画を固める前に、要件を確認するための質問（AskUserQuestion）をすることがあり、その質問への対応も、プログラム側で組み込みます。

社内の業務ツールにClaudeを組み込む場合は、編集を伴う処理の前に、必ず人の承認を挟む設計にしておくと安全です。

Plan modeに関する設定のまとめ

Plan modeに関わる設定を、一覧にまとめます。

設定の例を1つ示します。「ターミナルではいつも計画から始めて、計画の保存先はプロジェクト内にして、承認時に会話の内容を消す選択肢も出す」という書き方です。プロジェクトの.claude/settings.jsonに書きます。

{
  "permissions": {
    "defaultMode": "plan"
  },
  "plansDirectory": "./plans",
  "showClearContextOnPlanAccept": true
}

設定ファイルは複数の場所に置けます。同じ項目が複数のファイルにある場合は、公式ドキュメントの「設定の優先順位」に従い、プロジェクトの設定や組織の管理設定が、ユーザーのホームフォルダの設定より優先されます。

活用例

Plan modeはプログラミングの場面で語られることが多い機能ですが、Claude Codeは公式ドキュメントでも「メモや文書のフォルダなど、コード以外のフォルダでも動く」と説明されています。変更の前に計画を見る、という使い方は、コード以外のファイル整理にも役立ちます。ここでは、場面ごとの使い方の例を紹介します。以下は、使い方を伝えるための例です。

場面別の使い方

どの場面でも、Plan modeで見るのは「何を触るのか」と「何に影響するのか」です。実装の細かい中身が分からなくても、触る場所の一覧と、影響の範囲を確認するだけで、事故はかなり減らせます。

例：料金表ページを改定する場合の流れ

総務の担当者が、会社のホームページの料金表ページを、新しい料金に合わせて書き換える場合を例に、流れを追ってみます。

1. 元に戻せる状態にしておく作業の前に、今のホームページのファイルをgitでコミットするか、フォルダごとコピーします。
2. Plan modeに入るターミナルでClaude Codeを起動し、Shift+Tabで⏸ plan mode onにします。
3. 依頼を書く「料金表ページの料金を、新しい料金（基本プラン月額3万円→3万5千円）に変えたい。料金が書かれている場所を、サイト内のすべてのファイルから洗い出して。ページの見た目や構成は変えないで」と書きます。
4. 計画を読むClaudeが「料金ページのほかに、トップページと、よくある質問ページにも同じ金額が書かれています」と示します。自分では気づいていなかった箇所が見つかることがあります。
5. 直す「よくある質問の金額は、今回は変えない。理由は、旧料金のお客様向けの説明だから」と伝えて、計画を直してもらいます。
6. 承認して実装する「Yes, manually approve edits」を選び、編集を1つずつ確認しながら進めます。
7. 結果を確認する変更したページを画面で開いて、金額と表示を確かめます。意図しない変更がないか、変更の差分も見ます。

手順4のように、依頼した範囲の外に、同じ内容が書かれた場所が見つかるのは、計画を先に見る大きな利点です。いきなり実装に進むと、トップページだけ古い金額のまま残る、といった食い違いに気づきにくくなります。

例：大きめの機能を、質問から始めて作る場合

やりたいことが固まっていない大きめの変更では、計画の前に質問から入る流れが役立ちます。営業部門の担当者が、社内の見積書作成ツールに「承認フロー」を足したい場合を例にします。

1. 質問してもらう「見積書作成ツールに、上長の承認の仕組みを足したい。AskUserQuestionツールを使って、詳しく質問して。聞き終わったら、仕様をSPEC.mdに書いて」と頼みます。
2. 質問に答える「承認者は1人か複数か」「差し戻しはあるか」「承認前の見積書を、お客様に出してしまわないか」などの質問に答えます。答えにくい質問は、「選択肢と、それぞれの注意点を教えて」と聞き返します。
3. 仕様書を読むできあがったSPEC.mdを確認します。書かれていない前提や、今回はやらないことが入っているか見ます。足りなければ、その場で追記を頼みます。
4. 新しい会話で計画する会話を新しく始め、「SPEC.mdを読んで、実装の計画を立てて」と頼みます。調査の会話が混ざらないため、仕様だけに集中した計画になります。
5. 区切って実装する計画の手順を、「承認の画面」「承認の記録」「通知」のように区切り、1つずつ実装して確認します。

このように段階を分けると、問題が起きたときに、どの段階で何がずれたのかをたどりやすくなります。

依頼文の例

文書フォルダの整理

/plan 「議事録」フォルダの中のファイル名を、「2026-10-15_会議名.docx」の形式にそろえたい。まずは名前を変えず、変更前と変更後の名前の対応表を作ってほしい。名前が重なるものや、日付が分からないものは、別に一覧にして。

ホームページの文言の統一

/plan サイト全体で、会社名の表記が「株式会社〇〇」「(株)〇〇」「〇〇株式会社」とばらばらになっている。使われている場所を一覧にして、「株式会社〇〇」にそろえる計画を立てて。法人名の入った契約書のひな形など、そろえてはいけない場所があれば、別に挙げて。

集計スクリプトの引き継ぎ

/plan 前任者が作った月次集計のスクリプトを引き継いだ。変更はしないので、何をしているか、入力と出力のファイル、毎月やるべき手順を、説明してほしい。分からない部分や、注意が必要な部分があれば、そこも挙げて。

設定の見直し

/plan 社内ツールの設定ファイルに、使っていない古い項目が残っているように見える。削除してよいかを判断したいので、まず、各項目がどのファイルから使われているかを調べて、「使われている」「使われていない」「判断できない」に分けた一覧を作って。まだ何も削除しないで。

うまくいかないとき・注意点

Plan modeを使っていて、迷いやすい点と対処をまとめます。

よくある症状と対処

Plan modeを使うか迷ったとき

使うかどうか迷ったときは、次の質問に答えてみてください。「はい」が多いほど、Plan modeに向いています。

• 変更する場所が、1つか2つのファイルに収まらないかもしれない
• どう直すのが正解か、自分ではまだ決まっていない
• 触るファイルの中身を、自分はよく知らない
• 間違った変更をすると、気づくのに時間がかかる、または戻すのに手間がかかる
• ほかの人に説明するために、変更の計画を残しておきたい

すべて「いいえ」なら、計画を飛ばして、直接頼むほうが早く済みます。

計画の質を確かめる視点

計画が表示されたら、次の点を確認してから承認しましょう。専門的な知識がなくても確認できる項目です。

• 頼んだことの全部が、計画に入っているか
• 頼んでいないこと（範囲外）が、計画に入り込んでいないか
• 触るファイルの一覧に、重要なファイルや、触ってほしくないファイルが入っていないか
• 最後に、変更を確かめる手順が入っているか
• 分からない言葉や前提があれば、その場で「どういう意味？」と聞いて、納得してから承認しているか

確認の過程で疑問が出たら、承認前にその場で質問してかまいません。Plan modeは、納得するまで質問しても、ファイルが変わらないモードです。

Plan modeは「安全装置」ではない場面がある

Plan modeは、ふだんは編集を止めてくれますが、どんな場合でも編集を強制的に止める仕組みではありません。公式ドキュメントでは、次のような場合が説明されています。

「特定のファイルを絶対に触らせない」ことが目的なら、Plan modeではなく、権限のルール（denyルール）で止める設定を使います。公式ドキュメントでは、denyルールはbypass permissionsを含むすべてのモードで効くと説明されています。

会社で使うときに決めておくこと

チームや会社でClaude Codeを使う場合は、次のようなルールを先に決めておくと、使う人によって扱いがばらばらになるのを防げます。

• どんな変更では、計画を見てから進めるのか（複数ファイルにまたがる変更、本番に出るもの、など）
• 計画を承認する人は誰か。自分だけで決めてよい範囲はどこまでか
• 承認後に使う権限モード（1つずつ確認するか、autoにするか）
• 計画のファイルを、どこに保存して、どのくらい残すか
• bypass permissionsを、どの環境でなら使ってよいか（原則、隔離された環境のみ）

組織全体で、ターミナルのセッションの開始時のモードを決めたい場合は、管理者が管理設定（managed settings）のpermissions.defaultModeに指定できます。開始時のモードを決める設定のため、利用者はセッション中にモードを切り替えられます。

よくある質問

まとめ

Plan modeは、「作り始める前に、一度立ち止まって確認する」ための機能です。まずは、変更の影響が大きそうな作業や、よく知らないファイルを触る作業で試して、計画を読む習慣をつけてみてください。使いながら、依頼の書き方や、承認後のモードの選び方も、少しずつ決まっていきます。

社内で使う場面では、どの作業で計画を必須にするか、誰が承認するか、権限をどう設定するかなど、決めることが増えます。INTERCREATE JAPANでは、Claude CodeやCodexの導入から、社内のルールづくり、使い続けられる仕組みづくりまでをお手伝いしています。