Claude Code プランモードの使い方｜起動方法と依頼文の型10例

Claude Code のプランモードとは、Claude に「調べて計画を出すところまで」を任せ、ソースの編集は計画を承認するまで止めておく権限モードです。 Shift+Tab で切り替えるか、claude --permission-mode plan で最初からこのモードで起動します。Claude はファイルを読み、調査用のシェルコマンドを実行し、プランを書きますが、ソースは編集しません。

この記事では、入り方4通りと環境ごとの違い、プラン中に動くこと・止まることの表、承認画面の選択肢、プランモードを既定にする設定ファイルの全文に加えて、そのまま貼って使える依頼文テンプレート10種と、承認前のチェックリストを載せます。

確認環境：Claude Code 2.1.292（Linux）で claude --version と claude --help を実行。モードの挙動と設定は Claude Code Docs（Choose a permission mode ほか）を2026年10月7日に開いて確認。設定ファイルの JSON は Python 3.11.15 で構文を確認しています。

プランモードの早見表

プランモードで動くこと・止まること

プランモードは「何もしないモード」ではありません。読むことと調べることは進み、ソースを書き換えることだけが承認待ちになります。

シェルコマンドの扱い3ケース

プラン中のシェルコマンドは、セッションの条件によって扱いが変わります。上から順に見て、最初に当てはまったものが適用されます。

ケース3で確認なしに動く「読み取り専用の組み込みコマンド」には、ls・cat・echo・pwd・head・tail・grep・find・wc・which・diff・stat・du・cd と、git の読み取り系の形が含まれます。

ケース1は、--dangerously-skip-permissions などで bypass permissions をモードの巡回に入れて起動した対話型の端末セッションのことです。このときはプランモード中でも編集が止まらない場合があるため、計画だけを見たいセッションは通常の起動方法で始めると意図どおりに動きます。

プランモードへの入り方4通り

Shift+Tab で切り替える

端末では Shift+Tab を押すたびに権限モードが切り替わります。ステータスバーに ⏸ plan mode on と出ればプランモードです。

巡回の順番は default（表示は manual）→ acceptEdits → plan です。auto mode で始まったセッションでは、最初の1回で default に移り、そこから同じ順に進みます。

Claude Code v2.1.283 以降は、対話型の端末セッションと VS Code のセッションは auto mode で始まるのが組み込みの既定です。 それより前の版では、auto で始まるのは Pro・Max・Team プランだけで、ほかは manual で始まります。版によって押す回数が変わるので、回数ではなくステータスバーの表示で判断します。

/plan を依頼文の先頭に付ける

モードを切り替えずに、その依頼1回だけをプランモードで進める書き方です。

/plan 会員一覧に「最終ログイン日」での並べ替えを追加したい。変更が必要なファイルと手順を出して。

起動時に --permission-mode plan を付ける

最初からプランモードで始めます。

claude --permission-mode plan

--permission-mode に渡せる値は、手元の Claude Code 2.1.292 では次のとおりでした。

$ claude --version
2.1.292 (Claude Code)
$ claude --help | grep -A3 'permission-mode'
  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

同じフラグは -p（非対話の実行）でも使えます。

claude -p "src/order 以下の構成を調べ、在庫引当の処理の流れを説明して" --permission-mode plan

defaultMode で既定にする

プロジェクトの端末セッションを常にプランモードで始めるには、.claude/settings.json に次のように書きます。リポジトリにコミットすれば、同じプロジェクトで作業する人の端末セッションにも効きます。

.claude/settings.json（全文）

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan"
  }
}

自分のマシンのすべての端末セッションに効かせるなら、同じ内容を ~/.claude/settings.json に書きます。

セッションの開始モードは、次の順で最初に当てはまったものが使われます。

1. --permission-mode フラグ
2. 設定ファイルの permissions.defaultMode
3. 組み込みの既定

複数の設定ファイルに defaultMode があるときは、設定の優先順位（管理設定 → コマンドライン → .claude/settings.local.json → .claude/settings.json → ~/.claude/settings.json）で上にあるものが使われます。

設定ファイルは厳密な JSON です。コメントや末尾のカンマがあると読み込み時にエラーになります。Python で確認した結果です。

$ python3 -m json.tool .claude/settings.json > /dev/null && echo OK
OK
$ cat bad.json
{
  "permissions": {
    "defaultMode": "plan", // 既定をプランに
  }
}
$ python3 -m json.tool bad.json; echo "exit=$?"
Expecting property name enclosed in double quotes: line 3 column 28 (char 48)
exit=1

環境別の入り方と既定の設定

VS Code 拡張は、開始モードについてプロジェクトの .claude/settings.json と .claude/settings.local.json を読みません。 VS Code でプランモードを既定にするには、VS Code のユーザー設定に次を書きます。

VS Code のユーザー設定（settings.json）

{
  "claudeCode.initialPermissionMode": "plan"
}

この設定に書ける値は default・manual・acceptEdits・plan・bypassPermissions です。

VS Code のモード表示やデスクトップのモード選択で Plan を選んだ場合、その選択はその会話（セッション）だけに適用されます。次の会話まで持ち越したいときは、上の設定を使います。

プランを確認して承認する

プランができると、Claude はプランを示して進め方を聞いてきます。選択肢は次の3つです。

1つ目の選択肢は、セッションで auto mode が使えないとき（組織でオフにしている場合など）は Yes, auto-accept edits という表示になります。

承認するとプランモードを抜け、選んだモードで編集が始まります。もう一度計画に戻りたいときは、Shift+Tab でプランモードに戻すか、次の依頼の先頭に /plan を付けます。

Ctrl+G でプランを直接直す

Ctrl+G を押すと、提示されたプランが既定のテキストエディタで開きます。「この手順は不要」「この順番にしたい」といった直しは、会話で伝えるよりプランを直接書き換えるほうが早く確実です。

プランの保存先

プランはファイルとして ~/.claude/plans/ に保存されます。保存先は設定の plansDirectory で変えられます。プランを承認すると、セッションに名前を付けていない場合は、プランに基づいた名前が自動で付きます。

プランモードに関わる設定3つ

~/.claude/settings.json の例

{
  "showClearContextOnPlanAccept": true,
  "useAutoModeDuringPlan": false
}

• useAutoModeDuringPlan を false にすると、プラン中のコマンドは分類器ではなく自分への確認になります（前述のケース3）。false は管理設定、--settings、~/.claude/settings.json、.claude/settings.local.json に書いたものが有効で、共有用の .claude/settings.json に書いた false は使われません。
• showClearContextOnPlanAccept を有効にすると、承認画面の先頭に、プランを承認しつつ計画時のコンテキストを消す選択肢が加わります。調査で多くのファイルを読んだあと、実装をすっきりした状態から始めたいときに合います。

モードの移り変わり（図）

stateDiagram-v2
    [*] --> auto: v2.1.283 以降の端末・VS Code
    [*] --> plan: 起動オプションまたは defaultMode
    auto --> manual: Shift+Tab
    manual --> acceptEdits: Shift+Tab
    acceptEdits --> plan: Shift+Tab
    plan --> auto: Shift+Tab（承認せずに抜ける）
    plan --> 承認待ち: プランができる
    承認待ち --> auto: Yes, and use auto mode
    承認待ち --> manual: Yes, manually approve edits
    承認待ち --> plan: No, keep planning

依頼文の型：4つの欄を埋める

プランの質は依頼文で決まります。「目的・制約・触ってよい範囲・確認方法」の4つを埋めると、Claude が調べる範囲と、プランに書くべきことがはっきりします。

基本の型（全文）

/plan
## 目的
（何を、なぜ。完了したときにどうなっていればよいか）

## 制約
（使ってよい・使わないライブラリ、互換性、期限、守る規約）

## 触ってよい範囲
（変更してよいディレクトリ・ファイル。触らない場所も書く）

## 確認方法
（実行するテストコマンド、手で確かめる手順、期待する結果）

## プランに書いてほしいこと
- 変更するファイルの一覧と、それぞれの変更の要点
- 作業の順番
- テストの追加・変更
- 戻し方
- 判断に迷った点と、こちらに確認したい質問

最初からプランモードで起動している場合や Shift+Tab で切り替えた場合は、先頭の /plan の行は不要です。

記入例（全文）

/plan
## 目的
会員一覧画面（/members）に「最終ログイン日」での並べ替えを追加する。
一覧のヘッダーをクリックすると昇順・降順が切り替わる状態にしたい。

## 制約
- 新しいライブラリは追加しない
- 既存の「氏名」「登録日」の並べ替えと同じ書き方に合わせる
- API のレスポンス形式は変えない（クエリパラメータの追加は可）

## 触ってよい範囲
- src/members/ 以下
- tests/members/ 以下
- DB のマイグレーションと src/auth/ は触らない

## 確認方法
- npm test -- members が通ること
- /members?sort=lastLoginAt&order=desc で新しい順に並ぶこと
- 最終ログイン日が空の会員が末尾に来ること

## プランに書いてほしいこと
- 変更するファイルの一覧と、それぞれの変更の要点
- 作業の順番
- テストの追加・変更
- 戻し方
- 判断に迷った点と、こちらに確認したい質問

コピペ用の依頼文テンプレート10種

（　） の中を書き換えて使います。どれも基本の型に沿っているので、欄を足したり削ったりして構いません。

1. 機能追加

/plan
## 目的
（画面・API 名）に（追加したい機能）を追加する。
完了条件：（利用者から見てどう動けばよいか）

## 制約
- 新しいライブラリは追加しない（必要なら理由を添えて提案する）
- 既存の（似た機能の名前）と同じ書き方に合わせる
- 既存の API のレスポンス形式は変えない

## 触ってよい範囲
- （変更してよいディレクトリ）
- 触らない場所：（ディレクトリ・ファイル）

## 確認方法
- （テストコマンド）が通ること
- （手で確かめる操作と期待する結果）

## プランに書いてほしいこと
- 変更・追加するファイルの一覧と要点
- 作業の順番（小さく分けてコミットできる単位で）
- 追加するテストケース
- 戻し方
- 確認したい質問

2. バグ調査

/plan
## 目的
（起きている症状）の原因を特定し、直し方の案を出す。まだ修正はしない。

## わかっていること
- 再現手順：（手順）
- 期待する動き：（内容）
- 起きている動き：（内容・エラーメッセージの全文）
- 起き始めた時期・きっかけ：（わかれば）

## 制約
- 症状を隠すだけの対応（例外を握りつぶす等）は案に入れない
- 原因の候補は根拠（ファイル名と行）を添える

## 触ってよい範囲
- 調査は全体を読んでよい。変更の案は（ディレクトリ）に限る

## 確認方法
- 症状を再現するテストを先に書き、修正後に通ることで確かめる
- （テストコマンド）

## プランに書いてほしいこと
- 原因の候補（確からしい順）と、それぞれの根拠
- 追加で確かめたいこと（実行してよいコマンド）
- 修正案と、変更するファイル
- 再現テストの内容
- 戻し方

3. リファクタリング

/plan
## 目的
（対象のクラス・モジュール）を（読みやすくする／責務を分ける／重複をなくす）。
外から見た動きは変えない。

## 制約
- 公開している関数・クラスの名前と引数は変えない
- 動きを変える修正は混ぜない（見つけたら別の項目として報告する）
- 1つのコミットで変えるのは1種類の変更だけ

## 触ってよい範囲
- （対象ディレクトリ）
- 呼び出し側（ディレクトリ）は、型やimportの追従だけ可

## 確認方法
- 変更前に（テストコマンド）が通ることを確かめ、各ステップのあとにも実行する
- テストが薄い箇所は、先に現状の動きを固定するテストを足す

## プランに書いてほしいこと
- 現状の問題点（ファイル名と行つき）
- 分割・移動の案と、変更後の構成
- ステップごとの変更内容と、その時点で通すテスト
- 動きが変わるおそれのある箇所
- 戻し方

4. ライブラリ更新

/plan
## 目的
（ライブラリ名）を（現在の版）から（目標の版）へ更新する。

## 制約
- 更新するのはこのライブラリと、それに必要な依存だけ
- 公式の移行ガイド・リリースノートを読み、根拠の URL を添える
- 非推奨の警告は一覧にする（今回直すものと後に回すものを分ける）

## 触ってよい範囲
- 依存定義ファイル（ファイル名）とロックファイル
- 変更が必要になった呼び出し箇所

## 確認方法
- （ビルドコマンド）と（テストコマンド）が通ること
- （起動して確かめる画面・API）

## プランに書いてほしいこと
- 版ごとの破壊的変更のうち、このリポジトリに関係するもの
- 影響を受けるファイルの一覧（検索に使ったキーワードつき）
- 作業の順番（段階的に上げるか、一度に上げるか、その理由）
- 更新後に確かめる項目
- 戻し方（依存定義とロックファイルを戻す手順）

5. DB スキーマ変更

/plan
## 目的
（テーブル名）に（追加・変更したい列や制約）を加える。
理由：（なぜ必要か）

## 制約
- マイグレーションは（使っているツール名）の形式で書く
- 既存のデータを失わない。既存行に入れる値を明示する
- サービスを止めずに適用できる手順にする（難しい場合は理由を書く）
- 適用済みのマイグレーションファイルは書き換えない

## 触ってよい範囲
- （マイグレーションのディレクトリ）に新しいファイルを追加
- （エンティティ・モデルのディレクトリ）
- 触らない場所：（ディレクトリ）

## 確認方法
- 空の DB と、既存データを入れた DB の両方でマイグレーションを流す
- （テストコマンド）
- 戻しのマイグレーションを流して元の定義に戻ること

## プランに書いてほしいこと
- 実行する DDL（全文）
- 既存データの移し方と、件数が多い場合の所要の見込み
- アプリ側の変更と、適用の順番（DB が先か、アプリが先か）
- ロックがかかる操作と、その範囲
- 戻し方（戻しの DDL 全文）

6. テスト追加

/plan
## 目的
（対象のクラス・関数）にテストを追加し、（守りたい動き）を固定する。
実装は変えない。

## 制約
- テストフレームワークは既存の（名前）を使う
- 既存のテストの書き方（ファイル名、命名、準備の仕方）に合わせる
- モックは（外部 API・時刻・乱数）だけにする
- 実装側の不具合を見つけたら、直さずに報告する

## 触ってよい範囲
- （テストのディレクトリ）だけ

## 確認方法
- （単体テスト1件だけを実行するコマンド）で追加分が通ること
- 最後に（全体のテストコマンド）を実行する

## プランに書いてほしいこと
- 追加するテストケースの一覧（正常系・境界値・異常系に分けて）
- それぞれの入力と期待する結果
- 現状テストの無い分岐
- テストしにくい箇所と、その理由

7. 既存コードの調査のみ

/plan
## 目的
（知りたいこと。例：注文確定から在庫引当までの処理の流れ）を理解したい。
コードは変更しない。調査結果の報告だけがほしい。

## 制約
- 推測で書かない。書いた内容にはファイル名と行を添える
- 読んでもわからなかった点は「不明」として分けて書く

## 触ってよい範囲
- 読むのは（ディレクトリ）。編集はしない

## 確認方法
- 報告に出てくるファイル名・関数名を、こちらで開いて確かめられること

## 報告に書いてほしいこと
- 処理の流れ（入口から出口まで、順番に）
- 関わるクラス・関数の一覧と役割
- データが保存・更新される場所
- 設定値や環境変数に左右される箇所
- 変更するときに気を付ける点

8. 性能の改善

/plan
## 目的
（対象の画面・API・バッチ）の（応答時間／処理時間／メモリ）を改善する。
現状：（計測値）　目標：（数値）

## 制約
- 先に計測し、遅い箇所を数値で示してから案を出す
- 結果（レスポンスの内容・並び順）は変えない
- キャッシュを入れる案は、更新のタイミングと無効化の方法も書く

## 触ってよい範囲
- （対象ディレクトリ）
- インデックスの追加は案として出す（適用はこちらで判断する）

## 確認方法
- （計測に使うコマンド・手順）で前後を比べる
- （テストコマンド）が通ること

## プランに書いてほしいこと
- 計測の方法と、現状の内訳
- 改善案（効果の見込みが大きい順）と、それぞれの手間
- 変更するファイル
- 改善後に測る項目
- 戻し方

9. 設定・CI の変更

/plan
## 目的
（設定ファイル・ワークフロー名）を変更して、（実現したいこと）ができるようにする。

## 制約
- シークレットや鍵の値をファイルに書かない
- 権限は必要な分だけにする
- ほかのジョブ・環境の動きは変えない

## 触ってよい範囲
- （設定ファイル・ワークフローのパス）
- 触らない場所：（本番用の設定ファイルなど）

## 確認方法
- （構文チェックのコマンド）が通ること
- （試しに動かすブランチ・手順）で期待どおり動くこと

## プランに書いてほしいこと
- 変更前後の差分の要点
- 影響を受けるジョブ・環境の一覧
- 必要になるシークレット・権限（名前だけ）
- 試す手順
- 戻し方

10. レビュー指摘への対応

/plan
## 目的
PR（番号）で受けた指摘に対応する。指摘の一覧は次のとおり。
1. （指摘の内容）
2. （指摘の内容）
3. （指摘の内容）

## 制約
- 指摘と関係のない変更は入れない
- 指摘に同意できない点は、直さずに理由と代案を書く
- 指摘1件につき1コミットに分ける

## 触ってよい範囲
- この PR で変更したファイル
- それ以外に必要な場合は、理由を添えて提案する

## 確認方法
- （テストコマンド）が通ること
- 指摘ごとに、対応したことがわかる差分になっていること

## プランに書いてほしいこと
- 指摘ごとの対応方針（直す／代案を出す／質問する）
- 変更するファイルと要点
- 追加・変更するテスト
- レビュアーへの返信の下書き

プランに書かせる項目の Markdown 雛形

プランの形をそろえたいときは、依頼文の最後に「次の形式でプランを書いて」と添えて、この雛形を貼ります。CLAUDE.md に置いておく方法もあります。

# プラン：（作業の名前）

## 1. 目的と完了条件
- 目的：
- 完了条件：

## 2. 調べたこと
- 読んだファイル：
- わかったこと：
- 不明な点：

## 3. 変更するファイル
| ファイル | 種別（新規・変更・削除） | 変更の要点 |
|---|---|---|
|  |  |  |

## 4. 作業の順番
1.
2.
3.

## 5. テスト
- 追加・変更するテスト：
- 実行するコマンド：
- 期待する結果：

## 6. 影響する範囲
- 影響を受ける機能：
- 互換性：

## 7. 戻し方
- 手順：

## 8. 確認したい質問
-

あいまいな依頼文と直した依頼文の対比5組

直した依頼文に共通しているのは、対象（どのファイル・どのケース）、制約（変えないもの）、確認方法（どのコマンドで確かめるか）が入っていることです。

プランを承認する前のチェックリスト

承認すると編集が始まります。次の項目がプランから読み取れるかを見てから進めます。足りないものがあれば No, keep planning を選んで追記を頼むか、Ctrl+G で自分で書き足します。

プランモードを使う・使わないの判断表

プランモードは便利ですが、その分の手間も加わります。公式のベストプラクティスでは、差分を1文で説明できる作業は計画を省くことが勧められています。

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

公式が勧める進め方は、調べることと作ることを分ける4段階です。

つまずきやすい点と対処

よくある質問

Q. プランモード中は、コマンドが一切実行されないのですか？ A. いいえ。調査のためのシェルコマンドは実行されます。止まるのはソースの編集です。コマンドに確認が出るかどうかは、auto mode が使えるかと useAutoModeDuringPlan の設定で決まります。

Q. プランを承認せずに、プランモードだけ抜けられますか？ A. はい。もう一度 Shift+Tab を押すと、承認せずにプランモードを抜けます。

Q. /plan と --permission-mode plan はどう使い分けますか？ A. /plan はその依頼1回だけ、--permission-mode plan はセッションの開始からプランモードにします。調査から入る作業はフラグで起動し、実装の途中で一度立ち止まりたいときは /plan が手軽です。

Q. 承認したあと、また計画に戻れますか？ A. 戻れます。Shift+Tab でプランモードに切り替えるか、次の依頼の先頭に /plan を付けます。

まとめ

• プランモードは「調べて計画を出すまで」のモード。ソースの編集は承認まで止まる
• 入り方は4通り：Shift+Tab、/plan、claude --permission-mode plan、permissions.defaultMode
• v2.1.283 以降は auto で始まるのが既定。回数ではなく ⏸ plan mode on の表示で確かめる
• VS Code の既定は claudeCode.initialPermissionMode で設定する
• 承認の選択肢は3つ。1件ずつ見たいときは Yes, manually approve edits
• 依頼文は「目的・制約・触ってよい範囲・確認方法」の4つを埋める
• 承認前に、変更ファイル一覧・テスト方法・戻し方がプランにあるかを見る

参考・出典

いずれも2026年10月7日に確認しました。

• Claude Code Docs: Choose a permission mode https://code.claude.com/docs/en/permission-modes
• Claude Code Docs: Settings files and precedence https://code.claude.com/docs/en/settings
• Claude Code Docs: Configure permissions https://code.claude.com/docs/en/permissions
• Claude Code Docs: Claude Code のベストプラクティス https://code.claude.com/docs/ja/best-practices

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。