必要なものは3つです。「AI coding agents generate more code, but not more software」というニュースを日本企業の実務へ落とすには、コード量ではなく完了した業務を測ること、レビュー待ちと人の確認負荷を分けて記録すること、対象を絞った比較検証を行うことが欠かせません。
- 成果指標：解決済みIssue、完了した機能、本番反映までの時間を置く
- 制約指標：PR提出からマージまでの経過時間、変更要求、人のレビュー時間を置く
- 判断方法：導入前の基準値と限定運用を比べ、生成量ではなく工程全体で継続可否を決める
2026年10月14日時点で確認できるHarvard Universityの研究は、AI coding agent導入後にコード行数、コミット、プルリクエストが増えた一方、Jiraで解決済みとなったIssueとEpicには統計的に有意な増加を検出できなかったと報告しています。まずは、この「増えたもの」と「増えなかったもの」を混同しないところから始めます。
最初の手順：「software output」の意味を固定する
見出しが測っているのは企業内の通過量
2026年10月9日、Ars TechnicaはAI coding agents generate more code, but not more softwareを公開しました。根拠になったのは、Harvard UniversityのFiona Chen氏とJames Stratton氏によるArtificial Intelligence in the Firm: Bottlenecks in Software Productionです。確認したPDFは2026年8月4日版で、分析データは2021年1月から2026年3月までを対象にしています。
ここで最も大切なのは、見出しの「not more software」を「AIはソフトウェアを作れない」「導入効果はゼロ」と読み替えないことです。研究が最終成果の代理指標にしたのは、Jiraなどの課題管理システムで解決済みになったIssueとEpicです。論文では、Issueはコードのレビュー、テスト、デプロイを経て完了扱いになる作業単位、Epicは複数のIssueを束ねた機能・プロジェクト単位として扱われています。
| 項目 | 研究上の扱い | 読み違えやすい点 |
|---|---|---|
| AI coding assistant | 人が主に書くコードを補完・支援するツール | 自律的にPRを作るagentと同じ効果ではない |
| AI coding agent | 指示を受け、複数工程を進めてコードやPRを作るツール | 企業で利用信号が1件出ただけでも導入として検出され得る |
| coding output | 追加コード行数、コミット数、PR数 | 活動量であり、顧客価値や本番成果そのものではない |
| software output | 解決済みIssueとEpic | 売上、利用率、障害率を直接測った指標ではない |
AIgent Labには、経験豊富なOSS開発者の個別タスクを調べたMETR研究を扱うAIコーディングツールは本当に速い？最新研究の意外な結論があります。そちらは個人の作業時間を比較したランダム化比較試験です。今回のChen・Stratton研究は企業単位の導入時期と工程データを追った観察研究であり、対象、手法、答えようとしている問いが異なります。
718社の工程データで増えたもの
現行論文の標本は、エンジニアリング分析基盤Jellyfishの顧客のうち、研究利用に同意し、必要な期間のデータを持つ718社です。対象には725,938人が含まれ、GitHubなどのバージョン管理、Jiraなどの課題管理、カレンダー、HR、AIツールの利用信号を合わせて、約3億件の作業イベントを分析しています。
研究者は、企業ごとにAI導入時期が異なることを利用したstaggered difference-in-differencesで、導入前後の変化を推定しました。以下の活動量と完了成果は、企業・月ごとに活動エンジニア数で割った1人・1か月当たりの指標です。AI coding agentについての主な結果は次のとおりです。
活動量と完成成果を別レイヤーで読む
| 工程 | 指標 | 推定された変化 | 実務での解釈 |
|---|---|---|---|
| コード作成 | 活動エンジニア1人・1か月当たりの追加コード行数 | 30%増 | 生成・編集されたコード量は明確に増えた |
| コード作成 | 活動エンジニア1人・1か月当たりのコミット数 | 20%増 | 保存された変更の回数が増えた |
| レビュー投入 | 活動エンジニア1人・1か月当たりのPR数 | 23%増 | 人や自動チェックが確認すべき変更が増えた |
| 完了成果 | 活動エンジニア1人・1か月当たりの解決済みIssue | 統計的に有意な増加なし | コード量ほど明確な成果増を確認できなかった |
| 完了成果 | 活動エンジニア1人・1か月当たりの解決済みEpic | 統計的に有意な増加なし | 機能・プロジェクト単位でも明確な増加を確認できなかった |
有意差なしはゼロの証明ではない
Issueの推定値は小幅なプラスでしたが、統計的に有意ではありません。論文は、活動エンジニア1人・1か月当たりのIssue解決数について、基準平均3.67件の12%を超える増加を95%信頼区間で排除できるとしています。したがって、「増加が完全にゼロと証明された」ではなく、「この標本と観測期間では、コード量に見られた30%増に見合う完成成果の増加を確認できなかった」と書くのが正確です。
研究者は、AI導入後にIssueが大型化・複雑化したため件数が増えなかった可能性も検討しています。Issue説明から所要時間帯を推定する指標と、過去の実サイクルタイムから予測する指標という2つの機械学習による代理指標では、平均的なIssueの大きさが変わった証拠は見つかりませんでした。ただし、どちらも真の顧客価値を直接観測したものではありません。
速くなった生成工程の後ろで何が詰まったか
コード作成が速くなっても、その後ろにはレビュー、テスト、承認、デプロイがあります。前工程だけの処理能力を上げれば、次の工程に仕掛かりが積み上がる可能性があります。論文が具体的に捉えたのは、PR提出からマージまでの遅延と、レビュー負荷の増加を示す複数の指標でした。
49%は人の手作業ではなく提出からマージまでの経過時間
| 指標 | AI coding agent導入後 | 注意すべき意味 |
|---|---|---|
| PR提出からマージまでの経過日数 | 49%増 | 人が手を動かしたレビュー時間ではなく、待ちを含む経過時間 |
| 変更要求が1回以上付くPRの割合 | 基準の13%から約25%へ上昇 | ほぼ倍増したが、原因を品質低下だけに限定はできない |
| PR当たりのレビューコメント | 35%増 | 修正や確認の往復が増えた可能性を示す |
| レビューを行う活動エンジニアの割合 | 相対的に14%増 | 企業が人員をレビュー側へ振り向けた動きと整合する |
論文は、PR当たりのコード行数には有意な変化がなかったことも確認しています。つまり、単に1本ずつのPRが巨大化したからコメントが増えた、という説明だけでは足りません。ただし、変更要求やコメントの増加は、AI生成コードの品質だけでなく、導入後にレビュー基準が厳しくなったことでも起こり得ます。研究はコード本文、バグ数、障害率を直接測っていないため、「AIコードの品質が30%悪化した」といった結論は出せません。
AIレビューを追加しても、人の責任は消えていない
2026年3月時点で、標本企業の約80%にはAIコードレビュー製品を利用した信号がありました。一方、AIが生成したのは全レビューコメントの23.3%で、AI生成コメントが1件以上付いたPRは10.8%でした。Ars Technicaの記事は後者をAIが担当したPRの割合のように要約していますが、一次論文の定義は「AIコメントが1件以上付いたPR」です。AIがPR全体のレビュー責任を負った割合ではありません。
AIレビューの選び方や人との役割分担は、AIコードレビューエージェント解説｜主要5ツール比較も参考になります。大切なのは、生成agentとreview agentを増やした数ではなく、誰が要件適合、設計、セキュリティ、本番影響を承認するかを固定することです。
日本企業の評価軸は「活動」から「流れ」へ移す
この研究から日本企業が持ち帰るべきなのは、特定製品の採否ではなく、測定単位の変更です。コード行数、コミット、PRは、工程へ投入された活動量です。導入効果を判断するなら、その活動が完了成果へ変わるまでの流れを一緒に見なければなりません。
評価表は完了側から先に読む
| 層 | 観測候補 | 単独で判断しない理由 |
|---|---|---|
| 活動量 | 生成コード行数、コミット数、PR数 | 未レビューの仕掛かりが増えただけでも上がる |
| 工程の流れ | タスク着手から本番反映、PR提出からマージ、レビュー待ち | どこへ制約が移ったかを見つけるために必要 |
| 完了成果 | 解決済みIssue、完了機能、受け入れ条件の充足 | チームが実際に届けた仕事へ近い |
| 品質・安全 | 変更要求、CI失敗、再オープン、ロールバック、障害 | 速度向上と引き換えの手戻りを見落とさない |
| 人と費用 | 人のレビュー時間、再作業、ライセンス・推論費用 | 節約した作業と増えた確認負荷を同じ表で比べる |
特に、PR提出からマージまでの経過時間と、レビュー担当者が実際に費やした時間は分けてください。経過時間が長い原因は、コードを読む難しさだけでなく、担当者不在、承認権限、他案件の優先順位、CI待ちでも起こります。人の作業時間だけを測ると待ち行列を見落とし、経過時間だけを測るとレビュー難易度を誤解します。
導入率にも同じ注意が必要です。研究では、企業内でagent利用信号が1件以上見つかった割合が2026年1月までに95%を超えましたが、導入後12か月の期間にGitHubで活動したエンジニアを分母にすると、agent利用率は中央値企業で約20%でした。「契約済み」「利用者がいる」「対象業務で定着」「完成成果が増えた」は、それぞれ別の状態です。
日本企業へそのまま一般化できない5つの理由
この論文は大規模な実務データを使っていますが、万能な結論ではありません。導入判断では、少なくとも次の留保を残す必要があります。
研究の射程と後続情報を混ぜない
- 日本企業だけの結果ではない：Jellyfish顧客のうち、継続データがあり研究利用へ同意した企業が対象です。日本企業の業種、受託開発、稟議、検収工程を分けた推定は示されていません。
- ランダム化試験ではない：企業ごとの導入時期を使う観察研究で、導入がなければ早期導入社と後期・非導入社が似た推移をした、という仮定に依存します。未観測の組織差は残り得ます。
- 観測は2026年3月まで：論文は2026年8月版ですが、それ以降のモデル性能、ハーネス、レビュー運用の改善は反映していません。Jellyfish Researchは別の2026年8月分析でagentic codingのimpact gapが縮まりつつあると報告していますが、同じ因果推定の更新ではないため、直接置き換えることはできません。
- 顧客価値を直接測っていない：解決済みIssueとEpicは有用な代理指標ですが、売上、利用者数、UX、障害、保守性を直接表すものではありません。
- 利用信号は完全な利用台帳ではない：95%超という数字は、企業内で最初の利用信号を検出できたかに基づきます。論文が使ったAPI由来の検出には契約プランや連携状況による制約があり、連携外での利用は捉え切れない可能性があります。
確認した原論文はJob Market Paperと記載されており、著者ページにも2026年8月版として掲載されています。確認した資料には査読済みとの記載がありません。この点も、確定した普遍法則ではなく、自社で検証すべき強い問題提起として扱う理由です。
基準線・限定実行・継続判断の3段階で試す
導入検証は日数で区切る必要はありません。比較できる件数がたまること、通常のレビューと本番反映まで観測できることを終了条件にします。固定の成功率やPR行数を外から持ち込まず、自社の導入前基準と比べてください。
段階1：同じ種類の仕事で基準線を作る
まず、1チーム・1リポジトリ・1種類のタスクを選びます。たとえば、既存機能の小さな不具合修正、定型的な内部ツール変更、テスト追加などです。新規機能、緊急障害、法令対応のように性質の違う仕事を混ぜると、agentの効果よりタスク差を測ってしまいます。
- Issueの受け入れ条件と担当者を記録する
- 着手、PR提出、最初のレビュー、マージ、本番反映の時刻を取る
- 変更要求、CI失敗、再オープン、ロールバックを数える
- レビュー担当者の実作業時間を、可能な範囲で別に記録する
- ライセンス・推論費用と、再作業に使った人の時間を残す
基準線は「AIを使わない理想状態」ではなく、現在の通常工程です。すでに補完型AIを使っているなら、その状態を明記し、agentを追加した差として比べます。Chen・Stratton研究のagent推定も、assistant導入後にagentを追加した効果として解釈されているため、この区別は重要です。
段階2：変更範囲と承認責任を限定する
agentには、Issueと受け入れ条件を渡し、作業ブランチからPRを作らせます。デフォルトブランチへ直接反映させず、テスト結果、変更理由、影響範囲、未確認事項をPRに残します。GitHub公式ドキュメントは、PRテンプレートで目的、関連Issue、テスト情報、チェック項目を標準化できると説明しています。
重要なディレクトリは担当チームへ自動でレビュー依頼を送れるようにし、必要なら承認を必須にします。GitHubのCODEOWNERS公式説明と保護ブランチの公式説明を使えば、所有者レビューやステータスチェックを既存フローに組み込めます。これはagent固有の成功保証ではなく、確認責任を曖昧にしないための基盤です。
CODEOWNERSの最小設定例
次はGitHub公式の構文に沿った配置例です。組織名、チーム名、対象パスは実際のリポジトリへ置き換えてください。
# .github/CODEOWNERS
/src/payments/ @your-org/payments-reviewers
/infrastructure/ @your-org/platform-reviewers
動作環境：GitHubリポジトリ。指定するユーザーまたはチームには書き込み権限が必要です。保護ルールでコード所有者の承認を要求する場合は、対象ブランチ側にCODEOWNERSを置きます。本番環境で使用する前に、必ずテスト用リポジトリまたは保護対象外のブランチでレビュー依頼と承認条件を確認してください。
セキュリティ面では、NISTのSecure Software Development Frameworkが、組織の基準に沿ったコードレビュー・コード分析と、見つかった問題の記録・優先付けを推奨しています。AIが生成したかどうかに関係なく、本番コードの確認工程として残します。
段階3：生成量を隠して継続判断する
評価会では、最初にコード行数やコミット数を見せない方法が有効です。先に完成成果、工程時間、品質、人の負荷、費用を確認し、その後で活動量を見ます。活動量の伸びに判断が引っ張られにくくなるからです。
| 観測結果 | 判断 | 次の操作 |
|---|---|---|
| 完了成果が増え、レビュー負荷と品質が許容範囲 | 適用候補 | 似たタスクへ対象を1つずつ広げる |
| コード・PRだけ増え、完了成果は変わらない | 工程再設計 | 仕様、PR分割、レビュー割当、テストの詰まりを特定する |
| 完成は速いが、再作業・ロールバックが増える | 範囲縮小 | 高リスク領域を外し、受け入れ条件と検証を強める |
| 人のレビュー負荷と総費用が効果を上回る | 停止または用途変更 | 下書き、調査、テスト補助など別工程で再評価する |
AI coding agentの能力を引き出すハーネス設計は、Why are coding agents so dumb? 論点はハーネスで詳しく扱っています。ただし、ハーネスが優れていても、組織の承認能力や本番責任まで自動的に増えるわけではありません。
レビュー渋滞を増やす3つの誤算
誤算1：agentのPR数を生産性として報告する
❌ PR、コミット、生成コード行数が増えたので、導入は成功したと判断する。
⭕ 解決済みIssue、本番反映までの時間、変更要求、再作業、人の確認負荷を先に確認する。
なぜ危険か：今回の研究では、活動量の増加と完成成果の増加が一致しませんでした。PR数はレビュー工程に入った仕事であり、完了した仕事ではありません。
誤算2：生成agentとreview agentだけで責任を閉じる
❌ 別のAIがレビューしたため、人は差分を確認しなくてよいと扱う。
⭕ AIレビューは第一段の補助とし、要件適合、設計、セキュリティ、本番影響の承認者を人で明示する。
なぜ危険か：AIコメントが付いたことと、PR全体の責任をAIが引き受けたことは同じではありません。生成と評価が同じ誤解を共有する可能性もあります。
誤算3：マージされた成功例だけを集計する
❌ 完成したPRだけを数え、途中で捨てた変更、手作業で書き直したタスク、再オープンを除外する。
⭕ 失敗・中断・差し戻しも母数に含め、最初の指示から本番反映後まで追う。
なぜ危険か：失敗したagent作業を記録から外すと、見かけの成功率と節約時間だけが高くなります。工程全体の費用を比較できません。
HN 359ポイントが映した二つの現場感
Hacker Newsの対象スレッドは、2026年10月14日の確認時点で359ポイント、299コメントでした。ここでの発言は統計的な証拠ではなく、コミュニティの体験談・意見として区別して読む必要があります。
目立ったのは、「レビュー待ち」という言葉だけでは狭すぎるという反応です。設計意図、仕様理解、テストの意味、長期保守を人が把握できないまま差分だけ増えると、レビュー工程で問題が表面化します。仕様を先に確認し、AIを第一段レビューに使い、人はアーキテクチャや事業要件を判断する方がよい、という意見もありました。
一方で、小規模チームや個人開発では、以前なら作らなかった内製ツールや個人用ソフトウェアが増えたという反例も複数あります。これは原論文と必ずしも矛盾しません。論文の対象はJellyfishを利用する企業の工程データであり、課題管理に載らない個人ソフトウェアや小規模な試作をすべて捉える設計ではないからです。
コミュニティ反応から採るべきなのは結論ではなく、検証仮説です。「仕様確認を前へ移すと差し戻しが減るか」「小規模な社内ツールでは完了成果が増えるか」「テストの量ではなく保守負荷がどう変わるか」を、自社データで確かめてください。
よくある質問
Q1. この研究は、AI coding agentが役に立たないと証明したのですか？
いいえ。コード行数、コミット、PRは有意に増えています。一方、解決済みIssueとEpicでは有意な増加を検出できませんでした。研究が示すのは、コード生成工程の加速が、そのまま企業全体の完成成果へ比例して流れなかったことです。
Q2. 「レビュー時間49%増」は、人の作業時間が49%増えたという意味ですか？
違います。論文が測ったのは、PR提出からマージまでの経過日数です。レビュー待ち、担当者の都合、修正往復、CI待ちなどを含みます。社内の限定評価では、経過時間と人の実作業時間を分けて記録してください。
Q3. AIコードレビューを導入すればボトルネックは解消しますか？
この研究だけからは断定できません。2026年3月時点でAIレビュー利用信号のある企業は広がっていましたが、人のレビュー関与はなお大きい状態でした。AIレビューの導入数ではなく、完了成果、差し戻し、人の負荷がどう変わったかを比較する必要があります。
Q4. 日本企業にも同じ数値が当てはまりますか？
そのままは当てはめられません。日本企業だけの推定は示されておらず、受託・内製、規制、承認権限、レガシー環境でも結果は変わり得ます。数値を予測値として使わず、各社の限定評価で確かめるボトルネック候補として使うのが安全です。
Q5. 最初に1つだけ測るなら、何がよいですか？
対象タスクが一貫しているなら、Issue着手から本番反映までの時間を起点にしてください。その内訳として、agent作業、PR待ち、レビュー実作業、修正、CI、承認を分けると、速くなった場所と遅くなった場所を同時に確認できます。
Q6. 雇用削減の根拠として使えますか？
使えません。論文は、全社雇用とエンジニア雇用に統計的に有意な変化を確認できなかったとしています。また、観測期間は比較的短く、雇用情報の更新遅延や他社への波及を捉えないという留保があります。人員計画は別の根拠と長期データで判断すべきです。
結論
「AI coding agents generate more code, but not more software」が突きつけたのは、AI coding agentの能力不足という単純な話ではありません。コード作成だけを高速化すると、レビュー、テスト、承認、デプロイの制約が目立ち、活動量の伸びが完成成果へ届かない場合があるという工程設計の問題です。
日本企業が始める順番は明確です。現在の完了成果とレビュー負荷を測り、対象業務と承認者を限定してagentを入れ、コード量を隠した状態で工程全体を比較します。完成成果が増えず、レビュー待ちだけが増えたなら、モデルの追加購入より先に、仕様の明確さ、PRの分け方、レビュー担当、テスト、権限を見直してください。
- コード量・PR数は活動指標として扱い、成功判定から切り離す
- 完了成果、工程時間、品質、人の負荷、費用を同じ評価表に置く
- 全社展開の前に、同種タスクの限定検証で継続・再設計・停止を決める
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Artificial Intelligence in the Firm: Bottlenecks in Software Production — Fiona Chen、James Stratton、Harvard University。現行版2026年8月4日、参照日2026年10月14日
- Fiona Chen公式研究ページ — 論文名、著者、版、要旨の確認。参照日2026年10月14日
- AI coding agents generate more code, but not more software — Ars Technica、2026年10月9日公開、参照日2026年10月14日
- New Research from Harvard & Jellyfish: AI Is Making Developers Faster. So Where’s the Business Impact? — Jellyfish、2026年1月28日公開。初期版の公式解説として参照、参照日2026年10月14日
- Agentic Coding: The Impact Gap Is Closing — Jellyfish Research、2026年8月17日公開。後続の別分析として参照、参照日2026年10月14日
- Managing and standardizing pull requests — GitHub Docs、参照日2026年10月14日
- About code owners — GitHub Docs、参照日2026年10月14日
- Secure Software Development Framework Version 1.1 — NIST、参照日2026年10月14日
- Hacker News discussion — コミュニティの反応として参照、2026年10月14日時点
あわせて読みたい
- AIコーディングツールは本当に速い？最新研究の意外な結論 — 個人タスクの作業時間を測ったMETR研究との違いを確認する
- AIコードレビューエージェント解説｜主要5ツール比較 — 自動レビューと人の確認をどう分けるか整理する
- Why are coding agents so dumb? 論点はハーネス — agentが完了まで進めるための周辺設計を見直す
この記事はAIgent Lab編集部がお届けしました。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
