エージェント・スワームによる協調行動の限界突破：SQLite 構築実験レポート

概要と背景

今年年初に行われた実験では、エージェントのスケーリングによる協調行動の限界を検証しました。この取り組みにより、タスクの規模と複雑性を新たなレベルに引き上げることを目標としていました。

• 先行プロジェクト: 「Web ブラウザのゼロから構築」
  • 成果: コンセプト実証（PoC）としての成功は確認された。
  • 課題: 完成したソフトウェアとしては未熟な結果だった。
  • 手法: 白紙の状態から出発し、安定的かつ効果的なシステムへ**経験主義的アプローチ（山登り法）**で進化させた。

実験内容：Rust による SQLite のゼロ構築

従来のスワームが苦戦したタスクへ再挑戦し、以下のような厳格な条件下での検証を行いました。

• タスク: ドキュメントのみを頼りに Rust で SQLite をゼロから構築する。
• 提供されたリソース: なし
  • ソースコード、テストスイート、バイナリ、インターネットアクセスは一切提供されていない。
• 評価基準:

  sqllogictest

  スイートを基準に正解率を測定。 -数百万のクエリと既知の正解を用い、データベースが正しい回答を返せるかの割合で評価。

アーキテクチャ：「木」構造によるスケーリング

大規模タスクの説明は自然に**「木」**の形をとります。根にゴールを置き、再帰的に基本作業単位へ細分化します。

エージェント役割分担

役割	エージェント名	役割定義
プランナー	プランナーエージェント	最も賢いモデルを搭載。ゴールを小さな部分に分割し、委任する。
ワーカー	ワーカーエージェント	速く安価なモデルを搭載。委任された部分を実行する。

コンテキスト効率と構造利点

• 単一エージェントの限界:
  • 全体の木を辿るため、祖先ノード・現在位置・大局文脈を同時に保持する必要があり、「ブレ（迷走）」が生じやすい。
  • 目の前の作業に集中し大局を見失うか、大局を保持しつつ個別作業で劣化するジレンマに陥る。
• スワームの優位性:
  • プランナーは実装を行わず、ワーカーは計画を立てないため、コンテキストリソースが効率的に分割利用可能。
  • **「コンテキスト効率」**が高まり、並列化そのものよりも重要なパフォーマンス向上要因となる。

協調制御メカニズム：独自バージョン管理システム（VCS）

既存の Git や Cargo は数百のエージェントによる高速なコミットレートに対応できず、粗いロックに依存する限界がありました。新システムでは秒間約 1,000 コミットを処理する独自 VCS を構築しました。

故障モードへの対策

スワーム特有の失敗モードに対し、以下の解決策を実装・適用しました。

1. スプリットブレイン（Split-Brain）設計

• 問題: 互いに無自覚な 2 つのプランナーが、異なる部分で同じ概念を別々に実装しようとする。
• 対策: プロンプト設計により、プランナー自身が設計判断を行い、「同じ質問について 2 つの子ツリーが決断する」ことを禁止。

2. プランナー間の対立

• 問題: 存在を知りながら、同じファイルの上で往復の変更を繰り返す（現実認識の二重化）。
• 対策: エージェントに共有設計ドキュメントへの決定記録を命じる。コードはコンパイルチェック可能な参照を通じてそのドキュメントへ紐付ける。

3. マージ競合

• 問題: ワーカーエージェントがマージ競合処理に苦戦し、上書きや変更の手放しを起こす。
• 対策: 中立なサードパーティのエージェントを導入。衝突時に入管し、公正かつ効率的に解決を行う（工学チームの「マージキュー」の自動化版）。

4. メガファイル

• 問題: 肥大化したファイルは輸送・差分計算コストが高く、常に衝突の場となる。
• 対策: ワーカーエージェントに肥大化ファイルをフラグ付ける機能を付与。外部エージェントが介入して小さなモジュールへ分解する。

5. 骨格化（Ossification）防止

• 問題: エージェントがコアコードには触らないよう学習し、変更が停滞する。
• 対策: 「意図的な破損」を許可するライセンスを与える。有益なコア変更に対し、範囲外のフォーカスパッチを作成し、コンパイルエラーを通じて他のエージェントへ理由を伝播させる。

6. リビューレンズ（Review Lenses）

• 問題: エラーの蓄積と自己修正手段の欠如。
• 対策: 単一ではなく、多様な**「リビューレンズ」を重ねる**。
  • レビューエージェントへの入力源を変更（全トランスクリプトか出力だけかコードベースだけか）。
  • 異なる個性・トレーニングを受けたモデルをレビュアーとして採用。
  • 監査コストは低く、高品質な自己修正回路の構築に寄与。

環境形成：スティグメジー（Stigmergy）の応用

蟻や白蟻のような生物がコミュニケーションなしに協調する「スティグメジー」を、エージェントに適用しました。

• 概念: 直接的な会話ではなく、環境を形成し、それが次の個体への指示となる。
• 手法: 「メモを残す」「決断を文書化」から発展し、エージェント全体で管理される**「フィールドガイド（Field Guide）」**を採用。

  • index.md

    ファイルに起動時にすべてのエージェントへ情報を注入。
  • コンテンツ選定はエージェント自身が行う（トークン予算のみ制約）。
• 効果: モデルのパラメータが固定されているため、予期せぬ出会いを短縮する情報が重要となる。コードベースを「所有していない」状態でもこの恩恵は大きい。

実験結果：SQLite スイートの達成率

新スワームと旧スワームを比較し、以下のような劇的な差が出ました。

モデル構成ごとの成果

• Grok 4.5 を使用した場合:
  • 新システム: 4 時間で**80%**の達成率に到達。
  • 旧システム: 混乱（スパイラル）を起こし、2 時間未満で停止。

時限テストの結果比較

システム	制限時間内での達成率推移	特徴
新システム (Opus/Fable)	73% ~ 85%	安定して高いスコアを維持。
旧システム	11% ~ 77%	不安定で、一部の高スコアも低い期間を含む。

注記: Grok 4.5 の旧実行は 2 時間未満で停止したが、新構成（Opus, Fable など）はすべてスイートの**100%**を達成しました。

コストパフォーマンスの劇的改善

• Opus 4.8 / Composer 2.5 (ハイブリッド): 1,339 ドル
• GPT-5.5 (単独フルート): 10,565 ドル
• 結論: 「意図（intent）」をプランナーで明確化し、安価なモデルが実行を追従させることで、コスト削減の巨大な潜在源を発見。

詳細分析：生産性とコード質量

コミットレートと競合状況

• コミット数: 旧ハネスは最初の 2 時間で 68,000 コミット（新システムペースの約 70 倍）。多くのコミットが「繁忙作業」に過ぎなかった可能性あり。
• マージ競合: 旧システムで 70,000 件以上の競合を蓄積し加速した対照的に、新システムは 4 時間で1,000 未満の競合のみ。

コードベースの最適化

• パッケージ数: 旧実行は 54 クレート（3 つの SQL パッケージ含む）に対し、新実行は早期に 9 クレイトに収束。
• エンジンコード行数:
  • Fable 5 ミックス: 旧システム 64,305 行 → 新システム 9,908 行
  • Opus ミックス: 旧システム (スコア 97%) 19,013 行 → 新システム (スコア 100%) 4,645 行

戦略の多様性

• あるチームは広範な基礎を構築し急上昇（最終的に最高）。
• 他のチームは早期にスコアを獲得したが、後にプラトー（頭打ち）化。
• 重要: 絶対的なスコアだけでなく、トレンドの向上が重要な指標となる。

考察と結論

スペックをプロンプトとして

AI 能力の飛躍により、エンジニアリングの抽象レベルは「1 行」→「ブロック」→「ファイル/機能」→**「仕様（Spec）」**へと進化しました。

• スワームはコンパイラーのように、「意図」という高次抽象層から具体的なコードへ翻訳する役割を担います。
• プランナーがゴールを「木」として解析し、段階的に実行可能な作業へと落とし込みます。

今後の展開

• 公開リポジトリ:

  github.com/cursor/minisqlite

  （単独 Opus 4.8 の実行結果）
  • 初期レビューでは優れていますが、より深い手動分析が必要です。
• モデルの限界: GPT-5.6 Sol を frontier 構成として使用しましたが、直訳的表現に敏感になり「暴走的スパイラル」が発生しました。短期的には既存モデルとの比較が困難となり、GPT-5.5 に回帰せざるを得ませんでした。

スワームは単なる並列処理ではなく、コンテキスト効率化と高度な協調制御機構によって、複雑なタスクの解決を可能にします。