Claude Codeで「いきなり実装」を防ぐPlan Modeとプロンプトテンプレ集

結論：Plan Modeで計画だけ出させてから、承認して実装に進む

Claude Codeに「いきなり実装されて意図と違う変更が出た」という事故を減らす一番早い方法は、計画フェーズと実装フェーズを明示的に分けることです。公式のベストプラクティスでも、調査→計画→実装→コミットの4フェーズに分ける運用が推奨されています。

この記事では、次の3点をまとめます。

• 公式のPlan Mode（--permission-mode plan）を使う方法
• 計画先行で依頼するためのプロンプトテンプレート
• 計画レビューで見る観点と、実装に進ませる／やり直させる判断基準

CLIフラグの全体像は基本コマンド記事、最初の機能追加の通しフローは最初の機能追加の手順にまとめてあるので、操作そのものに不安がある方は先にそちらを読んでください。

Plan Modeとは：読み取り専用で計画だけ出させるモード

Plan Modeは、Claude Codeにファイル編集やシェルコマンド実行を許可せず、調査と計画だけを行わせるモードです。起動時にフラグで指定できます。

すでに対話セッションに入っている場合は、/permissionsや--permission-modeの切り替えでモードを変更できます。Plan Modeを抜けるには、セッション内で通常モード（default）に戻すか、いったんCtrl+Cで中断し、承認した計画を手元に置いたうえで普通のclaudeで実装セッションを開始する運用がやりやすいです。

計画だけ欲しいときの典型的な起動はこうなります。

Plan Modeでは、Claude CodeはReadやGrepといった読み取り系のツールだけを使い、EditやBashのような副作用のある操作を実行しません。結果として、計画文書（どのファイルをどう変える、どのテストを追加する、依存関係をどうする）だけが返ってきます。

プロンプトテンプレート1：計画だけを要求する最小形

最初は凝ったテンプレートよりも、「計画だけを先に出させる」ことを徹底するほうが効果があります。

## 依頼
src/forms/signup.ts のメールアドレス入力に空文字・@不在・ドメイン不正のバリデーションを追加したい。

## お願いすること（このターンではここまで）
1. 影響範囲のあるファイル一覧
2. 追加・変更する関数と、その入出力
3. 追加するテストケース（観点と期待値）
4. 触らないファイル／触らない関心事

## お願いしないこと
- 実装はしない
- パッケージ追加の提案以外で依存関係を変えない
- 別件の修正・リファクタを混ぜない

計画が出たらレビューする。良ければ「この計画で進めて」と返す。

ポイントは次の3つです。

• 「このターンではここまで」と出力の範囲を明示する
• 「やらないこと」を積極的に書いてスコープクリープを抑える
• 承認語（「この計画で進めて」）を決めておく

承認語を決めておくと、Claude Codeが「このまま実装してよいですか」と曖昧に聞いてきた際の摩擦が減ります。

プロンプトテンプレート2：調査→計画→実装→検証→報告

少し大きめのタスクには、4フェーズを依頼文に埋め込みます。公式ベストプラクティスの「Explore → Plan → Implement → Commit」に沿った形です。

## ゴール
既存の REST エンドポイント /users をページング対応にする。

## 進め方
1. まず Explore: src/api/users 配下と関連テストを読み、現状の仕様と呼び出し元を要約して
2. 次に Plan: 追加パラメータ、レスポンス変更、後方互換の扱い、必要なテストを箇条書きで出して
3. 計画レビュー: 私が「この計画で進めて」と返すまで実装しない
4. Implement: 計画通りに実装し、既存テストが落ちないことを `npm test` で確認
5. Report: 変更ファイル一覧・追加テスト・残タスクを要約して報告

## 制約
- 破壊的変更は避ける。どうしても必要な場合は計画で明示する
- 依頼外のリファクタ・整形・インポート並び替えは行わない
- 環境変数や秘密情報をテストに書かない

各フェーズのあいだで/statusや/costで状態を確認し、必要に応じて/compactで会話を圧縮すると、長いタスクでも精度が落ちにくくなります。操作の詳細は基本コマンド記事を参照してください。

プロンプトテンプレート3：バグ修正（症状→原因→修正計画）

バグ修正は、いきなり「直して」と言うと的外れな修正が返りやすい領域です。症状・仮説・検証手順を分けて依頼します。

## 症状
ログイン後、セッションタイムアウトで画面が真っ白になる。
- 再現手順: ログイン → 10分放置 → 任意の画面遷移
- 期待: 再ログイン画面にリダイレクト
- 実際: 空白画面（コンソールに 401 が出る）

## お願い
1. 想定される原因を src/auth/ の token refresh 周辺から3つまで挙げて
2. それぞれの検証方法（読むファイル・確認するログ・実行するテスト）を示して
3. 最も可能性が高い仮説を1つ選び、修正計画を出して（実装はまだしない）
4. 失敗を再現する失敗テストを先に書く計画にして

このテンプレートは「原因を複数出させ、仮説を1つ選ばせ、失敗テスト先行で書かせる」という三段構えになっています。最後の一文は、公式ベストプラクティスで繰り返し強調されている「Give Claude a way to verify its work」に対応します。

計画レビューで見る観点

計画が返ってきたら、次の観点で読みます。短くていいので、チェックリストとして手元に置いておくと効きます。

• 触るファイルが依頼の範囲に収まっているか
• 依頼外のリファクタ・削除・整形が紛れていないか
• 追加する依存（npm パッケージなど）はないか。あるなら理由は妥当か
• テストが書かれる予定になっているか（観点と期待値が具体的か）
• 後方互換や影響範囲の記述があるか
• 環境変数や秘密情報をテストデータに置こうとしていないか

気になる点があれば、「この依存は追加しないで、標準ライブラリで書いて」「テストは既存のjestに合わせて」のように1〜2文の修正だけ返します。いちど全部やり直させるより、計画だけを差分で直すほうが安定します。

実装に進ませるときの短い合図と、やり直させるときの指示

計画に問題がなければ、短い合図で実装に進ませます。

OK、この計画で進めて。実装と差分表示まで。テストはまだ流さない。

「テストはまだ流さない」のように停止点を明示しておくと、実装直後に差分を落ち着いてレビューできます。差分に問題がなければ、次のターンで「npm testを流して、落ちたらレポート」と続けます。

やり直させるときは、感情的な言い回しを避けて具体的に差し戻します。

計画を修正してほしい。
- user.service.ts は触らない（今回の対象外）
- メール正規化は既存の normalizeEmail() を使う
- テストは失敗再現の1ケースを先に書く構成にして

このパターンに慣れると、手戻りが減ります。

Plan Modeを使うと判断しやすいタスク／使わないほうが早いタスク

公式ベストプラクティスにもある通り、Plan Modeは常に必要ではありません。次の基準で判断します。

「1文で差分を説明できるなら計画は省く」と覚えておくと、過剰に重くなりません。

中断条件を依頼文に書いておく

計画先行運用をさらに安全にするには、中断条件（どこでClaude Codeに手を止めさせるか）を依頼文に書きます。例としては次のような条件です。

• テストが連続2回落ちたら、修正を続けずに失敗内容を要約して止める
• 依頼範囲外のファイルを編集しようとしたら、その時点で確認を求める
• 計画と実装が大きく乖離し始めたら、実装を止めて差し戻し案を出す

この中断条件は、本文に章立てで書くだけでも効きますし、CLAUDE.mdに共通ルールとして書いておくと毎回の指示が短くなります。CLAUDE.mdの書き方はCLAUDE.mdの書き方を参照してください。

まとめ：テンプレートは3つ、運用は「計画→承認→実装→検証」

Claude Codeの「勝手に実装される」を減らすコツは、難しい設定ではなくプロンプトと運用の型です。

• 最小テンプレート: 計画だけ出させる
• 通しテンプレート: Explore→Plan→Implement→Report
• バグテンプレート: 症状→原因→失敗テスト先行→修正計画

Plan Mode（--permission-mode plan）は、この型を強制するための公式機能です。頭で分けるだけでなく、モードとして分離しておくと、ついうっかり実装まで走る事故が物理的に防げます。

次のステップとしては、最初の機能追加の手順で通しのワークフローを体験し、基本コマンドで/status・/compact・/clearの使い分けを押さえると、計画先行運用が日常の開発に定着します。