大規模AIプロジェクトで「高性能な計画役＋安価な実行役」を使うとコストが約8分の1になったとCursorが報告

AI向けコードエディター「Cursor」を開発するAnysphereが2026年7月20日、大規模な開発作業を複数のAIエージェントに分担させる実験結果を公開しました。計画役に最も高性能なAIモデルを割り当てて実際の作業には高速で安価なモデルを使っても、すべての役割に高性能モデルを使った場合とほぼ同じ品質を保ちながら費用を大幅に削減できたとのことです。

エージェントスウォームと新しいモデルの経済性 · Cursor
https://cursor.com/ja/blog/agent-swarm-model-economics

1人の開発者が全体設計を考えながらログイン機能や検索機能を順番に実装すると、細かな作業に集中するほど当初の目的を見失いやすくなります。長時間動作する単独のAIエージェントにも同じ問題があり、プロジェクトの目的や過去の判断、関連コードを同時に扱ううちに、処理できる情報量の上限へ近づきます。

単独のAIが抱える情報量を減らすため、Cursorは複数のAIへ作業を分担させる「エージェントスウォーム」を開発しました。大きな目標を階層的に分解し、計画を担当する「プランナーエージェント」と、実装を担当する「ワーカーエージェント」に作業を割り振る仕組みです。プランナーはコードを直接書かず、目標の整理や作業範囲の決定に集中します。ワーカーは割り当てられた狭い範囲だけを処理するため、各AIが参照する情報量を抑えられるというわけです。

ただし旧版のエージェントスウォームでは、複数のプランナーが同じ機能を別々の方針で設計したり、ワーカーが互いの変更を上書きしたりする問題が発生しました。単独のAIが全作業を抱える問題は軽減できたものの、多数のAIによる設計判断や変更内容を十分に調整できませんでした。

旧版で見つかった課題を踏まえ、Cursorはエージェント同士の協調方法を見直した新版を開発しました。新版では設計判断を共有文書へ記録し、変更が衝突した場合は当事者ではないAIが調整します。変更が1つの巨大なファイルに集中した場合は新しい書き込みを止め、別のAIがファイルを分割する仕組みも導入。独自のバージョン管理システムや複数のレビュー役も追加され、旧版より重複作業や競合が起きにくくなっています。

Cursorは新版を検証するため、835ページのSQLiteマニュアルをAIに与え、データベース管理システムをRustで再構築させました。SQLiteのソースコード、テストスイート、実行ファイル、インターネット接続を与えない条件で、新版で試したすべてのモデル構成が最終的に評価用テストを100％通過したと報告されています。

以下はプランナーとしてOpus 4.8を使用し、ワーカーとしてComposer 2.5を使用した構成。灰色が旧版のスウォームでオレンジ色が新版です。新版のほうが評価用テストの通過率を早く高めていることが分かります。

さらに新版の実験では、プランナーとワーカーの両方にGPT-5.5を使う構成や、両方にGrok 4.5を使う構成に加え、プランナーにOpus 4.8またはFable 5を使い、ワーカーにComposer 2.5を使う構成が比較されました。

以下はモデル選択に応じて費用がどれくらい変化するかを表した図。プランナーのコストが灰色、ワーカーのコストがオレンジ色で示されています。プランナーとワーカーの両方にGPT-5.5を使った構成は1万565ドル(約170万円)でしたが、プランナーにOpus 4.8、ワーカーにComposer 2.5を使った構成は1339ドル(約22万円)と費用を約8分の1に抑えることができたとのこと。なお、「*」付きの構成は費用確認のために非公式に実行されたものです。

費用差が大きくなる理由は、実装を担当するワーカーが大半のトークンを消費するためとのこと。下図ではワーカーが消費したトークンがオレンジ色、プランナーが消費したトークンが灰色で示されています。各実験ではワーカーが全トークンの少なくとも69％を使い、多くの構成では90％を超えました。

費用差は大きいものの、比較したモデル構成では最終的な出力品質はほぼ同等だったとのこと。最先端モデルが最初の作業分解や設計判断を担えば、低コストなモデルは明確な指示に沿って作業できます。

Cursorは今後、プランナーとワーカーの組み合わせをさらに検証すると述べています。