最近、GitHubの稼働率が著しく下がり、開発者たちがTwitter（現X）で阿鼻叫喚の様相を呈しているのをよく見かける。CI/CDが回らず、強制的に「雪休み（Snow day）」を謳歌する羽目になった開発者も少なくないだろう。このダウンタイムの頻発を以て、GitHubの技術力低下だのオワコンだのと騒ぎ立てる輩が後を絶たないが、一旦そのような短絡的な批判は無視して、裏で何が起きているのかに焦点を当てる。
先日、Latent Spaceのpodcastにおいて、GitHubのCOO兼Microsoft CMOであるKyle Daigleが、この惨状の理由と今後のAIエージェント戦略について赤裸々に語った。結論から言えば、インフラが限界を迎えている理由は「人間の開発者が増えたから」ではなく、「AIエージェントが爆速でコードを書きまくっているから」である。
人間の限界スピードを超えたインフラの悲鳴
Daigleによれば、AIコーディングエージェントの台頭により、開発アクティビティはかつてない規模で急増している。2025年に年間10億回だったコミット数は、現在週2億7500万回のペースで推移しており、単純計算で年間140億回、実に1400%の成長を記録していることになる。
これまでGitHubのインフラは、10年以上の長きにわたり「人間の開発者が人間のタイピング速度でコードを書く」ことを前提に設計されてきた。しかし、24時間365日休むことなく、ミリ秒単位で巨大なPull Request（PR）を量産し、GitHub Actionsを回し続けるエージェントの登場により、その前提は完全に崩壊したのである。
問題の根源は複雑だ。Actionsを回すためのCPUリソースの枯渇（今やGPUと同じくらいCPUが逼迫している）、巨大なmonorepoの激増、そして何より「MySQL One」と呼ばれるレガシーな巨大データベースと、そのパーミッションレイヤーのボトルネックである。
スケールアップ（垂直）もスケールアウト（水平）も限界を迎え、物理的な制約に直面しているGitHubは今、根本的なリアーキテクチャを余儀なくされている。稼働率の低下は、この「14倍の爆発的成長」を支えるための成長痛に他ならない。インフラエンジニア目線で言えば、これほど痺れるスケーラビリティの課題もそうそうないだろう。SDLC（Software Development Life Cycle）全体へのAI統合というプラットフォーム戦略を実現するためには、この泥臭い基盤改修を避けては通れないのだ。
メガスキルの終焉とマイクロススキルの台頭
では、この爆発を生み出しているAIエージェントを、GitHub自身はどう社内で活用しているのか。
興味深いのは、Daigleが「メガスキル（mega-skills）」の時代は終わったと明言している点だ。複数のツールを複雑に繋ぎ合わせ、一つの巨大なプロンプトで全てを解決しようとするアプローチは、本質的に脆い。仕様や環境が少し変わるだけで容易に破綻するからだ。
代わりに彼らが注力しているのが「マイクロススキル（micro-skills）」である。一つの機能（例えばSlackの特定の会話を要約する、特定のリポジトリの差分を抽出するなど）だけを完璧にこなすアトミックなスキルを用意し、それを必要に応じて動的に組み合わせる。
これはUNIXの哲学にも通じるものがある。このアプローチにより、技術者だけでなく非技術者のリーダー層でさえも、CLIやデスクトップアプリから容易にAIを既存のワークフローに組み込めるようになった。Daigle自身も、週末に15個のエージェントを走らせ、膨大な過去のドキュメントやTeams、Slackのログを遡って分析し、経営戦略のインサイトを得ているという。「前へ進むために、AIを使って過去を振り返る」というアプローチは、リモートワークが主体の現代組織において極めて理にかなっている。
PRの8割がAIになる時代の「信頼」とは
エージェントがコードベースへ積極的に介入してくると、「開発者」の定義自体が揺らいでくる。現在、GitHubのアカウント数は2億を超えた。AIの支援によって、これまでコードを書けなかった層が大量に流入しているのだ。それに伴い、オープンソースエコシステムにおけるコラボレーションの要であったPull Requestの性質も変質しつつある。
コードの大部分がエージェントによって生成され、時には別のアージェントがそれをレビューする。この状況下で、人間はどうやってそのコードを「信頼」するのか。
slop forks（AIが生成した無価値なフォークや質の低いPR）が蔓延する中、Peter Steinbergerが提唱する「Prompt Request」のような新しい概念や、Mitchell Hashimotoが実践する「vouching（保証・推薦）」システムなどが議論されているが、最終的には「どの人間が承認したか」というソーシャルな信頼のレイヤーに帰結する。
Enterprise環境に目を向ければ、事態はより深刻だ。GitHub Copilotの導入は単に生産性を上げるだけでなく、コードの品質担保や知財リスク、レガシーシステムとの統合といった厄介な課題を引き起こしている。AIがいくら優秀でも、最後はHuman-in-the-loop（人間の関与）によるレビュープロセスと、組織的な変更管理が不可欠となる。AIは開発者を置き換えるのではなく、開発者の役割を「コードを書く人」から「システムを設計し、エージェントを導き、倫理と品質を担保する人」へと引き上げるものなのだ。
Copilotの次章と、OSレイヤーを狙うMicrosoftの野望
GitHub Copilotは、単なるコード補完（Autocomplete）ツールからの脱却を図っている。新しいCopilot CLIやDesktop App、そして統一されたSDKを通じて、セキュリティの修復からIssue管理まで、SDLC全域をカバーする包括的な「コーディングエージェントのハーネス」へと進化しつつある。
その先に見据えているのは、コンテキストとパーソナライゼーションの極致、「アンビエントAI（Ambient AI）」である。開発者が明示的に指示を出さずとも、AIが背後で常にプロジェクトの歴史、設定、コーディングスタイルを読み取り、最適なタイミングで最適な支援を提供する世界だ。
この文脈で非常に興味深いのが、MicrosoftがOpenClaw（コンピュータを自動操作するオープンソースのエージェント）のCVP（Corporate Vice President）をわざわざ置いている点である。MicrosoftはOpenClawを直接所有しているわけではない。しかし、エージェントがユーザーの代わりにブラウザを開き、ターミナルを叩き、アプリケーションを横断する世界線において、最も重要になるのは「OSレベルのサンドボックス」である。
エージェントが暴走して社外秘情報を漏洩させたり、本番環境を吹き飛ばしたりしないよう、安全にエージェントを実行できる環境（新しいOSレイヤー）の提供こそが、プラットフォーマーたるMicrosoftの次なる主戦場なのだ。
開発者基盤からの逃避は許されない：インフラ改修の行方
プラットフォーマーとしてのビジョンを褒め称えて終わるのも座りが悪いので、最後に現実的な批判的コメントも付け足しておく。
AIエージェントの普及によってイノベーションの敷居が下がるのは大いに歓迎すべきことだ。しかし、プラットフォームの根幹たるインフラの安定性が損なわれては元も子もない。現状、多くのEnterprise顧客やハードコアな開発者たちは、GitHub Actionsの遅延や不透明なエラーに日々頭を悩ませている。
Daigleがインタビューで語ったインフラ改善のロードマップ（データベースの分離、コンピュートリソースの増強、ジョブキューイングの刷新）は確かに理にかなっており、向こう数ヶ月で段階的な改善が見込まれるとしているが、我々開発者としてはそれが「絵に描いた餅」で終わらないことを祈るばかりだ。新しいAI機能の華々しいローンチの裏で、基幹システムの可用性低下を「成長痛」という言葉だけで誤魔化し続けることはできない。
かつてGitHubがPRという概念を生み出し、ソフトウェア開発の歴史を変えたように、今度は「エージェント時代の開発プラットフォーム」のデファクトスタンダードを再定義できるか。インフラの火消しに追われるだけでなく、UXを損なわずにスケールする堅牢な基盤を一日も早く構築し、我々に「雪休み」の代わりに「純粋にコードと向き合う時間」を返してほしいものである。早急なるインフラ安定化に踏み切り、この懸念が単なる杞憂であったと証明してくれることを期待したい。