AIコーディングエージェントはコードを増やすが、ソフトウェアは増やさない

AIコーディングアシスタントやエージェントがコードを速く書けるなら、ソフトウェアの産出量もそれに比例して増え、企業は技術者を減らせるはずだ。これまで業界では、そうした素朴な推論が広く共有されてきた。Ars Technicaが伝えた新しい研究は、この前提に正面から疑問を投げかけている。ハーバード大学の研究者Fiona ChenとJames Strattonは、数百社の実際の開発データを分析し、これらのツールを導入した企業がソフトウェアの産出を増やした、あるいは雇用を減らしたという証拠はほとんど見つからないと結論づけた。コードは確かに増えた。しかし、出荷されるソフトウェアは増えていないのである。

この研究のデータ基盤は大規模である。分析には、エンジニアリングチームの細かな成果を計測するJellyfishが集計したデータが使われた。コミットやプルリクエストといった約3億件の「作業イベント」と、課題管理ソフトウェアの記録を含み、2021年から2026年3月までの期間に、700社を超えるソフトウェア開発企業、70万人以上の従業員を対象としている。各社がいつAIを導入したかは、直接測定したAI利用状況とGitHub上の活動の分析を組み合わせて判定された。さらに、人間が主に書くコードを補完するAIコーディングアシスタントと、プロンプトに基づいて自律的にコードを書き提出するAIコーディングエージェントを区別している。そのうえで、導入前後における主要な変数を「差の差」回帰で比較した。この設計は、時間的な全体傾向や企業間の固有の差を、ツールそのものの効果から切り分けられる点に意義がある。単純に利用者と非利用者を比べるより、因果に近い読み方ができる。

とりわけ重要なのは、著者らによる原因の説明である。コーディング段階で得られた効率化は、生産工程の下流にある制約に吸収されるという。その最大の制約が、人間によるコードレビューだ。AI導入後は、レビューにかかる時間が大幅に長くなり、プルリクエストが修正を求められる確率が上がり、レビュアーが残すコメントも増えていた。これは現場のプログラマーの実感と一致する。AIが出力するコードは、一見もっともらしく、実際に動くことも多い。しかし、誰も確認なしにそれを信頼することはできない。その結果、正しさを確かめるコストが、書き手からレビュアーへと移る。工程の一部だけが加速し、隣の工程が変わらなければ、全体のスループットは最も遅い工程で決まる。制約理論の古い教えそのものであり、違いは、ボトルネックが「書く」から「読む」へ移ったことだけである。

この知見は、業界にいくつかの示唆を与える。第一に、生成された行数、コミット数、ツールの導入率といった指標は誤解を招きやすい。これらはツールが増幅する側の指標であり、実際の出荷が変わらなくても見栄えがよくなってしまう。第二に、生産性の恩恵を現実のものにしたい企業は、より強力な生成ツールを買うだけでは足りない。自動テストや静的解析、守るべき規約、そして生成だけでなく検証を支援するエージェントなど、レビュー段階への投資が必要になる。第三に、AIによって開発チームを縮小できるという語りは、このデータでは裏付けられていない。調査期間内に、雇用が明確に減少した形跡はなかった。ただし、これはAIに価値がないという意味ではない。研究が示したのは、企業レベルの産出と人員の指標に目立った変化がないという点であり、個々の作業が速くならないという主張ではない。

もちろん、この研究にも限界がある。データは2026年3月までで、モデルの能力、エージェントの設計、チームの作業手順は急速に変化している。レビューのボトルネックが恒久的だとは限らない。将来のエージェントが、より小さく検証しやすい変更を出力したり、レビュアーがすばやく確認できるテストや根拠を添えたりすれば、レビューのコストは下がり得る。また、ソフトウェアの産出そのものが測りにくく、コミットやプルリクエストは利用者に届けた価値の代理指標にすぎない。それでも、示されたメッセージは明確である。エージェントの時代に希少なのは、もはやコードを書く力ではなく、許容できるコストでコードの正しさを確かめる力だ。検証をより速く、より確実にできるチームとツールこそが、「より多くのコード」を「より多くのソフトウェア」に変えるだろう。