将来のAIエージェントが協働するよう学習される理由

私たちは、マルチエージェントシステムがほぼどこにでもあり、しかもそれが単にプロンプトエンジニアリングを極端に推し進めたものには見えない世界へと向かっている。

ここ数年、AIシステムが問題を解くために複数のLLMインスタンスを立ち上げる例がますます増えている。OpenAI にはマルチエージェントのチームがあり、同社が最近達成した IMO の金メダルにも関わった。¹ Grok 4 Heavy は、複数のエージェントに同じタスクを並列に取り組ませる。Claude Research は Claude 4 の複数のインスタンスを調整する。Claude Code は Task ツールを使ってサブタスクをサブエージェントに任せる。そしてこの1年で、OpenAI、Anthropic、Google DeepMind のいずれもが、マルチエージェントシステムの専門知識を持つ人材の求人を出している。

マルチエージェントシステムへのこの流れは続くと私たちは予想している。タスクが長くなるにつれて、並列化の利点は無視できないほど大きくなるからだ。重要なのは、これらのLLMインスタンスは並列に働くものの、多くの場合、独立には働かないということだ。互いの邪魔をしないよう調整する必要があり、重要なコンテキストや学んだことを共有できれば性能は上がる。現在、この調整は多くの場合、サブエージェントごとに特定の役割をハードコードすることで行われている。しかしこのやり方は廃れていき、必要に応じて任意のインスタンスを立ち上げて調整するよう、もともと学習されたモデルに置き換わると私たちは予想している。

Epoch AI の最新情報を受け取る 購読する

並列化から得られる莫大な利益

マルチエージェントシステムがさらに広まると予想する根本的な理由は、多くのタスクで、LLMインスタンスを並列に働かせることの利点が極めて大きいことにある。正確さと信頼性が上がり、実時間が節約でき、メモリ使用量も減る。

第一に、LLMインスタンスを並列に働かせると、モデルがより難しいタスクを解く能力が上がりうる。たとえば Claude Research のマルチエージェント構成は、Anthropic 社内の研究評価で、単一エージェントの Claude Opus 4 を90.2%上回った。複雑な問題では、必要な解決手順をすべて事前に予測するのは難しいので、複数のLLMにさまざまな戦略を試させると役に立つ。Grok 4 Heavy や GPT-5 Pro のような現在の製品は、単一インスタンスの版より目覚ましい性能と高い信頼性を示している。

こうした改善の多くは、マルチエージェントシステムが単一インスタンスの版より多くのトークンを使うことによるものだ。たとえば Claude Research のマルチエージェント構成は、単一エージェントの3.75倍、単純なチャットでの対話の15倍のトークンを使う。ここに、複数のエージェントを立ち上げる利点がある。同じ数のトークンを単一のコンテキスト内で使うには、言語モデルが現在持っていない、長いコンテキストを扱う能力が必要になるからだ。そして仮にモデルが実用上十分に大きなコンテキストウィンドウを持っていたとしても、コンテキストをよりモジュール化するほうがやはり役に立つ。たとえば LoCoDiff というベンチマークを考えてみよう。そこでは、長いコンテキストにわたってほぼ重複するコードベースがLLMを混乱させうる。このため、複数のLLMを立ち上げれば、トークン数をさらに有効にスケールさせられる。

第二に、タスクが複数のサブタスクに分かれる場合、それらのサブタスクを並列に行えば時間を大幅に節約できる。たとえば、Claude Research での並列のツール呼び出しは、「複雑な問い合わせの調査時間を最大90%短縮し、Research が何時間もかかっていた仕事を数分でこなせるようにした」。そしてこれがほかのタスクにも当てはまることは容易に想像できる。自分の分身を100人作って並列に処理できるなら、メールに一通ずつ返信して時間を無駄にする理由があるだろうか。

決定的に重要なのは、タスクを速くこなせることは、待ちきれないユーザーにとって良いだけではないということだ。AI開発者にとっても役に立つ。試行錯誤のサイクルが速くなり、ひいてはアルゴリズムの進歩が速くなるからだ。報酬モデルやデータの配合がモデルの質にどう影響するかを試すのに何日もかかるようでは、それらを改善するのは難しい。LLMがより長い時間幅のタスクをこなせるようになり、タスクを逐次的に解くのにより多くのトークンを使うようになるにつれて、この点はますます重要になっている。

関連して、並列化は、たとえばKVキャッシュの肥大化を防ぐことで、推論実行時に使えるメモリをより効率的に使う助けにもなる。たとえば、独立に行える五つのサブタスクを必要とするタスクを考えてみよう。これらを順番に行うと、5番目のサブタスクにたどり着くころには、モデルのKVキャッシュには最初の四つのサブタスクを解くのに関わったすべてのトークンのキーとバリューが入っている。五つのサブタスクを並列に解くのに比べて、これは極めて無駄が多い。

マルチエージェントシステムが広く使われるようになるこの流れに逆らう要因の一つは、コストである。マルチエージェントシステムは、単一のLLMインスタンスに問い合わせるより多くのトークンを有効に消費することで性能を上げているので、顧客は出力の質が下がっても支払いを少なくするほうを好むかもしれない。一部のタスク、たとえばユーザーが価格に非常に敏感で、質の高い応答からあまり価値を得ない消費者向け製品では、これが懸念材料になることには同意する。しかし、経済的価値が十分に高く、マルチエージェントシステムに向いているタスクは数多くあり、そこではマルチエージェント構成の利点がコストを上回ると私たちは考えている。その特に顕著な例がコーディングである。コーディングは現在のLLM利用の大部分を占め、年に数千億ドルの価値があり、実質的にすべてのフロンティアAI企業が主に力を入れている分野でもある。今日でさえ、Claude Code のような製品はマルチエージェント構成に基づいており、今後も似たような状況が続くと予想している。

もう一つの限界として考えられるのは、マルチエージェントシステムが大きな利益をもたらすのは、多くのコンテキストを共有しなくてもよいサブタスクに分解できるタスクに限られるということだ。そうした構造を持つタスクがどれだけの割合を占めるのかは未解決の問題である。しかし、経済的に重要なタスクの大半はこのように分解できると私たちは考えている。次節以降で見るように、サブエージェントは完全に独立して動く必要はなく、ときどき関連するコンテキストを共有できるのだから、なおさらそうだ。

並列に動くLLMインスタンスはやりとりし、調整し合うようになる

これまで見てきたマルチエージェントシステムのほとんどは、エージェント間の大がかりな調整を必要としていなかった。Grok 4 Heavy や o3-pro の場合、複数のインスタンスが立ち上げられるが、各インスタンスは同じタスクを解く。Claude Research の場合、異なるエージェントが異なるサブタスクを解くが、共有された環境に副作用を及ぼすことはない。

その例外の一つが Claude Code である。この場合、Claude の各インスタンスは、編集しているリポジトリを変更する行動をとることができ、ほかのインスタンスの行動と衝突する可能性がある。こうした場合には、エージェントが互いの邪魔をしないことが非常に重要になる。そしてコーディングではこの問題に場当たり的な回避策を使うこともできるが、² これはほかの分野にも広がる課題であり、コーディングは先行指標にすぎない。将来のエージェントは、Excel ファイルや Figma、その他のコンピュータ上の作業に同時に取り組む際に、調整し合う必要があるかもしれない。

互いの邪魔をするという問題を度外視しても、エージェント同士がやりとりしてアイデアを共有することにはおそらく利点がある。問題を解く際、エージェントは異なるアプローチを試し、どのアプローチがより有望か、あるいは有望でないかについての情報を共有できる。

その結果、将来のエージェントは独立には動かなくなる。コードですでに見られているように、エージェントは互いに干渉しないよう調整する必要があり、また意思疎通をし、ときどき関連するコンテキストを共有することからも利益を得るだろう。

ハードコードされたマルチエージェントシステムからの脱却

ここまでで、マルチエージェント構成から得られる利益は莫大になりうること、そしてサブエージェントは共有された環境で同時に動きながらも、やりとりし、調整し合い、互いに干渉しないようにするはずだということを確認した。現在、これは多くの場合、サブエージェントの役割とできることを細かく指定した凝ったスキャフォールド（モデルを動かす周辺の仕組み）によって実現されている。しかし、これがそう長く続くとは私たちは思わない。

どういうことかを説明するため、またしても Anthropic の Claude Research を取り上げよう。Claude の複数のインスタンスを調整するため、Anthropic は徹底的に作り込んだプロンプトを使った。たとえば、「引用サブエージェント」や「検索サブエージェント」といった特定のエージェントの役割を手作業で指定している。そして、あるタスクのためにいくつのエージェントを立ち上げるかを「リードエージェント」に選ばせる代わりに、プロンプトで、立ち上げるエージェントの数を明示的にハードコードしている。

このような硬直した構成は、おそらく長続きしない。GPT-4 のようなモデルでは「ステップバイステップで考えよう」といった作為的なプロンプトを使っていたものだが、モデルの能力を高める学習によって、その必要はなくなった。それとまったく同じように、こうした場当たり的なプロンプトが続くとは考えるべきではない。歴史的にもそうしたものは残ってこなかったし、マルチエージェントのLLM構成が例外だと考える理由もない。

その理由の一つは、研究所が計算資源のスケーリングを続けると予想されることだ。研究所はすでに、こうしたモデルを改善するために大量の労力と計算資源を注ぎ込んでおり、その一部は、インスタンス同士がやりとりするよう学習させることに充てられる可能性が高い。そうすれば、モデルは互いの邪魔をせずに、また単純なタスクに50ものエージェントを立ち上げてしまう傾向に陥らずに、調整することを学べる。Noam Brown がマルチエージェントRLの研究に「苦い教訓（Bitter Lesson）」を取り込ませると言うときに意味しているものの一部は、おそらくこれだと思う。必要なのは、相応の計算資源と試行錯誤だけだ。

もう一つの理由は、こうしたハードコードされたプロンプトから離れることで、マルチエージェント構成をより動的にできることだ。研究所がマルチエージェント構成から得られる利益を本当に生かすには、現実世界のさまざまな状況でそれを活用できるようにしたい。そうした状況の多くは、一見しただけでは分からない。つまり、いくつの（どの種類の）サブエージェントを立ち上げるか、タスクをどう分割するか、やりとりするエージェント間の衝突にどう対処するか、といったことをLLMエージェント自身に選ばせることになる。長期的には、こうした選択は、事前に指定するのではなく、タスクについての関連情報を持つエージェントが決めるのが最も効果的だろう。

要するに、マルチエージェントのLLM構成はますます増えており、そのうち最も注目すべきなのは、ハードコードを伴わない構成である。そうした移行から得られる利益は、少なくとも一部のタスクでは莫大になりうる。特に、複数のフロンティアAI研究所が最近、複数のLLMを使う設定について研究を発表していることを考えると、今後1〜2年のうちに、LLMが互いに調整し合うよう明示的に学習されたことを示す大きな発表がこれらの研究所からあっても驚かない。

長期的には、事態の不確実性はかなり高まる。ここまでは主に、同じ提供元（あるいは同じユーザー）の複数のエージェントが互いに調整し合うシステムを取り上げてきた。しかし将来の力学は、利害の対立する異なる研究所のエージェントが関わる、はるかに複雑なものになりうる。並列化の利益をどう活用するのが最善かも、ますます不透明になる。たとえば、それをより自然な形で行う将来のモデルアーキテクチャが登場する可能性も否定しにくい。それでも、既存の傾向を最も素直に延長すれば、こうなると私たちは考えている。既存の硬直したマルチエージェントの枠組みは廃れていく。代わりに、少なくとも今後1〜2年は、複数のエージェントが調整し合い、やりとりすることを学ぶようになる可能性が高い。