GitHubがGit基盤を刷新、エージェント開発時代の書き込み性能を35倍に
GitHubが稼働を止めずにGit基盤を再構築している。AIエージェントがコードを書き、コミットし、レビューするエージェント開発が、次のアーキテクチャシフトを引き起こしているからだ。
2026年9月だけで、GitHub上で作られたコミットは73.8億回に達した。前年同期と比べると5倍超だ。月間のGitイベント総数も4733億件まで増えている。
現行のアーキテクチャでは、読み取りの拡張と書き込みの耐久性が同じディスクコピーに依存している。GitHubはこの2つを分離する新アーキテクチャを構築し、内部ベンチマークで書き込みスループットを最大35倍まで高めた。本記事では、その設計原則と移行方針を解説する。
エージェント開発が生む爆発的な負荷
日常的なリポジトリと最も負荷の高いリポジトリの差は、想像以上に大きい。GitHub Blogの記事によれば、2026年8月時点で最も忙しいリポジトリは、1か月で約10億回のリクエストを受けていた。
月間4733億イベントという規模
リポジトリのアクティビティ分布を見ると、高い負荷が一握りのリポジトリに集中している。GitHub全体のGitアクティビティは2025年9月から2026年8月にかけて、月間2182億イベントから4733億イベントへと2倍以上に増加した。
Gitアクティビティが1年で2倍超に増えた推移を示している。
2026年9月のコミット数73.8億回というのは、従来の人間中心の開発ペースでは説明できない成長速度だ。リポジトリ内でエージェントと開発者が同時並行で作業する時代に入ったことを示している。
書き込みが読み取りより難しい理由
読み取りの拡張は比較的容易だ。キャッシュやレプリカを追加し、同じデータをより多くのクライアントに配ればよい。一方で書き込みは桁違いに難しい。GitHubのプリンシパルソフトウェアエンジニアであるBrian Celenza氏は、すべてのプッシュを永続的に保存し、次のエージェントやCIジョブが積み上げられる前に一貫性を保って可視化する必要があると指摘する。
書き込みは単なる負荷の問題ではなく、正しさの問題を含む。エージェントが並行して作業するリポジトリでは、この両立こそが核心になる。
現行アーキテクチャの仕組みと限界
Spokesと5台のファイルサーバー
現在のGitHubは、Spokesという保存システムですべてのリポジトリを管理している。Spokesとは、リポジトリの完全コピーを複数のファイルサーバーのローカルディスクに保持する仕組みで、デフォルトでは5台に保存する。高速なローカルディスクによりGit操作は低レイテンシーでデータを読み取れる。
複数のコピーは冗長性を担保しながら、読み取りを複数のファイルサーバーに分散させている。プッシュによって参照が更新されると、3相コミットプロトコルが動作する。これは複数サーバー間でデータの一貫性を保つ合意形成の手順で、過半数の合意（クォーラム）を取ってから反映する仕組みだ。CIやWeb UI、APIクライアントから見て、常に一貫したリポジトリ状態が見える。この組み合わせで、現時点で10億のリポジトリを支えている。
レプリカ追加が書き込みを遅くする構造
ここに構造的な課題がある。耐久性の仕組みとスケールの仕組みが同じディスクコピーに依存していることだ。ディスク上のコピーが真実の源なので、読み取り容量を増やすには耐久レプリカを追加するしかない。
ところが、すべてのレプリカはすべての書き込みに参加する。プッシュはレプリカセットの中で最も遅いものに合わせて完了する。つまり、読み取り負荷を吸収するためにレプリカを追加すると、書き込みが遅くなるのだ。
耐久性と読み取りの分離が書き込み性能に直結することを示している。
大多数のリポジトリではこのトレードオフは問題にならない。しかし、最も活発なリポジトリでは天井になる。レプリカを追加すれば書き込みのオーバーヘッドが増え、レプリカを失えば読み取り容量が減り、クォーラムを失えば書き込みが完全に止まる。この状況はエージェント時代の負荷には耐えられない。
新アーキテクチャの設計原則
GitHubは世界のコードが止まるメンテナンスウィンドウなしに、再構築を進めている。新アーキテクチャは2つの原則を中心に据えている。
耐久性とスケールの分離
第1の原則は、耐久ストレージと読み取り層の分離だ。従来は完全コピーが両方を兼ねていた。分離すれば、書き込みを確実に保存する層と、Gitリクエストに応答する層をそれぞれ独立に拡張できる。
これは、読み取り容量を増やすたびに書き込みが遅くなるという現行のトレードオフを断ち切る設計変更である。読み取りは需要に応じて横に広げ、書き込みは耐久性を保ったまま高速化できる。
必要な協調だけを残す
第2の原則は、Gitの意味論が要求する協調だけを残し、それ以外を独立して動作させることだ。多くのプッシュを受け取るリポジトリは、更新を素早く受け付けて公開しなければならない。協調は正しさを守る上で価値があるが、多すぎると書き込みスループットを制限し、忙しいリポジトリをボトルネックに変える。
協調を最小限に絞る2つの原則を整理したものだ。
現行アーキテクチャは、結合する必要のない場所まで密結合している。新設計では、Gitの意味論に必要な合意形成だけを残し、読み書きの経路を分離してスループットを引き上げる。
ベンチマーク結果と今後の展望
書き込みスループット35倍の意味
新アーキテクチャは、最高のスループットと信頼性を提供するよう設計されている。読み取りと書き込みは独立に拡張でき、障害からは優雅に回復する。内部ベンチマークでは、書き込みスループットが最大35倍まで向上した。読み取り容量も需要に応じて単独で拡張できる。
35倍という数字は、現行のレプリカモデルでは到達できない領域だ。エージェントが並行して作業するリポジトリでは、書き込みの頻度と同時実行性が飛躍的に高まる。GitHubはこの基盤を、オープンソースコミュニティとエンタープライズの双方に提供するとしている。
既存のコントロールをどう残すか
アーキテクチャを変えても、既存の管理機能は維持される。メンテナはブランチ保護と必須レビューを使い、未レビューの変更がデフォルトブランチに入らないようにできる。セキュリティチームは監査ログとリポジトリの可視性を使って、不審なアクセスを調査できる。オンコール担当者は、デプロイ失敗の原因を追える自動化と可観測性に頼れる。
この点は重要だ。スケールを優先してガバナンスを失えば、信頼は崩れる。GitHubはエージェント時代の負荷に対応しつつ、これまでチームが運用してきた制御を維持すると明言している。次回のシリーズ記事では、将来アーキテクチャとそこに至る過程をより深く掘り下げるとしている。
この記事のポイント
- GitHubは稼働を止めずにGit基盤を再構築している
- 2026年9月のコミット数は73.8億回で、前年同期比5倍超
- 現行のSpokesは耐久性と読み取りの両方を同じディスクコピーが担うため、レプリカ追加が書き込みを遅くする
- 新アーキテクチャは耐久ストレージと読み取り層を分離し、書き込みスループットを最大35倍に高めた
- ブランチ保護や監査ログなど既存のコントロールは維持される
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験