プルリクエストが届いた時には、テストはすでに実行済みで説明文も書き上がっています。すべてを一人でこなしたエージェントの仕事です。それでも誰かがそれに目を通さなければなりません。GitHub上では、その「誰か」はたいてい差分と向き合う一人の開発者であり、プロジェクトの他のメンバーはそのコードを目にすることすらありません。
ロチェスター工科大学のMaliha Noushin Raida氏とDaqing Hou氏は、25,264件のエージェント生成プルリクエストを、誰がレビューし誰がコミットしたかによって分類しました。対象となったリポジトリはいずれもスター数100以上で、使用されているエージェントは多くの開発者がすでに触れたことのあるGitHub Copilot、OpenAI Codex、Claude Codeであり、調査対象期間は2026年5月から7月までです。
レビューも修正も一人の開発者が担う
エージェント生成プルリクエストの大半は、一人の開発者の手を通過します。その開発者がエージェントのコードを読み、必要な修正を加え、マージするという流れです。この形態はデータセット中のプルリクエストの78.9%を占めます。
これは、多くのメンテナーがすでに実践しているやり方そのものです。エージェントに指示を出し、プルリクエストを待ち、開いて数行を修正し、リリースする。誰かがエージェントの成果をレビューしてそのまま採用するケースを数えると、一人によるチェックが全体のほぼ9割近くを占めます。
グループでのレビューは、プロジェクトの規模を問わずまれです。小規模チームは一人体制の運用に最も強く依存しており、大規模チームは作業をより分散させる傾向があるものの、それでも一人体制に取って代わるほどではありません。
ほとんどのリポジトリは四半期に1〜2件
リポジトリの中央値では、3か月間で開かれたエージェント生成プルリクエストは1〜2件でした。これが四半期全体の数字です。GitHub上のほとんどのプロジェクトでは、エージェントはたまに現れてはまた静かになり、その成果に触れるコントリビューターもごく一部に限られます。
多用しているのは、規模の小さいチームです。コントリビューターが1〜5人のリポジトリでは、エージェント生成プルリクエストの平均が1件あたり50.2件に上り、中規模・大規模チームを大きく上回りました。これは、エージェントを積極的に活用する一部の突出したケースによるものです。小規模プロジェクトを並べてみると、中央値に位置するものは他の多くのプロジェクトとさほど変わらない姿を見せます。
成果は増えても、レビュー担当は変わらず一人
Raida氏は、調査期間中にエージェント生成プルリクエストを30件以上こなした小規模チームに立ち返り、誰がレビューを担当していたかを確認しました。
「最も活発な小規模リポジトリ（つまり、エージェント生成プルリクエストが30件を超える小規模チーム)の間でさえ、その大半は依然として単独レビュアー方式のワークフローに従っていました」とRaida氏はHelp Net Securityに語っています。「これは、エージェントの活動が活発化しても、必ずしもレビュー体制の分散化にはつながらなかったことを示しています」
エージェントの働きは規模を拡大していく一方で、レビューを担う人数は一人のままです。
レビューが上限となる
問題はレビューにあります。コードレビューはすでに、多くの開発者にとって週の労働時間の大きな部分を占めており、エージェントが作成したプルリクエストもすべて、人間が読み、テストし、マージに値するかを判断しなければなりません。この作業は人間の手にゆだねられており、そこに使える時間には限りがあります。
その限界は数字にも表れています。Worklyticsによるプロフェッショナルの生産量のベンチマークに照らすと、サンプル中25件のプロジェクトが、現役の開発者がコードを出す速度と同じペースでエージェント生成プルリクエストを生み出していました。それ以外はすべてこのペースを下回っていました。
単独レビューもグループレビューも結末は同じ
一人で処理されたプルリクエストは、複数人で処理されたものとほぼ同じ割合でマージされています。
「マージ率(つまり、論文で説明されている期間内にマージされたプルリクエストの割合)は、二つの協働パターンの間で非常によく似ていました。単独レビュアー方式のプルリクエストでは81.2%、複数レビュアー・コミッター方式のプルリクエストでは80.3%でした」とRaida氏は述べています。
この二つのグループは異なる役割を担っています。Raida氏によれば、「単独レビュアー方式のワークフローで最も多く見られたプルリクエストの種類は機能追加関連であったのに対し、複数人によるワークフローで最も多かったのは修正関連のプルリクエストでした」。一人で運用するメンテナーは、エージェントを新機能の開発に向けます。一方、修正作業には複数人が集まってくるのです。
これらの数値は調査期間内でのマージ受け入れ状況を対象としたものであり、それ以上のことは扱っていません。リバート(取り消し)や後続のバグ修正、マージされたエージェント製コードが時間の経過とともにどれだけ維持されるかといった点は、このデータセットの範囲外です。
一人で切り盛りするレビュー体制
この傾向は、ある静かな午後に自分自身のCopilotの成果をマージした経験のある人なら誰もが心当たりのある、ごくありふれたやり方であり、負荷がかかっても崩れることはありません。数十件のエージェント生成プルリクエストをこなす小規模チームでも、一貫して一人の人間がループの中心にとどまっていました。この上限に対して、それが崩れる地点を見極められるほど強く押し込んだプロジェクトは、まだごくわずかしかありません。
翻訳元: https://www.helpnetsecurity.com/2026/07/22/users-of-ai-coding-agents/
