CursorのSQLite Rust実験から学べること

하이라이트

• GPT-5.5のみで構成したエージェントシステムでのRust製SQLite実装コストは約10,000ドルに達したが、Opus 4.8（計画担当）とComposer 2.5（実装担当）を組み合わせることで同等品質をわずか1,300ドルで達成した。

• 秒間約1,000コミットという並列エージェントの極端な書き込みスループットに対応するため、Gitの粗いロック処理を排した専用のバージョン管理システムが新しく構築された。

• 複数エージェントが同一ファイルを過剰に肥大化させるメガファイル問題に対しては、肥大化を検知して新規コミットをブロックし、専用のリファクタリングエージェントが小モジュールへ分解する設計が効果を発揮した。

• エージェントが既存のコアコード破壊を極度に恐れてコードを無駄に重複・肥大化させる現象（Ossification）は、明確に破壊やクリーンアップの権限をプロンプトで与えることで解決された。

• 単一のレビューではバグを見落としやすいため、トランスクリプト・出力・コードベースのみなど異なるコンテキストとペルソナを持つ複数の「レビューレンズ」を積層運用することがシステムの信頼性を高める。

타임라인

1. 00:00 - 04:43

   実験の目的とモデル構成によるコスト最適化

   実用目的の製品開発ではなく、高度なマルチエージェントスウォームの構築可能性を探る検証として行われた。仕様が明確に定義されていれば、実装を担当するワーカーエージェントには最先端の高額モデルを使用する必要はなく、適切な計画立案用モデルと安価な実装用モデルを組み合わせることでコストを約8割削減できる。

   • mini SQLite実験の真の目的は、ドキュメントのみから仕様通りのデータベースを構築できるエージェントシステムの設計検証である。
   • 835ページに及ぶSQLite仕様書とSQLogicTestを用いて、異なるモデル組み合わせによる実装品質とコストを比較した。
   • 全エージェントをGPT-5.5にした場合は約10,000ドルかかったのに対し、Opus 4.8とComposer 2.5のハイブリッド構成では1,300ドルで同等のテスト通過数を記録した。
2. 04:43 - 07:58

   マルチエージェント設計の基本構造と役割分離

   すべての作業を単一の指示で実行させるのではなく、全体設計、実装、評価という専門化されたノードへ分解する。タスク定義を明確にし、ワーカーエージェントにクリーンなコンテキストを提供することが、エラー率の低下とコード品質の維持につながる。

   • タスクをプランナー、ワーカー、レビュアーの別々のエージェントに分割するアプローチが極めて有効である。
   • ワーカーには広範なコンテキストではなく、明確に仕様化された作業定義と周囲のコード構造のみを与えることで高いコード出力を得られる。
   • 単純なバグ修正は単一エージェントで十分だが、複雑なプロジェクトでは専用役割の並列配置とコンテキストの分離が不可欠となる。
3. 07:58 - 10:48

   秒間1,000コミットを処理する専用バージョン管理システム

   旧来のスウォーム実験では1時間あたり1,000コミットであったが、新システムは秒間1,000コミットに達した。Gitのロジックでは高並行書き込みを制御できないため、衝突を直接可視化し、システム内で自動調停ロジックを走らせる土台として新VCSの自作が必要となった。

   • ピーク時に1秒あたり約1,000コミットを生成する超並列スウォームでは、従来のGitによる粗い排他ロックがボトルネックとなる。
   • 高スループット化だけでなく、ファイル書き込みの衝突を早期検知してエージェント側で調停するために専用のVCSが新しく作られた。
   • 人間用のツールは数百のエージェントが同一リポジトリで同時に競合・変更を加えるスケールに対応できない。
4. 10:48 - 14:23

   スプリットブレイン問題とプランナー間の競合解決

   並行して動くプランナーがコードベースの別々の場所で同じロジックを再実装してしまう現象に対し、プロンプティングによるタスク切り分けの厳格化が効力を発揮した。また、設計が矛盾した場合はリコンサイラーが共有ドキュメントを統合し、ダウンストリームのコードへコンパイル時チェック参照を通じて決定事項を反映させる仕組みを採用した。

   • 互いを認識しない複数のプランナーが同じ概念を異なる場所で重複実装する「スプリットブレイン設計問題」が発生した。
   • 重複防止は新機能の追加ではなく、ツリー構造のタスク委任時に重複決定を下さないプロンプト指示によって解決された。
   • プランナー同士の設計対立に対しては、共有設計ドキュメントと調停役（リコンサイラー）エージェントを介して解決策を伝播させた。
5. 14:23 - 18:32

   マージコンフリクトの調停とクリーンコンテキストの重要性

   エージェントは自らのタスクを優先するあまり、未コミットの他者変更や人間による変更を上書きする傾向がある。これに対処するため、それまでのコンテキストを持たない中立な調停エージェントを投入し、双方の変更内容を客観的に精査してコンフリクトを解決させる手法がとられた。

   • ワーカーエージェントは他者の変更を上書きするか自身の変更を破棄しやすく、マージコンフリクトの直接解消が苦手である。
   • 衝突の解消には、偏見のない第三者エージェントがマージキューのように介入して修正案を提示する調停メカニズムが有効である。
   • 自身の実装ログを持つエージェントは自己成果物にバイアスを持つため、フレッシュなコンテキストを持つ独立エージェントでの評価が必要となる。
6. 18:32 - 23:22

   メガファイル対策とコード硬化（Ossification）の克服

   エージェントにはファイル構造全体を綺麗に保つインセンティブがないため、特定ファイルにテストやロジックが追記され続けてパフォーマンスが低下する。また、本番環境破壊を避けるモデルの安全訓練により既存コードの削除をためらう傾向があるため、モジュール分解を行う専用エージェントや、破壊的修正の明示的許可がコードベースの健全化に寄与した。

   • エージェントが同一ファイルにコードを追記し続けることで肥大化するメガファイルは、転送やマージコストの低減を阻害する。
   • 肥大化ファイルにフラグを立てて新規コミットを止め、別エージェントが小さなモジュールへ解体する仕組みでコード肥大化を防いだ。
   • モデルの学習傾向による「コアコードの破壊回避（硬化）」には、プロンプトで明示的なコード削除やリファクタリングの権限を与える必要がある。
7. 23:22 - 32:17

   積層型レビューシステムと実戦的な応用

   レビューコストは開発コストより遥かに安いため、異なるペルソナを持つレビュアーを重ね合わせることで自動運転並みの高信頼性を確保した。ただし、SQLite実験のような完璧な仕様書やテストが存在しない一般的な新規開発では、反復的な仕様変更が避けられないため、今回の手法をそのまま適用することは難しく、人間のシステムアーキテクトによる設計とオーケストレーションが引き続き不可欠である。

   • 実行ログ、出力結果、コード単体など、異なる視点を持たせた複数の「レビューレンズ」を組み合わせることで欠陥検知率を向上させた。
   • 本実験の成功は、完璧な完全仕様書とテストスイートが存在していたという前提条件に大きく依存している。
   • 人間エンジニアの役割は、個別のコード記述からシステム全体のエージェント構築やアーキテクチャ設計という「システム思考」へ移行しつつある。