Agent Swarmとは​何か​ ──同じ​品質で​コストが​8分の​1に​なった、​AIエージェント​「分業」の​実験を​解説

AIに開発を任せるとき、費用を左右するのは「どのモデルを選ぶか」だと考えられてきました。もっと効くのは、どの仕事をどのモデルに割り当てるか——それを金額で示した実験報告が出ています。

2026年7月20日、開発ツール大手のCursorが「Agent swarms and the new model economics（エージェントの群れと、新しいモデル経済学）」という報告を公開しました^[1]。いちばん重要な数字はこれです。まったく同じ課題を、ほぼ同じ品質で解いたのに、AIの利用料金は最大で約8倍の差がついた。差を生んだのはモデルの優劣ではなく、仕事の配置でした。

この記事で分かること——①4通りのモデル構成で費用が8倍違った実測データ ②Agent Swarm（エージェントの群れ）＝設計役と作業役に分ける仕組み ③なぜ配置を変えるだけで安くなるのか ④群れが大きくなると壊れる5つの失敗 ⑤この実験をそのまま信じてはいけない理由。数値はすべてCursorの公開報告に基づくもので、CAG自身が再現検証したものではありません。

01同じ​品質、​費用は​8倍違った

Cursorが用意した課題は、かなり意地の悪いものです。SQLite（世界中で使われているデータベースソフト）を、835ページのマニュアルだけを頼りにRustというプログラミング言語でゼロから作り直す。ソースコードもテストもインターネットも見せません。出来上がったものは、SQLite公式の膨大なテスト集（数百万件の問い合わせと正解の組）で採点されます^[1]。

そこに4通りのモデル構成をぶつけた結果が、これです。

設計役 → 作業役	4時間後の正答率	費用
GPT-5.5 → GPT-5.5	約85%	$10,565
Grok 4.5 → Grok 4.5	80%	報告に記載なし
Fable 5 → Composer 2.5	100%（1時間で約73%）	Opus構成より高額
Opus 4.8 → Composer 2.5	100%	$1,339

いちばん高い構成が、いちばん低い点数でした。最良の構成は、最高性能のモデルを設計役にだけ置き、実際にコードを書く作業役には安くて速いモデルを使ったものです。

内訳を見るとさらにはっきりします。GPT-5.5で全部やった場合、作業役だけで9,373ドル。設計をOpus 4.8に、作業をComposer 2.5に任せた場合、作業役の総額は411ドルでした^[1]。

「高いモデルを使うほど良い結果が出る」という直感が、ここでは成立していません。

02Agent Swarmとは​ ──​「考える​人」と​「手を​動かす人」を​分ける

Agent Swarm（エージェントの群れ）は、名前ほど難しい仕組みではありません。役割が2つあるだけです^[1]。

役割	やること	やらないこと
Planner （設計役）	目標を受け取り、実行できる大きさまで分解して担当を割り振る	自分では手を動かさない
Worker （作業役）	割り振られた1つの小さな仕事だけを実行する	全体の計画を持たない

目標を根っこにして、枝分かれしながら細かい作業まで降りていく木のような形になります。課題が複雑なら枝は増え、単純なら枝は少ない。仕事量に応じて群れの形そのものが変わる、という設計です。

なぜ分けるのか。報告はその理由を「気が散るから」と説明しています。AIエージェントを1体で長時間動かすと、これまでの経緯・いま自分がどこにいるか・最終的な目的、この3つを同時に抱え続けることになり、だんだん軸がぶれていく（ドリフト）。分業すると、この負荷が消えます。

設計役は決して実装しないので、その頭の中が細かい実装の話で埋まることがない。作業役は計画しないので、持っている記憶のすべてを目の前の狭い仕事に使える^[1]。

人間のチームで、部長が全員分のコードを書かないのと同じ理屈です。複数のAIを束ねて動かすという発想自体は、この半年で各社が別々の入口から向かっている方向でもあります。

関連記事 ｜ 束ねる側の競争「どのモデルが最強か」はもう古い ──Sakana Fuguが見せた、AIを束ねる"司令塔"の競争 →

03なぜ配置を​変えるだけで​安くなるのか

費用が8倍変わった理由は、実はとてもシンプルです。AIの利用料金は、処理した文字量（トークン）で決まる。そして、そのトークンの大半は「作業」側で消費される。

報告によれば、どの実験でも作業役が全トークンの少なくとも69%、多くの回では90%以上を使っていました^[1]。つまり請求書の9割は「手を動かす部分」です。ここに単価の高いフロンティアモデルを置けば、そのまま総額に跳ね返る。逆にここを安いモデルに替えれば、総額はほぼそれだけで下がります。

関連記事 ｜ 料金の仕組みAIを全社に入れたら、今度は「使いすぎ」に悩み始めた ──AIエージェント時代の本当のコストは、月額ではなくトークンで決まる →

では品質はどうなるのか。報告の主張はこうです。

大きな仕事の中で、本当に最高水準の知性が必要な瞬間はごくわずかしかない。最初の分解、設計判断、いくつかのトレードオフの決断がそれにあたる。フロンティアモデルの設計役があいまいさを潰して、詳細で明示的な指示にまで落としてしまえば、あとは安価なモデルがそれに従うだけでよい^[1]。

賢さが必要なのは「何をどう作るかを決める瞬間」であって、「決まったものを書く時間」ではない。だから設計役にだけ高いモデルを置く。これが「新しいモデル経済学」と名付けられているものの中身です。

私たちがAIに任せる範囲を決めるときの基準も、近いところにあります。設計と検証には人と高性能なモデルを厚く置き、そこから先の量産は軽い構成で回す。今回の報告は、その肌感覚に金額という裏づけをくれた形でした。

04群れが​大きくなると、​壊れる

ここからが報告のいちばん実務的な部分です。エージェントを大量に並列で走らせると、人間のチームとまったく同じ問題が起きます。しかも速度が桁違いなので、被害も桁違いです。Cursorが挙げた失敗は5つ^[1]。

失敗	何が起きるか	対処
設計の分裂	複数の設計役が、同じ概念をそれぞれ別のやり方で実装してしまう	設計判断は設計役が自分で決め、同じ問いを2つの枝で決めさせない
設計役どうしの綱引き	同じファイルを互いに書き換え合い、行ったり来たりする	決定事項を共有ドキュメントに記録し、コードから参照させる。矛盾は調停役がまとめる
衝突	同じ場所を同時に触り、後から来た側が上書きするか、諦める	中立の第三者エージェントが全員の代理として衝突を解決する
巨大ファイル化	人気のあるファイルに編集が集中して肥大し、さらに衝突が増える	作業役が「太りすぎ」を報告し、別のエージェントが分割する
硬直化	中核のコードを誰も触りたがらなくなる	意図的に壊すことを許可し、理由をコメントで残して連鎖的に直させる

数字で見ると、改善の幅がわかります。同じGrok 4.5構成で、旧方式は2時間で7万件超の衝突を起こし、不安定になって2時間を待たずに停止しました。新方式は4時間動かして衝突は1,000件未満。いちばん取り合いになったファイルでも、旧方式は1,173体のエージェントが7,771回ぶつかったのに対し、新方式は47回でした^[1]。

書かれたコードの量も減っています。同じ100%到達でも、旧方式が19,013行かかったところ、新方式は4,645行。無駄な重複を書かなくなった分だけ短くなった、と説明されています^[1]。

なお、この規模を支えるためにCursorはバージョン管理システム（Git相当の仕組み）を自作しています。通常のGitのロックの取り方は「1人の開発者には十分でも、数百体が同時に働く量には耐えられない」ため、毎秒1,000コミットを捌ける独自実装を用意した、と述べています^[1]。ここは、すぐ真似できる話ではありません。

05この​実験を、​そのまま​信じてはいけない​理由

ここは正直に書いておきます。公開直後の技術者コミュニティでは、いくつか妥当な指摘が出ています^[2]。

① 課題が「作り直し」であること。SQLiteは世界中で使われている有名なソフトなので、そのソースコードはモデルの学習データにほぼ確実に含まれています。「マニュアルだけ見せた」と言っても、モデルは中身を知っている可能性がある。ゼロから新しいものを設計する力の証明にはなりません。

② 仕様書を書く手間が消えたわけではない。835ページのマニュアルがあったから群れは走れた。裏を返せば、その水準の指示が用意できない仕事には、この方式はそのまま持ち込めないということです。報告自身も、これから希少になるのは「意図を正しく記述すること」だと述べています^[1]。

③ 自分たちのコードではない。Cursorはこの実験を、エージェントが完全に所有するまっさらなコードベースで行いました。既存の事情が積み重なった実際の業務システムで同じ結果が出るかは、まだ誰も確かめていません（報告は「所有していないコードベースでは効果がもっと大きいはず」と述べていますが、これは検証済みの事実ではなく見通しです^[1]）。

④ 品質の中身は精査されていない。出来上がったコードについて、報告は「ざっと見た限りでは良く見えるが、深い手作業の分析はしていない」と明記しています^[1]。

つまりこれは「AIエージェントの群れで実際の開発が置き換わる」という証明ではなく、「役割を分ければ、費用の構造がここまで変わりうる」という実験室の測定結果として読むのが正確です。

06まとめ ──持ち帰れるのは​「配置」の​考え方

大きな仕組みを真似する必要はありません。この報告から現場に持ち帰れるのは、もっと単純な問いです。

いま使っているAIは、考える仕事と、こなす仕事を、同じ値段で処理していないか。

導入前に確かめておきたい4点

• 費用の内訳を、工程ごとに見ているか。総額ではなく「どの工程がトークンを食っているか」。9割が単純作業なら、そこを軽いモデルに替えるだけで請求書は変わります。
• 高いモデルを置くべき場所を決めているか。要件の分解、設計判断、トレードオフの決断。この3つ以外は、必ずしも最高性能を必要としません。
• 指示を、あとから読める形で残しているか。分業が成立するのは、決めたことが記録され、参照できるときだけです。口頭やチャットの流れに消える決定は、並列化した瞬間に矛盾になります。
• 成果物を突き合わせる仕組みがあるか。並列で走らせるほど、衝突と重複は増えます。誰が最終的に整合を取るのかを、先に決めておく。

Cursor自身が実験の結論として置いた一文が、この話の射程をよく表しています。これから希少になるのは、計算資源でも賢さでもなく、意図を正しく記述したものだ^[1]。