実装指示をそのまま投げると、Claude は「とりあえず動けばいい」で実装し始める。リファクタリングや新規機能追加で手戻りがちな人は、まず Plan モードで設計を固めてから渡せば、実装精度が爆上がりする。
前提：Plan モードは「設計の安全地帯」だ
Plan モードは @plan（または /plan）で起動する。このモードではモデルがファイルの書き換えやコマンド実行をせず、読み取り専用でリポジトリを解析し、設計書とステップ計画を出力するだけだ。設定ファイルの追加は不要だが、リポジトリ直下に CLAUDE.md を置いておけば、既存のビルドコマンドやテスト方針を解析の前提条件として自動で参照し、設計の現実味が向上する。
実際の手順：設計固定→実転換の3ステップ
実際のワークフローは以下の3ステップで回す。コンソール上でそのままコピペして試せる。
1. Plan モード起動＆設計指示
変更範囲と制約条件を明確に指定して /plan を叩く。
/plan
src/features/auth/ ディレクトリを、JWT から OAuth2.1(PKCE) へ移行する。
既存のテストを壊さず、移行用アダプタ層を挟む設計を提案して。
変更するファイル一覧と、依存関係の変化も明記すること。
Claude は CLAUDE.md の規約を参照しつつ、読み取り専用でコードベースをスキャンし、設計書とタスク分解を返す。この段階では一切のファイル操作が発生しないため、破壊的な変更のリスクをゼロにできる。
2. 設計のレビュー＆合意
出力された設計書に問題がなければ、以下のように実装モードへ移行する。
この設計で合意。Agent モードで実装を開始して。
ステップ1から順に実行し、完了したらテストも回すこと。
ここで重要なのは、設計書を丸ごとコピペしないことだ。Claude はすでにセッションコンテキストに設計書を保持している。合意の一言で、計画を「実行動作」に転換できる。
3. 実装実行＆検証
Agent モードに切り替わると、Claude は計画通りファイルを作成・修正し、テストを実行する。途中のコンフリクトや依存不足は自動で解消してくれるが、複雑な変更の場合は /compact でコンテキストを圧縮し、設計書の重要な決定事項だけを会話の冒頭に固定すると、実装時の精度が安定する。
効果・つまずき・コツ
効果（体感の before / after）
- before: 「この機能追加して」→ 実装→ テスト失敗→ 修正→ 再度テスト→ 3往復。
- after: Plan モードで設計レビュー→ 合意→ 実装→ テスト→ 1往復で完了。
- 設計段階で「既存のテストが壊れる」「循環参照が起きる」などのリスクが可視化され、実装の手戻りが体感で 30〜40% 減少した。また、コンテキストの無駄遣いが減り、長文の設計書でも末尾まで正確に読まれる。
つまずき・ハマりどころ
Plan モードの出力は「設計書」であり「実装指示書」ではない。ここで「コードをそのまま書いてください」と要求すると、モデルが設計と実装の境界で混乱し、中途半端なコード片や冗長な説明しか返さない。また、Plan モードはリポジトリ全体をスキャンするため、大規模プロジェクトでは解析に数秒〜数十秒かかる。即時性が求められるスクリプト作成やバグ修正には不向きだ。設計書が抽象的になりすぎると、Agent モードへ転換した後に「実装方針が曖昧だ」と再確認を促されるため、設計指示では「変更範囲」と「守るべき既存仕様」を明示する癖をつける。
コツ
- 設計書に「なぜその選択をしたか」の理由が含まれていれば、後々の保守性が段違いになる。
- 複雑な設計は
/compactで要約圧縮し、重要な決定事項だけをCLAUDE.mdや会話の冒頭に固定しておくと、実装時の精度が安定する。 - 設計レビュー時、モデルが依存解決で失敗しそうな箇所があれば、その場で「
package.jsonの依存関係も確認して」と追加指示を出す。
向かないケース・注意点
- 既存コードの 1〜2 ファイルのみを修正する場合：Plan モードの起動コストが割に合わない。
- 実験的なプロトタイピング：設計より試行錯誤が優先されるため、直接
/agentで回した方が速い。 - 注意：Plan モードの出力はあくまで提案であり、モデルの推論に基づいている。外部依存や環境設定に依存する設計は、実際のビルド/テストで検証する必要がある。機能やコマンド名はバージョンで変わりうるため、執筆時点の動作を基準にしている。
まとめ ＋ 次の一歩
- Plan モードは「設計レビューの往復」を 0 にし、実装の初回成功率を上げるための安全装置だ。
-
/plan起動 → 設計書レビュー → 「合意。実装して」の 3 行でワークフローが回る。 - 設計の品質が実装の品質を決定する。まずは大規模変更や新規機能追加から Plan モードを使い始め、設計レビューの習慣を身につけよう。
- 公式ドキュメント: https://docs.claude.com/en/docs/claude-code
筆者について / About the author
pendorix — 生成AI・LLM エンジニア（日本在住 / JLPT N1）。SESで約9年、Python・Java を中心に開発。現在はローカルLLM・RAG・生成AI実装に注力し、実測値と動くコードで検証した知見を発信しています。LLM / 生成AI 実装・DX支援のお仕事のご相談を歓迎します。
pendorix — GenAI / LLM engineer based in Japan (JLPT N1). ~9 years building software (Python / Java); now focused on local LLMs, RAG, and shipping practical GenAI systems — sharing hands-on, benchmarked findings. Open to LLM / GenAI implementation & DX opportunities.
GitHub: https://github.com/pendorix