はじめに
先日、OpenAIが公開した「Research acceleration: The view inside OpenAI」をもとに、3.1 agent-workdays という数字について整理しました。
そこで次に気になったのが、
AIエージェントは、数を増やせばその分だけ仕事が速くなるのか？
という点です。
人間が1つずつ順番に作業する代わりに、複数のAgentへ仕事を分けて同時に進められるなら、単純にはかなり速くなりそうです。
実際、AnthropicはResearch機能で複数のsubagentを並列に動かし、複雑な調査では調査時間を最大90%短縮したと説明しています。
一方で、同じAnthropicの公開情報を見ると、
- Multi-agentは大量のtokenを消費する
- 依存関係が強い仕事には向かない
- codingはresearchほど並列化しやすくない
- 1つの遅いsubagentを待つこと自体がボトルネックになる
といった課題も示されています。
さらにAnthropicは別の解説で、**並列化の主な利点は「速さ」ではなく「網羅性（thoroughness）やカバー範囲」**であり、総実行時間はむしろ長くなることが多い、とも整理しています。
OpenAIも、研究現場で複数のAgentを同時利用するケースが増えている一方、研究全体には多くのボトルネックがあり、一部の指標が速くなっても研究全体が同じ割合で速くなるとは限らないと説明しています。
この記事ではOpenAIとAnthropicの公式情報をもとに、
- どんな仕事ならAgentの並列化が効くのか
- Agentを増やすことでどこまで速くなるのか
- どこで新しいボトルネックが生まれるのか
- 結局、Agent数より何が重要なのか
を整理します。
※本記事は2026年9月時点のOpenAI・Anthropic公式情報をもとにした個人の整理メモです。
※記事中の図は公開情報をもとに筆者が独自に作成したものであり、OpenAI・Anthropic公式の資料ではありません。
※各社が公開している数値は、それぞれ特定のシステム・評価・実験における結果です。一般的な「Agentを増やせば何倍速くなる」という法則を示すものではありません。
先に結論
公開情報を読む限り、答えは、
並列化しやすい仕事では大きな効果がある。ただし、Agent数に比例して無条件に速くなるわけではない
と整理するのがよさそうです。
イメージとしては、
Agentを増やす
↓
独立した作業を並列に進める
↓
待ち時間を減らせる
↓
全体が速くなる可能性
があります。
しかし同時に、
Agentを増やす
↓
調整・重複・統合・評価が増える
↓
依存関係の強い作業が残る
↓
別の場所がボトルネックになる
こともあります。
そのため、「Agentを何体にするか」より、
仕事をどこまで独立した単位へ分割できるか
の方が重要そうです。
Anthropic Researchでは並列化で最大90%短縮
まず、並列化がうまく効いた公式事例として分かりやすいのが、AnthropicのResearch機能です。
AnthropicのResearchは、Lead Agentが調査方針を考え、複数のsubagentへ別々の調査を任せるmulti-agent構成になっています。
Anthropicによると、初期のResearch Agentは検索を順番に実行しており、複雑な調査では非常に時間がかかっていました。
そこで、
- Lead Agentが3〜5個のsubagentを並列に起動
- 各subagentも3つ以上のtoolを並列利用
する仕組みを導入しました。
その結果、複雑なqueryでは調査時間を最大90%短縮できたとしています。
Before
Search A
↓
Search B
↓
Search C
↓
Search D
After
┌→ Subagent A → Search ...
Lead ───┼→ Subagent B → Search ...
├→ Subagent C → Search ...
└→ Subagent D → Search ...
「別々の方向を調べる」という仕事は、それぞれの作業の依存関係が比較的小さいため、並列化と相性がよいことが分かります。
なお、この90%という数字は、**Research機能における「調査にかかる時間」**についての説明です。研究や開発の全工程が90%短縮するという意味ではありません。
参考
性能も上がったが、単純に「Agent数の効果」とは言えない
Anthropicは、multi-agent Researchについて性能面の評価も公開しています。
内部Research Evalでは、
- Lead Agent: Claude Opus 4
- Subagent: Claude Sonnet 4
というmulti-agent構成が、single-agentのClaude Opus 4を90.2%上回ったとしています。
ここで押さえておきたいのは、この評価が何を対象にしたものかです。
Anthropicが挙げているのは、
- 独立した探索経路が同時に多数存在する（breadth-firstな）query
- 必要な情報量が単一のcontext windowに収まらないquery
といったタイプの調査です。具体例としては「S&P 500のIT企業すべての取締役会メンバーを特定する」といった問いが挙げられており、single-agentは逐次検索で答えに到達できなかったとされています。
つまり90.2%という数字は、あらゆるtaskでmulti-agentが90.2%優れているという意味ではありません。
もう1点、
Agentを増やしたから90.2%性能が上がった
と単純に解釈しないことも重要です。
Anthropic自身の分析では、BrowseCompにおけるperformance varianceについて、
- token使用量
- tool call数
- modelの選択
という3つの要因で95%を説明でき、特にtoken使用量だけで80%のvarianceを説明したとしています。
つまりmulti-agentは、
複数のcontext windowとAgentを使い、問題に投入できる推論量や探索量そのものを増やせる
ことが強みの一つだと考えられます。
当然、コストも増える
並列化で処理能力を増やせる一方、計算量やtoken消費は増えます。
Anthropicによると、同社のデータでは、
- Agent: 通常のchatの約 4倍
- Multi-agent: 通常のchatの約 15倍
のtokenを使うとしています。
つまり、
Agentを増やす
↓
探索できる範囲が増える
↓
性能や速度が上がる可能性
同時に
Agentを増やす
↓
token・tool call・計算量も増える
という関係です。
そのためAnthropicも、multi-agentは増加するコストに見合う価値があるタスクで利用する必要があるとしています。
「速くなるか」だけでなく、
その速度向上にどれだけの計算資源を使うのか
もセットで見る必要があります。
Anthropicは「並列化の利点は速さではない」とも書いている
ここが個人的に一番意外だったところです。
Anthropicは2026年1月23日に公開した「Building multi-agent systems: When and how to use them」で、multi-agentが単一Agentを上回りやすい3つの状況を整理しています。
| 状況 | 内容 |
|---|---|
| context pollution | 別のsubtaskで拾った無関係な情報が、後続のtaskの性能を落とす場合 |
| parallelization | 独立した作業を同時に進められる場合 |
| specialization | 別々の指示・tool・前提知識が本当に必要な場合 |
このうち parallelization について、Anthropicは「利点は速さではない」と明記しています。
Anthropicの説明では、並列化の主な利点は速さではなくthoroughness（網羅性）やカバー範囲であり、
- 広い情報空間を探す必要がある
- 複雑な問いを多くの角度から調べる必要がある
といった場面で、単一Agentがcontextの上限内で扱える範囲より広くカバーできることが価値だとされています。そのうえで、計算量そのものが大きく増えるため、総実行時間はむしろ単一Agentより長くなることが多いとも書かれています。
前の節で見た「調査時間を最大90%短縮」と一見矛盾するように読めますが、比較している対象が違います。
90%短縮の比較
初期の逐次検索中心のResearch Agent
vs
subagent・toolの並列化を導入したResearch
総実行時間が増えるという話
single-agentで処理する場合
vs
multi-agentで、より広い範囲を探索する場合
逐次的に進めていた探索を並列化すれば、待ち時間を大きく減らせる場合があります。一方で、multi-agentではより広い範囲を探索できる分、計算量や実行量そのものが増えるため、single-agentと比べて総実行時間が長くなることもある、という整理です。
「Agentを増やす」ことは、単純に速さを買うというより、網羅性やカバー範囲を広げるための手段と考えた方が、公開情報とは整合しそうです。
参考
何でも並列化できるわけではない
Anthropicは、multi-agentに向いていない仕事についてもかなり明確に書いています。
たとえば、
- Agent間で同じcontextを共有する必要がある
- Agent同士の依存関係が多い
- リアルタイムで細かく連携する必要がある
といった仕事です。
特に興味深いのがcodingについてです。
Anthropicは、
多くのcoding taskはresearchに比べて、本当に並列化できるtaskが少ない
と説明しています。
Researchの場合、
企業Aを調べる
企業Bを調べる
企業Cを調べる
企業Dを調べる
はかなり独立しています。
一方codingでは、たとえば次のように前工程への依存が強いケースがあります。
設計
↓
基盤実装
↓
機能A
↓
機能B
↓
統合
↓
テスト
これはあくまで依存関係を示すための例ですが、前の結果へ強く依存する作業では、Agentを増やしても待ち時間や調整が発生します。
「仕事の種類・工程で割る」分け方は相性が悪い場合がある
前述の「Building multi-agent systems」の解説では、実装／テスト／レビューのように、仕事の種類や工程ごとにAgentを分ける方法が、失敗しやすいパターンの一つとして紹介されています。
Agent A → 機能を実装する
Agent B → テストを書く
Agent C → コードをレビューする
一見きれいに分かれていますが、この分け方はhandoffのたびにcontextが失われ、調整コストが常時発生します。Anthropicは、ある実験ではsubagentが実際の作業よりcoordinationに多くのtokenを使っていたと書いています。
「並列に動かせる形に見える」ことと「実際に独立している」ことは別だ、という例として分かりやすいと思います。
16 AgentでCコンパイラを作った事例でも同じ問題が起きた
この「並列化できる仕事／できない仕事」の違いをかなり分かりやすく示しているのが、Anthropicが2026年2月に公開したCコンパイラ構築の実験です。
この実験では、16個のClaude Opus 4.6 Agentを並列に動かしました。
約2週間、約2,000 Claude Code sessions、API cost約2万ドルを使い、最終的に約10万行のRust製Cコンパイラを構築しています。このコンパイラはLinux 6.9 kernelをx86・ARM・RISC-V向けにbuildでき、GCCのtorture testの99%を通過したとされています。
この実験では、複数の独立した失敗testがある段階では並列化がうまく機能しました。
たとえば、
Agent A → failing test Aを修正
Agent B → failing test Bを修正
Agent C → failing test Cを修正
Agent D → failing test Dを修正
という形です。
ところがLinux kernelをcompileする段階では問題が起きました。
数百の独立したtestがあるtest suiteと違い、kernel compileは1つの巨大なtaskです。そのため複数Agentが同じbugへ到達し、
- 同じ問題を修正しようとする
- 変更が競合する
- お互いの変更を上書きする
という状態になりました。
Anthropicの記事では、全Agentが同じtaskで詰まっていたため、16 Agentを動かしても役に立たなかったと説明されています。
その後、GCCを正解側のoracleとして利用するtest harnessを用意することで、状況が変わりました。
kernelのfile群
├─ 大部分 → GCCでcompile（正しいことが分かっている）
└─ 一部 → Claude製compilerでcompile
kernelが動く → その一部にbugはない
kernelが壊れる → 一部をさらにGCC側へ戻して絞り込む
こうして問題箇所を切り分けられるようにしたことで、再び複数Agentが別々のbugへ取り組めるようになっています。
この事例を見ると、
Agent数より、仕事を並列化可能な形へ分解できるかが重要
ということがかなり分かりやすく見えてきます。
参考
並列化そのものにもボトルネックがある
さらに面白いのが、multi-agentシステムそのものにもボトルネックが生まれることです。
Anthropic Researchでは、Lead Agentがsubagentを起動したあと、subagentの終了を待つsynchronous executionを採用しています。
この方式はcoordinationを単純にできます。
一方で、
Subagent A ───── 完了
Subagent B ───────── 完了
Subagent C ───────────────── 完了
Subagent D ─────── 完了
Lead Agent
↓
Cが終わるまで待つ
という状況が起こります。
Anthropicは、
- Lead Agentが途中でsubagentをsteerできない
- subagent同士もcoordinationできない
- 1つの遅いsubagentによって、その回の並列実行のまとまり全体がblockされる
と説明しています。
非同期にすればさらに並列化できますが、
- result coordination
- state consistency
- error propagation
など別の問題が難しくなります。
つまり、
並列度を高めるほどcoordinationも難しくなる
ということです。
OpenAIの研究現場でも並列利用は増えている
OpenAIの2026年9月の「Research acceleration」でも、似た方向の変化が報告されています。
OpenAIでは研究者がcoding agentを日常的に利用し、4つ以上のAgentを同時に利用する高並列workflowを使う研究者も増えています。
なお、この「4つ以上」の集計は、ユーザーが直接起動したAgentだけでなく、そこから生成されたsubagentも含めた日次のピーク値です。3.1 agent-workdaysとは別の集計なので、両者は分けて読む必要があります。
また、2026年8月中旬には、研究組織全体で、
人間の1 workdayあたり3.1 agent-workdays
のeffortが使われていたと報告されています。
ただしOpenAIは、これをそのまま研究速度の倍率とは扱っていません。
OpenAIは、AI研究を多くの工程から成るプロセスとして説明しています。たとえば、
新しい改善案を設計する
↓
モデル性能を評価するevalを作る
↓
大規模に検証するためのインフラを構築する
↓
学習中のバグや危険・不整合な挙動を検出する
↓
有望なアイデアをcore training runへ統合する
といった工程があります。
OpenAIは、この研究プロセスのどこかがうまくいかなければ、research loop全体が制約されると説明しています。
つまり、一部の工程をAgentで高速化できても、別の工程がボトルネックとして残れば、研究全体が同じ割合で高速化するとは限りません。
※別の分析では、OpenAIはEpoch AIが開発したAI R&D lifecycle taxonomy（Decide / Design / Build / Run / Analyze / Communicate）を使って、coding agentの出力tokenを分類しています。これは上記の研究プロセスの説明とは別の分析です。
自動化が進むほど、残った仕事がボトルネックになる
これはかなり重要なポイントだと思います。
OpenAIは、automationが進むにつれて、
最も自動化しにくいtaskがresearcher effortの中で相対的に大きな割合を占め、今後のprogressの重要なbottleneckになる
と説明しています。
また、現時点では人間の研究者がresearch prioritiesを設定し、どのideasやresultsを追うかを判断し、scale・pause・deployといった判断を行うと説明しています。
たとえば、
コード作成 → Agentで高速化
調査 → Agentで高速化
実験監視 → Agentで高速化
しかし
研究テーマ決定 → 人間
結果の評価 → 人間
次の方向決定 → 人間
という状態になれば、
コード生成速度をさらに2倍にしても、研究全体が2倍になるとは限りません。
またOpenAIは、computeもprogressを制約するgating factorであり、他のbottleneckが減るにつれて重要性が増す可能性があるとしています。
人間の介入もまだボトルネック候補
OpenAIのデータでは、Agentが扱えるtaskの長さや成功率は改善しています。
一方、直近6か月のデータでは、
人間なら4〜8時間かかると推定されたtaskのうち、成功したcaseでも半数を超えて1回以上の人間介入が発生
しています。
つまり、
Agent A
Agent B
Agent C
Agent D
↓
大量の結果
↓
人間が確認・判断
という構造になったとき、今度は人間が結果を確認する能力がbottleneckになる可能性があります。
Agentを増やすことと、Agentを管理・評価できることは別の問題です。
参考
並列化しやすい仕事・しにくい仕事
ここまでの公式事例から、かなりざっくり整理すると次のようになりそうです。
| 並列化しやすい | 並列化しにくい |
|---|---|
| 独立した調査 | 前工程への依存が強い作業 |
| 複数sourceの探索 | 同じshared contextが必要 |
| 独立したfailing testの修正 | 1つの巨大なbugの解決 |
| 複数候補の比較 | Agent間の頻繁なcoordinationが必要 |
| 結果を最後に統合できる | 同じcodeやstateを同時に変更する |
| 成否をtestで判定しやすい | 正解や評価基準が曖昧 |
| 対象ごとに分けられる（対象単位の分割） | 工程ごとに分ける（実装／テスト／レビュー） |
もちろん、これは厳密な分類ではありません。
同じcodingでも、testを細かく分割できれば並列化しやすくなります。
逆にResearchでも、すべてのsubagentが同じ前提情報を必要とするならcoordination costが大きくなります。
つまり重要なのはtaskのジャンルそのものより、
どれだけ独立したsubtaskへ分解できる構造になっているか
なのかもしれません。
Agent数より「仕事の分け方」が重要なのかもしれない
今回、OpenAIとAnthropicの公開情報を並べてみて、一番気になったのはここです。
最初は、
1 Agentより4 Agent、4 Agentより16 Agentの方が速いのでは？
と考えたくなります。
しかし実際には、
Agent数
×
各Agentの能力
だけではなく、
Taskを独立した単位へ分解できるか
↓
各Agentへ重複なく割り当てられるか
↓
結果を正しく統合できるか
↓
結果を評価できるか
が重要になります。
AnthropicのCコンパイラ事例でも、16 Agentという数そのものより、test harnessによって仕事を並列化可能な形へ変えたことが重要でした。
Anthropic Researchでも、Lead Agentへ適切なtask decompositionを教えることが重要で、subagentへの指示が曖昧だと重複調査や抜けが発生したとしています。実際、初期のシステムでは、あるsubagentが2021年の自動車向け半導体不足を調べている間に、別の2つのsubagentが現在のサプライチェーンについて重複した調査をしていた、という例が挙げられています。
なおAnthropic自身は、まず単一Agentのbaselineを強くしてから、context pollution・specialization・parallelizationのいずれかで必要性が実証された段階でmulti-agentへ進むことを勧めています。数か月かけてmulti-agent構成を作った結果、単一Agentのpromptを改善するだけで同等になった、というチームの例にも触れています。
Agentを増やす前に、
仕事をどう分けるか
を設計する必要がありそうです。
個人的に気になったポイント
これは人間の仕事にも近い気がします。
人を増やせばプロジェクトが無条件に速くなるわけではありません。
仕事を分けられなければ、
- 同じことを複数人がやる
- 確認が増える
- mergeが必要になる
- 情報共有が増える
- 誰かの完了待ちになる
ことがあります。
AIエージェントでも似た問題が起き始めています。
違うのは、Agentなら非常に短時間で数を増やせることです。
だからこそ今後は、
「Agentを何体使えるか」より、「仕事を並列化可能な構造へ設計できるか」
という観点が重要になるのかもしれません。
まとめ
OpenAIとAnthropicの公式情報をもとに、AIエージェントの並列化について整理しました。
ポイントは次のとおりです。
- Anthropic Researchでは、3〜5個のsubagentとtoolの並列利用により、複雑なqueryの調査時間を最大90%短縮した
- Anthropicの内部Research Evalでは、multi-agent構成がsingle-agent構成を90.2%上回った。ただし評価対象は、探索経路が独立に多数あり単一context windowに収まらないbreadth-firstなqueryである
- 一方、multi-agentは通常のchatと比べ約15倍のtokenを使うとされている
- Anthropicは2026年1月23日の解説で、並列化の主な利点は速さではなく網羅性（thoroughness）やカバー範囲であり、総実行時間はむしろ長くなることが多いと整理している
- 依存関係が強い仕事やshared contextが必要な仕事はmulti-agentに向きにくい。特に「実装／テスト／レビュー」のような工程での分割はcoordination costが大きくなりやすい
- AnthropicのCコンパイラ実験では、独立したfailing testは並列化できたが、Linux kernelという1つの大きなtaskでは全Agentが同じtaskで詰まり16 Agentが役に立たなかった
- synchronousなmulti-agent構成では、1つの遅いsubagentを待つこと自体がbottleneckになる
- OpenAIでも4つ以上のAgentを同時利用する研究者が増えている（subagentを含む日次のピーク値）
- ただしOpenAIは、AI研究には複数の工程があり、一部が速くなっても研究全体が同じ割合で速くなるとは限らないと説明している
- 自動化が進むほど、自動化しにくい仕事やcompute、人間による判断が次のbottleneckになる可能性がある
- Agent数そのものより、taskを独立した単位へ分解し、結果を統合・評価できる設計が重要
AIエージェントを増やすことは、計算資源を増やすことに少し似ています。
ただし、仕事自体が並列化できなければ、その力を使い切れません。
今後Agentを使うときには、
「何体動かすか」ではなく、「どの仕事なら独立して同時に進められるか」
という視点で考えてみたいところです。
参考
- OpenAI - Research acceleration: The view inside OpenAI（2026年9月6日）
- Anthropic - How we built our multi-agent research system（2025年6月13日）
- Claude by Anthropic - Building multi-agent systems: When and how to use them（2026年1月23日）
- Anthropic - Building a C compiler with a team of parallel Claudes（2026年2月5日）