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

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

私はエージェントを、人間に考えるのと同じように考えています。1体のエージェントは働き手です。1000体のエージェントは組織であり、機械の組織は分散システムです。

人々は私に、エージェントは永遠に実行できると言い続けます。技術的にはそれは真実です。クレジットカードが限度に達するまで、ループでモデルを呼び出すことができます。しかし、エージェントは依然として有限なものの上で実行されます：トークン、コンテキスト、計算能力、メモリ、ツール、お金。何かが必ず尽きます。

人間もそれほど違いはありません。私たちはしばらく働いて疲れ果てます。ワーキングメモリはわずかです。私たちは物事を忘れます。そのため、重要な部分を書き留め、眠り、翌朝、頭をすっきりさせて同じアイデンティティで戻ってきます。

機械も、異なる形で同じ制約を持っています。1台のボックスはCPUを使い果たします。1つのポッドはメモリを使い果たします。誰も、すべてのプロセスが永遠に生き続けることを想定してそれを修正しません。私たちは持っているリソースで作業をスケジュールします。

なぜ知性が免除されるのか理解できません。エージェントはしばらく働き、重要なことを書き留め、コンテキストをクリアし、自分自身または別 のエージェントがそこから引き継ぐことができます。私たちはInsForgeでVPS上で独自のコーディングエージェントを実行していますが、それらは常にキルされ、再起動され、コンテキストを使い果たしています。実際に損害を与える失敗は、計画がエージェントのコンテキストウィンドウ内にのみ存在していた場合です。

［画像: 3つのレーン、人間、機械、エージェントがあり、それぞれが作業、永続化、休息、再開のサイクルを繰り返している］

TL;DR

• Google Researchの180設定の研究では、エージェントを追加することで並列作業が最大80.9%向上し、逐次作業は39%から70%低下しました。タスクの形状が決定要因となります。
• 同じ研究で、オーケストレーターはエラー増幅を17.2倍から4.4倍に削減しました。調整は実際の仕事です。
• Silo-Bench (ACL 2026) では、2体から100体のエージェントからなるチームは多くの会話をしましたが、推論は劣悪でした。最も難しいタスクは、50体で成功率ゼロになりました。
• したがって、永続的なものはエージェントではなく、状態であるべきです。エージェントをプロセスのようにスケジュールし、ノードのように回復させてください。

エージェントはプロセスのように見え始めている

これはしばらく前から単なるアナロジーではなくなりました。それを構築する研究ライン全体があります。

AIOS は、ラトガース大学の「LLMエージェントオペレーティングシステム」であり、1文で問題を提起しています。

"LLMまたはツールリソースへの無制限のアクセスを許可すると、エージェントのリソース割り当てと利用において、非効率的または潜在的に有害な結果を招く可能性があります。"

彼らの答えはカーネルです。すべて のエージェントリクエストはシステムコール（LLM呼び出し、メモリ読み取り、ストレージ書き込み、ツール使用）に分解され、スケジューラーは古典的なFIFO（先入れ先出し）とラウンドロビンを使用して、次に誰の呼び出しを実行するかを決定し、コンテキストマネージャーはタスク中のエージェントのスナップショットを作成して、中断および再開できるようにします。既存のフレームワーク上に構築されたエージェントを提供する場合、最大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, January 2026。

厳密な逐次推論を必要とするタスクでは、テストされたすべてのマルチエージェントバリアントが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倍に低下しました。それがマネージャーの仕事です。マネージャーはすべてのタスクを実行するわけではありません。それは何が必要かを決定し、作業を分解し、割り当て、進捗を監視し、競合を解決し、結果を統合します。

コミュニケーションは調整ではない

これは私にとって最も人間的な響きです。

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%

DeepSeek-V3.1のエージェント数に対するSILO-Benchタスク成功率（3つの通信プロトコルで平均化、論文表3）。X軸は順序であり、線形ではありません。出典：Zhang et al., Silo-Bench, ACL 2026 (arXiv:2603.01045)。

傾向はすべての難易度レベルで低下しており、途中でいくつかの小さな上昇（レベルIで50体から100体、レベルIIで10体から20体）がありますが、どれも回復にはほど遠いです。最も難しいタスク、つまりすべてのシャードを一度に組み合わせる必要があるタスクは、50体で成功率ゼロになり、100体でもゼロのままです。モデル全体で見ると、最も強力なモデルでは平均成功率は2体で61%から100体で18%に低下し、最も弱いモデルでは17%から1%に低下しました。著者たちの結論は、「調整オーバーヘッドはスケールとともに累積し、最終的に並列化の利点を完全に排除する」というものです。

100人規模のSlackチャンネルにいたことがあるなら、あなたはすでにこれを知っていました。100人を1つのチャンネルに入れても組織にはなりません。100体を1つのメッセージバスに乗せても、集合知にはなりません。

マネージャーが失敗するとどうなるか？

今日のほとんどのマルチエージェントシステムは、中央オーケストレーターを通じて調整されます。マスターエージェントが目標を分解し、ワーカーにタスクを渡し、それらを監視し、結果をマージします。Googleの数値は、それが妥当なデフォルトであり、私たちもそうしていることを示しています。

分散システムの人々は次に何が起こるかを知っています。マスターがボトルネックになります。次にマスターが失敗します。コンテキストを使い果たすか、スタックするか、マシンがクラッシュするか、単に悪い判断を下し始めます。

AgentNet の著者たち（NeurIPS 2025）はそれを直接述べています：既存のシステムは「しばしば中央集権的な調整に依存しており、スケーラビリティのボトルネック、適応性の低下、単一障害点につながります。」彼らの答えは分散ルーティングであり、エージェントはローカルな専門知識に基づいて作業を互いに渡します。MIT Media LabのAyush Chopra はさらに進んで、「真の分散システムは、エージェント間の相互作用から生まれる調整を示し、「知性は個々の意思決定者ではなく、相互作用パターンそのものにあります。」と述べています。

ここでどちらかの側に立つ必要はないと思います。分散システムは、永続的な状態、ハートビート、障害検出、コンセンサス、フェイルオーバー、リーダー選出を使用して、何十年も前にこの問題の解決策を見つけました。リーダーが消えても、別のノードが引き継ぎます。それは、必要な状態がリーダー内に決して存在しなかったからです。

信頼性の高いシステムは、1つのインテリジェントなプロセスが永遠に生き続けることに依存できません。したがって、重要なのはエージェントの寿命ではなく、状態の寿命です。ゴール、計画、決定、完了したタスク、保留中のタスク、成果物、所有権、チェックポイント。これらは個々のエージェントよりも長く存続するはずです。エージェントは出入りします。組織は継続します。

［画像: 中央に永続的な状態。それに接続されたライブエージェント、コンテキストを使い果たした失敗したエージェント、そしてそこから作業を引き継ぐ新しいエージェント］

分散プログラミングでキャリアを積んだChristopher Meiklejohnは、この春率直に述べました：「複数のエージェントが同じコードベースで作業する瞬間、あなたは分散システムを持っています。」そしてそれに続く問題は「バグではありません。[...]それらは、状態を共有する複数の自律プロセスを持つことの避けられない結果です。」

興味深い問題

したがって、スケジューラー、ある種の階層、ワーカーよりも長く存続するメモリ、明確な所有権、バックプレッシャー、障害回復、そしてどのエージェントがスタックしているかを知るのに十分なオブザーバビリティが必要です。時にはリーダーと、それを置き換える方法が必要です。

だからこそ、私が興味深いインフラストラクチャの質問は「永遠に実行されるエージェントをどう構築するか？」ではなく、「実行されない何百万ものインテリジェントワーカーをどうスケジュールし、調整するか？」だと考えているのです。

オペレーティングシステムはプロセスをスケジュールする方法を教えてくれました。コンテナオーケストレーターは、一時的なワークロードをスケジュールし回復する方法を教えてくれました。分散システムは、信頼性の低いマシンがどのようにして信頼性の高いサービスを積み上げることができるかを教えてくれました。人間の組織は、個々の限界のある人々が単一の個人ではできないものをどのように構築するかを教えてくれました。エージェントは、それら4つの重なる場所に位置しています。

1体のエージェントは知性の問題です。100万体のエージェントは分散システムの問題です。

この記事は問題についてです。100万体のエージェントのためのインフラストラクチャが実際にどのように見えるべきか、チェックポイント、スケジューラー、ワーカーが得る予算、コーディネーターが死んだときの引き継ぎは、それ自体で投稿する価値があり、それが私が次に書くものです。

この記事が気に入ったら、教えてください。または、X または LinkedIn でフォローして、次回の投稿を見逃さないようにしてください。

FAQ

この記事を読んだ後に人々が尋ねる3つの質問

マルチエージェントシステムは中央オーケストレーターを持つべきですか？

通常ははい、ただし注意が必要です。中央集権型オーケストレーターはエラー増幅を4.4倍に抑えましたが、独立エージェントでは17.2倍でした。しかし、オーケストレーターはボトルネックであり単一障害点でもあるため、その状態は外部に存在する必要があり、別のエージェントが引き継げる必要があります。

エージェントオペレーティングシステムとは何ですか？

エージェントをプロセスのように扱うランタイムです。AIOSは、スケジューラー、コンテキストマネージャー、メモリマネージャー、ストレージマネージャー、ツールマネージャー、アクセス制御を備えたカーネルを提案しており、これにより多くのエージェントが、それぞれが永遠に実行されると仮定するのではなく、有限のLLM、メモリ、ツールの容量を共有できます。

エージェントが死んだときに生き残るべきものは何ですか？

ゴール、計画、決定、完了したタスクと保留中のタスク、成果物、所有権、およびチェックポイント。その状態が永続的で、単一のエージェントの外にあれば、エージェントはコンテキストを使い果たしたり、キルされたり、再スケジュールされたりしても、作業は継続します。

ソース

• Kim, Liu et al., Towards a science of scaling agent systems: When and why agent systems work, Google Research blog, January 28, 2026. Paper: arXiv:2512.08296。
• Zhang et al., Silo-Bench: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems, ACL 2026 main conference. Code。
• Mei et al., AIOS: LLM Agent Operating System, Rutgers University, 2024, revised 2025。
• Xiang et al., LLM-as-Scheduler: Agentic Workflow Dynamic Scheduling, ACL 2026。
• Yang et al., AgentNet: Decentralized Evolutionary Coordination for LLM-based Multi-Agent Systems, NeurIPS 2025。
• Ayush Chopra, What is a Multi-Agent System?, MIT Media Lab, June 16, 2025。
• Christopher Meiklejohn, Multi-Agent Systems Have a Distributed Systems Problem, March 30, 2026。