2月17日、Kian Kyars氏が「building sqlite with a small swarm」と題した記事を公開した。この記事では、複数のAIエージェントを軍団(Swarm)として自律稼働させ、わずか数日でSQLite互換エンジンをRustで書き上げた実験記録について詳しく紹介されている。
以下に、その内容を紹介する。
1. 人間は「環境」を作り、AIが「コード」を書く
ソフトウェア開発を「分散システム」と見なし、人間ではなく複数のAIにコードを書かせる。Kyars氏が構築したのは、Claude、Codex、Geminiという特性の異なるAIモデル計6体を、Gitとロックファイルで統制しながら並列稼働させるシステムだ。
結果として、2026年2月10日から12日までのわずか3日間で、約19,000行のRustコードが生成された。以下のデータベースの心臓部が実装され、282個のユニットテストをすべてパスしている。
- SQLパーサ: ユーザーの入力を解析し、プログラムが理解できる構造(抽象構文木/AST)へ変換する入り口。
- B+ツリー: 大量のデータから目的のレコードを高速に探し出すための、階層的なデータ構造。
- WAL(Write-Ahead Logging): 実際のデータ更新前にログを記録し、クラッシュ時の復旧を可能にする信頼性の要。
2. AIの暴走を抑える「ハーネス(制御機構)」
単にプロンプトを投げるのではなく、AIたちが協調するための物理的な「開発インフラ」が用意された。
├── AGENT_PROMPT.md // メインのタスク指示書
├── BOOTSTRAP_PROMPT.md // 初期化用プロンプト
├── launch_agents.sh // エージェント群の起動スクリプト
├── agent_loop.sh // 各ワーカーのメインループ
└── coalesce.sh // 重複を排除するための統合スクリプト
開発は、まずClaudeがアーキテクチャ設計とスケルトンを作成する「ブートストラップ」から始まり、その後6体のエージェントが自律的にタスクを奪い合う「ワーカー・フェーズ」へと移行する。各AIは最新コードをプルし、タスクをロックして確保し、本家SQLite3を「正解(オラクル)」として照らし合わせながら実装を進める仕組みだ。
3. 実験で見えた「AI並列開発」の急所
この実験は、AIによるソフトウェア開発の未来を示すと同時に、極めて現実的な課題を浮き彫りにした。
- 「調整コスト」という名のオーバーヘッド:
全154件のコミットのうち、実に54.5%(84件)がロックの確保や解除といった「調整」に関連するものだった。AI開発においても、スループットを決定付けるのはコード生成能力ではなく、排他制御の規律である。 - テストは「抗エントロピー」の力:
AIが並列で書き散らす環境では、システムは容易に崩壊(エントロピーが増大)する。これを食い止めたのは、「高頻度なテスト cadence(ケイデンス)」であった。1行書くたびにテストを回すような「一定のリズム」を維持することで、常に正常な状態を担保し続けた。 - ドキュメントは「ランタイム」の一部:
進捗を管理するPROGRESS.mdは、単なる読み物ではなく、AIたちが衝突を避けるための「共有メモリ」として機能した。「何が完了し(DONE)、何に着手中か(DOING)」をリアルタイムに更新し続けることで、AI軍団は迷子にならずに走りきることができた。
4. 成功を決定づけた「3つの設計思想」
Kyars氏がこの実験で最も重視したのは、AIに「何をさせるか」よりも、「どのような境界条件で働かせるか」というメタ設計だ。以下の3点が、複利的な開発速度を生んだ。
① 明確なモジュール境界:変更の波及を遮断する
DBMSのような複雑なシステムでは、一箇所の修正が全体を壊すリスクがある。Kyars氏は「パーサ」「ストレージエンジン」「インデックス」などの境界を厳格に定義した。
- 技術的意義: AI(ワーカー)は自分の担当するモジュールのインターフェース(API)さえ守れば、内部実装を自由に最適化できる。これにより、複数のAIが互いの足を引っ張り合うことなく、並列で機能を積み上げることが可能になった。
② 共通の真実(Shared Truth):AI間の認識同期
AIは個別に推論を行うため、時間が経つと設計思想が「微修正の繰り返し」でズレていく。これを防いだのが、共有ドキュメントという名のステート(状態)管理だ。
- 技術的意義:
PROGRESS.mdや共有の設計図を「最新かつ唯一の正解」としてAIに常時参照させる。これにより、人間が指示を飛ばさずとも、AI同士が「次に自分が埋めるべきパズルのピース」を自律的に判断できる環境が整った。
③ 高速なフィードバック:修正ループの最短化
AI開発において最大の敵は「待ち時間」だ。Kyars氏は、コード生成からコンパイル、SQLite3との比較テスト、エラー出力のフィードバックまでを完全に自動化した。
- 技術的意義: AIが誤ったコードを生成しても、数秒以内にテスト結果(スタックトレースや期待値との差分)が返される。この「ミリ秒単位の試行錯誤」の積み重ねが、人間には不可能な速度でのバグ修正とリファクタリングを実現した。
5. 開発規模のスナップショット
3日間という短期間で積み上げられた成果物の内訳は以下の通りである。
| 言語 | ファイル数 | 総行数 | 実コード行数(空白・コメント除外) |
|---|---|---|---|
| Rust | 14 | 18,650 | ~16,155 |
| Shell | 1 | 199 | ~139 |
| 合計 | 15 | 18,849 | ~16,294 |
6. 課題と今後の展望
Kyars氏は、今回の手法の限界についても言及している。APIのレートリミットによる作業の中断や、膨大なドキュメント量にAI(特に統合用のGemini)が圧倒され、処理が停止する場面も見られた。
CodexとClaudeのAPI使用状況。エージェントごとに負荷の偏りが見られる。
しかし、エージェントに正しい「アーキテクチャの規律」を与えれば、複雑なシステムコードであっても、複利的な速度で構築できることが証明された。
詳細は building sqlite with a small swarm を参照していただきたい。