目錄
GitHubは無視しにくい数字を公開しました。プラットフォームが1か月に処理するcommit数は、今年4月の14億から現在の29億へ増加し、わずか4か月で2倍を超えています。この数字が登場したのはIncident Reviewの中でした。8月17日、GitHubでは7時間47分にわたる世界規模のService Outageが発生し、github.com、Authentication、GitHub Actions、API、Pull Requests、Issues、Copilotまで影響を受けています。GitHubが示した結論は明確で、新たなTraffic Peakに対し、米国中部Data Centerの重要なInfrastructure Componentが需要に合わせてScaleできず、そのCapacity PressureがほかのServicesへ連鎖しました。
29億という数字を見ると、「AI AgentがGitHubをパンクさせた」と直接結びつけたくなりますが、現在公開されているDataだけではそこまで断定できません。GitHubは29億件のcommitのうち、人間が直接作成したもの、Copilot、Claude Code、Codex、そのほかのAgentによるものがそれぞれ何件なのか公開しておらず、4月以降に増えた15億件すべてがAIによるものとも説明していません。ただしGitHubは今年4月の時点からTrafficの急増とagentic development workflowsをあわせて説明しており、5月のReliability UpdateではGitHub Trafficが急速に増加し、そのかなりの部分がAI-assistedおよびagentic development workflowsによって押し上げられていると明記しています。そのため今回のcommit急増をAgent普及という大きな流れの中で見ること自体は合理的ですが、Correlationをそのまま単一のCausationとして書くべきではありません。
毎日GitHubを使うDeveloperにとって、今回のIncidentでより注目すべきなのもこの部分です。AI Codingによる変化はIDEやPull Requestの中だけではなくなり始めています。Repository、API、Actions、Authentication、Code Review、その周辺Servicesまで、より多くのMachine-generated Operationsを受け止める必要があります。これは8月17日のGitHub OutageをAIのせいにできるという意味ではありませんが、GitHub自身が数か月前とはまったく違うTraffic Scaleを前提にInfrastructureを再設計し始めていることは確認できます。
GitHubの月間Commitが14億から29億へ増加、この数字は何を意味する？
Commit数が倍増しても、有効なコード生産量が倍増したとは限らない
GitHubが8月に公開した数字では、月間commitsが14億から29億へ増えています。同じGraphでは、月間merged pull requestsが約1.3億、新規Repositoriesが約2,400万に達しており、2025年から2026年にかけてPlatform Activity全体が明らかに加速しています。
ただしcommitそのものはSoftware Outputではありません。Developerが3日かけて1つのFeatureを完成させ、1回だけcommitする場合もあれば、同じ変更を10個のcommitsへ分割することもあります。Agentの場合、修正、Test、Failure Resultの確認、再修正というLoopの中で多くのIntermediate Operationsを残す可能性があります。そのため29億という数字は、「世界のSoftware Productivityが2倍になった」と見るより、GitHubが処理しなければならないRepository Activityの量として理解するほうが適切です。
GitHubは現在もhuman-authored commitsとagent-authored commitsの完全な比率を公開していません。確認できるのは、同社が4月の時点ですでに、2025年12月後半からAgentic Development Workflowsが明確に加速し、Repository Creation、Pull Request Activity、API Usage、Automation、Large-repository Workloadsが急増していると説明していたことです。2025年10月に始めた10倍Capacity Expansionの計画も、2026年2月には将来30倍のScaleを前提とする設計へ変更されています。
つまり今回残しておくべき数字は、「AIが29億回commitした」ではありません。GitHubが現在本当に毎月29億件のcommitを処理する必要があり、GitHub自身もAgentic Developmentを現在のTraffic Growthにおける重要な要因の一つと考えている、ということです。
GitHub自身も「成長」をIncidentの言い訳にはしていない
GitHubはIncident Reportの中で、こうしたGrowthはSystemが受けたPressureを説明する材料にはなるが、Incidentの言い訳にはならないという趣旨を明記しています。この区別は重要です。29億commitは需要側で起きた変化ですが、需要がCapacityを超える前にCritical Componentを十分Scaleできなかったことは、GitHub側が対応すべきReliability Problemだからです。
そのためGitHubは「AI Trafficが多すぎたから仕方がなかった」とIncident Reportを書いたわけではありません。需要がCapacityを超える前にCritical Componentを拡張できなかったことを直接認め、今後はCapacityの増強、Architecture Bottleneckの除去、Observabilityの改善、Service-to-service Retry Behaviorの見直しを進めるとしています。
GitHubは8月17日、なぜ7時間47分も停止した？
当日のDeploymentが壊したわけではないが、「Configurationに問題がなかった」とも言えない
GitHubが今回のIncidentについて示したHigh-level ConclusionはCapacity Failureで、8月6日と8月17日の2つのMajor Incidentsはいずれも、当日のCode ChangeやConfiguration ChangeがTriggerではなかったとしています。ただしTechnical Root Cause Analysisまで読むと、より詳しい状況が見えてきます。新たなPeak TrafficによってCentral USのLoad BalancerでNetwork Saturationが発生し、1つのIstio Sidecar PodがConcurrency Limitへ到達しました。しかし既存Autoscaling PolicyはHost Serviceだけを監視し、Sidecar Limitを正しく考慮していなかったため、Sidecarが需要に合わせてScaleしませんでした。
その後、1つのServiceで発生したCongestionがほかのNodesへ広がり、最終的に4つのHAProxy NodesがFlow Limitsを使い切りました。Gateway Authentication PathでLatencyとFailureが増え、Issues、Pull Requests、API、Actions、Git Operations、Copilot、Enterprise Authenticationまで影響が拡大しました。IncidentのPeakではWebとAPI Error Rateが約20％、ArchiveとRaw Content Download Error Rateは一時50％近くに達しました。
つまり、「Configuration Changeが原因ではない」と「Technical ReportにMisconfigured Policyが出てくる」は矛盾しません。前者は当日に新しいDeploymentやSetting Changeが入り、それが直接Serviceを壊したわけではないという意味です。後者は、Sidecar Capacityを十分考慮しないAutoscaling Configurationが以前からSystem内に存在していたものの、過去のTrafficでは表面化せず、8月17日の新しいPeakによって初めて問題になったという意味です。
これは単純に「Capacity不足で落ちた」と書くより実態に近い説明です。Capacityが中心的な問題だったことは確かですが、Incidentが拡大した背景にはAutoscaling Policy、Load Balancer Flow Limits、Authentication Dependency、Retry Behaviorもあり、複数のLimitへ同時に到達したことで、1 RegionのLoad ProblemがCross-service Incidentへ拡大しました。
Retry StormでGitHubが回復し始めてもCopilotだけ問題が続いたのはなぜ？
1回のFailureが10倍のTrafficへ増幅された
GitHubはIncident Reportで非常に具体的な数字を公開しています。Central USが回復し始め、一部TrafficをNorthern Virginiaへ移したあと、VS Code内に存在していた未発見のRetry Bugによって、Copilot Token OperationのFailure時に大量の追加Requestsが短時間で発生しました。その結果、通常7,000〜9,000 RPSだったCopilot Token ServiceへのTrafficが70,000〜100,000 RPSまで増え、ほぼ10倍に膨らみました。
これが、「Serviceが回復した」からといってTrafficもすぐ正常に戻るとは限らない理由です。大量のClientsが同時にErrorsを受け取り、それぞれがすぐRetryし、さらにGateway、Client、各Serviceに独立したRetry Logicがあれば、本来は単一Requestの成功率を上げるための仕組みが、Incident中には通常よりはるかに大きなTrafficを生み出します。GitHubは最終的にGateway Authentication Retriesを減らし、一部Copilot Token Requestsへ一時的に403を返してRetry Loopを止めたうえで、Regionごとに段階的にTrafficを戻す必要がありました。
このRetry Stormは、「AIは疲れないから無限にRetryする」という説明より重要です。Retry Storm自体はAI特有の問題ではなく、従来のClients、Microservices、Automation Systemsでも起こります。Agent普及で増えるのはMachine Operationsの数とFan-outです。1人の1つのIntentから複数のTool Calls、API Requests、Repository Operations、Tests、その後のFixesまで派生する可能性があります。こうしたFlowにConcurrency Limit、Backoff、Total Time Budgetがなければ、単純なManual OperationsよりもTraffic Amplificationを制御しにくくなります。
GitHubはどう直す？Serverを増やすだけでなく、連鎖的なLoadも制限する
Autoscaling・Retry Budget・Regional Failoverを同時に見直す
GitHub Technical RCAが挙げた今後の対応には、Autoscaling Policyを修正し、Service Mesh SidecarのConcurrencyとCapacityも正しくScalingへ反映させること、関連ServicesのIstio Request、Concurrency、Scaling Limitsを全面的に確認すること、GatewayとClientのRetry LimitおよびBackoff Behaviorを見直すこと、VS CodeでCopilot Token Trafficを増幅したRetry問題を修正すること、さらにLoad Balancer Capacity MonitoringとRegional Failover Safeguardsを改善することが含まれます。
GitHub CTOによる全体説明には、Development Teamにも参考になるキーワードがもう一つあります。Retry Budgetです。GitHubは今後、一貫したRetry Limits、Retry Budgets、Variable TimeoutsをService-to-service Interactionへ導入し、それぞれのServiceが自分の都合だけでRetryし続け、結果としてDownstreamを一緒に圧迫することを防ぐとしています。
Retry Budgetは単純な「失敗したら3回Retryする」とはかなり違います。例えばDownstream ServiceがOverloadしているとき、1,000のCallersがそれぞれ「あと数回試せば成功する」と判断すれば、総Trafficは増えるだけです。Retry BudgetではRetry自体をLimited Resourceとして扱い、大量Failureが起きているときには、一部RequestsをFail FastさせてもSystem全体を守ることを優先します。
GitHubはすでに大幅にCapacityを増強しているが、Demandの伸びがそれ以上に速い
GitHubがCapacity増強を8月になって初めて始めたわけではありません。公式によると、今年のReliability Workではすでに300万以上のCPU Cores、120 PBのHigh-speed Storage、大規模なNetwork Capacityが追加され、ServicesのAzure Migrationも継続しています。現在AzureはGitHub Platform Loadの約58％、Git Operationsの約半分を処理しており、5月時点のPlatform Load約12％と比べるとかなり速いペースで移行しています。
しかしこの数字は同時に、Agentic Software DevelopmentがInfrastructure Teamにとってなぜ難しいのかも示しています。Demand Curve自体が急速に変化しているからです。GitHubが昨年10月に計画していたのは10倍Capacityでしたが、数か月後には30倍Scaleで設計し始めています。さらにMonthly Commitsは4月から8月の間に14億から29億へ増えています。Capacity Planningは、現在の数字へ一定のGrowth Rateを掛ければ終わる問題ではなくなっています。
AI Agent Trafficは従来のDevelopment Trafficと何が違う？
違いは「AIは眠らない」ことではなく、1つのTaskが多数のMachine Operationsへ展開すること
「人間は眠るがAIは眠らない」と説明すると直感的ですが、問題を単純化しすぎます。GitHub Actions、CI Bots、Dependabot、そのほかのAutomation Servicesは以前から24時間動いており、GitHubにとってNon-human Traffic自体が新しいわけではありません。
Agentがもたらすより明確な変化はFan-outです。人間が「このBugを直して」と1回入力するだけで、その後AgentがRepositoryを読み、Branchを作成し、複数Filesを編集し、Testsを実行し、Failure Logsを確認し、再修正し、Pushし、Pull Requestを作成し、さらにReviewやCIの結果を見て次のRoundへ進む可能性があります。GitHub自身も4月と5月のReliability Updateで、Repository Creation、Pull Request Activity、API Usage、Automation、Large-repository Workloadsの急増をAgentic Development Workflowsの拡大と関連づけて説明しています。
そのため今後Platformが処理するのは、単に「深夜でも誰かがPushしている」というTrafficではないかもしれません。1 User Intentの裏側で、従来より多くのAPI Calls、Git Operations、Actions Runs、Review Activityが発生し、それらが同時実行され、高速でRetryされ、多数のAgentsによってParallelに動く可能性があります。
AWSも同じ週にGPT-5.6のCross-region Inferenceを拡大、Agent Trafficのもう一方を処理している
Amazon Bedrockは同日、GPT-5.6 Sol、Terra、LunaのAPI Supportを拡大し、3モデルをbedrock-runtimeからResponses、Chat Completions、Converse APIsで利用できるようにしました。さらにGlobalおよびGeo Cross-Region Inferenceを追加し、Requestsを複数AWS Regions間で自動Routingすることで、より高いThroughputを確保できるようにしています。
ただし、これを「GPT-5.6が25以上のAWS Regionsへ直接Deploymentされた」と書くことはできません。現在SolのIn-region Availabilityは主にUS Eastで、N. VirginiaとOhioが含まれます。TerraとLunaはさらにUS WestのOregonにも対応しています。Cross-Region InferenceではInference Profileを使い、条件に合うRegions間でCapacityを調整します。AWSは8月18日、TerraとLuna向けにIndia Geo Cross-Region Inferenceも追加し、DataをMumbaiとHyderabadという地理範囲内に維持しながら処理できるようにしています。
AWSとGitHubを並べると、同じ週に起きた興味深いUpstream／Downstreamの対照として見ることはできますが、両社に直接的な因果関係があるわけではありません。AWSが行っているのは、高DemandなModel Inferenceが複数RegionsからCapacityを取得できるようにすることです。GitHubが対応しているのはRepository、Actions、API、そのほかDeveloper InfrastructureのDemand急増です。両者に共通するのは、Agentic WorkloadsによってPlatformがThroughput、Burst Traffic、Capacity Schedulingを再設計する必要が出ていることです。AWS自身もGPT-5.6提供時に、Agent Trafficは非常にBurstyになりやすく、1 User Requestから大量のModel Callsが発生する可能性があると説明しています。
AI Coding Agentを使うなら、Development WorkflowにどんなGuardrailを追加できる？
Local Gitには引き続き作業可能なRepositoryを残す
Git自体はDistributed Version Controlなので、通常のLocal RepositoryにはBranch、Commit、作業履歴の大部分が保存されています。そのためGitHubが利用できない場合でも、Local Commit、Branch作成、Merge、Local Testは通常そのまま続けられます。GitHub Outageと一緒に止まりやすいのは、Pull Request Review、Issues、GitHub Actions、Webhooks、Authentication、GitHub APIやHosted Runnerへ依存するDeployment Workflowです。
そのため、別のGit Clientを準備することより、「GitHubがなくてもどこまで仕事が続くか」を確認するほうが重要です。GitHubが午後いっぱい停止しただけでLocal Testまで実行できなくなるなら、Workflow内の重要なStepsをRemote Serviceへ依存させすぎている可能性があります。
AgentのRetryを「失敗したらもう一度」だけにしない
自作Agent、Script、AutomationからGitHub APIを呼ぶなら、少なくともMaximum Retry Count、Exponential Backoff、Jitter、Total Deadlineを設定し、Serviceが返すRate LimitやRetry-After Signalsにも従うべきです。今回GitHubでCopilot Token Serviceが通常7,000〜9,000 RPSから70,000〜100,000 RPSまで増幅した事例は極端ですが、重要なReminderになります。Retryは本来Success Rateを上げるものですが、Total LimitがなければIncident Amplifierにもなります。
Coding AgentではさらにConcurrency Limitを加えることもできます。例えば同じRepositoryで同時に動かせるAgent数、1分間にPushできる回数、CI Failure後の自動修正Roundsなどに上限を設定し、それを超えたら停止してHumanへ渡します。Agentに無制限でRetryさせるより、こちらのほうがControlしやすくなります。
GitHubのCapacityを助けるためにすべてのCommitをSquashする必要はない
Agentによる細かなCommitsをすべてSquashしてからPushすることを、「GitHubへのWrite Pressureを下げるため」の一般的なBest PracticeにするだけのDataは現在ありません。Commit HistoryをSquashするかどうかは、Review、Bisect、Rollback、TeamのVersion Control Policyに基づいて決めるべきです。
よりControlする価値があるのはPush、PR、CIのFrequencyです。AgentがLocal Branchで数Roundsの修正とTestsを完了してからBatch Pushすれば、1行変更するたびに新しいRemote Event、Webhook、CI Runを発生させる必要はありません。そのうえでMain BranchのHistoryを簡潔にしたい場合は、Team Policyに合わせてSquash Mergeを使えます。この方法ならAutomation Churnを減らしながら、Commit数を減らすことだけを目的に有用なDevelopment Historyを捨てずに済みます。
GitHub StatusをIncident確認Workflowへ直接組み込む
GitHub StatusではIssues、Pull Requests、Actions、API、Git Operations、CopilotなどのRecovery Statusが継続的に更新され、Status PageにはEmail、SMS、Slack、Webhook、Atom、RSS Subscriptionも用意されています。GitHubへ日常的に依存するTeamなら、Official Status Feedを既存Notification Systemへ組み込むほうが、Errorが出たあと30分かけてGitを再インストールしたりRouterを調べたりするより実用的です。
Small Teamでも新しい大規模Monitoring Platformを構築する必要はありません。少なくともGitHub、主要Model API、Deployment Platform、Cloud ProviderのOfficial Statusを同じ場所からすぐ確認できるようにするだけで、多くの不要なLocal Troubleshootingを先に除外できます。
Single Point of Failureを見直すとき、Git Repositoryだけを見ない
Git Repository自体はLocal Copyを残しやすい一方、GitHubで本当に代替が難しいのは周囲のServicesです。Pull Requests、Code Review、Issues、Actions、Secrets、Branch Protection、Packages、Webhooks、Deployment Approval、Third-party Integrationsなどがあります。
そこで具体的に一つ質問できます。GitHubが朝から夜まで停止した場合、何が通常通りできて、何が完全に止まるのか。特定Repositoryに非常に厳しいRecovery Time Objectiveがあるなら、Secondary Remote、Mirror、Alternative CI Pathを検討できます。一方、一般的なPersonal Projectなら、Localで作業でき、Service Recovery後にPushできると分かっていれば十分な場合もあります。BackupやRedundancy自体にもMaintenance Costがあるため、すべてのProjectをDual-platform High Availabilityへする必要はありません。
今回のGitHub Incidentが示したのは、AIがより多くのCodeを書いたことだけではない
GitHubの月間29億commitsは非常に大きな数字ですが、AI Productivity Rankingではなく、4か月でSoftware Outputが2倍になった証拠でもありません。より確実に言えるのは、GitHub Platform Activityが非常に速く増えており、GitHub自身もAI-assistedおよびAgentic Development WorkflowsがこのTraffic Growthの重要な要因だと繰り返し説明していることです。
新たなTraffic PeakがSidecar Capacityに合わせて正しくScaleしないAutoscaling Policyへぶつかり、その後Load Balancer Flow Limits、Authentication Dependency、Retry Amplificationが重なったことで、局所的なCapacity Pressureが7時間47分に及ぶCross-service Incidentへ変わりました。
日常的にCoding Agentを使うDeveloperにとって、29億commitsのうち何件をAIが書いたのか追及するより実用的なのは別の問題です。Codingが安くなり、自動化されるほど、Push、CI、Review、API、Deployment、Retryまで一緒に増える可能性があります。Agentがどれだけ速く次のVersionを書けるかは前半にすぎず、その後のInfrastructureがそれらのOperationsを安定して受け止められるかも、すでにDevelopment Workflowの一部になり始めています。
よくある質問 FAQ
現時点ではそのように断定できません。GitHubは月間commit数が4月の14億から29億へ増えたことを確認しており、最近のTraffic Growthのかなりの部分がAI-assistedやAgentic Development Workflowsによって押し上げられているとも説明しています。しかし8月17日のPeak Trafficのうち何％がAI Agentによるものだったのかは公開しておらず、AgentがIncidentの単一原因だったとも述べていません。直接的なTechnical CauseはCentral USのCapacity Pressureと、その後のAutoscaling、Load Balancer、Retry Problemsによる連鎖障害です。
GitHubが言っているのは、Incidentが当日新しくDeployされたCodeやConfiguration ChangeによってTriggerされたわけではないということです。一方、Technical RCAでは既存Autoscaling PolicyがHost Serviceだけを監視し、Istio SidecarのConcurrency Limitを正しく監視していなかったため、Peak Traffic時に必要なScaleが行われなかったことが確認されています。より正確には、「新しいSetting ChangeがIncidentを起こしたわけではないが、既存Autoscaling ConfigurationにはGapがあった」ということです。
いいえ。29億はGitHubが現在1か月に処理しているcommit activityの量であり、有効なCode量、Software Output、Developer Productivityへ直接換算することはできません。またGitHubは、このうちHumanとAI Agentがそれぞれ何％を占めるか公開していません。
GitHubへのPlatform Loadを下げることだけを目的に、すべてSquashする必要はありません。Commitsを残すかどうかはTeamのReview、Bisect、History Policyに基づいて決めるべきです。AgentによるRemote Operationsを減らしたい場合は、Local Branchで複数Roundsの変更を終えてからBatch Pushし、PR、CI、RetryのTrigger Frequencyを制御するほうが実用的です。
通常は使えます。GitはDistributed Version Controlなので、Local RepositoryからCommit、Branch作成、Merge、History確認などを続けられます。影響を受けるのは主にGitHub Serverを必要とするPull Requests、Issues、Actions、API、Remote Push／Pull、そのほかHosted Servicesです。
直接的な関係はありません。AWSは8月17日にGPT-5.6 Sol、Terra、LunaのCross-Region Inference対応を発表し、Model Requestsを複数Regions間でCapacity SchedulingすることでThroughputを高めています。一方GitHubはDeveloper Platform上で急増しているRepository、API、Actions、そのほかのTrafficを処理しています。両者はAgentic WorkloadsがInfrastructure Capacityへ与える影響を観察する例として並べることはできますが、AWSがUpstream Model Capacityを増やしたことがGitHubのDownstream Incidentを直接引き起こしたと書くことはできません。