GitHub、エージェント開発急増で30倍拡張へ 障害対応も組み替え

GitHubが出した今回の可用性アップデートは、単なる障害報告よりもインフラ需要の転換点を示す文章として読むべきだ。4月28日の投稿で同社は、2025年10月に10倍の容量拡張計画を始めたものの、2026年2月には現在の30倍を前提に設計し直す必要があると判断したと説明した。背景にあるのは、2025年12月後半から急加速したエージェント型開発ワークフローだ。リポジトリ作成、プルリクエスト、API利用、自動化、大規模リポジトリ処理が同時に増えているという。

重要なのは、いまのプルリクエストが単独で完結する処理ではないことだ。GitHubは、1つのワークフローがGitストレージ、mergeability checks、branch protection、GitHub Actions、検索、通知、権限、webhooks、API、バックグラウンドジョブ、キャッシュ、データベースまで連鎖的に触ると整理している。利用が一斉に膨らめば、小さな非効率でもすぐ待ち行列やデータベース負荷に変わる。AIコーディングの普及は、モデルの利用量だけでなく土台の開発基盤そのものを押し広げている。

その圧力は直近の障害でも表面化した。4月23日のmerge queue障害では、複数PRを含むmerge groupでsquash mergeを使った際に誤ったmerge commitが生成され、230のリポジトリと2,092件のPRが影響を受けた。4月27日にはElasticsearchサブシステムの障害で、プルリクエスト、issues、projectsの一部検索体験が止まった。GitHubはデータ消失はなく、Git操作やAPIも無事だったとしているが、検索停止だけでも共同作業の流れは十分に崩れる。

ここで見えてくるのは、AI支援開発の競争軸が変わり始めたということだ。優れたモデルを載せるだけでは足りず、そのモデルが発生させるトラフィックをどう隔離し、どこまで障害の波及を抑えられるかが製品力になる。GitHubが強調した isolation と blast-radius reduction は運用チームの言葉だが、実際には開発者が安心して任せられるかどうかを左右する機能でもある。エージェント開発がさらに増えれば、次の差は賢さよりも壊れにくさで開く可能性が高い。