GitHubで異変、年間179億回のコード更新とPRの4割超がAI起点に　急成長がインフラの限界を露呈

生成AIによるソフトウェア開発は、コードの入力を補助する段階から、AIエージェントに作業そのものを任せる段階へと移りつつある。開発者はコードを1行ずつ書く代わりに、修正したい内容や達成すべき目標を指示し、リポジトリ全体にまたがる変更をエージェントに委ねるようになった。この変化は開発の進め方を変えるだけでなく、コード共有プラットフォームのGitHubにも、かつてない規模の負荷をもたらしている。

GitHubが2026年10月28日に公開した年次報告書「Octoverse 2026」は、その変化を具体的な数字で明らかにした。コードのプッシュやコミット、プルリクエストの数が急増し、AIエージェントの利用も短期間で拡大している。一方、GitHubは増大する処理負荷に対応しきれず、大規模なサービス障害を繰り返してきた。同社が公開したインフラの技術資料と併せて見ると、AIエージェントの普及がソフトウェア開発の生産性だけでなく、その基盤となるシステムの設計にも変化を迫っていることが分かる。

年間179億回のプッシュが示すAIエージェント時代の開発規模

Octoverse 2026の集計期間は、2025年10月1日から2026年9月30日までの12カ月間である。今回の統計には公開リポジトリと非公開リポジトリの両方が含まれており、特に断りがない限り、この範囲で集計されている。過去の報告書では公開アクティビティを中心に、9月から翌年8月までを対象としていたため、GitHubは2024年と2025年の数値を今回と同じ定義・期間で再計算した。したがって、以前の年次報告書に掲載された数字と直接比較する際には、集計方法の違いに注意が必要だ。

統一した集計基準で比較すると、2026年の活動量は過去2年間を大きく上回った。年間のコードプッシュ数は179億回に達し、2024年の52億回と2025年の67億回を合わせた119億回を超えた。公開・非公開リポジトリを合わせたコミット数も343億回となり、2024年の100億回から3倍以上に増えている。コードの変更をGitHubに送信する頻度が、わずか2年間で大幅に高まったことになる。

2024年と2025年のプッシュ数、コミット数、プルリクエスト数、Actionsジョブ実行数には、GitHubがOctoverse 2026で公開した再計算値を使用している。オープンソースへの貢献数は公開リポジトリを対象とする別の指標であり、2024年の比較値は上記の資料では示されていない。

コードの変更だけでなく、レビューや自動化に関する活動も増えている。2026年にマージされたプルリクエスト（PR）は13億件に達し、1日平均で約350万件が取り込まれた計算になる。オープンソースへの公開貢献数も、2025年の11億2,000万件から2026年には25億件へと増加した。この貢献数には、コードのプッシュに加えてIssueの作成、PRの作成やレビュー、ディスカッションへの参加などが含まれる。1回のプッシュに複数のコミットが含まれていても、貢献数では1回として数えるため、コミット総数と貢献数は同じ指標ではない。

GitHubの開発者人口も拡大を続けている。2026年9月時点で世界の開発者数は2億2,500万人を突破し、国別では米国が3,830万人、インドが3,200万人で上位を占めた。両国とも、この1年間にそれぞれ1,000万人以上の開発者が増えている。日本は715万人で、米国、インド、中国、ブラジルに次ぐ世界第5位となった。

{
  "type": "bar",
  "title": "主要国のGitHub開発者人口（2026年9月時点）",
  "unit": "百万人",
  "categories": ["米国", "インド", "中国", "ブラジル", "日本", "英国", "インドネシア", "ドイツ"],
  "series": [
    {
      "name": "開発者数",
      "values": [38.3, 32.0, 12.4, 10.2, 7.15, 6.47, 6.34, 6.30]
    }
  ],
  "caption": "GitHubのユーザープロファイルに登録された所在地に基づく集計",
  "source": "GitHub Octoverse 2026"
}

GitHub上の活動が特に急増したのは、2026年6月以降だ。同社のデータでは、開発アクティビティは1月から徐々に増えていたが、6月を境に増加ペースが大きく加速した。この時期は、大規模言語モデル（LLM）の性能向上に加え、エージェントの動作を支えるハーネスや開発ツールが成熟した時期とも重なる。AIエージェントは単発のチャットでコードを提案するだけでなく、複数日にまたがる作業を継続し、専門的な役割を持つ別のエージェントを呼び出すようになった。ローカル環境だけでなく、クラウド上で複数の作業を並列実行できるようになったことも、活動量の急増に関係していると考えられる。

6月以降のコミットの約55%は、2026年に新たに作られたリポジトリから生まれていた。ただし、活動の拡大は新規開発者だけによるものではない。過去12カ月間にコードをプッシュした開発者のGitHub利用歴は平均36カ月であり、8月にPRを作成した開発者の75%以上が9月にもコードをプッシュしていた。また、開発者1人が関与するリポジトリ数も、1年前に比べて平均10%増えている。新しいプロジェクトが増える一方、既存の開発者もより多くのリポジトリで活動するようになったことが分かる。

こうした変化は、自動化された開発基盤の利用状況にも表れている。GitHub Actionsは2026年に毎秒平均1,440回のジョブを実行し、1日当たり約1億2,400万回、年間では約454億回に達した。年間の実行数は前年の3倍以上である。依存関係の更新を自動化するDependabotによってマージされたPRも3,000万件を超え、2025年のおよそ2倍になった。AIによるコード生成だけでなく、テスト、ビルド、セキュリティ検査、依存関係の更新まで、開発工程全体で自動処理が増えている。

PRの4割超がエージェント起点に、コードレビューの役割も変化

Octoverse 2026で特に注目すべきなのが、プルリクエストを作成する際のAIエージェントの関与率だ。2026年3月には、エージェントが作成した初案から始まるPRは全体の17%だったが、9月には40%を超えた。9月の1カ月間だけで、エージェントを起点とするPRは1億1,000万件に達し、3月の約6倍に増えている。開発者が変更内容を指示し、エージェントがコードを生成した後、人間がレビューするという開発手順が急速に広がっている。

ただし、この割合はGitHubが検知できたエージェントの利用状況に基づく。GitHubは、エージェントによるPR作成など、実際に観測できる利用の兆候を「エージェントシグナル」として集計している。開発者がローカル環境でAIを使ってコードを作成した場合など、検知対象に含まれない利用も存在する。そのため、シグナルが検知されなかったPRを、必ずしもAIを使わずに作成したものとみなすことはできない。

エージェントが関与したPRには、変更対象の広さにも特徴がある。複数ファイルにまたがる変更を含む割合は、エージェント起点のPRで87%だったのに対し、エージェントシグナルのないPRでは79%だった。AIエージェントは単一の関数や設定だけでなく、複数のファイルに影響する変更にも利用されている。

PRが作成されてからマージされるまでの状況にも変化が見られる。2026年2月時点では、2週間以内にマージされた割合はエージェント起点のPRが83%で、比較対象となるPRの約86%を下回っていた。しかし9月には、比較対象のPRが約86%でほぼ横ばいだったのに対し、エージェント起点のPRは90%まで上昇した。エージェントが生成した変更を、より短期間でマージできるようになったことが分かる。

もっとも、マージ率の改善だけでAIが生成するコードの品質が向上したと断定することはできない。開発チームのレビュー手順が改善された可能性や、エージェントに任せる作業の内容が変わった可能性もある。また、エージェントシグナルのないPRにも検知されていないAI利用が含まれるため、両者の数字を人間とAIの純粋な性能比較として扱うことは適切ではない。

GitHub Copilotの利用動向も、エージェントへの作業委任が広がっていることを裏付けている。Copilotの月間アクティブユーザーのうち、エージェント機能を利用する割合は前年の35%から55%へと上昇した。特に、開発者が作業を割り当てた後、エージェントが独立して処理を進める「Copilot cloud agent」の利用規模は前年比230%増となり、対話型のエージェントチャットの85%増を大きく上回った。開発者はAIに質問するだけでなく、具体的な作業の実行を任せるようになっている。

エージェントに委ねられる作業の範囲も広がっている。相互運用性やリバースエンジニアリングに関する言及を含む公開リポジトリの新規作成数は、2025年の約3万件から2026年には13万件超へと増加した。前年比の伸び率は300%を超えており、既存システムとの互換性の確保やプロトコルの再実装といった領域への関心が高まっている。ただし、この数字は関連する用語を含むリポジトリ数であり、すべてのプロジェクトでAIエージェントが利用されたことを示すものではない。

一方、コード生成の速度が上がるほど、人間によるレビューの負担も大きくなる。GitHubはこの課題に対応するため、2026年7月30日に「Stacked pull requests」のパブリックプレビューを開始した。関連する変更を小さなPRに分割し、依存関係を維持したまま順番にレビューできる機能で、9月までに26万4,000人以上の開発者が利用した。AIを活用したコードレビュー機能とGitHub Advanced Securityの利用量も、それぞれ前年比90%以上増加している。

セキュリティ対策の処理量も増えている。APIキーやパスワードなどの機密情報が誤ってリポジトリに送信されるのを防ぐプッシュプロテクションは、年間58億回のスキャンを実施した。これは前年のおよそ4倍に相当する。AIエージェントが大量の変更を生成できるようになったことで、開発組織にはコードの作成速度だけでなく、変更内容を検証し、安全性を確保する能力がこれまで以上に求められている。

開発負荷の急増で大規模障害が発生、GitHubがストレージ基盤を全面刷新へ

AIエージェントによる開発の拡大は、GitHub自身のインフラにも大きな負荷をかけている。2026年4月には14億回だった月間コミット数が、8月には29億回、9月には74億回へと急増した。4月から9月までの5カ月間で5倍以上に膨らみ、9月のコミット数は前年同月の約6倍に達している。人間の開発者だけでなく、複数のエージェントが同時にコードを変更するようになったことで、GitHubに求められる処理能力は短期間で大きく変わった。

GitHubは需要に対応するため、2026年に400万CPUコア、160ペタバイト（PB）の高速ストレージ、毎秒50テラビット（Tb/s）のネットワーク帯域を追加したと発表している。しかし、こうした大規模な設備増強にもかかわらず、サービス障害を防ぐことはできなかった。特に2026年8月には、GitHub Actionsや認証、APIなど、開発に不可欠な複数のサービスが長時間停止する事態となった。

GitHubが8月20日に公表した障害報告によると、8月17日の障害は7時間47分に及んだ。米国中部のデータセンターで重要なインフラコンポーネントが急増したトラフィックに対応できず、認証処理などに障害が波及したことが原因だった。影響はgithub.comのウェブインターフェースだけでなく、GitHub Actions、REST/GraphQL API、プルリクエスト、Issue、Copilotなどの主要機能にも及んだ。また、これに先立つ8月6日には、GitHub Actionsで10時間42分にわたる障害が発生している。

GitHubは、両方の障害について、コードや設定の変更ではなく、処理能力の不足が根本的な原因だったと説明している。需要がシステムの処理能力を超える前に、基幹コンポーネントを十分に拡張できなかったというわけだ。英メディアThe Registerの報道では、GitHubのステータスページを再構成した外部データに基づき、2026年5月7日時点の過去90日間の可用性が約84%まで低下していたと指摘している。ただし、この数値はサービス障害の発生時間を独自に集計したもので、GitHubが個々のサービスについて公表する稼働率やSLA達成率と同じ指標ではない。

エージェント関連機能も、負荷の急増による障害を経験している。2026年4月の可用性レポートによると、4月9日に発生したCopilot coding agentの障害では、新規セッション要求の約84%で処理が遅延した。通常15〜40秒程度のキュー待機時間が最大54分に達し、約2万2,700件のワークフロー作成が遅延または失敗した。原因はレート制限の実装上の不具合で、本来は個別のインストール単位に適用すべき制限が、利用者全体に適用されていたことだった。クライアント側の更新によって内部APIへのアクセスが通常の3〜4倍に急増したことも、障害を悪化させた。

こうした問題を受け、GitHubはハードウェアの追加だけでは今後の需要に対応できないと判断し、システムの構造そのものを見直し始めた。MicrosoftのCoreAI部門を率いるJay Parikh氏は、2026年10月28日のGitHub Universe 2026に関する公式発表で、処理能力の追加は重要だが、それだけでは目標を達成できず、アーキテクチャの変更が必要になったと説明している。

その中心となるのが、Gitストレージ基盤の再設計だ。GitHubが10月6日に公開した技術解説によると、従来のシステムでは、リポジトリのデータを複数のストレージサーバーに保持し、書き込み時に分散クォーラムを通じて整合性を確保していた。しかし、リポジトリ単位で書き込み処理を直列化する仕組みには、同じリポジトリに対して大量の書き込みが発生すると、処理が集中してしまうという制約がある。

人間の開発者が比較的少ない頻度で変更をプッシュする環境では、この方式でも大きな問題になりにくかった。ところが、数千のエージェントが同じリポジトリ内で別々のブランチを更新する環境では、書き込み処理が一つの待機列に集中しやすくなる。また、従来の設計では読み取り負荷を分散するために複製を増やすと、書き込み時に同期する対象も増えるため、読み取り能力の強化が書き込み処理を遅くするという問題もあった。

GitHubが進めている新アーキテクチャは、この制約を解消するため、主に二つの変更を取り入れる。第一に、書き込みの排他制御をリポジトリ全体ではなく、ブランチやタグなどの個々の参照（reference）単位に細分化する。第二に、永続的なデータ保存を担うストレージと、リクエストを処理する計算資源を分離し、それぞれを独立して拡張できるようにする。

GitHubが10月21日に公開した技術解説では、参照単位の排他制御について、実際のトラフィックを模した社内テストで書き込みスループットが3〜4倍に向上したと報告している。別途、次世代アーキテクチャ全体の内部ベンチマークでは、最大35倍の書き込みスループットを確認したという。ただし、両者は異なる段階の技術を対象とした測定結果であり、既存の本番環境全体で35倍の性能向上が達成されたわけではない。また、具体的な測定条件や第三者による再現結果は公開されていない。

新アーキテクチャでは、Microsoft Azureのオブジェクトストレージをデータの永続的な保存先とし、読み取り処理を担当する計算資源を必要に応じて増減できる構成を目指している。読み取り専用の処理ノードが障害で失われても、永続的なストレージからデータを取得して復旧できるため、従来のように完全なリポジトリの複製を再構築する必要を減らせる。さらに、複数のエージェントが異なるブランチへ同時に書き込む場合には、参照単位の制御によって不要な待機を抑えられる。

ただし、これらの仕組みは段階的に導入されている最中だ。2026年10月21日時点で、GitHub上のリポジトリの99.99999%はAzure上にも複製が置かれる構成となっているが、従来のストレージ基盤からの移行が完全に終わったわけではない。最も書き込み頻度の高い一部のリポジトリでは、リージョン間の通信遅延が移行の制約になっている。GitHubはAzure上のマルチリージョン構成への移行を2027年初頭までに完了する計画であり、新しいストレージ設計も順次導入していく方針だ。

AIエージェントの普及がGitHubの障害を引き起こした唯一の原因だと断定することはできないが、急激な処理負荷の増大が既存システムの限界を表面化させたことは、GitHub自身の障害報告と技術資料からも確認できる。今後は、新アーキテクチャによって実際の本番環境で処理能力がどれだけ改善するかに加え、障害の発生頻度や影響範囲が縮小するかが重要になる。GitHubへの依存度が高い開発組織にとっては、AIエージェントの性能だけでなく、コード管理基盤の可用性も運用設計に織り込む必要がある。

単一モデルの選択から複数モデルの連携へ、Copilot Fusionが変えるAI開発のコスト構造

AIエージェントの利用拡大と並行して、開発者がAIモデルを選ぶ方法も変化している。Octoverse 2026によると、GitHub Copilotでモデルを自分で選択しているユーザーのうち、複数のモデルを使い分けている割合は2026年5月の50%から9月には61%へと上昇した。有料プランの利用者が使用したモデルの種類も、5月の29モデルから9月には47モデルへと増加している。9月には、単一モデルがリクエスト全体の25%を超えることはなかった。

モデルの選択傾向を詳しく見ると、開発者が用途に応じて異なる特性のモデルを使い分けていることが分かる。ユーザーが明示的にモデルを指定したリクエストでは、汎用モデルが38%、高度な推論や計画を得意とするモデルが37%、高速・軽量モデルが25%を占めた。この集計には、Copilotの自動モデル選択によるリクエストや、GitHubとMicrosoftの社内利用、監視・テスト目的のリクエストなどは含まれていない。したがって、Copilot全体の推論処理量ではなく、開発者が自分でモデルを選んだ場合の利用傾向を示している。

{
  "type": "bar",
  "title": "Copilotで明示的に選択されたリクエストのモデル分類比率",
  "unit": "%",
  "categories": ["汎用モデル", "高度な推論・計画モデル", "高速・軽量モデル"],
  "series": [
    {
      "name": "リクエスト比率",
      "values": [38, 37, 25]
    }
  ],
  "caption": "2026年9月のモデル利用状況を基にした分類。自動モデル選択によるリクエストなどは対象外",
  "source": "GitHub Octoverse 2026"
}

こうしたモデルの使い分けを自動化するため、GitHubは2026年10月28日、新機能「GitHub Copilot Fusion」の一般提供を開始した。GitHubの公式発表によると、Copilot Fusionは独立した新しいAIモデルではなく、タスクに応じて適切なモデルを選び、必要に応じて複数のモデルを連携させる実行時のルーティング・オーケストレーション機構だ。開発者が作業内容に合わせてモデルを手動で切り替える必要を減らし、処理品質とコストのバランスを取ることを目的としている。

Copilot Fusionは、タスクの内容に応じて3種類の実行パターンを使い分ける。「Single」は単一モデルで処理を完結させる方式、「Cascade」は効率的なモデルで最初の回答を生成し、品質を評価した上で必要に応じて高性能なモデルへ引き継ぐ方式だ。「Critique」では、あるモデルが作成した回答を別のモデルが検証し、その結果に基づいて最初のモデルが修正を行う。すべてのタスクで複数モデルを呼び出すのではなく、作業の難度に応じて処理方法を選択する仕組みとなっている。

開発者はモデル名の代わりに、「Standard」「High」「Max」という3段階のエフォートレベルを選べる。Standardは日常的な開発作業での品質、コスト、応答速度のバランスを重視し、Highは複雑な不具合の修正や複数ファイルにまたがる変更などに対応する。Maxは最も高度な推論能力を必要とするタスク向けの設定だ。Copilot FusionはVisual Studio Code、GitHub Copilot CLI、Copilotアプリ、JetBrains IDEで利用できる。

この機能の前身となったのが、2026年9月4日に研究プレビューとして公開された「Project HydraFusion」だ。GitHubによると、プレビュー期間中にはCLIとCopilotアプリを通じて約6万セッションのルーティングが実行された。同社の内部評価では、コーディングベンチマーク「TerminalBench 2.1」において、Claude Opus 5を基準とする構成と同等以上の成績を維持しながら、推定コストを67%削減したと説明していた。ただし、この数字はGitHubが実施したオフライン評価に基づくものであり、すべての開発作業に同じ削減率が当てはまるわけではない。

一般提供されたCopilot Fusionについては、外部の評価機関による検証結果も公開されている。Artificial Analysisが2026年10月28日に発表した評価では、最上位設定のCopilot Fusion Maxが「Coding Agent Index v2.0」でスコア60.0を記録した。比較対象となるClaude CodeとClaude Opus 5.5 Maxの構成は61.7であり、両者の差は1.7ポイントだった。

この比較はArtificial Analysisのエージェント比較データに基づく。トークン消費量は同社の解説記事で約720万トークン、比較データでは丸め方の違いにより約730万トークンと表示されている。APIコストはベンチマークで消費したトークンに基づく推計であり、サブスクリプション料金や企業の総運用コストを示すものではない。

この結果で注目されるのは、性能とコストのバランスだ。Copilot Fusion Maxは、Claude CodeとOpus 5.5 Maxを組み合わせた構成に近い総合スコアを維持しながら、タスク当たりの平均APIコストを約半分に抑えた。トークン消費量もほぼ半分となっており、複数モデルを組み合わせることで、常に最も高性能なモデルを使う場合とは異なるコスト構造を作れることが分かる。

ただし、総合スコアが近いからといって、すべてのコーディング作業で同等の性能が得られるわけではない。Artificial Analysisの評価では、Copilot Fusion Maxは「Terminal-Bench 4.0」で71を記録した一方、リポジトリに対するコード変更を評価する「FrontierCode」では51となり、Claude Code + Opus 5.5 Maxの56を下回った。リポジトリの内容に関する質問応答を評価する「SWE-Atlas-QnA-AA」でも、Copilot Fusion Maxの57に対して比較対象は66だった。つまり、ターミナル操作を伴う作業では高い性能を発揮したものの、コード変更やリポジトリ理解では差が残っている。

所要時間についても、評価条件を踏まえる必要がある。GitHubはCopilot Fusion Maxが比較対象より約40%短い時間でタスクを処理したと説明しており、Artificial Analysisの比較ページにも36.1分と約60分という数値が掲載されている。ただし、これは特定のベンチマークにおける平均値であり、実際の開発現場での作業時間をそのまま予測するものではない。処理するリポジトリの規模やタスクの難度、呼び出されるモデルの組み合わせによって、結果は変わる可能性がある。

料金体系も、単一モデルの利用とは異なる。GitHubの公式ドキュメントによると、Copilot Fusion自体に追加料金は設定されていないが、内部で使用した各モデルの料金が、それぞれの標準レートに従って課金される。GitHubは2026年11月30日まで、有料Copilotプランの利用者に対してFusionのモデル利用料金を30%割り引く措置を実施している。また、StandardはすべてのCopilotプランで利用できるが、HighとMaxはPro+、Max、Business、Enterpriseなどの対象プランに限られる。

2026年9月時点で、有料Copilotユーザーの63%が自動モデル選択機能を少なくとも1回利用していたことも、こうした仕組みへの需要を示している。今後は単一モデルの性能だけでなく、作業内容に応じてモデルを振り分ける仕組みや、必要な品質をどれだけ低いコストで確保できるかが競争上の重要な要素になると考えられる。一方、企業が導入する際には、複数モデルの呼び出しによる課金額の変動や、選択されたモデルの確認、管理者による利用制限など、従来とは異なる運用上の課題にも対応する必要がある。

AIエージェントは建設・製造業にも浸透、TypeScriptの存在感が拡大

Octoverse 2026では、AIエージェントの普及がソフトウェア産業以外にも広がっていることが明らかになった。GitHubは今回初めて、公開リポジトリがどの産業分野に関係しているかを分析した。具体的には、2022年から2026年に作成された公開リポジトリから無作為に抽出したサンプルを対象に、リポジトリ名や説明文、トピック、READMEなどを多言語埋め込みモデルで分類した。産業分類には北米産業分類システム（NAICS）を使用している。

その結果、従来はソフトウェア開発との結び付きが比較的弱かった産業でも、公開リポジトリ数が大幅に増えていた。2022年を基準とすると、鉱業・採石・石油ガス採掘分野は約65倍、建設業は約18倍、事務・支援サービス業は約17倍に拡大した。専門・科学・技術サービス業は約5倍、製造業も約2.8倍となっている。

{
  "type": "bar",
  "title": "2022年比の産業別公開リポジトリ増加倍率",
  "unit": "倍",
  "categories": ["鉱業・石油・ガス採掘", "建設業", "事務・支援サービス", "専門・科学・技術サービス", "製造業"],
  "series": [
    {
      "name": "増加倍率",
      "values": [65, 18, 17, 5, 2.8]
    }
  ],
  "caption": "NAICS分類に基づく公開リポジトリ数の変化。2022年時点の母数が小さい分野では増加倍率が大きくなりやすい",
  "source": "GitHub Octoverse 2026"
}

特に鉱業分野の約65倍という数字は大きいが、2022年時点のリポジトリ数が少なかったことにも注意が必要だ。元の母数が小さい場合、少数のプロジェクトが増えるだけでも成長倍率は大きくなる。また、今回の分類はリポジトリの説明文などに基づく推定であり、各産業で実際に稼働しているソフトウェアの数を直接示すものではない。それでも、情報通信業以外の分野でもソフトウェア開発に関する公開活動が広がっていることは確認できる。

産業別の利用傾向を見ると、AIへの関心とエージェントの実際の利用には違いがある。事務・支援サービス、鉱業、医療、農業などでは、リポジトリの40%以上がREADMEやトピックでAIに言及している一方、エージェントによって作成されたPRが確認されたリポジトリは3%未満だった。これに対して建設業では、AIへの言及があるリポジトリは約25%だったものの、約9%でエージェント起点のPRが検知された。これは調査対象の産業の中で最も高い割合であり、製造業がそれに続いている。

この差は、AIに関するソフトウェアを開発することと、AIエージェントを開発作業に使うことが別の活動であることを示している。たとえば、AIを利用した分析サービスを開発していても、実際のコード作成には人間が中心となって取り組んでいる場合がある。一方、AIそのものを主題としないプロジェクトでも、コードの修正やテストをエージェントに任せることは可能だ。ただし、GitHubの調査で検知できるのはエージェント利用の一部であり、産業ごとの実際の利用率を完全に把握したものではない。

プログラミング言語の利用状況にも変化が見られる。2026年の月間アクティブコントリビューター数では、TypeScriptが引き続き首位となり、Pythonが2位、JavaScriptが3位だった。2025年9月から2026年9月までの増加数は、TypeScriptが362万人、Pythonが323万人、JavaScriptが182万人となり、上位2言語の伸びが目立つ。主要言語の中で前年比の伸び率が最も高かったのはRustで、コントリビューター数は約2倍に増加した。

エージェント利用との関係では、TypeScriptの採用率が特に高い。2026年に新設されたリポジトリのうち、エージェントシグナルが検知されたものでは、TypeScriptを主要言語とする割合が35%だった。一方、シグナルが検知されなかったリポジトリでは24%にとどまった。2026年より前に作られたリポジトリでも、シグナルありで27%、シグナルなしで17%と、同様の傾向が確認されている。

マージされたPRにおけるAIの関与率にも、言語による違いがある。TypeScript、Python、RustではAIの関与が検知されたPRの割合が40〜44%に達した一方、Java、C#、C++では21〜34%だった。主要言語のいずれでもAIの関与が一定の割合で確認されているものの、特に成長率の高い言語では、その割合も高くなっている。

GitHubは、この傾向の背景として、静的型付けやコンパイラによる検証のしやすさが関係している可能性を挙げている。TypeScriptやRustでは、型チェックやコンパイル時のエラーを利用することで、生成されたコードの問題を機械的に発見しやすい。エージェントにとっても、出力したコードを検証し、エラーを修正するための明確な手掛かりが得られることは利点となり得る。

ただし、今回の統計から、AIエージェントがTypeScriptなどの言語を自発的に選んだと断定することはできない。開発者が最初からその言語を指定している場合もあれば、対象リポジトリの既存言語に従って変更している場合もある。また、AIの利用が多いから言語の採用が増えたのか、その言語を使う開発者がAIを積極的に導入しているのかも、今回の観測データだけでは区別できない。言語の特性とエージェントの利用傾向に関連が見られることは確かだが、その因果関係については今後の検証が必要だ。

日本の開発者コミュニティも、こうした世界的な変化の中で成長を続けている。日本のGitHub開発者数は715万人で世界第5位となっており、GitHubはアジア太平洋地域の成長を支える要因として、各国政府によるAIインフラ投資や人材育成を挙げた。特に日本については、AIインフラへの継続的な投資が開発者コミュニティの成長を支えていると説明している。

一方、今後の開発者人口がどこまで増えるかについては、不確実性が大きくなっている。GitHubは過去の登録者数や利用動向を基に、43種類の時系列モデルと回帰モデルを用いて2031年の開発者人口を予測した。その結果、21モデルが2026年比で3倍以上、19モデルが2倍以上3倍未満の成長を見込んだ一方、2倍未満と予測したモデルは3つだけだった。多くのモデルが大幅な成長を示しているものの、予測結果には大きな幅があり、将来の開発者人口が確定したわけではない。

2026年の急激な成長は、それまでの傾向を基にした将来予測を難しくしている。AIエージェントによってコードを書く負担が減れば、従来はソフトウェア開発に関わっていなかった人々もプロジェクトに参加しやすくなる可能性がある。しかし、そうした変化が今後も同じ速度で続くかどうかは分からない。GitHubが示した43モデルの予測結果は、今後の成長余地の大きさと、その見通しの不確実性を同時に表している。

今回のOctoverse 2026で明らかになったのは、AIエージェントがソフトウェア開発の周辺的なツールから、日常的な作業を担う存在へと変わり始めていることだ。年間179億回のプッシュ、PRの40%超を占めるエージェント起点の変更、複数モデルの利用拡大は、その変化を具体的に示している。一方、コード生成の急増は、レビューやセキュリティ検証、インフラの処理能力に新たな負担をもたらしている。今後の開発組織には、AIエージェントを導入するだけでなく、大量の変更を安全に検証する体制を整え、複数モデルの利用コストを管理し、開発基盤の障害にも対応できる運用設計が求められる。