「Claudeに任せたら、 想定と違う方向に走った」 — Claude Codeを使い始めた人の8割が経験するやつです。
これを防ぐ仕組みが Plan mode(プランモード)。Claudeに 「先に計画だけ立てて、実装は私が承認してから」 と指示できる、安全装置のようなモードです。
特に 大きな変更・リファクタ・複数ファイルにまたがる修正 で効きます。今日はこの使い方を整理します。
モードは3種類、Shift+Tabで切り替え
Claude Codeには 3つのモード があります。
モード | 動作 | 切替方法 |
|---|---|---|
Normal mode | 編集ごとに承認を求める(初期状態) | デフォルト |
Auto Accept | 編集を自動承認(高速) | Shift+Tab×1 |
Plan mode | 読み取りのみ、計画を立てる | Shift+Tab×2 |
Shift+Tabを押すと、 Normal → Auto Accept → Plan → Normal … とループ切替されます。Plan modeになると、ターミナル下部に ⏸ plan mode on と表示されます。
これがPlan modeの起動。
Plan modeで起きること
Plan modeに入っている時、Claude Codeは以下のように振る舞います。
- ファイルを読み取る — OK
- 検索する — OK
- **コマンドを 実行(読み取り系) する — OK
- ファイルを書き換える — NG(承認待ち)
- 新規ファイルを作る — NG(承認待ち)
つまり、 読み取り専用の調査モード。コードを書き換えずに、変更計画だけ作ってくれます。
「/login 機能を追加したい」と頼むと、こう返ってきます。
以下の計画で実装します。
1. /api/login のエンドポイントを作成
2. LoginForm.tsx をフロントエンドに追加
3. セッション管理(JWT)を実装
4. テストコード追加
承認しますか?
[Approve] [Reject with feedback]
私が承認すれば、Plan modeから 自動的にNormal mode に戻り、計画通りに実装が進む。
却下するとPlan modeのまま残り、Claudeがフィードバックを受けて 計画を再提示 してくれます。
いつPlan modeを使うか
「全部Plan modeで」とすると、 小さな修正にも計画フェーズが入って遅くなる ので使い分けが必要。
Plan mode推奨の場面
- 複数ファイルにまたがる リファクタリング
- 新機能 の追加(認証・課金・APIなど)
- データベーススキーマ変更(マイグレーション含む)
- CI/CD設定 の変更
- 本番環境の設定ファイル いじり
- 「これ進める前に道筋確認したい」と感じる時
Plan modeを使わなくていい場面
- 1ファイル内の小修正
- 文言調整・誤字修正
- 明確に決まっている定型作業
- ログ確認・デバッグ
- すでに何度もやった作業
ざっくり言うと、 「失敗したら戻すのが面倒な変更」 = Plan mode が判断軸。
Auto Acceptとの使い分け
Plan modeとよく対比されるのが Auto Accept。
- Plan mode — 慎重派、計画作って承認後に実行
- Auto Accept — 信頼派、毎回の確認をスキップして高速実行
Auto Acceptがハマる場面
- 信頼できる定型タスク
- 短時間で結果を見たい時
- 自動テストが整備されているプロジェクト
Plan modeがハマる場面
- 大きな変更
- 不可逆な操作が含まれる可能性
- レビュー前提の業務
両方を タスクの性質で使い分ける のが上級者の運用。
opus plan モード — 賢いPlanの作り方
少し細かい話。Opus 4.7 モデルでPlan modeを使う時、 Effort levelを opus-plan に切り替えると、計画の精度が上がります。
/model
で Opus (opus-plan) を選ぶと、 計画段階だけ高い思考レベル を使い、実装段階は通常モードに戻る、という最適化が走る。
「重要な変更の計画は念入りに、実装は速く」という運用に合います。私はメイン業務でこのモードに固定しています。
失敗例 — Plan modeなしで道を間違えた話
参考までに、私の最近の失敗を共有します。
社内ツールに「メール通知機能を追加して」と頼んだ時、Plan modeを使わずに依頼。Claudeが メール送信まわりを大幅にリファクタリング し始めて、 既存のSlack通知ロジックまで巻き込まれた 事故が起きました。
/rewind で戻したから良かったものの、 作業時間が2時間溶けた。
これがPlan modeを使っていれば、 計画段階で「Slackロジックは触らない」と指定 できたはず。15分の余分な手間で、2時間の事故を防げたわけです。
私の運用ルール
参考までに、私のClaude Code運用フロー。
- 新規機能・大きなリファクタ → Plan mode で開始(Shift+Tab×2)
- 小さな修正・定型作業 → Normal modeのまま
- テストや確認作業 → Auto Accept(高速化)
- 重要変更の前後で git commit(
/rewindの保険)
このルールで、 作業の3割をPlan modeで処理 する形になります。
「便利だけど面倒」と最初は感じるPlan modeですが、 大事故を1回防げばペイ する仕組みです。
まとめ
- Plan modeは Shift+Tab×2 で切替、 読み取り専用の計画モード
- 計画承認後に 自動でNormal modeに戻って実装 が進む
- 推奨場面 — 大きな変更・複数ファイル・不可逆な操作
- 不要場面 — 1ファイル内の小修正・定型作業
- Auto Acceptとは 使い分け、タスクの重要度で選ぶ
- Opus 4.7なら
opus-planEffort level で計画精度が上がる - 失敗から戻す手間 を考えると、大きな変更にはPlan modeが安い
Plan modeを覚えると、Claude Codeに 大胆な作業を任せられる ようになります。今日のうちに、Shift+Tab×2 を一度試してみてください。
