Codex vs Claude Code：サブエージェント設計思想の分岐点¶

対象 / ポイント

対象: AIコーディングエージェントを業務で使用中、またはこれから導入を検討しているエンジニア。Codex CLIまたはClaude Codeの基本操作を理解していることを前提とする。

ポイント:

両ツールの設計分岐を「信頼モデル」の違いとして整理し、ツール選定の判断軸を得られる
Codex（明示的スポーン＋TOML定義）とClaude Code（暗黙的委譲＋Markdown定義）の設計差を構造的に比較できる
監査要件・チームのAIリテラシー・ワークフローの定型度に応じた選択指針がわかる

サブエージェントはなぜ必要になったのか¶

このセクションが答える問い

単一エージェントの何が限界で、サブエージェントはどの問題を解くのか。

大規模コードベースでAIコーディングエージェントを動かすと、3つのボトルネックに突き当たる。

コンテキスト汚染——ファイル探索で得た大量のテキストがメインの会話窓に溜まり、本来の実装判断に使えるトークンが減少する
逐次実行の遅さ——認証モジュールの調査→DBスキーマの確認→APIパターンの把握という独立した3タスクを直列に回すと、並列実行の3倍の壁時間がかかる
権限の粗さ——探索だけが目的のタスクにも書き込み権限がフルで渡り、本番コードベースでの安全性を担保しにくい

サブエージェントはこの3つを同時に解決する。メインエージェントがオーケストレータとして振る舞い、個別の調査・実装タスクをそれぞれ独立したコンテキストウィンドウを持つサブエージェントに委譲する。探索ノイズはサブエージェント内に閉じ込められ、メインには要約だけが返る。独立したタスクは並列に走り、読み取り専用のサブエージェントには書き込みツールを渡さないことで権限を最小化できる¹²。

この構造は「オーケストレータ＋サブエージェント」パターンと呼ばれる。Claude Codeは2025年後半からAgentツール（旧称Task）として実装していた²。Codexも2026年3月中旬のリリースでサブエージェントワークフローをデフォルト有効とし、公式ドキュメントでも安定機能として整理された¹。主要AIコーディングエージェントの双方がこのパターンを正式に採用した形になる。

では、同じパターンを採用した両者の設計は、具体的にどこが同じでどこが違うのか。

アーキテクチャ比較：設計判断はどこで分岐するか¶

このセクションが答える問い

両者のサブエージェント設計は、具体的にどこが同じでどこが違うのか。

共通する設計原則¶

両者が共有する設計判断は、表面的な類似ではなく構造的な収束として捉える必要がある。

コンテキスト分離。サブエージェントはそれぞれ独立したコンテキストウィンドウを持ち、中間のツール呼び出し結果は親に返らない。親が受け取るのは最終メッセージ（要約）のみ。これにより探索コストがメインの文脈を圧迫しない¹²。

読み取り中心のエージェントの標準化。Codexのexplorerは「read-heavy」な探索専用エージェントとして設計されており、sandbox_modeでread-onlyに制限できる¹。Claude CodeのExploreはWrite・Editツールへのアクセスを明示的に禁止している²。いずれも本番コードベースで安全に並列探索を走らせるための意図的な制約である。

カスタムエージェント定義。プロジェクトスコープまたはユーザースコープで独自のエージェントを定義でき、モデル選択・ツール制限・専用プロンプトを個別に設定可能。

共通の骨格が見えたところで、分岐する設計判断を4つの問いに沿って整理する。

分岐する設計判断¶

委譲は誰が決めるか¶

Claude Codeのサブエージェントは暗黙的委譲を基本とする。メインエージェントがタスクの性質とサブエージェントのdescriptionを照合し、自動的に適切なサブエージェントを選択・起動する²。ユーザーが「サブエージェントを使え」と明示しなくても、計画モードではPlanサブエージェントが、コードベース探索ではExploreサブエージェントが自動で起動する。

明示的に呼び出したい場合は、自然言語での指示や@メンションによるセッション単位の指定という段階的な手段も用意されている²。

一方、Codexは明示的スポーンを採用する。ユーザーがプロンプト内で「Spawn one agent per point」のように明確に指示しない限り、サブエージェントは起動しない¹。この設計はトークン消費の予測可能性を優先している。

# Codexでの典型的な起動プロンプト
Spawn one agent per point, wait for all of them,
and summarize the result for each point.
1. Security issue
2. Code quality
3. Bugs

ユーザーが「spawn」と書いた瞬間に初めてサブエージェントが起動する。Claude Codeでは同等のタスクを渡すと、エージェント側の判断で自動的にAgentツールが起動する場合がある。

エージェントを何で定義するか¶

項目	Codex	Claude Code
定義形式	TOML	Markdown＋YAMLフロントマター
配置場所（プロジェクト）	`.codex/agents/`	`.claude/agents/`
配置場所（ユーザー）	`~/.codex/agents/`	`~/.claude/agents/`
必須フィールド	`name`, `description`, `developer_instructions`	`name`, `description`（本文がプロンプト）
モデル指定	`model`フィールド（省略時は親から継承）	`model`フィールド（省略時は親から継承）
権限制御	`sandbox_mode`で個別オーバーライド可	`permissionMode`で5段階の制御

Codexはインフラ設定ファイルの慣習に沿ったTOMLを採用し、developer_instructionsを明示的なフィールドとして分離する¹。Claude CodeはMarkdownの本文自体がシステムプロンプトとなる設計で、ドキュメンテーションとエージェント定義が一体化する²。

並列性をどこまで制御できるか¶

Codexのagents.max_threadsはデフォルト6、agents.max_depthはデフォルト1（直接の子エージェントのみ許可、再帰的ネストは禁止）と、公式ドキュメントで明示されている¹。CSV一括処理ではspawn_agents_on_csvツール（experimental）を通じて1行1ワーカーのバッチ処理も可能だ。各ワーカーはreport_agent_job_resultで結果を報告し、SQLiteで状態管理される¹。

Claude Code側では、Codexのmax_threads/max_depthに直接対応する公開設定は現行ドキュメントで確認しにくい。並行数の実質的な制御はプロンプトエンジニアリング（「5つのサブエージェントを並列で起動せよ」のような明示指示）に委ねられる形が主流となっている。

ただし、Claude CodeにはAgent Teams（実験的機能）がある。複数の独立したClaude Codeセッションが共有タスクリストとメールボックスメッセージングで協調するという、サブエージェントとは別レイヤーの並列性だ³。

エージェント同士を会話させられるか¶

Codexの最新リリース（2026年3月26日、multi-agent v2）では、サブエージェントにパスベースのアドレス（/root/agent_aのような形式）が割り当てられ、構造化されたエージェント間メッセージングが導入された⁴。実行中のサブエージェントにステアリング指示を送ることも可能になっている。

Claude Codeのサブエージェント間通信は、現時点では親→子の一方通行が基本。親がAgentツールのプロンプト文字列でコンテキストを渡し、子は最終メッセージで結果を返す²。Agent Teams（マルチセッション）では共有タスクリストとメールボックスによるピアツーピア通信が可能だが、Codexのような構造化メッセージングとは性質が異なる³。

ビルトインエージェントの構成¶

ロール	Codex	Claude Code
読み取り専用探索	`explorer`	`Explore`（Haikuモデル）
汎用実行	`default`	General-purpose
実装特化	`worker`	――（汎用が兼ねる）
計画特化	――	`Plan`（計画モードで自動起動）
バッチ処理	`spawn_agents_on_csv`（experimental）	――
Bash実行	――	`Bash`（コンテキスト分離用）

Codexはworkerという書き込み権限付きの実行専用ロールを明確に分離している¹。Claude CodeはPlanサブエージェントという計画フェーズ専用のロールを持つ²。この差は、Codexが「タスクの実行単位」を、Claude Codeが「思考のフェーズ」をサブエージェント化の軸にしていることを示唆する。

実運用での選択基準¶

このセクションが答える問い

どのようなユースケースで、どちらのサブエージェント設計が有利に働くか。

Codexが優位に立つケース¶

バッチ処理・定型監査。100リポジトリの依存パッケージを週次でチェックするCI/CDジョブを想定してほしい。spawn_agents_on_csvは「CSVの各行に対して同一プロンプトで1ワーカーを起動し、結果をCSVにエクスポート」する定型処理に特化している（experimental）¹。入力が構造化されている場面——セキュリティ監査、マイグレーション対象の一括チェック——で威力を発揮する。

トークン消費の予測可能性。明示的スポーンモデルのため、ユーザーが意図しないサブエージェント起動が発生しない。APIの従量課金で運用する場合、コスト管理が容易になる。

クラウドネイティブなワークフロー。Codexはもともとクラウドサンドボックス上で動作する設計であり、CI/CDパイプラインからのcodex exec経由の非対話実行と相性が良い。

Claude Codeが優位に立つケース¶

探索的・対話的な開発。新機能のプロトタイピングで設計方針が未確定の場面を想像してほしい。暗黙的委譲により、ユーザーがサブエージェントの存在を意識せずとも最適なエージェントが選択される。プランモードでPlanサブエージェントが自動起動する挙動は、思考→実装の流れを自然にする²。

コンテキスト節約の自動化。Exploreサブエージェントがデフォルトでlightweight model（Haiku）で動作するため、読み取り探索のコストが暗黙的に最適化される。メインセッションはOpusで複雑な推論を行い、探索はHaikuに委譲する——この分離が設定なしで実現する²。

Hooksによるライフサイクル制御。SubagentStart/SubagentStopイベントにフックを仕掛けることで、サブエージェントの起動・終了時にカスタムロジックを実行できる⁵。たとえばサブエージェント起動時にSlack通知を飛ばす、終了時にログを集約するといった運用が可能になる。

まとめ¶

両ツールが「オーケストレータ＋読み取り専用探索エージェント＋書き込み可能な実行エージェント」という骨格を共有していることは、公式ドキュメントの仕様を並べれば確認できる事実である¹²。AIコーディングエージェントにおけるマルチエージェントアーキテクチャのパターンが固まりつつある。

ただし、標準化されたのはパターンの骨格であり、制御の粒度は分岐している。Codexは構造化メッセージング（multi-agent v2）とバッチ処理（CSV fan-out）で「プログラマブルなオーケストレーション」に向かっている。Claude CodeはAgent Teamsと共有タスクリストで「自律的なチーム協調」に向かっている。

この分岐の核心は運用責任の所在の違いにある。Codexでは、サブエージェントの起動タイミング・並行数・ネスト深度をユーザーが明示的に設計する。fan-outの設計はユーザーの責任であり、その分だけ監査性と予測可能性が高い。Claude Codeでは、エージェント自身がタスクの性質を判断して委譲先を選ぶ。認知負荷は下がるが、事後追跡はHooksなどの仕組みで補う必要がある⁵。

つまり、Codexはユーザーの明示的指示を信頼の起点とし、Claude Codeはエージェント自身の判断を信頼の起点とする。監査要件が厳しく定型処理が多いプロジェクトではCodexの明示性が、探索的で対話的な開発フェーズではClaude Codeの自律性が、それぞれ有利に働く。

この「信頼モデル」の分岐が次に問われるのは、エージェント間プロトコルの標準化の局面だろう。GoogleのA2A（Agent-to-Agent）やAnthropicのModel Context Protocolのように、異なるベンダーのエージェント同士が協調する枠組みが整備されつつある。そのとき、明示的スポーンの予測可能性と暗黙的委譲の柔軟性のどちらがプロトコル設計と相性が良いかが、次の設計判断の分水嶺になる。

Codex vs Claude Code：サブエージェント設計思想の分岐点¶

サブエージェントはなぜ必要になったのか¶

アーキテクチャ比較：設計判断はどこで分岐するか¶

共通する設計原則¶

分岐する設計判断¶

委譲は誰が決めるか¶

エージェントを何で定義するか¶

並列性をどこまで制御できるか¶

エージェント同士を会話させられるか¶

ビルトインエージェントの構成¶

実運用での選択基準¶

Codexが優位に立つケース¶

Claude Codeが優位に立つケース¶

まとめ¶

関連記事¶