8月29日、Towards Data Scienceが「From One Agent to a Team: Understanding Codex Subagents」と題した記事を公開した。同じ旅行プランニングタスクを3つの専門エージェントに分担させたところ、3エージェントがそれぞれ異なる都市を推奨するという興味深い結果が得られた。この事例を通じて、OpenAIのコーディングエージェント「Codex」でサブエージェントを意図的に設計・制御し、複数の専門エージェントを並列協調させる実践手法が詳しく解説されている。
なお、CodexはOpenAIが提供するコーディングエージェントであり、ブラウザで利用するChatGPTとは別製品だ。CLIから操作するエージェント環境として設計されており、コードの記述・実行・ファイル操作を自律的にこなす。本記事で扱うサブエージェント機能は、そのCodex上でマルチエージェントワークフローを構築するための仕組みだ。
3エージェントが異なる結論を出した
記事のハイライトから先に紹介する。チューリッヒ発4日間の旅行プランニングという同一タスクを、性格の異なる3つの専門エージェントに並列処理させた結果がこれだ：
- Travel Logistics Agent → コペンハーゲンを推奨
- Budget Analyst → プラハを推奨
- Experience Researcher → リスボンを推奨
3エージェントは同じ条件を与えられながら、それぞれの専門的視点から異なる結論に達した。メインエージェントはこの3つの知見を元の要件（予算1,200スイスフラン、移動の利便性、美術館、地元の食）と照合し、総合バランスでリスボンを最終推奨として選出した。単に3レポートを連結するのでも、最初に返答したエージェントの結論をそのまま採用するのでもなく、トレードオフを比較した上での判断を行っている。
サブエージェントとは何か
Codexに複雑なタスクを依頼すると、内部でタスクを分割し、個別のエージェント（サブエージェント）を生成して並列処理させることがある。各サブエージェントは独立したスレッドで動作し、メインエージェントがそれらの結果を集約して最終回答を生成する。
記事が問いかけるのは「では、これを意図的に設計・制御できるか？」という点だ。答えは「できる」であり、その具体的な方法が今回のケーススタディを通じて示されている。
ケーススタディ：旅行プランニングで3エージェントを並列稼働
候補地はリスボン・プラハ・コペンハーゲンの3都市。この1つのタスクを、以下3つの専門エージェントに分担させる：
- Travel Logistics Agent：交通ルート・移動利便性を評価
- Budget Analyst：旅行費用を比較
- Experience Researcher：旅行者の関心事との適合度を評価
エージェントの定義方法
Codexでは、プロジェクト内の .codex/agents/ ディレクトリにTOMLファイルを置くことでカスタムエージェントを定義できる。
.codex/
├── config.toml
└── agents/
├── travel-logistics.toml
├── budget-analyst.toml
└── experience-researcher.toml
各TOMLファイルには3つのフィールドを記述する：
name：Codexがエージェントを識別する名前description：このエージェントが何者かdeveloper_instructions：エージェントの振る舞いを規定するシステムプロンプト相当の指示。「どの観点で評価するか」「どんな形式で結果を返すか」といった行動規範をここに記述する
たとえば、予算分析エージェントの定義はこうなる：
name = "budget_analyst"
description = "Budget specialist for comparing the likely trip cost across candidate destinations."
developer_instructions = """Evaluate every destination from a trip-budget perspective.
Return concise, source-backed findings to the main agent."""
モデルの種類、推論強度、サンドボックス設定、ツール類はエージェントごとに上書きも可能で、指定しなければメインセッションの設定を継承する。
並列実行数は .codex/config.toml で制御できる：
[agents]
max_concurrent_threads_per_session = 3
プロンプトでの指示方法
エージェントを定義しただけでは動かない。メインエージェントへのプロンプトで、どのエージェントをどう使うかを明示的に指示する必要がある：
Use the `travel_logistics`, `budget_analyst`, and `experience_researcher`
agents in parallel. Each agent should evaluate all three destinations from its
specialty. Wait for all three agents, then recommend one destination and
explain the main tradeoffs with source links.
Webサーチ有効でCodexを起動すれば、3つのサブエージェントが同時に走り始める。CLIからはエージェントスレッドのビューで各エージェントのコンテキスト・ツール使用状況・途中経過をリアルタイムで確認できる。
このパターンをいつ使うか
サブエージェントパターンが有効なのは、独立して処理できる複数種類の作業が含まれており、最後に統合が必要なタスクだ。
サブエージェントの呼び出し方は3通りある：
- プロンプトに直接記述（今回のケーススタディ）：一回限りのタスクに適する
AGENTS.mdに記述：プロジェクト全体でこの戦略をデフォルト化したい場合に使う。Codex CLIがプロジェクトルートのAGENTS.mdを自動的に読み込み、エージェントの振る舞いや利用戦略をプロジェクト規約として定義できるSKILL.mdにパッケージ化：繰り返し発生するワークフローをスキルとして定義し、再利用可能な形にまとめる。AGENTS.mdと同様にCodex CLIが参照するプロジェクト規約ファイルの一種だ
なお、.codex/agents/*.toml はあくまで「誰がサブエージェントか」を定義するファイルだ。「いつ・どう使うか」はプロンプト、AGENTS.md、またはスキル定義が担う。この役割分担は設計上重要な点として記事で強調されている。
今回の事例が示すのは、マルチエージェントの価値が「速度向上」だけにとどまらない点だ。専門性の異なる視点を並列で走らせることで、単一エージェントでは生まれにくい「視点の衝突」が発生し、それをメインエージェントが統合することでより多面的な判断が得られる。コードレビュー・セキュリティ監査・ドキュメント生成といった複数観点が必要な開発タスクへの応用も自然に想起される。
※編集部の考察：3エージェントがそれぞれ異なる都市を推奨したという結果は、エージェントの専門性設計が適切に機能していることを示す一方、メインエージェントによる統合ロジックの品質がアウトプット全体を左右することも示唆している。統合フェーズの指示設計が実用上の鍵になりそうだ。
詳細はFrom One Agent to a Team: Understanding Codex Subagentsを参照していただきたい。
