発生から復旧まで：サービスは一斉には戻らなかった

GitHubがパフォーマンス問題の調査を始めたのは、8月17日13時40分（UTC）ごろ。米東部夏時間では午前9時40分にあたる。 その後、APIリクエストやActions、Webhooks、Issues、Pull Requestsなど、コードへのアクセス、レビュー、テスト、デプロイに関わる機能へ影響が広がった。

GitHubは後に、障害に関係するコンポーネントを特定し、是正措置を実施したと説明した。米東部夏時間12時36分に公開された更新では、サービスが「強い回復の兆候」を示しているとした一方、完全な安定には至っていなかった。

復旧はプラットフォーム全体で同時に進んだわけではない。主要サービスが稼働状態に戻った後も、一部アプリケーションではCopilotの認証問題が続いた。 外部のインシデント記録では、全体の障害が収束したのは21時15分（UTC）ごろとされており、深刻な性能低下が始まってから完全な復旧まで、約7時間半に及んだことになる。

影響の規模はどれほどだったのか

GitHubが示した主なエラー率は次の通りだ。

• WebエクスペリエンスとAPIトラフィック：約20％のエラー。
• アーカイブとRaw形式のリポジトリコンテンツのダウンロード：約50％のエラー。
• 開発者向け機能：Pull Requests、Issues、Actions、Webhooks、Git操作、Pagesが、時間帯によって性能低下または利用不能になった。
• AIコーディング支援：GitHub Copilotも影響を受け、主要サービスの復旧後もしばらく問題が残った。
• 企業向けID管理：SAMLおよびOIDC認証、SCIMプロビジョニング、Team Syncにも影響が及んだと報告されている。組織によっては、ユーザーのサインインやアクセス権管理を安定して行えない可能性があった。

ここでいう20％や50％は、影響を受けたリクエストのエラー率であり、GitHub利用者全体の何％がオフラインになったかを示す数字ではない。APIのエラー率が20％だったからといって、利用者の20％が一律にアクセス不能だったわけではない。また、50％という数字は、すべてのリポジトリ通信ではなく、対象となったダウンロードリクエストに適用される。

なぜ月曜の朝に起きたことが重く響いたのか

障害は米国の月曜朝、つまり多くの開発チームが週の作業を始める時間帯に発生した。開発現場では、始業後にリポジトリへアクセスし、コードレビューを確認し、CI/CDのジョブを実行し、リリースやデプロイを進めるケースが多い。

今回影響を受けたのは、これらの工程に直接関わるActions、Pull Requests、API、Webhooksなどだった。そのため、単一機能の停止ではなく、コードの取得からレビュー、ビルド、デプロイまで複数の連携箇所で失敗が起きる状況になった。

障害報告サイトの数字には、時間帯や集計方法による差もある。Downdetectorでは、米太平洋時間8時12分までに1万件を超える報告が記録されたという報道がある一方、別の復旧報道ではピークが約3,000件だったとされている。

これらは影響を受けた利用者数の正確な集計ではない。障害追跡サイトの数字はユーザーから寄せられた報告件数であり、地域、時刻、報告する人の割合、集計方法によって変動するためだ。

GitHubが行った対応と、まだ説明されていない点

公開された更新から確認できるGitHubの対応は、主に次の3点だ。

1. 複数サービスで発生した性能低下についてエンジニアが調査した。
2. 問題のあるコンポーネントを特定し、是正措置を取った。
3. 主要サービスの復旧後も、Copilotの一部アプリケーションで発生した断続的な認証失敗などへの緩和策を続けた。

一方で、問題のコンポーネントの名称、具体的な修正内容、そして今回の障害が容量不足によって直接引き起こされたことは、現時点の公開情報からは確認できない。

GitHubは、AI支援やAIエージェントによる開発ワークフローでトラフィックが急増していること、Azureへの容量移行やサービス分離などを進めていることを、より広い信頼性向上の文脈で説明している。 しかし、AI関連の負荷増大やインフラ上の制約を、8月17日の障害の確定した根本原因として扱うのは時期尚早だ。最終的な判断には、GitHubが予告しているポストモーテムを待つ必要がある。

2026年のGitHubで続く信頼性の課題

今回の障害は、GitHubにとって単発のトラブルとして片付けにくいタイミングで起きた。GitHubの2026年7月の可用性レポートでは、同月に8件のインシデントが記録されている。中でも7月8日の障害は7時間超にわたり、Web UI、REST API、GraphQL API、Actions、Packages、Copilot、Git操作などに影響した。

GitHubは、AI支援・AIエージェント型の開発ワークフローを主因の一つとして、トラフィックが急速に増えていると説明している。対応策として、伸縮性のある容量を確保するためのAzure移行、モノリスの分割、サービス間の共有障害点の削減などを挙げている。

インフラ計画の規模も大きい。当初は従来の10倍の容量を目標としていたが、2026年2月までに、当時の規模の30倍を前提に設計する必要があると判断されたと報じられている。 Azureの活用拡大に加えて、AWSを含むマルチクラウドの容量確保に関する取り組みも報じられているが、これらの計画が8月17日の具体的な原因を説明するものではない。

GitHubはもはやGitリポジトリを保管する場所だけではない。コードの共同作業、CI/CD自動化、ID管理、AIによるコーディング支援を一つの基盤で提供している。その分、共有される依存関係に問題が起きると、リポジトリへのアクセス、レビュー、ビルド、デプロイ、Webhooks、AI支援が一度に止まる可能性がある。

組織が今回の障害から考えるべきこと

今回の障害は、開発者が近く一斉にGitHubを離れることを証明したわけではない。短期的に大規模な移行が起きると予測できる根拠も、現時点では示されていない。

ただし、GitHubを本番ソフトウェアの提供基盤として使う組織にとって、障害時の前提を見直すきっかけにはなる。たとえば、次のような備えが考えられる。

• リポジトリのバックアップやミラーを維持する
• CI/CD設定を特定のホスティングサービスに過度に依存しない形で管理する
• 緊急リリース時の手順を文書化する
• SSO、Webhooks、ホステッドランナーが利用できない場合の運用を決めておく

こうした対策でプラットフォーム障害そのものをなくすことはできない。しかし、次のサービス停止が開発全体へ波及する範囲、いわゆる「爆発半径」を小さくすることはできる。

8月17日の障害について最終的な評価を下すには、GitHubのポストモーテムが必要だ。現時点で確実に言えるのは、リポジトリのダウンロードと複数の開発ワークフローに深刻な影響を与える、広範かつ連鎖的な障害が発生し、復旧は段階的に進んだということ。そして、その根本的な失敗原因は、まだGitHubから公表されていないという点である。

発生から復旧まで：サービスは一斉には戻らなかった

GitHubがパフォーマンス問題の調査を始めたのは、8月17日13時40分（UTC）ごろ。米東部夏時間では午前9時40分にあたる。 その後、APIリクエストやActions、Webhooks、Issues、Pull Requestsなど、コードへのアクセス、レビュー、テスト、デプロイに関わる機能へ影響が広がった。

GitHubは後に、障害に関係するコンポーネントを特定し、是正措置を実施したと説明した。米東部夏時間12時36分に公開された更新では、サービスが「強い回復の兆候」を示しているとした一方、完全な安定には至っていなかった。

復旧はプラットフォーム全体で同時に進んだわけではない。主要サービスが稼働状態に戻った後も、一部アプリケーションではCopilotの認証問題が続いた。 外部のインシデント記録では、全体の障害が収束したのは21時15分（UTC）ごろとされており、深刻な性能低下が始まってから完全な復旧まで、約7時間半に及んだことになる。

影響の規模はどれほどだったのか

GitHubが示した主なエラー率は次の通りだ。

• WebエクスペリエンスとAPIトラフィック：約20％のエラー。
• アーカイブとRaw形式のリポジトリコンテンツのダウンロード：約50％のエラー。
• 開発者向け機能：Pull Requests、Issues、Actions、Webhooks、Git操作、Pagesが、時間帯によって性能低下または利用不能になった。
• AIコーディング支援：GitHub Copilotも影響を受け、主要サービスの復旧後もしばらく問題が残った。
• 企業向けID管理：SAMLおよびOIDC認証、SCIMプロビジョニング、Team Syncにも影響が及んだと報告されている。組織によっては、ユーザーのサインインやアクセス権管理を安定して行えない可能性があった。

ここでいう20％や50％は、影響を受けたリクエストのエラー率であり、GitHub利用者全体の何％がオフラインになったかを示す数字ではない。APIのエラー率が20％だったからといって、利用者の20％が一律にアクセス不能だったわけではない。また、50％という数字は、すべてのリポジトリ通信ではなく、対象となったダウンロードリクエストに適用される。

なぜ月曜の朝に起きたことが重く響いたのか

障害は米国の月曜朝、つまり多くの開発チームが週の作業を始める時間帯に発生した。開発現場では、始業後にリポジトリへアクセスし、コードレビューを確認し、CI/CDのジョブを実行し、リリースやデプロイを進めるケースが多い。

今回影響を受けたのは、これらの工程に直接関わるActions、Pull Requests、API、Webhooksなどだった。そのため、単一機能の停止ではなく、コードの取得からレビュー、ビルド、デプロイまで複数の連携箇所で失敗が起きる状況になった。

障害報告サイトの数字には、時間帯や集計方法による差もある。Downdetectorでは、米太平洋時間8時12分までに1万件を超える報告が記録されたという報道がある一方、別の復旧報道ではピークが約3,000件だったとされている。

これらは影響を受けた利用者数の正確な集計ではない。障害追跡サイトの数字はユーザーから寄せられた報告件数であり、地域、時刻、報告する人の割合、集計方法によって変動するためだ。

GitHubが行った対応と、まだ説明されていない点

公開された更新から確認できるGitHubの対応は、主に次の3点だ。

1. 複数サービスで発生した性能低下についてエンジニアが調査した。
2. 問題のあるコンポーネントを特定し、是正措置を取った。
3. 主要サービスの復旧後も、Copilotの一部アプリケーションで発生した断続的な認証失敗などへの緩和策を続けた。

一方で、問題のコンポーネントの名称、具体的な修正内容、そして今回の障害が容量不足によって直接引き起こされたことは、現時点の公開情報からは確認できない。

GitHubは、AI支援やAIエージェントによる開発ワークフローでトラフィックが急増していること、Azureへの容量移行やサービス分離などを進めていることを、より広い信頼性向上の文脈で説明している。 しかし、AI関連の負荷増大やインフラ上の制約を、8月17日の障害の確定した根本原因として扱うのは時期尚早だ。最終的な判断には、GitHubが予告しているポストモーテムを待つ必要がある。

2026年のGitHubで続く信頼性の課題

今回の障害は、GitHubにとって単発のトラブルとして片付けにくいタイミングで起きた。GitHubの2026年7月の可用性レポートでは、同月に8件のインシデントが記録されている。中でも7月8日の障害は7時間超にわたり、Web UI、REST API、GraphQL API、Actions、Packages、Copilot、Git操作などに影響した。

GitHubは、AI支援・AIエージェント型の開発ワークフローを主因の一つとして、トラフィックが急速に増えていると説明している。対応策として、伸縮性のある容量を確保するためのAzure移行、モノリスの分割、サービス間の共有障害点の削減などを挙げている。

インフラ計画の規模も大きい。当初は従来の10倍の容量を目標としていたが、2026年2月までに、当時の規模の30倍を前提に設計する必要があると判断されたと報じられている。 Azureの活用拡大に加えて、AWSを含むマルチクラウドの容量確保に関する取り組みも報じられているが、これらの計画が8月17日の具体的な原因を説明するものではない。

GitHubはもはやGitリポジトリを保管する場所だけではない。コードの共同作業、CI/CD自動化、ID管理、AIによるコーディング支援を一つの基盤で提供している。その分、共有される依存関係に問題が起きると、リポジトリへのアクセス、レビュー、ビルド、デプロイ、Webhooks、AI支援が一度に止まる可能性がある。

組織が今回の障害から考えるべきこと

今回の障害は、開発者が近く一斉にGitHubを離れることを証明したわけではない。短期的に大規模な移行が起きると予測できる根拠も、現時点では示されていない。

ただし、GitHubを本番ソフトウェアの提供基盤として使う組織にとって、障害時の前提を見直すきっかけにはなる。たとえば、次のような備えが考えられる。

• リポジトリのバックアップやミラーを維持する
• CI/CD設定を特定のホスティングサービスに過度に依存しない形で管理する
• 緊急リリース時の手順を文書化する
• SSO、Webhooks、ホステッドランナーが利用できない場合の運用を決めておく

こうした対策でプラットフォーム障害そのものをなくすことはできない。しかし、次のサービス停止が開発全体へ波及する範囲、いわゆる「爆発半径」を小さくすることはできる。

8月17日の障害について最終的な評価を下すには、GitHubのポストモーテムが必要だ。現時点で確実に言えるのは、リポジトリのダウンロードと複数の開発ワークフローに深刻な影響を与える、広範かつ連鎖的な障害が発生し、復旧は段階的に進んだということ。そして、その根本的な失敗原因は、まだGitHubから公表されていないという点である。