GitHub Octoverse 2026：活動急増の中、エージェントがプルリクエストの40％超を起案
GitHubは10月28日、Octoverse 2026レポートを公開し、9月のプルリクエストの40％超でエージェントが最初のドラフトを作成したと報告した。プルリクエストは、変更をプロジェクトに取り込む前にレビューを依頼するためのコード変更提案である。この結果は、自動化されたドラフト作成がソフトウェア開発の中核ワークフローに入り込んだことを示す一方、生産性と品質は別個の論点として残している。
GitHub Octoverse 2026は、同プラットフォーム全体で記録的な活動も報告している。このため、変更を生み出すことと、有用なソフトウェアを提供することの違いは、より重要になる。AIモデルを用いて開発タスクを実行するソフトウェアであるAIコーディングエージェントは、なお相当な人間の判断を必要とする作業を生成し得る。
エンジニアリングリーダーにとって中心的な緊張関係は、コード生産量の増加と、それを評価する能力との間にある。METRによる先行研究は、これらの指標を分けて扱うべき理由を示している。一方で、GitHubがAnthropicとOpenAIのエージェントをサポートすることで、競合するプロバイダーは同一のレビュー環境に置かれる。実務上の問いは、プロセス全体を通じてどれだけ有用な成果が残るかだ。
GitHub Octoverse 2026が記録した、変更が始まる方法の転換
GitHubのOctoverse findingsによると、開発者は報告対象年に179億件のプッシュを行い、13億件のプルリクエストをマージした。プッシュとは、保存したコード変更をGitHubへ送信する操作である。プッシュ総数は過去2年分の合計を上回った。
報告期間は2025年10月1日から2026年9月30日までである。大半の数値には公開・非公開の両方のプロジェクトが含まれる。GitHubは過去の年についても比較可能な定義で再計算しており、これらの数値を従来公開されたレポートと比較する際には重要な留意点となる。
エージェント起案の割合は、3月の17％から9月には40％超へ上昇した。GitHubは、検出可能なエージェント生成の初稿を持つリクエストとしてこれらを定義している。
この導入指標は、提案された変更がどのように始まったかを測るものであり、エージェントが独力で完成させたソフトウェアの量を示すものではない。
この違いは見出しの意味を変える。開発者はタスクを指定し、最初のアプローチを却下し、結果の一部を書き直し、最終承認を下すことができる。成果物を完全に自律的なものと呼べば、こうした貢献は見えなくなる。
分母も同じくらい重要である。プルリクエストの割合を、コード量、作業時間、製品機能の割合に直接換算することはできない。提案される変更は、規模、難易度、重要性がそれぞれ異なる。
ドキュメントの修正と、決済承認に関する変更を考えてみよう。どちらもプルリクエストになり得る。しかし、プラットフォームがそれぞれを1件の提案として記録したとしても、必要なレビューや結果の重大さは大きく異なる。
同様に、提案変更数の増加には複数の要因があり得る。チームがより多くのプロジェクトに取り組んでいる、作業をより小さく分割している、追加の修正を生成している、といった可能性がある。これらは異なる解釈を必要とする。
だからこそ、このレポートはAIコーディングをめぐる議論に付随するあらゆる結論を背負わせることなく、注目に値する。これは観測可能な開発行動における大きな変化を記録している。その行動の経済的価値を確立するには、追加の証拠が必要だ。
したがって、GitHubのエージェント導入を追う読者にとって、有用な出発点は正確な帰属である。これは、同社の定義と検出範囲に基づくGitHubのプラットフォーム計測値だ。AIがすべてのソフトウェア開発にどれだけ貢献しているかについて、独立監査された推計ではない。
それでも、このニュースはその条件において重要である。ドラフト作成は、エンジニアリング作業への意味ある入口だ。エージェントがそこに参加するとき、レビューシステムは、その提案がプロジェクト要件と人間の説明責任に向き合う場となる。
これにより、メンテナー、エンジニアリングマネージャー、セキュリティレビュアーは物語の当事者となる。追加の活動が有用なソフトウェアになるのか、それとも未完了の提案の集積になるのかは、彼らの判断にかかっている。
ドラフトの増加がレビュー能力を圧迫する
エンジニアリングチームは、品質や優先順位の統制を失わずに、生成された変更を評価できる場合に、より高速なドラフト作成から利益を得る。
これは、すべてのチームがすでに過負荷のレビューキューを抱えているという主張ではなく、運用上の議論である。圧力はワークフローに由来する。提案を作ることと、その責任を引き受けることには異なる作業が必要だからだ。
レビュアーは、変更が何を達成する意図なのかを確認しなければならない。次に、その実装が意図と一致しているかを判断する必要がある。自動テストはこの判断を支援できるが、その有用性は実際に何を検証しているかに左右される。
期待される出力を確認するテストでも、顧客行動に関する誤った前提を見落とす可能性がある。変更は割り当てられたタスクを満たしていても、製品の別の部分と衝突することがある。こうした理由から、提案を裏付ける証拠を検討する必要がある。
影響は、提出時点での正しさにとどまらない。誰かが実装を保守し、その判断を説明し、要件変更時に対応しなければならない。追加のコードは、直ちにもたらす価値と並行して義務も生み出す。
エンジニアリングマネージャーにとって、これは能力配分の問題を提起する。ドラフト作成が容易になった場合、チームは新しい提案、既存システムの保守、本番環境の信頼性の間で、注意をどのように配分すべきなのか。こうした優先順位を調整せずに提出数を増やせば、制約を下流へ移すリスクがある。
Google CloudのDORA研究者は、AI development tradeoffsの分析で、関連する緊張関係を説明している。彼らは、作成段階で節約された時間が、監査や検証へ移ることが多いと報告している。その解釈では、AIは既存の組織的な強みと弱みを増幅するものとして扱われている。
この観察は、プラットフォームの数値を読むための有用な枠組みを提供する。要件が明確で、信頼できるチェックを備えたチームは、責任の所在が曖昧なチームとは異なる出発点にある。両者に高速なドラフト作成を与えても、その違いはなくならない。
直接の圧力は、変更を承認し、その結果に責任を持つ人々にかかる。メンテナーは、エージェントの自信を証拠の代替として合理的に扱うことはできない。エンジニアリングマネージャーも、提出数の増加だけから顧客価値を推測することはできない。
セキュリティチームも同様の配分問題に直面する。提案がアクセスルールを変更したり、機密情報を扱ったり、外部コンポーネントを導入したりする場合は、精査が必要になるかもしれない。その出自がリスクを決めるわけではない。
プロダクトチームにも役割がある。実装が容易になるほど、定義の曖昧な要求に取り組みたくなる誘惑は強まる。もっともらしい実装を生成するための労力が減るほど、明確な受け入れ基準の価値は高くなる。
個々の開発者にとって、この含意は単にプロンプトの書き方を学ぶこと以上に具体的だ。価値あるスキルは、求められた変更を、それが機能しプロジェクトに属することを示す証拠へ結び付けることである。
その中には、意思決定の背後にある理由を残すことも含まれる。searchable knowledge baseの構築に取り組むチームは、元の作成者が不在でも技術的な文脈を利用可能に保つという、関連する課題に直面している。
ドキュメントは変更を承認できない。しかし、承認が依拠する制約をレビュアーが理解する助けにはなる。ドラフト作成が加速する中、こうした共有コンテキストは、生成ツールそのものと並んで注意を払うべきである。
Copilot、Claude、Codexが同じワークフロー内で競合する
競争環境は、エージェント導入がなぜワークフローの問題になっているのかを説明する助けとなる。開発者は、チームが変更を議論し承認する場所を離れることなく、異なるプロバイダーに接することができる。
GitHubは2月の発表で、AnthropicのClaudeとOpenAIのCodexを含むpartner coding agentsをパブリックプレビューとして導入した。GitHubから作業を割り当て、これらのエージェントが生成したプルリクエストのドラフトをレビューする方法が説明されていた。
この発表は、報告対象年における製品の方向性を示す。ただし、現在の提供状況やアクセス条件の完全な一覧として読むべきではない。
GitHubにとって、競合するエージェントをホストすることは、自社のコーディングアシスタントと並び、レビューのワークフローを戦略的資産にすることを意味する。
開発者が特定の割り当てで別のプロバイダーを好む場合でも、プラットフォームは中心的な存在であり続けられる。作業には依然として、着地点、履歴、議論、承認プロセスが必要だからだ。
AnthropicとOpenAIにとって、この環境に登場することは、開発作業へ入り込む別の経路を提供する。彼らのエージェントは、チームがすでにソフトウェア変更を管理している場で、割り当てをめぐって競争できる。
この比較は、どのエージェントがより優れた結果を出すかを示すものではない。流通契約や製品発表だけでは、その問いに答えられない。それらが示すのは、プロバイダーがユーザーに到達する方法であり、同等のタスクをどれだけ確実に解決するかではない。
GitHubのエージェント導入を解釈する際、この違いは重要である。エージェント起案の提案が増えたからといって、勝者となるプロバイダーが自動的に特定されるわけではない。ワークフローの導入と、そのワークフロー内での競争は別の進展である。
具体例は2月の発表にある。開発者はエージェントにissueを割り当て、レビュー用のドラフトを受け取ることができた。issueは、求められたタスクや問題を記録する。これにより、委任には認識しやすい開始点と、レビュー可能な成果が与えられる。
重要なのは引き渡しにある。要求は試行された実装になり、人々が変更を調べ、修正を要求できるシステムへ戻る。エージェントは既存の説明責任の構造に参加する。
プロバイダーを評価するチームにとって、この構造は比較をより意味のあるものにするはずだ。重要な問いは、プロバイダーがチームの実際の作業を、許容可能なレビュー負荷で完了できるかどうかである。洗練されたデモンストレーションでは、その結果を立証できない。
反復的な保守タスクでエージェントを比較する場面を考えてみよう。有用な評価では、各提案が要求に対応しているか、プロジェクトの慣例を尊重しているか、信頼できる検証を提示しているかを考慮する。生成されたファイル数を数えることは、別の問いに答えるものだ。
チームへエージェントを統合する際も同様である。ツールへのアクセスは始まりにすぎない。権限、タスクの境界、承認の責任については、依然として明示的な判断が必要となる。
一貫したレビュー環境を維持することには、実務上の利点もある。チームは周辺プロセスをすべて置き換えることなく、新しいプロバイダーを評価できる。これにより、プロバイダー間の違いをワークフロー変更と区別しやすくなる。
したがって競争の物語は、中心的な緊張関係を裏付ける。プロバイダーは、確立されたエンジニアリング環境の中でドラフト作成をより利用しやすくしている。そのアクセスの価値は、チームが競合する提案を、受け入れられ保守可能な変更へどれだけうまく転換できるかにかかっている。
マージの高速化が残す、重要な品質上の問い
GitHubは、9月のエージェント関与リクエストの2週間以内のマージ率が90％に達したと報告している。検出されたエージェント関与のないリクエストでは約86％だった。
マージはプロジェクトへの受け入れを記録するものであり、変更の長期的な信頼性やビジネス価値を立証するものではない。
この制約は、人間による変更にも当てはまる。入手可能な証拠に基づいて承認することは合理的でも、後の挙動によって見落としていた相互作用が明らかになることはあり得る。ソフトウェア品質は時間をかけて形づくられる。
より迅速に受け入れられるようになることは、改善を反映している可能性がある。一方で、提出されたタスク、プロジェクトの慣行、求められる精査の度合いの違いを反映している可能性もある。観察による比較だけでは、こうした説明を自動的に切り分けることはできない。
タスクの選択は特に重要だ。チームは、すでに仕様化と検証の方法を把握している仕事を委任するかもしれない。より曖昧な割り当ては、開発者に残される可能性がある。違いを考慮せずに両者を比較すると、結果を過大評価するおそれがある。
逆の可能性も検討に値する。エージェントによって、これまで見過ごされていた保守作業が現実的になり、チームが取り組む仕事の範囲が広がるかもしれない。公正な評価では、有用な追加アウトプットも考慮すべきだ。
ここで、単純な解釈はどちらの方向でも破綻する。活動量の増加は、すべてのチームの生産性が向上したことの十分な証拠ではない。普遍的な生産性推計が存在しないことも、その活動に価値がないことの十分な証拠ではない。
METRの開発者生産性実験は、測定が重要である理由を示している。2025年初頭に実施された無作為化研究には、慣れ親しんだオープンソースプロジェクトで246件のタスクを完了した、経験豊富な開発者16人が参加した。AIの利用を許可すると、完了時間は19%増加した。
これらの結果は、特定の母集団、タスク環境、ツール世代についてのものである。2026年後半のエージェント性能を直接測定したものとして扱うべきではない。
この研究がここで重要なのは方法論上の理由からだ。開発者がツールを利用しているという観察だけでは、同等の仕事をどれだけ速く完了できるかは分からない。それを判断するには、信頼できる比較が必要となる。
行動が変化すれば、過去の研究も更新が必要になる。ある結果は当初の状況では有効であり続けても、新しいワークフローについては情報量が少なくなる可能性がある。それを時代を超えて通用するものとして扱うことも、別の測定誤差になる。
品質の比較にも、同様に慎重な境界設定が必要だ。提案された変更は既存のチェックを通過しても、将来の保守担当者が引き受けなければならない複雑さを加えることがある。逆に、より大規模な実装が不自然な回避策を取り除き、将来の作業を減らすこともある。
したがってレビュアーには、タスクに結び付いた証拠が必要となる。関連するチェック、理解しやすい根拠、変更された挙動の明確な説明は、由来を示すラベルよりも多くの情報を提供する。
エンタープライズの購入者にとって、これは調達上の課題となる。導入状況のダッシュボードは要約しやすい一方、回避できたインシデントや軽減された保守負荷を立証するには時間がかかる。説得力のある評価では、その違いを認めるべきだ。
適切な結論は具体的である。GitHubの受け入れ数値は、変更が同プラットフォームを通じてどのように進むかについての情報を提供する。一方で、手戻り、信頼性、レビュー負荷、有用なデリバリーについての追加研究の余地も残している。
この隔たりは、測定のための課題である。エージェントが普遍的に有益だとも、その貢献が単なるノイズだとも、どちらかを仮定する必要はない。
作業内容の変化に伴い、エージェント生産性の測定はより難しくなる
測定上の課題は、適切なダッシュボードを選ぶことにとどまらない。エージェントの利用は、開発者が試みるタスクや、注意の配分方法を変える可能性がある。
METRは2026年2月の生産性研究アップデートで、後続の実験は現在のAIによる生産性効果について信頼できる推計を提供していないと述べた。参加者の募集、タスク選定、エージェントの同時利用が解釈を複雑にした。
研究者らは、開発者が以前の推計よりも大きな恩恵を得ている可能性が高いと考えた。同時に、データはその改善の規模について弱い証拠しか示していないことも強調した。
信頼できる評価では、それを実行するツールの変化と併せて、仕事そのものの変化を考慮しなければならない。
これは、固定されたタスクの比較が限定された問いに答えるものだからだ。支援が特定の割り当てにどう影響するかは推計できる。しかし、支援によって人々が選ぶ割り当て自体が変わる場合に何が起きるかを、完全に捉えることはできない。
たとえば、ある開発者が、集中的な労力を要しすぎるため、面倒な移行作業を以前は先送りしていたとする。エージェントによって、ほかに多忙な週でもその作業を実行可能にできるかもしれない。その便益には、未完了のままだった仕事を完了することが含まれる。
次に逆のケースを考えてみよう。下書きが容易になることで、チームはユーザーが本当に必要としていることを確認する前に機能を実装するようになるかもしれない。実装は技術的に成功していても、本来なら別の場所に向けるべき注意を消費している可能性がある。
これらの例は、Octoverseデータセットから報告された結果ではなく、分析上の可能性である。有用なデリバリーには、意図と結果とのつながりが必要である理由を説明している。
並行作業は、さらに別の複雑さをもたらす。開発者が提案をレビューしている間に、エージェントが別のタスクに取り組んでいることがある。エージェントの経過実行時間を人間の作業時間として測定すれば、この体制を誤って表現することになる。
しかし、監督を無視しても結果は歪む。タスク準備、中断、却下されたアプローチ、最終レビューは、いずれもワークフローの評価に含まれる。会計上の境界が結論に影響する。
組織にとっては、これは複数の補完的な証拠形式を重視することを意味する。同等のタスク評価では完了に必要な労力を検討できる。運用記録では受け入れと手戻りを示せる。プロダクトの成果では、提供された変更がユーザーに役立ったかを確かめられる。
単一の指標ですべてを捉えることはできない。だからこそ、異質な結果を普遍的な生産性スコアに集約するのではなく、その指標が何を表すのかを明示すべきである。
あるチームは、保守に苦しみながらもデリバリー速度を改善するかもしれない。別のチームは、承認が別の場所で制約されたままであるため、リリース頻度を上げずに反復作業を減らすかもしれない。どちらも実際の経験に即した説明に値する。
同じ規律はチーム比較にも当てはまる。厳格な信頼性要件を持つ成熟したサービスは、新しい実験的プロジェクトとは異なる。提出数を開発者の有効性ランキングにしてはならない。
GitHub Octoverse 2026は、変化する開発環境の証拠として有用だ。そのより広い意味合いは、プラットフォーム上の活動をタスクレベルの研究や組織的成果と併せて検討することで、より明確になる。
開発者にとって実際的な関心は、仕事が完了しやすくなり、保守しやすくなるかどうかだ。管理者にとっては、その利得がチーム全体で維持されるかどうかである。下書き作成が一般的になっても、どちらの問いもなくならない。
レビュー負荷、信頼性、比較可能なタスク結果を注視する
次に有用な証拠は、エージェントの関与と、提案が現れた後に起こることを結び付けるべきだ。今後数か月、読者は下書き作成とデリバリーの関係を明確にする変化に注目すべきである。
最も強力な追跡証拠は、エージェント由来の作業をレビュー負荷、本番環境での成果、信頼できるタスク比較と結び付けるものになる。
最初のシグナルは、レビュー負荷に関するより良い報告だ。プラットフォームベンダーとエンジニアリングチームは、受け入れられたエージェント提案にどれほどの人間の注意が必要かを示すべきである。待機時間だけでは、それを立証できない。
あるリクエストは、レビュアーの労力をほとんど消費せずにキューで待つことがある。別のリクエストは、集中的な議論を必要としながら迅速に進むこともある。こうした状況を区別できれば、受け入れ統計はより有益になる。
比較可能な作業においてレビュー負荷が低下している証拠は、エージェントがワークフロー全体を改善するという主張を強める。負荷が増加していれば、下書き作成での節約の一部が監督に移っていることを示唆する。
読者は、チームが却下された作業をどのように計上しているかも確認すべきだ。成功したマージだけに焦点を当てたダッシュボードは、受け入れに至らない提案の評価に費やされた労力を省いてしまうことがある。そうした試みも評価に含めるべきである。
第二のシグナルは、受け入れ後の信頼性だ。マージ後も変更を追跡し、修正、差し戻し、インシデント対応が必要になったかを調べる評価に注目しよう。
差し戻しとは、以前の変更を削除または取り消すことだ。その意味は文脈に依存する。プロダクトの判断は、コード品質とは無関係な理由で変わることがあるためだ。有用な報告には、こうした説明を区別できるだけの詳細が必要である。
より迅速なデリバリーと並行して信頼性が安定していれば、純粋な利得という主張は強まる。追加の修復作業が増えれば、その主張には条件が付く。関連する比較では、タスクのリスクとプロジェクトの成熟度を考慮すべきだ。
これは、組織全体への展開を評価する購入者にとって特に重要である。範囲が限定された保守作業での成功したパイロットは、機微なシステムへの準備が整っていることを自動的には証明しない。拡大では、新しい対象範囲に関する証拠を生み出すべきである。
第三のシグナルは、現在のツールを用いて同等の作業を比較する更新された研究だ。研究は、タスク選定、同時に稼働するエージェント、生成を取り巻く人間の労力をどのように扱うかを説明すべきである。
信頼できる評価全体で一貫した改善が見られれば、生産性向上の主張は強まる。結果が混在すれば、便益が割り当て、開発者、組織に依存することを示唆する。どちらの結果も、普遍的な主張より有用である。
研究者は境界も可視化すべきだ。タスクレベルの結果、チームのデリバリー結果、開発者満足度の結果は、いずれも有効であり得る。それぞれが体験の異なる側面を説明している。
GitHub Octoverse 2026を評価する読者は、新たな発表が届いても中心的な区別を見失わないようにしよう。エージェントがどの仕事を始め、誰がそれを評価し、承認後に何が起こるのかを問うべきだ。組織が、導入状況と併せてレビュー負荷と信頼性に関する証拠を公表するかを追跡しよう。ツールを比較する際は、監督を計上に含め、自分の仕事に似たタスクから得られた結果を探そう。将来のレビュアーが目的を理解できるよう、重要な変更の背景を残そう。レポートはエージェントの関与を見過ごしにくいものにしている。次の判断は、その関与が完了を支援する仕事に基づくべきだ。チームがより少ない総労力で、より有用なソフトウェアを提供していることを示す証拠とは何だろうか。
