AI・信頼性・評価

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

2026/8/18

🤖 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件） だった。逆に、ビルドの失敗は2.1%、デプロイの失敗は3.1%と比較的まれだ。手を入れる先は、実行基盤よりも、出す前の重複の管理とテストにある。

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を作らないことを求めている——それは人間のレビュー工数だけでなく、トークン・計算資源・リクエスト上限といったエージェント側の資源の浪費でもあるからだ⁴。

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

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

出てきた比率が効いている。不採用のうち、真にエージェント側の失敗といえるのは 35.7%。31.2% はワークフロー上の制約——方針や運用の都合で、コードの良し悪しとは別の理由で閉じられたもの。そして残る 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 は最小限のやりとりでマージされる傾向にあった。同じ「マージ率」でも、その裏で人間がどれだけ手を入れたかは揃っていない。

重複には、構造的な原因がある

重複は偶然ではない。Xu らは、AIDev-pop の33,596件のPR／2,807リポジトリを対象に、「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が解決済み」という不採用理由は、この構造の帰結として読める²。

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

ではエージェントをマージ率で並べればよいか。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件しか標本がなく、原典自身が「標本が少ない」と断っている。むしろ原典が実務向けに書いているのは逆向きの読みだ。エージェントの選択が効くのは修正とテストであり、ドキュメントではどのエージェントも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テンプレート、そして「関数実装」だ。実際に投げられているタスクの構成は、ドキュメントが最大で、依存関係管理、テストが続く。加えて、エージェント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 というデータセット族に依拠している——それも「族」どころではない。Abujadallah らが母集団とした非マージPR 1,497件は、Alam らが数えた非マージ2,113件から Codex 分を除いた集合とぴたり一致する（713+675+84+25=1,497。マージ済みを足した3,225が分母で46.41%）²⁴。同じPR群を二組の研究者が別々に符号化して、最頻理由は「別PRで解決済み22.1%」と「放置17.3%」に割れた。何を「失敗」と数えるかの基準が研究ごとに違うことは、一般論ではなくこの二本の間で実際に起きている。人手で読まれたPRも326件・306件・717件と数百件規模だ。

対象も偏っている——そしてこれは一部の研究に限った話ではない。Peralta らはスター500以上、Alam らと Abujadallah らが使う AIDev-POP はスター100以上、Mazloomzadeh らはスター100以上の Python リポジトリに絞っている³²⁴¹。本稿が引いた数字は、ひとつ残らず「人気のあるOSSリポジトリ」の上に立つ。Xu らの生の co-active ペアにいたっては、上位10リポジトリだけで91.4%を占める（著者らはリポジトリ単位とPR単位の両方で正規化して対処している）⁵。著者自身が挙げる限界も具体的で、Mazloomzadeh らは「スターの少ない、あるいは新しいリポジトリには一般化しないかもしれない」こと、オープンPRを除外していることを断っている¹。だから以下の実務指針は、「証明された法則」ではなく「損失の出やすい場所の地図」として読むのが正しい。

実務で何を見るか

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

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

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

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