- OpenAI Codexがサブエージェント・ワークフローをサポートし、複雑な作業を複数の専門エージェントへ並列に分配し、結果を1つに統合する機能を提供
- サブエージェントはユーザーが明示的に要求した場合にのみ生成され、各エージェントが独立してモデルとツールを使用するため、トークン消費量は単一エージェントより増加
- カスタムエージェントをTOMLファイルで定義し、モデル、サンドボックスモード、MCPサーバーなどをエージェントごとに個別設定可能
- CSVファイルの各行を1つの作業単位としてワーカーエージェントを一括生成するspawn_agents_on_csvの実験的機能も含む
- コードレビュー、フロントエンドのデバッグなど、実践的なシナリオごとのカスタムエージェント組み合わせパターンを公式ドキュメントで案内
サブエージェントの概要と提供状況
- Codexは、専門化されたエージェントを**並列に生成(spawn)**し、結果を1つの応答として収集するサブエージェント・ワークフローをサポート
- コードベース探索や多段階の機能実装計画のような、高い並列性が必要な複雑な作業で特に有用
- サブエージェント・ワークフローでは、作業に応じて異なるモデル設定や指示を持つカスタムエージェントも定義可能
- 現在のCodexリリースでは、サブエージェント・ワークフローはデフォルトで有効
- サブエージェントの活動は現在CodexアプリとCLIで確認でき、IDE Extensionでの可視化も近日追加予定
- サブエージェントはユーザーが明示的に要求した場合にのみ生成され、各サブエージェントが独自にモデル・ツール処理を行うため、単一エージェント実行よりトークン消費が多い
一般的なワークフロー
- Codexがエージェント間のオーケストレーションを処理。新しいサブエージェントの生成、後続指示のルーティング、結果待機、エージェントスレッドの終了を含む
- 複数エージェントが実行中の場合、Codexはすべてのリクエスト結果が揃うまで待機して統合応答を返す
- 例のプロンプト: 現在のPRについて、セキュリティ問題、コード品質、バグ、レースコンディション、テストの不安定性、保守性それぞれに1つずつエージェントを生成し、全体結果を要約するよう依頼
サブエージェントの管理
- CLIの
/agentコマンドでアクティブなエージェントスレッド間を切り替え、進行中のスレッドを確認可能
- Codexに直接依頼して、実行中のサブエージェントを操作・停止したり、完了済みスレッドを終了させたりできる
承認とサンドボックス制御
- サブエージェントはユーザーの現在のサンドボックスポリシーを継承
- 対話型CLIセッションでは、非アクティブなエージェントスレッドからの承認要求がメインスレッド使用中でも表示されることがあり、承認オーバーレイには発生元スレッドのラベルが表示される
oを押すとそのスレッドを開き、承認・拒否・応答が可能
- 非対話型フローでは新しい承認を表示できないため、承認が必要な作業は失敗し、エラーが上位ワークフローへ伝播する
- 子エージェント生成時には、親ターンのライブランタイムオーバーライドを再適用する。
/approvalsの変更や--yoloのような対話型設定を含む
- 選択されたカスタムエージェントファイルに別のデフォルト値が設定されていても、親の設定が優先される
- 個別のカスタムエージェントごとにサンドボックス設定を個別にオーバーライド可能(例: 特定エージェントを読み取り専用モードに指定)
カスタムエージェント
- Codexには標準で3種類の組み込みエージェントを提供
default: 汎用のフォールバックエージェント
worker: 実装と修正に焦点を当てた実行重視エージェント
explorer: コードベース探索向けの読み取り中心エージェント
- カスタムエージェントを定義するには、
~/.codex/agents/(個人用)または.codex/agents/(プロジェクト単位)に独立したTOMLファイルを追加
- 各ファイルが1つのカスタムエージェントを定義し、Codexはそれを生成セッションの設定レイヤーとして読み込む
- すべてのカスタムエージェントファイルに必須の項目:
name, description, developer_instructions
- 任意項目:
nickname_candidates, model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.configなどは省略時に親セッションから継承
グローバル設定
- サブエージェントのグローバル設定はconfigurationファイルの
[agents]セクションで定義
agents.max_threads: 同時に開けるエージェントスレッド数の上限(デフォルト6)
agents.max_depth: 生成されたエージェントのネスト深度(デフォルト1。直接の子エージェントのみ生成可能で、より深いネストを防止)
agents.job_max_runtime_seconds: spawn_agents_on_csvジョブのワーカーごとのデフォルトタイムアウト(未設定時は呼び出しごとにデフォルト1800秒)
- カスタムエージェント名が
explorerのような組み込みエージェントと同名の場合、カスタムエージェントが優先
カスタムエージェントファイルのスキーマ
name(string、必須): Codexがエージェントを生成・参照する際に使うエージェント名
description(string、必須): Codexがこのエージェントをいつ使うべきかを示す人間向けガイド
developer_instructions(string、必須): エージェントの動作を定義する中核指示
nickname_candidates(string[]、任意): 生成されたエージェントの表示ニックネーム候補
- そのほか、サポートされる
config.tomlキーも含められる: model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.configなど
- Codexは
nameフィールドでエージェントを識別する。ファイル名とエージェント名を一致させるのが最も単純な慣例だが、真正な情報源はnameフィールド
表示ニックネーム
nickname_candidatesは、同じカスタムエージェントの複数インスタンスを実行する際に、UIで識別しやすいラベルを表示するためのもの
- ニックネームは表示専用であり、Codexは引き続き
nameでエージェントを識別・生成する
- ニックネーム候補は空でない一意な名前の一覧である必要があり、ASCII文字・数字・空白・ハイフン・アンダースコアを使用可能
- 例:
reviewerエージェントに["Atlas", "Delta", "Echo"]というニックネームを設定すると、アプリとCLIではニックネームが表示されるが、基底エージェントタイプはreviewerのまま
例1: PRレビューパターン
- レビューを3つの特化型カスタムエージェントに分割するパターン
pr_explorer: コードベースをマッピングし、証拠を収集する読み取り専用エージェント(モデル: gpt-5.3-codex-spark, reasoning effort: medium)
reviewer: 正確性、セキュリティ、テストリスクを見つけるPRレビュアー(モデル: gpt-5.4, reasoning effort: high)
docs_researcher: 専用MCPサーバー経由でフレームワークやAPIドキュメントを確認するドキュメント専門家(モデル: gpt-5.3-codex-spark, 読み取り専用)
- プロジェクト設定:
max_threads = 6, max_depth = 1
pr_explorerの指示: 探索モードを維持し、実際の実行経路を追跡し、ファイルとシンボルを引用し、親エージェントが要求しない限り修正提案は控える
reviewerの指示: オーナー視点でレビューし、正確性・セキュリティ・動作回帰・不足したテストカバレッジを優先し、可能なら再現手順を含める。スタイルだけのコメントは、実際のバグを隠すのでない限り避ける
docs_researcherの指示: docs MCPサーバーを使ってAPI、オプション、バージョンごとの挙動を確認し、リンクや正確な参照付きで簡潔に応答し、コード変更は行わない
- 使用例のプロンプト: "このブランチをmainと比較してレビュー。pr_explorerが影響を受けるコードパスをマップし、reviewerが実質的なリスクを見つけ、docs_researcherがパッチが依存するフレームワークAPIを検証"
CSVバッチ処理: spawn_agents_on_csv(実験的)
- 実験的機能であり、今後変更される可能性がある
- 類似作業が多い場合、CSVの1行を1つの作業単位としてワーカーサブエージェントを一括生成
- CodexがCSVを読み込み、行ごとにワーカーエージェントを生成し、バッチ全体の完了を待って結果をCSVとして書き出す
- 適したユースケース:
- 行ごとに1つのファイル、パッケージ、サービスをレビュー
- インシデント、PR、移行対象の一覧を点検
- 類似する多数の入力に対して構造化された要約を生成
- ツール入力パラメータ:
csv_path(ソースCSV), instruction(ワーカープロンプトテンプレート。{column_name}プレースホルダーを使用), id_column(安定した項目ID), output_schema(固定JSON形式), output_csv_path, max_concurrency, max_runtime_seconds
- 各ワーカーは
report_agent_job_resultを正確に1回呼び出す必要があり、結果を報告せずに終了した場合、その行はエラーとして記録される
codex execで実行すると、バッチ進行中はstderrに1行の進捗更新が表示される
- 書き出されたCSVには元の行データに加え、
job_id, item_id, status, last_error, result_jsonなどのメタデータが含まれる
- 関連ランタイム設定:
agents.max_threads(同時スレッド上限), agents.job_max_runtime_seconds(ワーカーごとのタイムアウト。呼び出し時のmax_runtime_secondsが優先), sqlite_home(エージェントジョブと書き出し結果に使われるSQLite状態保存パス)
例2: フロントエンド統合デバッグパターン
- UI回帰、不安定なブラウザフロー、アプリケーションコードと実行中プロダクトをまたぐ統合バグに有効なパターン
- 3つのカスタムエージェントの組み合わせ:
code_mapper: 関連するフロントエンド・バックエンドのコードパスを見つける読み取り専用探索エージェント(モデル: gpt-5.3-codex-spark, reasoning effort: medium)
browser_debugger: ブラウザツールを使って問題を再現し、証拠を取得するUIデバッガー(モデル: gpt-5.4, reasoning effort: high, sandbox: workspace-write)
- スクリーンショット、コンソール出力、ネットワーク証拠のためにブラウザツールを活用し、アプリケーションコードは編集しない
- Chrome DevTools MCPサーバーに接続(
http://localhost:3000/mcp, startup_timeout_sec: 20)
ui_fixer: 問題が特定された後、小さく的を絞った修正を担う実装重視エージェント(モデル: gpt-5.3-codex-spark, reasoning effort: medium)
- 最小限で正当化可能な変更のみを行い、無関係なファイルには触れず、変更した挙動だけを検証
- 使用例のプロンプト: "設定モーダルが保存に失敗する理由を調査。browser_debuggerが再現し、code_mapperが該当コードパスを追跡し、ui_fixerが失敗モードを把握した後で最小限の修正を実装"
4件のコメント
agent が GPT-5.1-Codex-Mini モデルだけを使う状態で、
Codex App の Custom instructions に
以下のプロンプトを追加すると、GPT-5.3-Codex-Spark で agent が動作しますね。
"- when it spawns agents, use models "GPT-5.3-Codex-Spark" or higher."
あるいは agent を作成するときにモデルを指定するのもなかなか楽しく、
Codex App で下位フォルダ構造で表示してくれるのも良いです。
カカオトークで大幅割引キャンペーンをやっている時に乗っかって、とても便利に使っています(笑)
残念ですね、またイベントはやらないんでしょうか(泣)
Codexにも早くリモートコントロールを作ってください!