今年前半、私たちはエージェントを協調させて目標に向かわせるスケーリングの限界を試す実験を行いました。仮説は、これによってタスクの規模と複雑度における新たな段階が開かれる、というものでした。

その中心となったプロジェクトは、ブラウザをゼロから構築する長時間稼働のスウォームでした。概念実証としては成功したものの、完成度の高い本ソフトウェアにはほど遠いものでした。

この取り組みは、意図的に実証重視で進めたものでした。私たちは白紙の状態から出発し、安定して効果的なシステムへと段階的に改善を重ねました。それ以来の目標は、エージェントスウォームを十分に理解し、意図して設計できるようにすることでした。

その進歩を確かめるため、私たちは旧来のスウォームが苦戦したタスクに再び取り組みました。ドキュメントだけを頼りに、RustでSQLiteをゼロから構築することです。

初期結果は有望でした。私たちは旧世代と新世代のスウォームを同じタスク、同じモデル、同じ時間予算で実行し、非公開のSQLテストスイートのどれだけをパスできるかを測定しました。

新しいスウォームは、すべての構成で旧来より良い結果を出しました。Grok 4.5では4時間で80%に到達した一方、旧来のスウォームは迷走し、2時間目に入る前に停止せざるを得ませんでした。

また、どのモデルにどの役割を担わせるかも変えてみました。ある実行では1つのモデルがすべてを担当し、別の実行では最先端モデルが計画を立て、高速で低コストなモデルが作業を担いました。どの構成でも品質はほぼ同じでしたが、コストには非常に大きな差がありました。¹

#木と葉

大きなタスクの説明は、自然と木の形をとります。根にある目標が再帰的に分割され、基本的な作業単位へと落とし込まれていくのです。私たちのスウォームには 2 つのロールがあり、どちらもこの木構造に沿った分解を軸に構成されています。

• 最も高性能なモデルを使うプランナーエージェントは、目標を複数の要素に分割し、それぞれを割り振ります。
• 一般に、より高速で低コストなモデルを使うワーカーエージェントは、それらの要素を実行します。

このデザインは、より厳格なオーケストレーションシステムを包摂するものです。問題に固定のトポロジーを押しつけるのではなく、スウォームの形は問題の輪郭に沿って広がり、計算資源とコンテキストはタスクの複雑度に応じてスケールします。

私たちは、これこそがこのデザインが ブラウザを構築すること、数学の問題を解くこと、GPU kernel を最適化すること といった多様なタスクに一般化できる理由だと考えています。実際に社内でもこれを使って、オープンソースソフトウェアの脆弱性を見つけて修正したり、自社コードベースのテストカバレッジを高めたり、数十億トークン規模の合成学習データを生成したりしています。

#ツリーがメモリにおいて果たす役割

1つのエージェントがタスク全体を引き受けると、自分だけでツリー全体をたどり、各リーフへ降りていく必要があります。その間ずっと、祖先ノード、現在位置、そしてより大きな目標をコンテキストに保持し続けなければなりません。

私たちは、これが長時間動き続ける単独のエージェントが次第にぶれていく理由を説明していると考えています。目の前の作業に集中すれば全体像を見失い、全体像を保とうとすれば目の前の部分での出来が悪くなってしまうのです。

スウォームでは、プランナーは実装を行わないため、コンテキストが低レベルの詳細で埋まることはありません。また、ワーカーは計画を立てないため、コンテキスト全体を1つの狭い作業に集中できます。

私たちは、エージェントスウォームをスケールできるのは、並列性そのものよりも、このコンテキスト効率によるところが大きいのではないかと考えています。この効率は、どの規模のスウォームでも発揮されます。だからこそ、この分解は中規模のタスクであってもエージェントのパフォーマンス向上に役立ちます。

この構造には、ほかの領域にも通じるものがあります。経済学者のロナルド・コースは、なぜそもそも企業が存在するのかを問い、調整コストは仕事そのものよりも速く増大するため、組織は誰もが誰とでも話す形にはならず、境界のある単位の階層へと落ち着くのだと論じました。

#エージェントのためのバージョン管理システム

以前の スウォーム に関する記事でも触れたように、Git や Cargo のようなツールは、並行性制御に大まかなロックを用いています。これは開発者1人であれば問題ありませんが、数百のエージェントが同時並行で生み出す作業量には対応できません。

今年前半の browser スウォーム は、Git 上でピーク時に1時間あたり約1,000コミットを記録しました。新しいシステムでは、ピーク時で1秒あたり約1,000コミットに達します。

この規模の活動量を支えるため、私たちは新しいバージョン管理システム (VCS) をゼロから構築しました。このレイヤーを自前で持つ理由は、スループットだけではありません。システム内のすべての変更は VCS を通るため、衝突が最初に表面化するのもここであり、次のセクションで説明するいくつかの調整メカニズムも、その内部に直接実装されています。

#1秒あたり1,000コミットで起こる破綻パターン

人間のエンジニアリングチームには、コードレビュー、責任範囲、スタンドアップ、マージキューといった標準的な連携の仕組みがあります。こうした仕組みは人間のペースでは機能しますが、スウォームのコミット速度では、人間のチームが普段はまず遭遇しないような破綻パターンが現れます。

#スプリットブレイン設計

互いの存在を認識していない2人のプランナーが、コードベースの別々の箇所で、同じ概念をそれぞれ異なる方法で実装してしまうことがあります。

これはプロンプトの工夫によって解決しました。プランナーはデザイン上の判断を委任せず自ら行い、さらに委任した2つのサブツリーが同じ問題について別々に判断しないよう徹底させています。

#プランナー間の競合

さらに厄介なのは、2人のプランナーが互いの存在を認識しながら、同じファイルをめぐって変更の応酬を繰り返すような競合です。

問題は、食い違う2つの現実認識が存在することであり、マージツールではその不一致は解消できません。そこで、エージェントは共有のデザインドキュメントに意思決定を記録します。ある決定に依存するコードには、そのドキュメントへのコンパイル時に検証される参照が付けられます。プランナー同士が気づかないうちに矛盾した場合は、調整役がドキュメントを統合し、その解決内容が参照を通じて下流に伝播します。

#マージ競合

スウォーム内では、エージェント同士が常に同じファイルでぶつかります。この衝突を解消するには、いったん処理を止めて相手のエージェントのコンテキストを取り込み、それを踏まえてマージする必要があります。ワーカーエージェントはこれが苦手で、実際には相手の変更を上書きしてしまうか、自分の変更を破棄してしまいます。

これに対処するため、私たちは中立な第三者エージェントがマージ競合に介入し、関係するすべての当事者に代わって解消する仕組みを作りました。その唯一の目的は、公平かつ効率的に処理することです。これは、エンジニアリングチームでマージキューが機能する仕組みに似ています。

#メガファイル

中には、エージェントの作業先として特に集中しやすいファイルがあります。各エージェントが追加するコードは少量でも、ファイルを小さいまま保つ責任を負う単一のエージェントはいません。

こうした「メガファイル」は、あらゆる処理の足を引っ張ります。転送や diff、マージのコストが高く、常に競合が発生する温床にもなります。

これを解決するために、私たちはワーカーエージェントが肥大化したファイルにフラグを立てられる仕組みを導入しました。フラグが立つと新しいコミットはブロックされ、外部のエージェントがその肥大化したファイルをより小さなモジュールに分解します。

#硬直化

エージェントは、人間が都度介在する既存のコードベースで作業する中で、変更が必要な場合でもコアコードには手を入れないことを学習してきました。

これを解決するために、私たちは意図的な破壊的変更を認めます。コアの変更に価値があると判断したエージェントは、自身のスコープ外であっても的を絞ったパッチを加え、なぜそうしたのかを説明するコメントを残せます。

コンパイラがその変更の影響をシステム全体に伝播させるため、古い設計に依存しているものはすべてビルドに失敗します。そうしたエラーに当たった各エージェントは、そのコメントを見つけて理由を読み、それに合わせて自分の担当部分を更新します。

#レビューの観点

長時間動作し、かつマルチエージェントで構成されるシステムでは、エラーは蓄積していきます。小さなミスが根本的な問題になる前に、システム全体が自ら修正できる仕組みが必要です。

私たちはさまざまな種類のレビューの観点を試しました。たとえば、レビューエージェントに ワーカー の完全な transcript を与える場合や、その output だけを与える場合、あるいは コードベース 以外は何も与えない場合です。さらに、異なるモデルで動作し、異なる学習を受け、異なる個性を持つレビュアーも試しました。

どれか1つの観点ですべてを見つけられるわけではありませんが、相関の低い観点を重ね合わせることで、完全なコンポーネントが1つもなくても、自動運転システムが人間を上回る信頼性に到達するのと同じように、高い効果が得られます。レビューに費やす compute は、非常に高い return をもたらします。レビューのコストは、それが監査する Work よりはるかに低いからです。私たちは、この積み重ね型のレビューシステムが、実行の品質を継続的に高く保つうえで大きく貢献していたと考えています。

#エージェントが環境を形作る

Stigmergy とは、アリやシロアリのような群生生物が、直接コミュニケーションを取らずに協調する仕組みです。彼らが環境を形作り、その環境が次の個体の行動を形作ります。

以前の実行では、「メモを残す」「判断を文書化する」といったルールを組み込んでいました。そうしたルールが明らかに有益だと思えたからです。振り返ってみると、これはエージェントが将来の自分やチームメイトのために知識を蓄積し、共有できるようにしていたのです。

私たちはこれをさらに発展させ、Field Guide と呼ぶ、エージェント自身が作成する共有コンテキストの実験を行いました。これは完全にエージェントが管理するフォルダで、index.md は開始時にすべてのエージェントに自動で注入されます。ガイドに何を載せるかを取捨選択するのはエージェントの役割であり、唯一の制約は行数の上限だけです。

このガイドの根底にある考え方は、モデルの重みは固定されているため、記録する価値があるのはまさに予想外の出来事であり、それによって次のエージェントの軌跡を短くできる、というものです。

Field Guide は、有望な結果を示している初期段階の実験です。エージェントが完全には把握していないコードベースでは、その効果はさらに大きくなると考えられます。後続のためにモデルが書くよう学習させ、よりよく記録できるほどよりよい報酬につながるようにすることは、興味深い今後の研究領域です。

#SQLite の実験

上記のすべての改善を取り入れたスウォームの新バージョンに、835ページにおよぶ SQLite マニュアル全体を Rust で実装するよう指示しました。ソースコード、テストスイート、SQLite バイナリ、インターネットアクセスは与えませんでした。

進捗の測定には、sqllogictest を基準に使いました。これは、同じクエリに対して異なるデータベースエンジンが同じ結果を返すことを確認するために、SQLite プロジェクトが作成したテストスイートです。既知の正解を持つ何百万ものクエリが含まれており、評価はスウォームのデータベースがそのうちどれだけ正しく答えられたかの割合で表されます。進捗は、1回の実行の中で上昇していく曲線として現れます。

スウォーム には、そのテストスイートの存在は一切伝えていませんでした。各実行の後には毎回、コードと実行内容そのものを人手でレビューし、不正やショートカットがないかを確認するとともに、テストで見られる部分だけでなく、システム全体がまんべんなく構築されていることを確かめました。

これらの曲線を見る際は、エージェントがそれぞれ独自に戦略を選んでいたことを念頭に置いてください。広く土台を築くことを優先し、終盤で急伸するまで何時間も低いスコアのままだったものもあれば、1つの領域を深く掘り下げて早い段階でスコアを伸ばし、その後は残りを埋めながら横ばいになったものもありました。重要なのは、特定の時点での正確なスコアよりも全体の傾向です。

#モデル構成ごとの結果

機能とコストの幅をカバーする4つの設定をテストしました。

1. GPT-5.5 をプランナーとワーカーの両方に使用。 全体を通して強力な最先端モデルです。²
2. Grok 4.5 をプランナーとワーカーの両方に使用。 比較対象として用いた、コスト効率に優れた最先端モデルです。
3. Opus 4.8 をプランナー、Composer 2.5 をワーカーに使用。 最先端レベルの判断力と効率的な実行を組み合わせています。
4. Fable 5 をプランナー、Composer 2.5 をワーカーに使用。 1段上のプランナーによって、このハイブリッドの価値が高まるのか下がるのかを確認するためです。

新しいハーネスは、すべての構成で旧ハーネスを上回りました。

Fable 5 のハイブリッドは、最初の1時間でスイートの約3分の2をクリアしました。4時間の打ち切り時点では、新しく実行したものは73%〜85%、旧バージョンで実行したものは11%〜77%でした。

旧ハーネスで Grok 4.5 を実行したものは、2時間に達する前に一時停止されました (詳細は後述) 。新しい設定はすべて、最終的にスイートの100%をクリアしました。

今後は、プランナーとワーカーの組み合わせについて N×N の完全なマトリクスを実行したいと考えています。今回のサイクルで重要なのはハーネスのバージョン間の比較であり、挙動の違いはスコア差から受ける印象よりもはるかに大きいことが分かりました。

#実行内容の詳細分析

まず最もシンプルな activity の指標を見ると、旧ハーネスと新しいハーネスで、Grok 4.5 のコミットの発生ペースがどのように変化したかがわかります。旧実行では最初の 2 時間で 68,000 件のコミットが発生しており、新実行のおよそ 70 倍のペースでした。

これを、より生産的だったと捉えることもできます。一方で、それらのコミットの大半は無駄な作業 (thrash、競合、churn) だったという見方もできます。

マージ競合のデータは、後者の解釈を裏づけています。旧実行では、一時停止するまでに 70,000 件を超える競合が蓄積し、安定するどころかさらに加速していきました。一方、新実行で記録された競合は、4 時間全体を通して 1,000 件未満でした。

競合は、ファイルサイズが最も大きくなった箇所に集中していました。旧実行では、最大級のファイルが実行全体を通して増え続け、最も競合が集中した単一のファイルでは 7,771 件の競合が発生し、1,173 の異なるエージェントがそのファイルに触れていました。新実行では、コードベース全体で最も競合したファイルでも 47 件でした。

旧スウォームにおける最大の調整上の failure、つまりスプリットブレイン — プランナー同士が互いに作業を重複させること — は、パッケージ構造に表れていました。Rust の code は crates と呼ばれるパッケージ単位で構成されており、このような project では各 crate が概ね 1 つの主要なコンポーネントに相当します。

旧実行は 54 個の crates まで拡大し、その中には別々の SQL パッケージが 3 つ含まれていました。新実行は早い段階で 9 個の crates に落ち着き、その後は 1 つも追加されませんでした。

こうした違いはすべて、最終的なコードベースに表れています。Fable 5 構成では、旧スウォームも新スウォームも最終的には完全な suite を通過しましたが、旧スウォームは 64,305 行の engine code を必要としたのに対し、新スウォームは 9,908 行でそれを達成しました。Opus 構成でも同様の傾向が見られ、旧ハーネスでは 19,013 行で 97% の評価、新ハーネスでは 4,645 行で 100% でした。

#モデルの経済性

冒頭でも述べたように、どのモデル構成でも品質はほぼ同等でしたが、コストには非常に大きな差があり、Opus 4.8 ハイブリッド では $1,339、GPT-5.5単独では$10,565 に達しました。トークンのデータを見ると、その差がどこから生まれているのかが分かります。

支出の構造はどの実行でも一貫しており、ワーカー が少なくとも 69% のトークンを占め、多くのケースでは 90% を超えていました。

ただし、プランナー のトークンは単価が高いため、費用の内訳はトークンの内訳とは異なっていました。Opus 4.8 と Composer 2.5 の組み合わせでは、プランナー としての Opus が生成したトークンはごく一部だったにもかかわらず、コストの約 3 分の 2 を占めていました。一方、ワーカー としての Composer はトークンの大半を処理しつつ、コストは残りの 3 分の 1 に収まっていました。

大規模なタスクで本当に frontier intelligence が必要になる場面は、最初の分解やデザイン上の判断、一部のトレードオフなど、ごく限られています。いったん frontier プランナー が曖昧さを詳細で明確な instruction に落とし込めば、より低コストなモデルはそれに従うだけで済みます。これは、コスト削減の大きな可能性を持つポイントです。プランナー と ワーカー の両方に GPT-5.5 を使った実行では、ワーカー だけで $9,373のコストがかかりました。これに対して、計画をOpus4.8が担い、作業をComposer2.5が担った実行では、ワーカー群全体のコストは$411 でした。

注目すべき点がもう 1 つあります。これは、2 つの ハイブリッド 実行を比較すると見えてきます。Fable 5 プランナー は、トークン単価がおよそ 2 倍だったにもかかわらず、planning tokens の使用量が大幅に少なかったため、Opus 4.8 プランナー より請求額はわずかに小さくなりました。しかし、Fable 実行の ワーカー はその数倍のトークンを消費し、実行全体ではかなり高コストになりました。

#プロンプトとしての仕様

AIの機能が飛躍するたびに、エンジニアが取り組める抽象度の水準は引き上げられてきました。

Autocompleteによって、エンジニアはコードを1行ずつ扱えるようになりました。初期のモデルはそれをコードの1ブロックまで引き上げ、エージェントはさらに、1つのファイルや1つの機能の単位まで引き上げました。

スウォームでは、仕事の単位が仕様になります。

それを機能させるには、スウォームが実際に仕様に従わなければなりません。本記事の大部分は、まさにその点について述べています。私たちはスウォームに835ページ分の文章を与えましたが、返ってきたのはデータベースでした。この実験で希少だったもの、そして今後のソフトウェアエンジニアリングで希少になると私たちが考えているものは、意図を適切に記述することです。

このように見ると、スウォームはコンパイラに似たものに見えてきます。コンパイラは、一連の中間段階を通じてソースコードをマシンコードへと変換します。スウォームは意図に対して、これと似たことを行います。プランナーは目標をタスクツリーとして解析し、それを段階的に実行可能な作業へと落とし込んでいきます。違いは、コンパイラが各段階で意味を保持するのに対し、スウォームは各段階で確率的だということです。本記事で説明するものはすべて、この隔たりを埋めるために存在します。

ぜひスウォームの出力を見てみてください。単独のOpus 4.8実行で生成されたコードベースは、github.com/cursor/minisqlite で公開されています。最初にざっと見た限りでは非常に良さそうですが、私たちはまだ踏み込んだ手作業での分析は行っていません。ぜひご自身の目で確認し、見つけたことを教えてください。