ソフトウェア開発のデファクトスタンダードであるGitHubが、前例のない可用性の危機に直面している。同社CTOであるVlad Fedorovは、近年の頻発するダウンタイムとパフォーマンスの低下について公式ブログを通じて公式に謝罪し、その根本的な原因がAIエージェントによる開発ワークフローの急激な加速にあることを明確に認めた。
GitHubは当初、将来の需要を見越して2025年10月からシステム容量を10倍に引き上げる計画を実行に移していた。しかし、インフラストラクチャの進化よりも、テクノロジートレンドの変化のほうが遥かに迅速であった。2025年12月後半から、自律的にコードを生成し、自動テストを実行し、自らプルリクエストを作成する「Agentic（エージェント駆動型）」なAIツールが開発現場に急速に浸透し始めた。その結果、2026年2月の段階で、GitHubは「現在の30倍」のスケールを前提としたアーキテクチャ設計を余儀なくされるという、想定外の事態に陥っている。
単にトラフィックの総量が増大しただけではない。人間による操作とは異なり、自動化されたエージェントは昼夜を問わず休みなく絶え間なくAPIリクエストを送信し、巨大なモノレポに対する複雑なワークロードを機械的な速度で生成する。GitHubのシステムにおいて、一つのプルリクエストを処理するという一見単純な操作であっても、バックエンドではGitストレージの読み書き、マージ可能性の計算、ブランチ保護ルールの評価、GitHub Actionsのトリガー、検索インデックスの更新、通知のルーティング、権限管理、Webhookの送信など、無数のサブシステムが連鎖的に駆動している。トラフィックがこの規模に達すると、システム内のごく僅かな非効率性が致命的なボトルネックへと成長する。処理待ちのキューが滞留し、キャッシュミスが直接的にデータベースへの過大な負荷を招き、インデックスの更新が遅延し、クライアントからのリトライ処理がトラフィックをさらに自己増幅させる。これらは、大規模な分散システムが限界を迎えた際に引き起こされる典型的なカスケード障害の前兆である。
開発者の不満とトップエンドユーザーの離脱
この水面下で進行していたインフラストラクチャの歪みは、次第に開発者の日常業務に直接的な被害をもたらすようになった。2026年の初頭から、ダッシュボード上のプルリクエストリストが正確に表示されない、コード検索機能が機能しない、あるいはGitHub Actionsのランナーが遅延・停止するといった障害が頻発している。システムの稼働率低下はデータにも表れており、サードパーティの計測プラットフォームによれば、4月のアップタイムは85%を割り込む水準にまで悪化している。これはSLA（サービス品質保証）の観点からも、エンタープライズ顧客の許容範囲を大きく超える事態である。
この状況は、長年にわたってエコシステムを牽引してきた著名な開発者たちのプラットフォームへの信頼をも揺るがしている。HashiCorpの共同創業者であり、現在は高性能ターミナルエミュレータ「Ghostty」の開発を主導するMitchell Hashimotoは、直近数ヶ月にわたる頻繁なシステム障害を理由に、同プロジェクトのホスティングをGitHubから別のプラットフォームへ移行する意向をブログで発表した。彼の手記によれば、カレンダーのほぼ毎日に障害の影響による「×」印が記されており、度重なるGitHub Actionsの停止はコードレビューの進行を著しく妨げているという。彼にとって、現在のGitHubはもはや「深刻な開発作業を行う場所」としての信頼性を喪失している。これはGitHubの根幹を支えるプロフェッショナル層からの強烈な警告として受け止められている。
優先順位の転換：「新機能」から「可用性第一」へ
この危機的状況を受け、GitHubは開発と運用の優先順位を「可用性（Availability）」を最上位に据え、次いで「容量（Capacity）」、最後に「新機能（New Features）」とする方針を明確に打ち出した。これまで同社は、親会社であるMicrosoftの戦略に沿う形でAzureへのインフラ移行を進めつつ、UIの刷新や新機能のリリースを継続してきたが、現在のアプローチはシステムの堅牢性を回復させることに全リソースを集中させている。
具体的な技術的アプローチとしては、単一障害点（SPOF）の徹底的な排除と、ブラスト・ラジアス（障害発生時の波及範囲）の最小化が進められている。短期的には、Webhookの処理バックエンドを従来のMySQLアーキテクチャから別のスケーラブルなシステムへ移行し、ユーザーセッションキャッシュの設計と認証・認可フローを根本から見直すことで、リレーショナルデータベースへの負荷を劇的に削減している。また、Gitのコア機能やGitHub Actionsといったクリティカルなサービスを他のワークロードから完全に分離し、特定のサブシステムが高負荷に陥った場合でも、プラットフォーム全体がダウンすることなく「Graceful Degradation（段階的な機能縮退）」を伴って稼働し続けられるような防御的設計へと舵を切っている。さらに、パフォーマンス要件が極めて厳しいコンポーネントについては、歴史的なRubyのモノリスアーキテクチャからGo言語ベースのマイクロサービスへと移行する作業を加速させている。
また、インフラ戦略における重要な転換点として、これまでMicrosoftの傘下としてAzureへの移行を推進していたGitHubが、将来的な「マルチクラウド」アーキテクチャへの移行パスの構築に本格的に着手した点が見逃せない。単一のパブリッククラウドプロバイダーにシステム全体を依存することは、大規模障害時のリスクを増大させる。これは、より高い次元での耐障害性と将来的な柔軟性を追求するための、不可避かつ現実的な技術的選択である。
4月に発生した二つの象徴的なインシデント
インフラ再構築の途上において、4月にはシステムの脆弱性が露呈する二つの重大な障害が発生し、事態の深刻さを改めて印象付けた。
一つ目は、4月23日に発生したマージキューシステムの不具合である。この障害は658のリポジトリと2,092のプルリクエストに直接的な影響を与えた。原因は、マージキューを利用した「Squash Merge（複数コミットを一つにまとめるマージ手法）」において、複数のプルリクエストが同一グループとして処理された際、以前にマージされた変更が意図せずリバート（取り消し）されてしまうという致命的なバグであった。Gitストレージ上のデータ自体が失われることはなかったものの、影響を受けたリポジトリのデフォルトブランチの状態が破壊され、GitHub側からの安全な自動修復が不可能な状況に陥った。これは、巨大なリポジトリにおける同時多発的な自動マージ処理が、いかに状態管理を複雑にし、予期せぬエッジケースを引き起こしやすいかを示す典型例である。
二つ目は、4月27日に発生したElasticsearchサブシステムの障害である。ボットネットによる大規模なトラフィック攻撃の可能性が高いとされるこの事件では、検索機能に依存するUIコンポーネント（プルリクエストやイシューのリスト表示など）が結果を一切返さなくなり、甚大な混乱を招いた。Gitのプッシュやプルといったコアオペレーション自体は正常に稼働していたものの、検索システムが単一障害点としてアーキテクチャ上から適切に分離されていなかったために、プラットフォーム全体の使用体験が大きく損なわれる結果となった。
コミュニティへの透明性と今後の課題
これらの相次ぐ事態に対し、CTOのFedorovは「我々は皆さんからいただいたメール、ソーシャルメディアの投稿、サポートチケットのすべてを読み、その痛みを重く受け止めている」と反省の意を表明している。改善に向けた第一歩として、GitHubはステータスページを改修し、より透明性の高い稼働状況の報告やインシデントの根本原因分析（RCA）の開示を約束した。
ソフトウェア開発のパラダイムが「人間がコードを書く」時代から、「人間がエージェントを指揮して自動的にコードを生成・テストする」時代へと急激に移行する中、旧来の静的なソースコード保管庫であったGitHubは現在、無数のAIが自律的に連携する広大なクラウドオペレーティングシステムへと役割を急激に変貌させつつある。現在彼らが直面している可用性の危機は、この巨大なシステムアーキテクチャの移行期における深刻な成長痛である。しかし、ビジネスを推進する開発者の忍耐には限界があり、Mitchell Hashimotoの離脱はその最も象徴的な出来事である。進行中のデータベース分離やマルチクラウド化といったインフラの抜本的改革が結実し、再び「世界中の開発者にとって最も信頼できる強牢なプラットフォーム」の座を確固たるものにできるか否か。今後数ヶ月のGitHubのインフラエンジニアリングの成否が、AIエージェント時代の開発インフラの標準を決定づけると言っても過言ではない。