はじめに
Claude Codeに指示を投げてすぐ実装させると、高確率で手戻りが発生する。「間違った問題を解いた」「既存コードと整合しない実装になった」「途中で仕様の抜けに気づいた」——これらは全て、計画フェーズをスキップしたことが原因だ。
Plan Modeは「考えさせてから動かす」ための仕組みだ。読み取り専用の探索フェーズを設けることで、Claudeがコードベースを深く理解した上で計画を立て、承認後にワンショットで実装する流れを実現できる。
なお、本記事はPlan Modeの操作・活用テクニックに特化している。コスト削減効果については「コスト最適化完全ガイド」で別途触れているため、そちらも参考にしてほしい。
Plan Modeとは何か
Plan ModeはClaude Codeの動作モードの1つで、有効化すると読み取り専用になり、ファイルの変更が一切できなくなる。
Shift+Tab × 2 で起動
（1回目はAuto-Acceptモード、2回目でPlan Modeに切り替わる）
| モード | ファイル変更 | 用途 |
|---|---|---|
| 通常モード | 毎回確認 | 慎重な実装 |
| Auto-Acceptモード | 自動承認 | スピード実装 |
| Plan Mode | 不可（読み取りのみ） | 探索・計画 |
Plan Mode中はRead・Glob・Grep・LS（読み取り系）、WebSearch・WebFetch（情報収集）、AskUserQuestion（仕様確認）が使える。Edit・Write・Bashは使用不可——これが「絶対にコードを書き始めない」保証になる。
探索→計画→実装→コミット：4フェーズワークフロー
Anthropicが公式に推奨し、Claude Code開発者のBoris Cherny（Anthropic）も実践するワークフローの全体像はこうだ。
[Phase 1: 探索（Explore）]
↓ コードベースを理解・関連ファイルを特定
[Phase 2: 計画（Plan）]
↓ 実装方針・変更ファイル・ステップを文書化
[Phase 3: 実装（Implement）]
↓ 計画をもとにワンショット実装
[Phase 4: コミット（Commit）]
↓ 変更を確定
フェーズ1と2（探索＋計画）はトークン消費が最小で、成果への貢献が最大だ。「早く実装させたい」という焦りを抑えて計画に時間を使う——ここが全体の効率を左右するポイントになる。
Exploreサブエージェント：Plan Modeの隠れた強力機能
Plan Mode中に複雑なコードベース探索が必要になると、Exploreサブエージェントが自動起動する。
- モデル: Claude Haiku（軽量・高速）
- 動作: コードベースを並列で検索・分析
- 特徴: 独立したコンテキストウィンドウで動作するためメインのコンテキストを消費しない
メインセッション（Sonnet/Opus）
↓ Plan Mode中に複雑探索が必要になる
Explore Subagent（Haiku × 複数並列）起動
↓ ファイル検索・コード分析を並列実行
結果をメインセッションに返却
HaikuはSonnetの約1/5のコスト。探索作業を自動的にHaikuに委任することで、高精度なPlan Modeが安価に実現できる。
Ctrl+G：計画を自分で編集する
多くの開発者が気づいていない機能として、Ctrl+G で計画をテキストエディタに展開して直接編集できる点がある。
Plan Mode起動
↓
Claudeが計画を生成
↓
Ctrl+G でテキストエディタに計画を展開
↓
人間が計画を修正・追記・削除
↓
エディタを閉じる → Claudeが修正後の計画を自動認識
↓
承認 → 実装開始
「Claudeが作った計画をそのまま使う」のではなく、「Claude＋人間のコラボレーションで最善の計画を作る」という発想の転換が、手戻りをさらに減らす。
RPI（Research-Plan-Implement）ワークフロー：Boris Taneの実践
エンジニアのBoris Tane（RPI考案者、Anthropic社外）が9ヶ月間Claude Codeを使い倒して確立した3フェーズワークフローを紹介する。組み込みのPlan Modeだけでなく、専用Markdownファイルで計画を管理する点が特徴的だ。
Phase 1: Research（調査）
「deeply understand the existing auth system before suggesting changes.
Save your findings to research.md」
「deeply」「in great details」などの言葉で深い分析を促し、調査結果を research.md に記録させる。書面化することで「認識のズレ」を実装前に発見できる。
Phase 2: Planning（計画）
「based on research.md, write a detailed plan.md explaining:
- approach and architecture decisions
- files to be changed with code snippets
- step-by-step todo list
- edge cases and tradeoffs
don't implement yet」
ここで必須なのが末尾の「don't implement yet」だ。Claudeは「熱心すぎるジュニアエンジニア」のように振る舞い、すぐコードを書きたがる。この一文がないと、計画が完成する前に実装を始めてしまう。
Phase 3: Implementation（実装）
「implement plan.md. implement it all」
計画が承認済みなので中断なく実装できる。「創造的な意思決定」は計画フェーズで完了しており、実装は計画を機械的に遂行するだけになる。
ダブルレビュー戦略
計画の品質をもう一段上げたいときは「ダブルレビュー」が使える。
[1st Claude] 計画作成 → plan.md を生成
↓
[2nd Claude] スタッフエンジニアとしてレビュー → 潜在的な問題を指摘
↓
[人間] 両方の視点を統合して最終計画を確定
↓
[1st Claude] 最終計画を実装
2ndClaudeへのプロンプト例はこうだ。
「You are a staff engineer reviewing a junior's implementation plan.
Review plan.md and identify: potential issues, missing edge cases,
architectural problems, and simplifications.
Be critical but constructive.」
2つの独立したセッションが計画を検証するため、1人では気づかない問題が浮かび上がりやすい。
Plan Modeを使うべき場面・スキップできる場面
全てのタスクにPlan Modeを使う必要はない。判断基準はシンプルだ——「この変更のdiffを一文で説明できるか？」できるならPlan Modeはオーバーキル。できないならPlan Modeで始める。
Plan Mode必須の場面：複数ファイルにまたがる変更、アーキテクチャに影響する変更、DBマイグレーション・本番クリティカルな変更、不慣れなコードベースへの変更。
スキップできる場面：スコープが明確な小規模修正、タイポ修正・変数名変更・ログ追加。
なお、Plan Modeの考え方をさらに発展させた手法としてSpec-Driven Development（仕様駆動開発）がある。Requirements→Design→Tasks→Implementationの4フェーズで各成果物をファイルとして永続化し、チーム全体で引き継げる形にしたもので、2026年に実践者が急増している。
ビフォーアフター
Before（Plan Modeなし）
指示を投げるとClaudeが即実装を始め、間違った前提で15分かけて実装を進める。「これじゃない」と巻き戻して再実装し、同じ間違いが違う形で再発する。1タスクに1時間かかる——というのがよくある状況だ。
After（Plan Mode + RPI）
Plan Mode起動 → research.md 作成（探索）→ plan.md 作成 → Ctrl+Gで人間が調整 → 承認 → 「implement it all」でワンショット実装。1タスクに20分（探索10分＋実装10分）まで短縮できる。
※時間感覚はBoris Tane（RPIワークフロー考案者）の実践例をもとにした概算だ。
まとめ
Plan Modeが変えるのは「何をClaudeに任せるか」ではなく「どの順序でClaudeと作業するか」だ。計画を人間が承認してから実装に入る——この順序を徹底するだけで、手戻りの発生率はがらっと変わる。
まず次の複雑な実装タスクで Shift+Tab × 2 でPlan Modeを起動し、計画生成後に Ctrl+G で確認・調整してみてほしい。計画に「don't implement yet」を入れる習慣とあわせて、手戻りの頻度が目に見えて変わるはずだ。
コメント