Claude CodeのPlan Modeが地味に最強だった——設計してから実装する開発スタイルのすすめ
Claude Codeの/planコマンドとShift+Tabで入れるPlan Modeの使い方を解説。設計→レビュー→実装の3ステップで手戻りを激減させる実践ワークフロー。
エンジニアのゆとです。
Claude Codeを使い始めた頃、僕の使い方はこうだった。
「この機能を実装して」と投げる → Claude Codeが一気にコードを書く → なんか微妙に違う → やり直し → またズレてる → もうひとっ走り → ようやく完成。
これ、全部Claude Codeのせいじゃなくて、「設計なし・一発勝負」で投げてた僕が悪かった。
料理で言えば、「なんかおいしいもの作って」でシェフに厨房に立たせるようなもんで、そりゃ好みと違うものが出てくることもある。それを「違う、やり直し」と繰り返すのはシェフにも失礼だし、トークンも財布も削れていく一方だった。
そこで使い始めたのが Plan Mode だ。これが地味に、体験をまるっと変えてくれた。
Plan Modeとは何か
Plan Modeは、Claude Codeがコードを書かずに設計だけを出力するモードだ。
ファイルの読み書きや変更を一切行わず、「こういう手順でやります」という計画だけを先に見せてくれる。
起動方法は2通りある。
# ターミナル上でのトグル
Shift + Tab# チャットの中でコマンドとして使う
/planShift + Tab を押すと、プロンプトの右に (plan mode) という表示が出る。この状態で指示を送ると、Claude Codeは実行せずに計画を文章で返してくる。もう一度 Shift + Tab を押すと通常モードに戻る。
/plan コマンドは、通常モードのセッション中に「今すぐプランだけ見せて」と言えるもので、その1ターンだけ設計出力になる。
表面上は似た機能だが、使いどころが少し違う。
- Shift + Tab（Plan Mode）: 複数回のやり取りをプラン専用にしたいとき。「設計フェーズ」を明示的に作る
- /plan コマンド: 普通の会話の流れで「ちょっとプランだけ」と挟みたいとき
どちらを使っても、Claude Codeはファイルに一切触らない。これが重要だ。
なぜ「設計→実装」がうまくいくのか
いきなり実装させると何が起きるか。
Claude Codeはプロンプトを受け取った瞬間に「最善手」を探しながらコードを書き始める。この判断は速いが、あなたが想定していない方向を選ぶことがある。
たとえば「ユーザー一覧を検索できるようにして」という指示を出すと、Claude Codeは「フロントでフィルタリング」「バックエンドAPIで検索」「全文検索エンジン導入」のうち自分が最善と判断したものを実装する。あなたが「バックエンドで普通にSQLのLIKEで十分だよ」と思っていても、関係なく進む。
結果として「なんか大げさな実装になった」「こういう構成じゃない」という手戻りが発生する。
これは Claude Codeが悪いわけじゃない。情報が足りないままエンジンをかけてしまっているだけだ。
Plan Modeを先に通すと、この問題を事前に潰せる。
- まず設計案が出てくる
- 「この方針でいいか」を自分が判断する
- 違ったら軌道修正してから実装を開始する
フロー図的に書くとこうなる。
【Plan Mode あり】
指示 → 設計案確認 → （必要なら修正指示） → 実装 → 完成
【Plan Mode なし】
指示 → 実装 → 「なんか違う」 → やり直し指示 → 実装 → 完成後者はやり直しのたびにトークンを消費するし、何より疲れる。
Plan Modeの使い方：3ステップ
Step 1. Plan Modeで設計を出す
Shift + Tab でPlan Modeに入ってから指示を送る。
（Plan Mode状態で）
既存のユーザー管理ページに、メールアドレスで絞り込める検索フォームを追加したい。
バックエンドはLaravelで、フロントはVue 3。
変更が必要なファイルと実装手順を教えて。まだ実装しなくていい。Claude Codeはこういう形で返してくる。
以下の実装計画を提案します。
【変更ファイル】
1. resources/js/pages/Users/Index.vue
- 検索フォームコンポーネントの追加
- search クエリパラメータをAPIに渡す処理
2. app/Http/Controllers/UserController.php
- index メソッドに検索条件を追加
- email による LIKE 検索（前方一致 or 部分一致）
3. app/Http/Requests/UserIndexRequest.php（新規作成）
- search パラメータのバリデーション
- 文字列、最大100文字
【実装順序】
1. バリデーションリクエストを作成
2. コントローラーに検索ロジックを追加
3. フロントにフォームとリクエスト処理を追加
【非変更ファイル】
- ルーティング（変更なし）
- マイグレーション（カラム追加なし）
- モデル（スコープ追加不要）この段階でまだコードは1行も書かれていない。
Step 2. 設計をレビューする
Plan Modeの真価はここにある。この出力を見て、自分が判断できる。
「バリデーションリクエストは既存の共通クラスに追加でいい」「LIKE検索は部分一致にしてほしい」「フロントのファイル名が違う」——こういう修正をこの段階で伝えられる。
確認、ありがとう。
2点修正してほしい:
- バリデーションは既存の UserRequest.php に追加してほしい（新規ファイル不要）
- LIKE検索は部分一致（%keyword% 形式）で
修正したプランを再度見せてClaude Codeが修正した計画を出し直す。これを必要なだけ繰り返す。
Step 3. 実装を依頼する
設計に納得したら、通常モードに戻して実装を依頼する。
# Shift+Tab で Plan Mode を解除してから
このプラン通りに実装してClaude Codeは確認済みの計画に沿って実装する。方向違いのやり直しがほぼ発生しなくなる。
実践例：機能追加をPlan Modeで進める
もう少し具体的な例を見てみよう。
「ダッシュボードにCSVエクスポートボタンを追加したい」というタスクをPlan Modeで進める場合。
まずPlan Modeで指示ダッシュボードのユーザー一覧にCSVエクスポートボタンを追加したい。
- ボタンを押したら現在の絞り込み条件を反映してエクスポート
- ダウンロードはブラウザで直接（別ウィンドウ不要）
- バックエンドNode.js + Express、フロントReact
変更ファイルと手順だけ教えて以下の実装計画を提案します。
【新規ファイル】
- server/routes/export.js — CSVエクスポートのAPIエンドポイント
- server/services/csvBuilder.js — CSV生成ロジック（json2csvライブラリ使用）
【変更ファイル】
- server/routes/index.js — exportルートの追加
- client/src/pages/Dashboard.jsx — エクスポートボタンの追加
- client/src/api/index.js — エクスポートAPI呼び出し関数の追加
【処理フロー】
1. フロント: 現在のfilter状態をクエリパラメータに変換
2. API: /api/export?... でGETリクエスト
3. サーバー: クエリに基づいてDBから取得 → CSV変換
4. レスポンス: Content-Type: text/csv で返す
5. フロント: Blob URLでダウンロードトリガー
【ライブラリ追加】
- json2csv（npm）: CSVシリアライズ用この時点で「あ、json2csv使うんだ。うちの環境にそれないな。既存でCSVを作る処理がutils/csvExport.tsにあるから、それ使ってほしい」と気づける。
utils/csvExport.ts に既存のCSV生成関数がある。
新しいライブラリを追加せず、それを使う形にプランを修正して修正計画が出てきたら確認して、OKなら実装へ。
設計段階でこの調整ができたのと、実装後にやり直しになるのとでは、消費するトークン量・時間・精神的コストが全然違う。
Plan Mode + サブエージェントの組み合わせ
大きめのタスクでは、Plan Modeで全体設計を確認してから、サブエージェントで並行実装という組み合わせが効く。
# まずPlan Modeで全体計画を作る
（Shift+Tab でPlan Mode）
認証システムをJWT方式に置き換えたい。
全体の変更計画を、フロントエンド/バックエンド/テストに分けて見せて
# 計画を確認して合意してから...
# サブエージェントに分割して並行実装
claude --subagent "さきほどの計画に従い、バックエンド側（auth.ts, middleware/jwt.ts）を実装して"
claude --subagent "さきほどの計画に従い、フロントエンド側（hooks/useAuth.ts, pages/Login.tsx）を実装して"設計が共有されているので、バックエンドとフロントエンドの実装が噛み合う可能性が高くなる。設計なしで並行させると、APIのレスポンス形式がズレていたりして後で泣きを見る。
ただしこのワークフローはタスクが大きいときの話で、小さい修正にこれをやると単純に手間が増えるので注意。
Plan Modeが不要なケース
Plan Modeは万能じゃない。これを使うべきでないシーンもある。
1. 明確なバグ修正「このエラーを直して」「この変数がnullになる原因を調べて直して」みたいなケースは、問題が特定されていて、解決の方向性がほぼ一つに収束する。プランを挟む意味が薄い。
2. 一行レベルの小さい変更「このコメントの誤字を直して」「変数名をuserIdからaccountIdに変えて」——これにPlan Modeをかましたら、「そのうち変えます」という一文のプランが出てくる。時間の無駄なので直接やらせた方がいい。
3. 試行錯誤が前提のスパイク「このAPIをどう使うか試してみたい」「パフォーマンスがどれくらい改善するか実測したい」みたいな探索的な作業は、設計よりもまず動かしてみることが目的。Plan Modeで固めてしまうと逆に柔軟さが失われる。
要するに「方向を間違えたら大きなやり直しが発生しそうなタスク」がPlan Modeの出番。小さくて明確なことには使わない。
トークン節約効果の話
Plan Modeがトークン節約になるというのは、直感に反するかもしれない。「設計でも1ターン使うなら、むしろ増えるんじゃ？」と思う人もいるはずだ。
計算してみると実は逆で、節約になる。
たとえば「機能追加→方向違い→やり直し→また少し違う→もう一回」という3回試行のパターンを考えると、
- 1回の実装で Claude Codeが触るファイル数: 5〜10ファイル
- ファイルを読む+書くトークン: 1実装あたり数千〜数万トークン
- 3回の試行で: その3倍
一方Plan Modeを使うと、
- 設計フェーズ: 読む量は少ない（ファイルの中身を全部読まなくていい）、書くのはテキストのみ
- 設計修正が1〜2回: 軽い会話で済む
- 実装は1回: トータルで1.2〜1.5回分くらいの消費
試行錯誤の回数を減らすことが、結果的にトークン節約になるという構造だ。
自分の体感では、複雑なタスクでPlan Modeを使うと、やり直しが発生しなかった分でだいたい30〜40%のトークン削減になっている。
まとめ
Plan Modeは地味なのに、使い始めてから「Claude Codeの出力に対してイライラする回数」がはっきり減った。
それまでは「なんか違う→やり直し」を繰り返していたのが、設計をレビューする機会ができたことで、「違う方向に進んでいく前に止める」ことができるようになった。
Shift + Tab というキーボードショートカット1つで入れるので、まず試してみてほしい。特に「このタスク、何ファイルに影響するか分からないな」「方針を間違えたくないな」と感じたタイミングで使うと、効果が体感しやすい。
「設計してから実装する」は人間のエンジニアでも当たり前にやること。Claude Codeと組む時も、同じ流れを意識するだけで、出力の品質が上がって手戻りが減る。
やることはShift + Tabを押すだけなので、損はない。
関連記事
