CodexのMulti-Agentsは何が違うのか？ Subagent / Agent Teamsとの違いを通信構造で整理する

TL;DR

• Subagent は「親から仕事を受け、独立コンテキストで処理し、結果を親に返す」基本形として捉えるとわかりやすい
• Codex Multi-Agents は、複数の作業スレッドを親が並列管理する中央集権型として読むと整理しやすい
• Claude Code Agent Teams は、親に戻すだけでなくチームとして協調する設計思想が前面に出ている

はじめに

Subagent、Multi-Agents、Agent Teams。

名前は違うのに、見た目はどれも「複数のエージェントっぽい何か」です。ここで機能比較を始めると、だいたい途中で混線します。なぜなら、表面の UI や実行方法より先に、誰が誰とどう情報をやり取りするのかを見たほうが本質に近いからです。

この記事では、Codex Multi-Agents / Claude Code Subagents / Claude Code Agent Teams の違いを、通信トポロジーに絞って整理します。

2026年3月12日時点の公開一次ソースとして、OpenAI は Codex の紹介 と Codex app で複数エージェントを並列実行するヘルプ、Anthropic は Subagents ドキュメント と Claude Code Agent Teams の発表 を参照しています。なお、本記事の「中央集権型」「協調型」は、公式説明を通信構造として読み替えた整理です。

ここで先に線を引いておくと、これは同じ製品にある同格の3機能を横並び比較する記事ではありません。OpenAI は公開一次ソース上で Subagent という用語を採用しておらず、Anthropic も Agent Teams を単なる Subagent の複数版としては説明していません。あくまで、読者が混同しやすい3つの概念を「通信構造」で揃えて読む整理です。

1. 先に結論: 違いは通信トポロジーにある

細かい機能差に入る前に、結論だけ先に置きます。

要するに、違いは「並列で動くかどうか」だけではありません。より大きいのは、協調の中心が親にあるのか、チーム側にあるのかです。

2. 前提: Subagentという基本形

まず比較の起点になるのが Subagent です。

Anthropic の Subagents ドキュメントでは、Subagent は専用の system prompt と separate context window を持つ作業者として説明されています。親セッションから仕事を受け、独立した文脈で処理し、結果を返す。この形で理解すると、かなりスッキリします。

Subagent の基本形は次のように表せます。

親セッション
  -> Subagent A がタスクを受ける
  -> A は独立コンテキストで処理する
  -> A は結果を親へ返す

この形の強みは明快です。

• メインのコンテキストを汚しにくい
• 専門タスクを隔離して任せやすい
• 作業の入口と出口が親に集約される

逆に言うと、Subagent は「小さな作業部屋」であり、最初から横連携の強いチームとしては作られていません。ここを土台にすると、Codex Multi-Agents と Agent Teams の違いが見えやすくなります。

3. Codex Multi-Agentsとは何か

OpenAI の公式説明では、Codex app はmultiple agents in parallel を前面に出しています。さらに Help の説明では、各エージェントはseparate threads organized by projects で動き、worktree を使うとisolated copy of your code ごとに並列実行できます。

この説明からわかるのは、Codex Multi-Agents が単なる「Subagent をいっぱい増やしただけ」ではなく、複数の作業スレッドを親が並列に管理する仕組みだということです。より厳密に言うと、OpenAI 自身はここで Subagent という名前を使っていません。したがって本記事の比較は、機能名の対応表ではなく、構造の似ているものを並べて読むための概念整理です。

なぜ中央集権型と捉えるのか

公開されている一次ソースを見る限り、OpenAI が強調しているのは次の3点です。

1. 複数エージェントを同時に走らせられること
2. 各エージェントが別スレッド・別 worktree で独立していること
3. 人間がスレッドをレビューし、必要に応じて次の指示を出せること

ここから見えてくるのは、親がハブになる構造です。

            -> Agent A
親セッション -> Agent B
            -> Agent C

結果や追加指示は基本的に親が扱う

このモデルは、実務ではかなり強いです。たとえば「1本は仕様調査」「1本は実装」「1本はテストケース洗い出し」のように、相互依存がまだ弱い段階では非常に扱いやすい。人間が Lead として全体を見て、必要なときだけ中継すればいいからです。

関連する運用論は、AIをチームメンバーとして働かせる運用 や エージェント開発の人間役割 でも相性よく読めます。

4. Codex Multi-Agentsの限界: エージェント同士は直接話す前提ではない

ここがいちばん重要です。

OpenAI の公開説明では、Codex Multi-Agents は別スレッドを並列に管理するモデルとして記述されています。一方で、Anthropic の Agent Teams のような「チームとして自律協調する仕組み」や、メンバー間の明示的な通信レイヤについては公開ドキュメントで前面には出てきません。

そのため、少なくとも公開説明ベースでは、Codex Multi-Agents は次のように読むのが自然です。

• A の発見を B に伝えたいときは、親が中継する
• 情報共有の中心は親スレッドにある
• ワーカー同士が勝手に相談して前進するモデルではない

つまり、A -> 親 -> B の構造です。

これは弱点であると同時に、ガバナンス上の強みでもあります。親が必ず情報経路に入るので、レビュー、承認、優先順位変更を入れやすい。スター型、中央集権型、親オーケストレーション型という表現がしっくりきます。

より広い設計パターンとして見たいなら、実践！マルチエージェント・デザインパターン も合わせて読むと位置づけがつながります。

5. Claude Code Agent Teamsとは何か

Anthropic の公式発表で Agent Teams は、multiple Claude Code agents work in parallel as a team and coordinate autonomously around the clock と説明されています。ここで焦点になっているのは、「親から仕事を受けて返す」よりも、チームとして協調して前進することです。

この点で Agent Teams は、Subagent の拡張というより、協調レイヤを強化した別のモデルとして読むほうが理解しやすいです。

Subagent が「独立ワーカー」だとすると、Agent Teams は「役割を持つ複数メンバーが、チームとして進む」モデルに近い。通信の中心が親だけに固定されず、調整責務の一部がチーム側に移っています。

ここでひとつ大事な注意があります。Anthropic は Agent Teams を「自律協調するチーム」として紹介していますが、2026年3月12日時点の公開一次ソースでは、低レベルの通信プロトコルや UI 詳細までは広く文書化されていません。したがって本記事では、「親に結果を返すだけのスター型ではない」ことが公式に強い、という粒度で扱います。

6. では、何が根本的に違うのか

ここまでを一文に圧縮すると、違いはこうです。

Subagent は「独立して処理して親に返す」基本形。Codex Multi-Agents は「その独立ワーカーを複数並列で親が裁く」中央集権型。Agent Teams は「チーム側が協調しながら進む」協調型。

実務での選び分けは、タスクの依存関係を見ると早いです。

• 仕事がきれいに分割できるなら Subagent か Codex Multi-Agents
• 依存関係が弱い並列化なら Codex Multi-Agents
• 途中で役割間のすり合わせが何度も発生するなら Agent Teams 的なモデル

比較軸を「何個走るか」ではなく「情報がどこを通るか」に変えると、製品名の違いに引っ張られにくくなります。

7. よくある誤解

並列実行できれば全部マルチエージェントなのか

半分正しく、半分ずれています。

複数動くこと自体は大事ですが、それだけでは十分ではありません。重要なのは、並列実行したあとにどう協調するかです。親がすべて捌くのか、チーム側に協調ロジックがあるのかで、設計上の性質は大きく変わります。

分散協調型のほうが常に上なのか

これも違います。

中央集権型は、人間が Lead として品質ゲートを握りやすい。特にレビューや承認を重くしたい開発組織では、むしろ中央集権型のほうが運用しやすいことが多いです。AI生成PRでレビューが詰まる本当の理由 で扱ったように、協調の自由度が高いほど、逆に意図復元コストが上がることもあります。

8. どのケースでどれを選ぶか

抽象論だけだと迷いやすいので、実務の判断に落とします。

迷ったときは、次の順で考えると外しにくいです。

1. タスクは途中で相互依存を増やすか
2. 人間が常に交通整理したほうが安全か
3. 協調よりも隔離のほうが価値を出すか

この3問で見ると、ただの「高機能かどうか」ではなく、運用設計として選べるようになります。基盤側の視点では AIエージェント開発を支える「共通基盤」 も参考になります。

9. FAQ

Subagent と Multi-Agents の違いは何ですか

Subagent は基本的に「1つの独立ワーカー」です。Multi-Agents は、その独立ワーカーを複数同時に走らせ、親がまとめて管理するモデルです。違いは能力の有無より、並列数と親の管理責務にあります。

Codex Multi-Agents と Agent Teams は同じですか

同じではありません。公開一次ソースの説明をそのまま読むと、Codex Multi-Agents は別スレッドを親が管理する性質が強く、Agent Teams はチームとして自律協調する性質が強いです。つまり、同じ「複数動くエージェント」でも、設計の重心が違います。この記事では、その差を中央集権型と協調型として整理しています。

どれが一番高度ですか

「一番高度」というより、依存関係に合っているかで選ぶべきです。独立タスクなら Subagent や Multi-Agents のほうが扱いやすく、調整の多い仕事なら Agent Teams 的なモデルのほうが自然です。

まとめ

この記事の要点はシンプルです。

• Subagent は親配下の独立ワーカー
• Codex Multi-Agents は親が複数ワーカーを並列管理する中央集権型
• Agent Teams はチーム側の協調が前面に出る協調型

つまり、見るべきは「何ができるか」よりも、誰が誰と話せるかです。

もし自分の運用に当てはめるなら、最初に考えるべき問いはひとつです。

この仕事は、親が全部交通整理したほうがよいか。それとも、メンバー同士の協調を許したほうが速いか。

この問いで整理すると、Subagent / Multi-Agents / Agent Teams の違いはかなり見通しがよくなります。

2026-05 時点の最新仕様（公式値）

Codex Multi-Agents v2

OpenAI Codex CLI は 2026 リリースで MultiAgentV2 が正式提供されました[公式値]（OpenAI Codex CLI 公式、OpenAI Codex Subagents 公式）。主要な拡張は以下:

• Path-based 通信: /root/agent_a のような階層アドレスで sub-agent 間の構造的メッセージング
• Thread caps と wait-time controls: 並列度を CLI flag で制御
• Root/subagent hints + v2-specific depth handling: ネストの暴走を防ぐ深度管理

Codex CLI 系の入門は Codex の subagents 入門 で扱います。

Claude Code Subagents の対応仕様

Claude Code 側は Subagents / Hooks / Skills の 3 拡張レイヤーを 2026 年標準提供[公式値]（Claude Code 公式、Claude Code Subagents 公式）。

Claude/Codex 通信構造レイヤー対比

詳細な使い分け 5 軸は Skills対Subagents使い分け5軸、ツール選定は 2026 年の AI コーディング自動運転最前線 を参照。

選定フローチャート

Q1: 仕事はメンバー同士の協調を必須とするか？
   Yes → Agent Teams（協調型）
   No  → Q2

Q2: ツールチェーンは Codex CLI 系か Claude Code 系か？
   Codex CLI       → Codex Multi-Agents v2（MultiAgentV2）
   Claude Code     → Claude Code Subagents（/agents + Hook）
   両方混在         → MCP 経由でブリッジ（[MCP権限設計](/articles/mcp-permission-design-criteria)）

承認境界の強制は PlanGate v8.6 Hook Enforcement、観測基盤の設計は AIエージェントの可観測性と障害解析 を参照。

FAQ

Q1. Codex Multi-Agents v2 と Claude Code Subagents の本質的違いは？

設計思想（コンテキスト隔離 + 並列）は同じですが、通信構造が異なります[公式値]。Codex は path-based 通信（/root/agent_a）で親が中央集権管理、Claude Code は /agents + Hook の組み合わせで PreToolUse から起動可能。詳細は Codex の subagents 入門 を参照。

Q2. Agent Teams を選ぶべきタイミングは？

メンバー同士の協調が必須のタスクです（経験則）。例えば、フロントエンド + バックエンド + DB 担当が 互いに APIs を確認しながら 進める実装タスク。独立タスクの並列なら Subagent / Multi-Agents の方が単純で扱いやすい。

Q3. Codex と Claude Code を併用する場合の通信は？

MCP（Model Context Protocol）経由でブリッジするのが現実解（経験則）。MCP は両ツールが対応しているため、共有リソース（DB / API）への接続は MCP server で標準化できます。詳細は MCPサーバー設計パターン集 と MCP権限設計の判断軸 を参照。

Q4. 並列度の上限は何で決まりますか？

Codex Multi-Agents v2 は thread caps + wait-time controls で CLI flag 制御[公式値]、Claude Code は /agents の同時起動数 + API rate limit が実質的な上限（経験則・3-4 並列が現実解）。詳細は Skills対Subagents使い分け5軸 を参照。

Q5. 観測はどう設計すべきですか？

階層 span（User Request → Agent → Sub-agent → Tool）で構造化ログを取るのが基本です（AIエージェントの可観測性と障害解析）。Codex の app-server は streamed agent events を提供するため、親子の委譲・返却を可視化できます[公式値]（App Server 公式）。

参考リンク

• OpenAI: Introducing Codex
• OpenAI Help: Use the Codex app for enabling multiple Codex agents in parallel
• OpenAI Codex CLI 公式
• OpenAI Codex Subagents 公式
• OpenAI Codex App Server 公式
• Anthropic Docs: Subagents
• Claude Code Subagents 公式
• Anthropic News: Introducing Claude Code Agent Teams

関連記事

• Codex の subagents 入門
• Skills対Subagents使い分け5軸
• Claude Code subagents の粒度設計と責務分離
• マルチエージェント・デザインパターンの実践
• 2026 年の AI コーディング自動運転最前線
• MCPサーバー設計パターン集
• MCP権限設計の判断軸
• PlanGate v8.6 Hook Enforcement
• AIエージェントの可観測性と障害解析