Plan Mode vs 直接実行

Plan Mode vs 直接実行の判断は、CCA-F 試験の Domain 3（Claude Code の設定とワークフロー）の中核に位置する。タスクステートメント 3.4 は、Plan Mode vs 直接実行が正しいアーキテクチャ上の選択である場合を受験者が判断することを求め、コミュニティの合格報告では一貫して試験全体で最も頻度の高い落とし穴領域の1つとして指摘されている。問いは決して「どちらのモードが優れているか」ではない——両方とも第一級の Claude Code ワークフローである。問いは常に「どのモードがシナリオに記述されたタスクの爆発半径、曖昧性、可逆性に正しく一致するか」である。

この学習ノートでは CCA-F 受験者がマスターすると期待されるPlan Mode vs 直接実行の全領域を解説する：各モードの正確な定義、plan mode を義務付けることを正当化する具体的なシグナル、同様に直接実行が正しいデフォルトであることを示す具体的なシグナル、Claude Code が生成する計画の形式、ユーザー承認のセマンティクス、デフォルト動作のための CLAUDE.md 設定、ハイブリッドパターン、常時オン計画のコスト、冗長な発見出力を分離するための Explore subagent パターン、そして受験者に「plan mode は常に安全」をデフォルトにするよう罰する試験の落とし穴。専用のセクションでは、Plan Mode vs 直接実行の問題が最も密集するコード生成と開発者生産性の試験シナリオにすべての概念を結び付ける。

Plan Mode の定義 — アクションを起こす前に Claude が実行計画を生成する

Plan Mode は Claude Code のワークフローであり、Claude がまず構造化され、レビュー可能な実行計画——実行しようとするアクションの番号付きリスト、触れようとするファイル、使用しようとするツールのシーケンス——を生成し、ファイルシステムの変更が起こる前にユーザーのレビューに提示する。計画はユーザーが承認、修正、または拒否するまで提示される。計画の外にある何も、承認されるまで実行されない。

Plan Mode はアクションを誤って実行するコストが短い遅延のコストを超えるタスクのために明示的に設計されている。plan mode では Claude は本番コードに触れる前に1ページの変更ブリーフを書くシニアエンジニアのように振る舞う。モードは Claude をよりスマートにするのではなく——基礎となるモデルは同じである——Claude がアクションにコミットするタイミングを変える。この時間的な分離が全体のポイントである。

Plan Mode はコミットのタイミングに関するものであり、能力に関するものではない

よくある誤解——CCA-F の引っかけ回答によって積極的に利用される——は Plan Mode をより強力またはよりスマートな Claude のバリアントとして扱うことである。そうではない。Plan Mode は同じモデル、同じツール、Claude が既に持っていた同じコンテキストを使用する。変わるのはコミットポイントである：plan mode では Claude はアクションする前に完全な意図を言語化しなければならない；直接実行では Claude は推論とアクションを交互に実行する。Plan Mode は高い爆発半径の作業で多くのレビュー可能性のために少量のレイテンシを交換する。

直接実行の定義 — 明示的な計画ステップなしに Claude が即座に行動する

直接実行はデフォルトの Claude Code ワークフローであり、Claude がタスクについて推論し、ファイルの読み取り、コードの編集、コマンドの実行——短い推論バーストと具体的なアクションを交互に実行する——ツール呼び出しを即座に開始する。事前承認された計画はない；進行中のエージェンティックループの作業が起こるにつれて観察できるだけである。

直接実行は無謀ではない；単にブロックされていないだけである。モデルはまだ内部的に計画し、失敗した編集の後にロールバックし、曖昧性に達した場合にユーザーにエスカレートする能力を持つ。直接実行が除去するのは必須の事前承認ゲートである。変更が小さく、可逆的で、明確にスコープされたタスクでは、これは正しい選択である——正式な計画を作成して承認を待つオーバーヘッドが計画が提供する価値を超える。

直接実行がデフォルトである理由

Claude Code はデフォルトで直接実行を選ぶ、なぜなら中央値の開発タスク——タイポ、1行の修正、明確なテストの更新——は即座のアクションから利益を得て、儀式的な計画によって罰せられるからである。すべてのタスクを plan mode に通すことは10秒の編集を2分の承認の儀式に変えるだろう。CCA-F 試験はPlan Mode vs 直接実行が好みではなくマッチングの問題であることを認識する受験者を評価する。

Plan Mode トリガー — タスクの複雑さシグナル、リスクシグナル、明示的なユーザーリクエスト

4つのシグナルのカテゴリがタスクを Plan Mode にルートすることを正当化する。

タスクの複雑さシグナル

複雑さシグナルはリクエストに直接現れる。「モノリスをマイクロサービスに再構築する」、「すべての API ルートを v1 から v2 に移行する」、「SSO をサポートするために認証層をリファクタリングする」、「共有ロギングユーティリティを新しいパッケージに抽出してすべての呼び出し元を更新する」——それぞれが多くのファイルにまたがる変更、いくつかのアーキテクチャ上の決定、複数の有効なアプローチを意味する。これらは plan mode のタスクである、なぜならアプローチ自体が最終的なパッチだけでなくレビューに値する決定であるからである。

リスクシグナル

リスクシグナルは爆発半径を強調する。ビルド設定、マイグレーションスクリプト、デプロイメントマニフェスト、支払い処理コード、またはセキュリティ重要モジュールに触れることは、間違いが過大な結果をもたらすことを意味する。タスクがシステムの起動、デプロイ、認証、または請求の方法を変更する場合は常に、plan mode が保証される——Claude が信頼できないからではなく、レビューステップが安価な保険だからである。

曖昧性シグナル

曖昧性シグナルはリクエストの複数の有効な解釈が存在する場合に現れる。「ユーザーモジュールを整理する」はデッドコードの削除、再フォーマット、ファイルの分割、またはそれら3つすべてを意味する可能性がある。リクエストが意図された変更を一意に決定しない場合、plan mode は曖昧性を表面化させ、コードが動く前にユーザーが解決できるようにする。

明示的なユーザーリクエスト

ユーザーはアクションを起こす前に Claude に計画するよう明示的に求めることができる。「何かを変更する前に計画を立ててください」、「まずアプローチを説明してください」、「どのファイルに触れますか？」のようなフレーズは plan mode の直接的な呼び出しである。CCA-F 試験は明示的なユーザーリクエストが CLAUDE.md に設定されたどのデフォルトモードも上書きすることを受験者が認識できるかどうかを頻繁にテストする。

Plan Mode を義務付ける場合 — 高爆発半径タスク、不慣れなコードベース、マルチファイルリファクタリング

Plan Mode は試験が定着した法則として扱う3つの標準的なタスクカテゴリに対して——オプションではなく——義務付けるべきである。

高爆発半径タスク

タスクの爆発半径が高いのは、誤ったアクションが迅速に元に戻せない場合である。データベーススキーマのマイグレーション、本番設定の変更、全面的な依存関係のアップグレード、パブリック API コントラクトに触れるリファクタリングはすべてこのカテゴリにある。悪い計画を元に戻すコストは5分；悪い半分完了したリファクタリングを元に戻すコストは午後いっぱいである。

不慣れなコードベース

Claude が広範に探索していないコードベースで作業している場合、plan mode が正しい最初のステップである。計画自体が探索のアーティファクトになる：Claude が関連すると考えるファイルを提案し、ユーザーがマップを修正し、その後のみ実行が開始される。これは探索を、コンテキストを消費するサイレントなアクティビティからレビュー可能なドキュメントに変換する。

マルチファイルリファクタリング

ファイルの境界を越えるタスク——特に影響を受けるファイルの数が曖昧な場合——は plan mode に属する。試験が使用する標準的な例は、45以上のファイルに影響するモノリス-マイクロサービス再構築である。このようなタスクへの直接実行は、コードが動く前に発見出力でコンテキストを使い果たす；plan mode は構造的な決定をフロントロードし、その後の実行フェーズを集中させる。

直接実行が適切な場合 — 明確にスコープされた、可逆的な、単一ファイルのタスク

直接実行はシナリオが小さなスコープを示す場合に同様に第一級の回答である。

明確にスコープされたタスク

明確にスコープされていることは、意図された変更が曖昧さなく指定されていることを意味する。「auth.ts の42行目、token.verify() 呼び出しの前に null チェックを追加する」は明確にスコープされている；計画するものは何もない。リクエスト自体が計画である。

可逆的なタスク

タスクは誤った変更が簡単に元に戻せる場合に可逆的である——バージョン管理付きの単一ファイル編集、ローカル設定の調整、テストの更新。可逆的なタスクには直接実行が合う、なぜなら少しずれた解釈に対してアクションを起こすコストが安価な git checkout だからである。

単一ファイルのタスク

単一ファイルのタスクが計画のオーバーヘッドを正当化することはほとんどない。「validator.py のこのバグを修正する」、「この関数をリネームする」、「このインポートを追加する」——計画ドキュメントはパッチより長くなるだろう。plan mode を強制することはレビュー可能性を追加せずにレイテンシを追加する。

サンプル Q5 パターン — 日付検証条件の追加

CCA-F 試験ガイドのサンプル Q5 はこの形をまさに引っかけ選択肢として使用する：シナリオが既存の関数に単一の日付範囲検証条件を追加することを説明し、1つの回答の選択肢が plan mode への切り替えを提案する。その回答は間違いである。タスクは単一ファイル、可逆的、明確にスコープされた変更——典型的な直接実行のケース——である。「plan mode は常に安全」をデフォルトにする受験者はこの問題で失敗する。

計画の形式 — 番号付きステップ、ツールシーケンス、ファイル影響リスト

Claude Code の plan mode は試験が受験者に認識させると期待する予測可能な計画の形を生成する。

番号付きステップ

すべての計画は独立したステップの番号付きリストである。番号付けは計画をステップごとにレビュー可能にし、部分的な承認を可能にする——ユーザーは「ステップ1〜3を承認する、ステップ4は考えさせてください」と言うことができる。自由形式の散文は計画ではない；番号付きのリストが計画である。

ツールシーケンス

各ステップは意図されたツールを指定する：Read src/auth.ts、Grep -r "verifyToken"、Edit src/auth.ts、Bash npm test。ツールシーケンスを事前に宣言することで、ユーザーが実行前に危険な操作（Bash、既存ファイルへの書き込み）を発見できる。

ファイル影響リスト

すべての計画は、計画が作成、変更、または削除するファイルの明示的なリストを含む。ファイル影響リストは大規模なリファクタリングをレビューするための最も価値ある要素である；全爆発半径を一目で表面化させ、偶発的な包含を捉える。

リスクと仮定のメモ

適切に形成された計画は、Claude が環境について行った仮定（「テストスイートは npm test で実行されると仮定」）と予見されるリスク（「マイグレーションには短いダウンタイムウィンドウが必要になる」）も列挙する。これらのメモがユーザーが最も注意深くレビューするアーティファクトである。

計画の検証 — 実行が進む前のユーザーレビューと承認

計画自体はユーザーがアクションを起こすまで不活性である。3つの結果が可能である。

そのまま承認

ユーザーが計画を逐語的に承認する。Claude Code は plan mode から抜け出し、ステップを順番に実行する。承認はサイレントな同意ではない——ユーザーが明示的に確認する。

修正を伴う承認

ユーザーが計画を承認するが特定の変更を要求する。「承認します、ただしステップ4をスキップしてステップ6にロールバックスクリプトを追加してください。」Claude Code は修正を反映するように計画を改訂し、実行する前に再承認のために改訂版を提示する。

拒否

ユーザーが計画を完全に拒否する、通常は選ばれたアプローチが間違っていたためである。拒否は会話を終了しない——ユーザーのフィードバックとともに Claude を計画に戻す。反復的な計画は通常である；最初の計画が複雑な作業の最終的な計画であることはほとんどない。

CLAUDE.md での Plan Mode の強制 — デフォルト動作の設定

Plan Mode はプロジェクトレベルの CLAUDE.md に命令を追加することでプロジェクトのデフォルトとして設定できる。「このリポジトリでファイルシステムを変更するアクションを起こす前に常に計画を作成してください」のような命令は、タスクのサイズに関係なく plan mode を強制する。これはほとんどの変更が高リスクのコードベース（infrastructure-as-code、支払いサービス、規制されたシステム）に適切であるが、ほとんどのアプリケーションリポジトリには不適切であり、すべてのタスクに儀式を課す。

ディレクトリレベルのオーバーライド

CLAUDE.md は階層をサポートするため、プロジェクト全体の plan mode のデフォルトはタスクが一貫して低リスクのディレクトリ（変更が見た目のものである /docs ディレクトリなど）に対して選択的に緩和できる。ディレクトリレベルの CLAUDE.md はプロジェクトのデフォルトを補完する。

Plan Mode と非インタラクティブ CI

Plan Mode は基本的にインタラクティブである——計画を承認、修正、または拒否するユーザーを必要とする。-p フラグを使用した非インタラクティブ CI パイプラインでは、強制された plan mode は承認するユーザーがいないため自動化を壊す。非インタラクティブに Claude Code を実行しなければならないパイプラインは plan mode を完全に避けるか、プログラム的に承認を提供するかのいずれかにすべきである。CCA-F 試験はこの相互作用をテストする。

ハイブリッドパターン — 特定のファイルパターンに自動計画、他には直接実行

成熟した Claude Code の設定はシグナルによってルートすることで両方のモードを組み合わせる。3つのハイブリッドパターンが試験シナリオで繰り返される。

パスベースのルーティング

インフラストラクチャのパターンに一致するパス（infra/**、migrations/**、.github/workflows/**）には plan mode が義務付けられ、リポジトリの残りはデフォルトで直接実行となる。.claude/rules/ パス固有ルールシステム（タスク 3.3）がこのルーティングを強制するメカニズムである。

操作ベースのルーティング

タスクがスキーマの変更、依存関係のバンプ、またはパブリック API の変更を含む場合は plan mode が義務付けられ、単一ファイル内のローカル編集はデフォルトで直接実行となる。CLAUDE.md の命令は計画を必要とする操作タイプをエンコードする。

探索-計画-実行の合成

最も複雑なタスク——ライブラリのマイグレーション、フレームワークのアップグレード、大規模な再構築——では、最適なワークフローが3つのフェーズに分割される。まず、Explore subagent が発見を実行しサマリーを返す。次に、Claude Code が plan mode でサマリーを使用して計画を生成する。次に、Claude Code が直接実行モードで承認された計画をステップごとに実装する。この3フェーズパターンはライブラリマイグレーションを含む試験シナリオで明示的に取り上げられる。

Explore Subagent — 冗長な発見出力の分離

Explore subagent は大規模なコードベースに対して Plan Mode と自然にペアになる専用の調査パターンである。

なぜ発見出力を分離するのか

大規模なコードベースの探索はトークンが多い。モジュールの依存関係グラフをマッピングするために30のファイルを読み取ることは、数万トークンを消費する可能性があり、そのほとんどはノイズである——メインの会話は結論（「更新しなければならない45の呼び出しサイトがここにある」）を必要とし、生のファイル内容を必要としない。subagent で発見を実行することで、メインのコーディネーターのコンテキストは決定に集中できる。

コンテキストウィンドウの枯渇

Explore subagent なしでは、発見が重いタスクはしばしば実際の作業が始まる前にコンテキストウィンドウを使い果たす。Claude Code は以前の命令、CLAUDE.md の内容、またはユーザーの元のリクエストへのアクセスを失う。Explore subagent は標準的な緩和策である。

Explore と Plan Mode のペアリング

標準的なパターンは：影響を受ける表面をマッピングするために Explore subagent を生成し、そのサマリーを受け取り、サマリーを使用して実行計画を生成するために Plan Mode に切り替え、承認された計画をステップごとに実行する。これはライブラリマイグレーションと大規模な再構築に推奨される形状であり——CCA-F 試験がコード生成シナリオで直接テストするパターンである。

エージェンティックループでの Plan Mode — ループの最初のイテレーションとしての計画ステップの使用

Agent SDK 内では、Plan Mode はエージェンティックループの明示的な最初のイテレーションとしてエンコードできる。最初のループが計画を生成し；ユーザーが承認し；後続のイテレーションが計画のステップを1つずつ実行し、各アクションの後に tool_result 観測が返ってくる。

計画優先のループ形状

計画優先のループは予測可能なメッセーストレースを持つ：ユーザーリクエスト → 計画（アシスタント）→ ユーザーの承認 → tool_use（ステップ1）→ tool_result → tool_use（ステップ2）→ tool_result → ... → end_turn。stop_reason の値は標準的なエージェンティックループのセマンティクスに従う；plan mode は Claude が早期のイテレーションで何を言うかを変えるが、ループがどのように終了するかは変えない。

Plan Mode と Subagent の生成

全体的な作業が subagent にわたって分解される場合、各 subagent は独立して計画するかどうかを決定できる。コーディネーターは plan mode で実行（全体的な実行計画を生成）し、一方で各 subagent はその葉のタスクを直接実行モードで実行できる。これは実際のエンジニアリングを反映する：シニアエンジニアが計画し、ラインワーカーが実行する。

計画のコスト — Plan Mode が常時オンの場合のレイテンシとトークンのオーバーヘッド

Plan Mode は無料ではない。アーキテクチャ上の判断のために2つのコストが重要である。

レイテンシのオーバーヘッド

Plan mode はユーザーレビューのための同期的な一時停止を挿入する。小さなタスクでは、この一時停止が総ウォールクロック時間を支配する。10秒の編集が2分の儀式になる：計画の生成、ユーザーが計画を読む、ユーザーが承認する、実行。明確にスコープされた作業では、このオーバーヘッドは純粋な無駄である。

トークンのオーバーヘッド

すべての計画はそれ自体が生成されたアーティファクト——番号付きステップ、ファイルリスト、リスクメモ——であり、出力トークンを消費する。計画はその後、セッションの残りのコンテキストを占有する。計画が多い長いタスクでは、計画のメタ作業に費やされたトークンが実際のコードに費やされたトークンと競合する。

コストが価値あるとき

計画のコストは代替コスト（半分完了したリファクタリング、間違ったアーキテクチャ方向、非可逆的な変更）が実質的に大きい場合に支払う価値がある。タスクの爆発半径が較正である。本番スキーママイグレーションでは、計画の税は些細な保険である。タイポの修正では、儀式の見せ物である。

やさしい解説: Plan Mode vs 直接実行

Plan Mode vs 直接実行は物理的な日常の類比に根ざすと直感的になる。3つの類比が全決定空間をカバーする。

類比1：厨房 — 仕込み vs ライン上の調理

短時間調理師は卵を直接揚げる：割る、塩を振る、プレートに盛る、提供する。仕込みなし、書かれたシーケンスなし、副料理長のレビューなし。これが直接実行である。200人のゲストを調理する宴会シェフはそのようには働かない。サービスが始まる前に、宴会シェフは準備リストを書き、各ステーションにタイミングを割り当て、副料理長たちにシーケンスを説明する。ラインがサインオフした後でのみ、誰かがパンに触れる。そのサービス前のブリーフィングがPlan Modeである。

両方の調理師は同様に有能である。ワークフローの選択は間違いの爆発半径によって左右される。塩を多く入れすぎた卵は卵1個のコスト。タイミングを間違えた宴会はイベントを台無しにする。Claude Code は同じ厨房——1人の調理師、2つのワークフロー、注文のサイズによって選択される。

この類比は Explore subagent も示す：宴会シェフは計画が書かれる前に若いコックにウォークインの在庫確認に行かせる。若いコックは「サーモンが15キロあって、ディルがない」と戻ってくる。ヘッドシェフはそのサマリーでメニューを計画する。若いコックのウォークイン全体の歩き回り（すべての棚、すべての容器）はヘッドシェフの記憶に入らない——サマリーのみが入る。これがまさに Explore subagent がメインの会話のコンテキストを保持する方法である。

類比2：オープンブックの試験 — 下書きのアウトライン vs 1回目の回答

オープンブックの試験には2つの戦略がある。すぐに認識できる多肢選択問題では、回答に丸をつけて次に進む。これが直接実行——問題は明確にスコープされ、回答は可逆的（後で変更できる）で、間違った推測のコストは小さい。

これまでこのようにはフレーズされていないトピックについての長い回答式問題では、散文を書き始めない。まずアウトラインを作る：論文、3つの支持論、結論、反例。アウトラインが成立した後でのみ、段落に展開する。そのアウトラインがPlan Modeである。それなしでは、間違った論文を主張する4ページを書いてしまい、書き直す時間がない。

試験は戦略を問題の種類に正しく一致させる受験者を評価する。CCA-F 試験は Plan Mode vs 直接実行をシナリオに記述されたタスクに正しく一致させる受験者を評価する。

類比3：建設現場 — 作業指示 vs パンチリスト

建設現場を歩く請負業者は自宅の所有者とともに両方の種類の作業に遭遇する。ゆるいキャビネットのちょうつがいはその場で締める——ドライバー、30秒、完了。これが直接実行である。同じ請負業者が台所のレイアウトを再構築するよう求められた場合、ハンマーを振り始めない。彼女は作業指示を作成する：この壁を解体し、これらのコンセントを移動し、ガスラインを移動し、この床をタイルし、これらのキャビネットを設置する。家の所有者が各行をレビューして承認する。それからのみ、クルーが動き出す。これがPlan Modeである。

建設の類比は特にマルチファイルリファクタリングのケースをうまく示す。台所の再構築は配管、電気、ガス、フレーミング、仕上げに触れる——複数の「ファイル」で、それぞれが他に対する依存関係を持つ。計画なしにデモを始めると、振りながらガスラインを切るリスクがある。CCA-F のサンプル問題の45以上のファイルにわたるモノリス-マイクロサービス再構築は、まさに台所の再構築である：フリースタイルするには依存関係が多すぎる。

試験当日にどの類比に手を伸ばすか

• タスクのサイズによるモード選択をテストするシナリオ → 厨房（短時間調理 vs 宴会）。
• 発見の分離（Explore subagent）をテストするシナリオ → 厨房のウォークインの在庫確認。
• 曖昧な作業で計画をスキップするコストをテストするシナリオ → オープンブックの論述。
• マルチファイルの爆発半径をテストするシナリオ → 建設作業指示。

Plan Mode と Claude Code の機能サーフェス

Plan Mode は孤立して存在するのではなく——CCA-F 試験が Domain 3 全体でテストする他の Claude Code の機能と合成する。

CLAUDE.md との相互作用

プロジェクトの CLAUDE.md はリポジトリに対して plan mode を義務付けることができる。ユーザーの CLAUDE.md はグローバルに plan mode を義務付けることができる。ディレクトリの CLAUDE.md はいずれかを特定のサブツリーに対してオーバーライドできる。階層はタスク 3.1 がテストするのと同じ3レベルの階層であり、plan mode のデフォルトに適用される。

スラッシュコマンドとの相互作用

.claude/commands/ に定義されたカスタムスラッシュコマンドはそのテンプレートの一部として plan mode を明示的に呼び出すことができる。例えば /refactor コマンドは、デフォルト設定に関係なくすべての /refactor の呼び出しが計画を引き起こすことを確保するために、そのボディに「編集の前に計画を作成してください」をハードコードする可能性がある。

Subagent との相互作用

Subagent はコーディネーターとは異なる独自の plan mode のデフォルトを持てる。Explore subagent は通常直接実行で実行する（その「アクション」は読み取り専用のツール呼び出しである）、一方でリファクタリング subagent はデフォルトで plan mode になる可能性がある。context: fork スキルパターンはこの分離を保持する。

パス固有ルールとの相互作用

.claude/rules/ の YAML ファイルはパスベースの plan mode の義務付けをエンコードできる：「migrations/** に一致するファイルはいかなる書き込みの前にも計画を必要とする。」これがハイブリッドルーティングのための本番グレードのメカニズムである。

一般的な試験の落とし穴 — Plan Mode は別個のモデルではない；直接実行は能力が低いわけではない

CCA-F 試験は Plan Mode vs 直接実行に結びついた3つの落とし穴パターンを積極的に利用する。

落とし穴1：「Plan Mode は別個の Claude モデル」

回答の選択肢は時々、Plan Mode がリクエストを異なるより強力なモデルにルートすることを示唆する。そうではない。同じモデルが両方のモードで回答する。Plan Mode はワークフローの規律であり、モデルのバリアントではない。回答の選択肢が「plan mode はより大きなモデルを使用する」と言っている場合、それは間違いである。

落とし穴2：「直接実行は能力が低い」

直接実行は Claude の能力を低下させない。必須の事前承認ゲートを除去する。「直接実行はマルチファイルタスクを処理できない」または「直接実行はテストをスキップする」と主張する回答の選択肢は間違いである。直接実行モードの Claude はまだテスト、ロールバック、エスカレート、または明確化の質問をすることができる——事前に計画にコミットしないだけである。

落とし穴3：「直接に始めて複雑さが出てきたら計画に切り替える」

これは合理的に聞こえるが、シナリオがすでに複雑さを述べている場合は間違いである。タスクが「45以上のファイルにわたるモノリス-マイクロサービス再構築」と説明されている場合、複雑さは事前にわかっている。直接実行で始めて後で切り替えると、モード切り替えの前に直接実行が実行した発見作業でコンテキストを無駄にする。複雑さが既に要件にある場合、Plan Mode は最初から始まるべきである。

落とし穴4：「Plan Mode は常により安全」

単一ファイルのバグ修正への Plan Mode はレイテンシを追加するが安全性を追加しない。CCA-F のサンプル Q5 パターン（日付検証条件の追加）は意図的に受験者を「安全のために」plan mode に誘惑する。試験はその選択を間違いと採点する。

落とし穴5：「Plan Mode は非インタラクティブ CI で機能する」

インタラクティブな plan mode は承認するユーザーを必要とする。-p で実行する CI パイプラインでは、インタラクティブな plan mode が自動化を壊す。インタラクティブな plan mode を中心にした CI ワークフローを設計する受験者は永遠にハングするパイプラインを生成する。

実践アンカー — タスク 3.4 シナリオ問題

Plan Mode vs 直接実行に結びついた CCA-F の問題は2つのシナリオファミリーに集中する。

Claude Code によるコード生成 — 標準的なシナリオ

コード生成シナリオは Plan Mode vs 直接実行が最も多くテストされる場所である。試験ガイドのサンプル Q5 はこの形を使用する：

開発チームはモノリシックな Python アプリケーションをマイクロサービスアーキテクチャに再構築する必要がある。この作業は認証、請求、レポートモジュールにわたる約45のファイルに影響する。複数の有効な分解戦略が存在し、チームはコードの変更が起こる前にアプローチをレビューしたい。どの Claude Code ワークフローが最も適切か？

正しい回答はPlan Modeである。タスクシグナル——大規模な変更、複数の有効なアプローチ、アーキテクチャ上の決定、マルチファイルのスコープ、明示的な「変更前にレビュー」の要件——はすべて plan mode のトリガーに一致する。

対になるサンプル問題は形を反転させる：

開発者が date-validator.ts の87行目を直接指摘する失敗した単体テストを持っている。スタックトレースは条件の前の null チェックが欠けていることを特定する。どの Claude Code ワークフローが最も適切か？

正しい回答は直接実行である。単一ファイル、明確なスタックトレース、明確にスコープ——計画のオーバーヘッドは修正を超えるだろう。「念のため plan mode に切り替える」は間違いである。

Claude による開発者生産性 — ハイブリッドシナリオ

開発者生産性シナリオは探索-計画-実行の合成をテストする：

開発者は大規模な Python コードベースにわたって requests から httpx へのライブラリマイグレーションを計画している。影響を受ける呼び出しサイトの数は不明であり、マイグレーションにはいくつかの動作の変更（タイムアウトのセマンティクス、応答オブジェクトの形状）が含まれる。どの Claude Code 機能の組み合わせが最も適切か？

正しい回答は、メインのコンテキストを溢れさせずに呼び出しサイトをマッピングするためのExplore subagent、表面がわかったらマイグレーションアプローチをレビューするためのPlan Mode、承認後にステップごとに計画を実装するための直接実行を組み合わせる。いずれか1つのモードを単独で選ぶ回答の選択肢は間違い——シナリオは明示的に3フェーズパターンを呼び出す。

CI 向けの Claude Code — 非インタラクティブの落とし穴

CI シナリオはしばしば plan mode の非インタラクティブパイプラインとの非互換性をテストする：

チームは依存関係の更新を自動化するために -p フラグを使用して GitHub Actions で Claude Code を実行する。プロジェクト全体の CLAUDE.md 設定は現在すべての変更に対して plan mode を義務付けている。パイプラインがハングしている。根本原因は何か？

正しい回答は、インタラクティブな plan mode がユーザーの承認を必要とし、それが非インタラクティブな CI で利用できないことである。修正は CI コンテキストに対して plan mode の義務付けを緩和するか、プログラム的に承認を提供することである。「-p フラグが間違っている」または「異なるモデルを使用する」と答える受験者はその相互作用を見逃している。

Plan Mode vs 直接実行 よくある質問（FAQ）

CCA-F 試験で直接実行よりも Plan Mode をいつ選ぶべきか？

高い爆発半径（マイグレーション、インフラ、セキュリティ重要コード）、アーキテクチャ上の曖昧性（複数の有効なアプローチ）、マルチファイルのスコープ（特にファイル数が大きいと述べられている場合）、または不慣れなコードベースのコンテキストをシナリオが説明する場合にPlan Modeを選ぶこと。標準的なトリガーフレーズは「マルチファイル」または「45以上のファイル」のような明示的なファイル数である。単一ファイル、可逆的、明確にスコープされた変更——明確なスタックトレース、明確な仕様、または1行の条件に典型的——をシナリオが説明する場合に直接実行を選ぶこと。シナリオが複雑さを事前に明示的に述べている場合、直接実行で始めて「複雑さが出てきたら切り替える」ことをしないこと——複雑さはすでにわかっており、plan mode は最初から始まるべきである。

Plan Mode は常により安全な選択か？

いいえ——これはタスク 3.4 で最も一般的な CCA-F の落とし穴である。単一ファイルのバグ修正への Plan Mode は安全性を追加せずにレイテンシとトークンのオーバーヘッドを追加する、なぜなら修正はすでに検証が簡単で元に戻しが簡単だからである。CCA-F のサンプル Q5 パターンは意図的に明確にスコープされたタスクと「安全のために plan mode に切り替える」引っかけ選択肢をペアにする；その引っかけ選択肢は間違いと採点される。Plan Mode は爆発半径に対するアーキテクチャ上の一致であり、ユニバーサルなベストプラクティスではない。

Plan Mode は非インタラクティブ CI パイプラインの -p フラグとどのように相互作用するか？

Plan Mode は基本的にインタラクティブである——計画を承認、修正、または拒否するユーザーを必要とする。-p フラグは CI でノンインタラクティブに Claude Code を実行し、ユーザーがいない。プロジェクトの CLAUDE.md が plan mode を義務付け、同じプロジェクトが -p で呼び出される場合、パイプラインは永遠に届かない承認を待ってハングする。CI で自動化された Claude Code を望むチームは、CI コンテキストで plan mode を無効化するか、plan mode の義務付けを省略する CI 固有の CLAUDE.md パスを使用するか、SDK を通じてプログラム的に承認を提供するかのいずれかにすべきである。

Explore subagent とは何で、Plan Mode と組み合わせていつ使用するか？

Explore subagent は特化した Claude Code subagent であり、分離されたコンテキストで冗長な発見作業——再帰的なファイル読み取り、コールグラフトレース、パターン検索——を実行し、コンパクトなサマリーをメインの会話に返す。タスクが計画を保証するほど複雑だが、発見がメインのコンテキストウィンドウを使い果たすほど大きい場合に Plan Mode と Explore subagent をペアにすること。標準的な3フェーズパターンは：Explore subagent を生成して表面をマッピングし、Plan Mode に切り替えてサマリーから実行計画を作成し、直接実行で承認された計画を実行する。ライブラリマイグレーションと大規模なリファクタリングが標準的なユースケースである。

Plan Mode は直接実行とは異なる Claude モデルを使用するか？

いいえ。Plan Mode と直接実行は同じ能力を持つ同じ基礎モデルを使用する。Plan Mode はアクションへのコミットのタイミングを変えるワークフローの規律——完全な計画を事前に生成してユーザーの承認のために一時停止する——であり、異なるまたは「よりスマートな」モデルではない。Plan Mode がより大きなモデルにルートすることを示唆する CCA-F 試験の回答の選択肢は間違いである。

Plan Mode をプロジェクトのデフォルト動作として設定できるか？

はい。プロジェクトレベルの CLAUDE.md は「ファイルシステムを変更する前に常に計画を作成してください」のような命令を含めることができ、リポジトリのすべてのタスクに対して plan mode をデフォルトとして強制する。CLAUDE.md は3レベルの階層（ユーザー → プロジェクト → ディレクトリ）をサポートするため、デフォルトはタスクが低リスクのディレクトリに対して選択的に緩和できる。ユーザーレベルの CLAUDE.md は個人的なデフォルトも設定できる。典型的な変更が小さな編集であるアプリケーションリポジトリでの常時オン計画には注意すること——儀式のオーバーヘッドが積み重なる。

単一のワークフロー内で Plan Mode と直接実行をどのように組み合わせるか？

標準的なハイブリッドパターンは3フェーズの合成である：メインの会話を溢れさせずにコンテキストを収集するためにExplore subagentを使用し、次にユーザーとアプローチをレビューするためにPlan Modeに切り替え、承認された計画をステップごとに実装するために直接実行で進む。このパターンは CCA-F 試験の開発者生産性シナリオの問題、特にライブラリのマイグレーションとフレームワークのアップグレードに明示的に現れる。シナリオが3つのフェーズすべてを説明している場合に単一のモードを単独で選択することは間違いである。

参考資料

• Claude Certified Architect — Foundations 試験ガイド: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Plan Mode and Iterative Refinement — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• Claude Code Features Overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Create Custom Subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Context Windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Integrate Claude Code into CI/CD Pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• Kishor Kukreja — Passed Anthropic's CCA-F 893/1000: https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

関連する ExamLab トピック：CLAUDE.md ファイル — 階層、スコーピング、モジュラー構成、タスク分解戦略、反復的改善技術、マルチステップワークフロー強制とハンドオフパターン、大規模コードベース探索のコンテキスト管理。