パルス：AIネイティブ開発においてGitHubは依然として最適か？

**タイトル: The Pulse: AIネイティブ開発においてGitHubは依然として最適な選択か？** こんにちは、プラグマティック・エンジニア・ニュースレターのボーナス無料版をお届けするゲルゲイです。各号では、シニアエンジニアとエンジニアリングリーダーの視点を通じて、ビッグテックとスタートアップをカバーしています。今日は、先週のThe Pulse号から4つのトピックのうち1つを取り上げます。フル購読者は以下の記事を8日前に受け取りました。このメールが転送されてきた方は、こちらから購読できます。 私たちは、可用性「フォーナイン」（99.99%、年間約52分のダウンタイム）を目指す高信頼性システムに慣れており、「スリーナイン」（年間約9時間のダウンタイム）をかろうじて達成するのは恥ずかしいこととされています。しかし、過去1か月間、GitHubの可用性は「ワンナイン」にまで低下しています！ これは、可用性の悪化によりGitHubが自社のステータスページの更新を停止した後、構築されたサードパーティの「missing GitHub status page」からのデータです。最近の状況は厳しいものがあります： ![image](https://blog.pragmaticengineer.com/content/images/2026/04/image.png)GitHubの可用性がワンナインに低下。出典: The Missing GitHub Status Page これは、30日間のうち、GitHubが3日間の問題を抱え、または毎日2.5時間（約10％の時間）問題や性能劣化が発生していたことを意味します。 GitHubは、AIエージェントからのインフラ負荷の急増に対応しきれていないようです。あるソフトウェアエンジニアは、GitHub全体でのClaude Codeボットの貢献を追跡する「Claude’s Code」という巧妙なウェブサイトを構築しました。過去3か月間の成長は膨大です： ![image](https://blog.pragmaticengineer.com/content/images/2026/04/image-1.png)Claude 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を率いていたら、以下の順序で行います： 1. エージェント的コードライフサイクルのための重要インフラとなることを中核に据えたノーススター計画を策定し、それを測定する方法を決定する。 2. Copilotに取り組む、またはCopilotを提唱する全員を解雇し、Copilotを停止する。人についてではなく、多くの才能ある人材がいることは確かです；ただ、間違った会社で働いているだけです。 3. Pierreを買収し、最初のエージェント製品としてエージェント的リポジトリホスティングを立ち上げる。リポジトリは、レガシーな製品間相互作用に負担がかかる可能性があるため、最初は従来のウェブ製品から分離する。 4. 新しいノーススターに対してすべての製品ラインとイニシアチブを再評価する。50％は削減されると予想します（異なるもののための余地を作るため）。 大きな考え方は、すべてのエージェント的相互作用がGitHub APIに決定的に依存すべきだということです。コードレビューはエージェント的であるべきですが、ラボはそれをGHに組み込むべきです（今日のようにGHAを通じて後付けされるのではなく、真のファーストクラスプラットフォームプリミティブとして）。GHは絶対にエージェントチャットプリミティブを立ち上げるべきで、エージェントメールボックスは明らかに有用です。GHはエージェント自体ではなく、プラットフォームであるべきです。 これは、外部のアイデアのみを基にしており、GitHubの内部がどのように機能しているか、彼らのKPIが何であるか、彼らが定義するノーススターが何であるかなどを知らないため、非常に明らかに情報不足でしょう。 しかし、不完全な情報でも、これが私のするべきことです。」 私の感覚では、GitHubには3つの同時発生する問題があります： 1. GitHubとCopilotはMicrosoftの内部政治に絡み取られています。2021年のGitHubのCopilotは、最初の大規模に成功した「AI製品」でした。Microsoftは「Copilot」ブランドを取り込み、すべての製品ラインで使用し、低品質のAI統合を作成しました。同時に、AzureやMicrosoft AIのようなMicrosoft内部組織は、Microsoft内で最も好意的な開発者ブランドの一つであるGitHubを手中に収めようとしていました。 2. GitHubにはリーダーがいません、意図的にそうしているようです。GitHubの最後のCEOはThomas Dohmkeで、自発的に退任し、MicrosoftはCEOの役割を補充せず、代わりに再編を行ってGitHubをMicrosoftのAIグループの一部とし、その独立性を剥奪しました。「Microsoft AI」側がその戦いに勝ったようです。 3. 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年以降、スタッフエンジニアの役割はどのようになるか？** エージェントがより多くのコードを書くとき、スタッフエンジニアの役割はどうなるか？実際、彼らはこれまで以上に需要が高まる可能性があります！

パルス：AIネイティブ開発においてGitHubは依然として最適か？

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト