メモリスによる要約- GitHubで2026年8月17日夜、複数サービスに障害が発生し22時40分から7時間35分続いた
- 他サービスの復旧後も認証まわりの不具合が長引き、Copilotだけが最後まで復旧しなかった
- AIツールを選ぶときは処理性能だけでなく、基盤の認証設計や障害時の情報開示も見ておく価値がある
プルリクエストの画面が、いつまでも真っ白なまま動かない。プッシュしたはずのコードが、どこにも反映されない。Copilotに話しかけても、返事が来ない。2026年8月17日の夜、そんな光景が世界中のディスプレイに広がっていた。
止まっていたのは「GitHub」だった。世界中のエンジニアがソースコード(プログラムの設計図にあたるテキストデータ)を保存し、共同で編集するための基盤サービスで、日々のコーディング作業のほとんどがここを経由する。そのGitHubで、8月17日22時40分(日本時間、以下同)、複数サービスの障害が始まった。
GitHub Statusのインシデントページによれば、最初の投稿は「一部のGitHubサービスでパフォーマンスへの影響が報告されており、調査中」という短いものだった。数分のうちにAPIリクエストとActions(コードの自動テスト・自動デプロイの仕組み)に性能低下が広がる。そして23時31分、コード補完AI「Copilot」の可用性低下も確認された。最初の異変から、まだ1時間もたっていない。
Gigazineが伝えているとおり、影響はその後もPull Requests・Issues・Pagesへと広がっていく。GitHub Statusが最終的に公表した影響範囲は、Git Operations・Webhooks・API Requests・Issues・Pull Requests・Actions・Pages・Copilotの8サービスにおよんだ。
翌1時16分の更新では、ウェブサイトの表示とAPI呼び出しで約20%、リポジトリのアーカイブダウンロードや生ファイル取得では約50%というエラー率が明かされている。認証を担うSAML・OIDCや、組織のアカウント管理に使うSCIM・Team Syncにも影響が及んでいた。この時点でGitHubは「根本原因の特定を継続中」としており、まだ何が壊れているのか自分たちでも掴みきれていなかった。
1時36分、GitHubは「問題のあるコンポーネントを特定し、是正措置を講じた」と発表し、1時59分にはAPI Requests・Actions・Git Operations・Issues・Pages・Pull Requests・Webhooksの7項目について「緩和した」と報告する。ここで話が終わっていれば、よくある夜間障害のひとつとして片づいただろう。
そうはならなかった。2時30分すぎ、Git Operationsが再び性能低下を報告し、6分後にはIssuesも同様の不調を訴えた。3時11分の更新で、GitHubは残っている問題を「散発的な認証エラー」だと言い直している。3時48分にはAPI Requestsまでもう一度崩れた。復旧は一直線ではなく、行きつ戻りつしていた。
4時13分、GitHubは認証トークンの再試行処理を一部無効化し、様子を見ていると報告する。5時08分になっても、まだ「Copilotの認証で散発的な障害が続いている」という表現が消えない。このときGitHubがわざわざ書き添えていたのが、「GitHub CLIやGitHub App経由のCopilot利用には影響がない」という一文だ。壊れていたのはCopilotの応答そのものではなく、特定の入り口の認証だけだった。5時45分に「30分以内の完全復旧見込み」と予告され、実際に6時15分、インシデントは解決を宣言された。22時40分の第一報から、7時間35分が経過していた。
他のサービスが軒並み「正常化」を報告し終えたあとも、Copilotの認証だけは深夜から明け方まで居座り続けた。ここに、AI機能を評価するときに見落としやすい点がある。Copilotが不安定になったのは、AIの応答生成そのものが壊れたからではない。土台になっている認証基盤が揺れたことに、後から巻き込まれた形だ。AI機能の可用性は、AI機能自身の設計より先に、それが載っている基盤の設計に規定される。
これは会議の録音や文字起こしを預けているAIツールにも、そのまま当てはまる話だ。tl;dvのデータベース設定不備が明らかにしたのも、AI議事録サービスの実力を決めるのは文字起こし精度だけでなく、裏側のクラウド基盤の設計だという事実だった。録音を終えてからAIに渡し、数分で要約が仕上がるという処理の流れを取っている以上、メモリスも含めて、経由先のどこかが止まればその影響を受けうる構造は共通している。
具体的に何を確認すればいいか。GitHubが今回示したのは、障害発生から数分刻みでコンポーネント単位の状況を更新し続けるステータスページの運用だった。会議録音や文字起こしを預けるAIツールを選ぶときは、同じようなステータスページを公開しているか、障害時に「何が止まり、何が動き続けるか」をどこまで具体的に書くかを、事前に見ておく価値がある。LG gramに搭載されたオンデバイス文字起こしや、YOMELの録音端末保持機能のように、クラウドが止まっても録音そのものは手元に残る設計を選んでおくのも、同じ発想の備えになる。
根本原因の分析は、GitHub自身が「入手でき次第共有する」としており、本稿執筆時点でもまだ公開されていない。何が壊れたのかが判明する前に、何が最後まで壊れなかったかを見ておく方が、次に同じことが起きたときの備えになる。
あわせて読みたい： AI議事録tl;dv、18万件超が公開状態に｜LG gramがオフライン文字起こしに対応、ActionPowerの軽量AIで実現｜YOMELに省データモード、録音を端末保持｜「サーバーに残さない、AIに学習させない」AIレコーダー「Oxtak」開発者に聞く録音データの安全性