ハーバード大学のワーキングペーパーは、「AIで書くコードが増えれば、納品されるソフトウェアも増える」という一般的な生産性の主張を検証する材料となる。Jellyfishのエンジニアリング分析プラットフォームを利用する718社で、Fiona ChenとJames Strattonは、コーディングエージェントの導入後、稼働中の従業員1人当たりのコード行数が30%、コミット数が20%、プルリクエスト数が23%増えたと推定した。完了したJira課題とエピックの指標には、統計的に有意な増加が見られなかった。論文の現行版の日付は2026年8月4日で、業務イベントデータは2026年3月までである。

この不一致はエンジニアリング責任者にとって重要だ。プルリクエストはレビュー、テスト、場合によっては修正の待ち行列に入る。同じ調査では、エージェント導入後、プルリクエストの提出からマージまでの経過時間が推定49%増えた。変更要求がより一般的になり、プルリクエスト当たりのコメント数も増えた。これらはレビュー作業の負荷増を示すが、エージェントが書いた変更がすべて質の悪いものだと示すわけでも、測定された欠陥率を特定するものでもない。

大きな変化

  • 何が変わったか：この企業単位の調査では、コーディングエージェントの導入は、コーディング活動の大幅な増加と、より厳しいプルリクエストレビューに伴っていた。一方、解決済み課題やエピックに統計的に有意な増加はなかった。
  • なぜ重要か：コード行数、コミット、プルリクエストは本番工程に入る仕事を測る。解決済みの仕事は後段の指標だ。コード量だけでエージェントを評価するチームは、レビューに回ってくる負荷を見落とす可能性がある。
  • 注目点：企業がレビュー能力を高められるか、また後続データで完了した仕事の増加が示されるか。このワーキングペーパーは2026年3月までの初期導入を追ったもので、長期的な影響は判断できない。

アシスタントとエージェントでは推定結果が異なった

著者は、開発者が作業する間にコード候補を返すアシスタントと、より高いレベルのタスクを受け取り、開発者が結果を承認するまでに複数の手順を進められるエージェントを区別している。アシスタントの導入はGitHub CopilotとCursorの法人ライセンス有効化で測定した。エージェントについては、Claude Codeの利用データに加え、ボットアカウントやコミット・プルリクエスト内のツール署名などのシグナルを組み合わせている。個人利用や統合されていないツールの一部は、この測定から漏れる可能性がある。エージェントの推定値は、先行するアシスタント導入期間と比べた、エージェント導入に伴う追加的な関連を示すものであり、エージェントを使う個人全員についての推定ではない。

アシスタントの結果はより小さく、コード行数が推定12%、コミットが9%、プルリクエストが5%増加した。論文の主要推定で統計的に有意だったのはコミットの結果だけだった。エージェント導入では、3つのコーディング活動指標すべてに有意な増加が見られた。コミットはコード更新を記録し、プルリクエストは変更をレビューに提出する。どちらも機能がユーザーに届いた証明にはならない。論文は、レビュー、テスト、デプロイ後にチームが作業完了と記録する追跡ワークフローに基づき、解決済みJira課題とより大きなエピックを後段の成果指標に用いる。Jiraのステータスは依然として納品の代理指標であり、ユーザーが受け取ったものを独立に測定するものではない。

エージェントでは、解決済み課題の推定増加は従業員・月当たり0.12件で、基準値は3.67、標準誤差は0.17だった。この結果は統計的にゼロと区別できない。エピックの完了にも有意な変化はなかった。著者によると、信頼区間は、調査期間中の課題完了数の増加が基準平均の12%を超える可能性を排除している。これは「エージェントは有用なソフトウェアを何も生まない」という主張より限定的な発見だ。小幅な改善はあり得るし、課題数では価値や品質のあらゆる変化を捉えられない。著者は予測タスク所要時間の指標を使い、課題の規模が変化したかを検証したが、サンプルではその変化を示す証拠はなかった。

レビュー担当者に届く仕事が増えた

レビュー指標は、成果の差に妥当な仕組みを示している。エージェント導入後、プルリクエストの提出からマージまでに基準値の7.03日と比べて3.45日余計にかかると推定され、49%の増加だった。これはレビュー工程での暦日であり、個人が実際にレビューした時間を計測したものではない。正式な変更要求を受けたプルリクエストの割合は、基準値13%から約12パーセントポイント上昇した。要求1件当たりのコメント数は基準値1.66から0.58増え、35%の増加だった。月に少なくとも1件のプルリクエストをレビューした従業員の割合は、基準値29%から約4パーセントポイント、相対比で14%上昇した。比較対象のアシスタント推定では、レビュー期間、変更要求、コメントに有意な増加はなかった。

これらのメタデータだけでは、レビュー担当者がなぜ変更を求めたのかは分からない。提出が増えれば固定容量のレビュー待ち行列に負荷がかかる可能性があり、コード品質やレビュー基準の変化も精査を増やし得る。著者はプルリクエストの平均規模に有意な増加を見つけず、コメント増加を説明する単純な仮説を弱めている。コード内容を調べたり、エージェント生成物の欠陥を直接数えたりはしていない。二段階の生産モデルは、コード作成の高速化と草稿ごとに必要なレビューの変化が組み合わさり、完了成果を抑える可能性を説明する。このモデルは観察結果の解釈であり、いずれかの仕組みを切り分ける独立の検証ではない。

調査対象ではAIレビュー工具も普及しており、2026年3月までに企業のほぼ80%がいずれかを利用していた。それでも論文がAIに帰属させたレビューコメントは23.3%で、プルリクエストの10.8%に少なくとも1件のAIコメントがあった。したがって、レビュー工具の導入は、これらの企業でレビューが自動化したことを意味しない。

この研究設計で分かること

研究者は、Jellyfishを利用する参加同意済みの718社、725,938人の従業員について、2021年1月から2026年3月までの約3億件の業務イベントを分析した。アシスタントやエージェントの導入前後の結果を、導入がより遅かった企業またはまだ導入していない企業の結果と、段階的な差の差法で比較している。企業と暦月の統制により、安定した差や共通の時間傾向の一部を調整する。それでも推論は、導入がなかった場合に各社がたどったであろう経路を比較可能とみなせるかに依存する。大企業ほど導入が早く、測定されていない変化が導入とエンジニアリング業務の両方に影響した可能性もある。これは観察研究であり、推定値を無作為化試験やすべてのソフトウェアチームへの予測として読んではならない。

雇用に関する結果にも同じ慎重さが必要だ。LinkedInと連携した総雇用数、およびJellyfishの稼働従業員数を使ったエンジニアリング職の分析では、観察期間中にエージェント導入へ有意な変化を帰属させられなかった。より長い調整期間の後の採用や、労働市場全体の動向を示すものではない。

BIG CHANGEの以前の報道は、AIコーディングと信頼できる納品に関する別のエンジニアリング事例を取り上げた。この研究は複数企業を対象とし、コーディング活動、レビュー、解決済みの仕事を別々の指標で見る。その実務上の教訓は、エージェントを評価する際にこれらの段階を合わせて追うことだ。初稿が速くなれば下流で待つ仕事量が変わるが、この論文は完了した課題やプロジェクトの対応する増加をまだ示していない。

出典・参考資料