2026年8月6日の深夜、世界最大のコードリポジトリサービスであるGitHubで大規模な障害が発生しました。自動化サービスであるGitHub Actionsが広範囲にわたって麻痺し、タスクのキュー待ちが数時間に及び、実行中のジョブも大量に失敗。WebホスティングサービスのGitHub Pagesのパフォーマンスも低下し、AIアシスタントCopilotによるコードレビュー機能も断続的に不具合を起こしました。この件に関するHacker Newsの投稿は、わずか8時間で299ポイント、253件のコメントを集めました。エンジニアたちはすぐに原因の手がかりを繋ぎ合わせました。プラットフォームを追い詰めたのは、まさにAIによるコード生成の急増でした。GitHubのCOO（最高執行責任者）Kyle Daigle氏が公開したデータによると、Actionsの週間実行時間は2023年の5億分から2025年には10億分へ、そして今週には21億分へと急増しました——わずか2年で4倍への躍進です。
非エンジニアの読者のために背景を説明すると、GitHubはプログラマー界のインフラであり、世界中のエンジニアがコードを保存し、数億個のプロジェクトでコラボレーションを行う場所です。スマートフォンにあるほぼすべてのアプリのコードがここを経由しています。Actionsはその上で動く自動化サービスであり、コード専属の自動執事のような存在です。開発者が一度ルールを記述しておけば、コードに変更があるたびに自動でテスト、ビルド、デプロイを行ってくれます。手動なら30分かかる作業を、マシンが数分で完了させます。
図：今回のGitHub障害に関する報道画像。出典：The Register
公式の障害記録によると、日本時間の8月6日夜11時過ぎからタスクの遅延とタイムアウトが発生し、成功率は一時30〜40%まで低下しました。公式側はアクセス制限をかけながら復旧を進めましたが、コード変更通知の15%しか通過できず、多くの変更が後続タスクをトリガーできませんでした。8時間後に成功率は99%に戻ったものの、CopilotやPagesには断続的な問題が残り、エンタープライズ向けのデータ移行サービスは一時停止を余儀なくされました。これは孤立した事象ではありません。7月29日にも同様のActions障害が発生しており、公式ステータスページによれば7月に26件、8月の最初の6日間でさらに6件の障害が記録されています。GitHubは4月の障害頻発について謝罪し、6月には幹部が構造改革を約束していたにもかかわらず、そのわずか1ヶ月後に再び崩壊したのです。
図：GitHub公式ステータスページの障害記録。性能低下から復旧まで約8時間。出典：githubstatus.com
障害報告書の中にある「作業用マシンが無効化されたタスクを割り当てられ、再試行の無限ループに陥った」という一文は注目に値します。分かりやすく言えば、マシンが失効した作業指示書を受け取り、実行後に無効と判明しても、再び指示書を取得しに行くとまた失効したものを渡されるという状態です。システムが混雑するほど無効なタスクが増え、悪循環が深まりました。これは高負荷システムにおける典型的な障害パターンです。
増加の源泉：AIが厨房の注文量を何倍にも膨らませた
公式の統計数字は極めて衝撃的です。2025年通年でGitHubが受け取ったコードコミット数は10億回でしたが、現在は1週間で2.75億回に達しており、このペースでは年間140億回に上ります。Actionsの実行時間は2年で4倍になりました。一般的な感覚に換算すると、週21億分という数字は、常に20万台以上のサーバーが世界中のエンジニアに代わってGitHub上で作業していることを意味します。週2.75億回のコミットは、平均して毎秒450回の頻度です。プラットフォームは毎秒450回ノックされ、そのたびにマシンを割り当ててタスクを実行しなければなりません。
図：Actionsの週間実行時間は2年で4倍に増大。週間のコミット数は2025年平均の約14倍に達する。データ出典：GitHub公式（COO Kyle Daigle）、筆者作成
この爆発的な増加はどこから来たのでしょうか？答えはAIプログラミングです。現代のAIアシスタントは自分でコードを読み、修正し、コミットし、テストを実行できます。1回のセッションで十数回のループを繰り返し、そのたびに一連の自動化タスクをトリガーします。以前は人間が1日に1〜2回コミットしていたものが、AIの代行により1日に数十回行われるようになりました。エンジニアコミュニティの集計によると、AIが作成したプルリクエストは昨年9月の月400万件から今年3月には1,700万件に急増。Claude Code単体でも毎週260万回のコミットを行っており、半年で25倍に増えました。人間がコードを書くのが「注文」なら、AIがコードを書くのは「厨房全体の注文量を一気に数倍にする」ようなものです。
注文が急増しても厨房が拡大されなければ、連鎖反応が起こります。Hacker Newsにおいて長年高負荷システムを手がけてきたエンジニア（cortesoft氏）がそのメカニズムを的確に説明しています。システム設計時には余裕を持たせてありますが、負荷が90%を超えると小さな変動が爆発を引き起こします。タスクがキューに溜まり、タイムアウトが発生し、クライアントが再試行し、その再試行がさらにキューを膨らませます。これは高速道路に似ています。交通量80%なら快適に走れますが、95%を超えると一回のブレーキが道路全体を大渋滞させます。同氏は「このような状況でマシンを追加しても意味がなく、ボトルネックは思いがけない場所にある」と指摘しています。
公式は修正中と主張、ユーザーは不十分と反発
双方の主張が出ています。GitHub公式はキャパシティの制限を認め、エンジニアが原因を特定し修正をデプロイ中であると発表しました。しかし有料ユーザーの不満は収まりません。自社サーバーを運用する企業ユーザーは「自前で費用を払って維持しているマシンすら丸一日停止した。有料サービスの品質がこれなのか」と嘆きました。2009年からGitHubを利用している古参ユーザー（zehaeva氏）はさらに厳しく指摘し、過去1年でGitHubの稼働率が「フォーナイン（99.99%）」から「ワンナイン（90%）」まで低下したとし、AI利用量の爆発的増加との関連性を指摘しました。フォーナインは年間ダウンタイムが1時間未満を意味しますが、ワンナインは年間30日以上停止し得ることを意味します。
さらにコメント欄では、インフラ移行を巡る議論も再燃しました。GitHubはMicrosoftによる買収後、インフラを自社データセンターからAzureクラウドへ移行を進めています。あるユーザー（toomuchtodo氏）は「自社データセンター時代の方が安定していた。拡張が必要な部分だけをクラウドに出すべきだったのに、すべてを移行してしまった」と振り返り、移行スケジュールが激しすぎたのではないかと疑う声も上がりました。一方で別のユーザーは、「買収から8年経っているが、不満が急増したのはこの1年であり、時期的にAIプログラミングの爆発的普及と完全に一致する」と反論しました。双方の意見が存在しますが、明らかな事実が2つあります。過去1年でGitHubの障害頻度が顕著に上昇したこと、そしてトラフィックの増大が紛れもない事実であることです。
効率革命と物理世界の追いかけっこ
この問題は一般的な人々にどう関係するのでしょうか？スマートフォンのあらゆるアプリの更新、バグ修正、機能追加の多くは、GitHubの自動化パイプラインを経由しています。プラットフォームが1日滞れば、世界中の数多くの開発チームのリリースサイクルが乱れます。より深層を見れば、これはデジタル上の生産速度と物理世界との追いかけっこです。AIはソフトウェアの生産量を飛躍的に増やしますが、サーバー、帯域幅、データセンターの拡張は物理的なプロセスであり、限界が存在します。GitHubは昨年10月にキャパシティ拡張目標を10倍に設定し、今年2月には30倍に引き上げましたが、依然としてトラフィックの増加に追いついていません。Microsoftが競合であるAWSから一時的に容量を借り受けてGitHubのピンチを凌いだという報道すらあり、クラウド大手の主力製品が競合のデータセンターに頼るという構図自体が、事態の深刻さを物語っています。
「すべてを自動化できる」というのはAI時代における最も魅力的なスローガンです。しかし現実は、自動化によって生成されたタスクも、最終的には物理的なマシンを待つキューに並ばなければなりません。今回のGitHubの障害は一つのシグナルです。誰もがより速く生産するようになったとき、最も希少なリソースはそのすべてを受け止めるインフラストラクチャとなります。AIの生産速度はソフトウェアの問題ですが、インフラの拡張速度は物理的な問題です。後者が前者に追いつかなければ、崩壊するのはその足元です。
参考リンク：
- GitHub Status: Actions と Pages の障害報告
- HN 議論 (item?id=49198302)
- The Register: Latest GitHub outage squeezes Actions, Pages to death
- Waxell: GitHub’s AI Agent Crisis: What 9 Outages Cost
- danilchenko.dev: GitHub’s AI Agent Problem: 17 Million PRs, Five Outages, and a Kill Switch
