エージェントを並列で走らせたとき、請求書の内訳がどうなるかを真面目に公開した例をあまり見たことがない。Cursorが7月20日に出した実験レポートは、そこに数字を入れてきた。トークンの9割以上を安いモデルが吐いているのに、金額の3分の2は少数の高いモデルが持っていく。この非対称が、マルチエージェント構成の設計そのものを規定している、という話だ。

835ページの仕様書だけを渡して、RustでSQLiteを書かせる

実験の課題設定がまず尖っている。SQLiteの公式マニュアル(835ページ)だけをエージェント群に与え、Rustで同等のデータベースエンジンを実装させる。SQLiteのソースコードもテストスイートもバイナリもインターネットも与えない。採点はsqllogictestという、SQLiteが実際に使っている数百万クエリ規模の適合テストで行う。

結果として、held-outのSQLテストスイートを100%通るエンジンが出来上がった。しかも前回の同種実験(Cursorは今年1月にエージェント群だけでWebブラウザを作らせている)と比べて、コード量が64,305行から9,908行に減っている。「同じ成果をより少ないコードで」という方向に改善したのは、正直この手のデモとしては珍しい。エージェントを増やすと普通はコードが膨れるからだ。

計画する役と、手を動かす役を分ける

新しい構成の骨格は単純で、planner(計画役)とworker(実装役)の二層ツリーになっている。plannerはフロンティアモデル、workerは安くて速いモデル。重要なのは役割の禁止事項のほうで、plannerは実装しないし、workerは計画しない。plannerのコンテキストが低レベルの実装詳細で埋まらず、workerは自分の担当する狭い一片にコンテキストを全部使える。

Cursorはこの設計理由を、企業がなぜ階層構造になるかを論じたロナルド・コースの議論に引きつけて説明している。全員が全員と喋る組織は、調整コストが仕事量より速く増えるので破綻する。エージェントでも同じことが起きる、という筋だ。比喩としては素直で、実際に旧構成が壊れた理由とも整合している。

旧構成の失敗は前回のブログに書かれていて、これが読み物として面白い。最初は共有ファイルによるロックで重複作業を防ごうとしたが、エージェントがロックを握ったまま離さない、あるいは解放を忘れる。20体動かしても実効スループットは2〜3体分に落ちた。次に楽観的並行制御(読み取りは自由、書き込みは前回読んだ時点から状態が変わっていたら失敗)に切り替えたら壊れにくくはなったが、階層がないせいでエージェント全体が「リスク回避的」になり、難しいタスクを避けて延々と空回りするようになった。誰も決めない組織そのものである。

新構成では、決定は必ずplannerが下す。加えて4つの調整装置が入っている。合意事項を書き残す設計ドキュメント(依存するコード側から参照が張られ、コンパイル時に検証される)、衝突を第三者として裁くマージ衝突アービター、肥大化したファイルを外部から分割するmegafile decomposer、そしてfield guideと呼ばれる、エージェント自身が書いて行数予算つきで管理する共有コンテキスト(起動時に自動注入される)。レビューも「全トランスクリプトを見る」「出力だけ見る」「コードベースだけ見る」と観点を変えた複数のレンズを、別々のモデルで走らせて相関を落としている。

💸 トークンの9割を占める側が、金額の3分の1しか占めない

本題のコスト構造。同じ課題を複数のモデル構成で解かせた結果、総額は構成によって桁近く変わった。

構成	総コスト
Opus 4.8 (planner) + Composer 2.5 (worker)	$1,339
GPT-5.5 単独(両役)	$10,565

Opus/Composerのハイブリッド構成では、workerであるComposerが全トークンの90%以上を生成しているのに、金額シェアはおよそ3分の1。残り3分の2は、トークン量ではごく一部しか占めないOpusのplannerが持っていく。単価差がそのまま出ている。

Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models simply have to follow it.
(フロンティアのplannerが曖昧さを潰して詳細で明示的な指示に落としてしまえば、安いモデルはそれに従うだけでいい)

この一文が実験の主張の中心だと思う。裏を返すと、モデル選択は「タスクごと」ではなく「役割ごと」に決めるべきという設計指針になる。曖昧さを潰す工程にだけ高いモデルを置き、そこから下は安いモデルで押す。自分の実務感覚とも合っていて、要件が固まりきっていない段階で安いモデルに大量に投げると、出てくるのは大量の「それっぽいが方向が違うコード」で、レビューコストが跳ね上がる。逆に指示が十分に具体的なら、モデルの賢さの差はかなり縮む。

なお、この記事を紹介したAlphaSignalの見出しは「15倍安い」と書いているが、公開されている$1,339と$10,565から出るのは約7.9倍で、15倍がどの比較を指すのかは元記事からは辿れなかった。二次情報の倍率は鵜呑みにしないほうがいい。

Gitを捨てた理由

地味だが実装的に一番引っかかったのがここで、Cursorはバージョン管理システムを自前で書き直している。エージェント群のコミット頻度がピークで毎秒約1,000に達し、Gitでは追いつかないためだ。旧構成のスループットは毎時約1,000コミット規模だったので、3桁違う。

効果は衝突数に出ている。旧構成はGrok 4.5で2時間に68,000コミットを積んで70,000件超のマージ衝突を起こしたが、新構成は4時間で衝突1,000件未満。最も競合したファイル1つで見ると7,771件から47件に落ちている。生成されたcrate数も54から9へ。テスト通過率で見ても、新構成はGrok 4.5で4時間で80%に到達した一方、旧構成は2時間持たずに発散して停止させる羽目になった。

VCSを書き直すのはやりすぎに見えるが、「全ての変更がVCSを通るので、衝突がそこで可視化され、調整機構を差し込む場所が一箇所に決まる」という設計は理にかなっている。マルチエージェントの調整問題を、エージェント間のプロトコルではなく共有ストレージ層の問題として解いた、と読むこともできる。

📌 この結果をどこまで信じるか

HNのスレッドでは、当然ながら「from scratch」に対する批判が出ている。SQLiteのソースコードは学習データにまず間違いなく入っているので、これは新規に作らせたのではなくモデルが圧縮して持っている知識を展開させただけではないか、という指摘だ。これは妥当な留保だと思う。同じ手法を、学習データに存在しない社内仕様で走らせたときに同じ数字が出る保証はない。

もう一つ、コメント欄で刺さっていたのが仕様書の話で、835ページの厳密な仕様が既に存在していたこと自体がこの実験の前提になっている。実務で難しいのは実装よりもその仕様を書くことで、しかも仕様は実行して検証できない。Cursor自身もレポートの最後で、taste と judgement と direction は人間から来たと書いている。

とはいえ、コスト構造の非対称性は実験の是非とは独立に成り立つ話だ。planner役に高いモデル、worker役に安いモデル、という切り分けは、swarmを組まない普通のエージェント運用でもそのまま効く。自分が今すぐ試すなら、まず「曖昧さを潰す1回」と「その後の実装N回」を明示的に別のモデル呼び出しに分けるところから始める。VCSを書き直すのはその後でいい。