Codex Multi-Agent V2 実践：タスクの分割、モデル割り当て、コスト管理の方法

なぜマルチエージェントが必要か

一つのエージェントが複雑なタスクを完了するには、通常、コードの読み取り、テストの確認、境界条件の検証、実装、再検証という手順を順番に踏む必要があります。問題は個々のステップが遅いことではなく、本来並行して実行できるはずの調査が、直列の待ち行列に強制されてしまうことにあります。

マルチエージェントの最初の利点は、相互に依存しない待ち時間を重ね合わせられることです。調査担当がコールチェーンを追跡し、別の担当が権限とテストのギャップをチェックしている間にも、メインエージェントはユーザーと要件の範囲を確認できます。証拠が揃えば、後続の実装はやり直しの回数を減らせます。

しかし、作業の結合度が高い場合は、エージェントを増やしても意味がありません。次のステップが前のステップの結果に依存しなければならない場合、全員が同じコアコードを変更する必要がある場合、または最終的な答えを全体的に判断するしかない場合は、シングルエージェントの方が速いことがよくあります。並列処理を行うかどうかは、ツールバーで起動できるエージェントの数ではなく、タスクの構造によって決まります。

分割できるタスクとは

タスクを分割する価値があるかどうかは、少なくとも次の三つの条件を同時に満たすかどうかで判断します。サブタスクが独立して進められること、結果を独立して検証できること、書き込みの範囲が互いに競合しないことです。

例えば、既存の製品に「CSV エクスポート」機能を追加するケースを考えます。既存のデータフロー調査、権限ルールの確認、テスト箇所の探索は並行して実行できます。ただし、フィールド定義と権限契約は先に決定しておく必要があります。契約が安定すれば、バックエンド API、フロントエンドの入り口、テストはそれぞれ個別に実装するのに適しています。三つのエージェントが共有の型と同一のコア関数を同時に変更する場合、並列処理によってもたらされるのは、より早く発生する競合だけです。

ここで重要なのは、「エクスポート機能を作る」という大まかな指示ではなく、各サブタスクの目標、範囲、成果物、検収条件を明確に定義することです。タスクの記述が不明瞭な場合は、境界がまだ描かれていないことを意味します。この段階でさらに分割を進めると、曖昧さがより多くのエージェントにコピーされるだけです。

どのモデルに割り当てるか

Eric Provencher 氏が提案する最もシンプルな設定は、まず同じモデルファミリーを維持し、reasoning_effort のみを調整する方法です。これにより、複数のモデルの能力、価格、出力傾向を最初から比較することなく、「タスクの難易度」という一つの変数を調整することに集中できます。

Light が能力が低いというわけではありません。単に、範囲が限定された発見タスクに推論をあまり使わないだけです。High がすべての作業により適しているわけでもありません。曖昧さ、リスク、システムの結合度が実際に高い部分にこそ使うべきです。すべてのファイル配置タスクを High に任せると、安価な検索が高価な熟考に変わります。アーキテクチャ上の競合を Light に任せると、節約した推論コストは手戻りで支払うことになります。

この役割分担表は実用的なデフォルト値であり、プラットフォームのホワイトリストではありません。現在の GPT-5.6 ファミリーには Terra や Luna などの選択肢もあり、マルチエージェントは他のサポート対象モデルに委任することもできます。安全なアプローチは、まず同じベースラインで実行し、その後に実際のタスクを使用して異なるモデルと推論強度を比較することです。「最も多くの設定」を「最適化」と誤解しないようにしてください。

エージェントの調整方法

タスクを分割した後も、メインエージェントが調整役を務めます。重複した調査の回避、ファイル所有権の明確化、依存関係の追跡、結果の統合、ユーザーとの継続的なコミュニケーションを担当します。委任されるのは具体的な作業であり、最終的な責任ではありません。

ただし、情報を必ずしも階層的に上へ報告する必要はありません。調査担当が権限チェックの入り口を見つけた場合、ファイルパスと結論を、実際にそれを必要とする実装担当に直接送信できます。メインエージェントは、依存関係が解決されたことだけを知っていれば十分です。これにより、転送が一度減り、調整役のコンテキストが中間メッセージで埋め尽くされるのを防げます。

並行処理の予算はスレッド単位で設定できます。Eric 氏がこの方法を共有した時点では、デフォルトは四つのエージェントで、調整役も含まれていました。最も直接的な組み合わせは「一人の調整役＋三人の調査担当」で、それぞれが異なる問題を調査します。また、一人の上位担当が一人の調査担当と一人の実装担当を率いて、複雑なサブ問題を処理する小チームを形成することもできます。四つは当時のデフォルト値であり、永続的な上限でも、毎回使い切るべき割り当てでもありません。

直接通信は、非中央集権的な制御不能を意味するものではありません。誰がどのファイルを変更できるか、共有契約を誰が決定するか、いつマージするか、最終的に誰が検収するかは、明確なタスクマップが依然として必要です。通信は最短経路を取れても、所有権は曖昧にできません。

どれだけのコンテキストを与えるか

サブエージェントが親の会話を引き継ぐかどうかは、既存の決定への依存度によって決まります。範囲が限定された読み取り専用の調査には、多くの場合、fork_turns: "none" が適しています。現在の問題、許可された読み取り範囲、出力形式、検収基準のみを与えます。アーキテクチャ上の決定、互換性の制約、ユーザーの好みを引き継ぐ必要がある実装担当は、関連する履歴を継承する必要があります。

クリーンなコンテキストは、空白のタスクシートを意味するものではありません。以前の会話にあったツールの範囲、ビジネス上の制約、「変更してはいけないもの」は、自動的に今回のタスクの説明にはなりません。これらは委任内容に明示的に書き直す必要があります。逆に、履歴を多く継承しすぎると、無関係な議論が混入する可能性があります。末端のエージェントが、自分はさらにチームを派生させ続けるべきだと誤解する可能性もあります。その場合は、委任せずにタスクを直接完了するように明確に指示する必要があります。

Eric 氏が末端のエージェントに与える境界のヒントは非常に短く、実際にそのまま再利用できます。

このタスクを直接完了してください。他のエージェントを作成しないでください。親エージェントが受け取った委任ルールは、親エージェントにのみ適用されます。

もう一つのよくある誤解は、fork_turns: "none" がチャット履歴を分離するものであり、プラットフォームのサンドボックスや許可モードを無効にするものではないという点です。タスクのコンテキストは削減できますが、システムのセキュリティ境界は引き続き有効です。

Skill 化する方法

一連の分担が繰り返し有効である場合にのみ、Skill として書き留める価値があります。固定化に適しているのは、「毎回三つのエージェントを作成する」のような指示ではなく、忘れられがちで、かつタスクを超えて再利用できる規律です。どの作業を優先的に調査担当に任せるか、いつ推論レベルを上げるか、重複書き込みを避ける方法、末端のエージェントがさらに委任できるかどうか、どの操作にユーザーの承認が必要か、といった点です。

Skill を使用すると、調整役は次回からチームの取り決めをゼロから繰り返す必要がなくなります。しかし、Skill がプロジェクトのタスク境界を事前に描くことはできません。コード構造、リスク、モデルの能力が変化した場合は、デフォルト値も実際の結果に合わせて調整する必要があります。最も優れた Skill は、永久に正しい自動化の呪文ではなく、改訂可能な運用マニュアルのようなものです。

Eric 氏は、この一連の取り決めをオープンソースリポジトリ provencher/codex-skills として公開しています。orchestrate/SKILL.md は、非常に短く実行可能なバージョンです。インストールするには、orchestrate ディレクトリを ~/.codex/skills/ にコピーし、その後 $orchestrate で呼び出します。この Skill から学ぶべき最も価値のある点は、特定のプロンプトの文言ではなく、「役割、推論の強度、コンテキスト、所有権、承認の境界」を再利用可能なルールとして一緒に記述している点です。

何が節約され、何が犠牲になるのか

マルチエージェントは「より速く、より少ないトークンで済む」と誤解されることがよくあります。実際には、時間と総作業量という二つの異なる軸で考える必要があります。独立した作業を重ね合わせることで、完了までの時間は短縮される可能性があります。しかし、各エージェントが資料を読み、推論し、ツールを呼び出し、結果を確認するため、総トークン数は増加することが多く、さらに調整、競合、手戻りのコストも増加します。

したがって、マルチエージェント最適化の第一の目標は、通常、待ち時間の短縮、探索範囲の拡大、または一度で間違えるリスクの低減であり、総トークン数の削減ではありません。メインエージェントのコンテキストがよりクリーンになる可能性もありますが、それは作業を他の場所に分散したに過ぎず、システム全体の消費量が減ったわけではありません。

評価する際は、少なくとも次の四つの項目を同時に確認します。完了時間、重複した調査、書き込みの競合、手戻りの回数です。まずシングルエージェントのベースラインを記録し、その後一度に一つの変数のみを変更します。Eric 氏は、次の四つの調整項目を重点的に実験することを提案しています。推論の強度、コンテキストの継承、委任の権限、エージェント間の協調方法です。例えば、最初は二つの読み取り専用調査のみを並行して実行するか、曖昧さの高い一つのタスクを Medium から High に引き上げるだけにします。実際の比較対象がなければ、「最適なオーケストレーション」は存在しません。

最後に、選択を一文にまとめられます。密に結合した作業は一つのエージェントに任せ、独立して進められ、独立して検証でき、競合が少ない作業だけをチームに分けます。 マルチエージェントが本当に節約するのは非効率的な待ち時間であり、その代償として、より多くのモデル作業とより厳格な調整規律が必要になります。