Claude Codeに少し大きめの依頼をすると、こういう経験はありませんか。
- 「ログイン機能を直して」と頼んだら、頼んでいないファイルまで書き換え始めた
- 5ファイル編集された後で「あ、その設計じゃない」と気づき、全部巻き戻し
- 途中で方針がズレているのに、止める間もなくコミット直前まで進んでいた
- 結局
git checkout .で全部捨てて、最初から指示し直す
これは「Claudeが賢くない」から起きるのではありません。いきなり実装フェーズに突入させているから起きます。
人間のエンジニアでも、いきなりキーボードを叩き始める人はいません。まず「何をどう変えるか」を頭の中で（あるいは紙に）組み立ててから手を動かします。Claude Codeにも同じことをさせればいい。それがPlan Mode（計画モード）／計画駆動です。
この記事では、「いきなり実装」から「計画を立てさせ→人間が承認してから実装」に切り替えるための具体的な型を紹介します。すべて今日のセッションから試せます。
Plan Modeとは何か
Plan Modeは、Claude Codeがファイルを一切編集せず、何をするかの計画だけを提示してくるモードです。
通常モードとの違いはこうです。
通常モード:
あなた「Xを直して」
→ Claudeがいきなりファイルを編集し始める
→ 編集が終わってから「こう直しました」と報告
Plan Mode:
あなた「Xを直して」
→ Claudeはコードを読むだけ（書き込みはしない）
→ 「こういう計画で進めます」と手順を提示
→ あなたが承認して初めて実装に入る
ポイントは、承認ゲートが間に1枚挟まることです。計画の段階なら、ズレていてもファイルは1行も変わっていません。「いや、そっちじゃない」と言うコストがほぼゼロです。実装後に巻き戻すのとは、やり直しの重さが段違いです。
Plan Modeへの入り方
Claude Code（ターミナル版）では Shift + Tab を押すたびにモードが切り替わります。Plan Modeに入ると入力欄の近くにモード表示が出ます。
通常モード → (Shift+Tab) → 自動承認モード → (Shift+Tab) → Plan Mode → ...
注: モードの切り替えキーやUI表記はバージョンによって変わることがあります。手元のClaude Codeで
Shift + Tabを何回か押し、現在のモード表示を確認してください。「計画を立ててから実装して。承認するまでファイルは触らないで」と最初のプロンプトで明示しても、実質的に同じ計画駆動の運用ができます。
キーで切り替えなくても、プロンプトで縛るだけでも効果は出ます。
このタスクは、まず計画だけを出してください。
- 該当ファイルを読んで現状を把握するのはOK
- ただしファイルの編集・作成・削除は承認前は一切しない
- 「変更するファイル / 変更内容 / 影響範囲」を箇条書きで出す
- 私が「OK」と言ったら実装に入る
Before / After: 計画駆動で何が変わるか
具体例で見ます。「フォームのバリデーションを追加して」という依頼を考えます。
Before（いきなり実装）:
あなた「登録フォームにバリデーションを追加して」
Claude（即座に）:
- RegisterForm.tsx を編集（Yupを導入）
- package.json に yup を追加
- validationSchema.ts を新規作成
- 既存の手書きバリデーションを削除
→ 「完了しました！」
あなた「待って、このプロジェクトZod使ってるんだけど…
あとYup入れないで。全部戻して」
5ファイルが書き換わり、ライブラリまで追加された後で、前提のズレが発覚します。巻き戻しと再指示で時間が溶けます。
After（Plan Modeで計画を先に出す）:
あなた「登録フォームにバリデーションを追加して。まず計画だけ出して」
Claude（読むだけ）:
計画:
1. RegisterForm.tsx に handleSubmit のバリデーションを追加
2. バリデーションライブラリは新規導入が必要。候補:
- Zod（型推論が効く・推奨）
- Yup
どちらを使うか指示をください
3. エラー表示は既存の <FieldError> を流用予定
影響範囲: RegisterForm.tsx のみ（他ファイルは変更なし想定）
あなた「Zodで。あと既存のFieldError流用でOK。実装して」
ライブラリ選定という後戻りコストの高い分岐を、ファイルを触る前に潰せました。これが計画駆動の本質です。
| Before（いきなり実装） | After（計画駆動） | |
|---|---|---|
| 方針ズレの発覚タイミング | 実装後 | 計画段階 |
| やり直しコスト | 全ファイル巻き戻し | 計画文を直すだけ |
| ライブラリ選定などの分岐 | 勝手に決められる | 承認前に確認できる |
| あなたの関与 | 事後レビュー | 事前の方向づけ |
計画レビューの観点 — 承認前に必ず見る5項目
Plan Modeは「計画を出させる」だけでは半分です。残り半分はその計画を人間がどうレビューするかです。計画をナナメ読みして脊髄反射で「OK」を押すなら、いきなり実装と大差ありません。
承認ボタンを押す前に、最低限この5つを確認してください。
1. 変更ファイルのリストが具体的か
「関連ファイルを修正します」のような曖昧な計画は危険信号です。どのファイルを、何ファイル触るのかが列挙されているかを見ます。リストが想定より多いなら、タスクが大きすぎるか、Claudeが余計なことをしようとしています。
良い計画:
変更: src/auth/login.ts, src/auth/session.ts（2ファイル）
新規: src/auth/token.ts
悪い計画:
認証まわりの必要なファイルを適宜修正します
2. スコープが膨張していないか
「ログインのバグ修正」を頼んだのに、計画に「ついでに認証全体をリファクタリング」が混ざっていないか。頼んでいないことが紛れ込んでいたら削らせます。スコープ膨張はレビューで最も見落としやすく、最も後で効いてくるポイントです。
3. 後戻りコストの高い決定が含まれていないか
ライブラリの追加、DBスキーマの変更、共通型の変更、公開APIのシグネチャ変更——これらは一度入れると剥がすのが大変です。計画にこれらが含まれていたら、承認前に必ず明示的に確認します。
4. 既存の規約・パターンに沿っているか
「このプロジェクトはZodを使っている」「エラーは共通の AppError で投げる」といった既存ルールを無視していないか。計画段階で「既存のどのパターンに合わせるか」が書かれていれば安心です。書かれていなければ聞き返します。
5. テスト・検証の手順が入っているか
実装後にどう正しさを確認するのかが計画に含まれているか。「実装する」しか書いていない計画は、動作未確認のコードを生む温床です。
レビュー観点をチェックリストにするとこうです。
| 観点 | 見るポイント | NGなら |
|---|---|---|
| 変更ファイル | 具体的に列挙されているか | 列挙させ直す |
| スコープ | 頼んでいないものが混ざっていないか | 削らせる |
| 後戻りコスト | ライブラリ/スキーマ/API変更があるか | 個別に確認 |
| 既存規約 | 既存パターンに沿うと書いてあるか | 規約を伝える |
| 検証手順 | テスト・確認方法があるか | 追加させる |
計画を「修正してもう一度出させる」のが正しい使い方
計画駆動でありがちな誤解が、「計画は一発で承認するもの」という思い込みです。実際は逆で、計画を読んで気になった点を指摘し、計画ごと直させる往復こそが価値の中心です。
あなた「計画出して」
Claude「計画A（5ファイル変更、ライブラリX追加）」
あなた「ライブラリXは入れない。既存の自前実装を拡張する方向で計画を直して」
Claude「計画B（2ファイル変更、ライブラリ追加なし）」
あなた「OK、それで実装して」
この往復はファイルを1行も変えずに行われます。コードを書く前に設計を詰める——これがソフトウェア開発で昔から言われてきたことを、Claude Code上で再現しているだけです。計画フェーズでの1往復は、実装後の手戻り10往復を防ぎます。
なぜ「複雑なタスク」ほど計画駆動が効くのか
簡単なタスク（タイポ修正、1行の定数変更）に計画駆動は不要です。むしろオーバーヘッドです。計画駆動が劇的に効くのは、タスクが複雑になるほどです。理由は3つあります。
理由1: 複雑なタスクは「分岐」が多い
タスクが複雑になると、「Aの方式かBの方式か」という設計上の分岐が増えます。いきなり実装させると、Claudeはその分岐を勝手に1つ選んで進みます。選択が外れていたら全部やり直し。計画段階なら、分岐に差しかかった時点であなたに聞いてくれます。
複雑なタスク = 分岐の連続
分岐1: 状態管理は既存のContextか新規Storeか
分岐2: APIはRESTのまま拡張かGraphQL導入か
分岐3: エラーは例外かResult型か
→ いきなり実装だと全部Claudeの独断で決まる
→ 計画駆動なら各分岐で確認が入る
理由2: 後戻りコストが指数的に上がる
単純なタスクなら、間違えても1ファイル戻すだけです。複雑なタスクは複数ファイルが絡み合うので、1つの設計ミスが全ファイルに波及します。戻すコストがタスクの複雑さに比例して跳ね上がるため、ファイルを触る前に方向を固める計画駆動の価値が大きくなります。
理由3: コンテキストの無駄打ちを防げる
複雑なタスクでいきなり実装させ、途中で方針がズレると、ズレた実装の試行錯誤が全部コンテキストを食います。計画段階で方向を固めておけば、実装フェーズは一直線に進み、無駄な試行錯誤でコンテキストを溶かさずに済みます。
タスクの複雑さと計画駆動の効果を整理すると、こうなります。
| タスクの複雑さ | 例 | 計画駆動の要否 |
|---|---|---|
| 極小 | タイポ修正・定数変更 | 不要（オーバーヘッド） |
| 小 | 1関数の修正 | 任意 |
| 中 | 1機能の追加（数ファイル） | 推奨 |
| 大 | 機能横断のリファクタ・新機能設計 | ほぼ必須 |
「迷ったら計画から」を基本にして、明らかに小さいときだけ通常モードで直行する。この線引きが実務的です。
計画駆動を習慣にする3つの小ワザ
最後に、計画駆動を「気が向いたらやる」から「デフォルト」にするための小ワザを3つ。
1. CLAUDE.mdに一文入れる
プロジェクトの CLAUDE.md に方針を書いておくと、毎回プロンプトで指示しなくても計画駆動が効きやすくなります。
## 実装の進め方
- 複数ファイルにまたがる変更は、まず計画（変更ファイル・変更内容・影響範囲）
を提示し、承認を得てから実装する
- ライブラリ追加・スキーマ変更は承認前に必ず確認する
2. 「計画→承認→実装」を口癖にする
最初のプロンプトの末尾に「まず計画だけ」と付けるのを習慣化します。たった6文字で後戻りリスクが大きく下がります。
3. 計画が雑なら実装させない
計画が曖昧なまま「とりあえず承認」してしまうのが一番もったいない使い方です。雑な計画は雑な実装の予告です。計画の解像度が低いと感じたら、「もっと具体的に。どのファイルを何行変えるか」と詰めてから承認します。
まとめ
| ポイント | 要点 |
|---|---|
| Plan Modeとは | ファイルを編集せず計画だけ出させ、承認ゲートを挟むモード |
| 入り方 |
Shift+Tab でモード切替、またはプロンプトで「計画だけ」と縛る |
| Before/After | ズレの発覚が「実装後」から「計画段階」に前倒しされる |
| 計画レビュー | 変更ファイル/スコープ/後戻りコスト/規約/検証の5観点で見る |
| 計画の往復 | 一発承認でなく、計画ごと直させる往復が価値の中心 |
| 複雑タスクで効く理由 | 分岐が多く・後戻りコストが高く・コンテキストの無駄打ちを防げる |
Claude Codeの「暴走」の多くは、賢さの問題ではなく承認ゲートを置いていない設計の問題です。計画を先に出させ、人間が方向を確認してから実装に入る。この1枚のゲートを挟むだけで、巻き戻しの回数が体感で激減します。
まずは次の複数ファイルにまたがるタスクで、プロンプトの末尾に「まず計画だけ出して」と付けるところから試してみてください。
補足: 試すための無料リポジトリ
本記事の内容を実際のプロジェクトで試すには、土台となるCLAUDE.mdとフォルダ構成があるとスムーズです。私が使っているスターター構成を無料で公開しています。
無料スターター（GitHub）:
https://github.com/noguso245-jpg/claude-code-skills-starter
さらに踏み込んで、ワークフローやサブエージェント設計を「実行可能なスキルファイル」としてまとめたパッケージも用意しています。手元で /コマンド として呼び出せる形です。
-
スターターパック（¥1,980）: CLAUDE.mdテンプレ7種・Hooks・MCP設定
https://streamsolty.gumroad.com/l/gliwz -
ワークフローOS（¥9,800）: 79本のスキル + ワークフロー3本 + プロンプト10種
https://streamsolty.gumroad.com/l/vhcysn
まずは無料リポジトリから試して、もっと体系的に使いたくなったら検討してもらえれば十分です。記事の内容だけでも効果は出ます。
最新のTipsはXでも発信しています: @k___n___t_1125