AI・信頼性・評価

AIエージェントのPRはなぜ不採用になる？理由の内訳とマージ率

2026/8/18 （更新: 2026/10/11）

🤖 AIを使用して執筆

不採用の内訳を数えると、重複とテストが上に来る

サスカチュワン大学の Alam らは、AIDev の人気リポジトリ部分集合（AIDev-POP）から、5つのコーディングエージェントが書いた修正系PR 8,106件を取り出した。うち65.0%はマージされ、26.1%（2,113件） はマージされないままクローズされている。この2,113件から95%信頼水準・許容誤差5%で無作為抽出した326件を、延べ約100人時かけて人手で読み、12の不採用理由として体系化した¹。

最も多かったのは、同じ問題が別のPRで先に解決済みだったこと、つまり重複であり、22.1%（72件） を占める。次がテストケースの失敗の 18.1%（59件）、その次が修正そのものが誤っているか不完全だった 15.3%（50件） だった。ビルドの失敗は2.1%、デプロイの失敗は3.1%と比較的まれだ。原典はテスト失敗と不正確な修正を合わせて、ビルドやデプロイの失敗よりかなり多いと書き、検証の準備不足を指摘している¹。レビューが一度も付かないまま閉じたPRは、4.6%だった¹。

ただしテスト失敗の59件のうち50件は Codex のPRで、標本に入った Codex の91件では54.9%がテスト失敗だった。原典はこれを、Codex の不採用がレビューや優先度ではなく検証の側で起きていることの表れと読む¹。残る4エージェントでは、テスト失敗は235件中9件にとどまり、ビルドとデプロイの失敗を合わせた8件とほぼ同じ規模になる。一方で、修正が誤っているか不完全だったものは34件あり、重複の64件に次ぐ¹。手を入れる先は、実行基盤よりも、出す前の重複の管理と検証にある。

Abujadallah らは、Copilot・Devin・Cursor・Claude の非マージの修正系PR 306件を対象に、14の理由を4つの上位カテゴリへまとめた⁴。修正の妥当性が失われる（relevance）、実装が不正確、エージェント側の実行失敗（provider）、技術的な問題（CI）の4つである。最多は妥当性のカテゴリで 24.8%（76件）、その中身は放置による自動クローズが 17.3%（53件）、別のPRに置き換えられた superseded が 5.9%（18件） だった。著者らは、放置の53件を実装の問題としては数えず、時間がたつうちに修正の意味が薄れたものとしている。実装の不正確さは合わせて10.1%（31件）、技術的な問題は22件（7.2%）で、その大半は CI 失敗の21件（6.9%）だ。さらに306件のうち 151件（49.3%） は、不採用の明確な理由が読み取れず分類できていない。この研究では、これらのエージェントが提案した修正の 46.41% が不採用になっている。処方も具体的で、実装方針のヒントを与える、避けるべき制約を明示する、破壊的変更を持ち込まず CI を通すよう指示する、の3点だ。著者らはあわせて、修正すべき課題に優先順位をつけて重複や放置されるPRを作らないことを求めている。著者らによれば、重複や放置されるPRは人間のレビュー工数を浪費するだけでなく、トークン・計算資源・リクエスト上限といったエージェント側の資源も浪費する⁴。

「不採用＝エージェントの誤り」ではない

MSR 2026 に採択された Peralta らの研究は、逆向きの問いを立てた。不採用PRを「エージェントの失敗」として数えてよいのか、である⁵。クローズ済みのエージェントPR 11,048件から、人間のレビューが介在した9,799件を絞り込み、代表事例717件を人手で精査した。

不採用PRの内訳は次のとおりだ。不採用のうち、真にエージェント側の失敗といえるのは 35.7%。31.2% はワークフロー上の制約による不採用である。これは、方針や運用の都合により、コードの良し悪しとは別の理由で閉じられたPRを指す。そして残る 33.1% には、判断理由が観測できる形で残っていない。3件に1件は、なぜ落ちたのかがリポジトリの記録から読み取れないということだ。著者らはここから、不採用という結果はエージェントの誤りを「大幅に過大評価している」と述べ、マージ／不採用のラベルだけでは、レビューの相互作用を見ない限り性能評価として不完全だと結論する⁵。

マージ側も一様ではない。マージされたPR 364件のうち、レビュアーの明示的な関与を必要としたのは 15.4% にとどまる。ここでいう関与は、レビュアーのフィードバック、あるいはレビュアーによる直接のコミットを指す。逆に 79.1%（288件） は、レビュアーとのフィードバックループが一度も観測されないままマージされていた（残る5.5%は、痕跡が乏しく判定できなかったものだ）⁵。エージェント別の差も大きい。Codex は167件中165件、Cursor は33件中30件がこの「ループなし」に入る一方、Copilot は49件中11件にとどまる。Copilot と Devin はレビュアーが介在するワークフローに組み込まれることが多く、Codex と Cursor は最小限のやりとりでマージされる傾向にあった。同じ「マージ率」でも、その裏で人間がどれだけ手を入れたかは揃っていない。

並走するPRは、珍しくない

Xu らは、AIDev-pop の33,596件のPR／2,807リポジトリを対象に、「co-active（同時活動）」なPRペアを数えた⁶。co-active なPRペアとは、同じリポジトリで、オープンからクローズまでの期間が重なっている、エージェント作成PR同士の組を指す。

重なりは広く観測された。40.2% のリポジトリが厳密な時間的重なりを持つ co-active ペアを含み、1週間の窓まで緩めると 53.4%。PR単位で見ると、全エージェントPRの 79.4% が厳密重なりの co-active ペアの内側にあり、週次窓では 95.0% に達する⁶。エージェントに仕事を投げる現場では、複数の作業が並走しているのが常態だということだ。

そして重なりの大半は、同じエージェント同士だった。エージェントをまたぐ重なりは、co-active ペア 580,913 組のうち 2,896 組（0.50%）、リポジトリでは 122／2,807（約4.3%）にとどまる。同一エージェント同士が co-activity の 99.5% を占める。ただしマージ競合率は、エージェントをまたぐペアで 41.7%、同一エージェント内のペアで 19.8% と倍ほど開き、95%信頼区間は重ならない。しかもこれは git のテキスト競合だけを数えた下限で、ビルド競合や意味的な競合は含まない⁶。競合に関与したファイルの 84.4% はソースファイルで、依存関係のマニフェストやロックファイルは3.9%だった。競合の種類は 42%近くが modify/delete や add/add といった構造的なものだった。つまり、まれだが起きたときに重いのがクロスエージェントの衝突で、頻度で効くのは同一エージェントの自己衝突である。前節で Alam らが数えた「先に別のPRが解決済み」という不採用理由は、この時間的な重なりとは別の指標である¹。Xu らは重なったPRが同じ課題を解いていたかを測っておらず、重なりが重複による不採用を生んだとまでは言えない⁶。

マージ率は、比較指標として壊れている

ではエージェントをマージ率で並べればよいか。Pinna らのタスク層別の比較研究は、受理率を左右する支配的な要因がタスクの種類であることを示した。ドキュメント作業の受理率 82.1% に対し、新機能は 66.1%。この 16ポイントの差は、ほとんどのタスクでエージェント間の典型的な差を上回る（種別全体では、最高の chore 84.0% と最低の perf 55.4% で 29ポイント開く）²。原典はこの16ポイントの差を、構造のはっきりした仕事で通りやすいことの表れと読みつつ、ドキュメントのPRは審査の基準が緩いといった別の説明もありうると断っている²。しかも、すべてのタスク種別で最良の単一エージェントは存在しない。カテゴリ別に見ると、修正は Codex の 83.0% が首位で Cursor が80.4%、Devin は45.6%まで落ちる。ドキュメントは Claude Code の 92.3%、機能追加も Claude Code の 72.6% が上に来る。ただし Claude Code は全7,156件中139件しか標本がなく、原典自身が「標本が少ない」と断り、92.3%のセルには「20件未満」の印を付けている²。むしろ原典が実務向けに書いているのは逆向きの読みだ。エージェントの選択が効くのは修正とテストであり、ドキュメントではどのエージェントも79%超で差がほとんど無い²。

順位は、マージ率の算出方法を変えても動く。Mazloomzadeh らの生のマージ比率は、Devin の37.8%から Codex の90.0%まで開き、首位は人間PRの84〜86%を上回る³。この比率では Codex が首位だが、同じ論文がリポジトリの規模や複雑さを調整して推定した確率では Claude（84.3%）と首位が入れ替わる³。修正系PRだけに絞った Alam らの集計ではさらに動き、Codex 81.6% が1位、Claude Code は57.4%（66/115）で3位に落ちる¹。層別研究は、生のマージ率比較はタスク構成に大きく交絡しており、意味のある比較には層別が要ると結論している²。

Polytechnique Montréal のグループも同じ方向を、より大きな標本で裏づけている。489のPythonリポジトリ／220,612件のクローズ済みPRを分析対象とし、うちエージェントが書いたものは 9,428件だった。マージ率が高い（0.80以上、しばしば0.90超）タスク種別として挙がったのは、GitHub Actions のワークフロー、CI/ビルド、アセット管理、依存関係の更新、フック管理、ライセンス遵守、トークン管理である。誤字修正とドキュメントも高い側に入る³。低いのは「LLM統合」、モデル評価、JSONテンプレートだ。「関数実装」は原典の中で扱いが割れており、四半期別の3帯分類では中位帯（0.60〜0.80）に置かれる一方、正規化マージ比の比較と Finding 5 では低い側に挙げられている。原典の図7が印字する平滑化したマージ比は0.62で、中位帯の下端にあたる³。実際に投げられているタスクの構成は、ドキュメントが最大で、依存関係管理、テストが続く。加えて、エージェントPRの欠陥混入しやすさは人間のPRと同等かむしろ低く、差の多くは統計的に有意でなかった³。

三つの読みは、まだ噛み合っていない

ここまでの証拠は、一つの結論に収束していない。Alam らは不採用理由の上位に重複（22.1%）とテスト失敗（18.1%）を並べる¹。Abujadallah らは同じ AIDev の非マージPRを別の枠組みで符号化し、分類できた理由の最多を「妥当性の喪失」（24.8%、うち放置が17.3%）とし、そもそも不採用の理由が読み取れなかったものが49.3%あると数えた⁴。二本は大きく重なる母集団を見ながら、何を最頻とするかで割れている。「エージェントの出力を直せ」と読めるのは、Abujadallah らの側では実装の問題10.1%と技術的問題7.2%で、合わせて17.3%だ。誤った応答も含むエージェント側の実行失敗8.5%を足しても、25.8%にとどまる⁴。Peralta らは、不採用ラベルがエージェントの誤りを過大評価していると読む。これは、ワークフローを直せという読みになる⁵。そして Mazloomzadeh らは、首位のエージェントのマージ率は人間並みかそれ以上で、欠陥の混入しやすさも人間と同等かむしろ低いと言う³。層別研究は、タスク構成が全体の比較を誤らせうると言う²。これらは、そもそも何かを結論づけるのに慎重であれという読みである。

この不一致は、標本と符号化の違いからも来る。いずれも AIDev というデータセット族に依拠している。しかも Alam らと Abujadallah らの二本の関係は、「族」よりも近い。Abujadallah らが母集団とした非マージPR 1,497件は、Alam らが数えた非マージ2,113件から Codex 分を除いた集合と一致する（713+675+84+25=1,497。マージ済みを足した3,225が分母で46.41%）¹⁴。ただし標本は別々で、Alam らが読んだ326件には Codex のPRが91件入り、Abujadallah らは Codex を除いた1,497件から306件を引いた¹⁴。重なる母集団から別々に抽出・符号化した結果、最頻理由は「別PRで解決済み22.1%」と「放置17.3%」に割れた。理由の読み取れなさにも開きがある。Abujadallah らは49.3%に理由を付けられず、Alam らが説明なしのクローズとして数えたのは4.0%だった⁴¹。何を「失敗」と数えるかの基準が研究ごとに違うことは、一般論ではなくこの二本の間で実際に起きている。人手で読まれたPRも326件・306件・717件と数百件規模だ。

対象も偏っている。この偏りは一部の研究に限らない。Peralta らはスター500以上、Alam らと Abujadallah らが使う AIDev-POP はスター100以上、Mazloomzadeh らはスター100以上の Python リポジトリに絞っている⁵¹⁴³。本稿が引いた数字は、すべて「人気のあるOSSリポジトリ」から得たものである。Xu らの生の co-active ペアにいたっては、上位10リポジトリだけで91.4%を占める（著者らはリポジトリ単位とPR単位の両方で正規化して対処している）⁶。著者自身が挙げる限界も具体的で、Mazloomzadeh らは「スターの少ない、あるいは新しいリポジトリには一般化しないかもしれない」こと、オープンPRを除外していることを断っている³。出典の成熟度も揃っていない。本稿が引いた研究のうち、MSR の会議録に採録されたものは脚注に DOI を併記した。DOI の無いものは、本稿の時点では査読前のプレプリントだ。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。