業務活用事例

Claude Codeのプランモードと直接実行を使い分ける判断基準

Claude Codeのプランモードと直接実行を使い分ける判断基準

この記事の要点

Claude Codeのプランモードと直接実行モードの違い・使い分けを解説。マイクロサービス化や大規模リファクタリングにはプランモード、単一ファイルの修正には直接実行が適切な理由を具体例で説明します。

結論

Claude Codeには「プランモード」と「直接実行」の2つのモードがあります。「複数の実装アプローチがあり得るか」「変更が複数ファイルにまたがるか」「アーキテクチャの意思決定が必要か」という3つの問いに1つでも「はい」があれば、プランモードから始めます。

プランモードは安全に調査と設計を行い、実装の方向性を確認してから変更するための仕組みです。後で大量のやり直しが発生するリスクを事前に排除します。


2つのモードの違い

比較項目プランモード直接実行
コードへの変更調査・設計フェーズではなし即座に変更
適したタスク複雑・大規模・アーキテクチャ判断が必要明確・小規模・手順が明快
主なメリット後戻りコストの削減素早い実行
主なデメリット余分な調査時間複雑なタスクで失敗リスク

プランモードを使うべき4つのパターン

パターン1: 大規模なアーキテクチャ変更

モノリシックアプリをマイクロサービスに分割するような変更は、数十〜数百のファイルに影響します。どのモジュールをどのサービスに切り出すか、依存関係をどう解消するかという設計上の判断が先行しないと、途中で矛盾に気づいて大量の作業が無駄になります。

プランモードで依存関係を整理し、移行順序の設計を確認してから実装を始めることで、この無駄を防げます。

パターン2: 複数の実装アプローチがある場合

「ユーザー認証をJWTとセッションどちらで実装するか」のような選択がある場合、どちらを選ぶかによって実装が大きく変わります。プランモードで各アプローチの利点・欠点・インフラ要件を比較してから決定することで、途中で「やはり別の方法にしよう」という方向転換を防げます。

パターン3: 45ファイル以上に影響するライブラリ移行

使用しているライブラリのバージョンアップや、ライブラリの置き換えでは、影響するファイルが多いほど事前調査が重要です。プランモードでどのファイルのどの箇所が変わるかを把握し、テストが必要な箇所をリストアップしてから変更を開始します。

パターン4: 未知のコードベースの調査

引き継いだレガシーコードや、初めて触る大規模コードベースでは、まず全体像を把握することが重要です。プランモードでコードベースを探索し、主要コンポーネントの依存関係を整理してから実装に入ることで、誤った前提で書いたコードを後で全て捨てるリスクを減らせます。


直接実行が適しているパターン

全てのタスクをプランモードで始める必要はありません。次のようなケースでは直接実行が効率的です。

明確なバグ修正 スタックトレースとエラーメッセージから原因が特定できているバグは、直接実行で修正します。「この関数のこの行を修正する」という作業に調査フェーズは必要ありません。

単一ファイル・単一関数の変更 バリデーションチェックを1か所追加する、定数の値を変更する、コメントを修正するといった変更は直接実行で十分です。

テストの追加 既存の実装を変えずにテストケースを追加する場合も、変更範囲が明確なので直接実行で問題ありません。

ルーティンのリファクタリング 変数名の統一、フォーマットの修正、明らかな重複コードの除去のような整理作業も直接実行が適しています。


プランモードの効果的な使い方

プランモードで最大の効果を得るには、調査フェーズと実装フェーズを意識的に分けることが重要です。

ステップ1: 探索に専念する

プランモードの調査フェーズでは、コードを変更しようとせず、理解に専念します。

良い指示の例(調査フェーズ):
「認証モジュールの現在の実装を調査してください。
セッション管理のコード・JWTトークンの発行箇所・ミドルウェアの設定を特定し、
主要なコンポーネントと依存関係を把握してください。まだコードは変更しないでください。」

調査の結果として、どのファイルが関連するか・どんな設計の選択肢があるか・リスクはどこにあるかを把握します。

ステップ2: 実装計画を確認する

調査の結果をもとに実装計画を立て、方向性が正しいかを確認します。この段階での方向修正は、実装後の修正より大幅にコストが低いです。

ステップ3: 直接実行で実装する

計画が固まったら、直接実行モードで実装します。プランモードで設計した内容を実装の指示に含めます。

実装フェーズの指示例:
「先ほどの調査結果を踏まえて、認証をJWTに移行します。
移行順序: 1. JWT発行ロジックを src/auth/ に実装, 2. ミドルウェアを更新, 3. 既存のセッション管理コードを削除
各ステップで既存のテストが通ることを確認しながら進めてください。」

Exploreサブエージェントの活用

コードベース全体の探索は詳細な出力を生成するため、メインの会話のコンテキストウィンドウを大量に消費します。Exploreサブエージェントを使うと、詳細な探索結果を会話に積み上げることなく、要約だけをメインに返すことができます。

具体的には、「このリポジトリ内の全テストファイルを特定して、テストフレームワークとカバレッジの概況を教えてください」という調査を独立したサブエージェントに任せます。サブエージェントは数百のファイルを調査しますが、メインに返すのは「Jestを使用、テストファイル142個、主要な未カバー領域は支払い処理モジュール」という要約です。

メインの会話のコンテキストウィンドウをクリーンに保つことで、後の実装フェーズで判断の質が落ちにくくなります。コンテキスト管理の詳細についてはAIのコンテキスト管理術で解説しています。


反復改善技術:Claude Codeと効果的に協力する方法

プランモード・直接実行のどちらであっても、Claude Codeとの協力をうまく進める手法があります。

具体的な入出力例を提供する

「このデータを変換してください」という自然言語での説明より、「この入力に対してこの出力を返してほしい」という具体例の方が正確な実装につながります。

抽象的な指示(曖昧):
「日付を読みやすい形式に変換してください」

具体的な指示(明確):
入力: "2026-06-05T09:00:00Z"
出力: "2026年6月5日(金)午前9時"

入力: "2026-12-25"
出力: "2026年12月25日(金)"

プロンプト全体の改善方法はプロンプトの書き方入門も参考になります。

テスト駆動で反復する

実装より先にテストを書き、そのテストの失敗状態をClaudeに見せながら実装を改善する手法です。

ステップ1: テストを書く
「このユーザー認証関数のテストを書いてください。
正常ログイン・パスワード誤り・アカウントロック・トークン期限切れの4ケースを含めること」

ステップ2: テストが失敗する状態を確認
ステップ3: テストを通過する実装を依頼
「先ほどのテストを全て通過する実装を書いてください。
失敗しているテスト: [テスト結果を貼り付け]」

テストを事前に定義することで「何が正しい実装か」が明確になり、曖昧な自然言語の解釈の違いによる手戻りが減ります。

インタビューパターンで見落としを防ぐ

新しい機能や馴染みのない領域の実装を始める前に、Claude Codeに「何を聞くべきかを聞く」手法です。

指示例:
「ユーザーのアクティビティログ機能を実装します。
実装を始める前に、設計上の考慮事項として私が答えるべき質問をリストアップしてください。
実装に入る前に、設計上の選択が必要な点を全て明確にしたいと思います。」

Claude Codeからの質問例:

  • ログはどのくらいの期間保持しますか?
  • 個人情報のGDPR対応はどうしますか?
  • 大量のログに対するパフォーマンス要件はありますか?
  • ログの検索・フィルタリング機能は必要ですか?

これらの質問に答えてから実装を始めることで、途中で「個人情報の扱いを考えていなかった」のような根本的な設計変更を避けられます。

相互依存する問題はまとめて伝える

独立した問題は1つずつ修正を依頼しても問題ありません。しかし、問題が互いに関連している場合は全ての問題をまとめて1つのメッセージで伝えます。

例えば、「入力バリデーションを追加する」と「エラーメッセージの形式を変更する」が互いに影響する場合、別々に修正を依頼すると最初の修正が2番目の修正で上書きされることがあります。関連する問題は一括して伝えます。


プランモードの落とし穴

プランモードを使うとき、よくある問題があります。

調査が終わらない 「もっと調べてから」と調査を続けすぎると、実装に入れなくなります。調査には明確な目的と終了条件を設定します。「このモジュールの依存関係を把握すること」のように具体的なゴールを決めます。

計画が詳細すぎる 全ての実装詳細をプランモードで決めようとすると、計画自体が大仕事になります。プランモードで決めるのは「どのアプローチを取るか」という方向性で、詳細な実装はClaude Codeに任せます。

計画と実装が乖離する 調査フェーズで把握した内容を実装フェーズに引き継がないと、実装が計画からずれます。プランモードでまとめた設計方針を実装の指示に明示的に含めます。


まとめ

プランモードと直接実行の使い分けはシンプルです。「複数ファイルへの影響」「アーキテクチャ判断」「複数の実装アプローチ」のどれかが当てはまればプランモードから始め、単一ファイルの明確な変更には直接実行を選びます。

プランモードの効果を最大化するには、調査→計画確認→実装という3フェーズを意識すること、Exploreサブエージェントで詳細探索をコンテキストから切り離すこと、インタビューパターンで設計上の見落としを事前に発見することが重要です。

この使い分けを身につけることで、複雑な変更でもやり直しのコストを抑えながら進められるようになります。

よくある質問

Claude Codeのプランモードとはどんな機能ですか?

コードを実際に変更する前に、調査と設計だけを行うモードです。コードベースを探索して依存関係を把握し、実装計画を立ててから変更を始めるため、後戻りが必要なコストの高いミスを防げます。

どんなタスクにプランモードを使うべきですか?

複数ファイルにまたがる変更・アーキテクチャの意思決定・ライブラリの移行・マイクロサービス化など、複数の実装アプローチがあり得るタスクです。単一ファイルの明確なバグ修正には直接実行で十分です。

インタビューパターンとは何ですか?

実装を始める前にClaudeが開発者に質問を投げかけ、設計上の考慮事項を洗い出す手法です。「キャッシュの無効化戦略はどうしますか?」のような質問で、見落としていた要件を事前に把握できます。