【ITニュース解説】After Agents Arrived, PRs Took 49% Longer to Merge. Stop Opening Them From a First Draft

システム開発の現場では、ソフトウェアの品質を保ちながら効率的に開発を進めることが常に求められている。近年、AI技術の進化は目覚ましく、プログラミングの世界でもAIコーディングエージェントと呼ばれるツールが注目されている。これは、開発者が指示を与えるだけでAIがコードを自動生成してくれる画期的なツールだ。多くの開発者は、AIがコードを書くことで、開発スピードが格段に向上し、人間はより創造的な作業に集中できると期待した。

しかし、実際にAIコーディングエージェントを導入した企業での開発プロセスを詳細に分析したハーバード大学の研究結果が、その期待とは異なる実態を明らかにしている。この研究は700社以上の企業を対象に、AIツールの導入が開発ワークフローにどのような影響を与えたかを調べたものだ。結果として、AIエージェントを導入した企業では、開発者が書いたコードを他のチームメンバーが確認・承認する「プルリクエスト（PR）」という工程が、以前よりもはるかに長い時間がかかるようになったという。具体的には、PRが提出されてから最終的にコードがプロジェクトに統合されるまでの「マージ時間」が、以前に比べて約5割も増加している。さらに、一度提出されたPRが、レビュー担当者から「変更が必要」と差し戻される割合が約2倍に増え、生成されるコードの行数も30%増加したと報告されている。一方で、実際に完了した作業、例えば課題管理ツール「Jira」で解決済みとマークされた問題の数には、統計的に意味のある増加は見られなかった。これはつまり、AIがたくさんのコードを早く書くようになったにもかかわらず、プロジェクト全体の進捗はそれほど早まっていない可能性を示唆している。

なぜこのような現象が起きるのだろうか。システム開発では、開発者が書いたコードをチーム全体で共有し、他のメンバーがその内容をチェックして問題がないか確認する「コードレビュー」という重要なプロセスがある。このプロセスは、コードの品質を保ち、バグを防ぎ、チーム全体の知識を共有するために不可欠だ。開発者が新しい機能や修正を実装すると、その変更内容をまとめた「プルリクエスト（PR）」を作成し、レビュー担当者に提出する。レビュー担当者はそのPRを読んで、コードの品質や安全性、機能の正確性などを確認し、承認することでコードがプロジェクトの主要な部分に統合される（マージされる）。

今回の研究では、このコードレビューのプロセスが、AIの導入によって大きな負担を抱えるようになったことが示されている。コードレビューを「生産者（開発者）がPRを作り、消費者（レビュー担当者）がPRを処理する待ち行列（キュー）」だと考えてみよう。AIエージェントはコードを高速に生成できるため、「生産者」である開発者がPRを提出するスピードは格段に上がった。しかし、「消費者」であるレビュー担当者の人数や処理能力は、それほど簡単には増やせない。結果として、レビュー待ちのPRが積み重なり、待ち行列が長くなる。

さらに悪いことに、AIが生成したコードの品質が不十分な場合、レビュー担当者はPRを「変更が必要」として差し戻すことになる。この差し戻されたPRは、修正されて再び待ち行列に並ぶことになる。これは「リトライ」と呼ばれ、すでに混雑しているレビューキューに、さらに負荷をかけることになる。以前は8件のPRのうち1件が差し戻されていたものが、AI導入後には4件のうち1件が差し戻されるようになったということは、同じPRが何度もレビュー担当者の手元に戻ってくる頻度が高まったことを意味する。これにより、レビュー担当者は本来であれば新しいPRを見るべき時間を、修正されたPRの再確認に費やすことになり、レビュー全体のボトルネックがさらに悪化するのだ。

この問題の根源には、人間がコードを書くプロセスと、AIがコードを書くプロセスの違いがある。人間がコードを書く場合、開発者は頭の中でコードの設計を考え、一行一行を注意深く記述し、自分で一度は読み直して基本的な間違いがないかを確認してからPRを作成する。つまり、「最初のドラフト」は開発者自身によって一度レビューされている状態なのだ。しかし、AIエージェントは、指示を受け取ると高速でコードを生成し、その「最初のドラフト」をそのままPRとして提出してしまう傾向がある。その結果、本来であれば開発者自身が行うべき初期の修正や推敲作業がスキップされ、その確認作業の負担がレビュー担当者に丸ごと押し付けられてしまう。開発者がAIの生成したコードを自分で確認する前にPRを出すことで、以前は開発者自身の思考の中で行われていた修正のサイクルが、レビュー担当者と開発者の間で行われる「コメントのやり取り」という形に移行してしまい、このやり取りはレビューキューの速度に合わせて進行するため、時間がかかってしまうのだ。

この状況を改善するための最も重要な対策は、AIエージェントが生成した「最初のドラフト」を、そのままプルリクエストとして提出しないことだ。開発者は、AIがコードを生成した後、それをまず自分でレビューし、納得できる状態にしてからPRを提出するべきである。具体的には、以下のような手順が推奨される。

まず、AIエージェントには専用のブランチ（コードの作業空間）で作業させ、そのブランチでAIが生成したコードの変更内容を、開発者自身が詳細に確認する。変更されたファイルのリストや、コードの変更履歴を順番に追いながら、AIが意図した通りにコードを書いているか、バグや問題がないかを注意深くチェックするのだ。この際、AIが提示する「まとめ」や「テスト結果の概要」に頼るだけでなく、開発者自身が実際にテストコードを実行し、機能が正しく動作するかを確認することも重要である。

もし問題点を見つけた場合は、それをレビューコメントを書くように具体的に言語化し、AIエージェントに直接フィードバックして修正を指示する。例えば、「src/orders.tsファイルのrefund()関数で、注文が支払済みであることのチェックが抜けている。このチェックを再度追加し、未払い注文に対するテストも追加してほしい」といった具合に、どのファイルで何が問題で、どう修正すべきかを明確に伝える。AIはすぐに修正案を生成できるため、この修正のサイクルを開発者とAIの間で素早く繰り返すことができる。この段階では、まだ他のチームメンバーにレビューを依頼せず、「ドラフトプルリクエスト（下書きPR）」としてマークしておくのが良いだろう。ドラフトPRは、まだマージできない状態であり、コードの所有者（レビュー担当者）にも自動的にレビュー依頼が送られないため、開発者とAIの間でコードを練り上げるのに適している。

開発者自身がAIの生成したコードを徹底的にレビューし、自分がもし他の人のPRを見たら承認できると確信できるレベルにまで品質を高めてから、正式なプルリクエストとして提出する。そして、PRの説明文も自分で作成し、変更内容を簡潔かつ明確に記述する。もし2つの文章で変更内容を説明できない場合、レビュー担当者もその変更を理解するのに苦労するだろう。

このような「セルフレビュー」のプロセスを導入することで、人間のレビュー担当者の貴重な時間を節約できる。本来、レビュー担当者が修正を依頼するために費やしていた時間や、修正されたコードを再度レビューするために費やしていた時間を、より新しいPRのレビューや他の重要な作業に振り向けることができるようになる。結果として、レビューキューの混雑が緩和され、開発プロセス全体の効率が向上することが期待される。

もちろん、このセルフレビューは万能ではない。開発者自身がAIに与えた指示に基づいてコードが生成されるため、開発者とAIは同じ「盲点」を共有する可能性がある。そのため、セルフレビューは最終的な品質保証ではなく、あくまで質の高いPRを提出するための準備段階と捉えるべきだ。セルフレビューをしても、開発者には見えなかった問題点を、チームメイトのレビュー担当者が発見してくれることは依然として重要である。また、全てのPRに対してこの徹底したセルフレビューを行うことは、開発者自身の時間も消費する。しかし、このコストは、最終的に誰かがそのコードを詳しく読む必要がある以上、誰がその作業を行うかという選択の問題である。レビュー担当者の時間を消費するよりも、開発者自身がAIを効率的に活用し、レビューのボトルネックを解消する方が、チーム全体としては合理的である可能性が高い。

AIによるコードレビュー支援ツールも登場しているが、研究によれば、これらもまた人間のレビューを完全に置き換えるには至っていない。多くの企業でAIレビューツールが使われているものの、レビューコメントの大部分は依然として人間が書いており、AIがコードレビューの待ち行列を解消する決定打とはなっていないのが現状だ。

結論として、AIコーディングエージェントは開発者の生産性を高める強力なツールであるが、その利用方法には工夫が必要である。AIが生成したコードの「最初のドラフト」をそのままPRとして提出するのではなく、開発者自身がAIと協力してコードを推敲し、高い品質に仕上げてからPRを出す習慣が、チーム全体の開発プロセスを円滑にし、AIの真の価値を引き出す鍵となるだろう。これは、開発者がAIとの協業において、より主体的な役割を果たすことの重要性を示している。