Claude Codeのプランモード（Plan Mode）は、「手を動かす前に、読み取り専用で計画だけ作らせるモード」です。結論から言うと、大きめの変更ほど、いきなり書かせるより先にこのモードで計画をレビューするほうが手戻りが減ります。逆に1ファイルの小修正でわざわざ使うものではありません。
この記事では、プランモードが何をするモードか、3つの入り方、使いどころの判断、そして「止めるための機能」と誤解されがちな点の整理まで、公式ドキュメントをベースにまとめます。私の運用判断は判断として明示して書きます。
プランモードとは——4つの権限モードのひとつ
Claude Codeには権限モード（permission mode）が4つあります。
| モード | 挙動 |
|---|---|
default | 編集や初回のコマンド実行のたびに許可を求める標準モード |
acceptEdits | セッション中のファイル編集を自動で受け入れる |
plan | 読み取り専用。分析と計画立案だけを行い、編集・実行はしない |
bypassPermissions | すべての許可確認を省略する（隔離環境以外では推奨されない） |
プランモード中のClaude Codeは、ファイルを読む・コードベースを検索する・構造を分析することはできますが、ファイル編集や状態を変えるコマンド実行には進みません。調査を終えると実装計画を提案として提示し、こちらが承認して初めて実行フェーズへ移ります。
「提案と実行が分離されている」こと自体が機能です。計画の段階なら、方針の誤りをコード変更ゼロのまま差し戻せます。
入り方は3つ——Shift+Tab・起動フラグ・設定
1. セッション中に切り替える
対話中にShift+Tabを押すと権限モードが循環します。画面下部の表示がplan modeに変わればプランモードです。「調査してほしいだけなのに書き始めた」というときも、その場で切り替えられます。
2. 起動時に指定する
最初からプランモードで始めるなら、起動フラグで渡します。
claude --permission-mode plan
レビュー依頼や設計相談など「今日は書かせない」と決まっているセッションはこれが確実です。
3. 設定ファイルで既定にする
プロジェクトの.claude/settings.json（または個人設定）で既定モードにできます。
{
"permissions": {
"defaultMode": "plan"
}
}
初見のメンバーやエージェントがまず調査から入る前提のリポジトリでは、既定をplanに倒しておく設計もあります。
使いどころは「大きい変更」と「知らないコードベース」
私の使い分けの判断はこうです。
- 複数ファイルにまたがるリファクタリング: どの層に手を入れるか、既存のどの仕組みを再利用するかという方針の分岐は、実装が始まる前に潰したほうが安い。計画に触る予定のファイルが挙がってくるので、影響範囲のレビューがそのままできます
- 初見・他人のコードベースの調査: 読み取り専用なので、探索中にうっかり何かを書き換える事故が構造的に起きません
- 計画だけ受け取って自分で書く: 実装案の比較検討やレビュー観点の洗い出しに使い、実行は承認しないという使い方も成立します
逆に、タイポ修正や1関数の変更のような小さなタスクでは、計画の往復のほうが高くつきます。既定はdefaultのまま、大きい変更のときだけShift+Tabで切り替える運用が現実的です。
「止める機能」かと思ったら、出力の質を上げる機能だった
プランモードは「暴走を止める安全装置」として紹介されがちです。ただ、使いどころを整理してみると、本体は別のところにあると考えています。これは私の判断ですが、先に方針を言語化させること自体が、実装の質を上げます。
- 計画の時点で、誤った前提——存在しないAPIを呼ぼうとしている、対象ファイルを取り違えている——が文章として可視化されます。コードを書いた後に見つけるより、直すコストが一桁安い段階です
- 一度承認された計画は、その後の実装の「合意済みの仕様」として機能します。途中で方向がぶれたときに、戻る基準点になります
- 書いて消してのやり直しは、コンテキストウィンドウも消費します。長いセッションほど、手戻りの削減がそのまま精度の維持につながります
コンテキスト消費の観点は別記事で詳しく書いています。
Claude Codeのコンテキスト管理入門｜/compactより先に/clearを覚えるClaude Codeのコンテキスト管理を公式ドキュメントベースで整理します。/contextでの観測、auto-compactの挙動、/compactの指示付き圧縮と要約で細部が落ちるリスク、/clearで区切る基本方針、CLAUDE.md・サブエージェント・MCP設定で「そもそも入れない」設計までをまとめます。www.tentspace.net
禁止の強制はプランモードの仕事ではない
ここは切り分けが必要です。プランモードはセッション中にいつでも切り替えられる、運用上のモードです。Shift+Tabひとつで抜けられる以上、「このコマンドは絶対に実行させない」という強制の仕組みとしては設計されていません。
禁止を強制したいなら、それは権限設定（allow / deny）とhooksの仕事です。「渡さない・許す・止める・外側で強制」の4層の考え方はこちらにまとめています。
Claude Codeの権限設定4層ガイド｜denyを厚くするだけでは守れないClaude Codeの権限設定を「渡さない・許す・止める・外側で強制」の4層で設計する方法を解説します。allowルールのワイルドカード警告や--restrictedフラグなど直近の公式アップデートを根拠に、hooksによる禁止だけでは塞げない穴と、各層の使い分けを実運用の構成で整理します。www.tentspace.net
役割分担はこう整理できます。
| 目的 | 使うもの |
|---|---|
| 実行前に方針をレビューしたい | プランモード |
| 特定の操作を禁止したい | 権限設定（deny）・hooks |
| 定型作業の確認を減らしたい | acceptEdits・allowルール |
無人運用の文脈では、そもそも都度の承認ボタン自体が機能しないので、境界の設計はまた別の話になります。
AIエージェントのヒューマンインザループ設計｜承認ボタンではなく既定値で作るAIエージェントの無人運用でヒューマンインザループをどう設計するかを整理します。都度の承認ボタンが機能しない理由、Claude CodeとGitHub Copilotの承認まわりの既定値の変化、人間の承認ゲートをゼロにする代わりに置いた4つの境界を、実運用中の構成で解説します。www.tentspace.net
承認後の流れと、差し戻しの作法
計画が提示されたら、承認するか差し戻すかを選びます。承認時には、その後の編集を1件ずつ確認するか、自動で受け入れて進めるかを選べます。定型的な実装まで落ちている計画なら自動受け入れ、判断が残っている計画なら1件ずつ、が目安です。
差し戻すときは「どこが違うか」を具体的に返します。計画はテキストなので、コードレビューよりコメントが書きやすいはずです。方針レベルの誤りをここで直せることが、このモードを使う理由そのものです。
まとめ——モードは仕事の大きさで選ぶ
- 小修正 →
defaultのまま - 定型作業の繰り返し →
acceptEdits - 大きい変更・初見のコードベース・設計相談 → プランモード（Shift+Tab /
--permission-mode plan/defaultMode） - 操作の禁止 → プランモードではなく権限設定とhooks
「まず計画を出して」と毎回プロンプトで頼むより、モードとして切り替えるほうが確実で、読み取り専用の保証も付いてきます。大きい変更の前に一呼吸置く仕組みとして、既定の道具箱に入れておく価値があります。
出典（執筆時点の公式ドキュメント）
- Claude Code Interactive mode（Shift+Tabによる権限モード切り替え）
- Claude Code CLI reference（
--permission-modeフラグ） - Claude Code Settings（
permissions.defaultModeと各権限モードの定義） - Claude Code Common workflows（プランモードの用途例）