GitHubが7時間超の大規模障害を経験——CTOが詳細を公表#
2026年8月17日、GitHubは7時間47分にわたる大規模なサービス障害を経験した。GitHub CTO のVladimir Fedorov氏が公式ブログにてその原因と今後の対応策を詳細に説明している。
障害の詳細：何が起きたのか#
今回の障害では、github.com へのアクセス、認証機能、GitHub Actions、API、プルリクエスト、Issues、そしてCopilotと、GitHubの主要サービスのほぼすべてが影響を受けた。世界中の開発者や組織に深刻な打撃を与えた。
調査によると、障害のトリガーとなったのはトラフィックが新たなピークに達したタイミングだったという。米国中部データセンター内の重要なインフラコンポーネントがそのトラフィック増加に追いつけず、スケールアウトに失敗。その結果生じたキャパシティ不足が連鎖的にシステム全体へ波及し、認証障害をはじめとする複数サービスの停止を引き起こした。
復旧には複数チームが連携した対応が必要となり、トラフィックの迂回、問題インフラの分離、そだんご的なサービス再開という手順が踏まれた。多くのサービスは当日中に回復したが、一部のCopilotサービスは復旧に時間を要した。原因のひとつとして、Copilotサービスのエラーがクライアント側での**リトライループ（自動再試行の繰り返し）**を引き起こし、復旧作業中に逆にトラフィックを増大させてしまったことが挙げられている。このリトライ挙動を抑制してから、ようやく安全にトラフィックを戻すことができたという。
根本原因はコードでもなく設定変更でもなく「キャパシティ不足」#
注目すべき点として、今回の障害も8月6日に発生した別の障害も、コードや設定変更によるものではないとFedorov氏は明言している。両インシデントの根本原因は「キャパシティ（容量）の不足」であり、需要が処理能力を超える前に重要コンポーネントをスケールさせることができなかったことに起因する。
GitHub上の月間コミット数は、4月時点の14億件から8月には29億件へと急増しており、この急激な成長がシステムに大きな圧力をかけていたことは確かだ。しかしFedorov氏は「成長が理由になるとしても、障害の言い訳にはならない」と述べ、責任を明確に認めている。
これまでの対策と今後の取り組み#
GitHubは今年初めに信頼性向上のコミットメントを発表しており、以下の3つの優先事項に取り組んできたとしている。
- キャパシティの追加：300万以上のCPUコア、120ペタバイトの高速ストレージ、大幅なネットワーク容量の増強
- 効率の改善
- アーキテクチャ上のボトルネックの解消
また、Azureへの移行が大きく加速しており、現在AzureはGitHubのプラットフォーム負荷の約58%、全Gitオペレーションの半数を処理している。これは5月時点の12%から大幅に増加した数字だ。Azure上では大規模モノレポ（単一リポジトリに多数のコードをまとめる構成）のスケーリング作業も進んでおり、次のマイルストーンとして「リーダー数に応じてリード容量が線形にスケールするアーキテクチャ」の段階的展開が計画されている。
今回の2件のインシデントを受けた即時対応として、以下の2点が実施されることになった。
- リトライ制限・リトライバジェット・可変タイムアウトの統一適用：サービス間通信全体にわたって実施し、リトライストーム（大量の再試行によるシステム過負荷）や連鎖的な負荷増大を防ぐ
- 低優先度アラートの見直し：突発的なトラフィック急増時に障害を起こしうるコンポーネントを特定するため、CPUおよびメモリ関連の低優先度アラートを精査する
さらに、重要システムを相互に分離し、共有依存関係を排除する取り組みも進められており、障害発生の可能性を低減しつつ、万が一障害が起きた際の影響範囲を限定することを目的としている。
なぜこのニュースが重要か#
GitHubは世界中の開発者にとってコードの保管・共同開発・デプロイ作業の中核を担うプラットフォームである。7時間47分という長時間の全面的な障害は、個人開発者から大規模な商用サービスまで幅広く業務を停滞させるインパクトを持つ。加えて、8月だけで2回目の重大インシデントであるという事実は、インフラの信頼性に対する懸念を高めている。
CTO自らが詳細な原因と具体的な対策を公表し、責任を認めた姿勢は透明性という観点で評価できる。
筆者の見解: コミット数が4月から8月にかけて倍増以上に膨らんでいるという数字は、GitHubへの依存度が急速に高まっていることを示している。Azure移行の加速とキャパシティ増強の両輪で対応しているとはいえ、根本原因が2回連続して「キャパシティ不足」であった点は、運用・監視体制そのものの見直しが急務であることを示唆している。
まとめ#
2026年8月17日のGitHub大規模障害は、急増するトラフィックへのキャパシティ対応の失敗によるものだった。GitHubはAzureへの移行加速、大規模なハードウェア増強、リトライ制御の統一など具体的な対策を進めているが、信頼回復に向けた取り組みはまだ道半ばだとFedorov氏自身も認めている。より詳細な技術的タイムラインや根本原因分析については元記事を参照してほしい。
