結論: Claude Code Plan Modeは、AIが実装を始める前にコードの変更計画を提示・承認させる機能です。/planコマンドまたはShift+Tabで即座に切り替えられ、「実装暴走」を防ぎながら大規模修正・削除作業・DBマイグレーションを安全に進められます。
この記事の要点:
- Plan Modeとは何か・通常モードとの違い・有効な7つのシチュエーション
- コピペ可能な起動プロンプト5つ＋7活用パターン別の具体的な使い方
- 失敗パターン3個（承認なし実行・Plan肥大化・部分実行中断）と回避策
対象読者: Claude Codeを使い始めたエンジニア・開発チームのリーダー・Claude Codeを業務導入している企業担当者
読了後にできること: 今日から/planコマンドを使い、AIの「暴走実装」を防ぐ安全なコーディングフローを構築できる
「え、もう変更されてる……」
先日、ある研修先でこんなシーンに出くわしました。受講者のひとりがClaude Codeに「認証フローを改善して」と投げたら、5分後にはOAuthの実装が半分終わっていた。方向性は悪くなかったんですが、そのチームが想定していたライブラリとは違うものが使われていて、コードレビューが大変なことになっていたんです。
これ、Claude Codeに限らず「AIに自由に動かせすぎた」ときに起きがちな問題なんですよね。意図とズレた実装が始まってしまい、途中で止めると中途半端な状態になる。Plan Modeは、まさにこのケースのために設計された機能です。
Claude CodeのPlan Modeは、AIが「計画を立てて承認をもらってから実装する」という動き方に切り替わるモードです。Anthropicが公式ドキュメントで推奨するExplore→Plan→Implement→Commitワークフローの核心部分でもあります。この記事では、Plan Modeの仕組みから7つの活用パターン、チームでの共有手順まで、コピペ可能なプロンプトつきで全部解説します。
個人的には、Plan Modeを知ってから「AIコーディング怖い」という感覚がかなり薄れました。ぜひ今日から試してみてください。
Claude Code完全ガイド（導入から実務活用まで）はこちらでまとめています。Plan Modeだけでなく全体的な使い方を学びたい方は先にご覧ください。Claude Codeを含むAIエージェント全般の導入戦略についてはAIエージェント導入完全ガイドもご参照ください。
Plan Modeとは何か——通常モードとの決定的な違い
Claude Codeには現在6つのパーミッションモードがあります（公式ドキュメント、参照日: 2026-06-03）。Plan Modeはそのうちの一つで、最大の特徴は「Claude がファイルを読んでも、ソースコードを絶対に書き換えない」という点です。
通常モード（default）では、Claude Codeはファイル読み込みを自由に行い、ファイル編集やコマンド実行のたびに都度確認を求めます。一方Plan Modeでは、ファイル読み込みや探索は自由ですが、コードの変更は一切行いません。代わりに「こういう手順で実装しようと思いますが、どうですか？」という計画書を出してきます。
| モード | ファイル読み込み | ファイル編集 | コマンド実行 | 使いどころ |
|---|---|---|---|---|
| default | 自動承認 | 都度確認 | 都度確認 | 通常作業 |
| acceptEdits | 自動承認 | 自動承認 | 一部自動承認 | 素早くコード改善 |
| plan | 自動承認 | 不可（計画のみ） | 探索コマンドのみ | 大規模修正前の検討 |
| auto | 自動承認 | 自動承認 | 分類器による自動判断 | 長時間の自律タスク |
| dontAsk | 自動承認 | 事前承認済みのみ | 事前承認済みのみ | CI/CD環境 |
| bypassPermissions | 自動承認 | 自動承認（全て） | 自動承認（全て） | 隔離コンテナのみ |
Plan Modeのキモは「承認フロー」にあります。計画を提示された後、以下の4つの選択肢から次のアクションを選べます（公式ドキュメント、参照日: 2026-06-03）:
- Approve and start in auto mode（自動モードで実装開始）
- Approve and accept edits（ファイル編集を自動承認して実装開始）
- Approve and review each edit manually（各編集を手動で確認しながら実装）
- Keep planning with feedback（計画にフィードバックして更に詰める）
3番目の「手動で確認しながら」を選べるのがポイントで、大規模修正でも「計画はOKだけど、1ファイルずつ確認したい」という使い方ができます。
また、Ctrl+Gを押すとテキストエディタで計画を直接編集してから実装に進めます。「このステップは順番を入れ替えたい」「このファイルは触らなくていい」という細かい調整がエディタ上でできるのは、実際にやってみると非常に便利です。
Plan Modeの起動方法——/planコマンドとShift+Tab
Plan Modeの起動方法は主に3つあります（Anthropic公式ドキュメント、参照日: 2026-06-03）:
方法1: /planコマンド（最も簡単）
プロンプトの冒頭に/planと入力するだけです。そのプロンプトだけPlan Modeで処理されます。
/plan 認証モジュール（src/auth/）のセッション管理を確認して、JWTトークンのリフレッシュフローがどうなっているか把握してから、実装計画を立ててください。方法2: Shift+Tabキー（セッション全体を切り替え）
Claude Codeのターミナルセッション内でShift+Tabを押すと、モードが順番に切り替わります。default → acceptEdits → plan → （自動承認要件を満たした場合はauto）というサイクルです。現在のモードはステータスバーに表示されます。
Windowsで「Shift+TabがautoとdefaultしかサイクルしてPlanが出ない」という問題が報告されています（GitHub Issues、参照日: 2026-06-03）。その場合は/planコマンドを使うか、Alt+Mで代替できます（Claude Code v2.1.0以降）。
方法3: 起動オプション（デフォルトをPlan Modeにする）
# 起動時にPlan Modeで開始
claude --permission-mode plan
# プロジェクトのデフォルトをPlan Modeに設定（.claude/settings.json）
{
"permissions": {
"defaultMode": "plan"
}
}「このプロジェクトはセンシティブなコードが多いから、デフォルトでPlan Modeにしたい」という場合は設定ファイルに書いておくのがおすすめです。私が顧問先に提案するときは、本番環境のコードを扱うリポジトリには.claude/settings.jsonでplan modeをデフォルト設定しています。
Anthropic推奨フローと/planの位置づけ
Anthropicは公式ドキュメントで、Claude Codeの理想的な作業フローを4段階で定義しています（公式Best Practices、参照日: 2026-06-03）:
- Explore（探索）: Plan Modeでコードベースを読み込み、現状を把握する
- Plan（計画）: 実装計画を作成・承認する
- Implement（実装）: Plan Modeを解除して実装を進める
- Commit（確定）: コミットメッセージを作成してPRを出す
探索と実行を分離することで、間違った問題を解決するリスクを避けられる。
— Anthropic公式ドキュメント Best Practices（参照日: 2026-06-03）
このフローの肝は「探索と実装を混在させない」ことです。Plan Modeで十分に現状を把握してから計画を立て、承認してから実装に入る。この順序を守るだけで、「方向性がズレた実装を止められなかった」という事故が激減します。
ただし、Anthropicも「Plan Modeはオーバーヘッドがある」と明示しています。変更箇所が1ファイルで内容も明確な修正（タイポ直し、変数名リネームなど）は普通に進めた方が速い。Plan Modeが本領を発揮するのは「変更が複数ファイルにまたがる」「修正前にコードベースをきちんと理解したい」「変更の影響範囲が不明確」な場面です。
コピペ可能プロンプト5選——今日から使えるPlan Mode起動テンプレ
以下はすべてそのままコピペして使えます。[ ]は自分の状況に書き換えてください。
プロンプト1: 新機能追加前の探索・計画
/plan [対象ディレクトリ（例：src/auth/）]を読んで現在の実装を理解したうえで、[やりたいこと（例：Google OAuth連携）]を追加する計画を立ててください。
特に以下の点を明確にしてください:
- 変更が必要なファイルのリスト
- 既存コードへの影響範囲
- 実装の順序とステップ
- テストが必要な箇所
計画が固まったら実装には進まず、私の確認を待ってください。プロンプト2: 大規模リファクタリング前の影響分析
/plan [対象機能名]のリファクタリングを計画してください。
まず以下を調査してください:
- 現在の実装の問題点
- 変更が影響するファイルと依存関係
- リファクタリング後の理想的な構造
- 段階的に進める場合のフェーズ分け
コードは変更せず、計画書だけ作成してください。プロンプト3: DBマイグレーション前の安全確認
/plan [マイグレーションの内容（例：usersテーブルにlast_login_atカラムを追加）]を安全に実行する計画を立ててください。
確認してほしい点:
- 既存データへの影響
- ロールバック手順
- ダウンタイムの有無
- 関連するアプリケーションコードの変更が必要か
本番環境に近いデータ量でも問題ないかも含めて計画してください。プロンプト4: セキュリティ修正前のリスク評価
/plan [セキュリティ課題の説明（例：SQLインジェクション脆弱性がレポートされた箇所）]の修正計画を立ててください。
以下を含めてください:
- 影響を受けるファイルと行番号
- 修正アプローチの選択肢（とトレードオフ）
- テスト方法
- 修正後の確認手順
計画確認後に実装に移ります。プロンプト5: 大量ファイル削除・整理前の確認
/plan [削除・整理の対象]を整理する計画を立ててください。
以下を確認してから計画を作成してください:
- 削除対象のファイルが本当に不要であることの確認
- 他のコードからの参照・依存関係
- 安全に削除できる順序
- 万が一のためのバックアップ手順
絶対にファイルを削除しないでください。計画書だけ作成してください。Plan Modeが特に効果を発揮する7つのシチュエーション
シチュエーション1: 新機能追加（複数ファイル変更が見込まれる場合）
新しいAPIエンドポイントを追加する、認証フローを変える、外部サービスとの連携を追加するなど、複数のファイルにまたがる変更が予想される場合はPlan Modeから始めましょう。
私が顧問先で「Google Calendar連携を追加したい」という依頼を受けたとき、Plan Modeで計画を作らせたら「バックエンドAPIだけでなく、フロントエンドのフォームコンポーネント3ファイルと、既存のスケジュール管理モジュールにも影響がある」という点が計画段階で判明しました。これを通常モードで始めていたら、途中で止めることになっていたと思います。
事例区分: 想定シナリオ
100社以上の研修・顧問経験をもとに構成した典型的なパターンです。
シチュエーション2: 大規模リファクタリング
「このモジュールの設計が古いから整理したい」という作業は、Plan Modeなしで始めると迷子になりやすいです。依存関係の把握が甘いまま実装を始めると、動いていたコードが壊れます。
/plan src/legacy/payment/ ディレクトリの実装を確認して、現代的なパターンに整理するための段階的なリファクタリング計画を立ててください。既存のテストが通ることを前提に、安全に進められる順序を示してください。シチュエーション3: モノレポのクロスパッケージ更新
モノレポ構成で共通ライブラリを変更すると、複数のパッケージに影響が出ます。Plan Modeで「どのパッケージのどのファイルが影響を受けるか」をリストアップしてから進めると、変更漏れを防げます。
シチュエーション4: DBスキーマ変更・マイグレーション
DBのスキーマ変更は取り返しがつきません。本番データへの影響、ロールバック手順、アプリケーション側のコード変更の三点セットを計画段階でまとめておくことが重要です。
/plan ordersテーブルにstatusカラム（ENUM型: pending/processing/completed/cancelled）を追加するマイグレーションを計画してください。既存の注文データへの影響、アプリケーション側で変更が必要なファイル、ロールバック手順を含めてください。シチュエーション5: ファイル・コードの大量削除
「不要になったファイルを整理したい」「deprecatedなコードを削除したい」という作業はリスクが高いです。「参照されていないと思っていたファイルが実は使われていた」というケースは珍しくありません。Plan Modeで依存関係を全部洗い出してから削除に入りましょう。
シチュエーション6: セキュリティ脆弱性の修正
セキュリティ修正は「直したつもりが別の穴を作った」という事故が起きやすい領域です。修正のアプローチと影響範囲を計画段階でレビューすることで、セカンドオピニオン的なチェックができます。
シチュエーション7: 初めて触るコードベースへの変更
引き継ぎや新しいプロジェクトへの参加直後は、「このファイルがどこから呼ばれているか」が頭に入っていません。Plan Modeで探索させながら計画を立てることで、コードベースの理解と実装計画を同時に進められます。
5ステップ実装フロー——最初から最後まで安全に進める手順
- Plan Modeを起動して探索を依頼する:
/planコマンドで関連コードの読み込みと現状把握を指示します。このとき「計画書だけ作成してください。実装には進まないでください」と明記するのが重要です。 - 計画書をレビューする: Claudeが提示した計画を精査します。変更ファイル一覧、変更の順序、テスト手順が揃っているか確認。不明点はこの段階でフィードバックします。必要ならCtrl+Gでエディタを開いて計画を直接編集してください。
- 承認モードを選択して実装を開始する: 計画に問題がなければ承認します。「各編集を手動で確認」か「自動承認で実装」かを作業の重要度に応じて選んでください。
- 実装中にずれを感じたら即Escで止める: 実装が計画通りに進んでいるか確認しながら進みます。「あれ、計画と違う」と感じたらEscキーで止めて、
/rewindで状態を戻せます。 - テスト実行→コミット→PR作成: テストが全部通ることを確認してコミット。コミットメッセージも「commit with a descriptive message and open a PR」でClaude Codeに任せられます。
【要注意】よくある失敗パターンと回避策
失敗パターン1: Plan承認なしにExecuteモードへ移行してしまう
❌ よくある間違い: 「大体わかったから早く実装に入りたい」という気持ちで、計画書を流し読みして即承認→実装を始めたら想定外のファイルが変更された。
⭕ 正しいアプローチ: 変更ファイルのリストを確認して、「このファイルは想定外じゃないか？」を必ずチェックしてから承認する。特にpackage.jsonやtsconfig.jsonなど設定ファイルが計画に含まれているときは要注意です。
実際に研修先で、「ライブラリのバージョンを上げて」という指示に対して、Claude Codeが計画書の中にpackage.jsonとpackage-lock.json以外にも.nvmrcとDockerfileの変更を含めていて、「そこまでは想定してなかった」というケースがありました。Plan Modeがあったから事前に気付けた例です。
事例区分: 想定シナリオ
100社以上の研修・顧問経験をもとに構成した典型的なパターンです。
失敗パターン2: 計画が長すぎて実装で迷子になる
❌ よくある間違い: Plan Modeで「全体を最適化してほしい」と広い範囲を任せると、30ステップ以上の巨大な計画書が出てきた。承認して実装を始めたら、どこまで進んだか分からなくなった。
⭕ 正しいアプローチ: 1回の計画は「フェーズ1の5ステップ」くらいの粒度に絞る。大きな作業は複数のPlanに分割して、各フェーズを完了してからコミットし、次のフェーズの計画を立てる。
なぜ重要か: Claudeのコンテキストウィンドウは有限です。長大な計画を持ちながら実装を進めると、コンテキストが埋まりやすくなり、後半でパフォーマンスが低下することがあります。
失敗パターン3: 部分実行で中途半端な状態になる
❌ よくある間違い: Plan Modeで計画を承認して実装が進んでいたが、途中で「やっぱり方向性を変えたい」と思って強制終了した。ファイルが半分書き換わった状態になった。
⭕ 正しいアプローチ: 途中で止めたくなったらEscキーで止め、/rewindコマンドでチェックポイントまで戻る。Claude Codeはすべてのファイル変更前にスナップショットを自動保存しているので、コードとセッション両方を安全に巻き戻せます（公式ドキュメント、参照日: 2026-06-03）。gitの代替ではないので、重要な作業前には必ずgit commitを済ませてから使ってください。
失敗パターン4: Plan Mode内で探索が広がりすぎてコンテキストが枯渇
❌ よくある間違い: Plan Modeで「プロジェクト全体を読んで最適な実装を計画して」と指示したら、大量のファイルを読み込みすぎてコンテキストが不足した。
⭕ 正しいアプローチ: Plan Modeでの探索は「src/auth/を読んで」「usersモデルに関連するファイルだけ確認して」のように範囲を絞る。広い探索が必要な場合はサブエージェントに任せると、メインセッションのコンテキストを節約できます。
チームでのPlan共有手順——コードレビューにPlan Modeを組み込む
Plan Modeはシングルエンジニアのフローだけでなくチームのレビュープロセスにも組み込めます。
方法1: 計画書をファイルに保存してチームレビュー
Ctrl+Gでテキストエディタを開いたとき、計画内容をそのままPLAN.mdとして保存してからチームにレビューを依頼できます。「このPR対応の実装計画です」と共有すると、レビュアーが「この順序で大丈夫か」「このファイルを変更する必要はないのでは」と早期にフィードバックできます。
# PLAN.md例
## 実装計画: Google OAuth連携追加
### 変更するファイル
- src/auth/oauth.ts（新規作成）
- src/routes/auth.ts（エンドポイント追加）
- src/middleware/auth.ts（セッション管理更新）
- frontend/components/LoginButton.tsx（UIコンポーネント更新）
### 実装ステップ
1. Google OAuth認証情報の環境変数設定
2. oauth.tsの作成（認証フロー実装）
3. auth.tsへのエンドポイント追加
4. ミドルウェア更新
5. フロントエンドUI更新
6. テスト追加・実行方法2: ライター/レビュアーパターン
Anthropicが推奨するパターンです（公式ドキュメント、参照日: 2026-06-03）。Session AのClaude Codeが実装を進め、別のSession BのClaude CodeがPlan Modeで実装内容を独立してレビューします。
# Session B（レビュアー側）
/plan @src/auth/oauth.ts の実装内容を確認して、PLAN.mdの要件通りに実装されているか、セキュリティ上の問題がないかレビューしてください。コードは変更しないでください。方法3: CLAUDE.mdでチームのデフォルト設定
# CLAUDE.md（プロジェクトルートに配置）
## 実装ルール
- 3ファイル以上の変更が見込まれる場合は必ずPlan Modeで計画を作成してから実装に入ること
- DBマイグレーション・削除作業・認証フロー変更は常にPlan Mode必須
- 計画書はPLAN.mdに保存してからPRに添付するこのようにCLAUDE.mdに書いておくと、チームの誰がClaude Codeを使っても同じ運用ルールが適用されます。
Ultraplan——ブラウザベースのPlan Modeレビュー（2026年版新機能）
公式ドキュメントによると、計画を承認するときの選択肢の一つに「Refine with Ultraplan」が追加されています（公式ドキュメント、参照日: 2026-06-03）。UltraplanはClaude Code on the web上でブラウザベースの計画レビューを行う機能です。
チームで計画をレビューする場合や、ターミナルを離れて他のデバイスで確認したい場合に便利です。claude.ai/codeで動作するため、ローカル環境のセットアップなしにPlan Modeの計画をレビューできます。
VS Code・JetBrainsでのPlan Mode操作
ターミナル以外の環境でのPlan Mode操作方法も確認しておきましょう（公式ドキュメント、参照日: 2026-06-03）。
VS Code拡張機能: プロンプトボックス下部にあるモードインジケーターをクリックして「Plan mode」を選択。設定からclaudeCode.initialPermissionModeを”plan”にするとデフォルトをPlan Modeにできます。
JetBrains IDEプラグイン: ターミナルと同様にShift+Tabで切り替えるか、--permission-modeフラグを使います。
Desktop app: 送信ボタン横のモードセレクターから選択。視覚的なdiff表示と組み合わせると、計画から実装、変更確認まで一気に行えます。
Plan Modeを使うべきでないケース
Plan Modeは強力ですが、常に使うべきというわけではありません。Anthropicは「Planning is most useful when you’re uncertain about the approach, when the change modifies multiple files, or when you’re unfamiliar with the code being modified. If you could describe the diff in one sentence, skip the plan.」と明示しています（公式ドキュメント、参照日: 2026-06-03）。
具体的にはこんなケースはPlan Modeをスキップして問題ありません:
- 変数名を1箇所リネームする
- コメントを追加・修正する
- 既に把握している1ファイルのバグを直す
- ログ行を追加する
Plan Modeのオーバーヘッドは「探索→計画→承認」というラウンドトリップにあります。小さな作業にこれを挟むと、逆に作業が遅くなります。「このタスクをdiffで一文で説明できるか？」を自問して、できるなら通常モードで進めましょう。
まとめ：Plan Modeで「実装暴走」を防ぐ3つのアクション
Plan ModeはClaude Codeを安全に使うための最重要機能のひとつです。「AIコーディングは怖い」という感覚の多くは、「いつ何が変わるかわからない」という不安から来ています。Plan Modeはその不安を根本から解決してくれます。
1. 今日やること: 次の作業で/planコマンドを1回使ってみてください。特に複数ファイルに触れる作業や、初めて読むコードベースへの変更があれば絶好の機会です。
2. 今週中: チームの.claude/settings.jsonにPlan Modeのデフォルト設定を追加する。特にDBマイグレーションや認証コードへの変更前はplan必須とCLAUDE.mdに明記する。
3. 今月中: Plan Modeを使ったコードレビューフロー（PLAN.mdをPRに添付する、ライター/レビュアーパターン）をチームで試してみる。
次回予告: 次の記事では「Claude Code Agent Teamsでの役割分担設計」をテーマに、複数AIエージェントを協調させる実践的なパターンを解説します。
あわせて読みたい:
- Claude Code完全ガイド（ピラーページ） — 導入から本番運用まで体系的に
- Claude Code社内導入5ステップガイド — チームへの展開方法
- Claude Code Agent Teams完全ガイド — マルチエージェント並列実行
参考・出典
- Choose a permission mode – Claude Code Docs — Anthropic（参照日: 2026-06-03）
- Best practices for Claude Code — Anthropic（参照日: 2026-06-03）
- Overview – Claude Code Docs — Anthropic（参照日: 2026-06-03）
- Plan mode missing from mode cycle on Windows – GitHub Issues — anthropics/claude-code（参照日: 2026-06-03）
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
