［ニュース解説］GitHubが明かす4月の2件の障害と「30倍スケール」への対応戦略

2026-04-29

はじめに

　GitHubのCTO・Vlad Fedorov氏が2026年4月28日、プラットフォームの可用性に関するアップデートをブログで公開しました。本稿では、4月に相次いだ2件の障害の詳細と、エージェント型開発ワークフローの急増に対応するために進められているインフラ強化の取り組みについて解説します。

参考記事

タイトル: An update on GitHub availability
著者: Vlad Fedorov
発行元: GitHub Blog
発行日: 2026年4月28日
URL: https://github.blog/news-insights/company-news/an-update-on-github-availability/

要点

GitHubは2025年10月より10倍のキャパシティ拡張計画を進めていたが、2026年2月には目標を30倍に引き上げた
2025年12月後半からエージェント型開発ワークフローが急加速し、月間プルリクエスト数・コミット数・新規リポジトリ作成数がいずれも記録的な水準に達している
4月23日の障害では、マージキューのスカッシュマージに不具合が発生し、658リポジトリ・2,092件のプルリクエストに影響が出たが、データ損失はなかった
4月27日の障害ではElasticsearchクラスターが過負荷状態に陥り（ボットネット攻撃が原因とみられる）、検索機能を利用するUI全般に影響が生じた
GitHubはRubyモノリスからGoへの移行、Azure活用によるコンピューティング増強、マルチクラウド化など複数の対策を並行して進めている

詳細解説

エージェント開発の急増が引き起こすスケール課題

　GitHubは2025年10月、プラットフォームのキャパシティを10倍に拡張する計画を開始しました。しかし2026年2月の時点では、目標をさらに引き上げ、30倍規模への対応が必要という判断に至っています。

　この方針転換の背景には、ソフトウェア開発のあり方そのものが急速に変わっていることがあります。GitHubの発表によれば、2025年12月後半からエージェント型開発ワークフローが急加速し、プルリクエストのマージ数は月間最大9,000万件、コミット数は14億件、新規リポジトリ作成数は月間2,000万件という記録的な水準に達しています。GitHubが提唱するエージェント型ワークフロー「Agentic Workflows」のような自動化パターンが広まったことで、従来は人間が行っていた操作がAIによって高頻度・大量に実行されるようになったと考えられます。

　問題の難しさは、1件のプルリクエストが処理される際にGitストレージ・マージ可能性チェック・ブランチ保護・GitHub Actions・検索・通知・権限・Webhook・API・バックグラウンドジョブ・キャッシュ・データベースなど多数のシステムを横断している点にあります。大規模な負荷下では、小さな非効率が連鎖的に拡大し、キューの深化・キャッシュミスによるデータベース負荷増大・リトライによるトラフィック増幅といった複合障害へと発展しやすいとされています。

4月23日：マージキューのスカッシュマージ不具合

　4月23日、プルリクエストのマージキュー機能でリグレッションが発生しました。スカッシュマージ方式を使用するマージキューにおいて、マージグループに複数のプルリクエストが含まれる場合、正しいマージコミットが生成されない不具合が生じました。具体的には、直前のマージ済みプルリクエストや過去のコミットへの変更が、後続のマージによって意図せず巻き戻されるという挙動が確認されています。

　GitHubの発表では、影響を受けたのは658リポジトリ・2,092件のプルリクエストとされています。この不具合はマージキュー外でマージされたプルリクエストには影響せず、マージ・リベース方式を使用するマージキューにも影響しませんでした。Gitにはすべてのコミットが保存されており、データ損失は発生していません。ただし、デフォルトブランチの状態が不正になったリポジトリが存在し、すべてを自動的に安全に修復することはできなかったとのことです。GitHubは今回の障害が複数のプロセス上の問題を露呈したとして、同種の問題の再発を防ぐためにプロセスの見直しを進めているとしています。

4月27日：Elasticsearchの過負荷障害

　4月27日には、GitHubの検索基盤であるElasticsearchサブシステムに関連する障害が発生しました。このクラスターが過負荷状態（ボットネット攻撃が原因とみられる）に陥り、プルリクエスト・Issue・プロジェクトなど検索機能を利用する複数のUI領域で結果が表示されない状態が続きました。Gitの操作やAPIへの影響はなく、データ損失も発生していませんが、検索依存のUI全般に大きな影響が出ました。

　GitHubによれば、Elasticsearchは信頼性対策の優先度付けにおいて他のシステムより後回しになっており、単一障害点を解消するための分離対応が完了していなかったとのことです。今後は依存関係と「爆発半径（障害の影響範囲）」の分析をもとに、同種の障害が起きた際の影響を最小化するよう改善を進める方針が示されています。根本原因の分析については、近く公開予定とされています。

インフラ強化の取り組み

　GitHubはこれらの障害への対応と並行して、複数の技術的改善を進めています。短期的には、WebhookバックエンドのMySQL依存を排除し、ユーザーセッションキャッシュの再設計と認証・認可フローの見直しによってデータベース負荷を大幅に削減しました。Azureへの移行を活用したコンピューティングリソースの追加増強も行われています。

　中期的には、GitやGitHub Actionsといった重要サービスを他のワークロードから分離し、障害時の影響範囲を最小化する取り組みが進んでいます。依存関係とトラフィックのティアを丁寧に分析し、正規のトラフィックへの影響を最小化しながら各攻撃経路を優先順位に沿って対処しているとされています。また、パフォーマンスやスケールに敏感な処理をRubyモノリスからGoへ移行する作業も加速しています。

　大規模モノリポジトリの増加という課題に対しても、過去3か月で大きく投資が進んでいます。Gitシステムとプルリクエスト体験の両面で対応が進められており、1日に数千件ものプルリクエストが発生するリポジトリにとって重要なマージキュー操作の最適化が含まれています。効率性とスケールを高める新しいAPIの設計については、近くブログ記事が公開される予定です。

　長期的には、マルチクラウド化への移行が進められています。将来的に必要となる高い耐障害性・低レイテンシ・柔軟性を実現するために不可欠な措置とされており、現在進めているカスタムデータセンターからパブリッククラウドへの移行の延長線上にある取り組みです。

　透明性の観点でも変化があり、GitHubステータスページに可用性数値が追加されました。規模の大小を問わずすべての障害についてステータス更新を行うことを表明しており、障害発生時に問題の所在を利用者が判断しやすい環境を整えていく方針が示されています。

まとめ

　2026年4月に相次いだ2件の障害は、エージェント型開発ワークフローの急増が引き起こすスケール課題を端的に示しています。GitHubはRubyからGoへの移行やマルチクラウド化など複数の対策を並行して進めており、今後の信頼性向上が注目されます。インフラ安全性への最近の取り組みについては、eBPFを活用したデプロイ安全性強化の解説もあわせてご覧いただければと思います。