Claude CodeのPlan Modeは、AIに「まず考えさせてから動かす」ための専用モードです。本記事では以下を学べます。

  • Plan Modeの起動方法と基本的な挙動
  • 設計フェーズと実装フェーズを分離するメリット
  • 実際のワークフロー例(リファクタリング・新機能追加)
  • Plan Modeが向くタスク・向かないタスクの見極め方

Plan Modeとは何か

Plan ModeはClaude Codeに搭載されている読み取り専用の計画立案モードです。このモードに入ると、ClaudeはReadGrepGlobなどの調査系ツールしか使えなくなり、EditWriteBashの書き込み系操作は一切実行されません。代わりに、コードベースを読み込んだ上で「何を・どこに・どう変更するか」という実装計画を提示し、ユーザーの承認(ExitPlanMode)を待ちます。

従来のClaude Codeは、指示を受けると即座にファイルを編集し始めるのが基本動作でした。小さな修正なら問題ありませんが、複数ファイルにまたがる変更や、仕様が曖昧なタスクでは「思っていたのと違う実装」が出てきて手戻りが発生しがちでした。Plan Modeは、この「設計の合意」と「実装」を明確に分離することで、その問題を解決するために導入されました。

起動方法

Plan Modeに入る方法は2つあります。

1. キーボードショートカット

Claude Codeのプロンプト入力中にShift + Tabを2回押すと、モードが循環的に切り替わります。

Normal Mode → Auto-Accept Mode → Plan Mode → Normal Mode...

画面下部のステータス表示がplan mode onに変わったら準備完了です。

2. 起動オプション

セッション開始時から強制したい場合は、CLIフラグを使います。

claude --permission-mode plan

CIや自動化スクリプトでまず計画だけ生成させたいケースでも有効です。

実際のワークフロー例

ケース1: 既存APIのリファクタリング

例えば「app/api/articles/route.tsのクエリロジックをlib/queries.tsに切り出したい」というタスクを考えます。Normal Modeなら以下のような指示を出すかもしれません。

routeからクエリロジックをlib/queries.tsに移動して

これをPlan Modeで実行すると、Claudeは次のような計画を返します。

## 実装計画

1. `app/api/articles/route.ts`の現状確認
   - 23-67行目に`supabase.from('articles').select(...)`のクエリが2箇所
   - うち1箇所はpagination付き、もう1箇所はカテゴリフィルタ

2. `lib/queries.ts`への移動
   - `getArticlesPaginated(page, limit)`関数を新規追加
   - `getArticlesByCategory(slug)`関数を新規追加
   - 既存の`getRecentArticles()`と命名規則を揃える

3. route.tsの更新
   - importを追加
   - インライン処理を関数呼び出しに置換

4. 影響範囲
   - `app/articles/page.tsx`は別ルートなので影響なし
   - 型定義の追加は不要(既存の`Article`型で足りる)

この段階で「pagination関数の引数を{page, limit}オブジェクトにしてほしい」といった軌道修正が低コストでできます。承認後、ExitPlanModeで実装フェーズに移行し、計画通りにファイルが書き換わります。

ケース2: 仕様が曖昧な新機能

「記事に『あとで読む』機能を追加したい」のような曖昧な依頼では、Plan Modeの真価がさらに発揮されます。Claudeは実装に入る前に、テーブル設計・RLSポリシー・UIの配置場所・認証フローへの依存といった論点を計画書に列挙してくれるため、ユーザーは仕様の穴を実装前に塞げます。

ExitPlanModeの挙動

計画が固まると、ClaudeはExitPlanModeという内部ツールを呼び出して承認を求めます。ユーザーは以下の選択肢から選べます。

  • Yes, and auto-accept edits: 実装フェーズに入り、以降の編集は自動承認
  • Yes, and manually approve edits: 実装に入るが、編集ごとに確認
  • No, keep planning: Plan Modeを継続し、計画をさらに練る

中規模以上の変更ではmanually approveが無難です。auto-acceptは小さなタスクや、ステージング環境での試行錯誤向きです。

Plan Modeが向くタスク・向かないタスク

向くタスク

  • 3ファイル以上にまたがるリファクタリング
  • DB schemaを伴う新機能追加
  • 仕様が口頭ベースで曖昧なタスク
  • 「どっちのアプローチがいい?」と相談したいとき

向かないタスク

  • typo修正・1行変更などの軽微な編集
  • ログ追加やデバッグ用の一時的なコード挿入
  • 既に詳細設計書が存在し、そのまま実装するだけのタスク

軽微な編集にPlan Modeを使うと、計画書の生成と承認のオーバーヘッドの方が大きくなり、かえって遅くなります。

既存ワークフローとの組み合わせ

Plan Modeはサブエージェントやスキルとも相性が良い設計です。例えばPlanサブエージェントに調査と計画立案を委譲し、メインスレッドはその計画を受け取って実装だけ行う、という分業が可能です。これによりメインのコンテキストウィンドウを温存しつつ、複雑なタスクを捌けます。

また、CLAUDE.mdにプロジェクト固有の制約(「APIルートには必ずsession検証を入れる」など)を書いておくと、Plan Modeで生成される計画書にもその制約が反映されるため、レビューの精度が上がります。

まとめ

Claude Code Plan Modeは、「AIに任せたら勝手に変なコードを書かれた」という典型的な失敗を防ぐための、シンプルかつ強力な仕組みです。Shift + Tab二回で起動できる手軽さながら、設計と実装の分離という開発フロー上のベストプラクティスを自然に強制してくれます。中規模以上のタスクに取り組むときは、まずPlan Modeに切り替えて計画を読むことから始めるのが、結果的に最短ルートになるケースが多いはずです。