アーカイブへ戻る

Claude Code ソースコード解説シリーズ 第15章: 業界の Plan（選択）

業界の Agent 設計における Plan を比較し、計画が実行制御面へ進化する流れを見ます。

『Claude Code ソースコード解析シリーズ』第15章｜業界の Plan（選択）

前節では Claude Code 自身の Plan Mode を分解した。EnterPlanModeTool が読み取り専用フェーズへの移行を担い、ExitPlanModeTool が計画の提出と権限の回復を担い、Plan subagent がコードベース調査を隔離し、検証 hook が計画を実行後のチェック基準に変換する。

この節では視点を変える。

Claude Code の外に目を向けると、業界の他のエージェントシステムは Plan をどのように設計しているのか？

この問いは、ともすると各ベンダーの機能比較に終始しがちだ。

  • Claude Code には Plan Mode、Plan subagent、permission mode がある。
  • Codex には /plan、Chat/Agent モード、AGENTS.md、subagents、approvals、sandbox がある。
  • Gemini Deep Research には collaborative planning があり、まず研究計画を返し、ユーザーが調整してから実行する。
  • Gemini ADK には Sequential / Parallel / Loop / Graph workflow があり、フロー編成を決定論的ワークフローとして構築する。
  • OpenAI Agents SDK には Agent.as_tool()、handoffs、そしてコードによる agent 編成のパターンがある。

しかし、これらの用語をただ覚えただけでは、読み終わったあとに頭の中でぼやけてしまう。

なぜなら、Plan が本当に解決しようとしているのは、次のような問いではないからだ。

モデルは計画を書けるか？

真に解決しようとしているのは、次の問いである。

エージェントが手を動かす前に、システムはいかにして範囲を画定し、
証拠を集め、リスクを可視化し、承認を得て、
その後の実行をこの計画の中に拘束するのか？

本稿の核心的な主張はこうだ。

現代のエージェントにおける Plan は、「プロンプトの中の『まず考えてみよう』」から離れ、**実行制御面（execution control plane）**の一層へと近づきつつある。

抽象論に終わらせないために、前節の例をそのまま引き継ぐ。

ユーザーの要求：REST API にページネーションを追加する。

このタスクは一見小さく見える。しかし実際のプロジェクトでは、ルーティング層、ORM（オブジェクト関係マッピング。データベースのテーブルをコード上のオブジェクトに対応づける層）、レスポンス形式、パラメータバリデーション、フロントエンドからの呼び出し、テスト、互換性戦略、パフォーマンス境界にまで波及しうる。

1. まず問題の連鎖を整理する

Plan モジュールは、モデルが「手順を列挙できない」から生まれたわけではない。

むしろ、モデルは手順を列挙するのが得意すぎる。計画を書かせれば、ほぼ確実にこう出力する。

1. 要件を分析する
2. インターフェースを修正する
3. テストを追加する
4. 検証を実行する

この計画は間違ってはいないが、役にも立たない。

本当に危険な問いに答えていないからだ。

ページネーションは offset か cursor か？
プロジェクトに既存のページネーション規約はあるか？
レスポンス構造は変更可能か？
古いクライアントに影響は出るか？
インデックスを追加すべきクエリはどれか？
互換性が破壊されていないことを証明できるテストはどれか？

つまり、Plan の問題進化の連鎖はおおよそ次のようになる。

単一ターンのチャットで直接質問に答えられる
-> エージェントがファイルを読み、コードを修正し、コマンドを実行し始める
-> 早すぎる実行は実害をもたらす
-> そこで実行前の読み取り専用の調査フェーズが必要になる
-> 読み取り専用の調査は大量のコンテキストノイズを生む
-> そこで調査コンテキストの分離か明示的な計画オブジェクトが必要になる
-> 計画が依然としてユーザーの期待とずれる可能性がある
-> そこで承認ゲートと修正可能な計画が必要になる
-> 実行フェーズで元の計画から逸脱する可能性がある
-> そこで検証・復旧・ロールバックの根拠が必要になる

この連鎖が示すのは、Plan が孤立したモジュールではないということだ。Plan は必然的に次の5つを引き連れてくる。

読み取り専用ツール
コンテキスト管理
計画オブジェクト
人間による承認
実行検証

業界の差異は主に「Plan があるかどうか」ではない。

違いは、各社がこの5つの要素をシステムのどのレイヤーに置くかだ。

（ある企業はプロンプトレイヤーに置き、ある企業は実行時権限レイヤーに置き、ある企業は API プロトコルの状態として実装する。後述するが、これがシステムのエンジニアリング成熟度を直接左右する。）

2. 共通構造：Plan レイヤーはたいてい「目標」と「実行」のあいだに挟まる

Claude Code であれ、Codex であれ、Gemini であれ、Plan レイヤーはおおむね次のようなことをしている。

ユーザー目標
-> 計画レイヤー
   -> スコープの画定
   -> 読み取り専用の調査
   -> 手法の比較
   -> リスクの表明
   -> 計画の出力
-> 承認ゲート
-> 実行レイヤー
-> 検証レイヤー

これを最小の状態遷移マシンとして描くとこうなる。

Scope -> Research -> DraftPlan -> Review -> Execute -> Validate

この中で Review はもっとも過小評価されがちなステップだ。

多くのデモで登場する Agent は、次のように一直線で進む。

目標 -> 計画 -> 実行

しかし実際のプロダクト開発では、あいだにもうひとつ層が要る。

目標 -> 計画 -> 人間／ポリシー承認 -> 実行

なぜか。

Plan の段階でしばしばトレードオフが露呈するからだ。

ページネーションに古いパラメータとの互換性を持たせるべきか？
レスポンスフィールドの変更を許容するか？
ついでにクエリレイヤーをリファクタリングしていいか？
フロントエンド側の呼び出しも同時に修正するか？
テストのカバレッジ粒度はどこまで求めるか？

これらはモデルの知能の問題ではなく、プロダクトとエンジニアリングの境界の問題だ。

端的に言えば、優れた Plan システムとは、こうしたトレードオフを明示的に提示するものであって、ユーザーに内緒で勝手に決め打ちしてしまうものではない。

（決め打ちされた結果：リリース後にフロントエンドが壊れて、プロダクトマネージャーから「レスポンスフォーマットを変えたのは誰だ」と詰められても、沈黙するしかなくなる。）

3. Claude Code：Plan を読み取り専用の調査と権限境界として設計する

前節で Claude Code の Plan Mode を分解した。業界比較の中に置いてみると、最も際立つ特徴は次の点だ。

Claude Code は Plan をランタイム権限レイヤーとサブエージェント調査レイヤーに配置している。

「まず計画を立ててください」とプロンプトで頼んでいるだけではない。

Plan Mode を権限状態に変えているのだ。Plan Mode に入ると、ファイル書き込み、編集、危険なコマンドといった操作が制限される。コードベースの理解が必要な場合は、システムが組み込みの Plan サブエージェントに調査を委任することもできる。

この設計はコーディングエージェントに特によく合う。

コードを書く上で最大のリスクは、**「プロジェクトをまだ理解していないのに、変更を始めてしまう」**ことだからだ。

ページネーションの例で見ると、Claude Code の理想的な流れは次のようになる。

ユーザー：REST API にページネーションを追加して
-> Plan Mode に入る
-> Plan サブエージェントが既存のエンドポイント、レスポンス形式、ORM の書き方、テスト構造を読み取り専用で検索
-> メインスレッドが調査結果を統合
-> offset / cursor / 互換性戦略を提案
-> ユーザーが承認
-> 書き込み権限を復帰
-> 実行して検証

ここでの Plan サブエージェントの価値は「並列検索」だけではない。

より重要なのはコンテキスト衛生だ。大量の検索パス、無関係なファイル、除外プロセスがすべてメインスレッドを汚染することはない。メインスレッドが受け取るのは調査の結論であり、膨大な探索ノイズではない。

つまり、Claude Code の Plan 哲学は次のように要約できる。

まずエージェントを読み取り専用の部屋に閉じ込め、全体を見通させてから、外に出して作業させる。

利点は安全性、抑制の効いた動作、コードベース探索への適合性である。

その境界線は、公開資料の中に固定されたプランスキーマや中央プランナー AST（抽象構文木、コード構造のツリー形式の中間表現）が見当たらないことだ。

言い換えれば、Claude Code は Plan をランタイムの段階として作っており、構造化された計画プロトコルとして作っているわけではない。

4. Codex：Plan をインタラクティブな操作面とエンジニアリングワークフローに昇華する

Codex は少し趣が異なる。

Claude Code の重点が「リードオンリーな調査＋権限モード」だとすれば、Codex はむしろ Plan を次のようなものとして位置づけている。

インタラクティブモード
+ プロジェクト命令
+ タスクリスト
+ subagent オーケストレーション
+ approval / sandbox

Codex CLI には /plan がある。plan mode に切り替え、Codex にまず実行計画を提案させてから実装に入る、という流れだ。

Codex は作業開始前に AGENTS.md 命令チェーンを読み込み、グローバルルール、プロジェクトルール、カレントディレクトリのルールを組み立てる。

つまり Plan フェーズで目にするのはユーザーの一言だけではなく、プロジェクト自身の作業プロトコルでもある。

ここが肝だ。

同じ「REST API にページネーションを追加して」という指示でも、裸のモデルが見るのは次の一行だけだ。

ページネーションを追加して。

一方、Codex の Plan フェーズでは、同時にこんな情報を目にしている可能性がある。

ユーザー目標：REST API にページネーションを追加する
AGENTS.md：すべてのインターフェースは backward compatible を維持すること
AGENTS.md：API パラメータのバリデーションは Zod に統一する
AGENTS.md：変更後は必ず npm test と typecheck を実行すること
カレントディレクトリのルール：users service はデータベースに直接アクセスしてはならない

このとき計画は、モデルがその場で考えた手順ではなく、ユーザー目標とプロジェクトの規約が合成された実行ブループリントになる。

Codex の二つ目の特徴は、Plan とコラボレーションを極めて密に結びつけている点だ。

公式の subagents ドキュメントによれば、Codex は複数の specialized agents を生成して並列作業させ、その結果を一つのレスポンスに集約できる。ただし強調されているのは、Codex が subagents を spawn するのはユーザーが明示的に要求した場合に限るという点だ。

これは、Codex のマルチエージェントが自律増殖するわけではなく、中央ランタイムに制御された fan-out / fan-in であることを示している。

Plan に置き換えると、こういう構図になる。

ユーザー目標
-> /plan でまず大まかな方向性を決定
-> 必要に応じて明示的に explorer / reviewer / worker を並列調査用に起動
-> サブ結果をメインスレッドに還流
-> メインスレッドが計画を更新
-> ユーザー承認後に実行

Codexの第3の特徴は、approvalとsandboxがかなり前方に位置していることだ。

Planは書いて終わりではなく、引き続き実行環境の制約を受ける。

approval policy が「どのアクションをユーザーに確認するか」を決める
sandbox が「どのディレクトリを読み書きできるか」「ネット接続の可否」を決める
subagent は親の実行境界を引き継ぐ
非対話タスクで承認不可の高リスクアクションに遭遇した場合、失敗としエラーを返す

つまり、CodexのPlanは工学的な制御面に近い。

まず計画
-> プロジェクトルールで制約
-> サブAgentへの分担を判断
-> 承認とsandboxを通過
-> 最後に実行と集約

利点は工学的な強度が高く、長時間タスク、PR修正、コードレビュー、明確なチーム規約を持つプロジェクトに適していることだ。

限界もある。公開情報には、内部でどのような記号プランナーや木探索、再現可能なプランナーアルゴリズムを使っているかの説明はない。確かめられるのは外部制御面のみであり、隠れた推論メカニズムではない。

Codexを一言で表すなら：

CodexのPlanは「考え終えてから実行する」ではなく、「目標、ルール、権限、分担、検証方法をまず組み上げてから実行する」だ。

5. OpenAI Agents SDK：Plan はモデルにもコードにも委ねられる

Codex はプロダクトとエンジニアリングのワークフロー寄りだ。OpenAI Agents SDK は別の問題をより際立たせている。

エージェントのフローはモデルが決めるべきなのか、それともコードが決めるべきなのか？

Agents SDK の orchestration ドキュメントは、オーケストレーションを次の2つに分類している。

LLM orchestration：モデル自身に計画、ツール呼び出し、specialist へのハンドオフを行わせる。
Code orchestration：コードがフロー、順序、並列性、ループ、終了条件を決定する。

これは Plan にとって重要だ。

Plan というと「モデルにもっと推論させる」と決めつける人が多い。しかし本番システムでは、すべてのフローをモデルに委ねられないことがよくある。

たとえばページネーションタスクでは方針検討をモデルに任せられるが、次のような制御ポイントはコードやランタイムが握るべきだ。

読んでから書く
既存のテストを先に実行する
ユーザー承認を待つ
スキーマとフロントエンドの同時変更を禁止する
失敗時は plan review に戻す

Agents SDK における2つの定番パターンも、Plan の実行方式の分岐点として捉えられる。

Agents as tools：
  manager が制御権を保持し、specialist をツールとして呼び出す。

Handoffs：
  triage agent が制御権を specialist に委譲し、specialist に後続のフローを引き継がせる。

前者は計画内の部分的なサブタスクに適している。たとえば「セキュリティレビュアーにページネーションパラメータのインジェクションリスクを確認させる」といったケースだ。

後者は本格的に対話の役割を切り替える場合に適している。たとえば「要件明確化エージェントから実装エージェントに引き継ぐ」といったケースだ。

つまり SDK レイヤーから得られる示唆は次のとおりだ。

Plan は必ずしも自然言語で記述しなければならないわけではない。
確定できるフローはコードで固定し、
判断が必要な部分はモデルの計画に委ね、
リスクの高い動作は人間の承認ゲートの背後に置く。

これこそが、多くのエージェントシステムが「1つの巨大なプロンプト」から「LLM + ワークフローグラフ + ガードレール」へと進化していく理由でもある。

（要するに、プロンプトだけでは足りなくなってくる。本当に効くのは長大なプロンプトではなく、ランタイムが「いつ止め、いつ通すか」を知っていることだ。）

6. Gemini：Plan を API ステートマシンとして公開する

Gemini Deep Research の collaborative planning は、現在公開されている資料の中で最も「Plan プロトコル」に近い設計の一つです。

単にモデルに「まず計画しろ」と指示するのではありません。計画を 3 つの API 段階に分解しています。

Step 1：collaborative_planning=true を設定し、研究計画をリクエスト
Step 2：previous_interaction_id で refine を継続、planning mode を維持
Step 3：collaborative_planning=false または省略で、承認して実行開始

これは非常にクリーンです。

ユーザーはチャットボックスで感覚的に「OK」と言うのではありません。同じ interaction チェーンを通じて、計画を「ドラフト」から「承認済み実行」へと段階的に進めていくのです。

ページネーションの例で類推してみましょう。

1 回目の interaction：
  API ページネーション改修案を調査してください。計画のみ返してください。

2 回目の interaction：
  計画内のフロントエンド変更を減らし、既存パラメータとの互換性を優先してください。

3 回目の interaction：
  計画を確認しました。実行を開始してください。

もちろん、Gemini Deep Research は主にリサーチタスクを対象としており、コードを直接変更する coding agent ではありません。

しかし、Plan モジュールへの示唆は極めて強いものがあります。

Plan は、会話の中の一時的なテキストではなく、プロトコルレベルの状態になり得る。

Gemini ADK はさらに別のレイヤー、workflow agents を補完しています。

ADK の Workflow Agents には、Sequential、Parallel、Loop といった型があります。これらは LLM が動的にフローを決定するのではなく、事前定義されたロジックでサブ agent の実行順序を制御します。

これは、Gemini エコシステムが planning を 2 層に分解していることを示しています。

モデル層：理解、推論、計画の生成または改訂を担当。
ワークフロー層：確定したフローを逐次、並列、ループ、またはグラフとして固定化することを担当。

これは本番システムに非常に適しています。

たとえば、ページネーション改修は次のように分解できます。

Sequential:
  inspect existing API conventions
  draft migration plan
  wait for approval
  implement backend
  run tests

Parallel:
  reviewer checks compatibility
  reviewer checks performance
  reviewer checks API docs

Loop:
  run tests -> fix failures -> run tests
  until tests pass or retry limit reached

この段階になると、Plan は単なる Markdown のリストではなく、実行グラフを駆動する構造へと変わる。

Gemini を一言でまとめると次のようになる。

Gemini の公開設計では、Plan を対話的に操作・再開・承認可能な API セッションに変えることに重点が置かれている。一方 ADK は、決定論的なフローをモデルの外に取り出し、予測可能なワークフローに落とし込むアプローチを採っている。

7. 3つの設計を1つの表にまとめる

Claude Code、Codex、Gemini を並べて見ると、その違いがはっきりしてくる：

システムPlan の主な着地点最強の能力適したシナリオ主な制約
Claude CodePlan Mode + Plan Subagent + 権限モード読み取り専用調査、コンテキスト分離、権限境界コードベース探索、複雑な変更前の安全な計画立案公開情報ではランタイム段階寄りで、固定の plan スキーマは強調されていない
Codex/plan / Chat / Agent モード + AGENTS.md + Subagent + 承認/サンドボックスエンジニアリングワークフロー、プロジェクトルール注入、中央集権的なオーケストレーションPR 修正、コードレビュー、長時間タスク実行、チーム規範のあるプロジェクト公開資料では主に制御面が露出されており、内部のプランナーアルゴリズムは公開されていない
Gemini Deep Research協調的計画立案 + Interactions API計画・修正・承認の3段階ステートマシン長時間の調査タスク、レポート生成、人間による調査範囲の調整が必要なタスク主にリサーチエージェント向けであり、直接的なコーディングランタイムではない
Gemini ADKWorkflow Agents / Graph ワークフロー決定論的フロー、逐次・並列・ループのオーケストレーション本番レベルのエージェントワークフロー、マルチステップのプラットフォーム機能開発の複雑度が高く、フローを明示的にモデル化する必要がある

この表の背後には、さらに重要な結論がある：

Claude は Plan を権限境界にした。
Codex は Plan をエンジニアリング制御面にした。
Gemini は Plan を API ステートマシンとワークフローにした。

三者はいずれかが他を代替するものではなく、異なるレイヤーで同じ問題を解決しているのだ。

8. Plan を神秘的なアルゴリズムとして扱わないこと

ここで特に境界線を一つ補足しておきます。

多くの人がこう問います。

これらのシステムは MCTS を使っているのか？
記号的プランナーを備えているのか？
隠された planner AST を持っているのか？

公開情報を踏まえると、最も無難な見解はこうです。そう仮定してはいけない。

Claude、Codex、Gemini はいずれも reasoning、thinking、agent loop、tool use、subagents、workflow を強調していますが、公開ドキュメントにおいて、それらの Plan モジュールが再現可能な古典的プランナーとして記述されているわけではありません。

したがって、これらのシステムを読むときに、Plan を次のように捉えてはいけません。

神秘的なプランナーアルゴリズム

むしろ、次のように捉えるべきです。

プロンプト駆動の計画
+ 読み取り専用の証拠収集
+ 明示的な状態
+ ツール権限
+ 人間による承認
+ 実行検証

この捉え方のほうが、むしろ工学的な価値があります。

なぜなら、自分で Agent Harness を実装するときに実際に再利用できるのは、「ベンダーが内部でどう考えているかを推測すること」ではなく、公開され観察可能なこれらの制御面だからです。

9. Plan を自前で実装するなら、4 層に分解できる

特定の実装をそのまま模倣するのではなく、業界に共通する設計だけを抽象化すると、最小限かつ信頼できる Plan システムは次の 4 層に分割できる。

第一層、モード層。

mode = chat | plan | execute

小さな質問には即答し、複雑なタスクはまず plan に入り、ユーザーが承認してから execute に進む。

第二層、ツール層。

plan mode:
  allow: read, search, inspect, safe command
  deny: write, edit, delete, 状態変更シェル, 外部副作用

execute mode:
  allow: 承認ポリシーとサンドボックスに従う

プロンプトだけでモデルを制約してはいけない。実行時に、現在の段階で副作用を起こせるかどうかを知っていなければならない。

第三層、計画オブジェクト層。

{
  "goal": "REST API にページネーションを追加",
  "assumptions": ["既存パラメータとの互換性を維持"],
  "evidence": ["既存の一覧 API が limit/offset を使っている"],
  "steps": [
    "レスポンス形式を確認",
    "users route を修正",
    "パラメータバリデーションを追加",
    "テストを追加",
    "test と typecheck を実行"
  ],
  "risks": ["レスポンス構造の変更がフロントエンドに影響する可能性"],
  "validation": ["既存テストが通ること", "新規ページネーションテストが通ること"]
}

計画オブジェクトは必ずしも JSON である必要はなく、Markdown、タスク表、ExecPlan、ワークフローグラフでも構わない。

重要なのは、復元可能であり、レビュー可能であり、実行段階から参照可能であることだ。

第四層、承認と検証層。

DraftPlan
-> ユーザーによる修正 / 承認
-> Execute
-> Validate(actual_diff, approved_plan)
-> 完了 / Plan に戻る

承認がなければ、Plan はモデルが独り言を言っているだけになりかねない。

検証がなければ、Plan は実行前の儀式にすぎなくなる。

10. Claude Code に立ち返る：なぜこの章を Plan の後に置いたのか

業界のアプローチを理解した上で Claude Code の Plan Mode を振り返ると、その立ち位置がよりはっきり見えてくる。

Claude Code は Plan を最も複雑なプロトコルに仕立てることも、明示的なワークフローグラフにすることもしなかった。

選んだのは、コーディングエージェントにおける最も決定的な一手だ：

実行前にまず読み取り専用で。

素朴に見える一手だが、極めて効果的だ。

コードツールにとって最大のリスクは、モデルが考えられないことではなく、あまりに早く変更を始めてしまうことだからだ。読み取り専用の Plan Mode、Plan サブエージェント、権限の復元、計画の永続化、検証フック——これらの仕組みが組み合わさることで、「まず理解し、それから行動する」という原則は、モデルの自覚からランタイムの制度へと格上げされる。

Codex と Gemini はさらに別の示唆を与えてくれる。タスクが「ローカルコードの修正」から「チーム開発フロー」や「長時間のリサーチワークフロー」へと広がるとき、Plan は新たなかたちへと成長し続けるという示唆だ：

Codex：プロジェクトルール + サブエージェント編成 + approval/sandbox
Gemini：協調的計画 API + ワークフローグラフ

つまり Plan の終着点は「モデルにもっと上手い計画を書かせること」ではない。それは：

不確実性を前に出し、副作用を後に回し、ユーザーの意思決定を重要な関門に戻し、実行結果を計画検証へと引き戻すこと。

これこそが、モダンな Agent Harness と単なるチャットボットを分かつ境界線のひとつなのだ。