1. JustFit
  2. ブログ
  3. GitHub Octoverse、PRの4割超がAI起点に

GitHub Octoverse、PRの4割超がAI起点に

JustFit編集部（運営：株式会社LEGAREA）

GitHubが年次報告「Octoverse 2026」を公開し、2026年9月のプルリクエストの4割超がAIエージェントの下書きから始まったと報告しました。プルリクエストとは、コードの変更を確認して取り込んでもらうための依頼のことです。この記事では、公表された数字と同じ日のカンファレンスでの発表を確認し、数字の読み方と、新規事業のシステム開発で見直したい点を整理します。

9月のプルリクエストの4割超が、AIの下書きから始まった

Octoverseは、GitHubが毎年まとめている開発活動の報告です。対象期間は2025年10月1日から2026年9月30日までです。

報道によると、2026年9月にGitHubで作られたプルリクエストの4割超は、AIエージェントが作った下書きから始まり、3月の17%から増えました。9月だけでエージェントが起点のプルリクエストは1億1,000万件で、3月の約6倍です。

GitHub自身のブログには、全体の伸びも示されています。2025年9月から2026年9月にかけて、コミットは6倍、Actionsのジョブは約4.8倍、プッシュは約4.5倍、マージされたプルリクエストは約3.9倍になったとのことです。6月以降は、全コミットの約55%が新しく作られたリポジトリから生まれています。

エージェント起点のプルリクエストの特徴

報道では、次のような傾向も紹介されています。

  • エージェント起点のプルリクエストは、複数のファイルに触れる割合が約87%で、そうでないものの79%を上回る
  • エージェントが関わったプルリクエストが2週間以内にマージされた割合は、2月の83%から9月は90%に上がり、エージェントの関与が検出されなかったものの86%を上回った

言語による差もあります。AIが関わったマージ済みプルリクエストの割合は、TypeScriptで44.1%、Pythonで41.1%、Rustで40.4%、Javaで21.2%と紹介されています。GitHubは、エージェントと働く開発者は、出力を確かめやすい言語に集まる傾向があるとみています。

同じ日のUniverseで、Copilotの担当範囲が広がった

Octoverseと同じ10月28日（米国時間）のGitHub Universe 2026では、Copilot関連の発表が続きました。

GitHub Copilot appは、エージェントによるソフトウェア開発のために作られたアプリで、コードだけでなく、仕様の作成、設計の議論、テレメトリー（利用状況のデータ）の分析も一つの画面で扱えます。Copilot projectsは、複数のリポジトリにまたがるエージェントの作業を、管理された並列のセッションで動かす機能です。セッションをGitHubアプリ、VS Code、CLI、Webのどこからでも追うことができ、エージェントはクラウドで作業を続けます。

Copilot Fusion：モデルの選択を、ツール側に任せる

もう一つがCopilot Fusionです。一般提供が始まり、タスクごとにモデルを選ぶ代わりにFusionを選ぶと、使うモデルをCopilotが振り分けて組み合わせます。利用者が選ぶのは、作業の深さ（努力レベル）です。日常的なコーディング向けのStandardと、難しい作業や深い推論向けのHighがあります。

管理面の仕組みもあります。Fusionは、企業や組織のモデルポリシーで有効になっているモデルだけを使い、管理者はFusion用にだけ特定のモデルを無効にできます。対象はすべてのCopilotプランで、VS Code、Copilot app、CLI、JetBrainsです。

性能についてGitHubは、Fusion MaxがArtificial Analysisのコーディングエージェント指標で60点となり、Opus 5.5 Maxを使うClaude Codeに2点差まで迫り、タスクあたりのAPI費用は約半分だったと報告しています。これはGitHubが示した数字です。作業内容によって結果が変わる可能性があるため、実際の開発で試して確かめるのが確実です。

「4割」が示していることと、示していないこと

数字を読むときは、次の点を押さえておくと誤解が減ります。

まず、数えているのは「プルリクエストの起点」です。コードの4割をAIが書いたという意味ではありません。この数字はGitHubによるエージェント活動の検出に基づいており、対象は報告期間のうち特定の月です。

次に、増えた理由は特定されていません。GitHubは、6月ごろから、モデルの改善、エージェント向けの道具や手順の広がり、クラウド実行の普及を背景に活動が増えたとしつつ、特定の要因には結びつけていません。

最後に、品質は測っていません。Octoverseの数字はプラットフォーム上の活動を数えたもので、生まれたソフトウェアの質や有用性を評価したものではありません。コミットやプルリクエストが増えたことと、事業として価値のあるものができたことは、別の話です。

編集部の見方：新規事業の開発で、人の仕事は「下書きの後」に集まる

ここからは、公表された事実ではなく、JustFit編集部としての見方です。

見方1：何を作らせるかを言葉にする力が、開発の入口になる

GitHubのブログは、プルリクエストを、作りたいことを指定し、それを実行するエージェントをまとめるところから始める開発者が増えていると書いています。

下書きをAIが作る前提に近づくほど、最初の指示の質が成果物を左右すると私たちは考えます。新規事業では、仕様がまだ固まっていない段階から動き出すことも多くあります。そのため、作りたいものをどう言葉にするかが大切です。整理の手順はAI開発の仕様の伝え方にまとめています。

見方2：増えるのは、確認する変更

エージェントが起点のプルリクエストは、複数のファイルに及ぶ傾向があるとされています。変更が早く増えるほど、確認する側の負担は大きくなります。報告の数字は活動量であり、品質ではない点も先に触れた通りです。

新規事業のシステムでは、動くかどうかだけでなく、事業の約束ごとに沿っているか、安全か、後から直せるかを見る必要があります。私たちは、AIが下書きを担う場合も、最終的な判断は人が持つ前提で進めるのが自然だと考えます。確認の観点は、AI生成コードのセキュリティやAI生成コードの保守でも整理しています。

見方3：モデルの選択が、道具の中に入っていく

Fusionのように、モデルの選択を道具側が担う流れが強まると、開発側が決めることは「どのモデルを使うか」から、「どこまで任せ、どう管理するか」へ移っていきます。管理者が使えるモデルを絞れる仕組みは、その一例です。

ただし、中でどのモデルが動くかは利用者が細かく選べなくなる場合があります。外部のAIに依存する部分が増えるため、品質の確認方法と、道具を替えても困らない作り方を先に考えておくと安心です。道具ごとの特徴は、AIコーディングツール比較で整理しています。

まとめ

今回のニュースで確認できた事実は、次の3点です。

  • 2026年9月のGitHubのプルリクエストの4割超は、AIエージェントの下書きから始まった（3月は17%）
  • 同じ日のUniverseで、Copilot app、複数リポジトリを扱うprojects、モデルを振り分けるFusionが発表された
  • 数字は活動量の記録で、品質や事業の成果を示すものではない

下書きを作る速さが上がるほど、何を作るか、どこまで確かめるかを決める役割の比重が増えると私たちは見ています。作る量が増えても、新規事業で本当に確かめたいのは、事業の仮説が成り立つかどうかです。

私たちJustFitは、「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを先に開発します。開発基盤のLAFでは、何を作るかを決めることと品質の最終判断を人の役割としています。新規事業のアイデアをシステムの形にしたいときは、JustFitのサービス紹介をご覧ください。

参考にした情報

← ブログ一覧へ