10月31日、pbxscience.comが「GitHub Adds 4 Million CPU Cores as AI Agents Push Code Activity to Record Highs」と題した記事を公開した。AIエージェントによるコード活動の急増を受けてGitHubがインフラを大規模拡張し、Gitアーキテクチャ自体の再設計に着手したことについて詳しく紹介されている。

1か月で73億コミット——5倍超の急増、そしてGitの設計的限界

2026年9月、GitHubが1か月に記録したコミット数は73.8億件。前年同月比で5倍以上に達した。4月時点では約14億件、8月には29億件だったものが、わずか数か月でここまで跳ね上がった。

この急増の主因としてGitHubが挙げているのが「agentic demand（エージェント需要）」だ。これは、人間のエンジニアと並行して、コードの生成・テスト・プルリクエストの送信までを自動的にこなすAIエージェントが生み出す負荷を指す概念である。GitHub Copilot WorkspaceやDevinのような自律型コーディングエージェントが普及し、1つのタスクに対して複数のエージェントが並走しながら数十〜数百のコミットを短時間で生成するケースが一般化してきた。

ここで重要なのは、Gitがそもそもこうした使われ方を想定して設計されていない、という点だ。Gitは分散バージョン管理システムとして1人または少数の人間が非同期にコードを変更することを前提に設計されており、複数のエージェントが同一リポジトリに対して高頻度・同時並行で読み書きを行うシナリオは設計の射程外だった。この構造的なミスマッチこそが、GitHubが単なるサーバー増設ではなくGit自体の再設計に踏み込まざるを得なかった根本的な理由だ。

2026年9月時点で、GitHubのプルリクエストの40%以上がエージェントの起草によるものとなっており、2026年3月の17%から急増した。1か月あたり約1億1000万件のプルリクエストがエージェントによって作成された計算になる。

また、今年新規に作成されたリポジトリのうち、エージェント設定ファイルを含むものは、含まないリポジトリと比べて平均8倍のコミット数を記録している。AIエージェントを組み込んだプロジェクトは、それだけ開発速度が速い。

Octoverse 2026：12か月の全体像

2025年10月〜2026年9月の1年間でGitHubが報告した主要指標は以下の通りだ。GitHubは毎年この時期にOctoverseと呼ばれる年次レポートを公開しており、今回の数値もその一環として示された。

コードプッシュが「2024年と2025年を合わせた数を1年で超えた」という事実が、この変化の速さを端的に表している。GitHub Actionsの1日あたり約1億2400万件というジョブ数も、エージェントがプッシュするたびにCI/CDパイプラインが連鎖起動する構造を考えると、コミット数の増加が単純にインフラ全体の負荷として乗数的に増幅していることがわかる。

インフラ増強だけでは足りない——Gitの再設計へ

この需要増に対応するため、GitHubは2026年1年間で以下のキャパシティを追加した。

• CPU：400万コア追加（8月時点で300万コアと報告されていたものが、年間で400万コアに）
• ストレージ：160ペタバイトの高速ストレージ
• ネットワーク：50 Tb/sの帯域幅

しかしGitHubは、ハードウェアの増強だけでは対応しきれないと判断し、Gitインフラ自体の再設計に着手している。複数のエージェントが同時並行で動作する場合、1つのプッシュがリポジトリ更新・自動テスト・セキュリティチェック・ビルド・通知と連鎖的に処理を引き起こすため、同時読み書きの負荷が従来の設計では処理しきれなくなっている。

Gitのリポジトリデータは内部的にオブジェクトストア（コミット・ツリー・ブロブなどの単位）として管理されており、書き込み時にはロックが発生する。人間が主体のワークフローではこの競合がほとんど問題にならなかったが、エージェントが秒単位でプッシュを繰り返す環境では、このロック競合とメタデータ更新のオーバーヘッドがボトルネックになる。GitHubが公式ブログ等で言及してきたGitのスケーリング課題はこれまでも存在していたが、エージェント需要がその問題を一気に表面化させた形だ。

再設計の方針は3点だ。

• システムの基盤コンポーネントの簡素化
• ストレージとコンピューティングの分離
• システム間の調整（コーディネーション）の頻度を削減

従来のGitHubは、リポジトリデータをファイルサーバー上に複数コピーとして保持するモデルだったが、このアーキテクチャを脱却する方向で動いている。ストレージとコンピューティングを分離するアプローチは、SnowflakeやDatabricksといったクラウドデータ基盤がスケーラビリティ確保のために採用してきた手法と方向性が近く、Gitのホスティング基盤がようやくその段階に踏み込んでいると言える。

障害の頻発——インフラ拡張と信頼性確保の両立が課題

急激な負荷増加に伴い、インフラ拡張の過程で大規模障害も相次いでいる。2026年10月7日には、Actions・プルリクエスト・Issuesに影響する広範な障害が発生した。GitHubはリアルタイムの稼働状況をgithubstatus.comで公開しているが、エージェントが常時稼働する環境においては、障害の影響範囲がこれまでとは異なるスケールで広がるリスクがある。人間のエンジニアであれば障害に気づいてリトライを止めるという判断ができるが、エージェントは設定次第で障害中も繰り返しリクエストを送り続けるため、障害の連鎖を悪化させる可能性も考慮する必要がある。インフラ拡張と並行して、信頼性の確保がより重要な課題として浮上している状況だ。

AIエージェントがソフトウェア開発の主要なアクターになりつつある今、GitHubが直面している問題はインフラの規模だけの話ではない。Gitという30年来の設計思想を持つシステムが、エージェント時代の負荷に耐えられるかどうかという問いに、業界全体が答えを求められている。

詳細はGitHub Adds 4 Million CPU Cores as AI Agents Push Code Activity to Record Highsを参照していただきたい。