blog

Claude Code planプランモード・計画の使い方と実践ワークフロー完全解説

Claude Code planプランモード・計画の使い方と実践ワークフロー完全解説

Claude Code planプランモードとは:計画と実行を分離する設計思想

Claude Code planモード(プランモード)は、AIがファイルを一切編集せず、読み取り専用の状態でコードベースを調査し、変更計画のみを出力する動作モードである。通常のデフォルトモードでは、プロンプトを受け取ったClaudeはそのまま編集ツールを呼び出してファイルに書き込みを行うが、プランモード下ではその書き込みアクションが抑制される。

この分離が実用上の価値を持つ理由は、AIコーディングツールが陥りやすい典型的な失敗パターンに起因する。要件が曖昧なまま実装を開始したAIが、複数ファイルにわたる変更を蓄積し、後からロールバックするコストが増大する——という問題は、自律エージェントの実用上の制約として現場でも頻繁に確認されている。プランモードはこの問題に対して、「考える」フェーズと「実行する」フェーズを明示的に分けることで、人間のレビューポイントを構造的に確保する。

Anthropic公式ドキュメント(code.claude.com/docs/en/common-workflows.md)の”Plan before editing”セクションは、本機能の目的を「変更がディスクに触れる前に計画をレビューする(review changes before they touch disk)」と明記している。これが機能設計の一次情報として最も信頼できる根拠となる。

Phase 1 プランモード コードベース調査 変更計画の出力 読み取り専用・書込なし

Phase 2 人間レビュー 計画の確認・修正 承認 or 差し戻し レビューポイント

Phase 3 実行モード 承認済み計画に基づく ファイル編集・実装 テストによる検証

公式ドキュメント”Plan before editing”の概念を図示

図1:Claude Code planプランモードにおける「計画→レビュー→実行」の3フェーズ分離(出典:Anthropic公式ドキュメント “Common workflows”)

Claude Codeの全体像についてはClaude Code入門ガイド、インストール手順の詳細はClaude Codeインストール完全解説をあわせて参照されたい。

Claude Code planプランモードの起動方法と計画の立て方:基本的な使い方

/plan:実行前に計画だけ提示。承認してから変更が始まる
/plan:実行前に計画だけ提示。承認してから変更が始まる

プランモードへの切り替え操作

プランモードへの切り替えには主に2つの経路がある。いずれもClaude Codeが起動している状態で操作する。

方法1:Shift+Tabキー
ターミナル上でClaude Codeが動作している状態で、Shift+Tabを2回素早く押す。モードが切り替わると、プロンプト周辺のUIにプランモードであることが視覚的に示される。作業中であっても随時切り替えが可能であり、デフォルトモードとの往復も制約なく行える。

方法2:/planスラッシュコマンド
プロンプト行に直接 /plan と入力して実行することでもプランモードへ移行できる。スラッシュコマンドの体系的な一覧はClaude Codeスラッシュコマンド一覧で確認できる。

プランモードで実行する基本ステップ

公式ドキュメント”Common workflows”の”Plan before editing”セクションに基づき、実際の操作フローを整理する。

  1. プロジェクトルートに移動し、claudeコマンドでClaude Codeを起動する
  2. Shift+Tabまたは/planでプランモードへ切り替える
  3. 実装したい機能・修正したいバグ・リファクタリング対象を自然言語で記述する
  4. Claudeがコードベースを読み取り専用で調査し、変更計画(どのファイルの何をどう変えるか)を出力する
  5. 計画を精査し、過不足があれば追加プロンプトで修正を指示する(ファイルは変更されないため何度でも反復できる)
  6. 計画が固まったらプランモードを解除し、通常モードで実装を実行する

このフローの核心はステップ5にある。プランモード中はファイルが変更されないため、設計レベルの問題を実装後のロールバックコストを払わずに潰せる。計画を精緻化するための追加質問を重ねても、コードベースへの副作用が一切ない点がエンジニアリング的に重要である。

プロンプト設計の実例

以下にプランモードで実効性の高いプロンプトパターンを示す。指示の粒度と対象スコープを明示することが計画品質に直結する。

# 認証モジュールのリファクタリング計画
/plan
AuthServiceクラスをJWTベースからセッションベースに移行したい。
影響を受けるファイルと変更手順をステップ順に列挙してほしい。
テストコードへの影響も含めること。

# バグ修正前の原因調査
/plan
カート画面で商品追加時にNullPointerExceptionが発生する(スタックトレースは添付)。
原因ファイルと修正箇所の計画を出してほしい。修正は実行しないこと。

# 新機能追加の設計確認
/plan
RESTful APIに新しい/orders/exportエンドポイントを追加したい。
既存のrouter・controller・serviceレイヤーのどこに何を追加・変更するか、
依存関係も含めて計画を立ててほしい。

「修正は実行しないこと」という明示的な制約をプランモード内のプロンプトに加えることで、Claudeが計画提示に留まる意図をより確実に伝えられる。モードの切り替えとプロンプトによる指示の両方で意図を固めることが、実務での安全策として有効である。

プランモードが有効な具体的シーンと使い分けの判断基準

プランモードはすべての作業に均一に適しているわけではない。効果が高い文脈と、かえってオーバーヘッドになる文脈を理解したうえで使い分けることが重要である。

プランモードが有効な場面

1. 影響範囲が広いリファクタリング
複数ファイル・複数モジュールにまたがる変更は、全体計画を把握しないまま実装を始めると、中途半端な状態で整合性が崩れるリスクがある。プランモードで依存グラフを可視化してから実装することで、ファイル単位の抜け漏れを事前に排除できる。

2. 未知のコードベースの構造把握
公式ドキュメント”Common workflows”の”Understand new codebases”セクションが示すように、プロジェクト参入初期にプランモードでアーキテクチャ概要を把握する使い方は自然な適合である。この段階ではそもそもファイルを変更する必要がないため、プランモードがデフォルトの適切な状態といえる。

3. バグ修正前の原因仮説の列挙
「どこを直すか」を確定する前に、Claudeにコードベース全体を読ませて原因仮説を列挙させる。誤った箇所を実装段階で変更するリスクを、計画段階で排除できる。

4. 大規模な新機能追加の設計確認
新規エンドポイント・ドメインモデルの導入時に、どのレイヤーに何を追加し既存コードのどこを修正するかを計画として先に文書化できる。計画出力はそのままチームレビューの入力資料として機能する。

プランモードが不要または過剰な場面

単一ファイル内の小規模修正・変数名変更・コメント追加など、影響範囲が自明な作業では計画フェーズを経由するコストが効果を上回る。モード切り替えの分だけ作業速度が落ちるため、作業の複雑度と影響範囲を判断基準として使い分けることが現実的である。

Claude Codeの動作モード比較

観点 プランモード(plan) デフォルトモード AcceptEditsモード
ファイル書き込み なし(読み取り専用) 確認後に実行 自動承認で即実行
主な用途 設計・計画・調査 通常の実装作業 自動化・CI連携
人間レビューの挿入点 計画段階(実行前) 編集確認時 実行後
適した作業規模 中〜大規模変更 小〜中規模変更 反復的な小〜中規模変更
切り替え方法 Shift+Tab / /plan 起動時デフォルト Shift+Tab
ロールバックリスク なし 中(事後確認が必要)

Claude Code planプランモードを組み合わせた実践的ワークフロー設計

「計画→承認→実行」の3段階フロー

実務で広く採用されているワークフローパターンは、プランモードを起点とした3段階構成である。

  1. プランモードで計画を立案:読み取り専用でコードベースを調査し、具体的な変更計画を取得する
  2. 計画をレビュー・承認:人間が計画の妥当性・網羅性・設計判断を確認し、必要に応じて修正指示を追加する
  3. 通常モードで実装・テスト:承認済みの計画に基づいて実装を実行し、テストで動作を検証する

このフローは公式ドキュメント”Plan before editing”の設計思想を実作業レベルに展開したものである。特に大規模なモノリポや複数チームが関わるコードベースでは、計画ドキュメントをそのままプルリクエストの説明やコードレビューの参考資料として転用できる点が実用的な副次効果となる。

CLAUDE.mdとの連携による品質枠組みの整備

Claude Codeはプロジェクトルートに配置したCLAUDE.mdファイルを読み込み、コーディング規約・アーキテクチャ方針・禁止パターンをコンテキストとして参照する。プランモードで計画を立案する際もCLAUDE.mdの内容が反映されるため、チームの規約に沿った計画が自動的に生成されやすくなる。

さらに、プランモードで初期計画を作成した後、その計画で合意した方針(例:「このプロジェクトではRepositoryパターンを使用する」「テストはユニットとE2Eの両方を必須とする」)をCLAUDE.mdに逆に書き戻す運用も有効である。これにより、以降の作業でClaudeが合意済み方針から逸脱しにくくなり、計画と実装の一貫性を構造的に維持できる。

サブエージェントへの委譲との組み合わせ

公式ドキュメント”Common workflows”には”Delegate research to subagents”というワークフローも記載されている。メインのClaude Codeセッションではプランモードで全体計画を立て、詳細な調査タスク(特定ライブラリの使用箇所の全列挙や、特定パターンのコード検索など)をサブエージェントに委譲することで、メインコンテキストを汚染せずに情報収集できる。大規模コードベースではコンテキスト管理がトークンコストと出力精度の両面に直接影響するため、この分業は無視できない実用価値を持つ。

Agent SDKを用いればPythonやTypeScriptからプログラマティックに同等の動作を実行することも可能である。公式ドキュメント”Agent SDK overview”(code.claude.com/docs/en/agent-sdk/overview.md)によれば、Python向けにはclaude-agent-sdk(Python 3.10以上が必須)、TypeScript向けには@anthropic-ai/claude-agent-sdkが提供されており、allowed_toolsでRead・Edit・Bashなどのツールを制限することで、SDK経由でもプランモード的な読み取り専用の調査動作を実装できる。なお、同ドキュメントには「2026年6月15日以降、サブスクリプションプランでのAgent SDK利用は新しい月次クレジットから消費される」との注記があり、コスト管理の観点で把握しておく必要がある。

CI・自動化パイプラインへの組み込み

公式ドキュメントの”Pipe Claude into scripts”セクションでは、Claude CodeをCI/CDパイプラインに組み込む用途が説明されている。プランモードをこのコンテキストで活用する場合、計画出力をMarkdownまたはJSONとして保存し、プルリクエストのテンプレートや変更影響チェックリストに自動挿入するフローを構築できる。コードレビュー前の影響範囲の可視化を自動化するという用途では、プランモードとCI連携の組み合わせが有効に機能する。

Claude Codeのコスト最適化についてはClaude Code料金・プラン解説およびClaude Code APIコスト詳細も参考にされたい。

プランモードの技術的限界と注意すべきトレードオフ

計画精度はコンテキスト品質に依存する

プランモードの出力品質は、Claudeに与えるコンテキストの質と量に強く依存する。コードベースが大規模でファイル数が多い場合、Claudeが1回のセッションで参照できる範囲には物理的な上限があるため、計画に抜け漏れが生じる可能性がある。特定のディレクトリやファイルを明示的に参照させるプロンプト設計、あるいはCLAUDE.mdによるスコープ制限が現実的な対策となる。

また、コードベースのドキュメント化が不足している場合は、Claudeが誤った前提に基づいて計画を立案するリスクもある。計画出力を精査するエンジニアの判断力が最終的な品質保証として機能することは変わらない。

計画と実装の乖離リスク

プランモードで作成した計画は、実装フェーズで状況が変化した際に自動更新されない。計画と実際の実装が乖離する状況は、特に複数ステップにわたる長い作業や、計画立案後に時間をおいて実装を再開した場合に起こりやすい。計画はあくまで出発点であり、実装途中での変化を人間がモニタリングする責任は依然として残る点を認識しておく必要がある。

コスト削減に直結しないケースへの注意

プランモードを経由しても、調査フェーズでのトークン消費は発生する。「計画を立てることでやり直しを減らす」というメリットが実質的なコスト削減につながるかは、作業の性質によって異なる。影響範囲が明確で単純な作業では、計画フェーズ分だけトークン消費が増加する可能性もある。プランモードの使用有無は作業規模・複雑度・リスク許容度を勘案して判断するべきである。

他ツールとの比較における位置づけ

Cursorなど他のAIコーディングツールとのアーキテクチャ上の差異についてはClaude Code vs Cursor比較、OpenAI Codexとの比較はClaude Code vs Codex比較を参照されたい。「AIが自律的に動く前に人間が関与できる接点を明示的に設ける」という設計思想は、Claude Codeのプランモードが色濃く体現している方針であり、ツール選定時の設計哲学の違いとして認識しておく価値がある。

全体的な使い方の整理

Claude Code全般の使い方についてはClaude Code使い方ガイド、SEOや非エンジニア向けの導入事例についてはClaude Code SEO初心者ガイドも参照されたい。Claude Codeの機能全体像についてはClaude Code総合解説でも確認できる。


弊社が開発するバーチャルヒューマン/AIアバターソリューション「DeepAI」は、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現し、接客・研修・広報など多様な用途に活用されている。対話AIを組み合わせた複雑なパイプラインの改修においても、「実行前に計画を固める」というアプローチは強い親和性を持つ。Claude CodeのプランモードのようなAI支援ツールの導入を検討されている方は、弊社DeepAIとあわせてご相談いただきたい。


参考文献

監修

河合 継(クリスタルメソッド株式会社 代表取締役)

AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について編集方針

AIブログ購読

 
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • AI規制イタリア国家戦略の実施令承認——日本AI政策への実務的示唆

    AI規制イタリア国家戦略の実施令承認——日本AI政策への実務的示唆

    イタリアAI規制 実施令の予備承認——何が起きたか 2026年6月10日、イタリアの閣議(Consiglio dei Ministri)は、2025年9月23日...

  • OpenAI Codexエージェントが企業クラウドへ——Ona買収が日本企業に意味すること

    OpenAI Codexエージェントが企業クラウドへ——Ona買収が日本企業に意味すること

    OpenAI×Ona買収の要点——何が起きたか 2026年6月11日、OpenAIはAIエージェント向けクラウド実行環境を手がけるスタートアップ「Ona(旧Gi...

  • NVIDIA Vera CPU正式ローンチがAIインフラとデータセンター投資に示す日本企業への示唆

    NVIDIA Vera CPU正式ローンチがAIインフラとデータセンター投資に示す日本企業への示唆

    NVIDIA Vera CPUとは何か——AIインフラ向けCPU内製化という構造的転換 NVIDIAは2026年、エージェント型AIと強化学習の時代に向けて専用...

View more