エージェント群と新しいモデル経済学

2026年7月21日原文(cursor.com)

概要

エージェントスウォーム による大規模協調の限界検証
新旧システム比較 でSQLiteをRustでゼロから構築
タスク分割・役割分担 の最適化による効率向上
バージョン管理・衝突対策 のための独自VCS開発
レビュー・知識共有 による品質維持と自己修正

エージェントスウォームによる大規模タスク協調の進化

今年初めに、 複数エージェントの協調 によるタスク遂行能力の限界を検証する実験を実施
代表的なプロジェクトは、 ゼロからWebブラウザを構築 する長期的なスウォーム
概念実証には成功したが、 実用的なソフトウェア品質には未到達
実験は 経験的アプローチ で、安定したシステムを目指して漸進的に改善
以降は、 エージェントスウォームの構造理解と意図的な設計 を目標に

SQLiteプロジェクトによる新旧スウォームの比較実験

旧スウォームが苦戦したSQLiteのRust実装 を再挑戦課題に設定
同一モデル・同一時間制限 で新旧スウォームを比較
Grok 4.5モデル利用時、新スウォームは 4時間で80%のテストスイート合格、旧スウォームは2時間未満で中断
プランナーとワーカーの役割分担 を柔軟に変更し、コストと品質のバランスを検証
全ての構成で新スウォームが旧スウォームを上回る結果

タスク分割とエージェントの役割設計

大規模タスクは ツリー構造 で分割される
- プランナーエージェント ：賢いモデルで目標を細分化し、割り当て
- ワーカーエージェント ：高速・低コストモデルで実作業を実行
問題の形状に合わせて スウォームの構造が自律的に成長
この設計により、 多様なタスクへの汎用性 を実現
社内利用例： 脆弱性発見・修正、テストカバレッジ向上、合成データ生成

メモリ効率とスウォームのスケーラビリティ

単一エージェントは全タスクを把握する必要があり、 文脈保持に限界
スウォームでは プランナーは設計に集中、ワーカーは実装に専念 でき、文脈効率が向上
この 文脈効率 こそがスケーラビリティの本質
Ronald Coaseの組織論にも類似構造

独自バージョン管理システム（VCS）の開発

既存のGit等は 数百エージェントの同時作業 に不向き
1,000コミット/秒 のスループットを支える新VCSを自社開発
変更の衝突検出や協調機構もVCS内部で実装

高速スウォーム特有の障害と対策

Split-brain設計 ：複数プランナーが同じ概念を異なる方法で実装
- プロンプト設計で回避、設計決定を一元化
プランナー間の競合 ：同一ファイルを巡る設計対立
- 設計ドキュメントと参照で解決、矛盾時はリコンサイラーが調停
マージコンフリクト ：ワーカー同士の同時編集衝突
- 第三者エージェントが中立的に解決
メガファイル問題 ：肥大化したファイルでの衝突多発
- ワーカーが肥大化を検知・フラグ、専用エージェントが分割
オシフィケーション（硬直化） ：コアコードの変更忌避
- 意図的な破壊を許可、理由説明コメントで依存箇所を誘導修正
レビュー手法 ：多様な視点・モデルによる積層的レビュー
- 複数の「レンズ」で監査し、人的品質を超える信頼性を追求

環境変化による間接協調（スティグマジー）

アリやシロアリのような 環境を介した協調 （スティグマジー）の導入
エージェント自身が 知識共有用フィールドガイド を作成・管理
モデル重みが固定されているため、 意外な発見やノウハウを蓄積
後続エージェントの効率化 に貢献

SQLite実験の詳細と評価

835ページのSQLiteマニュアルをRustで実装 するタスクを新スウォームに指示
ソースコード・テストスイート・バイナリ・インターネットアクセスは一切非公開
sqllogictest を使い、進捗を自動評価
- 数百万クエリに対する正答率を計測
各エージェントが独自戦略で構築 し、進捗曲線の傾向を分析

モデル構成ごとの結果

テストした構成例：
- GPT-5.5 （プランナー兼ワーカー）
- Grok 4.5 （プランナー兼ワーカー）
- Opus 4.8＋Composer 2.5 （ハイブリッド構成）
- Fable 5＋Composer 2.5 （次世代プランナーと効率実行）
全構成で新スウォームが旧スウォームを上回る
Fable 5ハイブリッドは 1時間で2/3合格、4時間で73〜85%
旧スウォームは 11〜77% にとどまり、Grok 4.5は2時間未満で中断
全新構成は最終的に100%合格

コミット・コンフリクト統計と考察

Grok 4.5の旧スウォームは 2時間で68,000コミット （新スウォームの約70倍ペース）
しかし 70,000超のマージコンフリクト が発生し、安定せず中断
新スウォームは 4時間で1,000未満のコンフリクト に抑制
大規模スウォーム制御の本質は、効率的な分割・協調・知識共有にあり

Hackerたちの意見

今年の初めにあったブラウザのスワームは、Gitで1時間あたり約1,000のコミットがピークだったけど、新しいシステムは1秒あたり約1,000のコミットに達してるんだ。 >この活動のペースを支えるために、ゼロから新しいバージョン管理システム（VCS）を作ったよ。スループットだけがこのレイヤーを持つ理由じゃないんだ。システム内のすべての変更はVCSを通過するから、衝突が最初に見えるのはここだし、次のセクションのいくつかの調整メカニズムも直接ここに実装されてる。ボタンを作るために宇宙を発明するって感じだね。

└

こういう引用を読むと、どうしても無限の猿定理を思い浮かべちゃうな。 https://en.wikipedia.org/wiki/Infinite_monkey_theorem

└

その時点でVCSを使う意味ってあるの？

└

正直言って、すごく妥当だと思う。VCSは人間の作業構造を助けるために作られたもので、自律的な作業を促進するように再構築するのは適切だよね。

└

高スループットなリビジョン管理システムを作るのは可能だよ。HNでもgit-in-postgresとかの実験があったし。問題は、実際のボトルネックは何かってことだね。俺はLLMを使った作業のためのVCSを作ったんだけど、それは開発中の自分のコードを使ってブートストラップしたんだ。実際、もし本当に機能しなかったら、存在すらしなかっただろうね！俺の経験では、物事を追跡して評価することがボトルネックだったから、そこに注力したんだ。実際のところ、「人間の評価とフィードバックをどう活用するか」が重要な質問だよ。Cursorの人たちは最後の投稿で「味、判断、方向性は人間から来た」と結論づけてた。数段落前の「コンパイルするな、もっと早くコミットしろ」って言葉の後に、意外と理にかなってるように聞こえたよ。

└

たぶん、彼らはChatGPTで雰囲気を楽しみながらコードを書いてたんじゃないかな。

その進捗をテストするために、古いスワームが苦労していたタスクに戻ったんだ。それは、SQLiteをゼロからRustで、ドキュメントだけを頼りに構築すること。SQLiteのソースコードはトレーニングデータに含まれてないの？

└

Rustではないね。違うかもしれないし…

└

もちろんそうだよね。

こういうクレイジーな実験が進行中なのを見るのは最高だね。たとえこれが100%うまくいかなくても、今は高コストでも、未来を垣間見るようなもので、2023年にタブ補完しかなかった頃にコーディングエージェントについて話してたのと同じ感じ。

└

そんなに高くつくことはないはずだよ。作業を小さな部分に分ければ分けるほど、理論的にはそれを完成させるモデルも小さくできるからね。だから、エージェントの群れは最先端のAPIコールである必要はなくて、小さな安いコンピュータのクラスターでホストできるんだ。組織としては、何百台もの小さなコンピュータを持つローカルサーバーに投資することが基本的にできるよ。エンジニアやフロンティアモデルを使って、タスクの細分化を計画して実行できる。で、それをローカルクラスターに流し込んで、各小さなタスクを何をするか知らずに処理させるんだ。実際の問題は中間部分だね。中レベルの抽象化のテスト、相互接続の検証、高いスピードで技術的負債を築くこと、そして自分が何を作ったのかを認識すること。アメリカや多くのグローバル市場のMBAにとって、短期的な市場の上昇しか気にしないから、AIがまだハイプサイクルの真っ只中にある今、利益重視の人には深刻な問題じゃないと思う。持続可能性やインフラに気を使う俺たちのような負け組にとってだけが本当の問題なんだよね。

└

みんなまだ慣れ親しんだおもちゃで遊んでる気がする。「LLMの内部層からもっとコードを抽出しよう！」ってね。SQLiteはもう持ってるし、彼らの「仕様」はそこから来たんだ。面白いフロンティアは別のところにある：新しい有用なものを作るためにそれをパイプラインにどう組み込むかだよ。フォローアップの投稿を書く気になったよ。http://replicated.live/blog/follow-up

Hacker Newsで議論の続きを見る

ハクソク