GitHubは2026年11月5日、新しいGitストレージアーキテクチャ「Project Rubicon（プロジェクト・ルビコン）」の技術詳細を公開しました。社内テストでは5,000の並行エージェントが単一リポジトリで作業し、毎秒7,200プッシュを処理しながら、読み取りトラフィックも低レイテンシで提供できたとしています。この発表はGitHub Universeで示された新ストレージ構想の核心部分にあたります。
室谷代表取締役GitHubの新Gitストレージ「Project Rubicon」は、GitHubが2026年11月5日に公開した新しいGitストレージアーキテクチャで、数千のAIエージェントが単一リポジトリへ同時に書き込めるようにする基盤なんですよね。社内テストで5,000の並行エージェント、毎秒7,200プッシュを処理したという数字がまず目に入ります。
テキトー教師DotAI 認定講師単に「GitHubが速くなりました」という話じゃないんですよ。これはエージェント型開発を前提に、Gitのストレージの設計そのものを作り直したという発表です。
GitHubはこれを「業界が越えてしまった転換点（point of no return）」への対応と位置づけていて、そこからRubiconという名前が来ています。
GitHubはこれを「業界が越えてしまった転換点（point of no return）」への対応と位置づけていて、そこからRubiconという名前が来ています。
GitHubの新Gitストレージアーキテクチャとは？何が発表されたのか
まとめ
GitHub「Project Rubicon」発表内容
- 新Gitストレージアーキテクチャの名称は「Project Rubicon」
- 背景: 99.99999%のリポジトリはAzureへ移行済みで、残る最も混雑した0.00001%が課題
- データセンターとAzure間の約25ミリ秒の往復が書き込み上限を決めていた
- 社内テストで5,000の並行エージェントが単一リポジトリで作業
- 毎秒7,200プッシュを処理し、その間も読み取りを低レイテンシで提供
- 設計原則は「調整を最小化」「ストレージとコンピュートの分離」
- データはAzure Blob Storageに保存
- 開発者から見たGitの使い方(push/fetch/branch/保護の仕組み)は従来通り
- リクエストは従来通りSpokesが受けてルーティングと負荷分散を担い、データプレーンだけが新しくなった
室谷代表取締役まず前提を整理したいんですけど、GitHubは2026年10月21日の記事で、GitHub上の99.99999%のリポジトリをAzureへ移したと説明しています。その上で、残りの最も混雑しているリポジトリをどう扱うかが課題として残っていました。
テキトー教師DotAI 認定講師そうなんです。残った0.00001%は「最も忙しいリポジトリ」で、データセンターとAzureの間の約25ミリ秒の往復が書き込みの上限を決めてしまっていた。
そこで設計を変えたのが今回のRubiconです。発表された内容を箇条書きで整理するとこうです。
そこで設計を変えたのが今回のRubiconです。発表された内容を箇条書きで整理するとこうです。
- 新Gitストレージアーキテクチャの名称は「Project Rubicon」
- 社内テストで5,000の並行エージェントが単一リポジトリで作業
- 毎秒7,200プッシュを処理
- その間も読み取りトラフィックを一貫して低レイテンシで提供
- 設計原則は「調整を最小化」「ストレージとコンピュートの分離」
- データはAzure Blob Storageに保存
- 開発者から見たGitの使い方は従来通り
室谷代表取締役ここで大事なのは、開発者が使うGitの操作自体は変わらないという点です。pushもfetchもbranchも同じで、保護の仕組みもそのまま。
裏側のデータプレーンだけが新しくなった、というのがGitHubの説明なんですよね。
裏側のデータプレーンだけが新しくなった、というのがGitHubの説明なんですよね。
テキトー教師DotAI 認定講師そこは受講生さんからもよく質問が出るところです。「新しいアーキテクチャになったら自分のワークフローは変わるのか」と。
GitHubの公式説明では、GitクライアントやAPI、Web UIからのリクエストは従来通りSpokesが受けてルーティングと負荷分散を担い、その下のデータプレーンが新しくなったという構造です。
GitHubの公式説明では、GitクライアントやAPI、Web UIからのリクエストは従来通りSpokesが受けてルーティングと負荷分散を担い、その下のデータプレーンが新しくなったという構造です。
Project Rubiconの核心：不変パックと可変参照の分離が意味すること
まとめ
不変パックと可変参照の分離が意味すること
- Gitオブジェクト（パックデータ）は不変で内容により名前が決まる → 同時保存に合意不要
- リファレンス更新だけが合意（クォーラム）を必要とする
- リファレンス更新はオブジェクト格納に比べて非常に小さい
- 結果として、データ保存・リクエスト処理・リポジトリ維持という従来は密結合だった部分を独立にスケールできる
- リファレンス＝ブランチやタグなど特定のコミットを指す名前。整合性要件はリファレンス単位で適用され、異なるブランチへの書き込みは本来依存し合わない
室谷代表取締役Rubiconの核心は、Gitの書き込みのうち「合意が必要な部分はごくわずか」という観察から始まっているんですよね。Gitのオブジェクトは不変で、内容によって名前が決まる。
だから2人の書き手が何も合意しなくても同時に保存できる。
だから2人の書き手が何も合意しなくても同時に保存できる。
テキトー教師DotAI 認定講師単に「速くした」という話じゃなくて、Gitの性質を突き詰めた結果なんですよ。pushのうち合意が必要なのはリファレンスの更新だけで、それ以外のオブジェクト格納は調整不要。
この分離が設計の出発点になっています。
この分離が設計の出発点になっています。
室谷代表取締役リファレンスというのはブランチやタグなど、特定のコミットを指す名前のことです。Gitの整合性要件はリファレンス単位で適用される。
つまり、異なるブランチへの書き込みは本来依存し合わないわけです。
つまり、異なるブランチへの書き込みは本来依存し合わないわけです。
テキトー教師DotAI 認定講師ここを整理するとこうです。
- Gitオブジェクト（パックデータ）は不変で内容により名前が決まる → 同時保存に合意不要
- リファレンス更新だけが合意（クォーラム）を必要とする
- リファレンス更新はオブジェクト格納に比べて非常に小さい
- 結果として、データ保存・リクエスト処理・リポジトリ維持という従来は密結合だった部分を独立にスケールできる
室谷代表取締役MYUUUでも複数の作業を並行で回すことが増えてきたので、この「調整を最小化する」という設計思想はすごく実感があります。エージェントは待ち時間がそのまま生産性のロスになるので、コミット遅延を最小化するという要件は現場感覚とも合うんですよね。
なぜ5,000の並行エージェントと毎秒7,200プッシュが可能になったのか
書き込みクォーラムのスコープ変更前後
従来
- リポジトリ全体でロックを取得
- 書き込みを直列化
- 最も遅い正常レプリカが全書き込みのレイテンシを決める
- 単一ノード構成でコンピュート律速になりやすい
変更後
- クォーラムのスコープを個々のリファレンスへ
- 同じリファレンスを触る書き込みだけが待ち合う
- 異なるリファレンスへの書き込みは互いに待たない
- 複数書き込みノードへ処理を分散
- 内部テストで異なるリファレンスへの書き込みが3〜4倍のスループットを低レイテンシで実現
テキトー教師DotAI 認定講師ここが一番質問の多いところです。なぜ数千のエージェントが同時に単一リポジトリへpushできるのか。
カギは書き込みのクォーラムの範囲を変えたことです。
カギは書き込みのクォーラムの範囲を変えたことです。
室谷代表取締役従来はリポジトリ全体でロックを取って書き込みを直列化していた。だから最も遅い正常なレプリカが全書き込みのレイテンシを決めてしまっていたんですよね。
これをリポジトリ全体から個々のリファレンスへスコープを変えた、と。
これをリポジトリ全体から個々のリファレンスへスコープを変えた、と。
テキトー教師DotAI 認定講師そうすると、同じリファレンスを触る書き込みだけが待ち合えばよくなる。実際には多くの書き込みは異なるリファレンスを触る、たとえばエージェントや開発者がそれぞれ自分のブランチへpushするケースです。
これらが互いに待たなくなる。
これらが互いに待たなくなる。
室谷代表取締役GitHubの説明では、実トラフィックに近い内部テストで、異なるリファレンスへの書き込みが3〜4倍のスループットを低いレイテンシで実現したとされています。ここは数字として押さえておきたいところです。
テキトー教師DotAI 認定講師もう一つ、複数の書き込みノードをサポートした点も重要です。GitHubは、受信パックのインデックス作成とオブジェクトの接続性チェックが書き込みの中で最もCPUコストが高く、書き込みサイズに比例してコストが増えるため、単一ノードではすぐにコンピュート律速になると説明しています。
室谷代表取締役だから書き込み処理を多数のノードに分散する。障害耐性も上がるし、ノード障害時の復旧も早くなる。
エージェントが24時間並列で動く世界では、この耐障害性は地味だけど効いてくる部分ですよね。
エージェントが24時間並列で動く世界では、この耐障害性は地味だけど効いてくる部分ですよね。
テキトー教師DotAI 認定講師さらに、エージェントは各pushの完了を待って次の作業に進むので、コミット遅延の最小化が必須要件になっています。加えて各pushはCI実行やデプロイ、他エージェントの取得を誘発して読み取りが増幅する。
だから読み取りを安く保つことも要件に入っているんです。
だから読み取りを安く保つことも要件に入っているんです。
従来のGitストレージと何が変わったか——書き込みロックとレイテンシの課題
室谷代表取締役従来との違いを整理すると、まず負荷の性質が変わったという前提があります。これまで最も混雑するリポジトリでも書き込みは1秒あたり数十件、しかも短いバースト程度だった。
それがエージェントの並列・常時稼働で持続的な高負荷になると予測したわけです。
それがエージェントの並列・常時稼働で持続的な高負荷になると予測したわけです。
テキトー教師DotAI 認定講師従来の構造的な課題は3つに整理できます。
- 書き込みがリポジトリ全体のロックで直列化され、単一の待ち行列になっていた
- 最も遅い正常レプリカが全書き込みのレイテンシを決めていた
- 読み取りと書き込みが同じレプリカを奪い合い、独立にスケールできなかった
室谷代表取締役特に3つ目は大きいですよね。GitHubの説明では、多くのリポジトリは読み取りが書き込みの100〜1,000倍と極端に読み取り偏重。
なのに読み書きが同じリソースを奪い合っていた。
なのに読み書きが同じリソースを奪い合っていた。
テキトー教師DotAI 認定講師リポジトリ全体ロックのまま参照更新の往復を含めて保持すると、クォーラムが実質「一度に1書き込みしか通さない順序なしの待ち行列」になる。書き込みレートが上がるほど行列が伸びて、各書き込みの待ち時間が前より長くなる。
これは構造的な問題なんですよ。
これは構造的な問題なんですよ。
室谷代表取締役これをリファレンス単位の直列化に変えると、共有リファレンスで競合する書き込みだけが待てばよくなる。異なるリファレンスへの書き込みは同時に飛行できる。
GitHubはこれを「不要なものを直列化しない」という調整最小化の原則の具体例として説明しています。
GitHubはこれを「不要なものを直列化しない」という調整最小化の原則の具体例として説明しています。
テキトー教師DotAI 認定講師書き込みスループットの上限は、同時に書き込まれるリファレンスの数にほぼ比例して上がる。だから数千のエージェントがそれぞれ別ブランチへpushするようなワークロードで効いてくる、という設計です。
読み取りと書き込みの独立スケールとデータ安全性の仕組み
室谷代表取締役次は読み取り側です。リポジトリのデータがAzure Blob Storageに永続保存され、書き込みごとに更新されるようになると、読み取りトラフィックを書き込みのクォーラムから切り離して独立にスケールできるようになる、と。
テキトー教師DotAI 認定講師ストレージとコンピュートの分離ですね。GitHubは、読み取りは今よりはるかに多くのインメモリキャッシュがあると有利だが、そのメモリは書き込み側でも必要になる、というトレードオフに触れています。
室谷代表取締役仮想レプリカという考え方も面白いですよね。仮想レプリカは自分では永続状態を持たず、遅れている仮想レプリカはリクエスト処理に必要なデータだけをダウンロードして追いつく。
だから読み取りを安く保てる、と。
だから読み取りを安く保てる、と。
テキトー教師DotAI 認定講師データ安全性の面では、各リファレンスの変更を順序付けて記録し、リファレンス間を素早く線形化できる能力が要件に入っています。サーバーがあるリファレンスの更新を受け入れたら、クライアントはそれより古い値を見てはいけない、その値かより新しい値だけを見る。
これはfast-forwardでもforce pushでもdeleteでも同じです。
これはfast-forwardでもforce pushでもdeleteでも同じです。
室谷代表取締役整合性の保証はリファレンス単位で維持したまま、異なるリファレンスの並行性を上げた、というのが正確な理解なんですよね。速さのために正しさを犠牲にしたわけではない、と。
テキトー教師DotAI 認定講師そこは受講生さんにも強調しているところです。GitHubは正確性・耐久性・可用性・レイテンシの保証を保ちながらスループットを最大化する設計を選んだ、と説明しています。
レプリカは多くのリポジトリで5つ持ち、耐久性・可用性・スケールのバランスを取っているという話もあります。
レプリカは多くのリポジトリで5つ持ち、耐久性・可用性・スケールのバランスを取っているという話もあります。
室谷代表取締役移行の途中経過も興味深いですよね。多くのリポジトリで5つのレプリカのうち2つがAzureにあり、Gitトラフィックの約半分をAzureが処理している。
Spokesは同じリージョンとアベイラビリティゾーンのレプリカへ優先的にルーティングして読み取りレイテンシを抑える、という説明でした。
Spokesは同じリージョンとアベイラビリティゾーンのレプリカへ優先的にルーティングして読み取りレイテンシを抑える、という説明でした。
提供状況と今後の展開——日本でいつ使えるようになるのか
室谷代表取締役ここが読者にとって一番気になるところだと思うんですけど、提供状況についてはどうでしょうか。
テキトー教師DotAI 認定講師今回の公式ブログとXの投稿で確認できるのは、社内テストで5,000並行エージェント・毎秒7,200プッシュを実現したという結果と、アーキテクチャの技術的な説明までです。一般提供の開始時期や、日本を含む各リージョンでの提供スケジュールについては、現時点では明らかにされていません。
室谷代表取締役記事の位置づけとしては、GitHub Universeで発表した新ストレージ構想の技術詳細をエンジニアリングブログで解説したもの、という理解でよさそうです。すでにGitHubの内部で動かしながら作り替えている、というのがGitHubの説明なんですよね。
テキトー教師DotAI 認定講師そうですね。「GitHubを動かしたままその下を作り替えてきた」という表現が公式記事にあります。
移行は段階的で、まずデータをAzureへ移し、その後にアーキテクチャを進化させるという順序を取ったと説明されています。
移行は段階的で、まずデータをAzureへ移し、その後にアーキテクチャを進化させるという順序を取ったと説明されています。
室谷代表取締役開発者から見るとGitの使い方は従来通りなので、仮に自分のリポジトリが新しい基盤に移っても、ワークフローを変える必要はなさそうだというのがポイントです。少なくともGitHubの説明上は、push・fetch・branchの使い方も保護の仕組みも同じとされています。
テキトー教師DotAI 認定講師料金やプランへの影響、Git LFSなど既存の大容量ファイル対応との関係については、今回の公式資料では言及が確認できません。ここは憶測で書かない方がいい部分です。
現時点では明らかにされていない、と伝えるのが正確ですね。
現時点では明らかにされていない、と伝えるのが正確ですね。
室谷代表取締役エージェント前提の開発が当たり前になると、リポジトリの混雑の性質そのものが変わる。GitHubが「次の一歩ではなく2桁以上のスケールを目標にした」と言っているのは、まさにその先を見ているわけですよね。
テキトー教師DotAI 認定講師教育の現場でも、AIエージェントにコードを書かせる演習が増えています。そこでボトルネックになるのがコミットの待ち時間とCIの誘発による読み取り増幅。
今回の設計は、そうした現場の困りごとがそのままアーキテクチャの要件になっているのがよく分かる事例です。
今回の設計は、そうした現場の困りごとがそのままアーキテクチャの要件になっているのがよく分かる事例です。
よくある質問
室谷代表取締役ここまでの話を踏まえて、よく聞かれそうな点をまとめておきましょうか。
テキトー教師DotAI 認定講師そうですね。まず「Project Rubiconとは何か」という点。
これはGitHubが2026年11月5日に技術詳細を公開した新しいGitストレージアーキテクチャで、数千のエージェントが単一リポジトリへ同時に書き込めるようにする基盤です。
これはGitHubが2026年11月5日に技術詳細を公開した新しいGitストレージアーキテクチャで、数千のエージェントが単一リポジトリへ同時に書き込めるようにする基盤です。
室谷代表取締役「5,000並行エージェント・毎秒7,200プッシュという数字は本番環境の実績なのか」という疑問もありますよね。これはGitHubの説明では社内テストの結果です。
実トラフィックに近い内部テストで、異なるリファレンスへの書き込みが3〜4倍のスループット、低レイテンシになったとも説明されています。
実トラフィックに近い内部テストで、異なるリファレンスへの書き込みが3〜4倍のスループット、低レイテンシになったとも説明されています。
テキトー教師DotAI 認定講師「不変パックと可変参照の分離とは何か」も定番の質問です。Gitオブジェクトは不変で内容により名前が決まるため合意不要で同時保存でき、合意が必要なのはリファレンス更新だけ。
だからリファレンス単位でクォーラムを取る設計にした、というのが答えです。
だからリファレンス単位でクォーラムを取る設計にした、というのが答えです。
室谷代表取締役「自分のリポジトリやワークフローは変わるのか」という点は、GitHubの説明上はGitの使い方が従来通りとされています。pushやfetch、branchの方法も保護の仕組みも同じです。
テキトー教師DotAI 認定講師「いつから使えるのか」については、一般提供の時期や日本での提供スケジュールは現時点では明らかにされていません。公式資料で確認できるのは、GitHubが自社サービスを動かしながら段階的に移行を進めているという状況までです。
室谷代表取締役「データの安全性はどうなるのか」という質問にも触れておきたいですね。GitHubは、リファレンス単位の整合性要件を維持し、正確性・耐久性・可用性・レイテンシの保証を保つ設計を選んだと説明しています。
速さと引き換えに整合性を緩めたわけではない、というのが公式の立場です。
速さと引き換えに整合性を緩めたわけではない、というのが公式の立場です。
テキトー教師DotAI 認定講師最後に「Git LFSとの関係は」という点ですが、これは今回の公式資料では言及が確認できません。分からないことは分からないと伝えるのが、速報記事として誠実な姿勢だと思います。
室谷代表取締役エージェントが当たり前にコードを書く時代のインフラは、人間だけを前提にした設計の延長では限界が来る。GitHubのRubiconは、その限界を設計レベルで突破しようとする動きとして見ておくと、今後の展開が追いやすくなるんですよね。
