GitHub.comで8月17日13時40分（UTC、日本時間22時40分）に始まった障害は、リポジトリを開けないという一点に収まらなかった。GitHubはWeb体験とAPIで約20%のエラー率を報告し、アーカイブのダウンロードとRawリポジトリコンテンツの取得では約50%が失敗したとしている。SAML/OIDC認証やSCIM、Team Syncも影響を受け、開発者がコードを読む経路から企業アカウントのアクセス管理、CIまでが同じ時間帯に揺れた。
もっとも、約50%という数字を「git cloneの半分が失敗した」と読むのは誤りである。影響を受けた機能の分母を分けなければ、利用者が取るべき代替手段も、GitHubが復旧後に説明すべき障害範囲も見失う。20時45分（UTC、日本時間18日5時45分）の公式更新では主要機能はおおむね復旧したものの、障害は「critical（重大）」かつ「investigating（調査中）」のままで、一部アプリでCopilot認証の失敗が残っていた。
13時40分から20時45分、緩和後にも起きた再悪化
GitHubは13時45分（UTC、日本時間22時45分）、Pull RequestsやIssuesを含む複数の操作で約20%のエラー率を確認した。14時04分（UTC、日本時間23時04分）には、Web体験とAPIが約20%、アーカイブとRawリポジトリコンテンツの取得が約50%のエラー率だと説明を更新している。後者は、同じ「リポジトリ取得」に見えても、Git操作全体を測った数字ではない。
影響は認証系にも及んだ。SAML/OIDC、SCIM、Team Syncが障害対象に加わり、14時31分（UTC）以降はCopilotが「major outage（大規模停止）」へ移った。14時49分から15時01分（UTC）にかけては、Issues、Pull Requests、Actions、API Requestsがそれぞれ「major outage（大規模停止）」となった。PagesとGit Operationsは「degraded（性能低下）」または「partial outage（一部停止）」で、開発チームではレビューから公開までの各経路が別々のタイミングで不安定になった。
16時36分（UTC、日本時間18日1時36分）、GitHubは問題のあるコンポーネントを特定し、是正措置を取ったと発表した。16時59分（UTC）には、API Requests、Actions、Git Operationsを含む対象サービスの劣化を緩和したとしている。ただし復旧は一直線ではなく、Git Operationsは17時30分から18時23分（UTC）、API Requestsは18時48分から19時01分（UTC）に再び悪化した。Issuesが正常化したのは20時22分（UTC）である。
20時45分（UTC）の更新時点では、一部アプリでCopilot認証の失敗が残った。GitHub CLIとGitHub App経由のCopilot利用は、この残存する認証障害の影響を受けないとGitHubは説明している。ただし、これは障害全時間帯のCopilot利用が無影響だったという意味ではない。同社は30分以内の全面回復を見込んだが、その時点では解決済みになっていなかった。
約50%が指すのはアーカイブとRawの取得
GitHub Docsによれば、ソースアーカイブはブランチ、タグ、コミット時点のスナップショットをtarballまたはzipballで生成する。完全な履歴を含まない配布物であり、履歴を含むリポジトリを取得する方法としてはcloneを案内している。したがって、今回の約50%はアーカイブとRawリポジトリコンテンツのダウンロードに限った当時の概算である。
GitHubはGit Operationsも性能低下としたが、Git操作についてのエラー率は公表していない。約20%も、障害時間全体の平均値、地域別の値、契約別の値ではなく、当時のWeb体験とAPIに関する概算だ。全リポジトリの取得が半数失敗した、あるいはgit cloneが半数失敗したといった表現は、公式の影響範囲を超えてしまう。
この区別は実務で効く。アーカイブをCIの入力やリリース配布に使うケースと、履歴を含むcloneを使う開発環境では、同じリポジトリにアクセスしていても、障害時に確認すべき経路が異なるからだ。障害対応では「GitHubが遅い」という一括りの報告より、Web/APIの応答、コンテンツ取得、Git Operationsのどこで失敗したかを分けて記録する必要がある。
コード取得から企業認証まで広がった影響範囲
SAMLのシングルサインオンは、アイデンティティプロバイダーを通じてEnterprise内のリポジトリ、Issues、Pull Requestsへのアクセスを制御する。SCIMはユーザー管理、Team SyncはIdPのグループとGitHub Teamの所属を同期する機能だ。GitHubは今回、SAML/OIDC認証、SCIM、Team Syncを障害の影響範囲として報告した。画面やAPIに加え、組織のサインインと権限反映も不安定になる経路が存在したことになる。
たとえば、入社者へのアクセス付与や退職者の権限削除は、IdP側のグループとGitHub側のチームを同期する運用に依存する。SAML/OIDC、SCIM、Team Syncが同時に影響範囲へ入れば、コードを取得できるかとは別に、誰が組織資源へ入れるかという手続きも滞る可能性がある。もっとも、GitHubは個別顧客の実害件数を公表していないため、どの運用がどの程度止まったかまでは分からない。
Actions、Webhooks、API Requestsの障害も同じ問題を広げた。認証済みの利用者がいても、push後の自動実行、外部サービスへの通知、APIを使う社内連携が止まれば、開発の流れは途中で切れる。今回の影響範囲は、コードホスティングの可用性を、保存データの有無だけでは測れないことを示した。
専用基盤への移行後も、利用者向け経路は影響を受けた
GitHubが7月に公表した可用性報告では、同月に8件の障害があった。Azure Central USが処理するモノリスの読み取りトラフィックは7月28日に52.75%へ達し、Azureで処理するGitトラフィックは47%と、6月の43%から増えた。公式文はこの47%をCentral USに限定していない。全リポジトリの29%は同地域に2つ目のレプリカを持つという。さらに専用のユーザーサービスはピーク時に毎秒100万件を超えるクエリを共有経路から外し、主要な認可検索処理の80%を分離済みの経路へ移したとしている。
リポジトリコンテンツについても、GitHubはCentral USの専用基盤から全面配信していると説明していた。それでも今回、アーカイブとRawコンテンツの利用者向け経路では約50%の失敗が発生した。保存・配信基盤を専用化しても、認証や要求処理を含むエンドツーエンドの経路まで障害から完全に分離できるとは限らない、というのがこの組み合わせから導ける範囲である。問題のコンポーネントや根本原因が未公表のため、専用基盤そのものが原因だったとは言えない。
GitHub CTOは2025年10月に容量を10倍へ増やす計画を始め、2026年2月には将来30倍の規模を前提にする必要があると判断したと説明している。2025年12月後半からエージェント型の開発フローが急増し、Pull RequestがGitストレージやActions、検索を経て、APIやバックグラウンドジョブまでを横断する負荷を持つようになったという。同社は高負荷時、キューの滞留やキャッシュミスからデータベース負荷と再試行トラフィックが増幅し、遅い依存先が複数の利用体験へ波及するとみている。そのため、重要サービスの分離と単一障害点の削減、障害時にも一部機能を保つ設計を進めてきた。これらは今回の原因説明ではなく、GitHubが以前から対処しようとしてきた障害の広がり方である。
根本原因は未公表、障害分析で確かめる分離の実効性
GitHubが公表したのは、問題のあるコンポーネントを特定して是正措置を取ったという段階までだ。Azureへの移行、AI開発の負荷、認証トークンの再試行が今回の根本原因だったと断定できる情報はない。データが失われなかったという発表も、20時45分（UTC）時点では出ていない。
同社の7月報告では、当四半期にCentral USで読み取りトラフィックの70%、書き込みトラフィックの30%を処理し、2026年末までにGitHub.comの本番トラフィックを自社データセンターから移す目標を掲げた。これは進行中の計画であり、完了を示す数値ではない。今回の障害で確かめるべきなのは、移行率の高さそのものではなく、特定コンポーネントの不調がWebから自動化までの各経路へどう広がり、再試行やフェイルオーバー、サービス分離がどこで機能したかである。
最終的な解決時刻と障害分析が出れば、約20%と約50%がどの時間帯のどの経路を表すのか、再悪化を招いた条件が何だったのかを照合できる。障害が未解決だった20時45分（UTC）時点では、その説明を待つほかない。
