結論：Claude Code の Plan Mode（計画モード）は「読み取り中心」のモードで、Claude にソースを編集させず、まず調査と計画書を出させ、人間が承認してから実行に移すための仕組みです。大規模リファクタや不慣れなコードベース、本番直結の変更を安全に進めたいときに効きます。
- 要点1：Plan Mode では Claude はファイルを読み込み・読み取り系シェルコマンドで調査するが、ソースの編集はしない（公式:
planモード = Reads only / does not edit your source）。 - 要点2：入り方は3通り。セッション中に
Shift+Tabでモードを循環、プロンプト先頭に/plan、または起動時にclaude --permission-mode plan。 - 要点3：計画提示後に「承認方法」を選ぶ（auto で実行／編集を自動承認／1件ずつレビュー／計画を続ける 等）。承認するとモードが切り替わり、Claude が編集を始める。
対象読者：Claude Code を業務コードや本番リポジトリで使う開発者・PM・テックリード。「AI にいきなり書き換えさせるのが怖い」「大きな変更ほど先に計画を見たい」人。
今日やること：手近なリポジトリで Shift+Tab を押し、ステータスバーが plan 表示になった状態で「この機能を追加する計画を立てて」と頼んでみる。出てきた計画を読んでから承認する流れを一度体験する。
「リファクタを頼んだら、確認する前に10ファイル書き換わっていた」——Claude Code を本番コードで使い始めた開発者がだいたい一度はやる事故です。私自身、初めて中規模のリポジトリで依存関係の整理を任せたとき、意図と違う方向に編集が走って git checkout で巻き戻す羽目になりました。原因は能力ではなく「順番」です。調査と計画を飛ばして、いきなり実行モードで走らせていた。
この「順番」を制度として固定してくれるのが Plan Mode（計画モード）です。本記事では、Plan Mode の正確な挙動・入り方・承認フロー・acceptEdits（自動承認）との違い・効く場面を、公式ドキュメントの記述に沿って開発者目線で整理します。記号やコマンドは実際に打てる形のまま載せます。
Plan Mode とは何か（公式定義に沿って）
Claude Code は、ファイルを編集したりシェルコマンドを実行したりネットワークアクセスをするとき、いったん止まって承認を求めます。この「どれくらいの頻度で止まるか」を決めるのが permission mode（パーミッションモード）です。公式ドキュメントでは次の6モードが定義されています。
default— 読み取りのみ無確認。各ツールの初回使用時に確認を求める標準動作acceptEdits— 読み取り・ファイル編集・一般的なファイル系コマンド（mkdirtouchmvcp等）を自動承認plan— Plan Mode。読み取りのみ。調査・計画はするがソースを編集しないauto— 背後の安全チェック付きで基本すべてを自動承認（リサーチプレビュー）dontAsk— 事前承認済みツール以外を自動拒否（CI・スクリプト向け）bypassPermissions— すべての確認をスキップ（隔離環境専用）
公式の表現を引くと、Plan Mode は次のように定義されています。
plan モード:
「Plan mode tells Claude to research and propose changes
without making them.
Claude reads files, runs shell commands to explore,
and writes a plan, but does not edit your source.」
→ Claude に「変更を実行せず、調査して提案させる」モード。
ファイルを読み、調査用のシェルコマンドを走らせ、
計画書を書くが、ソースは編集しない。ここで重要なのは2点です。第一に、Plan Mode は「無効化」ではなく「読み取り中心」だということ。Claude は cat grep find といった読み取り系コマンドでコードベースを自由に調べられます。第二に、Plan Mode でもパーミッションプロンプト自体は default と同じく機能します（公式: 「Permission prompts still apply the same as default mode」）。つまり「読み取りは止めない／編集はそもそもしない」という前提で調査と計画に専念させるのが Plan Mode です。
Plan Mode の入り方（3つの方法）
入り方は3通りあり、状況で使い分けます。公式ドキュメントの記述どおりに整理します。
- セッション中に
Shift+Tabで循環：CLI ではShift+Tabを押すたびにモードがdefault→acceptEdits→planの順で循環します。現在のモードはステータスバーに表示されます。plan表示になればそこが Plan Mode です。 - プロンプト先頭に
/planを付ける：単発のプロンプトだけ Plan Mode で扱いたいときに使います。 - 起動時にフラグで指定：最初から Plan Mode で立ち上げたいときは起動オプションを使います（下記）。
# 最初から Plan Mode で起動する
claude --permission-mode planPlan Mode を抜けたいだけ（計画を承認せず通常に戻したい）なら、もう一度 Shift+Tab を押します。公式の表現では「Press Shift+Tab again to leave plan mode without approving a plan」です。Shift+Tab の循環に auto や bypassPermissions が入るかは、アカウント要件や起動フラグによって変わります（plan の後ろに有効化済みの追加モードが差し込まれる挙動）。まずは default → acceptEdits → plan の3つを覚えておけば十分です。
プロジェクト単位で常に Plan Mode から始めたい場合は、.claude/settings.json に defaultMode を設定します。
// .claude/settings.json
{
"permissions": {
"defaultMode": "plan"
}
}本番リポジトリや、チームに共有するリポジトリでは、この設定を入れて「最初は必ず計画から」というガードを効かせておくと事故が減ります。
計画をレビューして承認する流れ
Plan Mode で「この変更を計画して」と頼むと、Claude は調査結果と変更計画を提示し、最後に「どう進めるか」を聞いてきます。公式ドキュメントで挙げられている承認オプションは次のとおりです。
- Approve and start in auto mode — 承認して
autoモードで実行を始める - Approve and accept edits — 承認して
acceptEdits（編集を自動承認）で実行を始める - Approve and review each edit manually — 承認するが、各編集を1件ずつ手動でレビューする
- Keep planning with feedback — まだ実行せず、フィードバックを与えて計画を練り直す
- Refine with Ultraplan — ブラウザベースのレビュー（Ultraplan）でさらに精緻化する
計画を承認するとPlan Mode を抜け、選んだオプションに対応するパーミッションモードへ切り替わって、Claude が編集を始めます。逆に「もう一度計画したい」ときは Shift+Tab で Plan Mode に戻すか、次のプロンプト先頭に /plan を付けます。
計画文そのものを直接いじりたいときは Ctrl+G を押すと、提案された計画がデフォルトのテキストエディタで開きます。「この計画の3番目のステップは要らない」「先にテストを書く順番にしたい」といった修正を、Claude に再依頼せずエディタ側で直接書き換えてから進められます。
実務では、変更の大きさで承認オプションを使い分けるのがおすすめです。小さく見通しの立つ変更なら Approve and accept edits、本番に近い・影響範囲が読みにくい変更なら Approve and review each edit manually を選んで、git diff 相当の感覚で1つずつ確認していく。最初から auto で全部任せるのは、サンドボックスやコンテナなど壊れても安全な環境に限定するのが無難です。
acceptEdits（自動承認）との違い
混同されやすいのが acceptEdits モードとの違いです。両者は「人間の確認回数を減らす」点は似ていますが、向きが正反対です。
plan : 読み取りのみ。Claude はソースを「編集しない」。
まず計画を出させ、人間が承認してから実行へ。
→ 「実行を止める」ためのモード。
acceptEdits : ファイル編集と一般的なファイル系コマンドを
「自動承認」する。確認をいちいち挟まない。
ステータスバーに「⏵⏵ accept edits on」と表示。
→ 「実行をなめらかにする」ためのモード。公式ドキュメントによると、acceptEdits は作業ディレクトリ（または additionalDirectories）内のパスに対して、ファイル編集に加えて mkdir touch rm rmdir mv cp sed といったコマンドも自動承認します。スコープ外のパスや保護対象パスへの書き込みは引き続き確認を求めます。つまり acceptEdits は「自分でレビューしながらコードを反復するとき（Iterating on code you’re reviewing）」向けで、変更が走ること自体は前提です。
一方 Plan Mode は「コードベースを変更する前に探索するとき（Exploring a codebase before changing it）」向け。両者は対立ではなく連続したワークフローとして組み合わせます。Plan Mode で計画 → 承認時に acceptEdits（または手動レビュー）へ切り替え → 実行、という流れです。実際、承認オプションの1つが「Approve and accept edits」なのは、この接続を前提にした設計です。
Plan Mode が効く場面・効かない場面
どんな作業でも Plan Mode を挟めばよい、というわけではありません。確認回数が増えるぶん、小さなタスクではかえって遅くなります。効く場面・効かない場面を分けておきます。
- 大規模リファクタ：複数ファイルにまたがる変更は、実行前に「どのファイルをどう触るか」のリストを見たい。計画段階で対象漏れや過剰な変更に気づける。
- 不慣れなコードベース：他人のリポジトリ・引き継いだプロジェクトでは、まず Claude に調査させて全体像を計画として出させると、自分の理解の補助線になる。
- 本番直結の変更：マイグレーション・課金・認証まわりなど、失敗のコストが高い領域は、計画レビューを挟むだけで事故率が下がる。
- 要件が曖昧なとき：「いい感じに直して」レベルの依頼は、いきなり実行させると意図とズレやすい。計画を出させて、ズレていたら
Keep planningで修正してから実行に移す。
逆に、1〜2行の修正、タイプミス直し、テストの追加といった小さく可逆な作業では、Plan Mode はオーバーヘッドになります。そういうときは default や、レビューしながら回す acceptEdits のほうが速い。「変更が大きい・読みにくい・戻しにくいほど Plan Mode、小さい・見通せる・戻せるほど通常モード」という温度感で選ぶとちょうどいいです。
もう1つ補足すると、Plan Mode はサブエージェントによる並列開発とも相性が良い領域ですが、公式ドキュメントには「サブエージェントの frontmatter に書いた permissionMode は auto モードの分類器評価では無視される」という注意もあります。サブエージェントへ計画段階の制約をそのまま引き継がせられると過信せず、親セッション側でモードを管理するのが安全です。
実際の進め方（最小ワークフロー）
ここまでを実際の手順に落とすと、次の流れになります。手近なリポジトリで一度なぞってみてください。
- リポジトリのルートで
claudeを起動する（または起動済みセッションで作業）。 Shift+Tabを押し、ステータスバーがplan表示になったことを確認する。- 「この機能を追加するための計画を立てて。変更するファイルと順番を一覧で。不明点があれば先に質問して」と依頼する。
- 提示された計画を読む。対象ファイルや順番に違和感があれば、そのまま
Keep planning相当のフィードバックを返すか、Ctrl+Gでエディタを開いて計画を直接編集する。 - 納得したら承認オプションを選ぶ。影響が読みにくい変更なら Approve and review each edit manually、見通せる変更なら Approve and accept edits。
- 実行後は
git diffで差分を確認し、想定どおりかをレビューする。
依頼文に「不明点があれば先に質問して」「仮定した点は仮定と明記して」の一言を足すと、計画の質が上がります。Plan Mode は「実行を止める」仕組みであって「計画を正しくする」仕組みではないので、計画自体をどう良くするかはプロンプト側の工夫が効きます。プロジェクト全体の前提を CLAUDE.md（プロジェクトメモリ）に書いておくと、計画段階から制約を踏まえた提案が返ってきやすくなります。
よくある失敗パターンと回避策
失敗1：Plan Mode に入ったつもりで実行モードのままだった
❌ Shift+Tab を押した「つもり」で、ステータスバーを確認していない。
⭕ 必ずステータスバーの表示が plan になっているかを目視する。承認オプションが出るまでは編集が走らないのが正しい挙動。出ないなら Plan Mode に入れていない。
失敗2：計画を読まずに「Approve and start in auto mode」を即押し
❌ 計画を流し読みして一番上の「auto で実行」を反射的に選ぶ。これでは Plan Mode を挟む意味が薄い。
⭕ 影響範囲が読みにくい変更では Approve and review each edit manually を選び、1件ずつ確認する。auto はコンテナ等の壊れても安全な環境に限定する。
失敗3：plan と acceptEdits を取り違える
❌ 「自動で進めてほしい」つもりで Plan Mode にして、なぜ編集されないのか悩む。
⭕ Plan Mode は「編集しない」モード。自動で編集を進めたいなら acceptEdits。ステータスバーの plan と ⏵⏵ accept edits on の表示で見分ける。
失敗4：保護対象パスへの書き込みを Plan Mode で防げると思い込む
❌ .git や .claude などへの書き込みガードを Plan Mode に期待する。
⭕ 保護対象パス（protected paths）への書き込みは、default・acceptEdits・plan のいずれでも自動承認されず確認を求める、という別レイヤーの仕組み。恒久的に止めたいなら deny ルールを設定する。所属組織の規程やセキュリティポリシーにも従ってください。
まとめ：今日から始める3つのアクション
Plan Mode は、Claude Code を「いきなり書き換えさせる道具」から「まず計画を見せてくれる相棒」に変える、最小コストのガードです。能力を制限するのではなく、調査と実行のあいだに人間のレビューを差し込む。大きな変更ほど効きます。
- 体験する：手近なリポジトリで
Shift+Tab→planを確認し、計画を出させてから承認する流れを一度やってみる。 - 使い分ける：大規模・本番直結・不慣れなコードは Plan Mode、小さく可逆な変更は
default／acceptEdits。 - 仕組み化する：本番リポジトリは
.claude/settings.jsonのdefaultMode: "plan"で「最初は必ず計画から」をデフォルトにする。
さらに自動化や定着まで進めたい場合は、Hooks による整形・通知の自動化や、Claude Code の業務導入ガイドもあわせて参照してください。なお Plan Mode の承認オプションや Shift+Tab の循環挙動はバージョンで変わりうるため、運用前に公式ドキュメントで最新の挙動を確認することをおすすめします。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を執筆。
出典
- Choose a permission mode — Claude Code 公式ドキュメント（Plan Mode の定義・入り方・承認オプション・Shift+Tab 循環）
- Configure permissions — Claude Code 公式ドキュメント（permission modes 一覧・protected paths・deny ルール）
- CLI reference — Claude Code 公式ドキュメント（–permission-mode フラグ）
- Settings — Claude Code 公式ドキュメント（defaultMode 設定）
