GitHubが止まった日 — 開発の世界が一社に懸かっているということ
GitHubが止まった日 — 開発の世界が一社に懸かっているということ
GitHubがまた止まった。だが本当の問いは「なぜGitHubが落ちたか」ではなく「なぜ一社のデータセンター一つが世界中の開発パイプラインを同時に止められるのか」である — これはGitHubの技術的失敗なのか、それとも我々全員が利便性のために集中を選んだ代償なのか。
導入 — ロードバランサー数台が止まった7時間47分
2026年8月17日、UTC基準で13時28分から21時15分までの7時間47分、GitHub.comが不安定になった。Issues、Pull Requests、API、Actions、そしてCopilotが同時に遅延し、あるいは失敗した。GitHubが事後に公開したインシデントレポートによれば、ピーク時のWeb・APIエラー率は約20%で、アーカイブのダウンロードとraw リポジトリコンテンツのダウンロードは約50%まで跳ね上がった。SAML・OIDC認証、SCIM、Team Syncまで影響を受け、データレジデンシーを使うGitHub Enterprise CloudのActionsワークフローのうち、GitHub.comにホストされた公開ステップ定義に依存するものも一緒に止まった。
開発者にとってGitHub障害は「サイトが一つ開かない」だけの出来事ではない。コードのプッシュ、CIビルド、デプロイパイプライン、パッケージのインストール、ログイン、そして今やエディタ内のAI補完まで、一日の作業フロー全体が一度に止まる。同じ日、Hacker Newsには障害スレッドとは別に「Ask HN: GitHubの代替は何か」という問いが立ち、421件のコメントが付いた。障害が復旧する前から、人々はすでに次の問いへと移っていた — 我々はなぜこれほど一社に懸かっているのか、そして抜け出す道はあるのか。本稿は二つを切り分けて見る。まず何がいつどう止まったか(事実)、次になぜ我々がこの構造に至ったか(分析)である。
現象 — 何が止まったか、そしてボトルネックはなぜ認証だったか
まず事実関係である。GitHubの事後レポートを時系列でたどると、この日の障害の形がはっきり見えてくる。14時58分頃にWeb・APIトラフィックのエラー率が約20%に達し、15時台にはAPI・Pages・Gitオペレーション・Webhooksが順に性能低下として表示された。16時36分に米国中部(Central US)データセンターが回復したことで大半のサービスは正常に戻ったが、Actionsは約18時03分まで低下状態が続き、Copilotトークンサービス(Copilot Token Service)は21時02分にようやく完全回復した。つまり単一の障害ではなく、回復のあとも尾を引いた残存失敗が数時間を余分に引き延ばした出来事だった。
原因の構造は教科書的なカスケードである。レポートによれば、直接の引き金は米国中部ロードバランサーのネットワーク飽和だった。トラフィックが新たなピークを記録し、そもそもそれを引き起こしたのは、Istioのサイドカーポッド一つが並行性の限界に達したのに、オートスケーリングポリシーが誤設定されていて正しく拡張できなかったことだった — ポリシーがホストサービスの限界は監視していたが、サイドカーの限界は監視していなかったというのである。この一つの失敗が横へ広がり、最終的に四台のHAProxyノードがフロー限界を使い切り、ゲートウェイの認証パスが崩れて広範な認証遅延と失敗が発生した。そこへ「楽観的なリトライロジック(optimistic retry logic)」が事態を悪化させた。失敗した要求をクライアントが繰り返し投げ直すと、内部ロードバランサーがさらに大きく過負荷になった。
この点こそが核心である。障害はリポジトリサーバーが死んだからではなく、認証という共通の関所が塞がったことで全方位に広がった。認証トークンはGitHubのほぼすべての製品が必ず通らねばならない関門である。トークン発行が遅れれば、IssuesもPRもActionsもCopilotも同時に認証に失敗する。GitHubは失敗していたトラフィックの一部を中部から北バージニア(Northern Virginia)へ移して処理したが、今度はそちらでリトライの嵐が起きた。圧巻はその嵐の正体である。ある内部エンドポイント一つの応答が遅延すると、VS Codeに潜んでいたリトライのバグが発動してトラフィックを約10倍に増幅させ、これがCopilotトークンサービスの回復を遅らせた。レポートの数値がこの増幅をそのまま示している — 平常時は毎秒7~9千件だったCopilotトークンサービスのトラフィックが、毎秒7万~10万件へ跳ね上がった。
復旧の手法自体も示唆的である。問題のHAProxyノード群を同時に一時停止させると即座に広範な回復が起き、北バージニアのリトライの嵐は二つの手で抑えた — ゲートウェイのリトライロジックをPRで一時的に縮小し、Copilotトークン要求をロードバランサー段で403として遮断したうえで、サイトごとにトラフィックを徐々に戻していったのである。さらにcodeloadエンドポイントを狙ったスクレイピング攻撃が重なり回復を妨げたという説明も付いた。GitHubが挙げた再発防止策は、オートスケーリングポリシーがサービスメッシュのサイドカーの並行性まで反映するよう直し、Istioの要求・並行性・スケーリングの限界を全面点検し、ゲートウェイとクライアントのリトライ・バックオフの限界を再検討し、トラフィックを10倍に膨らませたVS Codeのリトライ挙動を修正し、ロードバランサーの容量監視とリージョンフェイルオーバーの保護策を改善する、というものである。要するにこの日の障害は、一つの誤設定 → 認証ボトルネック → リトライ増幅という、大規模分散システムで最もありふれ、最も恐ろしい失敗モードだった。
深層 — なぜ開発の世界が一社にこれほど懸かるようになったか
技術的原因がカスケードだったとすれば、波及の大きさを決めたのは構造である。GitHubは時間をかけて、異なる層を一つの傘の下に束ねてきた。ソースホスティングに始まり、Issueトラッキング、コードレビュー(PR)、CI/CD(Actions)、パッケージレジストリ(GitHub Packages、そして2020年に買収したnpm)、アイデンティティと認証(「Login with GitHub」で無数の外部サービスがGitHubアカウントに依存する)、最後にAIコードアシスタント(Copilot)まで。各層を足すたびに利便は増したが、単一障害点(SPOF)の半径も一緒に大きくなった。この日、認証一つが塞がっただけでこれらすべての層が同時に揺れたのは偶然ではなく設計上の必然である。しかも2018年にMicrosoftが約$7.5B(75億ドル)規模でGitHubを買収して以降、GitHubは単なるコードホスティングではなく、Microsoftのデベロッパーエコシステム戦略(Azure、VS Code、Copilotへと連なる)の中心に置かれた。集中は会社の失策ではなく、事業モデルそのものである。
では、なぜ皆が離れられないのか。Hacker Newsの「Ask HN: GitHubの代替」議論がこの摩擦をよく映し出している。最も頻繁に推薦された代替はForgejoだった。議論では、ForgejoはGiteaから分岐したコミュニティ主導のフォークで、単一バイナリにPodmanやDockerで手軽に載せられるため、コストに敏感なチームに魅力的だという評価が出た。Giteaは速く管理も楽だがGitLabほど機能が揃っていないという指摘、GitLabセルフホストのCommunity Editionは機能が豊富な代わりにリソースを多く食い保守負担が大きいという指摘が続いた。CodebergはForgejoで動く無料の公開インスタンスで、AI生成コードに対する強硬な方針で話題になったという言及もあった(この方針をめぐっては「とんでもない参入障壁だ」という反応と「合理的なコミュニティ保護だ」という反応に割れた、というのが議論の要点である)。このほか、メールベースのワークフローのミニマルなSourceHut、そしてRadicleやTangledといった実験的な非中央集権の代替が挙がった。
問題は代替の存在ではなく、移行の摩擦である。議論で繰り返し出た摩擦点を整理するとこうなる。第一に、ネットワーク効果だ。プロジェクトがGitHubになければ発見されず、協力者が移住を渋るという指摘である。第二に、CI/CDのロックインだ。GitHub Actionsが事実上のベンダー依存を作り、代替は互換をうたうが機能の同等性は不完全だという(ある参加者がActionsを「誰かが幻覚状態で作った科学実験のようだ」と皮肉った一節を議論は印象的に引いていたが、これは揶揄であると同時に、それだけ置き換えが厄介だという裏返しでもある)。第三に、セルフホストの運用コストだ。保守・セキュリティパッチ・ランナー管理に専任の人手が要り、ある会社は数年にわたり自動アップグレードを回しながら何度も破壊的変更(breaking change)に遭ったという経験談が寄せられた。第四に、機能の空白だ。Forgejo・Giteaにはフェデレーション(federation)がなく、インスタンス間の協業が制限されるという指摘である。重要なのは、議論のかなりの部分が「GitHubが勝ったのは単にネットワーク効果ではなく、実際により良い開発者体験(DevX)を提供しているからだ」という実用主義の立場を取ったことだ。代替は機能だけでなくDevXそのものを追いつかねばならない — そしてまだ大半はそこに達していない、というのが冷静な現実認識だった。
ここにgit自体の皮肉が重なる。gitは本来、非中央集権の分散バージョン管理システムである。すべてのクローンが完全なリポジトリの複製を持つ。ところが我々はその上にIssues・PR・CI・アイデンティティ・AIを載せた「フォージ(forge)」を中央集権化し、そのフォージがすなわちGitHubなのだ。コード履歴は分散していても、協業の社会的な層の全体が一箇所に集まっている、という格好である。だからGitHubが止まると、gitが非中央集権だという事実は慰めにならない。ローカルにコミットはできても、PRもレビューもCIもデプロイも回らない。
展望 — ヘッジの方向: ミラーリング、セルフホスト、そしてAIが育てる集中
では実務者は何ができるか。Hacker Newsの議論で最も実用的な提案は「ミラー・アンド・ミラー(mirror-and-mirror)」戦略だった。Forgejoのようなセルフホストインスタンスを一次に置いてGitHubを二次のミラーに使うか、その逆に置くかの折衷案である。実際、6年以上セルフホストインスタンスを運用したある参加者は、GitHubクラウドより「ダウンタイムがはるかに少なかった」と証言した — もちろんその代償に運用負担を自ら背負った。反対側には、GitLabのランナーが「最大の失敗地点」で細かな管理が要るという不満もあった。つまりセルフホストは可用性を自分の手に握る代わりに、その可用性を維持する責任まで丸ごと引き受けるトレードオフである。万能薬ではない。
今回の障害が与えた具体的な教訓は、より狭く実践的である。第一に、認証を自分のデプロイパイプラインのクリティカルパスに置くな。GitHubのログインやトークン発行が死ぬとデプロイが死ぬ構造なら、それは他人のSPOFを自分のSPOFとして相続したことになる。第二に、依存をキャッシュしベンダリングせよ。npmやコンテナレジストリがGitHub系に懸かっているなら、社内のプロキシやミラーにパッケージをキャッシュしておくことが、障害時のビルドを救う。第三に、リトライにバックオフと上限をかけよ。この日の災いを大きくしたのは、まさに上限のない楽観的リトライだった。皮肉にも、GitHubを崩した失敗モードが、そのGitHubに依存する我々のシステムにもそのまま潜んでいるかもしれない。第四に、復旧の順序をあらかじめ定義せよ — 何から蘇らせるか分からなければ、回復のあとも残存失敗が数時間を引き延ばす。
一方でAIは、この集中を和らげるのではなく深める方向に働く。Copilotがエディタに深く食い込むほど、GitHubエコシステムの粘着力は増す。今回の障害が象徴的なのは、VS CodeのリトライのバグがCopilotトークンのトラフィックを10倍に膨らませ、回復を遅らせた点である。クライアント(エディタ)とサーバー(トークンサービス)がAIという新しい軸でより密に結ばれることで、失敗の伝播経路も一つ増えたわけだ。楽観シナリオでは、今回の事故がリトライ・オートスケーリング・フェイルオーバーに対する業界全体の覚醒につながり、ミラーリングとセルフホストが標準的な衛生として定着する。悲観シナリオでは、利便がまた勝ち、次の障害のとき我々は同じように驚く。その間の現実はおそらく、大きな組織はミラーとキャッシュで静かにヘッジし、大多数の個人や小規模チームはGitHubに残りつつ「いつか移らねば」と唱え続ける状態の持続だろう。
結論 — GitHubの失敗なのか、集中を選んだ代償なのか
リードの問いに戻ろう。この日の障害はGitHubの技術的失敗であると同時に、我々が集中を選んだ代償である。誤ったオートスケーリング設定一つが認証ボトルネックを生み、リトライの嵐がそれを増幅したのは、確かにGitHubのエンジニアリングの問題だ。しかしその問題がIssues・PR・CI・パッケージ・認証・AIを一度に麻痺させえたのは、我々がそれらすべての層を一社の一つの傘の下に喜んで集めておいたからである。前者はポストモーテムで直せる。後者はポストモーテムでは直らない。
だから残る問いは「GitHubを去るか」ではない。大半は去らないだろうし、去るべき理由も大半にはない — DevXとネットワーク効果は実在する価値である。本当の問いは「一社にどこまで懸けるか」だ。コード履歴はすでに分散しているのだから、少なくともデプロイを救うミラー一つ、依存を救うキャッシュ一つ、リトライを抑える上限一つくらいは自前で備えること — それが次の7時間47分を耐える最も安い保険である。gitは非中央集権として生まれた。その上に我々が中央を建てたのなら、その中央が揺れるときに備えるのも、我々の務めである。
出典: