100万のエージェントは分散システムの問題である

私はエージェントを人間に考えるのと同じように考えています。1つのエージェントは労働者です。1000のエージェントは組織であり、機械の組織は分散システムです。人々はエージェントは永遠に実行できると言い続けます。技術的にはそれは真実です。クレジットカードが限度に達するまでモデルをループで呼び出すことができます。しかし、エージェントは有限なものの上で実行されます。トークン、コンテキスト、計算能力、メモリ、ツール、お金。何かが必ず尽きます。人間もそれほど違いはありません。私たちはしばらく働くと疲れます。ワーキングメモリは非常に小さいです。私たちは忘れます。だから、重要な部分を書き留め、眠り、翌朝には頭をすっきりさせて、同じアイデンティティで戻ってきます。機械も異なる形で同じ制約を持っています。ボックスはCPUを使い果たします。ポッドはメモリを使い果たします。誰もすべてのプロセスが永遠に生き続けることを期待してそれを修正しません。私たちは持っているリソースで作業をスケジュールします。知能に免除がある理由がわかりません。エージェントはしばらく働いて、重要なことを書き留め、コンテキストをクリアし、自分自身または別 のエージェントがそこから引き継げるようにすることができます。私たちはInsForgeで独自のコーディングエージェントをVPSで実行しており、それらは常にキルされ、再起動され、コンテキストを使い果たしています。実際に損害を与える失敗は、計画がエージェントのコンテキストウィンドウ内にのみ存在していた場合です。 TL;DR Google Researchの180設定の研究では、エージェントを追加することで並列作業が最大80.9%向上し、逐次作業は39%から70%低下しました。タスクの形状が決定します。同じ研究で、オーケストレーターはエラー増幅を17.2倍から4.4倍に削減しました。調整は実際の仕事です。Silo-Bench（ACL 2026）では、2〜100人のエージェントのチームが大量に会話しましたが、推論は悪かったです。最も難しいタスクは、50エージェントで成功率ゼロになります。したがって、永続的なものはエージェントではなく状態であるべきです。エージェントをプロセスのようにスケジュールし、ノードのように回復させます。 エージェントはプロセスのように見え始めています。これはしばらく前にアナロジーではなくなりました。それを構築する研究ライン全体があります。Rutgers大学の「LLMエージェントオペレーティングシステム」であるAIOSは、問題文を1文で始めています。「LLMまたはツールリソースへの無制限のアクセスを許可すると、エージェントの非効率的または潜在的に有害なリソース割り当てと利用につながる可能性があります。」彼らの答えはカーネルです。すべて のエージェントリクエストはシステムコール（LLM呼び出し、メモリ読み取り、ストレージ書き込み、ツール使用）に分解され、スケジューラーは古典的なFirst-In-First-OutとRound Robinを使用して誰の呼び出しが次に実行されるかを決定し、コンテキストマネージャーはタスク中のエージェントをスナップショットして中断および再開できるようにします。彼らは、既存のフレームワーク上に構築されたエージェントを提供する場合、実行速度が最大2.1倍になると報告しています。スケジューリング、コンテキストスイッチング、メモリ管理、ストレージ、アクセス制御。それがオペレーティングシステムです。プロセスはたまたま考えているだけです。それは1レベル上でも利益をもたらします。 LLM-as-Scheduler（ACL 2026）は、ほとんどのクエリが重いマルチエージェントワークフローに値しないという観察から始まり、スケジューラーがクエリごとにワークフローを選択できるようにします。彼らは、トークン数を43%削減し、エンドツーエンドのレイテンシを36%以上削減し、精度は強力な固定ワークフローに対して最大1.4パーセントポイントの低下で済みました。したがって、1つのエージェントはプロセスのように見え、数千のプロセスにはスケジューラーが必要です。結構です。しかし、計算能力のスケジューリングはその半分にすぎません。エージェント同士を調整する必要もあり、そこが面白くなるところです。10人が調整します。1万人はマネージャーを考案します。10人は部屋で自分たちで調整できます。1000人はお互いに話して、会社が何をすべきかを独立に決定することはできません。そこで、チーム、マネージャー、部門、そして最終的にはCEOを考案しました。マネージャーが存在するのは、調整自体が仕事であり、誰かがそれをしなければならないからです。私もエージェントが同じ問題を抱えるだろうと仮定しました。今ではデータがあります。 Google ResearchとMITは、5つのアーキテクチャ（単一エージェント、独立、集中型、分散型、ハイブリッドマルチエージェント）と3つのモデルファミリーにわたる180のエージェント構成の管理された研究を実施しました。彼らの見出しは、「「エージェントが多い」アプローチはしばしば天井に達し、タスクの特定の特性に合わない場合はパフォーマンスを低下させる可能性さえある」でした。逐次タスク−39%から−70%テストされたすべてのマルチエージェントバリアントは、計画スタイルのタスクを悪化させました。並列化可能なタスク+80.9%集中型調整による財務推論同じ5つのアーキテクチャ、反対の結果、タスクの形状によって決定されました。出典：Google Research、「Towards a science of scaling agent systems」、2026年1月。 厳密な逐次推論を必要とするタスクでは、テストされたすべてのマルチエージェントバリアントが、39%から70%悪化させました。彼らの説明は、通信オーバーヘッドが推論を断片化し、実際のタスクのための「認知予算」が少なすぎたということです。財務推論のような並列化可能な作業では、集中型調整がパフォーマンスを80.9%向上させました。エージェントが多いほど知能が増えるわけではありません。彼らは調整を増やしましたが、調整はタスクが必要とするのと同じ予算を消費します。 2番目の発見は、私が繰り返し考えていることです。エラー増幅：独立エージェント17.2倍対集中型オーケストレーター4.4倍0倍5倍10倍15倍20倍独立エージェント：17.2倍のエラー増幅独立エージェント（オーケストレーターなし）17.2倍集中型オーケストレーター：4.4倍のエラー増幅集中型オーケストレーター（1人のコーディネーター）4.4倍Google Researchの実験における最大エラー増幅：話さない並列エージェントはエラーを最大17.2倍に増幅しました。集中型オーケストレーターは同じ効果を4.4倍に抑えました。出典：Google Research、「Towards a science of scaling agent systems」、2026年1月。話さない並列エージェントはエラーを17.2倍に増幅しました。それらの前にオーケストレーターを置くと、4.4倍に低下しました。それがマネージャーの仕事です。マネージャーはすべてのタスクを実行するわけではありません。それは何が起こるべきかを決定し、作業を分割し、それを割り当て、進捗を監視し、競合を解決し、結果を組み合わせます。 コミュニケーションは調整ではない。これは人間らしいと感じます。Silo-Bench（ACL 2026採択）は、2〜100人のエージェントのチームに30の分散アルゴリズムタスクを与え、単一のエージェントではすべてを見ることができないようにデータをシャードしました。54の構成、1,620の実験。エージェントはピアにメッセージを送信したり、ブロードキャストしたり、ファイルを共有したりできました。彼らはたくさん話しました。それはあまり助けになりませんでした。「エージェントは自発的にタスクに適した調整トポロジーを形成し、積極的に情報を交換しますが、分散状態を正しい回答に合成することに体系的に失敗します。」著者はこれをコミュニケーション・推論ギャップと呼んでおり、彼らの1行バージョンは私が書くよりも優れています：「エージェントは有能なコミュニケーション能力者ですが、分散推論能力は低いです。」スケールとともに悪化します。 SILO-Benchのエージェント数ごとの成功率：すべての難易度レベルは開始点よりもはるかに下で終了し、レベルIIIタスクは50および100エージェントで成功率ゼロになります0% 25% 50% 75% 100% 2 5 10 20 50 100 エージェント数 システムタスク成功率レベルI（集計）、2エージェント：85%成功レベルI（集計）、5エージェント：72%成功レベルI（集計）、10エージェント：68.7%成功レベルI（集計）、20エージェント：65.7%成功レベルI（集計）、50エージェント：38.1%成功レベルI（集計）、100エージェント：40.6%成功レベルII（メッシュ）、2エージェント：61.7%成功レベルII（メッシュ）、5エージェント：55.3%成功レベルII（メッシュ）、10エージェント：28.3%成功レベルII（メッシュ）、20エージェント：29.5%成功レベルII（メッシュ）、50エージェント：17.4%成功レベルII（メッシュ）、100エージェント：14.3%成功レベルIII（グローバルシャッフル）、2エージェント：36.2%成功レベルIII（グローバルシャッフル）、5エージェント：17.2%成功レベルIII（グローバルシャッフル）、10エージェント：10%成功レベルIII（グローバルシャッフル）、20エージェント：5.7%成功レベルIII（グローバルシャッフル）、50エージェント：0%成功レベルIII（グローバルシャッフル）、100エージェント：0%成功レベルI（集計）レベルII（メッシュ）レベルIII（グローバルシャッフル）50および100で0%SILO-Benchタスク成功率対エージェント数（DeepSeek-V3.1、3つの通信プロトコル全体で平均）（論文表3）。X軸は順序であり、線形ではありません。出典：Zhang et al.、「Silo-Bench」、ACL 2026（arXiv:2603.01045）。傾向は