7月5日、OpenAIが「Subagents – Codex」と題した記事を公開した。OpenAI Codexに複数のサブエージェントを並列起動するワークフローがデフォルトONで実装され、PRレビューやUI修正といった複合タスクをエージェントに分割・並列処理させることが可能になった。

まず体験すべきプロンプト：PRを6エージェントで並列レビュー

この機能の旨味を即座に把握できるのが、ドキュメントに掲載されている以下のプロンプト例だ。PRの差分に対し、セキュリティ・コード品質・バグ・競合状態・テストの不安定さ・保守性の6観点を1エージェントずつ並列で担当させ、結果をまとめさせる。

I would like to review the following points on the current PR (this branch vs main). 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
4. Race
5. Test flakiness
6. Maintainability of the code

この1プロンプトでCodexがオーケストレーションを自動処理し、6つのサブエージェントを起動・待機・結果統合まで担う。ユーザーが個別のエージェントを管理する必要はない。

CLIでは /agent コマンドで実行中のエージェントスレッド間を切り替えながら状態確認が可能。実行中のサブエージェントへの操作指示やスレッドのクローズもCodexに直接話しかけて行える。活動状況はCodexアプリおよびCLIで確認でき、IDEエクステンションでの表示は近日対応予定とされている。

なぜ今、オーケストレーターパターンが注目されるのか

LLMエージェントの実用化が進む中、「1つのエージェントが何でもこなす」設計から「役割を分けた複数エージェントをオーケストレーターが束ねる」設計へのシフトが加速している。タスクを分割することで、各エージェントのコンテキストを絞り込んで精度を上げつつ、全体の処理を並列化してスループットを向上させられるのが主な利点だ。

OpenAIはCodex以外にもAgents SDKでオーケストレーター・ハンドオフパターンをサポートしており、今回のCodexサブエージェント機能はその思想をコーディング特化の開発環境に組み込んだ形と捉えられる。また、エージェントが外部ツールやサービスと接続する手段としてMCP（Model Context Protocol）との連携も本機能でサポートされており、ドキュメント参照やブラウザ操作をエージェントに担わせる構成が可能だ。

現在のCodexリリースでは、このサブエージェント機能はデフォルトで有効になっている。ただし、サブエージェントは明示的に指示した場合にのみ起動される。各エージェントがモデルとツールを独立して動かすため、シングルエージェントの実行よりトークン消費量が増える点は考慮が必要だ。

並列サブエージェントの仕組み

Codexはオーケストレーションを自動で処理し、サブエージェントの起動、フォローアップ指示のルーティング、結果の待機、スレッドのクローズまでを担う。組み込みエージェントとして、汎用の default、実装・修正向けの worker、コードベース探索向けの explorer の3種類が用意されており、これらを組み合わせるか、独自エージェントを定義して利用する。

カスタムエージェントの定義

独自エージェントは TOMLファイル で定義する。個人用は ~/.codex/agents/、プロジェクト単位では .codex/agents/ 以下に配置する。各ファイルで1エージェントを定義し、必須フィールドは name・description・developer_instructions の3つ。model、model_reasoning_effort、sandbox_mode、mcp_servers などは省略するとセッション設定を継承する。

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
"""
nickname_candidates = ["Atlas", "Delta", "Echo"]

nickname_candidates は表示名のプール。同じエージェントを複数起動した際にUIで区別しやすくなる。名前の解決には name フィールドが使われ、ニックネームはあくまで表示のみに影響する。

グローバル設定と主なパラメータ

~/.codex/config.toml または .codex/config.toml の [agents] セクションで以下を設定できる。

max_depth はデフォルトの1（直接の子エージェントのみ許可）を推奨する。値を上げると、広いタスク委譲の指示が繰り返しのファンアウトを引き起こし、トークン消費・レイテンシ・リソース消費が増加する。

CSV一括処理：spawn_agents_on_csv（実験的機能）

繰り返し性の高いタスクには spawn_agents_on_csv が使える。CSVの1行ごとにサブエージェントを1つ起動し、バッチ処理した結果をCSVに書き出す。ファイルやサービスの一括レビュー、インシデント・PRリストのチェックなどに対応する。

Create /tmp/components.csv with columns path,owner and one row per frontend component.
Then call spawn_agents_on_csv with:
- csv_path: /tmp/components.csv
- id_column: path
- instruction: "Review {path} owned by {owner}. Return JSON with keys path, risk, summary, and follow_up via report_agent_job_result."
- output_csv_path: /tmp/components-review.csv
- output_schema: an object with required string fields path, risk, summary, and follow_up

各ワーカーは report_agent_job_result を1度だけ呼び出す必要がある。未報告のまま終了した行はエラー扱いでCSVに記録される。codex exec で実行すると進捗が stderr にシングルライン表示される。

なお、この機能は実験的と明記されており、今後変更される可能性がある。

実践パターン例

ドキュメントでは2つの構成例が紹介されている。

PRレビュー構成：pr_explorer（read-onlyでコードパス探索）、reviewer（correctness・security重視）、docs_researcher（MCPサーバー経由でAPIドキュメント確認）の3エージェントを組み合わせる。

UIデバッグ構成：code_mapper（read-onlyで関連コード特定）、browser_debugger（Chrome DevTools MCPサーバー連携で再現・証拠収集）、ui_fixer（最小限の修正実装）という役割分担で構成する。

各エージェントに明確な単一の責務を持たせ、隣接する作業に流れ込まないよう developer_instructions で制約するのがポイントとされている。役割を絞り込むことで、コンテキスト汚染によるミスを防ぎつつ、オーケストレーター側の統合処理をシンプルに保てる。

詳細はSubagents – Codexを参照していただきたい。