エージェントやCIを並列に動かすとき、リポジトリからコードを速く取得できれば、それだけ開発も速く進むのでしょうか。変更を送り返すpushや、同じブランチへ変更を取り込む場面まで考えると、読み取り速度だけでは答えが出ません。

2026年10月6日にGitHubが公表したGit基盤の再設計は、この読み書きの関係を見直す取り組みです。どの処理を独立に増やし、どの更新には順序を守らせるのかをたどると、エージェントを増やす際に見るべき負荷も分かります。

Spokesでは複製を増やすほど更新の協調も増える

GitHubの複製基盤であるSpokesは、複数のサーバにリポジトリを保持し、更新後の状態をそろえる仕組みです。2017年公開の技術解説「Stretching Spokes」では、3フェーズコミットを使った参照更新と、離れた拠点との通信往復を減らす工夫が説明されています。データを複製することと、その複製を一致させることは、以前からセットの課題だったわけですね。

今回の再設計が向き合うのは、その複製が読み取りの処理能力も担っている点です。読み取り先を追加すると書き込み時の協調相手も増えるため、読み取りを強化する施策がpushの負担になります。

ここで分けたいのは、データを失わないための複製と、同じデータを大勢へ返すための処理能力です。この2つを同じサーバ群で増やす構成では、cloneの混雑だけを解消しようとしても、書き込み側まで影響を受けます。

Gitの参照更新には「先端が変わっていないか」の確認が必要

では、書き込みをすべて独立に進めればよいのでしょうか。Gitでは、ブランチがどのコミットを指すかを決める更新に注意が必要です。

Gitの参照に関する公式解説にあるように、ブランチは履歴の先端を指す参照です。コミットのデータが存在することと、mainがそのコミットを指していることは別の状態です。

具体例として、2つの処理が同じ先端Aを読み、それぞれBとCへ進めようとする場合を考えます。git-update-refの仕様では、更新前のオブジェクトIDを指定すると、現在値がそのIDと一致した場合だけ更新します。Bへの更新が先に成功すれば、「まだAである」という条件でCへ更新する処理は成功しません。

これはGitの仕様から組み立てた説明例で、GitHub内部の実装手順を示すものではありません。それでも、同じ参照を更新する際には競合を検出する段階が必要だと分かります。データの準備を並列化できても、ブランチの先端まで無条件に上書きできるわけではありません。

永続ストレージとキャッシュ用ワーカーを分けて拡張する

GitHubの新設計では、正本をAzure Blob Storageへ置き、読み取りはキャッシュを持つワーカーで処理します。協調を必要な参照更新へ絞り、リポジトリの圧縮整理や不要オブジェクトの回収も専用ワーカーへ分離する方針です。

この構成なら、読み取り用ワーカーを増やすことを、正本の複製を増やすことから切り離せます。設計上の意味は、CIの取得要求に応える能力と、更新を確定する能力を別々に調整できる点にあります。

ただし、役割を分けると、今度はキャッシュが空の状態でどの程度の待ち時間が生じるかも評価対象になります。これは構成から導ける運用上の観点であり、今回の発表には、その条件での具体的な応答時間は示されていません。

GitHubは内部ベンチマークで最大35倍の書き込みスループットを報告しています。これは単一のpushが35倍速くなるという意味ではなく、各リポジトリで同じ改善が得られる保証でもありません。処理件数と1回の待ち時間は、分けて読む必要があります。

CIの並列度は現在の推奨値と実測で決める

基盤の設計が変わるという話から、すぐにエージェントやCIの並列数を増やしてよいとは判断できません。2026年10月7日に確認したGitHubのリポジトリ制限ドキュメントには、リポジトリ当たりの読み取りは毎秒15操作、pushは毎分6回という推奨最大値が記載されています。いずれも推奨値であり、今回の発表を上限変更の告知として扱うべきではありません。

同ドキュメントは、CIのclone戦略の最適化やキャッシュサーバの検討も勧めています。まずは自分たちの処理を、コードの取得、変更の送信、共通ブランチへの取り込みに分けると、調整する場所を選びやすくなります。

運用で記録する指標としては、次の組み合わせが考えられます。これは本記事からの提案です。

処理	記録する値	判断につなげる問い
clone・fetch	実行回数と完了までの時間	同じ内容を取得するジョブが集中していないか
push	回数、所要時間、失敗理由	並列数を増やすと待ち時間や失敗が増えないか
共通ブランチへの取り込み	待機時間と再試行回数	作業ブランチを増やしても、取り込み待ちが残らないか

エージェントを増やす際の問いは、「cloneが速いか」から、「読み取りを増やしても更新を滞らせずに済むか」へ広がります。GitHubの再設計は、そのために保存・配信・更新の役割を分ける試みです。利用側でも処理ごとの負荷を測れば、追加の並列実行が役立つ場所と、順序を守って進める場所を判断できます。

出典

• Title: Building Git infrastructure for agent-scale development
• URL: https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/