CodexのMulti Agents機能とは？Claude CodeのAgent Teamsと比較して整理

はじめに

Codexは、端末からローカルで動くOpenAIのコーディングエージェントです。選んだフォルダのコードを読み取り、変更し、実行までできます。オープンソースで、速度と効率のためにRustで作られています（参照*1）。

この記事では、Codex 0.102.0で試験的に導入されたMulti Agentsを、Claude CodeのAgent Teamsと比べながら整理します。複数のエージェントに仕事を分けると何が変わるのか、どこまで自動で進められるのかを、導入時の注意点や社内運用の考え方も含めて解説します。DX推進やAI導入を担当する立場でも、社内説明に使える整理を目指します。

Codex 0.102.0のMulti Agents機能の概要

Multi Agentsの定義

Multi Agentsは、1つの作業を1人のエージェントに任せきりにせず、複数のエージェントに役割を分けて動かす考え方です。たとえば「調べる役」と「直す役」を分けると、調査の途中でコードを触ってしまう事故を減らしやすくなります。

Codex 0.102.0では、設定ファイルで「複数エージェントの役割」をカスタマイズできるようにし、Multi Agents向けの名前や設定の形へ移行していく流れも含めて追加した、とOpenAIのCodexリリースノートが整理しています（参照*2）。

Multi Agentsは「賢い1人」を作る話ではなく、「役割が違う複数人」を作る話です。役割が違えば、同じ指示でも確認する場所や出す答えが変わります。社内で説明するときは「1人に全部任せないための分業」と捉えると伝わりやすいです。

v0.102.0における試験導入の位置づけ

Codex 0.102.0のMulti Agentsは、試験的な機能として提供されています。Kevin Kernは、Codex 0.102で「experimental multi-agent support」が入ったと説明し、TUIでは「/experimental -> multi agents」から有効化できると示しました（参照*3）。

試験的という位置づけは、使い方や設定の置き場が変わる可能性がある、という意味も含みます。OpenAIのCodexリリースノートは、複数エージェントの役割を設定でカスタマイズできるようにしたことに加えて、「新しいmulti-agentの命名や設定の表面」に向けた移行も含むと書いています（参照*2）。

そのため、最初から大きな業務に適用するより、影響が小さい作業で試し、社内ルールや承認フローと相性がよい分担を見つける進め方が現実的です。PoCで止まりやすい組織でも、対象を絞って実績を作ると本番化の説明がしやすくなります。

有効化手順と前提条件

有効化は大きく2通りです。Kevin Kernは、TUIなら「/experimental -> multi agents」で有効化できると示しています（参照*3）。

設定ファイルでの有効化もできます。同じ投稿で、設定の例として「[features] multi_agent = true」を挙げています（参照*3）。

前提条件としては、まずCodexを0.102.0系にしておくことが必要です。また、役割を増やすほど、指示の書き方が結果に影響します。役割ごとに「やること」と「やらないこと」を短く決めておくと、指示の回数が減り、承認の判断もしやすくなります。

Codex Multi Agentsの使い方と役割設計

標準エージェント役割

CodexのMulti Agentsには、最初から3つのエージェント役割が含まれるとKevin Kernが示しています（参照*3）。役割があると、同じ作業でも「どこまでやってよいか」がはっきりします。

3つの役割は次の通りです。

default: 雑多な作業向け。失敗の原因調査と修正案の提案など、調べると直すの両方を扱います。
explorer: コードベース調査向け。たとえば支払いの流れを地図のように整理し、危険がないか確認するが、編集はしないという使い方です。
worker: 実装と不具合修正向け。特定のフォルダを担当させ、機能追加やテスト実行まで進めます。

実務での使い分けは単純です。最初にexplorerへ「編集なしで全体像だけ」を依頼し、次にworkerへ「直す場所とテスト」を依頼すると、関係ない場所への変更が減ります。defaultは、切り分けが難しい障害対応の入口として置くと回しやすいです。

カスタムエージェント設計

標準の3役だけでも便利ですが、業務の型が決まっているチームほど、役割を追加したくなります。OpenAIのCodexリリースノートは、0.102.0で「設定によるカスタマイズ可能な複数エージェント役割」を追加したと説明しています（参照*2）。

カスタム役割を考えるときは、役割名よりも「やってよいこと」と「やってはいけないこと」を先に決めると設計しやすいです。たとえば、調査役は編集禁止、実装役は担当フォルダを限定、確認役はテストと差分確認だけ、のように境界を作ります。

社内導入の観点では、境界がある役割ほど説明が簡単です。たとえば、explorer系には「変更しない」「根拠としてファイル名を書く」を固定し、worker系には「変更点を小さく」「実行したテスト結果を書く」を固定します。固定の型があると、担当者が変わっても品質がぶれにくくなります。

並行実行とスレッド管理

複数エージェントを動かすときに気になるのが、同じ場所を同時に触って壊さないか、という点です。CodexアプリはGitのワークツリーを使い、同じプロジェクト内で複数の独立タスクを同時に実行できるとOpenAIが説明しています（参照*4）。

Gitリポジトリなら、自動化は専用のバックグラウンドワークツリー上で動き、あなたの作業と衝突しにくい設計です。一方で、バージョン管理されていないプロジェクトでは、プロジェクトのフォルダ内で直接動くとも書かれています（参照*4）。

つまり、並行実行を前提にするなら、Git管理がほぼ必須です。運用では、スレッドが増えるほど最後に「どの変更を採用するか」の判断が必要になります。採用判断を軽くするには、workerの担当範囲をフォルダで切り、explorerの結果に基づいて修正の優先順位を決める流れが合います。

Claude CodeのAgent Teamsとの比較

協調方式と役割分担

Claude CodeのAgent Teamsは、複数のエージェントが大きな作業を分割して協調する仕組みです。TechCrunchは、エージェントが順番に作業するのではなく、それぞれが役割を持ち、他のエージェントと直接連携して進めると説明しています（参照*5）。

同記事でAnthropicの製品責任者Scott Whiteは、責任を分割することで並行して作業でき、より速く進むと述べたとされています（参照*5）。

CodexのMulti Agentsと比べると、どちらも「役割を分ける」点は同じです。違いをひとことで言うと、Codexは「役割を設定して、別々に動かす」入口が見えやすい一方、Claude Codeは「チームとして直接連携する」考え方を前面に出しています。社内での説明では、前者は分業の型を先に作りやすく、後者は協調の体験を重視しやすい、と整理できます。

提供形態と文脈長

提供形態にも違いがあります。TechCrunchは、Agent TeamsがAPIユーザーと購読者向けに研究プレビューとして提供されていると説明しています（参照*5）。

文脈長も比較ポイントです。TechCrunchは、Opus 4.6が1百万トークンの文脈を提供すると書いています（参照*5）。一方でAnthropicのモデル更新情報ページは、Claude Opus 4.6が200Kのコンテキストウィンドウ、出力トークン上限が128Kだと整理しています（参照*6）。

同じ製品名でも「どの場面で、どれだけ扱えるか」の表現が揺れることがあります。実務では、使う窓口（API、製品機能、設定）を先に決め、公式の仕様ページで上限を確認すると判断しやすくなります。長い仕様書や大量ログを扱う場合は、上限がそのまま作業手順の設計に影響します。

安全設計とチーム運用の要点

権限管理とサンドボックス

複数エージェントで作業を分けるほど、権限の扱いが運用の中心になります。OpenAIのCodexリリースノートは、0.102.0で権限フローをより統一し、TUIで権限履歴を分かりやすくしたこと、さらにディレクトリがブロックされたときにサンドボックスの読み取り権限を付与するためのスラッシュコマンドを追加したことを挙げています（参照*2）。

同リリースノートは、ネットワーク許可の扱いも構造化し、許可を求める画面で接続先のホストや通信方式がより分かるようにしたと説明しています（参照*2）。

社内運用では、誰がどの許可を出したかが後から追えることが説明責任につながります。役割ごとに許可の範囲を変えると、承認が必要な場面が減り、運用が止まりにくくなります。たとえばexplorerは読み取り中心、workerはテスト実行まで、のように切り分けると設計しやすいです。

リポジトリ指示ファイルとガバナンス

複数エージェントを同じリポジトリで動かすなら、作業のルールを文章で固定すると事故が減ります。OpenAIはCodexの紹介記事で、Git運用の指示として「ファイルを書き換える場合は新しいブランチを作成せず、変更をgitでコミットする」「pre-commitが失敗したら修正して再試行する」「git statusでクリーンな作業ツリーを確認する」などを明記しています（参照*7）。

同記事は、評価対象はコミットされたコードのみで、既存のコミットを変更・修正してはならないとも書いています（参照*7）。

この手のルールは、人間だけでなくエージェントにも効きます。役割が増えるほど、変更の単位と手順が揃っていないと追跡が難しくなります。社内でよくあるPoC止まりを避けるには、技術より先に「差分の確認」「コミット」「テスト結果の記録」を揃える方が進めやすいです。

ユースケース別の選び方

Codex Multi Agentsが向くケース

Codexは、Slack統合、Codex SDK、管理者向けツールを追加し、チームのチャンネルからCodexにタスクを委任したり質問を投げたりできるとOpenAIが説明しています（参照*8）。開発の現場に組み込みやすい入口があると、複数エージェントの分担も日常業務に乗せやすくなります。

同記事では、世界中の開発者による採用が進んでいることや、CiscoやInstacartなどの活用事例にも触れています（参照*8）。社内で導入を進める立場では、こうした企業名があるだけでも稟議の材料になりやすいです。

また、Codexの変更作業はGitのワークツリーで衝突を避ける設計があり、同じプロジェクト内で複数タスクを同時に進められるとOpenAIが説明しています（参照*4）。Gitで管理しているチームほど並行作業のメリットが出ます。

業務に当てはめると、explorerで影響範囲を整理し、workerで修正とテストを進める分担が作りやすいです。たとえば定例の不具合対応なら、explorerに「再現条件と関係ファイル」を集めさせ、workerに「修正とテスト結果」を書かせると、担当者の確認時間を減らせます。

Claude Agent Teamsが向くケース

Claude CodeのAgent Teamsは、複数のエージェントが役割を持ち、互いに直接連携して大きな作業を分割する、とTechCrunchが説明しています（参照*5）。最初から「チームで協調する」体験を中心に置きたい場面で検討しやすいです。

事例としてAnthropicは、成長マーケティングチームが数百の広告を含むCSVを処理し、成績の悪い広告を特定して短い文字数制限内で新しい案を作るエージェント型の流れを作ったと紹介しています。さらに2つの専門的なサブエージェントで、数百の新しい広告を数分で作成したとも書いています（参照*9）。

同記事は、Figmaのプラグインを開発し、フレームを識別して見出しと説明を入れ替えることで最大100件の広告案を自動生成し、コピー作業を大幅に削減したとも説明しています（参照*9）。コード修正だけでなく、表データ処理や制作物の量産のような業務でも、分担が作りやすいことが読み取れます。

DXの文脈では、開発部門だけでなく事業部門の作業も一緒に扱いたいときに、こうした事例が参考になります。たとえば、広告文の作成や資料のたたき台の作成と、必要な小さなスクリプト作成を同じ流れで回したい場合は、チーム型の考え方が合いやすいです。

おわりに

Codex 0.102.0のMulti Agentsは、試験的に有効化して使い始められ、標準役割に加えて設定で役割をカスタマイズできる方向へ進んでいます（参照*3）（参照*2）。役割を分けるほど、指示の境界と権限の扱いが運用の中心になります。

Claude CodeのAgent Teamsは、複数エージェントが役割を持って直接連携し、大きな作業を分割して進める設計だとTechCrunchが説明しています（参照*5）。

選定では、「コード中心でGit運用に乗っているか」「事業部門の表データや制作物も含めて分担を回したいか」をまず切り分けると判断しやすいです。加えて、PoCで終わらせないために、差分確認、テスト結果、権限履歴を残す運用までセットで設計すると、社内説明と定着が進みやすくなります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））