5,000のAIエージェントが同じGitを使うとき。GitHub「Rubicon」の設計思想

AIエージェントが何十本もの枝で同時にコードを書き、変更を次々と送る。そんな開発を支える場所は、AIモデルだけではない。コードを受け取り、ほかのエージェントに読ませるGitの基盤も、仕事量の変化に直面している。GitHubは11月5日、新しいGitストレージ設計「Project Rubicon」の仕組みを公表した。

同じリポジトリに、5,000のエージェント

GitHubによると、社内試験では単一リポジトリで5,000のエージェントを並行稼働させ、毎秒7,200回のpushを処理した。これは実運用の平均値ではなく、新設計の能力を確かめるためのテスト結果だ。同社が現在の繁忙リポジトリで観測する書き込みは、瞬間的に毎秒数十回程度という。見据えているのは、人間の作業が集中する短いピークではなく、エージェントの更新が昼夜続く状態である。

書き込みが増えると、読み込みも増える。pushを受けたCIがコードを取得し、デプロイが始まり、別のエージェントが新しい状態を取り込む。GitHubが示した一つのリポジトリでは、日々のリクエストが2026年3月の平均約4,400万件から5月には約1億8,100万件に増えた。ただし、これは特定の事例であり、全リポジトリの伸びを示す数字ではない。

合意が必要なのは「どこを指すか」

Rubiconの要点は、Gitのデータを二つに分けたことだ。コミットなどのオブジェクトは内容で識別され、いったん保存すれば書き換えない。一方、ブランチが最新のどのコミットを指すかという「参照」は更新される。複数の書き手が同じ参照を動かすときだけ、更新順序を決めなければならない。

そこでGitHubは、データ本体をAzure Blob Storageに置き、参照と保存済みデータの一覧を専用の複製ログ「Ref-CAS」で管理する。更新を受ける仮想レプリカはデータを先に保存し、その後で参照を確定する。エージェントが別々のブランチで働くなら、互いの更新を待つ場面を減らせる。読み込み側は参照の版が変わったかを先に確かめ、変化がなければ大きなデータを取り直さない。

書き込みのたびに増えるデータの束は、別の処理ノードが背後でまとめる。更新を受ける計算資源を、整理作業に奪われにくくするためだ。利用者のGit操作は従来どおりで、変更の競合やレビューまで自動で解決する仕組みではない。

開発の「待ち時間」が設計課題になる

この発表が示す変化は、コードを書く速さだけを上げても、開発全体は速くならないということだ。pushの確定を待つ時間、次の状態を取得する通信量、CIとレビューの処理能力が、並行作業の上限を決める。日本の開発チームでも、複数エージェントを使うなら、ブランチの分け方や統合時の責任を設計する必要がある。

GitHubは今後、リポジトリ全体を複製せず必要なファイルだけで作業する方法や、複数ファイルの変更を一度に確定するAPIも検討している。これらは今回の性能試験で実証された機能ではなく、今後の計画だ。Rubiconが問いかけるのは、AIの成果物をどれだけ速く生むかに加え、それを安全に受け取り、共有し、人が判断できる流れをどう作るかである。

出典：GitHub Engineering「Inside GitHub’s new Git storage architecture」