GitHub は 2026 年 10 月 6 日、公式エンジニアリングブログで、世界のコードホスティングを支える Git インフラを再構築していると発表した。理由は明快で、コードを書く主体が変わったからだ。この 1 年で、エージェントと開発者が GitHub 上で生み出すコミット、プッシュ、マージは倍増を続け、人間のペースに合わせて設計されたストレージ基盤が、まず書き込みのボトルネックに突き当たった。
まず数字から：プッシュは月 33.5 億回へ
GitHub が示す規模の変化は急だ。2026 年 8 月、プラットフォーム上の Git イベントは 4733 億回に達し、前年の 2 倍を超えた。2026 年 9 月のコミットは 73.8 億回で、前年の 5 倍以上。プッシュは月 6.9 億回から 33.5 億回へ、前年比 4.9 倍になった。プルリクエストのマージは前年のほぼ 4 倍、GitHub Actions の 9 月の実行回数も 32.6 億回と 4 倍を超えた。
エージェントの働き方は、書き込みの一つひとつを増幅させる。数千のエージェントが同一リポジトリの別々のブランチで並行して働くと、持続的な書き込みが最終的にトランクという一点へ収束する。マージは同一のリファレンスを奪い合い、トランクベース開発、リリーストレイン、マージキューはすべての作業を、全部のマージを飲み込まなければならない 1 本のリファレンスへ流し込む。各プッシュはさらに数千回の読み取りへ扇状に広がる。CI とコードスキャンが同じブランチの先端を 1 分間に何千回もクローン、フェッチするからだ。
読み取りは広げやすく、書き込みは難しい：旧基盤の結合点
現在のストレージ層 Spokes は、各リポジトリの完全なコピーを複数のファイルサーバーのローカルディスクに保持する（既定で 5 部）。プッシュでリファレンスが更新される際は 3 フェーズコミットとクォーラムで、Web、API、CI が一貫した状態を見られるようにしている。この組み合わせが今日、10 億規模のリポジトリを支えている。
問題は、耐久性と拡張性が同一の仕組みである点だ。ディスク上のコピーは真実の源であると同時に、読み取り能力の源でもある。読み取り容量を増やすには耐久レプリカをもう 1 部増やすしかなく、各レプリカはすべての書き込みに参加するため、プッシュの速度は最も遅いレプリカに引きずられる。読み取りのためにレプリカを増やすと書き込みが遅くなり、レプリカを失うと読み取り容量が落ち、クォーラムを失えば書き込みは止まる。大半のリポジトリではこのトレードオフで成り立つが、最も活発なリポジトリでは天井になる。
再構築の方向：耐久性と拡張性を分ける
新アーキテクチャの狙いは、耐久性と拡張性を分離しつつ、3 つの線を守ることだ。ワークフローは変えない。ブランチ、レビュー、マージ、履歴といった開発者が信頼する進め方は新基盤の上でもそのまま動き、利用者の習慣を変えさせない。信頼性を最優先し、すべての判断をその物差しで測る。そして制御は人の手に残す。ブランチ保護、必須レビュー、監査ログ、リポジトリの可視性といった統制は維持し、エージェントがどれだけ働いても、コードのレビューと承認は所有者が行う。工学面では協調の最小化が重視される。高頻度にプッシュを受けるリポジトリは、各ステップで全体の合意を待つのではなく、更新を素早く受け付けて公開できなければならない。再構築全体はプラットフォームを止めずに進み、世界のコードが止まるメンテナンス時間は存在しない。
この話の意味は 1 社にとどまらない。エージェントの産出が数十億コミット単位で数えられるようになると、ボトルネックはモデルの能力からインフラへ移る。人間のペースで作られたリポジトリ、レビュー、CI を、機械のペースに合わせて作り直す必要があるのだ。本サイトでは以前、GitHub が 219 件の実在 PR で AI コードレビューを測る ReviewBench を紹介した。あちらが問うのは「エージェントが書いたコードは信用できるか」。今回の再構築が答えるのはその裏側、「プラットフォーム自体がエージェントの書く速度に追いつけるか」である。プログラミングエージェントを多用するチームにとって、今後 1〜2 年は、コード基盤の書き込みスループット、マージの待ち行列、監査能力が、モデルそのものと同じくらい注視すべき対象になる。
