Cursor のエージェントスウォーム実験 — 「高性能プランナー＋安価ワーカー」でコスト 1/8¶

作成日: 2026-07-22 出典 / きっかけ: Cursor（Anysphere）ブログ「Agent swarms and the new model economics」（Wilson Lin、2026-07-20）。GIGAZINE 経由（2026-07-21）で原典に当たった関連: agentic_ai_パフォーマンスエンジニアリング_整理 enterprise_bench_企業aiエージェント評価ベンチマーク_整理 block_buzz_人間とエージェントの共同ワークスペース_整理

0. 要点（3行）¶

SQLite を 835 ページのマニュアルだけから Rust で再実装させる大規模タスクで、プランナー（高性能モデル）＋ワーカー（安価モデル）の分業が単独高性能モデル比で費用約 1/8（$10,565 → $1,339）、品質は同等（テスト 100% 通過）
根拠は「境界知能（frontier intelligence）が要る瞬間は少ない — 初期分解・設計判断・トレードオフのみ。曖昧さが明確な指示に変換された後は安価モデルで足りる」。ワーカーが全トークンの 69〜90% を消費する一方、コストの約 2/3 はプランナー側
スウォームを成立させたのは調整基盤（毎秒 1,000 コミット対応のカスタム VCS・競合解決エージェント・自動生成ナレッジ「Field Guide」）。抽象化の階段は「補完=行 → モデル=ブロック → エージェント=ファイル/機能 → スウォーム=仕様そのもの」

1. 実験設計¶

タスク: SQLite の公式マニュアル（835ページ）のみを与え、Rust でデータベースを再実装。ソースコード・テストスイート・SQLite バイナリ・インターネットアクセスは一切なし
評価: SQLLogicTest（SQLite 公式のテストスイート、数百万クエリ）の通過率
構成: プランナーエージェントが目標を分割し委譲、ワーカーエージェントが実装

仕様（マニュアル835p）
   │
   ▼
[プランナー]  高性能モデル（Opus 4.8 / Fable 5）
   │  分解・設計判断・トレードオフ ← 「境界知能が要る瞬間」
   ▼
[ワーカー群]  安価・高速モデル（Composer 2.5）
   │  実装の大量トークン消費（全体の69〜90%）
   ▼
[調整基盤]  カスタムVCS・競合解決エージェント・Field Guide

2. 結果の数値¶

コスト（同等品質・テスト 100% 通過）¶

構成	費用
GPT-5.5 単独（プランナー兼ワーカー）	$10,565
Fable 5 + Composer 2.5	約 $5,000+
Opus 4.8 + Composer 2.5	$1,339（単独比約1/8）

ワーカー実行だけの比較でも、GPT-5.5 ワーカー $9,373 → Opus プランニング＋Composer 実行 $411 と報告

コード量（新旧スウォームシステム比較）¶

構成	旧システム	新システム
Fable 5 ハイブリッド	64,305 行（100%）	9,908 行（100%）
Opus 4.8 ハイブリッド	19,013 行（97%）	4,645 行（100%）

調整オーバーヘッド（Grok 4.5・2時間時点、新旧比較）¶

指標	旧	新
コミット数	68,000	1,000（約70分の1）
マージ競合	70,000+	1,000 未満
Rust クレート数	54	9

3. 何がスウォームを成立させたか（調整基盤）¶

カスタム VCS: 毎秒 1,000 コミットに耐える
分散設計の防止メカニズム: 旧システムはクレート乱立（54個）＝エージェントが勝手にモジュールを切る問題があった
中立なマージ競合解決エージェントを別途置く
Field Guide: 自動生成されるナレッジ共有（学んだ制約・決定を後続エージェントに引き継ぐ）

4. 考察（ここは自分の解釈）¶

一言でいうと「知能は設計に、物量は実装に」。トークン消費の主体（ワーカー）とコストの主体（プランナー）が逆転している構図が本質で、単価差が大きいほど分業の効きが良くなる
汎化への留保: SQLLogicTest という完全なオラクル（自動判定できる正解）がある spec-driven タスク1件での結果。仕様が曖昧・検証が人手のタスクにそのまま外挿はできない（原典もタスクは1種）
数値は Cursor 社内システム・社内価格での報告値。モデル間比較（GPT-5.5 vs Opus+Composer）はハーネス差も混ざるため、モデル優劣の証拠としては読まない方がよい
自分の運用との接続: ~/.claude の「サブエージェントは機械的タスクなら sonnet/haiku 明示」ルールはまさにこの経済性の縮小版。Workflow でのファンアウト時、finder/verifier を安いモデルに落とす設計は本実験と同じ構造（今日の PR #59 レビューでも実践）
Buzz（Block）のような「人間＋エージェント共同ワークスペース」と組み合わさると、プランナー/ワーカー分業＋監査ログが標準的なチーム構造になっていく可能性

5. まとめ — 早見表¶

状況	推奨
仕様が明確・検証が自動化できる大タスク	プランナー高性能＋ワーカー安価の分業（本実験の型）
仕様が曖昧	まず人間＋高性能モデルで仕様を固める（分解こそ境界知能の使い所）
自分の Claude Code 運用	サブエージェント委譲時に model を明示（機械的=sonnet/haiku、判断=継承）

参考リンク¶

原典: https://cursor.com/blog/agent-swarm-model-economics （日本語版: https://cursor.com/ja/blog/agent-swarm-model-economics）
GIGAZINE 紹介記事: https://gigazine.net/news/20260721-agent-swarm-model-economics/
SQLLogicTest: https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki

作成: 2026-07-22 ／最終更新: 2026-07-22