AIコーディングエージェント導入後もデバッグ時間はコーディングの2倍 — 生成コードの35%は「動作を理解されないまま」本番投入

9月28日、Computer Weeklyが「Are AI coders more trouble than they're worth?」と題した記事を公開した。AIコーディングエージェントの普及によって開発チームの生産性が向上するどころか、デバッグ負荷が増大しているという調査結果を詳しく紹介している。

AIが書いたコード、35%は「何をするか理解されないまま」本番投入される

独立系調査会社Coleman Parkesが英米のソフトウェア開発チーム300名（開発者およびエンジニアリングリード）を対象に実施した調査が、Undoの報告書「Overcoming the limitations of coding agents in complex software systems」として公開された。Undoはデバッグ支援ツール（UDBなど、プログラムの実行を時系列で巻き戻しながら解析できるリバーサブルデバッガ）を開発・販売する企業であり、本レポートは自社製品の訴求文脈で発行されている点には留意しておきたい。ただし調査自体は独立系の調査会社が実施しており、個別の数字は一次データとして参照に値する。

結果は厳しい。**93%のチームがAIのハルシネーション（事実に基づかない自信満々な回答）を経験しており、コードの問題箇所を誤診されたという。55%はAIエージェントが誤ったコードを頻繁に混入させ、手直しによってリリースサイクルが遅延していると回答した。さらに94%**が、AIが生成したコードの解析を月1回以上行う必要があり、その結果として生産性を失っていると認めている。

特に深刻なのは、AIが生成したコードの35%以上が、開発チームがそのコードの動作を完全に理解しないまま本番環境へ到達しているという事実だ。「とりあえず動くから」でマージされたコードが本番障害の種になる——現場エンジニアには心当たりのある話ではないだろうか。

デバッグ時間は週平均16.9時間、コードを書く時間の約2倍

Undoの調査では、エンジニアがデバッグに費やす時間はコードを書く時間の約2倍に達しており、週平均16.9時間という数字が示された。元記事によれば、コード記述に充てられる時間は週約8〜9時間とされており、この数字との対比で「2倍」という表現が導かれている。

なお、この「2倍」という数字はAIエージェント導入を直接の原因としてデバッグ時間が増加したことを証明するものではなく、AIエージェントが普及した現在の開発現場における実態調査として捉えるのが正確だ。AIが普及する以前と比較した縦断的なデータは本調査には含まれていない。

AIエージェントはコードを高速に大量生成できる。しかしその速度に人間のデバッグ能力が追いつかない。記事が指摘するように、ボトルネックはコード生成の上流から、理解・検証・デバッグという下流へと移動しただけだ。コスト削減を目的に導入したはずのAIが、別の場所で人的コストを生み出している構図である。

Undoの創業者兼CEOであるGreg Law氏はこう述べている。

「コードが明らかに壊れている場合、原因を見つけるのはたいてい簡単だ。エンジニアが苦労するのは、"ほぼ正しいが完全ではない"コードだ。そういうとき、何が・なぜ問題なのかを解明するために何日も費やすことになる。エージェントは大量のコードを素早く書くのは得意だが、デバッグは苦手だ。その結果、エンジニアは人間がデバッグできる限界をはるかに超えたコードの雪崩に埋もれている」

問題の本質：AIはコード生成だけに使われ、デバッグには使われていない

Undoの主張は明快だ。AIをコード生成にだけ適用しても生産性向上は実現しない。ソフトウェアデリバリーサイクル全体にAIを適用すべきだ、というものである。

特にデバッグ局面でのAIの弱点として、以下が挙げられている：

アプリケーションがなぜそのように振る舞うのかを理解することの難しさ
不完全な証拠から自信を持って回答するAIの性質（ハルシネーション）
これらが組み合わさることで、バグや不安定性の原因をAIが誤診しやすくなる

解決策としてUndoが提案するのは、「コードが実行時に実際に何をしているか」というリッチなコンテキストをAIエージェントに与えることで、エージェント自身が証拠を収集し、正確な結論に独立して到達できるようにする、というアプローチだ。これは同社の製品コンセプトと直接つながる提言であり、解決策の評価にあたってはその点も念頭に置く必要がある。