OpenAIでCodexの開発者体験を担当するEric Provencher氏が、並列サブエージェントを増やす運用に警鐘を鳴らした。2体を超えて同時に動かすと、品質を高めないままトークンを消費する可能性が高いという。だが同じ週、Nous Researchは1,393体を使って100万行超のPythonコードを改修した事例を公表し、高額でも人手では後回しになっていた仕事を19時間で進めたと評価した。両者の主張は、エージェントの数より先に、経過時間と総トークン、成果の質を別々に測る必要があることを示している。

AD

「2体」より重要な調整税の中身

Provencher氏は2026年9月、2体を超える並列サブエージェントについて「ほぼ確実に、品質向上なしでトークンを燃やしている」とXへ投稿した。各担当が互いの仕事を十分に信頼できず、他の担当が済ませた確認を繰り返すためだという。別の投稿では、多数の並列レーンを逸脱や過剰検証なしで維持する難しさを、調整税（coordination tax）と表現した。

トークンが増える場所は、子担当の回答だけではない。各担当は共通の目的やリポジトリの事情を読み直し、必要なファイルやツールを探す。親担当は報告を受けて矛盾を解き、変更を統合する。担当同士の境界が曖昧なら、同じ探索と同じ検査が重なる。並列検索で回答までの時間を短縮できても、処理した入力の総量は増え得る。Provencher氏も、速度へ割増料金を払うだけの予算と理由がある場合は並列化が合理的だと認めている。

同氏が紹介した運用は、Astraに仕事を計画させ、分けた仕事を別スレッドへ送った後、主担当はいったん処理を終えるというものだ。子スレッドは完了時だけ主担当へ通知する。絶えず進捗を尋ねる回数を減らし、各スレッドが同じ状況を何度も読み込むのを抑える狙いである。

ただし「2体」は、公開された比較試験から導かれた上限ではない。対象課題と使用モデルは明らかでなく、試行回数も分からない。品質指標とトークンの集計方法も示されておらず、現時点ではProvencher氏の実務経験に基づく目安である。

1,393体は本当に無駄だったのか

Nous Researchの事例は、その目安を極端な規模から問い直す。Hermes Agentの主要実行は約19時間続き、1,393体のサブエージェントを起動した。最大218体が同時に動き、100万行を超える非テストPythonコードを36の重ならない範囲へ分けた。各担当は分離した作業領域（Git worktree）を使い、触る範囲、維持すべき外部仕様、実行する検査を記した指示書を受け取った。

主要実行の推定モデル費用は約1万9,300ドルで、再開後の作業などを含めると約2万5,000ドルに達した。人間によるレビュー時間は別である。それでもNousは、少人数のチームで同じ作業を進めれば2カ月から2年、15万〜180万ドルかかると粗く見積もり、放置していた改修を短期間で進めた価値を強調する。この人手費用は幅の大きい反実仮想であり、統制された総費用の比較ではない。

成果は大きい。非テストPythonコードは106万3,826行から69万8,363行へ34.4%減った。5,000行を超えるファイルは37から6、300行を超える関数は192から2へ減少した。最大だったgateway/run.pyも34,847行から5,512行になった。巨大な定義を読む負担は確かに下がった。

一方、レビューは既存テストが見逃した回帰も見つけた。リポジトリ内に呼び出し元がないという理由で、外部プラグインが使う可能性のある公開名を削除していたほか、例外処理を変える自動書き換えが約65箇所へ波及した。2回のコミュニティレビューで修正してからマージしたものの、追加修正はその後も続いた。行数削減を、そのまま品質向上とはみなせない。

Nousは4,000個のシンボルを探すシミュレーションも実施した。定義探索1回当たりの平均返却トークンは2,218から993へ減り、計算上は55.2%の減少となる。ただし測ったのはコード探索時に返る文脈量であり、エージェントが工学タスクを正しく終える割合ではない。中央値は逆に増え、モジュール数と依存関係も増加し、一部の入口では読み込みが遅くなった。

AD

「品質向上ゼロ」を証明する比較はない

Provencher氏はHermes事例に対し、単独のAstraなら費用の一部で実行できたはずだと批判した。しかし、同じコードベース、同じ完成条件、同じ検査を単独のAstraへ与えた結果は公開されていない。Hermes側にも単独実行との比較群はない。したがって、1,393体が費用を押し上げたことは確認できても、同じ品質を単独モデルがより安く実現できたとはまだ測れていない。

逆方向の主張にも同じ制約がある。Nousが示す15万〜180万ドルの人手費用は社内推定で、AI側には人間のレビュー時間を含めていない。さらに、コード行数や巨大関数の減少は構造の変化を示すが、将来の変更速度、障害率、保守費用まで証明しない。両者が最適化している目的も異なる。Provencher氏はトークン効率を問い、Nousは長く保留されていた作業を短時間で終える選択肢を評価している。

OpenAIの公式ガイドは、この対立に近い順序を勧める。まず道具を持つ単一エージェントの能力を高め、構成と評価を単純に保つ。そのうえで、条件分岐が多すぎて指示が守られない場合や、似た道具を何度も選び間違える場合に複数化を検討する。体数を先に決めるのではなく、単独担当が失敗する理由を特定してから役割を分ける考え方である。

エージェント数ではなく分割可能性を測る

3つの一次資料を同じ軸へ置くと、並列化の成否はエージェント数そのものではなく、作業範囲の独立性、共有文脈の重複、統合・検証負荷、経過時間の価値で判断する必要がある。

判断軸 単一または少数担当に向く 並列化を検討できる
作業範囲 同じ設計判断や同じファイルを触る 範囲と入出力を先に分離できる
共有文脈 大量の履歴を全員が必要とする 担当ごとに短い指示書で足りる
統合 人の判断で矛盾を解く必要がある 機械検査と明示した仕様で結合できる
失敗の隔離 一つの修正が全体へ波及する 作業領域や権限を担当ごとに分けられる
時間の価値 総費用の最小化を優先する 締切短縮がトークンの上乗せを正当化する

この表で右側の条件がそろわない限り、担当を増やしても処理の重複が先に膨らむ。特に、短い指示書へ圧縮できない共有履歴と、人の判断を要する統合作業が同時に残る仕事は、少数担当から始めた方が費用を測りやすい。

Hermesが成立した最大の条件は、1,393という数ではなく、36の非重複範囲と分離した作業領域を先に用意した点にある。それでも外部仕様の削除と例外処理の回帰が残り、人間のレビューが最後の防波堤になった。範囲を分けられない仕事へ同じ規模を持ち込めば、各担当が共通文脈を読み、同じ判断をやり直し、統合時に再び全体を検証することになる。

次の評価では、完了までの時間と総入力・出力トークンを同時に記録したい。加えて、重複したツール呼び出し、統合とレビューの回数、検出された回帰、完成条件の達成率を、単独実行と同じ課題で比べる必要がある。並列化が有効なのは、速さのために支払った追加トークンが、締切短縮や保留作業の解消として回収できるときである。