Claude Code Plan Modeの使い方：承認前に計画を見直す手順

価値があるのは、承認前に見落としていた呼び出し元に気づいたり、既存のインターフェース仕様を守ったり、不要なデータベース変更を取り除いたりできることです。詳しい計画を立てる意味は、それによって判断が変わるかどうかにあります。

Claude Code Plan Modeでできること

Plan Modeでは、Claudeがコードベースを調べ、変更案をまとめます。ファイルの読み取り、調査用コマンドの実行、計画の書き出しは可能です。通常、ソースコードの編集は承認するまでブロックされます。工事で壁を動かし始める前に、改修図面を確認するようなものです。Anthropicの計画ワークフロー。

ただし、公式ドキュメントには重要な例外が記載されています。対話型ターミナルセッションで権限チェックをスキップするbypass permissionsが利用可能な場合、Plan Modeのブロックは適用されません。 Claudeへの指示は引き続き計画の作成ですが、編集を試みると実行できてしまいます。--allow-dangerously-skip-permissionsでbypassを利用可能にした場合も、現在のモードとして選択していなくても、この例外に含まれます。承認するまでソースコードを編集させたくない場合は、bypassを有効にせず起動してください。Anthropicの権限モードのルール。

計画のワークフローと権限システムは連動しています。計画にはClaudeが何を変更するつもりかが記され、権限モードは、確認を求めずに実行できる操作を制御します。

Plan Modeの起動方法と終了方法

ターミナルで最初からPlan Modeを使うには、次のコマンドを実行します。

claude --permission-mode plan

すでにセッションを開始している場合は、次の操作を使います。キーを何回押したかではなく、モード表示を確認してください。

autoから切り替えると、default（Manual）、acceptEdits、planの順に進みます。その後に利用可能な任意のモードが続き、bypass permissionsが先、autoが最後になります。Windowsでは、NodeまたはBunランタイムがVT入力モードを有効にしない場合の代替操作として、AnthropicはAlt+Mを案内しています。モードの切り替え、キーボード操作リファレンス、コマンドリファレンス。

Claudeが計画を提示すると、承認画面で次の選択肢を選べます。

• **No, keep planning（承認せず、計画を続ける）**を選び、具体的な修正点を伝えます。
• **Yes, manually approve edits（承認し、編集は個別に確認する）**を選ぶと、方針を承認しつつ、各編集を個別にレビューできます。
• 利用可能な場合は、**Yes, and use auto mode（承認してautoモードを使う）**を選び、autoモードで続行できます。

autoモードが利用できない場合、自動化の選択肢は、編集を自動承認するものになります。bypassを有効にしてセッションを開始していた場合は、その選択肢でbypass permissionsに切り替わります。選ぶ前に、表示されたモードを確認してください。承認するとPlan Modeが終了し、選んだ権限で実装が始まります。Shift+Tabでの切り替えでもPlan Modeは終了しますが、提案された計画を承認したことにはなりません。計画承認時の動作。

エディターの画面から使う場合、VS Codeではプロンプトの下にあるモード表示をクリックしてPlanを選びます。DesktopのCodeタブでは、Sendの横にあるモード選択を使います。JetBrainsでは、内蔵ターミナルでCLIの操作を使います。また、変更履歴には、v2.1.280からVS Codeで/planの入力に対応したことが記載されています。各画面での操作、公式変更履歴。

Plan Modeで押さえておきたい設定

プロジェクトのターミナルセッションをPlan Modeで開始するには、.claude/settings.jsonに次の設定を追加します。

{
  "permissions": {
    "defaultMode": "plan"
  }
}

ユーザー全体のターミナルの既定値にする場合は、~/.claude/settings.jsonを使います。起動フラグは設定ファイルより優先され、プロジェクト設定や管理設定によってユーザーの既定値が上書きされることもあります。VS Codeには独自の起動設定があり、VS Codeのユーザー設定で"claudeCode.initialPermissionMode": "plan"を指定します。拡張機能は、起動時の権限モードを決める際にプロジェクト設定を読み取りません。起動モードの設定。

次の追加キーは、Claude Code設定のpermissionsの外側、最上位に置きます。

これらは別々の設定です。計画の保存先、計画中のコマンドをどう確認するか、会話を消去する承認オプションを表示するかを、それぞれ指定します。設定リファレンス、計画の保存先、コンテキスト消去の選択肢。

コンテキストを消去するなら、制約、未決事項、受け入れ基準を計画そのものに書き込んでください。そうしないと、実装時には参照できない会話の内容を前提にすることになります。

Plan Modeとautoモードはどう使い分ける？

Plan Modeは、実装に進む判断をレビューまで保留します。autoモードは、別の分類モデルに操作を評価させることで、日常的な権限確認を減らします。分類モデルが確認するのは、操作が権限上の問題を起こさないかどうかです。計画のレビューでは、提案された設計が解くべき問題を正しく解決するかを確認します。

autoモードが利用可能で、useAutoModeDuringPlanが有効のままなら、この分類モデルは計画中のシェルコマンドも審査します。承認されたコマンドは実行され、拒否されたコマンドはブロックされます。autoが利用できない場合、またはこの設定を無効にした場合は、組み込みの読み取り専用コマンドの範囲を外れるコマンドについて確認が表示されます。重要なパスの削除には別の処理があり、対話型ターミナルでのbypassの例外は優先して適用されます。計画中だからといって、すべてのシェルコマンドが読み取り専用とは限りません。 計画中のコマンド実行。

実装時には、defaultは手動レビューを意味し、acceptEditsは対象範囲内の編集や一般的なファイルシステムのコマンドを、ドキュメントに記載された例外を除いて自動で許可します。autoでは、バックグラウンドでの操作の審査が加わります。いずれのモードも、アーキテクチャの良し悪しを判断してくれるわけではありません。権限の選び方は、Claude Code Auto Modeの解説で詳しく取り上げています。

現在のドキュメントでは、v2.1.283以降、対話型ターミナルとVS Codeのセッションにおける標準の起動モードはautoとされています。ただし、設定、組織、利用可否に関するルールが適用されます。そのため、Plan Modeでの起動を明示的に設定する意味は今もあります。現在の起動モードのルール。

古い手順では、重要な変更を見落とすことがあります。Anthropicの変更履歴には、v2.1.72での/planへの説明引数の追加、v2.1.81でのコンテキスト消去オプションの既定での非表示化、v2.1.218での、autoを使った計画中に読み取り専用か判定が難しいBashコマンドを分類モデルが扱う仕組みの導入が記録されています。公式変更履歴。

実践例：請求額を変えずに料金計算を共通化する

具体的なリファクタリングを考えてみます。あるアプリケーションでは、購入時の料金をAPIで計算し、更新時の料金をバックグラウンドワーカーで計算しています。目標は料金ルールの共通化ですが、それぞれの呼び出し元が持つ丸め処理と割引の挙動は維持したいとします。ここで示すのは説明用の計画例です。検証済みリポジトリの実施報告でも、Claudeが必ず出力する内容でもありません。

Plan Modeに入り、守るべき制約を具体的に伝えます。

関連するプロジェクトのファイルが、次の構成だとします。

最初の草案では、共通の計算処理を抽出し、両方の呼び出し元を切り替え、古いヘルパーを削除してテストを更新する、という提案が出るかもしれません。すっきりした手順に見えますが、まだ不十分です。購入処理と更新処理で丸めるタイミングが違っていたら、どうなるでしょうか。

承認する前に計画を編集します。 レビュー時にCtrl+Gを押し、早い段階で古い処理を削除する手順を、次の内容に置き換えます。

計画を保存して元の画面に戻ります。まだ修正が必要なら、計画を続ける選択肢を選び、この修正内容と計画全体の整合性を取るようClaudeに依頼します。必要なのは、矛盾する削除手順を取り除くことです。その下に注意書きを付け足すだけでは足りません。直接編集することも、計画を続けることも、公式に案内されているワークフローの一部です。Anthropicの調査・計画・実装のガイド。

修正後の計画は、実装に移せる次のような順序になっているはずです。

1. 既存の挙動をテストに記録する。 購入時と更新時の現在の金額について、丸めの境界、割引、不正な入力を含むテストケースを追加します。期待する結果が不明なケースは、先に解決します。
2. アダプターの背後に共通の料金計算ポリシーを導入する。 既存の各関数の入力、出力、エラー時の挙動を維持します。呼び出し元による違いを明示します。
3. 呼び出し元を段階的に移行する。 購入処理を更新して検証し、その後に更新処理を切り替えます。無関係な整理は、この変更に混ぜません。
4. 結果を検証する。 プロジェクトで実際に使っている料金計算、API、ワーカーのチェックを実行し、続けて通常の型チェックと結合テストを実行します。差分をレビューし、公開レスポンスや課金の意味が変わっていないか確認します。
5. 元に戻せる経路を残す。 検証が成功するまで、互換性を保つための境界を維持します。不要になったコードは、個別にレビューできる別の手順で削除します。

この例では、編集を手動で確認する選択肢で計画を承認します。実装後は、実際の変更とテスト結果を計画に照らして確認します。計画にテストが書いてあっても、実行して結果を確認するまでは、まだ提案にすぎません。

ここで得られるコスト面の効果は明確です。両方の呼び出し元とそのテストを書き換える前に、挙動の変化を見つけられることです。根拠のないトークン削減率を持ち出す必要はありません。

先に計画を立てる効果が大きい作業

初期の設計ミスが広がりやすい作業を優先します。私なら、次の状況を、効果が見込める順にPlan Modeへ回します。

これらは提案するワークフローであり、効果を測定した結果ではありません。方針が不確か、変更が複数ファイルにまたがる、コードに不慣れ、といった場合には計画を立てるというAnthropicの推奨に沿っています。誤字の修正、内容が決まっているログ文の追加、範囲が明確な名前の変更なら、直接変更を依頼します。Anthropicが計画を推奨する場面。

コストを見積もるときは、計画を入れる前後のワークフローを比べます。直接実行する場合、方針の間違いに気づくまでに、実装とレビューの時間を費やします。計画を先に立てる場合は、調査と計画レビューの時間が先にかかる代わりに、手戻りを避けられる可能性があります。

計画にかかる人件費と追加のモデル利用料の合計が、回避できると見込まれる手戻りのコストを下回るなら、計画を立てる価値があります。 これは判断の基準であり、Anthropicが示すコスト削減のベンチマークではありません。自分たちの開発コストと実際の利用量で判断してください。すでに正確に指定できる変更を言い直すだけの計画なら、省いてかまいません。

Plan Modeを活用したサービスに、どんな可能性がある？

最も有望なのは、チーム向けのリファクタリング・レビューパックです。変更案を、レビュアーがすぐ確認できる対象ファイル一覧、維持すべきインターフェース仕様、受け入れチェック、ロールバックのメモにまとめます。特に共通のビジネスロジックを扱う場面では、開発者ごとのレビュー品質をそろえるために、開発責任者が対価を払う可能性があります。

2026年10月12日に取得したDataForSEOの米国向けキーワード推計では、「code refactoring tools」は月間170検索です。これは、その作業への関心を示す小さな手がかりであり、検索した人が計画レビュー製品を購入する証拠ではありません。最小限の有用な製品としては、エクスポートした計画とリポジトリのファイル構成を受け取り、呼び出し元の漏れや裏付けのない前提を確認して、プルリクエストの要点をまとめるものが考えられます。ただし、汎用的な計画作成は、すでにClaude Codeの機能です。導入する価値を出すには、チーム固有のチェックと、レビューに使える成果物が必要です。

より対象を絞るなら、受託開発会社向けの移行準備パックという可能性もあります。アップグレードの見積もり前に、影響を受けるコンポーネントの一覧、段階的なリリースのチェックリスト、未決事項の一覧を作るものです。同じDataForSEOの調査では、「code migration tools」の米国での月間検索数は20と推計されています。この商用の検索語は規模が小さいため、幅広い製品を作る前に、既存顧客の需要を確かめるべきだと考えられます。

最小構成なら、特定の系統の移行に絞り、各変更に対応するベンダーのドキュメントへのリンクを添えることを必須にできます。課題は保守です。バージョン固有の移行ルールはすぐに古くなります。Plan Modeは調査を支援できますが、検証済みの移行ルール集を提供するわけではありません。これらは検索需要を手がかりにした製品の仮説であり、収益予測ではありません。

Ultraplanは提供を終了しています

AnthropicはUltraplanのリサーチプレビューを削除しました。/ultraplan、キーワードによる呼び出し、Web上のUltraplanで計画を練り直すための承認オプションも含まれます。公式ページでは、リサーチプレビューは実験的な機能であり、フィードバックに応じて変更や削除を行う場合があると説明しています。計画ワークフローには、ローカルのPlan ModeとClaude Codeのクラウドセッションが案内されています。Anthropicの現在のUltraplanページ。

Plan Modeについてよくある質問

月曜日には、共通処理の呼び出し元を持つ次のリファクタリングでPlan Modeに入り、維持すべき挙動、影響を受けるファイル、検証、ロールバックを洗い出すよう依頼してみてください。承認する前に、最も根拠の弱い前提を修正します。Claude Codeのベストプラクティスで紹介する、より広いレビューの習慣と組み合わせるとよいでしょう。

チームで繰り返し使える計画・レビューワークフローが必要なら、開発プロセスへの組み込みをお手伝いできます。