CursorのAIエージェントスウォーム、SQLite再構築テストでワーカーコストが9,373ドルから411ドルに95%減少

ソースコードもインターネットアクセスもなく、835ページのドキュメントだけを頼りにデータベースエンジンをRustでゼロから再構築し、実運用の請求に載せられるほど低いコストで実行する。Cursorが2026年7月20日に結果を公開したテストでは、自律型AIエージェントの導入コストを試算するエンジニアリングチームにとって重要な知見が示された。最も注目すべきなのは、スウォームがベンチマークに合格したことではない。同等の品質の結果を得るためのワーカーモデルのコストが、構成によって9,373ドル（約153万7,000円）と411ドル（約6万7,000円）に分かれ、実行作業を担うモデルの違いだけで約22倍の開きが生じたことだ。

低コストを実現したのは、プランナーとワーカーを分離するアーキテクチャである。高価なフロンティアモデルがタスクの分解と設計判断を担い、安価で高速なモデルがその指示を実行する。Wilson Linが執筆したCursorの調査は、2世代のエージェントスウォームに同じ条件で同じ作業を与えた結果と、新システムが旧システムの実行を破綻させた7万件超のマージコンフリクトを発生させずに完了できた理由を記録している。

■プランナーとワーカーの役割分担

Cursorのアーキテクチャは、エージェントを2つの明確な役割に分けている。利用可能な中で最も高性能なフロンティアモデルで動くプランナーエージェントは、高レベルの目標を再帰的に分解し、単一のワーカーが全体の目的について推論しなくても完了できるほど限定されたサブタスクに落とし込む。より高速で安価なモデルで動くワーカーエージェントは、それらのタスクを並行して実行する。

この仕組みがコストを下げる理由は、単なる並列化ではなくコンテキストの分離にある。単一のエージェントが大規模なタスクを引き受ける場合、タスクツリー全体をたどりながら、現在の位置、ツリー内の上位タスク、全体の目標を同時にコンテキストウィンドウへ保持しなければならない。Cursorの投稿は、長時間稼働する単一エージェントが本来の目的からずれていく理由を、全体像の把握と目の前の作業への集中との間でトレードオフを強いられるためだと説明している。スウォームでは、プランナーはコードに触れず、ワーカーは計画を立てない。どちらも、もう一方の仕事に必要な認知的負荷を抱え込まずに済む。

Cursorはこの構造を、ロナルド・コースの企業理論を引き合いに出して経済学的に説明している。調整コストは作業そのものよりも速く増大するため、組織は全員が相互に連絡を取り合う形ではなく、役割と範囲を限定した単位の階層へと落ち着く。プランナーとワーカーの分割が企業の階層構造に似ているのは、企業に管理職と個々の実務担当者がいるのと同じ理由だ。実務担当者に戦略を考える能力がないからではなく、両方の仕事を1つの役割に混在させると、それぞれのパフォーマンスが低下するからである。

■秒間1,000コミットの世界

以前のCursorのブラウザ構築スウォームは、標準的なGitを使用し、ピーク時に1時間あたり約1,000コミットを記録した。新システムは、ピーク時に1秒あたり約1,000コミットに達する。人間のエンジニアリングチーム向けに設計された標準的なバージョン管理ツールは、人間の作業速度を前提とした粒度の粗いロックを使用している。エージェントの速度では、同じロックが人間のチームでは遭遇しないような障害を引き起こす。

このスループットを処理するため、Cursorは新しいバージョン管理システム（VCS）をゼロから構築した。このカスタムVCSは単なるパフォーマンス最適化ではなく、スウォームの複数の調整メカニズムを実装するレイヤーでもある。旧システムで発生した重大な障害は、いずれもバージョン管理データを通じて可視化された。

スプリットブレイン設計は、互いの作業を認識していない2つのプランナーエージェントが、コードベースの異なる部分で同じ概念を別々の方法により実装したときに発生した。旧システムによるGrok 4.5の実行では、停止されるまでに54個のRustクレートが作られ、その中には3つの異なるSQLパッケージも含まれていた。2つのプランナーがそれぞれ独立してSQLパーサーが必要だと判断するのを防ぐ仕組みがなかったためだ。新システムでは早い段階で9個のクレートに落ち着き、実行終了までその数を維持した。解決策はプロンプトにあり、プランナーには、委任する複数のサブタスクが同じ設計上の問題をそれぞれ独立して判断しないようにすることが求められた。

プランナー間の競合、すなわち2つのプランナーが互いの存在を認識しながら、同じファイルを変更し合って対立する、より難しい問題には、コンパイル時にチェックされる設計ドキュメントで対処した。エージェントが設計上の判断を共有ドキュメントに記録し、コードが関連するドキュメントへの参照をコンパイル時に保持することで、調整役のエージェントが競合するドキュメントを統合すると、その解決内容が参照を介してコードベース全体へ自動的に反映される。

複数のワーカーによる同時編集で生じたマージコンフリクトは、中立的な第三者エージェントに割り当てられた。このエージェントは、どちらか一方のアプローチを優先することなく競合を解決する。人間のエンジニアリングチームにおけるマージキューに似た仕組みだが、機械の速度で動作する。

メガファイル、すなわちエージェントの作業が不釣り合いに集中したファイルはワーカーによって検出され、コミットがブロックされる。さらに、外部の分解エージェントが起動し、巨大化したファイルを小さなモジュールへ分割する。旧システムによるGrok 4.5の実行で最も競合したファイルには1,173のエージェントが触れ、7,771件のコンフリクトが記録された。新システムでは、最も競合したファイルでもコンフリクトは合計47件だった。

硬直化、すなわち人間の監督下で作られたコードベースから学習したエージェントが、必要な場合でもコアコードを変更しようとしない問題には、意図的に既存コードを壊すことを明示的に許可して対処した。コア部分の変更が必要だと判断したエージェントは、担当範囲外であっても変更箇所を限定したパッチを作成し、その理由を説明するコメントを残せる。コンパイラが変更の影響を依存コードへ伝え、ビルドエラーに遭遇した後続のエージェントは説明を確認して自身の作業を更新する。

■レビューレンズとフィールドガイド

Cursorは実験中、複数のレビュアー構成をテストした。ワーカーの完全な実行履歴を与えられたレビュアーは、出力だけを与えられたレビュアーとは異なるエラーを発見した。その両者も、完成したコードベースだけを与えられたレビュアーとは異なるエラーを発見した。単一の視点ですべてを見つけることはできなかった。自動運転システムが相関のないセンサーの情報を組み合わせることで人間を上回る信頼性を目指すのと同様に、互いに相関しない複数のレビューレンズを組み合わせることで、単一のレビュアー方式よりも高い累積信頼性が得られた。Cursorは、レビューは監査対象の作業そのものよりも安価であるため、レビューに計算資源を使うことは費用対効果が高いと説明している。

スウォームはまた、Cursorが「フィールドガイド」と呼ぶものも維持した。これはエージェントが管理する知識フォルダで、その索引が起動時にすべてのエージェントへ与えられる。エージェントはガイドの整理を担当し、あらかじめ定められた行数の上限内で内容を管理する。モデルの重みは実行中に変化しないため、ガイドには実行のある部分で得られた意外な知見が記録され、後から作業するエージェントは、先行するエージェントが高いコストをかけて発見した近道を利用できる。これは、シロアリが設計図や中央制御なしに複雑な巣を作る際、環境を変化させることで後に続く個体の行動を導く「スティグマジー」と呼ばれる協調メカニズムを、ソフトウェア開発へ直接応用したものだ。

■SQLiteベンチマークの結果

Cursorはスウォームに対し、835ページに及ぶSQLiteマニュアルの内容全体をRustで実装するよう指示した。ソースコード、テストスイート、コンパイル済みバイナリ、インターネットアクセスは、いずれも与えられなかった。進捗は、SQLiteプロジェクトが開発した、既知の正解を持つ数百万件のクエリを含むテストスイート「sqllogictest」で評価された。スウォームには、それぞれの実行が終わるまで、このテストスイートの存在は知らされなかった。

新しい実行基盤では4つの構成が試された。プランナーとワーカーの両方にGPT-5.5を使う構成、両方にGrok 4.5を使う構成、プランナーにOpus 4.8、ワーカーにComposer 2.5を使う構成、プランナーにFable 5、ワーカーにComposer 2.5を使う構成である。4時間の打ち切り時点で、新システムの各構成は73～85%のスコアを記録した。同じモデルを使った旧システムの各構成は11～77%だった。新システムのすべての構成は最終的に100%へ到達した。旧システムによるGrok 4.5の実行は、開始から2時間を迎える前に停止された。

世代間の挙動の差は、スコアの差が示す以上に顕著だった。旧システムによるGrok 4.5の実行は、最初の2時間で約68,000件のコミットを生成した。これは新システムの約70倍のペースであり、停止されるまでに7万件を超えるマージコンフリクトを蓄積した。新システムは、4時間の実行全体を通じてコンフリクトを1,000件未満に抑えた。

コード品質の違いも同様に明確だった。Fable 5の構成では、旧システムが64,305行のエンジンコードを必要とした一方、新システムは9,908行で同じ100%の合格率を達成した。Opusの構成では、旧システムは19,013行を生成して97%に達したのに対し、新システムは4,645行で100%に達した。

ただし、ベンチマークの数値はすべてCursorによる自己申告であり、まだ独立した監査を受けていない。Cursorは事後的に不正利用の有無を調べ、エージェントがテストに通りやすい実装だけを選んでいなかったことを確認したとしている。これとは別に、Cursorの過去の調査では、Composer 2.5が標準的なベンチマーク条件と、情報を遮断したベンチマーク条件との間で20.7ポイントの差を示した。これはテストされたモデルの中で最大の開きであり、Cursorが自社モデルを使って実施した評価をどの程度重視すべきかを判断する際の関連情報となる。

■エージェントスウォームの実行コスト

正式なコスト比較は4つの構成を対象としている。Opus 4.8とComposer 2.5のハイブリッド構成は、実行全体で1,339ドル（約22万円、1ドル＝164円換算、以下同）だった。プランナーとワーカーの両方にGrok 4.5を使う構成は1,928ドル（約31万6,000円）、Fable 5とComposer 2.5のハイブリッド構成は2,234ドル（約36万6,000円）、プランナーとワーカーの両方にGPT-5.5を使う構成は10,565ドル（約173万3,000円）だった。Cursorは品質についての結論を出さない非公式な試行として、Opus 4.8だけを使う構成と、Fable 5だけを使う構成も実行した。Fable 5だけを使った場合の20,057ドル（約329万円）という金額は、公開後に広く伝わった「15倍」という比較の根拠だが、Cursorの投稿では正式なデータではなく例示として扱われている。

すべての構成に共通する傾向として、ワーカーは総トークン量の少なくとも69%、多くの場合は90%以上を占める一方、プランナーのトークンは単価が高い。OpusとComposerの構成では、Opusプランナーが生成したトークンは全体の一部にすぎなかったにもかかわらず、総コストの約3分の2を占めた。Composer 2.5で動くワーカー群は、入力100万トークンあたり0.50ドル（約82円）、出力100万トークンあたり2.50ドル（約410円）という低い単価で、残りの処理を担った。

アーキテクチャの選択が持つ経済的な価値を最も直接的に示すのが、ワーカーコストの比較だ。プランナーとワーカーの両方にGPT-5.5を使う構成では、ワーカーだけで9,373ドル（約153万7,000円）のコストがかかった。OpusとComposerのハイブリッド構成では、同等の結果を得たワーカー群全体のコストが411ドル（約6万7,000円）だった。

それでも、プランナーの品質は依然として重要だ。Fable 5プランナーが消費した計画用トークンはOpusより少なかった。Fable 5のトークン単価はOpus 4.8の約2倍だが、生成した計画用トークン数は少なかった。それにもかかわらず、ワーカーが同じ作業を終えるためにはるかに多くのトークンを必要としたため、Fableのハイブリッド構成は全体として高コストになった。説明が簡潔すぎて多くの曖昧さを未解決のまま残すプランナーは、何百ものエージェントが同時に動く中で、その曖昧さを個々のワーカーに推論させることになる。

Cursorはまた、当初GPT-5.6 Solを構成に含める予定だったものの、「ほかのモデルでは見られなかったような暴走的なスパイラル」に遭遇し、GPT-5.5へ切り替えたとしている。これは、特定のモデルと組み合わせた場合に生じるスウォームアーキテクチャ上の制約として記録されたもので、草稿には記載されていなかった。

■ワーカーモデルの実態と背景

両方のハイブリッド構成でワーカーモデルとして使われたComposer 2.5は、Cursor独自のコーディングエージェントである。料金は入力100万トークンあたり0.50ドル、出力100万トークンあたり2.50ドルで、同量の出力を生成する場合、AnthropicのClaude Opus 4.7のおよそ10分の1にあたる。標準的なコーディングタスクのベンチマークでは、Opus 4.7やGPT-5.5と同程度の性能を示す。Cursorは、北京を拠点とするAI研究機関Moonshot AIのオープンウェイトモデル「Kimi K2.5」を基盤として、継続事前学習と強化学習を行い、このモデルを構築した。

プランナーとワーカーを分ける構成のコスト効率を評価する企業や政府機関は、このモデルの出自に留意すべきである。中国の国家情報法（2017年）は、中国の組織に国家情報活動への支持、協力、支援を求めている。中国に本社を置くMoonshot AIは、この法的枠組みの下で事業を行っている。ただし、Composer 2.5のモデルウェイトはCursorの運営会社Anysphereが米国のインフラ上で保有している。CursorのAPIへ送信されたユーザーデータはMoonshotではなくAnysphereのサーバーへ送られるため、Moonshotのホスト型APIを直接利用する場合とは、データが外部へさらされる可能性が実質的に異なる。米国の議員は2026年4月、Cursor製品に含まれるKimi K2.5など、中国由来のAIモデルについて正式な調査を開始した。Cursorはその後、中国由来の基盤モデルを使わず、SpaceXのColossusインフラ上でゼロから学習する1.5兆パラメータのモデルを発表した。このモデルは、将来のリリースでKimiを基盤とするComposerを置き換えると見込まれている。

■実環境での実用性と今後の課題

Cursorは、スウォーム規模の導入が実製品に到達した例として、BunをZigからRustへ書き換えたプロジェクトを挙げている。64のエージェントインスタンスで同時に動かしたFable 5のプレリリース版が、書き換え作業の大部分を担った。11日間で100万行を超えるコードを処理し、総コストは約165,000ドル（約2,706万円）だった。これは制御されたベンチマークではなく、実在する製品で得られた実際のエンジニアリング成果である。

それでも、ベンチマークと実稼働環境との隔たりは残っている。Cursor自身の投稿が引用した2025年の調査では、実稼働環境で使われたエージェントの68%が、人間の介入までに10ステップ以下しか完了していなかった。47%は5ステップ未満だった。Cursorのアーキテクチャは、スプリットブレイン設計、メガファイルの蓄積、マージコンフリクトの連鎖といった、エージェントの実行を大規模な環境で破綻させる問題に直接対処している。ただし、自律型エージェントの反復実行と、実稼働のエンジニアリングチームが求める監督との根本的な緊張を解消できるかについて、Bunの書き換えは可能性を示しているものの、決定的な答えは出していない。

Cursorはエージェントスウォームを「確率的コンパイラ」と表現している。AIの能力が向上するたびに、エンジニアが作業する抽象度は、行単位のオートコンプリートから、ブロックまたはファイル単位のアシスタント、機能単位のエージェントへと高まってきた。スウォームでは、作業の単位が仕様そのものになる。SQLiteの実験で最も必要だったのは、より優れたモデルではなく、意図を十分に正確に記述したものだった。835ページのマニュアルが、その仕様として機能した。実稼働環境では、適切な仕様を作成することが、このアーキテクチャでは代替できない人間の主要な役割として残る。

Cursorの運営会社Anysphereは、約600億ドル（約9兆8,400億円）相当の全株式交換によりSpaceXに買収されることで合意した。規制当局の承認を条件に、取引は2026年第3四半期に完了する見込みとされている。プランナーとワーカーを分けたスウォームアーキテクチャは、現在Cursor 3を通じて法人ユーザーへ提供されている。Opus 4.8だけを使った実行で作成されたコードベースは、github.com/cursor/minisqliteで公開されている。

■注目ポイントQ&A

●プランナーとワーカーのAIエージェントスウォームは、実際にはどのようにコストを削減するのですか？

コスト削減は、単に安価なモデルを使うことではなく、コンテキストを分離することで実現します。単一のフロンティアモデルが大規模なタスク全体を処理する場合、全体の目標と行単位の実装判断をすべて同時に追跡しなければならず、コンテキストウィンドウが埋まるにつれて処理コストが高くなります。Cursorのプランナー・ワーカー構成では、フロンティアモデルはタスクの分解と重要な設計判断、つまり高度な判断が本当に必要な部分だけを担当します。フロンティアモデルのプランナーが曖昧さを解消し、明確で詳細な指示に変換すれば、安価なモデルは、自分に与えられていない情報について推論せずに計画を実行できます。ワーカーは総トークン量の69%から90%以上を占めるため、ワーカーのトークン単価が請求額に大きく影響します。Cursorの実験では、プランナーとワーカーの両方にGPT-5.5を使う構成と、Opus 4.8をプランナー、Composer 2.5をワーカーに使う構成を比較すると、同等の結果に対するワーカー群のコストが9,373ドルから411ドルへ減少しました。

●CursorのComposer 2.5は中国のAIモデルに基づいているのですか？

はい。Composer 2.5は、北京を拠点とするMoonshot AIのオープンウェイトモデル「Kimi K2.5」を基盤として構築されています。CursorはKimi K2.5を基に継続事前学習と強化学習を行いました。その結果できたのはCursorが保有するモデルであり、モデルウェイトはAnysphereが米国のインフラ上で管理しています。CursorのAPIへ送信されたユーザーデータは、MoonshotではなくAnysphereのサーバーへ送られます。中国の国家情報法は中国企業であるMoonshot AIに適用されますが、その法的義務が、Anysphereが別に保有するモデルウェイトや米国の管轄下にあるサーバーへ自動的に及ぶわけではありません。米国の議員は2026年4月、この問題について正式な調査を開始しました。Cursorはその後、中国由来の基盤モデルを使わず、SpaceXのハードウェア上でゼロから学習する1.5兆パラメータのモデルを発表しています。

●AIエージェントスウォームはソフトウェアエンジニアの代わりになりますか？

この実験で示された証拠だけでは、代わりになるとはいえません。Cursor自身の投稿は、意図の仕様化、すなわちソフトウェアが何をすべきかを正確かつ十分に網羅して記述することが、SQLiteの実行における主な制約だったとしています。835ページのSQLiteマニュアルが、その役割を果たしました。実際のエンジニアリングプロジェクトに、同等のドキュメントが用意されていることはまれです。Cursorの投稿は「この実験で不足していたもの、そして今後のソフトウェアエンジニアリングで不足すると予想されるものは、意図を適切に記述したものだ」と明記しています。投稿が引用した2025年の調査では、実稼働環境で使われたエージェントの68%に対し、10ステップ以下で人間が介入していました。スウォームアーキテクチャは、エージェントの実行を破綻させる調整上の負荷を減らしますが、何を構築すべきか、結果が正しいかを判断する人間の役割をなくすものではありません。

●CursorのようなAIエージェントスウォームを導入する上で、最大のエンジニアリングリスクは何ですか？

この記事で扱われた実験は、インターネット接続や稼働中の外部依存関係がなく、実行時間を制限し、終了後に不正利用の有無を確認するという、制御されたベンチマーク条件で行われました。実稼働環境のコードベースはさらに複雑です。別の2026年の調査では、攻撃者が関与していないにもかかわらず、AIコーディングエージェントが実稼働環境へ損害を与えたことが確認された事例が188件ありました。データベースの削除、Git履歴の破壊、クラウドリソースの消去など、知らされていなかった境界を越えて割り当てられたタスクを実行し続けたことによるものです。Cursorの調整メカニズムが対処するのは、制御されたスウォーム実行内における複数エージェントの競合であり、実稼働環境への任意のアクセスではありません。リスクが最も高くなるのは、自動化パイプラインで長時間にわたり無人で実行する場合です。そして、それこそがコスト面では魅力的に見える用途でもあります。

元記事: Cursor Agent Swarm: Worker Fleet Dropped From $9,373 to $411 in SQLite Test