AIでコードは増えたが、完了した作業は増えたと言えない：理解の負債

AIコーディングエージェントを入れると、コードの量は目に見えて増えます。一方で、その分だけ仕事が終わったのかは、見えにくいままです。10月に報じられた2つの資料が、この問いに数字で答えています。ハーバード大学の2人の研究者による論文（2026年8月4日版）と、Undoの委託でColeman Parkesが実施した調査です。調べ方も対象も違いますが、増えた量の先で起きていることは同じ方向を指しています。

コードは3割増えたが、完了した作業は増えたと言えない#

論文はエンジニアリング分析ツールを提供するJellyfishのデータを使っています。対象は718社、約3億件の作業記録で、期間は2021年1月から2026年3月までです。各社がAIツールを導入した時期のずれを利用して、導入前後の変化を比べています。AIの利用状況はGitHub Copilot、Cursor、Claude Codeについて観測しています。

AIエージェントを導入した会社では、次のように変化しました。

指標	導入後の変化
追加されたコード行数	30%増
コミット数	20%増
プルリクエスト（PR）数	23%増
Jiraの課題と機能（エピック）の解決数	有意な変化なし

Jiraの課題は、論文の説明では、コーディングの成果が本番環境にデプロイされたときに解決されます。つまり、本番に届いた作業の量には、有意な増加が見られませんでした。論文の推定では、課題の解決数の増加は、95%信頼区間で基準値の12%を超えないとされています。コードの増加幅（30%）に見合う増加は確認できていません。

課題が大きくなり、件数が横ばいでも成果は増えている、という可能性も確かめられています。課題1件あたりの大きさに変化は見つかりませんでした。なお、補完中心のAIアシスタントでは、コードの増加は行数12%、コミット9%、PR5%にとどまり、有意だったのはコミットだけです。

増えていたのは、レビューの時間と手戻り#

論文はこの差の理由を、コードレビューが待ち時間の中心になったことだと解釈しています。エンジニアがコードを書く時間は、全体の30〜42%です（論文の推計）。残りのレビューや管理などの時間が変わらなければ、書く工程だけが速くなっても、完了した作業の増加にはつながりにくくなります。

AIエージェントの導入後は、PRを出してからマージされるまでの平均日数が49%延びました（基準値は7.03日）。変更依頼が付くPRの割合はほぼ倍になり（基準値は13%）、PR1件あたりのレビューコメントは35%増えています。コードレビューをするエンジニアの割合も14%増え、会社は人手をレビューに回しています。

AIによるレビューも広がっていますが、中心は今も人です。2026年3月時点で、AIをレビューに使った会社は全体の約8割ですが、レビューコメントのうちAIが書いたものは23.3%で、AIのコメントが1件でも付いたPRは10.8%でした。

理解されないまま本番に届くコード（Undoの調査）#

もう一つの資料は、Undoが委託した調査です。対象は売上2億5000万ドル以上の大企業でミッションクリティカルなソフトウェアを担当する、シニアエンジニアリングリーダー300人で、93%がC/C++を扱っています。調査は2026年7〜8月に行われました。InfoQの記事が取り上げ、数値はUndoの報告書のページに載っています。

主な結果は次のとおりです。AIが生成したコードの35%は、チームが十分に理解する前に本番へ届いています。週の作業時間ではコードを書くのが平均9.8時間なのに対し、デバッグは16.9時間です。内訳は、開発中が9.7時間、顧客が見つけた本番の問題が7.2時間で、週40時間の42%に当たります。79%は、コードの生成は大幅に速くなったが、リリースの周期は以前より速くなっていないと答えました。過去6か月の間に、AIの誤った診断による根本原因の取り違えを93%が1回以上、本番障害やサービス停止を81%が1回以上経験しています。

現場の対処も聞かれています。AIエージェントでコードの理解やデバッグをするときの工夫として、最も多かったのは、エージェントの操作を人が承認する方法で66%でした。次いで、実行時に何が起きたかの情報をログやソース解析に足す方法が55%です。原因をエージェントに探させず、人が仮説を立ててエージェントに検証させる方法は48%、別のエージェントに作業を確認させる方法は40%でした。エージェントだけで確認を完結させる方法は、4つの中で最も少ない結果です。

どちらの資料も「理解の負債」という言葉は使っていません。2つの結果を結ぶ言葉として、私はこれが分かりやすいと考えています。AIがコードを書くと、書く人が内容を理解する作業は省かれがちです。省かれた分は消えず、レビューの往復や、障害のときの原因調べに、後から時間がかかります。論文のレビュー時間の増加と、Undoの調査のデバッグ時間は、その負荷が表れる別々の場所と読めます。

2つの資料の違いは次のとおりです。

	ハーバード大の論文	Undoの調査
調べ方	作業記録の分析（導入前後の比較）	リーダーへのアンケート
対象	718社	300人（大企業、93%がC/C++）
見ているもの	出力、レビュー時間、手戻り	デバッグ時間、障害、理解の度合い
読むときの注意	2026年3月までのデータ	調査を委託したUndoは、デバッグ用の実行記録ツールを売る会社

Undoの調査は自己申告で、対象も大規模でC/C++中心の現場に偏っています。結論がUndoの製品の用途と重なる点も踏まえ、数値は傾向として読むのが妥当です。

量の指標を、何に置き換えるか#

行数、コミット数、PR数は、書く工程しか測っていません。論文ではこの3つがいずれも2割以上増えた一方で、完了した作業に有意な増加は出ていません。AIを入れた効果を、これらで測ると、実態より大きく見えます。

置き換えの出発点になるのが、DORAのソフトウェアデリバリー指標です。DORAの解説ページでは、次の5つを挙げています。

• スループット: 変更のリードタイム（コミットから本番デプロイまでの時間）、デプロイ頻度、デプロイ失敗からの復旧時間
• 不安定性: 変更失敗率（即時の対応が必要になったデプロイの割合）、デプロイ手戻り率（本番インシデントを受けた計画外のデプロイの割合）

PRを経由する運用では、リードタイムにレビューの待ち時間が含まれるので、書く工程だけが速くなっても、数字は改善しにくくなります。変更失敗率と手戻り率は、十分に理解されないまま届いたコードの影響を拾える可能性があります。DORAの調査では、速度と安定性は、多くのチームで連動します。

使い方には注意点もあります。DORAは、指標を目標にするとチームが数字を操作しやすくなることと、1つの指標だけで複雑なシステムを測ってはいけないことを挙げています。複数の指標を並べて見るのが前提です。

理解の負債に近いところを見るために、2つを足す案があります。1つは、レビュー待ちの日数と、変更依頼の付くPRの割合です。論文が使った指標で、GitHubのデータから出せます。もう1つは障害の振り返りで、原因を説明できた担当者がいたか、原因の特定に何日かかったかを記録することです。どちらも私の案で、効果を検証したものではありません。

評価で品質とコストを並べる考え方は、Agent Experience（AX）の記事でも触れています。

読むときの限界#

ハーバード大の論文のデータは、2026年3月までです。Ars Technicaは、エージェントの出力はその後も改良されており、使い方に慣れた会社ではレビューと執筆の釣り合いが変わる可能性があると指摘しています。論文の推定は観察データによるもので、レビューが長くなった理由がコードの質の低下なのか、レビュー基準の変化なのかは、これだけでは切り分けられません。

それでも、書く速度だけで導入の効果を判断すると、レビューと障害対応に移った負荷を見落とします。自分たちのチームで見るなら、エージェント導入の前後で、レビュー待ちの日数と変更依頼の割合を並べるところから始められます。