Cursor のエージェント群が SQLite 再構築で100%成功——プランナー・ワーカー分離で開発コスト99%削減
Cursor が発表した新型エージェント群システムは、frontier モデルがタスク計画を、安価なモデルが実行を担当する分離型アーキテクチャ。SQLite の Rust 再構築実験で全テスト成功し、Composer 2.5 ワーカー利用で従来比99%のコスト削減を実現した。開発効率と経済性を両立する新しい LLM 活用法の実証例。
AI コーディング支援ツール Cursor が、新型マルチエージェントシステムの実験結果を公開した。Frontier LLM(高性能モデル)がタスク計画を行い、安価でより軽量なモデルが具体的な実装作業を担当する「プランナー・ワーカー分離」アーキテクチャを採用。SQLite を Rust で完全に再構築する実験において、すべての新型構成が 100% のテスト成功率を達成し、従来型システムを大幅に上回るパフォーマンスを示した。
実験概要:SQLite の Rust 再構築
Cursor が実施した検証は、SQLite データベースを Rust 言語で一からコードを書き直すもの。ドキュメンテーションのみを参照でき、ソースコードやインターネットアクセスは禁止という厳格な条件下での実験だ。
テストには sqllogictest という数百万個の SQL クエリと既知の正解結果を含むベンチマークが用いられた。単なる「動作する」コードではなく、データベース仕様を完全に満たし、エッジケースまで適切に処理できる実装が求められる。
プランナー・ワーカー分離型アーキテクチャの成功
従来型の単一エージェントシステムでは、一つの AI モデルがタスク全体の進行経路を考え続ける必要があり、それに伴うコンテキストドリフト(長いタスク系列での判断品質低下)が発生しやすい。
Cursor の新システムでは、以下のように役割を分離している:
- プランナーエージェント:Frontier モデル(Claude Opus、GPT-5 など)が高度な意思決定を担当。タスクを小分けにし、各ワーカーに何をすべきかを明確に指示
- ワーカーエージェント:より軽量で低コストのモデル(Composer 2.5 など)が実行。プランナーからの指示に従い、コードの記述や既存コードの修正を行う
この分業体制により、各エージェントの処理経路(context window)を小さく保つことができ、結果として判断精度が向上するとともに、トークン消費量が最適化される。
実験結果の詳細
テスト成功率と生成コードの品質
- 新型システム(全構成):100% テスト完了率を達成
- 従来型システム:最高でも 77% の完了率にとどまる
4時間のトレーニング後の成果物(新規作成時):
- 新型構成:73~85% の成績
- 従来型構成:11~77% と大幅に遅れ
コード品質の劇的な改善
生成されたコードの大きさも顕著な改善が見られた。Frontier モデル(Opus)の場合:
- 従来型:64,305 行の エンジンコード
- 新型:9,908 行 — 約 84% の削減
それでいてテストスコアは同等かむしろ向上しており、「より少ないコードでより高い品質を実現」している。
マージコンフリクト の激減
コード生成時に最大の課題となるのがマージコンフリクト(複数エージェント修正の競合)。
- 従来型システム:2 時間で 70,000 件以上のマージコンフリクトを生成、全体で約 1,000 件のマージコンフリクトを蓄積
- 新型システム:1,000 件未満に抑制
プランナーが事前に調整を行うため、ワーカー間での修正競合が大幅に減少する。
経済性と実用性:フロンティアモデルの役割の最小化
実験の重要な発見は、Frontier モデルの使用を最小限にしても高品質が保証される ことだ。
全体のトークン消費内訳:
- ワーカー(実行層):全トークン消費の 69% 以上を占める
- プランナー(計画層):残りのトークン使用
コスト分析(SQLite 再構築一回あたり):
- 高コスト構成(Opus + Opus):$10,565
- 低コスト構成(Opus プランナー + Composer 2.5 ワーカー):$1,339
同一の品質を保ちながら、ワーカーコストを $9,373 から $411 に削減 — 実に 95% 以上の削減を実現している。
開発実務への含意
この実験結果は、AI を使った大規模ソフトウェア開発の経済学に新しい視点を提供する:
-
高度な LLM は計画と監督に:ChatGPT など Frontier モデルは実装そのものより、アーキテクチャ設計やタスク分解など、高度な意思決定に費やす方がコスト対効果が高い
-
実装作業は安価モデルで十分:Composer 2.5 のような軽量モデルでも、プランナーから適切な指示を受けることで、高品質なコード生成が可能
-
コンテキストドリフトの回避:マルチエージェント設計により、単一エージェントでは解けないような大規模タスクもスケーラブルに対応可能
業界への波及効果
この成果は、特に開発生産性ツール(IDE、GitHub Copilot、Cursor など)や、企業内の AI 導入戦略に大きな影響を与える見込みだ。これまで「Frontier モデル一択」とされていた大規模開発タスクが、複数層の LLM を組み合わせることで、より低コストで実現可能になることが実証された。
同時に、LLM ベンダー側にとっても戦略的な転機となる。Frontier モデルの差別化は「最難関タスクでの正確性」に集約され、実装系タスクでの競争力の必要性が低下する可能性がある。逆に、Composer 2.5 のような「軽量ながら品質の安定した」モデルの重要性が高まり、LLM 市場全体の構造が「計画層と実行層の分離」に向けて再編される可能性を示唆している。