AI・信頼性・評価

エージェントのPRはどこで止まるか。不採用の内訳を数える

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

🤖 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件） だった。ただしこの59件のうち50件は Codex のPRで、標本に入った Codex の91件では54.9%がテスト失敗だった。原典はこれを、Codex の不採用がレビューや優先度ではなく検証の側で起きていることの表れと読む²。残る4エージェントでは、テスト失敗は235件中9件にとどまり、ビルドとデプロイの失敗を合わせた8件とほぼ同じ規模になる。全体でも、ビルドの失敗は2.1%、デプロイの失敗は3.1%と比較的まれだ。手を入れる先は、実行基盤よりも、まず出す前の重複の管理にある。Codex のように、落ちるときはテストで落ちるエージェントでは、テストがそれに並ぶ。

Abujadallah らは、Copilot・Devin・Cursor・Claude の非マージの修正系PR 306件を対象に、14の理由を4つの上位カテゴリへまとめた¹。修正の妥当性が失われる（relevance）、実装が不正確、エージェント側の実行失敗（provider）、技術的な問題（CI）の4つである。最多は妥当性のカテゴリで 24.8%（76件）、その中身は放置による自動クローズが 17.3%（53件）、別のPRに置き換えられた superseded が 5.9%（18件） だった。実装の不正確さは合わせて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ポイント開く）³。しかも、すべてのタスク種別で最良の単一エージェントは存在しない。カテゴリ別に見ると、修正は 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 らの生のマージ比率では Codex（90.0%）が首位だが、同じ論文がリポジトリの規模や複雑さを調整して推定した確率では 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%に限られる。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 の無いものは、本稿の時点では査読前のプレプリントである。だから以下の実務指針は、「証明された法則」ではなく「損失の出やすい場所の地図」として読むのが正しい。

実務で何を見るか

重要なのは、上の不一致がどう決着しても変わらない部分がある点だ。テスト失敗も重複も投げるタスクの選び方も、エージェントの賢さを待たずに、こちらのディスパッチ側で今週変えられる。

• 投げる前に、重複を潰す。 リポジトリの40.2%が時間的に重なるエージェントPRのペアを抱えており、PR単位で見れば全体の79.4%が別のPRと同居している。その大半は同一エージェント同士だ⁶。不採用理由の最多も「別のPRで先に解決済み」（22.1%）で²、別の符号化でも superseded が第2のサブテーマに立つ¹。issue に担当を宣言（claim）させ、同一ファイル群を触る作業を同時に走らせない。手段はロックでもキューでも構わないが、並走の可視化をハーネス側に持たせる。クロスエージェントの競合率が41.7%と高い以上、複数種のエージェントを同じリポジトリに同時投入するなら、担当領域は分けたほうがいい⁶。
• CIが緑であることを、レビュー要求の前提条件にする。 テスト失敗は不採用理由の第2位（18.1%）で重複に次ぐが、その大半は Codex 1体から来ている²。Codex を含まない母集団を読んだ Abujadallah らでは、CI 失敗は306件中21件（6.9%）にとどまる¹。それでも、レビュアーが赤い CI を発見する運用は、人間の時間とエージェントの資源を両方捨てている。エージェントには「破壊的変更を持ち込まず CI に照らして検証してから出す」ところまでを指示に含める。Abujadallah らもこれを推奨している¹。ビルドの失敗は2.1%、デプロイの失敗は3.1%とまれなので、Codex を使うなら、優先度はテスト側に置いていい²。
• 勝てるタスク種別から投げる。 CI/ビルド設定、依存関係の更新、ワークフロー、ライセンスやトークンの管理、それにドキュメントと誤字修正は、マージ率0.80以上で通る⁴。一方でLLM統合とモデル評価は下位にある。「関数実装」の評価は原典内で割れており、内訳は脚注に記した。層別研究でも、ドキュメント82.1%に対し新機能66.1%で、この差はエージェント間の差より大きい³。エージェント導入の初手を新機能開発に置くのは、受理率の低い種別から始める選択にあたる。
• レビュアーを名指しで割り当てる。 不採用の33.1%には判断理由が記録に残っておらず、マージ側では79.1%が、人間のコメントは付いていても、レビュアーとのフィードバックループを一度も経ずに通っている⁵。放置による自動クローズは、別の研究では最大のサブテーマ（17.3%）に立つ¹。誰が見るかを決め、落とすなら理由を書く。これだけで、次のディスパッチに渡せる情報が生まれる。
• 生のマージ率でエージェントを順位づけない。 タスク構成による交絡が大きく、種別ごとに最良のエージェントは入れ替わる³。比較するなら、自分のリポジトリで実際に投げているタスク種別ごとに層別して測る。

エージェントPRの評価は、「このモデルは何%通るか」という問いから離れつつある。生のマージ比率は37.8%から90.0%まで開き、首位は人間の84〜86%を上回る。欠陥の出やすさは同等以下だ⁴。それでいて、不採用の3分の1には理由が残っておらず、マージの8割はレビューの往復を経ていない⁵。この組み合わせが意味するのは、指標が測っているのがエージェントとリポジトリ運用の噛み合わせだということだ。そして噛み合わせには、モデルの更新を待たずに、ディスパッチ側から手を入れられる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。