パルス：AIネイティブ開発においてGitHubは依然として最適か？
GitHubの可用性が過去1ヶ月で99%未満に急落し、AIエージェント（特にClaude Code）によるインフラ負荷の急増が主要因として指摘され、AIネイティブ開発におけるプラットフォームの信頼性が問われている。
キーポイント
GitHubの可用性の急激な低下
過去1ヶ月間の可用性が99%未満（ワンナイン）にまで低下し、30日間のうち3日間で問題が発生、または1日あたり約2.5時間の障害・劣化が発生している状況が報告されている。
AIエージェントによるインフラ負荷の急増
Claude CodeボットのGitHubへの貢献が過去3ヶ月で6倍に増加し、AIエージェントからの膨大なインフラ負荷が可用性低下の主要因として特定されている。
具体的な障害事例と根本原因
2月と3月に発生した3件の主要障害は、データベースクラスタの飽和、フェイルオーバー時のテレメトリギャップ、設定問題など、インフラストレインとフェイルオーバーの不具合が組み合わさって発生している。
AIネイティブ開発プラットフォームとしての課題
GitHubがAIエージェントの急増する負荷に対応できておらず、従来の高可用性基準（フォーナイン）から大きく後退していることが、AI開発におけるプラットフォーム選択の再考を促している。
スタートアップPierreのAIネイティブソリューション
Pierre ComputerはGitHubが処理できないAIエージェントによるコード生成の負荷増に対応する「AIネイティブ」ソリューションを構築し、GitHubの230リポジトリ/分に対し15,000リポジトリ/分のピークを達成した。
GitHubの信頼性問題と代替案の検討
GitHubの信頼性問題が深刻化しており、チームはPierreのようなスタートアップやセルフホスティングGitを検討し始めている。
Mitchell HashimotoのGitHub改革提案
GitHubはエージェント中心のコードライフサイクルを中核インフラとして位置付け、Copilotを廃止し、Pierreを買収してエージェント対応リポジトリホスティングを優先すべきだという提案。
影響分析・編集コメントを表示
影響分析
この記事は、AIエージェントの普及が従来の開発プラットフォームのインフラ設計に根本的な課題を投げかけていることを示しており、AIネイティブ開発におけるプラットフォーム選択基準の再定義を迫る可能性がある。GitHubのような業界標準ツールの信頼性低下は、開発者コミュニティ全体の生産性と信頼に直接影響を与える重大な問題である。
編集コメント
AIエージェントの爆発的普及が既存の開発インフラを圧迫している生々しい事例。プラットフォーム提供側の対応力が問われるとともに、AI時代の開発ワークフロー再設計の必要性を浮き彫りにしている。
タイトル: The Pulse: AIネイティブ開発においてGitHubは依然として最適な選択か？
こんにちは、プラグマティック・エンジニア・ニュースレターのボーナス無料版をお届けするゲルゲイです。各号では、シニアエンジニアとエンジニアリングリーダーの視点を通じて、ビッグテックとスタートアップをカバーしています。今日は、先週のThe Pulse号から4つのトピックのうち1つを取り上げます。フル購読者は以下の記事を8日前に受け取りました。このメールが転送されてきた方は、こちらから購読できます。
私たちは、可用性「フォーナイン」（99.99%、年間約52分のダウンタイム）を目指す高信頼性システムに慣れており、「スリーナイン」（年間約9時間のダウンタイム）をかろうじて達成するのは恥ずかしいこととされています。しかし、過去1か月間、GitHubの可用性は「ワンナイン」にまで低下しています！
これは、可用性の悪化によりGitHubが自社のステータスページの更新を停止した後、構築されたサードパーティの「missing GitHub status page」からのデータです。最近の状況は厳しいものがあります：
imageGitHubの可用性がワンナインに低下。出典: The Missing GitHub Status Page
これは、30日間のうち、GitHubが3日間の問題を抱え、または毎日2.5時間（約10％の時間）問題や性能劣化が発生していたことを意味します。
GitHubは、AIエージェントからのインフラ負荷の急増に対応しきれていないようです。あるソフトウェアエンジニアは、GitHub全体でのClaude Codeボットの貢献を追跡する「Claude’s Code」という巧妙なウェブサイトを構築しました。過去3か月間の成長は膨大です：
imageClaude Codeからの負荷が3か月で6倍に。出典: Claude’s Code
インフラ過負荷によるGitHub障害の連鎖
GitHubのCTO、Vladimir Fedorovは、ブログ投稿で可用性の問題に言及し、3つの主要なインシデントを説明しました：
2月2日：セキュリティポリシーが意図せず仮想マシンメタデータへのアクセスをブロック
2月9日：データベースクラスタが過負荷に
3月5日：Redisクラスタでの書き込みが失敗
ソフトウェアエンジニアのLori Hochsteinは、これらの障害とCTOの対応について有益な分析を行い、興味深い観察をしています：
飽和： データベースクラスタのインシデント（2月9日）は、予想以上の使用によりデータベースが飽和したケースでした。データベースはステートレスサービスよりもスケールアップが困難です。GitHubはまた、追加トラフィックの量を過小評価していました。
フェイルオーバー＋テレメトリギャップ： 2月2日のインシデントは、1つのリージョンでのインフラ問題が健全なリージョンへのフェイルオーバーを引き起こし、テレメトリギャップ（新しいリージョンで誤ったセキュリティポリシーが適用され、VMメタデータへのアクセスがブロックされた）によって事態を悪化させた組み合わせでした。
フェイルオーバー＋設定問題： 3月5日のインシデントは不気味なほど類似していました：フェイルオーバー後、設定問題がRedisクラスタでの書き込みをブロックしました。
これらの障害についてGitHubから詳細が得られるのは確かに良いことです。私には、インフラの負荷がさらなるインフラ問題を引き起こし→制約をより速く引き起こし→フェイルオーバーが本来あるべきほどスムーズでない、という印象を受けます。GitHubが既存システムを変更し続けているからでしょうか？
スタートアップがGitHubに手本を示す
GitHubがAIエージェントによるコード生成とプルリクエストの増加による負荷増に対応するのに苦労する一方で、Pierre Computerという新興企業は、AIエージェントがコードをプッシュするための「AIネイティブ」ソリューションを構築したと主張しており、GitHubができることをはるかに超えてスケールすると言います。PierreはJacob Thorntonによって設立されました：以前はCoinbase、Medium、Twitterのエンジニアであり、かつて非常に人気のあったBootstrap CSSライブラリの作成者でもあります。
以下は、Pierreがサポートし、GitHubがサポートしていないものです：
「10月[2025年]、Githubは1分あたり約230の新規リポジトリを平均していると共有しました。
先週、私たち[Pierre Computer]は3時間にわたり1分あたり15,000以上の新規リポジトリの持続的なピークに達しました。
そして過去30日間で顧客は900万以上のリポジトリを作成しました」
これらは信じられない数字です（自己申告ではありますが）–そしてGitHubが明らかに近づけない、少なくとも現時点ではできない水準です！顧客に関する詳細はほとんどなく、Code.storageと呼ばれる製品はクローズドベータのようです。
それでも、これはGitHubが構築に失敗した「AIエージェントのためのgit」のタイプであり、GitHubが切実に必要としているインフラのタイプです。
GitHubは焦点と目的を見失ったのか？
GitHubの信頼性問題は深刻であり、このまま続けば、チームはPierreのような小さなスタートアップの代替案を試し始めたり、あるいはセルフホスティングGitさえ検討し始めるでしょう。しかし、世界最大のGitホストはどのようにして顧客を軽視し、コードコミットとプルリクエストの増加に備えてインフラを準備できなかったのでしょうか？
Ghosttyの創設者であり、GitHubのヘビーユーザーでもあるMitchell Hashimotoは、GitHubのコアサービスの状態に不満を募らせた後、もし自分がGitHubを率いていたらどうするかについて、次のようなアドバイスを述べています（強調は筆者）：
「もし私がGitHubを率いていたら、以下の順序で行います：
- エージェント的コードライフサイクルのための重要インフラとなることを中核に据えたノーススター計画を策定し、それを測定する方法を決定する。
- Copilotに取り組む、またはCopilotを提唱する全員を解雇し、Copilotを停止する。人についてではなく、多くの才能ある人材がいることは確かです；ただ、間違った会社で働いているだけです。
- Pierreを買収し、最初のエージェント製品としてエージェント的リポジトリホスティングを立ち上げる。リポジトリは、レガシーな製品間相互作用に負担がかかる可能性があるため、最初は従来のウェブ製品から分離する。
- 新しいノーススターに対してすべての製品ラインとイニシアチブを再評価する。50％は削減されると予想します（異なるもののための余地を作るため）。
大きな考え方は、すべてのエージェント的相互作用がGitHub APIに決定的に依存すべきだということです。コードレビューはエージェント的であるべきですが、ラボはそれをGHに組み込むべきです（今日のようにGHAを通じて後付けされるのではなく、真のファーストクラスプラットフォームプリミティブとして）。GHは絶対にエージェントチャットプリミティブを立ち上げるべきで、エージェントメールボックスは明らかに有用です。GHはエージェント自体ではなく、プラットフォームであるべきです。
これは、外部のアイデアのみを基にしており、GitHubの内部がどのように機能しているか、彼らのKPIが何であるか、彼らが定義するノーススターが何であるかなどを知らないため、非常に明らかに情報不足でしょう。
しかし、不完全な情報でも、これが私のするべきことです。」
私の感覚では、GitHubには3つの同時発生する問題があります：
- GitHubとCopilotはMicrosoftの内部政治に絡み取られています。2021年のGitHubのCopilotは、最初の大規模に成功した「AI製品」でした。Microsoftは「Copilot」ブランドを取り込み、すべての製品ラインで使用し、低品質のAI統合を作成しました。同時に、AzureやMicrosoft AIのようなMicrosoft内部組織は、Microsoft内で最も好意的な開発者ブランドの一つであるGitHubを手中に収めようとしていました。
- GitHubにはリーダーがいません、意図的にそうしているようです。GitHubの最後のCEOはThomas Dohmkeで、自発的に退任し、MicrosoftはCEOの役割を補充せず、代わりに再編を行ってGitHubをMicrosoftのAIグループの一部とし、その独立性を剥奪しました。「Microsoft AI」側がその戦いに勝ったようです。
- GitHubには焦点がなく、収益源としてCopilotを追い求めることに固執しています。GitHubにはCEOがおらず、内部政治に巻き込まれているので、GitHubチームは何ができるでしょうか？最も安全な賭けは収益を増やすことであり、それを行う最良の方法はGitHub Copilotにもっと投資し、信頼性のような長期的な問題を無視することです。
私はMitchellに同意します：GitHubには「ノーススター」がなく、大きな組織が機能不全に陥っているのを見ています。そのビジョン–そしてCEO–の欠如は強く打撃を与えています：
- GitHub Copilotは2021年に最も使用されたAIエージェントから、Claude Codeに追い抜かれ、まもなくCursorにも追い抜かれようとしています。
- プラットフォームとして、GitHubにはAIエージェントをサポートするために進化する方法についてのビジョンがありません。確かに、GitHubにはMCPサーバーがありますが、AIエージェントが生成する膨大な負荷を処理できる「AIネイティブgitプラットフォーム」はありません。
- GitHubは方向性なく小さな機能と改善を出荷し続けています。例えば、2025年10月、彼らはスタックドディフに取り組み始めました。しかし、それが出荷される時には、スタックドディフワークフローはほとんど時代遅れになっているかもしれません–少なくともAIエージェントの文脈では！
あなたが世界の誰よりも一つのことをうまくやるとき、市場を勝ち取るのは簡単です。今、GitHubはあまりにも多くのことをしており、Copilot、そのプラットフォーム、AIインフラで平凡な仕事をしています。
先週のThe Pulse号の全文を読むか、今週のThe Pulseをチェックしてください。
最近のThe Pragmatic Engineer号をキャッチアップ：
- Thuan Phamと共にUberをスケーリング（Uberの最初のCTO – ポッドキャスト）。 Uberを絶え間ない障害からグローバルインフラストラクチャへスケーリングする方法、マイクロサービスとプラットフォームチームへの移行、AIがエンジニアリングをどのように再形成しているかなどのトピックについて話しました。
- Jean Leeと共にWhatsAppを構築（ポッドキャスト）： WhatsAppの19番目のエンジニア、Jean Leeが、小さなチームでアプリをスケーリングする方法、Facebookの買収、そしてそれがエンジニアリングの未来について何を明らかにするかについて。
- 2027年以降、スタッフエンジニアの役割はどのようになるか？ エージェントがより多くのコードを書くとき、スタッフエンジニアの役割はどうなるか？実際、彼らはこれまで以上に需要が高まる可能性があります！
原文を表示
Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week’s The Pulse issue. Full subscribers received the article below eight days ago. If you’ve been forwarded this email, you can subscribe here.
We’re used to highly reliable systems which target four-nines of availability (99.99%, meaning about 52 minutes of downtime per year), and for it to be embarrassing to barely hit three nines (around 9 hours of downtime per year.) And yet, in the past month, GitHub’s reliability is down to one nine!
Here’s data from the third-party, “missing GitHub status page”, which was built after GitHub stopped updating its own status page due to terrible availability. Recently, things have looked poor:
imageGitHub down at one nine. Source: The Missing GitHub Status PageThis means that for every 30 days, GitHub had issues on 3 days, or issues/degradations for 2.5 hours daily (around 10% of the time.)
GitHub seems unable to keep up with the massive increase in infra load from agents. One software engineer built a clever website called “Claude’s Code” that tracks Claude Code bot contributions across GitHub. Growth in the past three months has been enormous:
imageLoad from Claude Code has 6x’d in 3 months. Source: Claude’s CodeStream of GitHub outages from infra overload
GitHub’s CTO, Vladimir Fedorov, addressed availability issues in a blog post and covered three major incidents:
2 February: security policies unintentionally blocked access to virtual machine metadata
9 February: a database cluster got overloaded
5 March: writes failed on a Redis cluster
Software engineer Lori Hochstein did a helpful analysis of these outages and the CTO’s response, and has interesting observations:
Saturation: the database cluster incident (9 Feb) was a case of the database getting saturated, due to higher-than-expected usage. Databases are harder to scale up than stateless services. GitHub also underestimated how much additional traffic there would be.
Failover + telemetry gap: the 2 Feb incident was a combination of an infra issue in one region failing over to a healthy region, and making things worse with a telemetry gap (incorrect security policies were applied in the new regions which blocked access to VM metadata)
Failover + configuration issue: the 5 March incident was uncannily similar: after a failover, a configuration issue blocked writes on a Redis cluster
It is certainly nice to get details from GitHub on these outages. It feels to me that infra strains are causing more infra issues → they trigger constraints faster → failovers are not as smooth as they should be. Could it be because GitHub keeps changing their existing systems?
Startup shows GitHub how it’s done
While GitHub struggles to keep up with the increase in load from AI agents generating more code and pull requests, a new startup called Pierre Computer claims to have built an “AI-native” solution for AI agents pushing code, which scales far beyond what GitHub can do. Pierre was founded by Jacob Thornton: formerly an engineer at Coinbase, Medium, and Twitter, and also the creator of the once-very popular Bootstrap CSS library.
Here’s what Pierre supports, which GitHub does not:
“In October [2025], Github shared they were averaging ~230 new repos per minute.
Last week we [at Pierre Computer] hit a sustained peak of > 15,000 repos per minute for 3 hours.
And in the last 30 days customers have created > 9M repos”
These are incredible numbers – if also self-reported – and something that GitHub clearly cannot get close to, at least not today! There are few details about customers, while the product – called Code.storage – seems to be in closed beta.
Still, this is the type of “git for AI agents” that GitHub has failed to build, and the type of infrastructure it needs badly.
Has GitHub lost focus and purpose?
GitHub’s reliability issues are acute enough that, if it keeps up, teams will start giving alternatives like small startups such as Pierre a try, or perhaps even consider self-hosting Git. But how did the largest Git host in the world neglect its customers, and fail to prepare its infra for an increase in code commits and pull requests?
Mitchell Hashimoto, founder of Ghostty, and a heavy user of GitHub himself, had advice on what he would do if he was in charge of GitHub, after growing frustrated with the state of its core offering. He writes (emphasis mine)
“Here’s what I’d do if I was in charge of GitHub, in order:
- Establish a North Star plan around being critical infrastructure for agentic code lifecycles and determine a set of ways to measure that.
- Fire everyone who works on or advocates for Copilot and shut it down. It’s not about the people, I’m sure there’s many talented people; you’re just working at the wrong company.
- Buy Pierre and launch agentic repo hosting as the first agentic product. Repos would be separate from the legacy web product to start, since they’re likely burdened with legacy cross product interactions.
- Re-evaluate all product lines and initiatives against the new North Star. I suspect 50% get cut (to make room for different ones).
The big idea is all agentic interactions should critically rely on GitHub APIs. Code review should be agentic but the labs should be building that into GH (not bolted in through GHA like today, real first class platform primitives). GH should absolutely launch an agent chat primitive, agent mailboxes are obviously good. GH should be a platform and not an agent itself.
This is going to be very obviously lacking since I only have external ideas to work off of and have no idea how GitHub internals are working, what their KPIs are or what North Star they define, etc.
But, with imperfect information, this is what I’d do.”
My sense is that GitHub has three concurrent problems:
GitHub and Copilot are entangled with Microsoft’s internal politics. GitHub’s Copilot in 2021 was the first massively successful “AI product.” Microsoft took the “Copilot” brand and used it across all of their product lines, creating low-quality AI integrations. Simultaneously, internal Microsoft orgs like Azure and Microsoft AI were trying to get their hands on GitHub, which is one of the most positive developer brands at Microsoft.
GitHub has no leader, seemingly by design. GitHub’s last CEO was Thomas Dohmke, who stepped down voluntarily, and Microsoft never backfilled the CEO role; instead carrying out a reorg to make GitHub part of Microsoft’s AI group and stripping its independence. It seems the “Microsoft AI” side won that battle.
GitHub has no focus, and is stuck chasing Copilot as a revenue source. GitHub has no CEO and is caught up in internal politics, so, what can GitHub teams do? The safest bet is to increase revenue and the best way to do that is by investing more into GitHub Copilot, and ignoring long-term issues like reliability.
I agree with Mitchell: GitHub has no “North Star” and we see a large org being dysfunctional. That lack of vision – and CEO – is hitting hard:
GitHub Copilot went from the most-used AI agent in 2021, to be overtaken by Claude Code, and is soon to be overtaken by Cursor.
As a platform, GitHub has no vision for how to evolve to support AI agents. Sure, GitHub has an MCP server, but it has no “AI-native git platform” that can handle the massive load AI agents generate.
GitHub keeps shipping small features and improvements without direction. For example, in October 2025, they started to work on stacked diffs. However, when it ships, the stacked diffs workflow might be mostly obsolete – at least with AI agents!
It’s easy to win a market when you do one thing better than anyone else in the world. Right now, GitHub is doing too many things and doing a subpar job with Copilot, its platform, and AI infra.
Read the full issue of last week’s The Pulse, or check out this week’s The Pulse.
Catch up with recent The Pragmatic Engineer issues:
Scaling Uber with Thuan Pham (Uber’s first CTO — podcast). We went into topics like scaling Uber from constant outages to global infrastructure, the shift to microservices and platform teams, and how AI is reshaping engineering.
Building WhatsApp with Jean Lee (podcast): Jean Lee, engineer #19 at WhatsApp, on scaling the app with a tiny team, the Facebook acquisition, and what it reveals about the future of engineering.
What will the Staff Engineer role look like in 2027 and beyond? What happens to the Staff engineer role when agents write more code? Actually, they could be more in demand than ever!
関連記事
ClaudeがSpotifyやUber Eatsなどの個人アプリに直接接続
AnthropicはClaudeがSpotifyやUber Eats、TurboTaxなどの個人アプリに直接接続できる新機能を提供した。これにより、ユーザーはハikingから grocery shopping まで多様なサービスを利用可能になる。
日常生活向けのClaude新コネクタ機能
AnthropicはClaudeに、メールやカレンダーなど日常アプリと連携する新コネクタ機能を追加した。
Anthropic、AIエージェントの展開を簡素化する「Managed Agents」を発表
AnthropicはClaude上で「Managed Agents」を提供し、エージェントのロジックと実行環境を分離する。これにより、長時間のワークフローや外部ツール連携、エラー回復が実現する。