SECTION 01
Plan Modeは「いつ使うか」の判断が9割
Claude CodeのPlan Modeは、AIにいきなりコードを変更させず、まず作業計画を出させる機能です。便利な機能ですが、すべてのタスクで使う必要はありません。重要なのは「どの場面で起動するか」という判断基準を持つことです。
これまでの試行錯誤の中で落ち着いたのは、タスクの規模で3段階に分けるシンプルなルールです。この基準を決めてから、戻れないところまで進んでしまうミスが明らかに減りました。
- 軽微な修正（タイポ修正、1ファイルの小さな変更）→ 現在のブランチでそのまま実装
- 単一機能の追加（新しいコンポーネント、1つのAPIエンドポイント）→ ブランチを切って実装
- 複数ファイルにまたがる変更（リファクタリング、アーキテクチャ変更）→ Plan Modeで設計してから実装
判断基準をひとことで言えば、「戻れなくなるリスクがあるかどうか」です。影響範囲が見えない変更をAIにいきなり任せると、途中で方針がずれたときのやり直しコストが大きくなります。Plan Modeはそのリスクを事前に可視化する手段です。
もうひとつ実務で効いているのが、最初からではなく「詰まったときの切り替え先」として使うパターンです。通常モードで実装を進めていてループにハマったら、Plan Modeに切り替えて状況を整理し直します。計画を立て直すだけで、無駄な試行が減って突破口が見えることが多いです。
SECTION 02
Plan Modeの起動と基本操作
CLIでのPlan Modeの起動方法はShift+Tabです。Claude Codeのプロンプト入力画面でShift+Tabを押すと、default → acceptEdits → planの順にモードが循環します。つまり通常状態から1回押すとacceptEditsモード、もう1回押すとplanモードに入ります。VS Code拡張やDesktop / Webアプリでは、モードセレクタからも切り替えが可能です。
通常モード（default）との最大の違いは、Plan Modeではソースコードの編集を行わないという点です。ただし、ファイルの読み取りや調査のためのシェルコマンド実行は行います。AIがコードベースを読んで分析し、「何をどの順番でやるか」の計画を作成する際に、必要な情報を能動的に集めてくれるわけです。
単発で計画だけ出したい場合は、/planコマンドを使う方法もあります。モードを切り替えずにその場で計画を出力させられるので、ちょっとした方針確認に便利です。
計画が出力されると、変更対象のファイル一覧、実行予定のステップ、各ステップの依存関係がリスト形式で表示されます。この計画をそのまま承認することもできますし、修正のフィードバックを返すこともできます。計画の読み方を知っておくと、次のレビューフェーズがスムーズになります。
SECTION 03
出てきた計画のレビューで見るべき3つのポイント
Plan Modeが出力した計画をそのまま承認するのではなく、3つの観点でレビューする習慣をつけると事故が減ります。計画の品質を見極める目を持つことが、AIと安全に協働するための基本です。
1つ目は「変更対象ファイルの一覧が妥当か」です。計画に含まれているファイルが実際の影響範囲と一致しているかを確認します。ここで漏れがあると、実行フェーズで予期しない不整合が起きます。特に設定ファイルやテストファイルが抜けていないかは注意して見てください。
2つ目は「実行予定のコマンドに副作用がないか」です。データベースのマイグレーション、パッケージのインストール、ビルドスクリプトの実行など、元に戻しにくい操作が含まれていないかを確認します。副作用のあるコマンドが計画に入っていたら、その前後でバックアップやブランチの保護を検討してください。
3つ目は「ステップの順序と依存関係に抜けがないか」です。たとえば、型定義を変更する前にその型を使っているファイルを先に修正してしまうと、中間状態でエラーが出ます。ステップ間の依存関係が論理的に正しい順番になっているかを確認してください。
- 変更対象ファイルの一覧 → 影響範囲と一致しているか
- 実行予定のコマンド → 副作用や破壊的操作がないか
- ステップの順序 → 依存関係が正しい順番になっているか
この3点を確認するだけでも、AIに任せっぱなしで起きる典型的な事故はかなり防げます。レビューに慣れてくると、計画を見ただけで実装の成功率がおおよそ分かるようになってきます。
SECTION 04
計画が浅いときに深掘りさせる追加質問の型
Plan Modeが出す計画は、最初から完璧とは限りません。抽象的なステップや曖昧な表現が含まれていたら、追加の質問で具体化させるのが重要です。計画の精度を上げるフィードバックにはいくつかのパターンがあります。
最も効果的なのは、「他に影響を受けるファイルはないか」という問いかけです。AIは提示したファイル以外にも関連するファイルを認識していることが多く、聞くだけで計画の網羅性が上がります。同様に「このステップが失敗したらどうなるか」と聞くと、ロールバック手順やエラーハンドリングの考慮が追加されます。
- 「他に影響を受けるファイルはないか」→ 計画の網羅性を上げる
- 「このステップが失敗したらどうなるか」→ ロールバック手順の追加
- 「既存のテストは通るか」→ テストへの影響確認
- 「この変更でパフォーマンスに影響はあるか」→ 非機能要件の確認
計画をブラッシュアップするときは、「ここはもっと具体的に」ではなく、具体的な観点を指定して質問する方が精度の高い回答が返ってきます。「この関数の変更で呼び出し元はどう影響されるか」のように、レビューで気になった箇所をピンポイントで指すのがコツです。
何度かフィードバックを往復させて計画が十分に具体化されたら、その計画を「承認」として次の実行フェーズに進みます。計画段階で時間をかけることに抵抗を感じるかもしれませんが、ここでの精度が実行フェーズの手戻りを大きく減らします。
SECTION 05
計画から実行フェーズへ移る手順
計画のレビューが完了したら、実行フェーズに移行します。Claude Codeでは計画の承認後、acceptEdits（編集の都度確認） / auto（自動実行） / 手動確認しながら進めるといった複数の進め方から選べます。この切り替えのタイミングで、いくつか確認しておくべきことがあります。
実行に移す前のチェックリストとして、以下の項目を確認してください。
- 現在のブランチは正しいか（mainに直接コミットしようとしていないか）
- 未コミットの変更が残っていないか（計画の変更と混ざるリスク）
- 計画のステップ数が妥当か（多すぎる場合は分割を検討）
実行モードに移ったら、「先ほどの計画に従って実装してください」と指示するだけで、AIが計画通りにコードを変更していきます。計画で合意した内容がコンテキストに残っているため、改めて詳細な指示を出す必要はありません。
実行後はセルフレビューと動作確認をセットで行います。AIが計画通りに実装したかどうか、変更差分を確認してください。UIやAPIに変更がある場合は、実際にブラウザやターミナルで動作を確認するところまでがワンセットです。
この「計画→レビュー→実行→確認」のサイクルを1つの型として持っておくと、タスクの種類が変わっても同じ流れで進められます。慣れてくると、計画のレビューで実装の精度がほぼ決まることが実感できるはずです。
SECTION 06
実践：サブエージェント構成にPlan Modeを組み込む
Claude Codeのスキルやサブエージェントをカスタマイズしている場合、タスク規模に応じて自動でPlan Agent（計画エージェント）を起動する設計が効果的です。一例として、私はこのような条件分岐で計画フェーズを挟む構成に落ち着きました。
基本の型はこうです。5タスク以上の実装計画では、まずPlan Agentでタスク分解と依存関係を整理し、その後Coder Agentを並列起動して実装に入ります。計画フェーズで依存関係が明確になっているので、並列実行しても競合が起きにくくなります。
- Plan Agent: タスク分解、依存関係の整理、実行順序の決定
- Coder Agent: 計画に従ったコード実装（並列起動可能）
- Review Agent: 実装完了後のコードレビュー
- Test Agent: 動作確認と検証
この4段構成はClaude Codeの標準仕様ではなく、試行錯誤の中で安定した私の運用設計です。Claude Codeにはbuilt-inのPlan subagentやカスタムサブエージェントの仕組みがあるので、プロジェクトに合わせて構成を調整してみてください。
ここで重要なのが、計画の前にガードレール（ルール・仕様・制約）を作り込んでおくことです。ガードレールがなければ、計画が正確でも実行がブレます。コーディング規約、テストのカバレッジ基準、禁止パターンなどを事前に定義しておくと、エージェントの出力品質が安定します。
plan → code → review → testのサイクルをあらかじめ設計しておくことで、人間が介入するポイントが「計画の承認」と「最終確認」の2箇所に集約されます。途中で困ったり人間の判断が必要になったら、AI側から呼びかけてもらう設計にしておくと、監視コストも下がります。
この構成は大規模な変更ほど効果を発揮します。単発のタスクでは手間が増えるだけなので、先述のタスク規模の判断基準と組み合わせて使い分けるのがポイントです。
SECTION 07
計画の質を上げるモデル選択の考え方
Plan Modeを使う意味は「計画を出す」だけではありません。計画フェーズに強いモデルを当てることで、設計の精度そのものを上げるという使い方があります。
試行錯誤の中で安定してきたのは、Opusクラスのモデルで計画を作ると、長い工程でもステップの組み立てがかなり正確になるという実感です。計画フェーズでは推論力の高いモデルを使い、実行フェーズではコスト効率の良いモデルに切り替える構成がおすすめです。
- 計画フェーズ: 推論力の高いモデル（Opusなど）で設計の精度を確保
- 実行フェーズ: コスト効率の良いモデル（Sonnetなど）でコード生成
- レビューフェーズ: 計画との整合性を確認するため、再び推論力の高いモデル
この構成のメリットは、計画の正確さが実行フェーズのミスを減らし、結果的にトータルのコストが下がる点です。安いモデルで計画も実行も回すと、計画の抜け漏れが実行時のループにつながり、かえって時間とトークンを消費します。
モデルの選択は環境や予算によって変わりますが、「計画には良いモデルを使い、実行は効率重視で回す」という考え方を持っておくと、品質とコストのバランスが取りやすくなります。なお、ClineではPlan/Actそれぞれに別モデルを公式に設定できるので、こうした使い分けがしやすい環境です。
SECTION 08
CursorやClineの計画機能との実務上の違い
Claude Code以外にも、CursorのPlan ModeやClineのPlan/Actモードなど、計画機能を持つAI開発ツールは複数あります。実務で併用してきた中で見えてきた違いを整理します。
Cursorの強みは「一歩戻せる手軽さ」です。GUI上で変更のプレビューを見ながら、気に入らなければすぐに元に戻せます。CursorのPlan ModeではShift+Tabで計画モードに入り、質問しながら計画を作ってMarkdown化することもできます。
一方、Claude Codeの強みは「コードベース全体の理解の深さ」です。ターミナルベースで複数セッションを同時に走らせられるため、大きなリポジトリでの作業に向いています。
使い分けで落ち着いたのは、「どこで計画を立てるか」を決める感覚です。慎重に進めたいときはCursorで調査と計画を立ててから進める。または、Claude CodeのPlan Modeを使って計画を立て、実行に移す。どちらか一方に絞るのではなく、両方使ってプランニングを寄せる先を決めます。
Clineにも公式のPlan & Actモードがあり、計画と実行を明確に分離できます。実務上の差はツールの特性よりも「GUIかCLIか」という操作体系の違いに集約されることが多いです。GUIの方が計画の視認性は高いですが、CLIの方がスクリプトやCI/CDとの連携がしやすいです。
結論として、計画機能そのものの優劣ではなく、自分のワークフローに計画フェーズをどう組み込むかが重要です。ツールは手段であり、「計画してから実行する」という習慣を持つことの方が、どのツールを使うかよりも大きな差を生みます。
SECTION 09
Plan Modeを活かすための実践Tips
ここまでの内容を踏まえて、Plan Modeを日常の開発で活かすための実践的なコツをまとめます。特に導入初期に意識すると効果が大きいポイントです。
まず、計画の粒度は「1ステップ＝1コミット」を目安にしてください。計画のステップが大きすぎると実行時に問題の切り分けが難しくなります。逆に細かすぎると計画の作成自体に時間がかかりすぎます。コミット単位で分割できる粒度が、レビューもしやすく実用的です。
- 1ステップ＝1コミットの粒度を意識する
- 計画に「確認ポイント」を明示的に入れさせる
- 不安なステップには「実行前に確認を求める」指示を追加する
- 計画が長すぎたら、フェーズごとに分割して段階的に進める
次に、「実行前に確認を求める」指示を計画に組み込むテクニックが便利です。たとえば「データベースに変更を加えるステップの前に、必ず確認を求めてください」と指示しておけば、副作用のある操作の前でAIが一旦止まってくれます。
最後に、Plan Modeで出した計画は再利用可能な資産になることも覚えておいてください。似たようなタスクが再び発生したとき、過去の計画をテンプレートとして流用できます。計画をそのまま捨てるのではなく、うまくいった計画はメモとして残しておくと、次回の計画精度がさらに上がります。
SECTION 10
まとめ：Plan Modeを軸にした設計フローの全体像
Plan Modeは単なる機能ではなく、「AIにいきなり任せて事故る」を防ぐための設計フロー全体の入り口です。タスクの規模で使うかどうかを決め、計画をレビューし、納得してから実行に移す。このサイクルを持つだけで、AIとの協働の質が変わります。
この記事で紹介したフローを整理すると、以下のようになります。
- 判断: タスク規模で3段階に分け、複数ファイル変更ならPlan Modeを使う
- 計画: Plan Modeで設計を出力させ、3つの観点でレビューする
- 深掘り: 計画が浅ければ追加質問で具体化させる
- 実行: 計画承認後、acceptEdits / auto / 手動確認のいずれかで実装に進む
- 確認: セルフレビューと動作確認で品質を担保
ガードレールを先に作り込むこと、計画フェーズに推論力の高いモデルを当てること、詰まったときのフォールバックとしてもPlan Modeを使えること。これらを組み合わせると、計画の精度と実行の安定性が両立します。
「何をやるか」をAIと一緒に確認してから動く。この習慣が、AIコーディングを安全に、そして効率的に進めるための最もシンプルで強力な方法です。まずは次の複数ファイル変更のタスクで、Plan Modeを試してみてください。
