エージェントが取って代わるのはレビュアーであって、レビューではない

2026年6月、自動プログラム修復の研究で知られるソフトウェアエンジニアリング研究者のMartin Monperrusは、The End of Code Review: Coding Agents Supersede Human Inspection（コードレビューの終焉：coding agentが人間による検査に取って代わる）と題する論文を発表しました。その主張は、coding agentがある能力の閾値を越え、マージ前に人間が差分を確認することはもはや必須の品質ゲートではなくなった、そしてエージェントがコードを書き人間が必須のレビュアーであり続けるという一般的な構成は袋小路だ、というものです。¹

この論文は批判者が認めようとする以上に正しく、そして重要な一点で具体的に間違っています。エージェントはレビュアーに取って代わりました。差分を一行ずつ読んで欠陥を探す人間の仕事は、いまやエージェントの集団がより上手く、しかもすべてのコミットに対してこなす仕事になっています。しかしこの論文は、その役割をレビューそのものと混同しています。論文が示すエージェントのパイプラインを実際に運用してみると、人間の仕事は消えはしません。コードを検査することから、そのコードが満たすはずだった意図を所有することへと、移動するのです。 私はそのパイプラインを運用しています。レビュアーは死につつあります。レビューはスタックの上層へと移動しているのです。

私はこの論文を真剣に受け止めたいと思います。なぜなら、これに対するほとんどの反応はそうしないからです。反射的な返答は「でもエージェントはハルシネーションを起こす」というものですが、Monperrusはそれをすでに認めています。誠実に向き合うなら、まず彼が正しい点を認めるところから始まります。

要点

• Monperrusは、coding agentが人間によるコードレビューの必要性を終わらせたと主張します。レビューのあらゆる目的（欠陥検出、スタイル、セキュリティ、知識移転）はエージェントによってより良く、より安価に果たされ、人間のレビュー能力はエージェント駆動のスループットに合わせてスケールできないからです。¹
• 必須の人間承認チェックボックスが終わったという点で彼は正しく、また大きな差分をざっと流し読みする疲れた人間よりもエージェントの方が体系的な検査を上手くこなすという点でも正しいのです。
• 彼はこの点について素朴ではありません。論文はハルシネーション、prompt injection、セキュリティ盲点の相関を認めたうえで、高リスク・新規・規制対象・倫理的な変更には人間を残しています。¹
• 問題は、彼が残余の人間の役割を小さなエスカレーション集合として扱っている点です。本番環境では、それは荷重を支える中心です。エージェントは与えられた仕様に対して最適化しますが、その仕様を書き、所有することこそが、還元不可能な人間の営みなのです。
• レビュアーという役割は自動化されつつあります。ソフトウェアが目的にとって正しいかどうかについての判断としてのレビューは、エージェントが追随できない場所へと移動しているのです。

論文が正しい点

Monperrusは、チームがコードをレビューする理由についてのBacchelliとBirdの列挙を土台にしています。すなわち欠陥検出、スタイルと標準の徹底、知識移転、チームの状況把握であり、第5の次元としてセキュリティが加わります。¹² 彼のやり方は、それぞれの目的を取り上げ、エージェントの方が上手く果たすと論じることです。エージェントは疲労もタイムゾーンの遅延もなく、すべてのコミットを検査します。人間が場当たり的にパスを行うよりも体系的に脆弱性のクラスを列挙します。マージ時にアーキテクチャの要約と更新されたドキュメントを生成します。論文は閾値の議論を組み立てるためにSWE-benchの能力曲線を持ち出します。すなわち、ベンチマークが2023年に登場したときには最良のモデルが実際のGitHub issueの2パーセント未満しか解決できなかったところから、2025年後半にはトップのエージェントが70パーセントを超えるまでになったのです。¹³

この部分に異論はありません。なぜなら、私はそれが機能するのを日々目にしているからです。私の自律的なビルドループは、3つのレビュアーによるゲートを走らせています。コードがマージされる前に、別々のエージェントが正しさ、規約、セキュリティをチェックし、さらにもう一つのループが実装を独立したモデルに送って敵対的なパスを行わせます。これらのエージェントは実際の欠陥を捕まえ、しかも人間に時間があった変更だけでなく、すべての変更でそれを捕まえます。このサイトでこの記事に先行した2本の記事は、それぞれエージェントの評価器を通過しており、その評価器はルーブリックに照らして記事を採点し、私がその後修正しなければならなかった具体的な事実上の問題を指摘しました。エージェントが訓練されたレビュアーに匹敵する、実行可能で構造化されたレビュー出力を生み出すという論文の主張は、私にとって思弁ではありません。それは私の日常です。

スループットの議論もまた正しく、それは人々が過小評価している部分です。エージェントの支援を受けた開発者は、人間のレビュー能力が吸収できるよりも多くのpull requestを一日に生み出します。書き手が速く、レビュアーが人間であるとき、レビューキューが律速の制約となり、レビューは時間的プレッシャーの下で行われる形式へと劣化します。¹ エージェントが書き人間がゴム印を押すという素朴な取り決めが、本当の保証を何ら提供しないという点でMonperrusは正しいのです。コードが正しく見え、テストが通るからという理由で承認する人間は、レビューをしているのではありません。署名をしているのです。

彼が記述するパイプラインは、私が運用しているものそのもの

論文が人間によるレビューを置き換えるために提案するのは、「一つのモデルを信頼する」ことではありません。それはエージェントをループに組み込んだ検証パイプラインです。複数の独立したエージェント、理想的には異なるモデルが、非公式なコメントスレッドではなく、較正された構造化サインオフ（テストカバレッジ、セキュリティスキャン、JSONまたはSARIFとしての推論トレース。SARIFは静的解析結果のための標準的な交換形式です）を生み出し、エージェントには不確かなときに棄権するよう指示し、人間は難しいケースのために残されます。¹

それは、名前こそ違え、私が1年にわたって構築し、書いてきたアーキテクチャです。私は、エージェントのpull requestにはより小さなレビュー面が必要であること、自動レビューには一人の自信に満ちた裁定者ではなく異論が必要であること、そして構造化された証拠からなるレビューパケットが非公式な差分コメントに取って代わりつつあることを論じてきました。ですから、私はパイプラインに反対しているのではありません。私はその論拠を作る側に回ったのです。私が論じているのは、パイプラインが存在したあとに人間に何が残されるか、という点です。なぜなら、私はその答えの中で生きてきたのであり、それは論文が与える答えとは違うからです。

議論が破綻する場所：レビューは決して検査だけではなかった

Monperrusは高リスクの変更、新規のアーキテクチャ、規制対象のコードパス、倫理的判断のために人間を残し、それらをエスカレーションとして枠づけます。すなわち、エージェントが指摘したときに人間へと回される例外として。¹ この枠づけは、人間の役割を、それ以外は自動化されたラインに対するまれな割り込みのように聞こえさせます。

ラインを実際に走らせると、その逆を教えられます。エージェントは自らの目的を生み出しません。それは手渡された仕様に対して最適化するのであり、重要なあらゆる変更において、エージェントが何かを照らし合わせて確認できるようになる前に、誰かが正しさとは何を意味するのかを決めなければなりません。論文自体、議論のセクションでその境界を認めています。エージェントは技術的な品質指標に対して最適化するのであり、ある計測の変更がユーザーの妥当なプライバシー期待を侵害していること、あるいはあるランキングの微調整がバイアスを増幅していることに気づくよう確実には備わっていない、と。¹ それは周縁部における限界として提示されています。しかしそれは周縁部にあるのではありません。「この変更は我々が本当に望むものにとって正しいか」という問いは、自明でないあらゆるマージの中心に位置しており、それはまさに、仕様に較正されたエージェントがその仕様について問うことのできない問いなのです。

私はこの記事に先行して公開した2本の記事で、これを具体的に感じました。エージェントのレビュアーはそれらを採点し、それぞれの中で事実の行き過ぎを捕まえました。一方では検証されていない組織に関する主張、もう一方では誤って帰属された統計です。捕まえたのはエージェントでした。修正はそうではありませんでした。行き過ぎを誠実にどう正すか、どの情報源が実際にその主張を支えていたか、その文の誠実な版は何だったかを決めるには、ルーブリックが指摘できても解決できない、意図についての判断が必要でした。エージェントは何かが間違っていることを見つけました。正しさがどう見えるかを決めたのは人間でした。その労働の分担こそが移動であり、それは規制対象の周縁ケースではなく、日常的なコンテンツの上で起きたのです。

ですから人間はループから去りません。人間はループの終わりから始まりへと移動します。かつてレビューは最後のチェックポイント、完成したコードを検査する人間でした。エージェントのパイプラインでは検査は自動化され、還元不可能な人間の仕事は前方へと移動します。すなわち、エージェントが照らし合わせて検証できる真なるものを持てるよう意図を十分に正確に仕様化すること、そして出荷された結果が仕様を満たしながらも要点を外したときにその結果を所有することです。説明責任は、指標に対して最適化するシステムには委任できません。なぜなら説明責任とは、意図的に間違える覚悟を持ち、それに答える覚悟だからです。

主張の誠実な版

タイトルから挑発を取り除けば、擁護可能な主張は「コードレビューの終焉」よりも狭くなります。擁護可能な主張は、差分の検査者かつ必須の承認チェックボックスとしての人間の終焉です。その役割は本当に終わっており、心地よい儀式を守るためにそうでないふりをすることは、それ自体一つの不誠実です。エージェントのコードを実際には精査できないまま承認し、儀式として検査の席に人間を座らせ続けるチームは、自分たちが持っていると思い込んでいる保証をすでに失っています。

しかし「code review」は常に代理の言葉でした。それはチェックポイントを名指しつつ、判断を意味していました。この変更は、我々が必要とすることを、安全に、我々が責任を持てるやり方で行うか、という判断です。チェックポイントを自動化しても、判断は蒸発しません。それは入口における意図の仕様化と、出口における説明責任へと移動するのであり、エージェントの速度で動くチームにおいては、それは以前より重要でなくなるどころか、より重要になります。なぜなら、エージェントは仕様が言うことなら何でも、間違ったものまで含めて、忠実かつ迅速に作り上げるからです。書き手が速ければ速いほど、ボトルネックは何を求めるべきかを知ることになっていきます。レビュアーが取って代わられつつあるという点でMonperrusは正しいのです。レビューが終わりつつあるという点では間違っています。それはエージェントが占めることのできない唯一の席へと移動しているのです。

重要なポイント

エンジニアリングのリーダーへ： - 人間によるレビューを差分の検査として配置するのをやめましょう。エージェントの方が継続的により上手くそれをこなします。エージェントのコードに対する人間の承認チェックボックスは、保証の見せかけです。 - その人間の能力を、意図の仕様化と説明責任へと再配分しましょう。仕様に対して正しいことが事実に対して正しいかどうかを決める、レビューの部分です。

開発者ツールの作り手へ： - 論文が記述するアンサンブルレビューのパイプラインを構築しましょう。複数のモデル、較正された棄権、構造化されたサインオフです。レビュアー間の異論こそが信号なのです。 - ゲートだけでなく、パイプラインの前段を設計しましょう。最も価値の高い面は、人間が意図を、エージェントが照らし合わせて検証できる仕様へと変える場所です。

エンジニアへ： - あなたのレビュースキルは無価値になりつつあるのではありません。住所を変えつつあるのです。価値は、差分の中のバグを見つけることから、コードが何をするはずだったかを定義し、その結果を所有することへと移動します。

FAQ

この論文は、人間によるコードレビューが終わったということでしょうか。

一行ずつ差分を検査する人間、そして必須の承認者としての人間は終わりました。それは論文の最も強い論点です。エージェントの方が体系的な検査を、しかもすべてのコミットで上手くこなします。終わらないのは、コードレビューが代理していた判断、すなわち変更が実際の目的にとって正しいかどうかです。その判断は消えるのではなく、意図の仕様化と結果の所有へと移動するのです。

Monperrusは実際に何を主張しているのですか。

coding agentが、コードレビューの掲げるあらゆる目的（欠陥検出、スタイル、知識移転、セキュリティ）を、より低コストかつより高スループットでいまや果たしていること、そしてエージェントが書いたコードの必須のレビュアーとして人間を残すことは袋小路だということです。それは本当の保証を与えず、スケールできないからです。彼は、構造化されたサインオフを生み出すエージェントのアンサンブルを提案し、人間は高リスクと倫理的なケースのために残します。これは実証研究ではなく、ポジションペーパーです。¹

議論が最も弱いのはどこですか。

残余の人間の役割をまれなエスカレーションとして扱っている点です。実際には、人間の役割は自明でないあらゆる変更において荷重を支えています。なぜなら、エージェントは自らが作成も問いもできない仕様に対して最適化するからです。仕様を定義し、結果に答えることは、周縁ケースではなく中心的な仕事なのです。

チームはエージェントのpull requestに人間の承認ステップを残すべきですか。

検査の見せかけとしては残すべきではありません。人間が変更を本当に精査できないのなら、その承認はレビューではなく署名です。エージェントのアンサンブルに検査をさせつつ、人間の労力を上流の意図の正確な仕様化に、そして下流の出荷された結果の所有に投じる方が良いのです。

出典

• Martin Monperrus, “The End of Code Review: Coding Agents Supersede Human Inspection,” arXiv, 2026年6月11日：arxiv.org/abs/2606.13175。既存の能力の証拠を統合したポジションペーパー。BacchelliとBirdからコードレビューの目的を列挙し、SWE-benchの能力曲線を引用し、ハルシネーション、prompt injection、倫理的説明責任を含む限界を論じています。
• Alberto Bacchelli and Christian Bird, “Expectations, Outcomes, and Challenges of Modern Code Review,” ICSE 2013。論文が土台とするレビュー目的の分類法の実証的な出典：Microsoft Research
• Carlos E. Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?,” ICLR 2024。能力曲線の背後にあるベンチマーク（最良のモデルが登場時に1.96%を解決）：arxiv.org/abs/2310.06770
• 本番環境の経験からのエージェントレビューに関する関連記事：より小さなレビュー面、レビューには異論が必要、レビューパケット、そしてこの記事が運用について述べている、3つのレビュアーによるゲートがそのパイプラインである自律的なビルドループ。