世界を動かす技術を、日本語で。

プルリクエスト、イシュー、Git操作、APIリクエストに関するインシデント

概要

  • GitHub のサービスでパフォーマンス低下が発生
  • 影響範囲は Git操作、APIリクエスト、Issue、Pull Request
  • 問題は 2026年5月27日 に発生
  • 現在は 完全復旧
  • 詳細な 原因分析 は後日公開予定

GitHubサービス障害の概要

  • 2026年5月27日、GitHubにて パフォーマンス低下 の障害発生
  • 影響を受けた機能
    • Git Operations (Git操作)
    • API Requests (APIリクエスト)
    • Issues (課題管理機能)
    • Pull Requests (プルリクエスト)
  • 12:10 UTC に初報、障害調査開始
  • 12:54 UTC、障害が継続していることを確認
  • 13:16 UTC、障害の完全解消を報告

今後の対応

  • 詳細な原因分析(Root Cause Analysis) を後日公開予定
  • 利用者への 謝意と理解への感謝 を表明
  • 障害発生時の 迅速な情報共有 を継続

利用者への影響

  • 一時的な Git操作やAPIリクエスト遅延
  • IssueやPull Request の閲覧・操作に支障
  • 現在は 全サービス正常稼働

Hackerたちの意見

https://isgithubcooked.com いつもこういう事件のコメントではGHを擁護してるんだけど、今月は彼らの基準でもかなりひどいね。重要なコンポーネントをフィルタリングしても、セブン2や3を除いても。

5月は重大な問題が続出してる。時間が経つにつれて悪化してる気がする。

マイクロソフトが買収した後、何か一つでもうまくいったことある?

もうダメだね。マイクロソフトが買収してからずっとこうだし、2023年の前からもひどかった。今の時点でGithubの不安定さに悩むくらいなら、自分でGitLabやForgejo、Codebergをホスティングした方がマシだよ。プラットフォームの明らかな無視と不注意を考えると、擁護のしようがない。

あのページのUI、めっちゃいいよね。GitHubの競合を作ったらいいのに。ユーザープロフィールや貢献、PRのUXがほぼ「ハブ」製品の全てだから、gitは完全に別のオフラインアプリだし。

“ストリーク”って、連続稼働日数のこと?それとも、少なくとも1回のダウンタイムがあった日数のこと?後者だと思うんだけど :]

あんなペースで問題のポストモーテムをするのは物理的に無理だよね。OpenClawを導入すべきだと思う。

フライトレーダー24で絵を描くパイロットみたいに、全サービス - クリティカルでフィルタリングすると、5月には誰かがスワスティカを描こうとしてたのが見える… AIエージェントたちが反乱を起こしてるの?

見た中で、GitHubのダウンタイムに関するサイトやグラフの中で、これが一番衝撃的だと思う: https://damrnelson.github.io/github-historical-uptime/ 残念ながら、新しいデータで更新されている様子はないけど、もし更新されてたとしても、GHの状況は良くならないだろうね。

クリックする前は、数日前の事件のまとめだと思ってたんだけど、全く新しい事件だったね。

昨日のやつだと思ってた!バカな俺。

俺だけかな?AIコーディングが普通になってから、信頼できるサービスでの障害がめっちゃ増えた気がする。Supabaseは数週間ごとにダウンするし、Cloudflareもそう。で、今はGithubも。

あなただけじゃないよ。未レビューの雑なものが本番に行ってるのか、雑なものの生成による需要の増加なのか、ちょっと不明だね。

いや、あなただけじゃないよ。何が起こってるかはかなり明らかだよ。いつものエンシティフィケーターたちが、エンシティフィケーションのスピードを100倍にする素晴らしいツールを手に入れたから、こういうクソみたいな障害が毎日のように起こってるんだ。

俺のせい? いや、もちろん違うよ。

そうだね、それがサービスの利用を急増させたから。GitHubはAzureで動いてるし、AzureはAIのせいでキャパシティに負担がかかってるから、GitHubのサービスは自動スケールに苦労してるんだ。

いや、みんなが大丈夫だって思ってるフリしてるだけ。実際は、誰も何も気にしてないよ、本当に。

その通り。もう気をつけるインセンティブなんてないよね。だって、LLMに直させればいいんだから。

確かに outages(障害)は増えてるけど、問題はその障害がプロバイダーがLLMを使って製品を作ってるせいで、以前の品質を提供できてないのか、それともLLMが全く新しいユーザーベースを生み出して、無料プランでプロジェクトを展開してるから、成長に追いつけなくなってるのかってことだよね。新しい無料ユーザーの流入が、彼らの混合計算(無料 vs 有料)をめちゃくちゃにして、利益を失わずにスケールできなくなってるんじゃないかな。多分、両方の要素が混ざってると思う。

これ、マジでおかしいよ。特に気になるのは、ウェブUIとAPIの両方でプルリクエストがすべてのコミットやブランチの変更を一貫して反映してないこと。フルのdiffを確認せずに何かをマージしちゃうのが簡単になっちゃう。

うん、最近何回かあったんだけど(ステータスページのインシデントとは関係なさそうなやつ)、PRを開くのに20分から1時間も待たなきゃいけなかった。GitHubが自分のブランチにベースブランチと比べて新しいコミットがあるって認識しなかったから。

エージェントが開発した世界の一端を味わってみて。

AIがソフトウェアを食べる前に、まずGHとマイクロソフトを食べるみたいだね。

ヒョウが顔を食べるなんて思わなかったんだね!

まだ影響が残ってるのに、インシデントを解決済みってマークしないでほしいな。例えば、俺のコミットがブランチに表示されなかったり、アクションが実行されなかったり。前回と同じ問題だし、キャッシュをリフレッシュする必要があるっていうメッセージを上に表示してほしいな(言葉は違ったかもしれないけど)。

誰かがこの第三者の「正直な」ステータスページをリンクしてたよ: https://mrshu.github.io/github-statuses/ 自分のGitHubの経験に照らすと、こっちの方が正確な気がする。

請求機能が少なくとも3つの9が維持されてるのは良いね。

まあ、重要な成長はフリーミアムの利用から来てるよね。ビジネスを支えるものがないのに、たくさんのバイブスがアクションを引き起こしてる感じ。だから、収益は他の成長に追いついてないし、請求システムもストレスを感じてない。

新しいPR: GitHubのソフトウェアとインフラを2018年6月1日のバージョンに戻す。新しいPR: 新規ユーザーのサインアップを6ヶ月間停止。人事の取り組み: 今後の全KPIは自動的に99.9%の稼働率を要求する。年次の稼働率が目標を下回った場合、成果に関係なく全てのボーナスは没収。人事の取り組み: CEOとCTOを解雇。

新しいPR: GitHub APIを無効にする。新しいPR: 使用を予測可能にするために、認証を通じて(AI)ボットをブロック。

GitHubにはCEOがいないよ。

財務の取り組み: マイクロソフトの買収を取り消す。

https://mrshu.github.io/github-statuses/