AI coding agents が開発現場に入ると、コードはたしかに増える。だが、出来上がるソフトウェアの量まで増えるとは限らない。Ars Technica が取り上げた最新の研究は、そのズレをかなりはっきり示している。AI が生む効率は、結局のところ人間の review に吸い取られてしまうのではないか、という話だ。派手なデモや「開発が何倍速くなる」といった宣伝に慣れた目から見ると、かなり冷ややかな結果に見える。
記事が紹介しているのは、Harvard University の Fiona Chen と James Stratton による研究だ。ふたりは Jellyfish の集約分析データを使い、実際のソフトウェア開発現場で AI coding tools が何を変えたのかを追った。対象になったのは、2021年から2026年3月までのデータで、700社超、70万人超の従業員にまたがる情報だという。データの中身もかなり広く、300 million 件の individual work events、たとえば commit や pull request に加え、issue 管理ソフトの記録も含まれている。
研究では、AI coding assistants と AI coding agents を分けて扱っている。前者は人間が主に書いた code を補完するタイプ、後者は prompt をもとに code を自律的に書いて submit するタイプだ。研究チームは、各社がいつどちらを導入したかを、実測の AI 利用データと GitHub 活動の分析から推定し、その前後で開発指標がどう変わったかを difference of differences の regression で比べた。
結果は、まず code の量については明快だった。AI coding agents を導入した企業では、total lines of code が平均で 30% 増え、total commits は 20% 増え、pull requests は 23% 増えた。一方で、ソフトウェア成果そのものは同じようには伸びていない。Jira で追跡される Issue や Epic、つまり機能単位の仕事の解決率は、AI 導入後も統計的に有意な変化がなかった。しかも、Issue の大きさや複雑さが AI 導入後に変わった形跡も見られなかったという。
この差を生んでいるのが code review だ。AI agents 導入後、pull request が submit されてから merge されるまでの平均 review process time は 49% 伸びた。さらに、changes requested が付く pull request の割合はほぼ倍になり、pull request あたりの comments も 35% 増えた。開発者側も対応せざるを得ず、code review を担当する workers の割合は 14% 増加した。ただし、Jellyfish の全体データと LinkedIn 情報を突き合わせても、AI の導入による雇用全体の有意な変化は確認できなかったという。
AI が review まで肩代わりできれば話は違うが、現時点ではそこも限定的だ。2026年3月時点で 80% の測定対象企業が何らかの AI code review を使っていたものの、AI agents が担っていたのは review comments 全体の 23.3% にとどまり、pull requests の 10.8% にしか関わっていなかった。つまり、review の主役はまだ人間だ。記事は、AI coding agents が開発を速くするどころか、下流の review に詰まりが移っただけではないか、という研究の見方を伝えている。
この研究でいちばん引っかかるのは、AI の効率化が否定されたのではなく、別の場所で相殺されている点だと思う。コードを書く工程だけを見ると、AI agents はたしかに強い。だが、実際の開発は code を吐き出して終わりではなく、設計の妥当性、テスト、レビュー、修正、マージという連鎖で動く。そこで人間がボトルネックになれば、全体の throughput は伸びない。研究結果はその当たり前を、かなり大きなデータで裏づけている。
むしろ重要なのは、AI が作る code の“量”がそのまま価値にならないことだ。commit や pull request が増えるのは、見た目には生産性が上がったように見える。でも、Issue の解決率が動かないなら、企業が本当に欲しい成果、つまり機能の完成や改善は増えていない。ここで起きているのは、開発の前工程だけが膨らみ、後工程が詰まっている状態だと思う。工場で言えば、ベルトコンベアの入口だけ速くしたようなものだ。
この話は「AI が雑だからレビューが増えた」という単純な説明で片づけるべきではないと思う。たしかに pull request あたりの comments は 35% 増え、changes requested もほぼ倍になった。だが、review が増える理由は、品質が落ちたからだけではないはずだ。AI が生成した code は量が多く、変更範囲も広がりがちで、しかも文脈の理解が浅いまま差し込まれることがある。人間の reviewer は、動くかどうかだけでなく、既存の設計と合うか、保守できるか、将来の変更を壊さないかまで見なくてはいけない。そこを機械に任せ切れない以上、確認コストは残る。
この点で面白いのは、AI code review の導入も進んでいるのに、主導権はまだ人間にあることだ。2026年3月時点で 80% の企業が何らかの AI code review を使っていても、AI が担う review comments は全体の 23.3% にすぎない。つまり、AI は review をゼロにするのではなく、review の一部を補助する段階にいる。現場感覚としても納得しやすい。機械に一次チェックを任せるのは便利だが、最終責任を置き換えるにはまだ足りない、ということだろう。
それでも多くの企業が AI coding agents を入れ続けるのは、局所最適としては魅力があるからだと思う。個々の開発者にとっては、下書きや定型実装を AI に任せて手元の仕事が早く終わる場面はある。マネージャーから見ても、短期的にはコードの流量が増えたように見える。だから導入は進む。実際、研究では 95% の企業がすでに AI coding agents を実装しているという。ここまでは、流れとして自然だ。
ただ、組織全体で見たときに問題になるのは、誰がその増えた流量をさばくのかだ。review が増えれば、結局は senior engineer や tech lead に負荷が集まりやすい。AI が若手の手作業を減らしても、経験のある人の判断を減らせるわけではない。むしろ、AI が生んだ雑多な差分を人間が吸収する構図になりやすい。そうなると、企業は「開発者を増やした」のではなく「確認作業を増やした」だけかもしれない。研究が雇用の有意な変化を見つけなかったのも、そのあたりの実感とつながっている気がする。
この研究が突きつけているのは、AI 開発ツールを評価するなら、生成量ではなくスループットで見ろ、ということだと思う。何行書けたか、何件 commit したかは分かりやすいが、それだけでは企業価値に結びつかない。むしろ、review time、rework の回数、Issue の解決率、バグ混入率のような指標を合わせて見ないと、本当に得をしているのか判断できない。
そして、AI ベンダーの説明もここで変わるべきだろう。これまでの宣伝は「コードを書くのが速くなる」に寄りすぎていた。しかし現実の開発は、書く速度より、理解して直し、承認する速度のほうが律速になりやすい。もし本当に AI が価値を出すなら、生成だけでなく review、テスト、差分の要約、仕様との整合性確認まで含めて、人間の判断を軽くしなければならない。そうでなければ、現場には code だけが増えて、ソフトウェアは増えないまま残るのではないかと思う。
参考: AI coding agents generate more code, but not more software
