GitHubは2026年10月6日（UTC）、開発者とAIエージェントが並行して作業する負荷を見据え、Git基盤を再構築中だと説明した。この記事は提供開始の告知ではない。読み解くべき問いは、短い間隔で増えるpushをどう保存し、次のエージェントやCIの作業から一貫して見えるようにするか、である。
pushの後、次の作業に何を渡すのか
たとえば、あるエージェントが変更をリポジトリへpushし、続いて別のエージェントが取得し、CIが検証する場面を考える。最初の入力はGitの更新、その後の入力は更新後の状態を読む要求だ。必要な出力は、失われずに保存され、次の作業から一貫して見えるリポジトリの状態である。GitHubは、各pushを耐久的に保存して一貫して可視化することを、新しい負荷が求める条件として挙げている。
この条件が難しくなる理由は、書き込み同士の調整にある。多くのpushを受け付けるには更新を素早く処理したい。一方、正しさを守るための調整も必要だ。GitHubの説明では、調整が多すぎると書き込み処理の伸びを制限し、忙しいリポジトリをボトルネックにする。エージェントの増加は、コードを作る側だけでなく、その結果を受け取るGit基盤にも負荷をかける。
現行のSpokesでは、保存と読み取りが結び付いている
GitHubによると、現行のSpokesは各リポジトリの完全なコピーを複数のファイルサーバーのローカルディスクに置く。標準では5つだという。速いローカルディスクがGitの読み取り処理を支え、同じコピーが耐久的な保存も担う。GitHubの2017年のSpokes解説には、pushをプロキシ経由で複数のサーバーへ複製し、fetchやcloneを近くの複製から処理できる仕組みも記されている。これは当時の設計を説明する資料であり、現在の細部まで証明するものではない。
2026年の記事が示す制約は明確だ。完全なコピーが保存とGit要求の処理を兼ねるため、読み取り能力と耐久的なコピーの数を切り離しにくい。また、書き込みに必要なクォーラムを失えばpushが止まると説明する。Spokesが果たしてきた複製と読み取りの役割を踏まえると、新設計の焦点は「コピーをいくつ増やすか」だけではない。保存の責任と、要求を処理する能力を別々に拡張できるかにある。
新設計の二つの軸
第一は、必要な正しさを保ちながら調整を減らすことだ。GitHubは、忙しいリポジトリでもpushを受け付けて公開できるよう、調整の多さを見直す方針を示した。保守作業については、別のワーカーが耐久的なストレージに対して直接処理し、pushやfetchを遅らせずにバックグラウンドで最適化する構想を述べている。どの更新にどのような合意手順を使うかは、提示された抜粋からは分からない。
第二は、保存と処理を分けることだ。GitHubは、完全なリポジトリのコピーが担っている二つの役割を分離し、読み取りと書き込みをそれぞれ拡張する設計を掲げる。読み取り要求が増えたとき、耐久的なコピーを増やすことに直結させず、読み取り能力を増やせるという説明だ。これは設計上の狙いであり、公開環境でどの程度の性能が得られるかを示す数字としては読めない。
利用者との接点は、普段のpush、fetch、cloneや、それを使うエージェントとCIの作業である。GitHubは基盤を稼働させたまま作り直し、そのために利用者へ開発手順の変更を求めない方針を述べる。ただし、新しい保存方式の詳細、移行時期、特定のクライアントやCIとの連携仕様は、提供された抜粋では確認できない。
利用者が今読み取れること
設計が狙いどおりに働けば、多数のエージェントが作業するリポジトリで、pushを確実に公開する能力と、その結果を読む能力を別々に伸ばしやすくなる。これはGitHubが示した設計からの見通しであり、すでに全利用者が体験できる改善という意味ではない。GitHubは、コードの所有者が変更をレビューし、理解し、承認できることも原則に挙げている。
今回の発表から確かに分かるのは、GitHubが書き込みの増加をGit基盤の課題として捉え、調整の削減と保存・処理の分離を進めていることまでだ。提供された抜粋には内部ベンチマークへの言及があるものの、比較条件を確認できるだけの記述はない。導入時期や実運用での効果を判断するには、今後の具体的な説明が必要になる。
画像注：冒頭の画像は設計思想を表す概念イラストであり、GitHubの実際の構成図ではない。
出典：参照した一次発表（確認日：2026-10-11）。