AIコーディングエージェントを入れれば、開発はそのぶん速くなる。そう考えて導入を進めている組織は少なくないはずです。ところが、コードの量が増えても、チームが仕上げる仕事の数は増えていないという調査結果が出てきました。速く書けるのに、なぜ速く終わらないのか。この記事では、その原因として浮かび上がった「コードレビュー」の問題を掘り下げます。
1. 書く量は増えたのに、終わる仕事は増えていない
ハーバード大学が700社以上を対象に行った調査で、AIコーディングエージェントを導入した組織の変化が示されました。生成されるコードの量はおよそ30%、プルリクエストの数はおよそ23%増えています。プルリクエストとは、書いた変更をチームに取り込んでもらうための申請のことです。
一方で、課題の完了数には有意な増加が見られませんでした。手を動かす量は確かに増えたのに、ゴールにたどり着く件数は変わっていないわけです。
原因として指摘されているのが、人間によるコードレビューの処理能力です。AIが大量に書いたコードを、人が一つずつ確認する工程が追いつかず、そこで仕事が滞っている。この負担は「レビュー税」とも呼ばれ、開発者の間で議論になっています。
数字だけ見ると開発が3割速くなったように感じますが、実際は「書く」工程だけが速くなり、全体の速度は一番遅い工程に縛られたままだと考えられます。
2. ボトルネックはなぜ「書く」から「読む」へ移ったのか
ソフトウェア開発は、書く、読んで確かめる、取り込む、動かす、という工程の連なりです。全体の速さを決めるのは、最も遅い工程です。工場の生産ラインと同じで、一つの機械だけ速くしても、次の機械の前に仕掛品が積み上がるだけになります。
以前は、この中で最も時間がかかるのが「書く」工程でした。人がキーボードを打つ速さには限界があり、レビューする側はそれに合わせて回っていました。書く量と読む量の釣り合いが、自然に取れていたわけです。
AIエージェントはこの釣り合いを崩しました。書く工程が一気に速くなった結果、読む工程が新しい最も遅い工程になったのです。しかもコードは、書くより読むほうが重い作業になりがちです。他人が書いたコードの意図を読み取り、想定外の動きがないかを確かめるには、自分で書くとき以上の集中力が要ります。
AIが書いたコードは、見た目が整っていても前提の理解がずれていることがあります。レビューする人は「書いた人に聞けば分かる」という近道を使いにくく、読む負担はさらに増えるのではないかと思います。
ここで怖いのは、レビュー待ちの山を前にして確認が甘くなることです。急いで承認されたコードが積み重なれば、品質の低下やセキュリティ上の穴につながります。レビュー税は時間の問題であると同時に、安全の問題でもあるわけです。
3. レビュー体制の比較
AIが書くコードが増えた現場で取りうるレビューの形を、特徴ごとに整理しました。
| 項目 | 人だけでレビュー | AIのレビュー支援を併用 | 変更を小さく分けて運用 |
|---|---|---|---|
| 処理できる量 | 人の時間に比例 | 一次チェック分は増える | 1件あたりが軽くなる |
| 見落としへの強さ | 担当者の集中力しだい | 形式的な誤りに強い | 差分が小さく追いやすい |
| 設計意図の確認 | 得意 | 苦手な場面がある | 説明を添えれば得意 |
| 導入の手間 | 小さい | 中程度 | 開発の進め方の見直しが必要 |
| レビュー税への効果 | 小さい | 中程度 | 中程度 |
どれか一つで解決するというより、組み合わせて使うものだと考えられます。AIに機械的なチェックを任せ、人は設計や意図の確認に時間を使う。そのうえで、一度に出す変更を小さく保つ。この三つをそろえて、ようやく書く速さに読む速さが近づくはずです。
正直なところ、AIがAIのコードを確かめる構図には少し引っかかりもあります。書いた側と確かめる側が同じ癖を持っていれば、同じ見落としを重ねるおそれがあるからです。最後の判断を人が持つ形は、当面崩さないほうがよさそうです。
4. シュナちゃんのコーナー🐾
- Q. AIでコードが増えたのに、どうして仕事が早く終わらないワン？
A. 書くのが速くなっても、人がチェックする工程が追いつかないからなんだワン。ハーバード大学の調査でも、コード量は約30%増えたのに、課題の完了数は増えていなかったんだワン。 - Q. じゃあ、AIを使うのはやめたほうがいいの？
A. そうじゃないんだワン！ 書くのが速くなった分、確かめ方も一緒に変えるのが大事なんだワン。僕なら、変更を小さく分けて、見る人が疲れない工夫から始めたいワン。
5. AI時代の開発チームが見直したいこと
手をつけやすいのは、成果の測り方です。書いたコードの行数やプルリクエストの件数は、AIを入れれば簡単に増えます。それを成果と見なすと、レビューの山を増やすほど評価が上がるという、ちぐはぐな状態になりかねません。完了した課題や、利用者に届いた価値で測るほうが実態に近づきます。
もう一つは、レビューを担う人の時間を、最初から計画に入れることです。AIで書く量が増えるなら、読む時間も同じだけ必要になります。レビューを「空いた時間にやる仕事」のままにしておくと、どこかで必ず詰まります。
あくまで想像ですが、これからのエンジニアは「書く人」より「確かめる人」としての役割が大きくなっていくのかもしれません。AIの出したコードを正しく評価し、取り込むかどうかを判断する力が、腕の見せどころになりそうです。AIで速く書くことと、速く届けることは別物です。その差を埋める仕組みを持つチームが、エージェントの恩恵を本当に受け取れるのだと思います。
編集後記
バイブコーディングを使えば、開発や仕事は楽に速く終わるものだと思っていたので、意外でした。とはいえ、AIを活用してより高品質な仕事や開発ができるなら、人の確認作業も手間だとは感じません。AIの進化に伴って、これからは書く力よりも読む力が必要になるのかもしれません。
