Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study
この実証的研究は、5つのAIコーディングエージェントによる8,000件以上の修正関連プルリクエストを分析することで、ビルド失敗は稀である一方で、テストケースの失敗と重複したイシュー解決がマージにおける主要な障壁であることを特定しており、それによって現在のAIエージェントにおける主要な限界と、ソフトウェア保守における人間とAIの協調を向上させるための方向性を浮き彫りにしている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
あるソフトウェアプロジェクトを、巨大で賑やかな建設現場に例えてみましょう。「メンテナー（保守担当者）」は、どの設計図を実際に形にし、どれをゴミ箱に捨てるかを決定する現場監督です。最近、彼らは「AIエージェント（ロボット助手）」を雇い始めました。この助手たちは、壊れた部分を修理するための計画書（「プルリクエスト」または「PR」と呼ばれます）を作成します。
この論文は、次のような問いを投げかける探偵の報告書のようなものです。「これらロボット助手たちが作成した修理計画は、どのくらいの頻度で承認されているのか？ そして、承認されなかった場合、その理由は何なのか？」
以下に、その調査結果を分かりやすい比喩を用いて解説します。
1. 全体像：成功率
研究者たちは、5種類の異なるタイプのAIロボット（OpenAI Codex、GitHub Copilot、Devin、Cursor、Claude Code）によって提出された8,000件以上の修理計画を調査しました。
- 良いニュース： 約**65%**のケースで、現場監督たちは「よし、これを実行せよ！」と言い、修正をマージ（採用）しました。ロボットたちはまずまずの仕事をしています。
- 悪いニュース： 約**26%**のケースでは、監督たちは「ノー」と言い、計画を構築することなく終了させました。また、**9%**はまだ検討中のまま待機室に留まっています。
- ロボットによる違い： すべてのロボットが同じ能力を持っているわけではありません。
- OpenAI Codexは優等生です。**81%**という高い確率で承認されました。
- Devinは最も苦戦しました。承認率はわずか**43%**であり、つまり、その修理計画の半分以上が拒絶されたことを意味します。
2. 「なぜ」：なぜ計画は拒絶されるのか？
研究者たちは、326件の拒絶された計画を深く掘り下げ、なぜ失敗したのかという正確な理由を突き止めました。彼らは12の異なる理由を見つけ出し、それらを3つの主要なカテゴリーに分類しました。
A. 「間違った修正」の問題（技術的な問題）
時として、ロボットは漏水を直そうとして、実際にはパイプ自体を壊してしまうことがあります。
- テストの失敗（最も一般的な技術的理由）： ロボット自身のロジックでは合格していても、プロジェクトの厳格な安全テストには失敗しました。これは、シェフが料理を作ったものの、見た目は立派だが、保健所の検査官（テストスイート）が試食したらひどい味だった、というような状況です。
- 不完全または誤った修正： ロボットは問題の原因を推測しましたが、解決すべき対象を間違えていたか、あるいは問題の半分しか解決していませんでした。
- ビルド／デプロイの失敗： 極めて稀ですが、修正内容があまりに壊れていたため、建物（プログラム）を組み立てることすらできなかった（コンパイルできなかった、あるいは実行できなかった）ケースです。
B. 「タイミング」の問題（プロセス上の問題）
修正内容は実は正しいのですが、タイミングが合わないことがあります。
- 誰かが先にやってしまった（拒絶の第1位）： これは**22%**のケースで見られました。ロボットは壊れた窓を直そうと懸命に働いていましたが、人間（あるいは別のロボット）がその5分前にすでに窓を直していました。ロボットの計画は、単に重複していたために拒絶されたのです。
- 活動停止： ロボットが計画を提出した後、音信不通になりました。監督たちは返答を待つのに飽きてしまい、チケットをクローズしてしまいました。
- 優先度の低さ： ロボットが修正しようとした問題は、もはや重要ではなくなっていたか、あるいはプロジェクトマネージャーが無視することに決めた問題でした。
C. 「コミュニケーションの断絶」の問題
- レビューなし： ロボットはレビューを求めましたが、人間の監督者は一度も目を通しませんでした。
- 説明のない拒絶： 計画は理由の説明もなく終了させられ、ロボット（および研究者）はなぜ失敗したのかについて暗闇に取り残されました。
3. 「スピード」の要因
研究者たちは、計画が承認されるまでにどれくらいの時間がかかるかも測定しました。
- 迅速なマージ： 多くの優れた修正は、非常に素早く承認されました。
- 遅いマージ： 中には時間がかかるものもありました。興味深いことに、「優等生」であるOpenAI Codexは、最も一貫しており、かつ迅速な承認時間を記録しましたが、他のロボットは待ち時間が非常に予測困難でした。
まとめ
この論文は、**「コードを書けることだけでは不十分である」**と結論付けています。
現実の世界で修理計画を承認してもらうためには、ロボットには以下のことが求められます：
- 単に見栄えが良いだけでなく、厳格な安全テストに合格すること。
- 人間や他のロボットがすでに行った作業と重複しないこと。
- 人間の監督との対話に積極的に関わり続けること。
現在、最大の障壁は、ロボットがコードを書けないことではなく、テストに失敗するか、あるいは他の人々が同じ問題を修正する際に先を越されてしまうことです。この研究は、AIが真に信頼できる「バーチャルなチームメイト」になるためには、単にコードを書くだくだけでなく、プロジェクトの文脈（コンテキスト）やワークフローのタイミングをより深く理解する必要があると示唆しています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。