今年2月9日、北京時間の深夜、世界中で数千万人の開発者が同じページを開いた。
404ではなく、404よりもさらに不安を掻き立てる——すべてのエンジニアの背筋を凍らせる黄色の警告バーと、ステータスページに並ぶ緑から赤に変わったインジケーター。
github.com が利用できません。
APIが停止しています。
GitHub Actions が停止しました。
Git操作が停止しました——Copilotさえも例外ではありませんでした。
その夜、誰かのCI/CDパイプラインが最も重要な段階で停止し、誰かの自動デプロイが空中で立ち往生し、誰かはまだマージされないPRを待っていた——その背後には、リリースを待つ機能と、リアルなユーザーを待つ気持ちがあった。
その後、GitHubは事故報告を公開しました。技術的な観点から見ると、根本原因は「認証およびユーザー管理を担当するコアデータベースクラスターの過負荷」でしたが、この数語の背後には、驚異的な連鎖反応が隠されていました——
2日前、エンジニアリングチームはユーザーに新しいモデルを迅速に提供するため、「ユーザー設定キャッシュ」の更新時間を12時間から2時間に変更しました。この設定値の変更だけでした。
結果、本来12時間に分散して行われるはずだったキャッシュ書き換えが2時間に圧縮され、密集した「キャッシュ書き換えストーム」が発生し、非同期タスクキューが一瞬で過負荷となり、共有インフラストラクチャコンポーネントがクラッシュしました。この連鎖反応はHTTPS Git操作を担当するサービスにも及び、最終的にプラットフォーム全体の接続が枯渇しました。
12から2に変更された数字。
GitHubは、自分で変更した設定によって障害が発生しました。
しかし、あなたがこの設定変更だけに注目しているなら、この物語の最も重要な部分を見落としているでしょう。
01 それは偶然ではなく、十回の偶然だ
2月9日の事故は、孤立した出来事ではありません。
実際、2026年の最初の3ヶ月間で、GitHubは少なくとも8回の重大な事故を経験しました。2月だけでも、大小を問わず37回の障害が記録されています。GitHubのCTOであるVlad Fedorovは後日、ブログでこの2ヶ月間、GitHubが企業顧客に約束した「3つの9」、つまり99.9％の可用性を維持できなかったことを認めていました。
この2か月の障害アーカイブを確認すると、奇妙なパターンが見えてきます。すべての事故は、異なる原因のように見えます。
2月2日：Azure計算プロバイダーに問題が発生し、GitHub Actionsが約4時間停止。Copilotコードエージェント、CodeQL、Dependabotも影響を受けた。
2月9日：キャッシュリライトストーム、認証データベースが過負荷。
3月5日：Redisクラスターの障害により、GitHub Actionsの95%のワークフローが5分以内に起動できず、平均遅延は30分でした。
3月18日：Webhookの遅延が通常レベルの32倍に急増しました。
毎回は「予期せぬ出来事」に見えるが、その直接的な原因は常に異なる。しかし、フェドロフの説明はこれらを一つの物語に繋ぎ合わせた。彼は、これらの事故の背後には三つの共通する構造的要因があると述べた。「急速な負荷の増加、サービス間の密結合による局所的な障害の拡散、そして異常なクライアントからのトラフィックを防ぐためのシステムの脆弱性。」
エンジニアの言葉で言えば、GitHubの基盤は、新しい負荷の重圧之下で亀裂が入り始めている。
そして、この「新しい負荷」には具体的な名前があります。
02 毎週2億7500万回の提出
重要なデータ
2025年通年のコミット総数：約10億回
2026年の1週間あたりのコミット数：2.75億回
この速度で推移すると、2026年全年の予測は140億回（前年比14倍増）です。
GitHub Actionsの計算量：2023年週5億分 → 2025年10億分 → 2026年初頭のある週21億分
もしあなたがGitHubのインフラエンジニアであれば、2025年と2026年のモニタリングダッシュボードの比較は、きっとあなたを驚かせるでしょう。
2025年全年、GitHubは約10億回のコードコミットを処理しました。この数字自体はすでに大きく、GitHubプラットフォームが長年にわたり蓄積してきた結果です。しかし2026年には、1週間のコミット数が2億7500万回に達しました。換算すると——この速度で全年を進めると、2026年の総コミット数は約140億回に近づき、2025年全年の14倍になります。
これは滑らかな成長曲線ではなく、急峻な斜面です。GitHubのActionsの計算量の変化がより明確に示しています：2023年には週に5億分を消費し、2025年には10億分に倍増し、その後2026年初頭のある週には、いきなり21億分に跳ね上がりました。
何がコードを急いで提出しているのか？
人間の開発者ではありません。
GitHubのデータによると、AIエージェントがこのプラットフォームで最も活発な「ユーザー」となっています。Claude Codeという1つのツールだけで、GitHubのすべてのパブリックリポジトリへのコミットの4.5%を占めています。週間コミット数は260万回に達しており、2025年9月末にはまだ10万回でした——3か月で25倍の成長です。
AIエージェントが開いたPRの数も爆発的に増加しています。2025年9月には、AIが生成したPRは月間約400万件でしたが、2026年3月には1700万件に跳ね上がり、半年で4倍以上になりました。
これを理解するための画面があります。
以前、GitHubの「ユーザー」は主に人間のプログラマーでした。彼らは昼間働き、夜に眠り、週末は休憩し、毎回のコミットには考え、迷い、手の速さに上限がありました。システムの負荷は人間の生活リズムに従い、ピークと谷があり、予測可能でした。
現在、ますます多くの「ユーザー」がAIエージェントである。それらは眠らず、休まず、ためらわず、1つのタスクに対して複数の並列エージェントを同時に起動でき、各エージェントの1時間あたりの提出量は、実際のエンジニアが1週間で行う作業量を簡単に上回る。さらに重要なのは、それらがコードの提出だけでなく、新しいリポジトリを次々と作成していることである。リポジトリを人間の「作業スペース」ではなく、ワークフローの「出力成果物」として扱っているのだ。
GitHubのインフラエンジニアたちは、より多くのトラフィックを伴う類似の問題ではなく、性質が完全に異なる問題に直面している。
03 Copilotの資金が尽きてきました
頻繁な障害は問題の一面に過ぎず、GitHubにはもう一つより深刻な問題がある——会計を確認したところ、損失が出ていたことだ。
Copilotの初期の価格設定ロジックは、ユーザーが主に「補助的な補完」の形で利用し、各インタラクションが短時間で、計算量が予測可能であるという合理的な仮定に基づいています。個人版は月額10ドル、ビジネス版は席単位で月額19ドルというモデルは、過去数年間うまく機能してきました。
そして、Agentic AIが登場しました。
エージェント型ワークフローと従来の補完は、別物である。標準的なコード補完では、リクエストは線形で予測可能であり、計算サイクルは短い。一方、エージェント型コーディングセッションは数時間にわたり実行され、複数の並列スレッドを起動し、多段階の推論、自己修正、リポジトリ間のリファクタリングを実行する。1つのセッションで消費されるトークン量は、通常のユーザーの1か月分のサブスクリプション料金を簡単に上回る。
GitHubが直面している状況は、少数の重度のAgenticユーザーが、月額数ドルの料金で、数百ドル相当の計算リソースを消費していることです。
この状況に対し、GitHubの対応は明確だった——まず流量制限し、その後価格を変更した。
今年の年初から、GitHubはCopilotに対して、セッション時間上限と週間使用量上限の二つの並行したレート制限を導入しました。両方の次元は、トークン消費量にモデル計算重みを掛けた値に基づいて計算されます。同時に、一部の個人Copilotプランでは新規ユーザーの登録が一時停止されました。
6月1日、GitHubはより根本的な価格改革を実施しました：Copilotが従来のサブスクリプション料金から使用量課金に完全移行し、「AIクレジット」が導入されました。1 AIクレジットは1セントに相当し、使用量はトークン消費に基づいてリアルタイムで計算されます。
座席料金の時代は、Agentic AI の前で終わりを告げた。
この変化はGitHubの問題だけではありません。2026年、AIが人間の作業を「補助」するだけでなく、完全なワークフローを代替し始める中、AIツール業界全体が「月額1人あたり」のサブスクリプションモデルの集団的価格危機に直面しています。
04、30倍で、10倍ではありません
インフラの問題に戻ります。GitHubはこの「14倍の成長」にどのように対応するつもりですか？
問題の深刻さを示す細部があります：
2025年12月下旬、Agenticワークフローが急激に加速し始めた。GitHubのエンジニアたちは、10倍では不十分であることに気づいた。2026年2月、その深刻な停止後、GitHubはアーキテクチャを現在の規模の30倍に再設計する必要があると発表した。
拡張ではなく、再設計です。
これらの二つの用語には大きな違いがあります。スケールアウトとは、既存のマシンを増やし、既存のデータベースにメモリを追加することです。方向は変わらず、規模が大きくなるだけです。一方、再設計とは、既存のアーキテクチャが30倍の規模でシステム全体が機能しなくなることを意味し、サービスの分割、データフロー、障害隔離の方法を根本から見直す必要があるということです。
GitHubが明示した具体的な方向性には、カスケード障害を防ぐための重要なサービスの分離、バックプレッシャーメカニズムとトラフィックデグレード機能の導入、ホットサービスへの独立したホストの配置、シングルポイント障害の排除、およびより洗練された変更管理——キャッシュTTLを12時間から2時間に変更するような操作を十分な負荷テストなしに直接本番環境にリリースしないこと——が含まれます。
注目すべきは、GitHubが孤立していないということです。
StripeはAIエージェントによるアカウント一括作成の問題に直面しており、AWSはエージェント専用の認証システム、ログシステム、運用制御メカニズムを構築中である。これらの対応は予防策ではなく、モニタリングダッシュボードにすでに解決が必要なシグナルが表示されているためである。
GitHubは、AIツールチェーンの最核心にあるため、最初に突破されただけだ。
05 コードリポジトリが、AIの排気管になりつつある
この全体の性質について一度立ち止まって考えてみてください。
GitHubとは何ですか？最も直感的な答えは、プログラマーがコードを保存する場所であることです。しかし、より深く見ると、それは人間のソフトウェア協力の基盤です。コミット履歴は協力の軌跡であり、PRは議論の容器であり、Issuesは意図の記録であり、Actionsは実行のパイプラインです。この一連のシステムは、人間の作業リズム、思考パターン、協力スタイルのために設計されています。
AIエージェントがこれを変えた。
AIエージェントが1日に何百回もコードをコミットするとき、その1回1回の「コミット」の背後には人間の思考や判断はなく、ただタスクのループの進行ステップがあるだけだ——コードリポジトリはまだ「協力の容器」なのか？
AIツールがリポジトリを自動生成し、PRを自動で開き、CIを自動で実行し、マージするようになった今、開発者はこのプロセスの主体であり続けるのか、それとも「レビュー担当」甚至「観察者」に退化してしまったのか？
GitHubのCTOは、この危機を「負荷の急激な増加」と表現した。しかし、この表現は問題の本質を過小評価している可能性がある——これは単なる量の増加ではなく、使用方法の質的変化である。従来のモデルでは、GitHubは「開発者のツール」だったが、新しいモデルでは、GitHubが「AIの排気口」、すなわち自動化ワークフローの出力パイプラインに変わりつつある。
これはGitHubにとって何を意味するのか、まだ答えは出ていない。30倍のスケーリングはトラフィックの問題を解決できるが、ビジネスモデルの再定義や「私の真のユーザーは誰か」というアイデンティティの問題を解決することはできない。
最近、非常に意味深い現象が見られた：GitHubはダウンタイム後に多数のエンジニアリングブログを公開し、各障害の根本原因を非常に詳細に説明しており、その透明性は驚異的である。一部では、これはGitHubが信頼を積極的に構築しようとしている兆しと見なされているが、他には、今後の再構築期間中にさらに多くの不安定さが続くことを踏まえ、透明性によって開発者コミュニティの忍耐を獲得しようとしているとの見方もある。
自らの成功によって破壊されたプラットフォームは、自らを分解して再構築する必要がある——そしてこのプロセスそのものが、耐え抜けるかどうかの試練でもある。
2月9日の夜、PRのマージを待っていたエンジニアは、おそらくやっとグリーンライトを得たことだろう。しかし、彼が待たされたそのダウンタイムが、GitHubの偶然の出来事ではなく、ソフトウェア開発業界全体が新しい時代に入る音だったことに気づかなかったかもしれない。
本文は微信公众号「極客公園」（ID：geekpark）より、著者：宇宙猿