GitHub、99.9%の可用性維持すら厳しい状況

 (theregister.com)
4 ポイント 投稿者 GN⁺ 2026-03-24 | 5件のコメント | WhatsAppで共有
  • 最近、GitHubのサービス障害が頻発しており、業界標準の 「5 nines（99.999%）」 はおろか、「3 nines（99.9%）」 の達成すら難しい状況
  • 2月9日には Actions、Pull Request、通知、Copilot などの主要機能で同時障害が発生し、一部サービスでは 数時間以上の遅延 が発生
  • Copilotのポリシー伝播の問題 により、一部ユーザーは2月10日午前まで モデル表示エラー を経験
  • GitHubが ステータスページの構造を変更 したことで、直近90日間の 可用性追跡が難しくなり、非公式データでは 可用性が90%未満となった時点 も確認されている
  • Enterprise Cloud SLAは99.9%のアップタイム を明記しているが、実際にはすべてのユーザーに保証されておらず、ダウンタイムを前提にした運用戦略 の必要性が高まっている

GitHubの可用性低下と頻発するサービス障害

  • クラウドサービスの障害頻発 が一般化する中、GitHubもまた安定性の問題を抱えている
    • 「1日たりとも障害のない日は珍しい」といった表現も出ており、「5 nines（99.999%）」 はもちろん、「1 nine（90%）」 すら難しい状況だと述べられている
  • 2月9日（UTC基準）、GitHubの主要機能である Actions、Pull Request、通知、Copilot がすべて障害を起こした
    • GitHubは15時54分ごろ、「一部サービスに問題がある」と告知し、通知の遅延が約 50分 に達すると発表
    • 17時57分には遅延が約30分まで縮小し、19時29分に復旧したと通知
  • Copilot関連の障害 はさらに長く継続した
    • 2月9日16時29分から2月10日9時57分まで、一部ユーザーで Copilotのポリシー伝播の問題 が発生
    • その結果、新たに有効化されたモデルがユーザーに表示されない現象が報告された
  • GitHubは ステータスページの構造を変更 し、直近90日間の 可用性追跡が難しくなった
    • 詳細情報は提供されるものの、全体的な アップタイムの傾向を視覚的に把握しにくい形 に変わった
    • 非公式の復元ページ（mrshu.github.io/github-statuses/）のデータでは、2025年に一時可用性が90%未満に低下 した時点も確認されている
  • GitHubの Enterprise Cloud SLAは99.9%のアップタイム を明記しているが、すべてのユーザーにそれを保証しているわけではない
    • 業界では 「5 nines」が理想的な基準 と見なされる一方、一部ベンダーは 90%の維持すら難しい現実 にあると評価されている
    • こうした状況は、顧客がダウンタイムを前提とした運用計画を用意すべき ことを示唆している

関連する文脈と事例

  • GitHubは最近、AI機能とポリシー変更 をめぐって複数の論争を経験している
    • Pull Requestに対する AIコード遮断用の「キルスイッチ」 の検討

    • セルフホストランナー料金プラン計画の撤回

      • Zig言語プロジェクトがMicrosoftのAI中心政策を理由にGitHubを離れた事例 が存在
      • こうした出来事とあわせて、サービス安定性の低下 が開発者コミュニティの不満を強める要因として作用

結論

  • GitHubの最近の障害は、「3つの9（99.9%）」すら達成が難しい可用性の問題 を浮き彫りにしている
  • Copilotなど中核機能の不安定さ が続く中、クラウドベースの開発プラットフォームの信頼性確保 が重要課題として浮上
  • ダウンタイム対策の戦略策定 の必要性が改めて強調されている

関連記事

5件のコメント

 
elbanic 2026-03-26

GitHubは無料サービスなのに、高可用性を期待すること自体が…
 
cosine20 2026-03-27

カカオトークで障害が起きても同じことをおっしゃるんでしょうか…
 
malkeu 2026-03-26

git reset --hard すればよさそうですね
 
master6559 2026-03-25

GitHubで障害さえ起きなければ、今のままでいいんだけど
 
GN⁺ 2026-03-24
Hacker Newsの意見

  • GitHubの稼働率(uptime)の問題は間違いなく深刻だが、すべての機能が同時に止まったからといって「GitHub全体が落ちた」と言うのは言いすぎだと思う
    私はCopilotをほとんど使わないので、そのサービスが頻繁に止まっても気にしない
    本当に重要なのは    Git、Webサイト、API、Actions    のような中核機能の安定性だ

    • 同意する。だが過去90日間で、どの個別サービスも**3x9(99.9%)**の稼働率を達成できていない
      GitHubのEnterprise SLAではサービスごとに最低99.9%を保証しているが、実際の数値はこちらで確認できる
    • 「GitHubが落ちた」という表現が誇張なのは確かだが、実際にはAPIですら99.69%、つまり9が2つしかない
      Copilotは9が1つの水準で、中核サービスであるGitとActionsも同様だ
    • この会社は時価総額1兆ドル規模のグローバル企業のポートフォリオに属している
      これだけのリソースを持つ会社が顧客を放置するのは言い訳の余地がない
    • 最近大企業が口にする「5 nines」はほとんど幻想だ
      実際にはエラー応答であっても「正常動作」として計算している
      ネットワーク業界のように本当に99.999%を達成するケースはまれで、ほとんどはデータのスライシングのトリックでステータスページを緑に保っている程度だ

  • 2025年にGitHubのCTOが「Azureへ全面移行して信頼性を高める」と発表したときから不安だった
    以前はコミュニティが「新機能をもっと速く追加しろ」と叫んでいたが、今は安定性と信頼性のほうが切実だ

    • それでもGitHubは新機能追加の速度も相変わらず遅い
    • 大規模プラットフォームだけにこだわらないなら、小さくて退屈なくらい安定した代替手段も存在する
    • 私はその時期に参加したが、自分のリポジトリを公開で共有できるというだけで新鮮だった
    • 全体としては業界全体の安定性は良くなったが、今は無数の依存関係が絡み合っていて、一か所に問題があるだけで全体が揺らぐ
    • Azureへ完全移行する際にIPv6アクセスをうっかり忘れてくれることを願っている

  • GitHubは今、Azure移行、AIベースのインフラ変更、AIトラフィックの急増という三重苦を抱えている
    人気プロジェクトでは、Issue登録から数分でAIが作った数十件のPRが押し寄せる
    こうした負荷に耐えるのは難しく、AI以前の「N 9s」と以後の「N 9s」では難易度がまったく違う

    • その通り。GitHubはもともとこうしたAIエージェント暴走環境を前提に設計されていない

  • GitHubのステータスページを見ると、実際には90.21%、つまり9が1つの水準だ
    過去の2019年アーカイブでは月に1〜4件だった障害が、今では1日1回ペースになっている

    • この数値が悪い理由は、単なるダウンタイムだけでなく**性能低下(degraded performance)**も含んでいるからだ
    • それでもClaudeのstatus.claude.comよりはましだと冗談を言う人もいた

  • GitHubがAI機能に執着している間に、プラットフォームのセキュリティは崩れている
    最近Aqua Securityが攻撃を受け、複数のリポジトリが感染したが、これはGitHub Actionsのmutable reference脆弱性を悪用した事例だ
    GitHubはこの問題を認識していながら修正していない

    • 当面の対策としては、Actionsのバージョンを**ハッシュで固定(pin)**するのがよい
      例: uses: actions/checkout@11bd7190...
      自動化ツールはmheap/pin-github-actionを参照
    • CI/CDはYAMLベースの複雑さのせいで過度にもつれたと思う
      昔はJenkinsでデプロイし、簡単なテストはスクリプトで処理していたが、今では分散したYAML地獄になってしまった
    • 「スイスチーズより穴が多い」と言われるほど、GHAのセキュリティは深刻だ
    • こうした問題を何年も放置してきたコミュニティ議論もある

  • 90%の稼働率はすべてのサービスを含んだ数値なので、実際の体感は異なるかもしれない
    だがCopilotの96.47%ですら9が1つにすぎない
    GitHubは「すべての機能を一緒に使え」と勧めるが、そうするほど    信頼性は急激に低下する

    • しかも「遅いが動いている」ケースは統計に含まれない
      たとえば単純なPR diffを開くのにも30秒以上かかる
    • 一部の障害は公式に遅れて報告されることもある
      CI/CD、git、PR機能がすべて止まった事例もあった
    • 2019年のデータと比べると、今は10倍以上悪化している
    • 96%は本当にひどい数値だ

  • GitHub Enterprise Serverを自前で運用した立場からすると、こうした問題は驚きではない
    アクティブ-アクティブ非対応、ダウンタイムなしのアップグレード不可、ロールバック不可など、基本的な高可用性要件を満たしていない
    バグがあればバックアップ復元以外に方法がなく、その過程でデータ損失が発生する
    こうした製品を高額顧客に販売していること自体が、可用性への無関心の証拠だ

    • うちの会社も結局GHESを諦めてGHECへマイグレーションした

  • Microsoftには良い製品を台無しにする才能がある
    Skypeが代表例で、WindowsやNotepad、Explorerも同じだ
    Office → Office 365 → Microsoft 365 → Copilot 365へと続くブランドの混乱もひどい

    • 「GitHub for Business」が出る日も近そうだ

  • うちの会社ではPRごとにGitHub Actionsでセキュリティスキャンを回している
    GitHubが止まるとセキュリティゲートも止まり、開発者が検証なしでマージしてしまう
    こうした状況で脆弱なコードが流入しているのに、GitHubはCopilotにばかり人員を注いでいる

    • これに関する公開事例があるのかと尋ねる人もいた

  • IPv6軽視はGitHubの技術的な杜撰さを象徴している
    より大きな問題は、なぜこの状態でもセキュリティ監査を通過できるのかということだ
    GitHubのセキュリティ文書を見ると、形式的な水準にすぎない

    • 監査の品質もアーキテクチャの水準と同じくらいお粗末だ