核心要約
最近、Swarmsチームが発表したGraphWorkflowにより、マルチエージェントタスクのスケジューリングが高速化されましたが、この論文の真の価値は「62.5％の加速」という数字そのものにあるのではありません。それは重要な兆候を示しています。つまり、マルチエージェントシステム（通称「蜂の群れ」）は、「モデルの賢さ」を競う段階から、「組織の協力能力」を競う段階に移行しているのです。蜂の群れは単にエージェントが多ければ多いほど良いわけではなく、「賢いエージェントたちが互いに時間を無駄にせず、集団で間違いを犯さず、安定してタスクを完了できるようにする」という問題を解決する必要があるのです。
一、「蜂の群れ」に惑わされないで：単なるエージェントの集まりではない
多くの製品では「複数のエージェントを同時に動かす」ことを蜂の群れと呼んでいますが、厳密に言えば、本物の蜂の群れとは「中央制御がなく、個々のエージェントが局所的な情報に基づいて行動し、全体として集団的な行動を形成する」ものです（例えばアリが道を探すような）。現在実際に使用できるマルチエージェントシステムは、むしろ「臨時のプロジェクトチーム」に似ています：
- 単一エージェント：一人で作業をこなす熟練した従業員のようなもので、線形で短いタスクに適しています（例えばメールを書くなど）；
- スーパーバイザー/ワーカー：プロジェクトマネージャーが数人のアシスタントを指揮する形（例えばAnthropicのシステムでは、メインエージェントがタスクを分割し、サブエージェントが資料を調べる）；
- グラフワークフロー：固定されたプロセスのパイプライン（例えばコンプライアンスチェックやバッチテストなど）で、GraphWorkflowやLangGraphもこのカテゴリに属します；
- ダイナミックな蜂の群れ：タスクの途中で自ら分割するかどうか、どのような仲間と協力するかを決定するもの（例えばKimi Agent Swarmは300個のサブエージェントを動的に調整できる）；
- 完全に分散された蜂の群れ：まだ実験室段階であり（例えば鳥の群れのシミュレーションのような）、実際の使用にはまだ遠いです。
したがって、蜂の群れの本質は「組織の問題」です。つまり、複数のエージェントが分業し、コミュニケーションを取り、状態を共有することで、単一のエージェントでは不可能なことを達成する方法です。
二、なぜマルチエージェントが必要なのか？単一エージェントではできないタスク
モデルはどんどん賢くなっていますが、すべてのタスクが「より多くの時間を与えれば解決できる」というわけではありません：
- 作業範囲が広すぎる：例えば100件のレポートから相互に裏付け合う事実を見つけ出す場合、単一エージェントは一つずつ確認しなければならず、スタックする可能性がありますが、マルチエージェントは異なる方向を並行して調べることができます（例えば複数の人が異なる資料を同時に調べる）；
- 単一の思考には限界がある：単一エージェントは一つの方向に集中してしまい、他の道を見落とすことがありますが、マルチエージェントは複数の道を同時に進むことができます（例えば誰かが公開資料を調べ、誰かが原始的な文書を調べ、誰かが反証する）。
Anthropicの例は非常にわかりやすいです。メインエージェントが全体を統括し、サブエージェントが作業を行うことで、単独で最も強力なモデルを使用するよりも90％の効率が向上しますが、トークンコスト（費用）は15倍になります。すべてのタスクに適しているわけではありません！例えばプログラミングタスクでは並行化できる部分が少なく、マルチエージェントはむしろ引き継ぎのコストを増加させることがあります。
三、スケジューリングの高速化の背後にあるもの：組織レベルで計算能力が消費され始めている
GraphWorkflowの高速化は「タスクスケジューリング」の最適化によるものです。固定されたタスクフローを事前にコンパイルし、繰り返し実行することで、「誰が誰を待つか、誰が結果を誰に渡すか」という時間を削減しています。しかし、これは単一のマシンでの静的なタスクのスケジューリングコストのみを測定しており、モデル自体の速度は測定していません。モデルの呼び出しには数百ミリ秒かかりますが、スケジューリングの最適化による数ミリ秒の改善は大きくありません。
しかし、これは重要な問題を示しています。エージェントが数十から数百に増えると、「組織コスト」が大きな割合を占めるようになります。会社の人員が増えると同じように、誰が何をするか、誰が誰を待つか、誰が間違えたらどうするかを調整するために時間がかかります。これらのスケジューリング作業はもはや「付随的な機能」ではなく、システムが安定して動き続けるかどうかを決定する要素になります。現在、蜂の群れについて議論する際には、「ワークフロー」「スケジューラー」「状態の統合」といった技術的な用語がより頻繁に使われるようになっています。これがその理由です。
四、蜂の群れの3つの難問：タスクの分割、情報の管理、エラーの検出
タスクを複数のエージェントに割り当てることは管理のように見えますが、実際には技術的な難問です：
1. 委任：どのタスクを分割すべきか？誰に割り当てるべきか？いつ自分で処理を終えるべきか？例えばSearchSwarmでは、メインエージェントが「委任するかどうか」を学び、サブエージェントは圧縮された結果のみを送信することで、コンテキストの無駄を避けます。
2. 記憶：ユーザーの好みを覚えるのではなく、「タスクの証拠の連鎖」を管理することです。誰が何を担当しているのか？結論はどの資料から来ているのか？どの仮説が覆されたのか？もし各エージェントが長い会話を転送するならば、システムはノイズに埋もれてしまいます。
3. 検証：マルチエージェントが自然と信頼性が高いわけではなく、むしろ集団で間違いを犯す可能性があります（例えば同じ資料を使用すると、偏見が強化される）。実験によると、中央の検証機能を持つアーキテクチャでは、エラーの拡大率が4.4倍であり、検証機能がない場合の17.2倍よりもはるかに低いです。将来最も不足するのは「作業をするワーカー」ではなく、「エラーを検出するバリデーター」です。
五、未来の蜂の群れ：「小さな会社」ではなく、臨時の「突撃隊」
多くのデモでは、蜂の群れを「CEO、マーケティング、製品」の部門構造に例えていますが、これは誤解を招くものです。未来の主流の形態は「臨時の小隊」のようになるでしょう：
- タスクが来たら、まずリスク、予算、並行性を判断する；
- 必要に応じていくつかのエージェントを一時的に作成し、タスクが終われば解散する；
- 中央が目標と予算を管理し、局部では動的な探索が許され、バリデーターがブレーキをかける。
例えばWebSwarmの再帰的な蜂の群れでは、エージェントは途中で自分で処理するかサブエージェントを生成するかを決定でき、組織構造は「運用中に形成されるグラフ」のようになります。しかし、動的な構造にはリスクもあります。予算がコントロールを失ったり、エラーが追跡しにくくなるため、生産システムは「自由」と「コントロール可能」の間でバランスを取る必要があります。
スタートアップへのアドバイス
「エージェントの数」にこだわらないでください。まず、ユーザーが持っている問題を明確にし、それに最適なソリューションを考えましょう。エージェントの数は単なる手段であり、目的ではありません。重要なのは、問題を効率的に解決するためのアプローチです。