ハクソク

世界を動かす技術を、日本語で。

AIコーディングエージェントはより多くのコードを生成するが、より多くのソフトウェアは生み出さない

2026年10月13日原文(arstechnica.com)

概要

AIコーディングエージェント導入後、コードレビューにかかる平均時間が大幅に増加 プルリクエストの修正依頼やコメント数も増加傾向 AIによるレビュー支援は限定的な効果にとどまる 従業員数には大きな変化が見られない AI導入のコストと効果のバランスに疑問が残る現状

AIコーディングエージェント導入後のコードレビュー遅延

  • AIコーディングエージェント 導入後、プルリクエスト提出からマージまでの 平均レビュー時間 が49%増加
  • プルリクエストに対する 修正依頼率がほぼ2倍、コメント数が 35%増加
  • レビュー担当者の割合 も14%増加
  • JellyfishやLinkedInデータ の分析では、AI導入後も 従業員数に大きな変化はなし
  • 「エージェンティックコーディング」時代 では、プルリクエストの修正頻度が顕著に増加

AIによるコードレビュー支援の現状

  • 2026年3月時点で 80%の企業がAIコードレビューを導入
  • しかし、AIが担当した レビューコメントは23.3%、 プルリクエストは10.8% にとどまる
  • 人間によるレビュー が依然として大多数を占める状況
  • AIエージェントはまだ 新しい技術 であり、導入企業の多くが 最適な活用方法を模索中

導入効果と今後の課題

  • コーディング速度の向上 と レビュー時間の増加 が相殺される現象
  • チームがAIエージェントの 利点と欠点を学ぶ ことで、今後の効率化が期待される
  • 現時点では、 AI導入による時間やコスト が「本当に価値があるのか」疑問視される状況
  • 多くの企業が AIエージェント運用の最適解 を模索している段階

Hackerたちの意見

AIが以前は見逃されていたコードのバグをたくさん見つけているのに気づいたよ。中には重要なものもあって、早めに見つけられるのはいいことだね。リストの12項目のうち、他の11項目は実際にはまず遭遇しないと思うけど、今知ったからにはそれぞれどう対処するか考えなきゃね（ドキュメント作成やファイリング、無視することも含めてさ）。まずは12の異なる問題を理解することが大事だよ。

└

以前は全部自動でコーディングしてたけど、新しいプロジェクトのバグをモデルに聞いたら、毎回思い出すのに15分かかるような面倒な初期設定のことを1分で済ませてくれたよ。開発者が単純なことで実装を完全に狂わせると、無駄に浪費する時間がたくさんあると思う。LLMによって節約された開発者の時間は、実際には何でもあり得るから測れないんだよね。

└

これらのものはまだ90%がゴミの誇大広告だよ。詳細はここを見てね: https://www.youtube.com/watch?v=NnV_cWeoo5Q&list=LL&index=3

これは2026年3月の話だけど、私が職業で経験したことと一致してる。コードレビューは常に大きなボトルネックで、エージェントによるコーディングが進むにつれてさらにそうなってる。自動レビューにもっと頼るべきだという話もあったけど、実際の改善にはつながってないね。シニアエンジニアは、エージェントがどんなに良くなっても、行単位のレビューを手放すのが難しいと思う。もしコードレビュー文化に大きな変化があるとしたら、まずは確立されたエンジニアリングチームではなく、最初から人間のレビューをしない方針を採用するスタートアップで起こると思う。そういうことが起こってるはずだけど、今のところほとんどの研究や調査には見えないだろうね。もし成功すれば、そういう会社が大幅に早く出荷できるようになって、業界全体がそれに追随せざるを得なくなるだろう。

└

同意するよ。最新のモデルは、要件が明確であれば、検証がかなり上手になってきてる。最近、テストスイートがすごく大きいのに、LLMが変更でテストをほとんど壊さないことにイライラしたんだ（PRは新しいテストを追加するだけで、古いものを変更しない）。だから、フル監査をやらせたら、約10万行のテストのうち、約6万行がほとんど役に立たないと判断された。多くは過剰にモックされていて、実際には何もテストしていないものもあった。それらを削除して、もっと広範なシナリオテストを書き直したら、たくさんのバグを見つけて修正もしたよ。合計で約2時間かかった。人間は要件、仕様、テストシナリオをレビューする必要があると思うし、いくつかの業界や用途ではまだすべての詳細をレビューしなきゃいけない。でも、典型的なCRUDアプリなら、プロセスと品質の基準を今まで以上に高く設定できるし、さらに早く進めることができると思う。

└

真剣なアプリケーションのために行単位のレビューを諦めるべきじゃない。私の会社のリーダーシップは、AIの目標について数週間ごとに揺れ動いてる。最近の話では、「AIを使うことで開発者の速度が今後2〜3年で約2倍になると期待している」と言ってるけど、もちろんそれは全くの非論理的だよ。私のチームの人たちは、コードを書くのに約10%の時間を使って、90%はデザインや分析に使ってるからね。だから、AIがコードを書く速度を2倍にしても、全体としては5%しか速くならないってことだ。

└

人間が上手くなったからって行単位のレビューを諦めるわけじゃないし、シニアエンジニアは自分のコードに対して他の人に行単位のレビューをしてほしいと思ってる。コードを生成する人やプログラムの良し悪しの問題じゃないんだよ。

└

シニアエンジニアは、エージェントがどれだけ進化しても、行ごとのレビューを諦めるのが難しいと思う。実は、俺は伝統的なコードレビューがあまり好きじゃないんだ。理由の一つは、ほとんどのコードレビュー用ツールが使いづらいから（特にGitHubやGitLabのウェブインターフェース）。でも、人間は正確性やセキュリティに関してコードレビューが得意じゃないってのもある。問題の一部は、著者のメンタルモデルにアクセスできないから、再構築しないといけないってこと。そうしないとプログラムのロジックを理解するのが不十分になる。純粋なエージェントによるコードレビューには別の問題があって、アーキテクチャやデザインの判断に関しては人間のレビュアーと比べて劣ることが多い。誤検知や見逃しも心配だしね。今のところ、エージェント支援のコードレビューが適切なIDEで行うのが一番良い結果を出してる。メンタルモデルを素早く構築して、基盤となるロジックを分析するのに役立つし、エージェントが最初の確認をしてくれるから。

└

コードレビューが遅れさせてるわけじゃないよ。欲しいものを手に入れるのには時間がかかるし、ちゃんと合ってるかどうかも確認しないと、クソみたいなものを本番に出しちゃって、自分の評判を落とすリスクがあるからね。PRをおざなりに通すチームでも、ドラフトを出して、雰囲気を掴むまでマージを待ってる人がいるのを見かけるよ。

└

行ごとのレビューを手放すのに苦労しているシニアエンジニアとして、君の意見に同意するよ。コードレビューは、何十年も続けてきた中で最も価値のあるプラクティスの一つだった。質の高いリリースを確保するための最良の方法の一つだし、若手エンジニアにスキルを伝えるための最高の方法でもある。エンジニアリング組織全体に部族的な知識を広げるし、他の人が関わっていないシステムに触れる機会を与える。伝統的な人間中心のエンジニアリングチームの利点は数えきれないほどある。でも、重いレビューから少ないレビューに移るのではなく、全くレビューなしの極端なところから始めて、新しいエージェントの現実に合わせたプラクティスに移る方が理にかなっている気がしてきた。エージェント時代のためにコードレビューを修正する必要はなくて、まだ発明されていない全く新しいプラクティスが必要なのかもしれない。

└

僕はハイブリッドなレビュープロセスに賛成だな。人間は自分の限界を認識して、得意なところ（提案された変更の高レベルな概念やアーキテクチャ）に集中して、あとはLLMに任せるべきだと思う。人間が一行ずつレビューするのは今や無意味だよ。

└

これをこう言い換えたいな：品質は常に重要なボトルネックで、エージェンティックコーディングではさらに顕著になってる。コードレビューは、設計やコードの品質問題が多く見られる場所なんだ。

Hacker Newsで議論の続きを見る