同じ開発プロジェクトで、複数人やAIが別々の変更をほぼ同時に送る場面を考えてみよう。変更を受け取る側は、保存を確定させ、次に作業する人がその結果を矛盾なく読めるようにする必要がある。GitHubは、AIエージェントの利用に伴う通信量の増加を、Gitの保存基盤を見直す背景に挙げている。2026年10月21日（UTC）に公開した技術記事では、特に忙しいリポジトリを移す際に残った課題を説明した。
ほぼ全てを複製しても、移行は終わっていない
リポジトリは、プログラムのファイルと変更履歴を保管する場所だ。GitHubによると、過去1年で全リポジトリの99.99999％が、自社のデータセンターとクラウド基盤のAzureの両方に置かれるようになった。ここでの数字はリポジトリの数の割合であり、書き込み件数や処理負荷の割合ではない。
残る0.00001％には、GitHub上でも特に忙しいリポジトリが含まれる。GitHubは、それらをAzureにも移す妨げとして、拠点間で通信が往復するのにかかる25ミリ秒を挙げた。「ほぼ全て」という数字から移行全体が完了したと読むと、この少数に集中する課題を見落とす。GitHubの説明では、複製を新しい拠点へ運びながら、そこで処理する要求を段階的に増やしていく。
25ミリ秒が響くのは、変更を確定する処理
Gitで変更を送る操作は「push」と呼ばれる。GitHubがSpokesと呼ぶ現行の仕組みは、リポジトリの複製を複数のサーバーに置き、書き込みを確定するために複製間で調整する。このとき使う「クォーラム」とは、複数の複製のうち多数が認めれば書き込みを確定できる仕組みだ。
GitHubの説明では、複製が複数の地域にまたがるリポジトリは、現行方式で処理できる書き込み量の上限が低くなる。拠点間の25ミリ秒は通信一往復の時間であり、すべての利用者のpushが一律に25ミリ秒遅くなるという測定値ではない。特に書き込みが多いリポジトリでは、変更を確定するための調整が処理量を制限する、というのが今回の問題だ。
更新先が違えば、順番待ちを分ける
Gitには「参照」という、履歴の特定の位置を指す名前がある。ブランチはその一例だ。GitHubが示した変更は、書き込みを順番づける単位を参照ごとに分けるものだ。別々のブランチへ変更を送る場合を考えると、更新先が異なる作業まで一律に同じ列で待たせない、という狙いが分かりやすい。同じ参照を更新するときには、引き続き整合性を守る必要がある。
GitHubは、現実的な通信量を用いた社内試験で、異なる参照への書き込みについて処理量が3〜4倍高くなり、遅延も低下したと報告している。これは異なる参照への書き込みを対象とした社内試験の結果だ。GitHub全体の処理速度が3〜4倍になった、あるいは残るリポジトリの本番移行が完了した、という意味ではない。提供された資料からは、試験の詳しい比較条件や本番環境での改善幅までは判断できない。
読み取りを増やす設計にもつながる
この変更は、書き込みだけで完結する話ではない。GitHubによれば、多くのリポジトリでは書き込み1回に対し読み取りが100〜1000回あり、現状は読み取りと書き込みが同じ複製を使って資源を取り合う。GitHubは、参照ごとの調整を進めることが、データを自身に永続保存しない複製を使い、読み取り能力を別に増やす道も開くと説明する。これは今後の設計の方向であり、その複製がすでに全リポジトリで使われているという発表ではない。
さらにGitHubは、参照ごとに分けても、書き込みを確定する集団そのものが次の処理量の上限になると述べる。今回の記事を読む鍵は、移したリポジトリの割合だけでなく、異なる変更をどこまで独立して確定できるかにある。AIが変更を作る量を増やすなら、その変更を保存し、次の作業へ一貫した状態で渡す基盤も問われる。
画像注：画像は複数拠点への複製と書き込みの調整を表す概念イラストであり、GitHubの実際の設備や構成図ではない。