Claude Code Plan Modeの使い方—auto-acceptへの切替判断

2026年4月21日

Claude Codeの作者本人が、開発タスクの約8割はPlan Modeから始めると話していて、最初これを読んだときは正直ちょっと意外でした。自分はつい --dangerously-skip-permissions でファーストドラフトを走らせて、問題が出たら巻き戻す、という雑な進め方に慣れていたからです。改めてPlan Modeの挙動と他モードとの関係を整理してみると、「自分がやっていた手戻り、その多くがここで防げたやつだな」と腑に落ちる場面がいくつもあったので、自分の整理を兼ねて書き残しておきます。

想定している環境は、Claude Code v2.1系（2026年4月時点）、macOS / Linux ターミナル、モデルは Sonnet 4.6 と Opus 4.7 を切替前提、です。

Plan Modeを挟むだけで手戻りが減る理由

Claude Codeにはざっくり3つの実行モードがあります。通常モード、auto-acceptモード、Plan Modeの3種類です。このうちPlan Modeは 読み取りと検索と思考にしか権限がない状態 で、ファイルの編集・書き込みや外部コマンドの実行が一切走りません。ここが他の2モードと決定的に違うポイントです。

読み取り専用という設計の意味

「書けない状態にするだけでは、単に安全なだけではないか」と自分も最初は思っていました。ただ設計意図はもう一歩踏み込んだところにあります。書ける状態のままAIに指示を出すと、Claudeは「答える＝書く」に直結しやすく、問題の理解が浅いまま動き始めてしまうことが多いからです。

Plan Modeでは Read / Grep / Glob などの読み取り系、それに WebFetch ぐらいしか使えないので、結果として「調べる・考える・計画を提示する」以外のことができません。これにより計画に納得してから通常モードに戻すという流れが構造的に強制されます。

8割のタスクをPlan Modeから始めるという指針

公式ドキュメントやAnthropicの発信を追っていくと、「新規機能の追加」「複数ファイルにまたがる変更」「既存コードのリファクタ」の3パターンはほぼ例外なくPlan Modeから入る、というスタンスが見えてきます。体感の数字として「8割」と語られているのを何度か見かけました。

逆に言うと、残り2割ほどはPlan Modeを使わなくてよい領域があります。変数リネーム、コメント修正、ログ1行追加といった小さな変更が代表例で、ここにPlan Modeを挟むとオーバーヘッドのほうが目立ちます。この線引きは記事後半で整理します。

通常モード・auto-acceptとの関係

3モードはキー操作で切り替わります。

モード	切替キー	書き込み	承認	主な用途
通常モード	(デフォルト)	○	都度承認	対話的な小さい変更
auto-accept	Shift+Tab×1	○	承認スキップ	計画が固まったあとの一気通貫
Plan Mode	Shift+Tab×2 または /plan	✕	–	調査・設計・計画

Plan Modeで計画 → 通常モードで承認しながら実装 → auto-acceptで残りの機械的な実装、という順にグラデーションで使い分けるのが基本の型だと思います。

Plan Modeの起動方法とモデル選択

Shift+Tab 2回と /plan の違い

Plan Modeに入る経路は2つあります。1つはTUI上で Shift+Tab を2回押す方法。もう1つは入力欄で /plan と打つ方法です。機能としてはどちらもPlan Modeに入るだけなのですが、使いどころが微妙に違います。

Shift+Tab のほうは、セッション中にサクッと切り替えたい場面向きです。通常モードで少し触っていて「これは事前に計画を立てたほうがいいな」と気づいたタイミングでキーを叩く感じですね。

一方 /plan は、プロンプトの先頭に書いてそのまま計画依頼に使います。新しい会話を始める時点で「最初から計画モードで」と宣言したい用途に合っています。

/plan Next.jsのAPIルートをApp Routerに移行する計画を立ててください。対象ファイルと移行順序を含めてください。

Plan Mode is now active.
I will investigate the codebase before proposing changes.
...
Plan:
1. /src/pages/api/users.ts -> /src/app/api/users/route.ts (handler書き換え)
2. /src/pages/api/posts.ts -> /src/app/api/posts/route.ts
3. 旧エンドポイントを指す import を検索して置換
4. tests/api/ 配下のテストを App Router 仕様に書き換え

Plan Mode中にOpusを使うべきケース

Plan Modeで出力される計画の質は、当然ながら使っているモデルの性能に引きずられます。小さな修正であればSonnet 4.6で十分ですが、複雑な既存コードを読んだ上で設計判断が要る場面ではOpus 4.7のほうが計画の粒度が明らかに上がる、というのが使ってみた感覚です。

モデル切替は /model コマンドで行えます。Plan Modeに入ってから切り替えれば、そのセッションのPlan生成だけOpusにする、という使い方ができます。

/model opus
/plan 既存のRedisキャッシュ層をリファクタし、TTL設定の重複を排除する

Model set to claude-opus-4-7.
Plan Mode is now active.
Plan:
1. src/cache/redis_client.py: set_with_ttl のデフォルトTTLを定数化
2. src/cache/config.py: 各キャッシュ種別のTTL値を一箇所に集約
3. 旧実装の TTL 引数を呼び出し元から削除

今Plan Modeに入っているかの確認

プロンプト欄直上のステータス行に現在のモードが表示されます。Plan Modeのときは「plan mode on」の表示がつくので、「書き込みできないから遅い」ではなく「書き込まない状態だから」と意識できる視覚的な手がかりになります。ここを見ずに「なぜ書き込まれないんだ」と悩むのがありがちなハマり方なので、最初に目で確認する癖をつけると楽です。

やりがちな失敗パターン3つ

ここからはアンチパターンの整理です。Plan Modeを使い始めたころに自分が引っかかった3つを挙げます。

1. Plan Modeに入らないまま一問一答で突撃する

一番多い失敗がこれです。「複数ファイルにまたがる変更」「既存の設計に手を入れる変更」「外部依存の差し替え」のような横断的な作業なのに、通常モードでいきなり依頼してしまうパターンですね。

NGパターン:

認証ミドルウェアをJWTからCookie-basedに差し替えてください。

...5ファイルを編集しました。
(実際には既存のテストが壊れ、CORS設定とも衝突していた)

Plan Modeを挟むと、この差し替えが既存テストやCORS設定と干渉することを事前にClaudeが洗い出してくれます。

/plan 認証ミドルウェアをJWTからCookie-basedに差し替える

Plan:
- 影響範囲: src/middleware/, src/tests/auth/, src/cors/
- 依存する既存テスト: tests/auth/*, tests/integration/session_*
- 変更が必要な環境変数: JWT_SECRET を削除、SESSION_SECRET を追加
- ロールアウト: フラグで段階的に有効化し、テスト -> staging -> prodの順

2. 粒度の粗い計画をそのままAcceptする

Plan Modeで計画は出たけれど、その内容が粗い、というケースも多いです。「関連ファイルを修正する」「テストを更新する」レベルの抽象度だと、実装フェーズで結局迷います。

計画を受け取ったら、ファイルパス・関数名・変更内容の3点が書き込まれているかを自分で確認する癖をつけると安全です。粗ければ「もう1段詳細化して」と返せばその場で書き直してくれます。

3. Plan Mode中なのに「書き始めて」と指示する

Plan Modeに入ったまま「じゃあ、このとおりに書き始めて」と頼んでしまうケースです。書き込み権限がないので実行できず、Claudeから「Plan Modeのため実行できません」という主旨の応答が返ってきます。

計画が固まったら、Shift+Tab を押して通常モードに戻すか、exit plan mode and proceed のように明示的に指示するのが正解です。ここの切替を忘れがちなので、キー操作自体を癖として覚えるのが早いと思います。

Planを編集して精度を上げる

Ctrl+Gでの手動編集ワークフロー

公式ドキュメントを読んでいて「これは地味に強いな」と感じた機能が、生成された計画の手動編集です。Claudeが計画を提示したあと、Ctrl+G を押すとOS標準のテキストエディタ（$EDITOR / $VISUAL で設定したもの）でその計画ファイルが開きます。

何が嬉しいかというと、「AIが書いた計画を、人間が手で整えてからAIに実行させる」という双方向のワークフローが成立することです。順序の入れ替え、不要な手順の削除、注釈の追加などをエディタ側で自由に行い、保存して戻せば、その内容でClaudeに実装させられます。

計画に入れるべき最低限の項目

自分が計画に入れるようにしているのはこの4項目です。

対象ファイル：ファイルパスと、必要なら行番号レンジ
変更内容：関数単位で「何をどう変える」「何を削除する」
変更順序：依存関係がある変更は明示的に順番を決める
検証方法：各ステップ後に何を確認するか（単体テスト実行、型チェック、手動確認など）

とくに最後の「検証方法」を入れておくと、auto-acceptに切り替えた後でも各ステップで自動的にチェックが走り、失敗時に止まる挙動を期待できます。

計画の粒度を上げるプロンプト例

雑に「〜をリファクタする計画を立てて」とだけ投げると抽象的な計画が返ってきがちなので、プロンプトに制約を入れておくと精度が上がります。

/plan src/auth/ 配下のJWT認証コードをリファクタする計画を立ててください。
以下を含めてください:
- 変更対象ファイルのフルパス
- 削除する関数・追加する関数の名前
- 各ステップでどのテストで検証するか
- 変更を3〜5段階に分割

Plan:
1. src/auth/jwt.ts: verifyToken() の重複呼び出しを集約
   検証: npx vitest run tests/auth/jwt.test.ts
2. src/auth/middleware.ts: トークン抽出関数 extractToken() を切り出し
   検証: npx vitest run tests/middleware/auth.test.ts
3. src/auth/index.ts: 旧エクスポートを削除し再エクスポートを再構成
   検証: npx tsc --noEmit
4. tests/auth/: モック関数の import パスを差し替え
   検証: 全テスト再実行

auto-acceptへの切替判断

切替の判断基準として使っている3条件

Plan Modeで固めた計画を実装フェーズに移すとき、通常モードで進めるかauto-acceptで一気に走らせるかで迷うことが多いです。自分は以下の3つの条件が揃ったらauto-acceptに切り替える、というルールで運用しています。

計画がファイルパス・関数名まで詳細化されている
変更対象ファイルに未コミットの手書き変更が無い（git cleanに近い状態）
各ステップの検証コマンド（test / lint / 型チェック）が計画に書かれている

1つでも欠けているとauto-acceptで走ったあとに「ここは違うな」と気づいた時のロールバックが面倒になります。逆にこの3条件が揃っていれば、auto-acceptは明確に時間を節約してくれるモードになります。

Plan Mode と auto-accept の比較表

観点	Plan Mode	通常モード	auto-accept
書き込み	不可	都度承認	自動
スピード	遅い（読込多い）	中	速い
事故リスク	極小	小	中〜大
向くタスク	計画・調査	対話的な実装	計画済み実装
向かないタスク	即応答の依頼	大量の機械的変更	設計判断が残る作業

長時間タスクで途中からPlan Modeに戻すパターン

auto-acceptで走らせていて、途中で「あれ、この方針でいいんだっけ」と不安になったら、Shift+Tab で一旦Plan Modeに戻す運用も使えます。戻した直後にClaudeは追加の変更を行わず、現状のコンテキストを読み取って次の計画を立て直せるので、「ここから先は再設計したい」というケースで有効な逃げ場として機能します。

Plan Modeを使わないほうがいいケース

最後に、Plan Modeを挟むとオーバーヘッドのほうが目立つケースをまとめておきます。公式でも「計画モードを毎回使う必要はない」と明示されている領域です。

タイプミスや変数リネーム

スコープが明確で、影響範囲が1ファイル内にとどまる変更はPlan Modeを挟まないほうが楽です。例えば「getUserName を全部 fetchUserName に置換」程度であれば、通常モードで即実行するほうがトータルの手数は少ないですね。

対話的に探索するデバッグ

エラーメッセージを見ながら「これ試してみて、だめなら次これ」と進めたいときも、Plan Modeはむしろ邪魔になります。Plan Modeは 先に計画を全部立ててから実行する 前提の設計なので、試行錯誤型の調査とは相性がよくありません。

単発のツール実行

npm test を走らせたいだけ、gh pr view 123 でPRを見たいだけ、のような単発タスクもPlan Modeを挟む必要はないです。Plan Modeは「複数ステップからなるコード変更」に対して効くものなので、1ステップで終わる作業とは目的が違うと割り切ったほうがスッキリします。

まとめ

Plan ModeはClaude Codeを読み取り専用にし、調査・計画だけ行わせる状態
起動は Shift+Tab 2回、または /plan コマンド
複雑な変更の8割はPlan Modeから入るのが推奨される運用
生成された計画は Ctrl+G でエディタ編集可能。ファイルパス・関数名・検証方法までを詰めるのが要点
計画が詳細化 + ワーキングツリーがクリーン + 検証コマンド定義、の3条件が揃ったらauto-acceptへ切替
小さな修正・対話的デバッグ・単発タスクではPlan Modeは使わない

モード切替の型を身につけておくと、「走らせてから巻き戻す」という一番コストの高い進め方を自然に避けられるようになります。コンテキスト管理や計画テンプレの運用と合わせて整備すると効果が大きいテーマなので、Claude Codeのコンテキスト管理術や CLAUDE.md設計の記事も合わせて読むと、モードの使い分けが自分の中で繋がってくると思います。