AIコーディングエージェントはコミットを最大240%増加させるが、リリースはわずか30%しか増えない

ニュース概要

2026年に発表された2つの独立した研究は、同じ結論を指し示している。AIコーディングエージェントは開発者がはるかに多くのコードを生成できるようにするが、その追加出力は、比例した完成・出荷・広く使用されるソフトウェアにはつながっていない。2026年10月10日付のArs Technicaの報道は、ハーバード大学主導のソフトウェア企業に関する研究を強調しており、別の全米経済研究所（NBER）のワーキングペーパーも、GitHubデータを用いて驚くほど類似した状況を明らかにしている。

ハーバード大学の研究：コードは増えるが、成果は変わらない

ハーバード大学の研究者であるFiona Chen氏とJames Stratton氏は、エンジニアリングチームの成果を測定するプラットフォームであるJellyfishの集計データを分析した。このデータセットには、コミットやプルリクエストなどの約3億件の作業イベントに加え、700以上のソフトウェア企業の70万人以上の従業員に関する課題追跡データが含まれている。期間は2021年から2026年3月までである。

各企業がいつAIツールを導入したかを特定するため、チームは直接測定されたAI使用状況とGitHubアクティビティの分析を組み合わせた。彼らは2つのカテゴリを区別した。人間が主に書くコードを自動補完するAIコーディングアシスタントと、プロンプトから自律的にコードを記述・提出するAIコーディングエージェントである。その後、彼らは差の差回帰分析を用いて、異なる時期に導入した企業間で、導入前後の成果を比較した。

コーディングエージェント導入後に変化したこと

コーディングエージェント導入後の企業レベルの平均的な結果は以下の通りである。

• 生成されたコードの総行数は約30%増加した。
• 総コミット数は約20%増加した。
• プルリクエストは約23%増加した。
• Jiraなどのツールで追跡される課題とエピックの解決率は、統計的に有意な変化を示さなかった。
• 追跡される課題の規模や複雑さに検出可能な変化はなく、チームが単により小さく簡単な作業を引き受けたと主張することは難しくなっている。

追加コードの行き先：レビューのボトルネック

報道によると、追加の出力は下流で吸収された。コードレビューにはより長い時間がかかり、プルリクエストは修正が必要になる可能性が高く、レビュアーはより多くのコメントを残した。著者らは、これらのツールの使用により、企業が全体的なソフトウェア出力を増やしたり、雇用を減らしたりしたという証拠はほとんど見つからなかった。開発者は一般的に、AIが生成したコードは注意深くチェックする必要があることを認識しているため、それを検証するために必要な人的労力は多大である。

NBERからの別の見解

Mert Demirer氏、Leon Musolff氏、Liyuan Yang氏によるNBERワーキングペーパー「Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools」（ワーキングペーパー35275）は、同じ問題を別の角度から考察している。このペーパーは2026年5月に発行され、2026年9月に改訂された。50万人以上のGitHub開発者に関するデータとAI使用テレメトリを使用し、マッチングしたイベントスタディデザインを適用している。

著者らは、各世代のツールがコミットを大幅に増加させたことを見出した。累積効果は、自動補完で約30%、対話型コーディングエージェントで180%、自律型コーディングエージェントで240%であった。ただし、その効果は生産チェーンに沿って縮小する。自律型エージェントの場合、240%のコミット効果は、プロジェクトでは約80%、リリースでは約30%に低下する。4つの主要なソフトウェアマーケットプレイスでは、新しいアプリの数は急増するが、総使用量は増加しない。

このペーパーの初期バージョンは、一部の二次報道で、より少ない開発者サンプルと180%の見出しとなるコミット数で要約されていたことに注意されたい。上記の数値は、NBERのページに記載されている最新の改訂版を反映している。

弱点連鎖の説明

NBERの著者らは、このパターンを「弱点連鎖」のレンズを通して解釈している。そこでは、最も遅い人間依存のステップがパイプライン全体を制限する。彼らは、AIと人間の労力の間の代替弾力性を0.23と推定しており、これは強い補完性を示している。つまり、レビュー、統合、リリースが依然として人間に依存している場合、プロセスの一部を高速化してもほとんど役に立たない。これは、より多くのコードが到着するとレビュー時間が長くなるというハーバード大学の調査結果と一致する。

より広い文脈と注意点

2026年の他の解説は、リリースプロセスが追いつかない限り、より速いプルリクエストがバグ、レビュー時間、保守負荷を増加させるという「生産性パラドックス」を説明している。企業がエージェントを使用してコードを30%速く出荷するなど、ベンダーが報告するいくつかの数値が流通しているが、これらはベンダーの資料からのものであり、独立して検証することはできなかった。研究グループMETRによる2025年のランダム化試験では、複雑で成熟したコードベースに取り組む経験豊富な開発者は、AIツールを使用すると約19%遅くなることが判明しており、この結果はこれらの新しい研究とともによく引用される。

読者はまた、両方の研究が多くのチームにわたる平均を測定していることも心に留めておくべきである。強力な自動テスト、明確な仕様、迅速なレビュープラクティスを備えた個々のチームは、異なる結果を見る可能性があり、ツール自体も急速に変化し続けている。

学習者とチームにとっての意味

学生や現役の開発者にとっての教訓は、コードを書くことはソフトウェアを構築する上での1つの段階に過ぎないということだ。コードを読む、テストを書く、変更をレビューする、システムを設計するスキルは、コード生成が安価になるにつれて、より価値が高まる。エンジニアリングチームにとって、これらの研究は、コード行数やコミット数だけで成功を測定するのではなく、レビューツール、自動テスト、リリースパイプラインへの投資を示唆している。