AIでコードは増えたのに、ソフトウェアの成果が増えない理由

導入：生成AIがソフトウェア開発に入り、最も分かりやすく変わったのはコードを書ける量と速度だ。しかし、コードが増えたからといって、利用者に届くソフトウェアが同じ割合で増えるとは限らない。ハーバード大学の研究者であるFiona Chen氏とJames Stratton氏の分析は、Jellyfishの開発チームに関する集約データを用い、この直感に反する状況を示している。AIによってコード作成は活発になっても、ソフトウェアの成果は増えていない可能性がある。

分析から読み取れること

素材によれば、対象は700社を超えるソフトウェア企業で、commitやPRなど3億件を超える独立した作業イベントと、70万人を超える従業員の記録が含まれる。ただし、今回提供された素材には、研究の全手法、対象期間、詳細な統計結果は掲載されていない。そのため、すべての組織に当てはまる因果関係として断定するのではなく、AI導入後の工程を考えるための重要なシグナルとして読むべきだ。

主なポイントは次の通りだ。

• AIはコード作成の負担を下げ、変更やコミットの量を増やし得る。
• 変更が増えれば、レビュー、テスト、統合、保守の仕事も増える。
• 人間によるCode Reviewが重要な関門であり続けるなら、追加されたコードは本番へ進まず、待ち行列にたまる可能性がある。
• AIの効果はコード行数や生成量ではなく、PRの所要時間、マージ、欠陥、リリース、利用者への価値で評価すべきだ。

ボトルネックは移動する

従来の開発では、コードを書く作業が遅さの主因と考えられがちだった。コーディング支援ツールやエージェントがこの工程を短縮すると、今度はレビュー担当者の時間が希少になる。レビューは文法の確認だけではない。アーキテクチャとの整合性、セキュリティ、業務ルール、テストの十分性、将来の保守コストを判断する必要があるからだ。レビュー体制を増強せず、自動テストや変更の優先順位付けも整えなければ、生成速度の向上がそのまま納期短縮につながらず、滞留や手戻りを増やすこともある。

ここで重要なのは、コードが中間成果物に過ぎないという点だ。価値が実現するには、検証、統合、承認、リリース、保守を通過しなければならない。AIを速い入力装置としてだけ導入すれば、工程の前半だけが膨らみ、後半の処理能力は変わらない。全体の成果を増やすには、パイプライン全体が追加の変更を安全に処理できる必要がある。

企業への示唆

企業はAIの利用率や生成コード量だけで導入効果を説明すべきではない。作成速度と、実際のソフトウェア提供を分けて測る指標が必要だ。自動テスト、リスクに応じたレビュー、細かな変更単位、明確なコード所有権、重要システムへの人間の監督は、そのための現実的な施策になる。

開発者にとっても、AIは技術的判断を不要にするものではない。むしろ設計、レビュー、優先順位付け、複雑性の管理がより重要になる。最も多くのコードを書くチームではなく、価値の低い変更を早く見分け、信頼できる変更を実用的なソフトウェアへ変えられるチームが優位に立つ可能性がある。素材だけではCode Reviewが唯一のボトルネックだとは証明できないが、AI開発の焦点が「どれだけ書けるか」から「組織がどれだけ安全に消化できるか」へ移っていることは示している。

出典：OSChina