【ITニュース解説】Agent PRs revert at 6.1% or 14.5%, depending on the vendor

最近の研究で、AIが生成するコードの品質と、それが開発プロセスに与える影響について、具体的なデータに基づいた分析が公開された。この研究は、AIが書いたコードの品質を「良い」「悪い」といった単純な二元論で語るのではなく、どのようなAIエージェントが、どのような条件でコードを生成したかによって、その評価が大きく変わることを示唆している。システムエンジニアを目指す上で、AIツールが日常的に利用される現代において、こうした知見は非常に重要となるだろう。

この研究は、「AIが生成したコードは本当に質が悪いのか？」という問いに対し、一概に答えを出すことを避ける姿勢から出発している。具体的には、2024年12月から2025年7月にかけて、GitHub上の2,807のリポジトリから集められた37,623件のプルリクエスト（PR）を追跡している。プルリクエストとは、開発者が自分の変更をプロジェクトのメインコードに統合してもらうために提出する「変更提案」のようなもので、通常は他の開発者によるレビューを経て承認される。このうち33,596件はOpenAI Codex、Devin、GitHub Copilot、Cursor、Claude Codeという5つの商用AIエージェントによって作成され、残りの4,027件は同じリポジトリで同時期に人間によって作成されたものだ。研究チームは、これらのPRがマージ（メインコードに統合）された後、90日間にわたってその変化を追跡し、コードの品質や保守性に関する様々な側面を測定した。

研究が焦点を当てた主な測定項目は三つある。一つ目は「パッチレベルの品質」で、約9,000件のPRにおけるセキュリティ上の問題点（例えば、パスワードのハードコードや危険なeval関数の使用）や、保守性を示す指標（コメントの比率、コード行の長さ、複雑さなど）を分析した。二つ目は「マージ後の保守性」で、約26,000件のマージ済みPRについて、90日間の間にどれだけコードが変更されたか（チャーン）、そしてどれだけ元の状態に戻されたか（リバート率）を測定した。リバートとは、一度マージされたコードが、後にバグや問題が見つかったためにその変更が取り消されることを指す。三つ目は、PRに対する人間やボットによるレビューの数や、変更要求の数をカウントした。

最も注目すべき結果は、マージ後90日間のリバート率に関するものだ。人間が作成したPRのリバート率は平均で11.5%だった。これに対し、AIエージェント全体で見た場合ではなく、個々のAIエージェントごとに見ると、リバート率に大きな差が生じていることが明らかになった。OpenAI Codexが作成したPRのリバート率は6.1%と、人間のPRよりも顕著に低い数値を示した。これは、Codexが生成するコードが、マージ後に問題を引き起こしにくい傾向にあることを示唆している。一方で、Devinが作成したPRのリバート率は14.5%と、人間よりも高い数値だった。GitHub Copilotは12.5%、Cursorは11.4%、Claude Codeは10.5%であり、CursorとClaude Codeは人間のベースラインと統計的に大きな差がないという結果だった。この結果は、「AIが書いたコードは悪い」と一括りにしてしまうのは不適切であり、どのAIエージェントを使ったかによって品質が大きく異なることを強く示している。

また、各エージェントのPRのサンプルサイズ（分析対象となったPRの数）も重要であると研究は指摘している。OpenAI Codexの17,756件に対し、Claude Codeはわずか267件と、大きく異なる。サンプルサイズが小さい場合、そのパーセンテージだけを見て判断するのは危険だ。例えばClaude Codeのリバート率10.5%は、統計的には人間との間に検出可能な差があるとは言えない範囲に収まっている。つまり、数字の背後にあるデータの量と信頼性も合わせて考慮しなければ、誤った結論を導き出す可能性があるということだ。

セキュリティに関する分析では、全体としてAIエージェントが生成したコードは、人間が生成したコードと比較してセキュリティ上の問題（例えば、認証情報をコードに直接書き込むハードコードや、潜在的に危険なeval関数の使用）が少ない傾向にあったという。しかし、この効果は非常に大規模なPRに限られており、小さいPRでは人間との差はほとんど見られなかった。したがって、「AIコードは常に人間よりも安全」と単純に結論づけることはできない。

コードレビューの工数に関しても興味深い結果が出ている。GitHub Copilotが作成したPRは、最も多くの人間によるレビューや変更要求を受けていた。また、Claude Codeが作成したPRは、初回の人によるレビューを待つ時間が最も長く、平均で12.6時間かかっていた。これは、Claude Codeが生成するPRが、変更行数が平均495行と非常に多く、入れ子の深さも複雑であるため、レビューに時間がかかりやすいという傾向と一致している。これはコードの複雑さや規模が、レビュープロセスにおけるボトルネックとなる「ルーティング問題」を示唆している。

これらの知見は、システムエンジニアが自分の開発プロジェクトでAI生成コードを効果的に管理するために役立つ。研究は、自身のレポジトリでAIコードの品質を測定するための具体的な方法を提案している。まず、プルリクエストが作成された時点で、それがAIエージェント、人間、または両方の混合によって書かれたものかを明確にラベル付けすること。次に、一定期間（例えば90日間）のマージされたPRを対象に、リバート率、サイズを正規化した変更の頻度、初回レビューまでの待機時間、PRあたりの変更要求数という四つの指標を追跡すること。そして、これらの指標を「AI」と一括りにするのではなく、個々のAIエージェントごとに分けて分析することが重要だ。さらに、PRのサイズや、AIエージェントがコード生成に費やしたセッションの長さといった情報も記録することで、品質の違いが単なるルーティング（処理経路）の問題によるものなのかを判別できる。

AI生成コードのレビューを支援するツールも多数登場している。これらのツールを選ぶ際には、コードの出所情報やリポジトリの履歴を確認できるか、そして自身の開発環境で利用できるかどうかが重要な判断基準となる。

結論として、AI生成コードの品質やその保守性に関する議論は、「AIか人間か」という二項対立では十分に語れない。どのAIエージェントが、どれくらいの規模のコードを、どのようなコンテキストで生成したか、そしてそれがどれだけレビューを要するかといった多角的な視点から評価する必要がある。この研究は、AIをソフトウェア開発に導入する際に、単純な数字や一括りの評価に惑わされず、具体的なデータに基づいて個々の状況を詳細に分析することの重要性を強調している。