GitHubがAWSに救援を求めた日: AIエージェントが壊した開発インフラの現実

「GitHubはもはや真剣な仕事をする場所ではない。毎日何時間もブロックされ続けるなら」。HashiCorp創業者でターミナルエミュレータGhosttyの作者Mitchell Hashimoto氏は2026年4月、自らのプロジェクトをGitHubから移行すると発表した際にこう述べた（BigGo Finance）。個人の不満ではない。業界を代表する開発者が「信頼性の問題」を理由に離れるのは、異常事態の一つのシグナルだ。

その翌月、事態は本質的に解決していないことが明らかになる。2026年6月16日、MicrosoftはGitHubのトラフィックの一部をAmazon Web Services（AWS）に迂回させていることを認めた。自社クラウドのAzureではなく、最大の競合他社の基盤に頼る決断だ（TechTimes）。

AIエージェントが起こしたコミット大爆発

何がGitHubをここまで追い込んだのか。GitHub COOのKyle Daigle氏が2026年4月に明かした数字がすべてを語る。プラットフォームは週2.75億コミットを処理しており、2026年通年では140億件のペースで推移している。2025年通年が10億件だったことと比べると、14倍のペースだ（GitHub COO Kyle Daigle via BigGo Finance）。

この爆増の主役はAIコーディングエージェントだ。AIエージェントが開くプルリクエストの数は2025年9月の400万件から2026年3月には1700万件へと、わずか6ヶ月で325%増加した（Quasa.io）。GitHub Actionsの週次計算時間も2023年の5億分から2025年には10億分、そして2026年初頭の1週間で21億分に達した。

人間の開発者は仕事が終われば帰宅する。夜間はコミットが減り、週末はさらに落ちる。AIエージェントには睡眠も休日も祝日もない。ベースラインが消えた。インフラは最大負荷の想定で設計するしかなくなった。

GitHubは2025年10月に容量を10倍に拡大する計画を立てたが、2026年2月の段階で30倍が必要だと判明した（Neowin）。この20倍の見積もり誤差が、その後の「AWSへの緊急依頼」につながる。

GitHubを壊した三つの数字

稼働率88.4%: SLAの崩壊

2026年5月、GitHubは1ヶ月に9件の障害を記録した（TechTimes）。6月半ばまでの推定稼働率は88.4%で、エンタープライズ向けのSLA（サービスレベル合意）で一般的な「3ナイン」（99.9%）には遠く及ばない。ダウンタイムに換算すると計算上で月間53時間超に相当する水準だ。GitHubのCTO自身がエンタープライズ顧客への稼働率保証を2月と3月に達成できなかったことを認めた（TechTimes）。

Azure移行率40%: タイミングの悪さ

GitHubは歴史的に独自のデータセンターを持つハイブリッド運用をしてきた。Microsoftに買収された後、2027年を目標にAzureへの完全移行を進めていた。2026年5月時点でモノリスのトラフィックの40%がAzureに移行済み、7月に50%を目指していた。この移行の最中にAIエージェント需要が爆増したため、Azureへの移行スピードが需要の伸びに追いつけない状況になった（Windows News）。

MySQL 1: 15年もののレガシーボトルネック

Daigle氏が明かした内部事情がさらに深刻だ（Latent Space）。GitHub内部で「MySQL 1」と呼ばれる単一のMySQLデータベースが、2億アカウントの権限管理を担っている。どのユーザーがどのリポジトリにアクセスできるかを毎回このDBに問い合わせる設計だ。人間が主役だった時代には耐えられた設計も、AIエージェントが絶え間なくAPIを叩く世界では単点障害（SPOF: 障害が全体に波及する唯一の弱点）のリスクが高まる。

「Availability First」と緊急のAWS迂回

GitHubが打ち出した方針が「Availability First（稼働率最優先）」だ。これは機能開発を一時凍結し、エンジニアリングリソースをインフラの安定化に集中させるものだ。MySQL 1の分散化、ジョブキューシステム（大量のジョブをキューに積んで非同期処理する仕組み）の刷新、GitHub Actionsランナーの分離など、10年以上手を付けてこなかったコアシステムを解体・再設計する作業が同時並行で動いている。

ただし、これは中長期の施策だ。設計変更は数ヶ月単位で時間がかかる。その間も毎週2.75億のコミットは降り注いでくる。短期の解決策がAWSへのオフロードだ。

GitHub Actionsのランナーと一部のCodespaces環境のバースト処理（通常時の数倍のトラフィックが一時的に集中する処理）がAWSに迂回される。エンジニアはAzure上で動いているのかAWS上で動いているのかを意識する必要はない。Daigle氏はAzureへの完全移行という長期目標は変わっていないと強調しているが、Azureが追いつくまでの「つなぎ」として競合クラウドに救援を求めた形だ（AI Weekly）。

逆説的な状況だ。MicrosoftはAzureをAI時代のインフラとして最も強くマーケティングしてきた企業だ。しかし自社の最重要開発者プラットフォームが急増するAI負荷に耐えられず、競合のAWSに頼らざるを得なくなった。AIが引き起こしたインフラ危機は、どれほど大きな企業であっても例外ではないという事実を示している。

GitLab、Forgejo: 開発者の行き先

HNのスレッド（item #48549918）には「AzureよりAWSで安定してくれる方がマシ」という反応と「マルチクラウドとは思っていなかった」という驚きが混在した。より根本的な問いを立てる開発者もいる。「どのクラウドで動いているかより、特定企業のSaaSに依存することのリスクをどう考えるか」だ。

Mitchell Hashimotoの行動が象徴的だ。GitLabではなく自前のインフラへの移行を選んだのは、「ホスティングの自律性」という考え方からだ。GitLab、Gitea、ForgejoなどのセルフホストGit基盤への関心は高まりつつある。GitLabはこの状況を「インフラ安定性とAzure非依存」を強みとして企業顧客に直接マーケティングし始めている（Neowin）。

ただし、GitHubの代替候補にも現実的な課題がある。GitHubのエコシステム（Actions Marketplace、GitHub Packages、Copilot統合、Dependabotなど）は一朝一夕に再現できない。「不満はあるが移行コストは高い」という判断で、当面はGitHubに留まる企業が大多数だろう。信頼性問題が長期化すれば、その計算が変わる可能性はある。

AIインフラ危機はGitHubだけではない

視野を広げると、GitHubの問題は業界全体が抱える「AIコンピュート需要の爆発」の一例に過ぎない。Googleは2026年6月時点でSpaceXのスターシールドに月9.2億ドルを支払ってコンピュート容量を確保しているとされる。AnthropicもSpaceXのColossus施設に月12.5億ドルを支払う契約を結んだ（Axios）。詳細は当ブログのAnthropicとSpaceX Colossus契約の解説記事も参照してほしい。クラウドのビッグスリー（AWS、Azure、Google Cloud）でさえ自前では処理しきれなくなった需要を外部に出し始めているという構図だ。

GitHubのケースが特に象徴的なのは、需要の源がAIツールそのものだという点だ。GitHub CopilotというAI機能を提供したことで、AIエージェントが大量にGitHubに流れ込み、GitHubのインフラを圧迫した。AIが自分のホストを食い荒らすという構図だ。

GitHubはAzureへの完全移行完了とMySQL 1の分散化が完了する2026年9月以降に改善を見込むとされている（Windows Forum）。その見通しどおりに事が進むかどうかは、AIエージェントの需要増加ペースと、Microsoftのインフラ整備スピードの競争結果次第だ。

関連記事

• GitHub Copilot従量課金移行: 月$39が2時間で消えた開発者の怒りと代替ツール選び
• エージェンティックコーディング時代: 開発者の役割はどう変わるか
• AIコーディングエージェント比較2026: Claude Code・Cursor・Copilot実力と料金
• AnthropicとSpaceX Colossus計算資源契約の全貌

---

本記事の数値・可用性データは2026年6月16日〜18日の報道を基にしています。GitHubのインフラ状況は随時変化するため、最新情報はgithubstatus.comをご確認ください。本記事は特定サービスへの移行を推奨するものではありません。