Codexオーケストレーション｜複数エージェントの分け方

Codexオーケストレーションとは

Codexオーケストレーションとは、AIに一度にすべてを任せることではなく、開発の目的をいくつかの小さな担当へ分解し、それぞれの結果を主担当が一つの成果へまとめる考え方です。たとえば、未知のリポジトリを調べる担当、変更案を考える担当、テストの抜けを探す担当を分けます。各担当には「何を見るか」「触ってよい範囲」「返す形式」を明記し、最終的な採用判断は主担当または人が持ちます。

この方式の価値は、同じ時間に別の角度から情報を集められる点だけではありません。長いログや検索結果を主担当の会話へそのまま流し込まず、担当ごとに要点をまとめて返せば、目的・制約・決定事項が埋もれにくくなります。公式のCodexサブエージェント文書も、調査、テスト、トリアージ、要約のような読み取り中心の仕事から並列化を始める考え方を示しています。

主担当と分担先の役割を分ける

主担当は、依頼の背景、優先順位、変更してはいけない範囲、完了条件を保持します。分担先は一つの問いに集中し、確認できた事実、推測、未確認の点を分けて報告します。この境界が曖昧だと、各担当が同じファイルを読み直したり、別の前提で修正を始めたりして、速く進めたはずの作業が後でやり直しになります。オーケストレーションは担当数を増やす技法ではなく、情報の受け渡しを明確にする設計です。

並列に向く仕事と向かない仕事

並列に向くのは、同じ入力から独立して答えを出せる仕事です。エラーの発生条件を調べること、既存テストを読むこと、変更候補の影響範囲を列挙することは、互いの結果を待たずに始められます。一方、同じ実装ファイルの書き換え、直前の設計判断に依存する修正、データ移行のように順序が重要な仕事は、担当を増やしても調整の負担が増えます。判断の依存関係を先に描くことが、並列化の成否を左右します。

なぜ今Codexの分担設計が必要か

Codexの利用範囲が広がるほど、一つの会話へすべての調査と変更を集める方法には限界が出ます。公式のサブエージェント文書は、複数の担当を並列に動かして結果を集める機能を、複雑で分割しやすい仕事に向くものとして説明しています。またCodex cloudの公式ページは、独立した環境で作業を並行して進め、結果を確認してから次の変更へ進む使い方を紹介しています。機能を使えるかどうかより、どの仕事を分け、どこで人が確認するかを決めることが重要です。

2026年8月4日に見るべき時事フックは、直近の版更新が「単にモデルが賢くなった」という話ではなく、セッション、接続、作業の入口、確認の仕方を広げていることです。複数の仕事を扱う入口が増えれば、同時に動かす仕事を選ぶための設計が必要になります。ここでは、更新の事実と、日々の作業に取り入れるときの判断を分けて整理します。

0.146.0で作業の入口が増えた

Codex 0.146.0は2026年7月29日に公開された安定版です。公式リリースには、/new や /clear による新しいセッション名、重要なスレッドの固定、サイド会話の切り替え、スレッドのフォーク、追加のプラグイン関連機能、リモートのCode Modeホストへの接続などが記載されています。これらはすべてを同時に使うべきだという意味ではありませんが、調査用の会話、実装用の会話、レビュー用の会話を分けて管理しやすくする材料になります。詳細はCodex 0.146.0の公式リリースで確認できます。

0.147.0-alpha.4は試験版として扱う

0.147.0-alpha.4は2026年7月31日に公開されたプレリリースです。公式ページでは安定版とは別の試験版として表示されているため、分担設計を試すときも、安定版で確認した結果と試験版で確認した結果を同じものとして扱わないようにします。新しい版を入れた直後は、担当の起動可否だけでなく、結果の表示、利用量、作業の再開、変更の確認まで小さな依頼で確かめます。版番号と確認日を記録するなら、0.147.0-alpha.4の公式リリースが基準になります。

GPT-5.6の公式ガイドが示す方向

OpenAIのGPT-5.6モデルガイドは、複数エージェントを並列に調整し、結果を統合する機能をベータ版として説明しています。複雑な仕事を独立した流れへ分けると、待ち時間を縮めたり、別の視点を同時に得たりできる一方、分けられない仕事には向きません。Codexの機能とAPIの機能は同一ではありませんが、どちらにも「独立性を確認してから分ける」「結果を統合する」という共通の考え方があります。製品名や版番号だけを追うのではなく、依存関係を見て使い分けるのが現実的です。

分担を設計する四つの役割

実務では、担当に難しい名前を付けるより、受け取る成果物を決めたほうが安定します。調査役ならファイル名と根拠、実装役なら変更対象と差分の意図、検証役なら再現条件と結果、統合役なら採用した判断を返すようにします。役割を固定しすぎる必要はありませんが、担当の境界と返却形式をそろえると、Codex、GitHub Copilot、Cursorなど別の入口でも同じ考え方を適用できます。

Step 1: 調査役を置く

最初の担当には、コードを変更せずに現状を説明させます。見る場所を「ルーティング」「データの読み書き」「関連テスト」のように狭く指定し、見つかったファイル、関係する関数、再現に必要な入力、まだ分からない点を返してもらいます。調査役の目的は正解を断定することではなく、主担当が次の問いを正しく選べる材料を作ることです。返却内容にファイルパスや行の目印を含めると、あとで確認しやすくなります。

Step 2: 実装役を一つに絞る

変更を作る担当は、同じ範囲に対して一つに絞るのが安全です。調査の結果から対象ファイル、変更しないファイル、受け入れ条件を渡し、不要な整理や名前変更をしないように指定します。実装役は変更理由、想定した副作用、追加または更新したテストを記録します。複数の案を比べたい場合は、先に読み取り担当へ案を出させ、採用する案を決めてから一つの変更へ進めます。

Step 3: 検証役を独立させる

検証役には、実装役の説明をそのまま信じず、要求と差分を照合させます。通常のケースだけでなく、空入力、権限不足、通信失敗、既存データとの互換性など、壊れやすい境界を確認します。検証役は「問題なし」と短く返すのではなく、実行した確認、通った確認、実行できなかった確認、残るリスクを分けて報告します。実装した担当とは別の視点にすることで、見落としを見つけやすくなります。

Step 4: 統合役が判断する

統合役は、調査、実装、検証の結果を一つの判断へまとめます。採用した変更、保留した提案、追加で確認すること、公開前に人が読む箇所を短く整理します。結果が食い違ったときは、担当数を増やす前に、根拠となるファイルや再現条件を照合します。統合役が変更まで同時に担当すると境界がぼやけるため、最終判断と差分確認に集中させるのがコツです。

依頼文を作る手順

オーケストレーションの品質は、担当を起動する操作より最初の依頼文で決まります。「詳しく調べて直して」のように目的だけを渡すと、すべての担当が同じ場所を見たり、変更まで進めたりします。次の順番で、入力、分担、返却形式、確認者、完了条件を明記してください。

1. 目的と対象範囲を書く。 何を解決するのか、利用者に見える結果は何か、対象のフォルダーや機能はどこかを一文で示します。触れてよい範囲と、今回は変更しない範囲も書き、担当が勝手に課題を広げないようにします。
2. 独立した問いへ分ける。 「原因調査」「関連テストの確認」「既存仕様の確認」のように、互いの返答を待たずに始められる問いを選びます。前の結果がないと答えられない問いは、並列ではなく次の段階へ回します。
3. 返却形式をそろえる。 各担当に、結論、根拠となるファイル、確度、未確認事項、次の提案を返すよう指定します。文章の長さや表の有無より、主担当が結果を比べられることを優先します。
4. 待つ条件を決める。 全担当の結果を受けてから実装へ進むのか、先に届いた調査だけで次へ進むのかを明記します。重要な変更では全結果を待ち、軽い情報収集では途中の要約を受け取るなど、失敗時の扱いも書いておきます。
5. 完了条件を人の言葉で書く。 関係するテストが通る、差分が対象範囲に収まる、未確認の点が一覧になっている、といった判定基準を置きます。「よい感じに終える」ではなく、誰が読んでも同じ判定になる条件にします。

読み取り中心で分ける実例

最初の実験には、変更を伴わない作業を選ぶと効果を測りやすくなります。サブエージェントへ同じ大きな依頼を配るのではなく、結果の重なりが少ない問いを選び、返却形式をそろえます。ここでは、現場で使いやすい三つの例を紹介します。いずれも最終的な変更は主担当が差分を確認してから行います。

例1: 不具合調査とテスト確認

「画面を開くと保存に失敗する」という問題なら、原因候補を追う担当、保存処理の既存テストを読む担当、最近の変更履歴を読む担当へ分けられます。原因担当は再現経路と疑わしい関数を返し、テスト担当は足りないケースを返し、履歴担当は問題が入り込んだ時期と変更理由を返します。三つの報告を比べれば、いきなり修正を始めるより狭い変更範囲を決めやすくなります。

例2: 大きなリポジトリの整理

初めて触るリポジトリでは、全体の構成、認証に関係する入口、データ処理の流れ、テストの置き場所を別々に調べさせます。各担当はすべてのファイルを説明するのではなく、主担当の問いに必要な部分だけを要約します。公式文書が示す「大きな資料を小さな問題に分け、要点を主スレッドへ戻す」考え方にも近く、会話へ生のログを大量に持ち込まずに済みます。調査後は一枚の構成メモへ統合し、次の変更を選びます。

例3: UI・API・テストを分ける

画面変更を伴う機能では、UIの表示条件、APIの入力と返却値、テストの期待値を別の担当が確認できます。ただし、仕様が一つの担当の判断に依存するなら、最初から同時に書き換えさせません。UI担当とAPI担当は変更案を返すだけにし、統合役がデータの契約を決めた後で、実装を一つの担当へ渡します。分ける対象はファイルの数ではなく、判断の独立性です。

失敗しやすい分け方

担当数を増やせば必ず速くなるわけではありません。Codexの公式文書も、読み取り中心の作業から始め、複数の担当が同時にコードを編集する作業には慎重であるよう説明しています。失敗の多くは、分ける前の依存関係を見ていないこと、結果の形式を決めていないこと、利用量と確認時間を見積もっていないことから起こります。

同じファイルを同時に書かせる

同じ設定ファイル、同じテスト、同じデータ変換処理を複数の担当が編集すると、変更の順番が分からなくなります。各担当が自分の変更だけを正しいと思っていても、最後に統合すると意図の違う行が混ざります。まず読み取り担当に案を出させ、実装範囲を決め、変更は一つの担当へ集約します。どうしても分ける場合は、担当ごとに所有するファイルと受け渡す形式を明確にします。

役割名だけを与えて成果物を指定しない

「調査役」「レビュー役」と名前を付けるだけでは、どこまで調べれば終わりかが伝わりません。調査役には対象ファイルと質問、レビュー役には見る観点と問題の重要度、検証役には実行する確認と返す記録を与えます。成果物が具体的なら、主担当は報告を比べられます。逆に、役割名だけで判断を任せると、担当ごとに文章の粒度が変わり、統合の時間が増えます。

全部を並列にして利用枠を忘れる

並列の担当は、それぞれがモデル処理と道具の利用を行います。公式文書も、単独の担当より利用するトークンが増えると説明しています。短い検索を十個に分けるより、問いを三つに絞ったほうが、結果を読む時間と利用量の両方を抑えられることがあります。担当数、モデル、推論の深さを固定せず、重要な調査に厚く、単純な確認に軽く配分してください。

設定とモデルの選び方

Codexの設定は、動かせる担当の数、担当が使うモデル、推論の深さを分けて考えます。公式文書には、複数エージェントの有効化、同時に開ける担当スレッド数、標準モデル、標準の推論努力を設定する項目が示されています。環境や版によって利用できる項目は変わる可能性があるため、設定を変更する前に公式のサブエージェント設定を確認し、小さな依頼で挙動を確かめます。

最初に確認する設定

同時に動かす上限は、最初から大きくしないことが大切です。たとえば次のように三つまでに抑え、調査・テスト・要約のような読み取り中心の仕事で試します。実際に使える名前や既定値は公式リファレンスに合わせ、設定を写しただけで動くと決めつけないでください。

[agents]
enabled = true
max_concurrent_threads_per_session = 3
default_subagent_model = "gpt-5.6-terra"
default_subagent_reasoning_effort = "medium"

上限は「同時に作業を依頼できる最大数」であり、品質を保証する数ではありません。主担当の会話、端末の負荷、利用枠、レビューにかかる時間を合わせて決めます。試すときは変更前の設定を控え、結果が悪化した理由を版番号と依頼内容から追えるようにします。

モデルの役割を分ける

公式文書は、難しい計画や検証には高い推論設定、読み取り中心の大規模スキャンには速度と効率を重視したモデル、明確で繰り返しの多い確認には軽いモデルを使う考え方を紹介しています。調査役だけを軽くし、統合役と最終レビュー役には深い推論を残す、といった配分が現実的です。すべての担当に同じモデルを使う場合も、担当数を増やしたときの利用量と結果の差を確認します。

結果の確認方法を先に決める

設定を変えたら、担当が起動したかだけで合格にしません。担当ごとのスレッドを開けるか、依頼した問いに答えているか、主担当へ要約が返るか、途中で止めたときに状態が説明されるかを確認します。変更を含む作業では、主担当が差分、テスト結果、未確認事項を読んでから採用します。表示された成功メッセージより、再現できる確認記録を優先してください。

利用量と品質のバランス

オーケストレーションを導入すると、時間は短くなっても利用量が同じ割合で減るとは限りません。各サブエージェントが自分の文脈を読み、道具を使い、結果をまとめるためです。公式文書は、分担した作業では単独作業より多くのトークンを消費すると説明しています。したがって、評価するときは経過時間だけでなく、完了までの利用量、主担当が結果を読む時間、やり直しの回数、見つかった問題の数を合わせて見ます。

速さだけで判断しない

三つの担当を動かして五分早く終わっても、報告を比較するのに十五分かかるなら得ではありません。逆に、同じ時間で原因調査とテストの抜けを発見でき、修正後のやり直しが減るなら、利用量が増えても意味があります。最初の一週間は、単独で進めた例と分担した例を同じ種類の仕事で比べ、速度、品質、確認時間の三つを記録します。

上限を小さく始める

担当数は、依存関係が少ない仕事の数に合わせます。二つの問いしかないのに八つの担当を起動すると、同じ資料を読む重複と結果の整理が増えます。最初は二から三担当にし、結果が似通うなら問いをまとめ、結果が不足するなら担当の指示を具体化します。上限を増やす前に、各担当の返却内容が主担当の判断に役立ったかを確認することが先です。

利用量の記録を残す

依頼日、版番号、モデル、担当数、仕事の種類、かかった時間、返却内容、最終的な変更数を一枚に記録します。同じ仕事を別の設定で比べれば、速度と品質のどちらを得たのかが分かります。新しい版を試すときも、設定と依頼を変えすぎないことが重要です。一度に多くを変えると、良くなった理由も悪くなった理由も特定できません。

GitHub Copilot・Cursor・Aiderとの使い分け

Codexオーケストレーションを他のAIコーディングエージェントと比べるときは、モデル名だけでなく、担当を分ける場所、結果を集める場所、変更を確認する場所を比べます。同じようにコードを読めても、画面の横で質問する道具と、複数の作業を管理する道具では、適した分担の粒度が違います。製品を一つに決めるより、調査、実装、レビューのどこをどの入口に任せるかを先に決めます。

GitHub Copilotで使う場合

GitHub Copilotは、エディタの中でコード候補を確認したり、リポジトリに関する質問をしたりする入口として扱いやすい製品です。調査結果をすぐに表示中のコードへ反映したい場合に向きます。複数の独立した調査を管理するときは、担当ごとの問いと返却形式を明記し、最終変更の前に差分を人が読む流れを作ります。Codexと組み合わせる場合は、同じファイルを別々の入口から同時に変更しないことが重要です。

Cursorで使う場合

Cursorは、複数ファイルをまたぐ編集と、エディタ内の文脈を保った対話を進めやすい入口です。UIの表示、データ処理、テストなど、影響範囲を分けて設計したい仕事に適します。ただし、同じ作業ツリーで複数の変更を同時に進めると、どの提案がどの判断から生まれたか分かりにくくなります。まず読み取りと案出しを分け、採用した案を一つの変更へまとめます。

Aiderで使う場合

Aiderのようにターミナル中心でリポジトリを扱う道具と比べると、Codexの分担機能は担当スレッドと結果の統合を意識しやすい点が特徴です。一方、軽い一ファイル修正や、手元で対話しながら細かく直す仕事なら、単独の担当のほうが速いこともあります。比較では、同じ修正を競わせるのではなく、調査にかかった時間、差分の読みやすさ、テストの再現性をそろえて見ます。

Windowsで最初の一回を試す手順

Windowsでは、端末、エディタ、アプリで表示される版番号や設定の場所が違うことがあります。最初の試行は、変更を伴わないリポジトリ調査にし、実際にどの入口で担当が動き、どの形式で結果を返すかを確かめます。次の順番なら、設定の間違いと依頼の分け方を切り分けやすくなります。

1. 版番号を確認する。 利用しているCodexの画面またはCLIで版番号を記録し、安定版か試験版かを確認します。ほかの入口で試す場合も、入口ごとの番号を別々に残します。
2. 設定を小さくする。 同時に動かす数を二から三にし、読み取り中心の担当だけを使います。設定名は公式のサブエージェント文書と照合してから保存します。
3. 変更しない依頼を出す。 「このリポジトリの認証入口、関連テスト、最近の変更理由をそれぞれ調べ、ファイル名と根拠を返してください。ファイルは変更しないでください」と依頼します。問いが独立していることを確認します。
4. 結果を比べる。 担当ごとに結論、根拠、未確認事項を並べ、同じファイルを指している箇所と、食い違う箇所を確認します。報告が長すぎる場合は、次の依頼で要約の形式を狭めます。
5. 一つの変更へ戻す。 調査結果から対象範囲と完了条件を決め、実装は一つの担当へ渡します。変更後は差分とテストを人が読み、担当の報告だけで完了にしないようにします。

Windowsで入力がうまくいかない場合は、まず複数担当の仕組みを疑うのではなく、単独の短い依頼で同じ入口を確認します。版番号、設定の読み込み先、作業フォルダー、表示されたエラーを別々に記録すると、端末固有の問題と分担設計の問題を分けて考えられます。

そのまま使える最小テンプレート

次の依頼文は、既存コードを変更せずに分担の効果を測るための最小形です。実際のプロジェクトでは、対象の機能名、見てほしいフォルダー、返してほしい形式、触れてはいけない範囲を追加します。最初から実装まで求めず、調査結果がそろった時点で主担当が次の依頼を決めることで、誤った前提のまま変更が広がるのを防げます。

このリポジトリの「〇〇機能」を変更せずに調査してください。

担当1: 実装の入口とデータの流れを調べる
担当2: 関係するテストと不足している確認を調べる
担当3: 最近の変更と既存仕様の根拠を調べる

各担当は、結論、根拠となるファイル、確度、未確認事項を短く返してください。
同じ内容を重複して調べず、全員の結果がそろったら主担当が統合します。
この依頼ではファイルを変更せず、最後に次の一手だけを提案してください。

このテンプレートのポイントは、担当名ではなく問いを分けていることです。三つの結果が同じなら、分担する価値が低いと判断できます。逆に、異なる根拠がそろい、主担当が対象範囲を狭められるなら、次の実装依頼へ進む意味があります。依頼を保存しておけば、別のリポジトリや別のAIコーディングエージェントでも、同じ条件で効果を比べられます。

まとめ

Codexオーケストレーションは、担当を増やすことそのものではなく、独立した問いを分け、結果を同じ形式で受け取り、最後の判断を一つに戻す設計です。最初は調査、テスト確認、要約のような読み取り中心の仕事から始め、同じファイルを複数担当に同時編集させないことが安全な出発点になります。

2026年8月4日時点では、7月29日の0.146.0、7月31日の0.147.0-alpha.4、GPT-5.6の公式ガイドが、Codexを複数の仕事へ広げて考える材料になっています。ただし、版更新は分担の成功を保証しません。担当数、モデル、推論の深さ、利用量、確認時間を小さく記録し、単独作業と比べて本当に価値があったかを判断してください。

最初の一歩は、三つの担当を起動することではありません。「何を分けると独立するか」「何を返してもらえば判断できるか」「どこで人が差分を読むか」を書くことです。この三つが決まれば、Codex CLI、Codex cloud、GitHub Copilot、Cursorのどの入口でも、速さに流されず品質を保った作業設計へ近づけます。