マーティン・モンペルス KTH 王立工科大学 ストックホルム、スウェーデン monperrus@kth.se
要旨 ― コードレビューは、1976年にフェイガンがコードインスペクションを体系化して以来、ソフトウェア開発における主要な品質ゲートであり続けてきた。半世紀にわたり、マージ前に同僚が変更点を精査しコメントすることは、あらゆる規模の組織で根幹をなすプラクティスであった。コーディングエージェントとは、大規模言語モデル（LLM）を基盤とし、ソフトウェアの読解、作成、テスト、修正を自律的に行えるシステムである。我々は、コーディングエージェントが能力の閾値を超え、従来の人間によるコードレビューがソフトウェア品質パイプラインにおいて必須の構成要素ではなくなったと主張する。我々の論拠は二つの主張に基づく。第一に、コードレビューが掲げるすべての目標は、人間のレビュアーよりも低コストかつ高スループットでエージェントによって達成可能である。第二に、エージェントがコードを書き、人間が必須のレビュアーであり続けるという素朴な統合は袋小路である。なぜなら、それは意味のある保証を提供せず、AI支援によるスループットにも対応できないからである。
I. はじめに
コードレビューは、現代のソフトウェア開発における主要な人間による品質ゲートである。バッケリとバードがマイクロソフトでの実践を調査し[1]、サドウスキーらがグーグルでの実態を記録して以来[2]、コードレビューは四つの重複する目標を果たすものと理解されてきた。それは、本番稼働前に欠陥を発見すること、スタイルと規約を強制すること、チームメンバー間で知識を移転すること、そして進化するコードベースに対する共通認識を構築することである。真剣なソフトウェアチームでこれを省略するチームはない。
しかし、コードレビューには過小評価されがちな多大なコストが伴う。大規模組織の開発者は、労働時間の10％から15％を他者のコードの読解とコメントに費やしている[2]。プルリクエストを提出してから実行可能なフィードバックを受け取るまでのレビュー待ち時間は、日常的に24時間を超え、場合によっては数日に及ぶこともあり、継続的デリバリーに構造的な遅延をもたらしている[3]。時間的コスト以外にも、レビューは社会的な摩擦を生み出す。すなわち、口調のエスカレーション、年功序列バイアス、そして初回貢献者が批判的なフィードバックを受けてプロジェクトを放棄するという十分に立証された傾向などである[4], [5]。
このような状況下に、コーディングエージェントが登場した。Claude Code、Codex、GitHub CopilotといったLLMベースのシステムは、現在では人間の指示なしにファイルの読み取りと変更、テストスイートの実行、コンパイラ出力の解釈、障害の反復的な修復を行うことができる[6]-[9]。SWE-bench（人気のあるPythonライブラリから抽出された、実際の未修正のGitHub Issueのベンチマーク）において、最先端のエージェントはタスクの80％以上をエンドツーエンドで解決する[10]。LLMベースのコードレビューに関する研究では、エージェントが訓練された人間のレビュアーに匹敵する品質でインラインの欠陥コメントを生成できることが示されている[11], [12]。
本論文では、我々は強い主張を行う。すなわち、コーディングエージェントは人間によるコードレビューが冗長となり、エージェント駆動の検証に置き換えられるべき能力の閾値に達した、というものである。我々は新たな実証研究を提示するのではなく、既存の能力に関する証拠を統合し、ソフトウェアエンジニアリングの実践、ツール、研究に対するインプリケーションを列挙する。具体的には、エージェントがレビューの確立された目標を満たせること、エージェントがコードを書くが人間が必須のレビュアーであり続ける中間モデルは不安定であること、そして人間による必須検査の経済的合理性は、日常的な変更に対してはすでにマイナスに転じていることを論じる。
要約すると、我々の貢献は以下の通りである。
コードレビューのすべての掲げられた目標（欠陥検出、スタイル強制、知識移転、チームの共通認識）が、人間のレビュアーよりも低コストかつ高スループットでコーディングエージェントによって達成可能であることの実証。
AIコード生成と必須の人間によるレビューの組み合わせは安定した終着点ではないという論拠。それは保証の外観を作り出す一方で、レビュー能力を次の配信ボトルネックに変えてしまう。
必須の人間による検査の費用対効果がすでに逆転していることを示す費用便益分析。エージェントレビューは即時的で一貫性があり監査可能である一方、エージェントの能力が成長するにつれて人間によるレビューの限界的な欠陥検出価値は縮小する。
II. 背景
A. コードレビュー：歴史と実践
正式な工学分野としてのコードレビューは、1976年にIBMでのコードインスペクションに関するフェイガンの論文に端を発する[13]。フェイガンは、計画、概要、準備、インスペクション、修正、フォローアップという構造化された多段階プロセスを提案した。このプロセスは高コストであり、プロジェクト全体の工数の最大3％を必要とするとされた。
現代のコードレビューの有効性に関する実証的な記録は、その普遍的な採用が示唆するものよりも微妙である。バッケリとバードは、欠陥検出が主な動機ではあるものの、レビュアーが最も確実に提供するものではないことを発見した。コメントコーパスを支配するのは、スタイル修正、軽微な改善、意図に関する質問である[1]。チェルウォンカらは、「マイクロソフトでのコードレビューは『バグを見つけていない』」という鋭い結論に達した。深いロジックレベルの欠陥を捕捉するという意味では、その主な価値は知識移転と保守性の向上にある[14]。知識移転と社会化は、レビュー相互作用の価値ある成果として一貫して研究で浮かび上がっている[1], [4]。
図1. 本論文の論証マップ。レビューの目標は三つの主張を支え、それが結論に至り、実践とツールに関する四つのインプリケーションを伴う。
B. 自動コードレビュー
コードレビューを自動化する取り組みは、大規模言語モデルよりも前から存在する。初期のアプローチは、パターンマッチング、ルールベースのチェッカー、そして変更がコメントを引き付けるかどうか、またどのようなコメントがつくかを予測するためにレビューコメントのコーパスで訓練された機械学習分類器に依存していた。これらのシステムは、コメント予測、変更ファイルの優先順位付け、特定の欠陥クラスの検出といった、個々のレビュー活動を個別に自動化した。
LLM時代は新たな可能性を開いた。CodeReviewer [11]は、プルリクエストの差分と関連するレビューコメントの大規模コーパスでモデルを事前学習し、コメント生成、コード改善予測、重大度分類において競争力のあるパフォーマンスを達成する。LLaMA-Reviewer [15]は、パラメータ効率の良いファインチューニングを適用して汎用LLMをレビューコメント生成タスクに適応させ、強力なレビューパフォーマンスがファインチューニングによって達成可能であることを示している。Tufanoら[16]は、差分から改善されたパッチまでのエンドツーエンドのパイプラインを構築し、モデルがレビューコメントを生成し修正コードを生成できることを示し、レビューと修正のサイクルにおける往復を一回分削減した。PornprasitとTantithamthavornは、これらおよび関連システムを産業環境で評価し、欠陥タイプ全体にわたって意味のあるカバレッジを見出している[12]。Tangらは、専門化されたコミュニケーションエージェントが協調してコードレビューを実行するマルチエージェントシステムであるCodeAgent [17]を導入し、自動化の境界を単一モデルのコメント生成から協調エージェントワークフローへと押し進めている。これらのシステムに共通するのは、人間が統治するレビューワークフロー内の活動を自動化することに焦点を当てている点である。つまり、全体的なレビューゲートの必要性を問うことなく、特定のステップの効率を改善しているのである。
我々の知る限り、本論文はコーディングエージェントによる必須の人間のコードレビューの完全な置き換えを主張し、その結果生じるワークフロー、ツール、研究への影響を議論した最初のものである。
C. コーディングエージェント
コーディングエージェントとは、大規模言語モデル（LLM）がエージェントループに組み込まれたシステムである。モデルはファイルの読み書き、シェルコマンドの実行、テストの実行、ドキュメントの照会のためのツールを呼び出し、目標が達成されるか停止条件が満たされるまで反復することができる。LLMは言語理解、コード合成、文脈推論を提供し、ツールループはソフトウェア成果物の実際の状態とその実行に対する基礎的な裏付けを提供する。
代表的なエージェントには、GPTモデルライン上に構築された対話型アシスタントであるOpenAI Codex [18]、開発者のターミナルで直接動作するエージェント型コーディングアシスタントであるClaude Code [19]、リポジトリ規模のソフトウェアエンジニアリングタスクに最適化されたエージェント・コンピュータインターフェースを導入したSWE-agent [6]、自律的にコードベースをナビゲートし修正を展開する商用システムであるDevin [7]、エージェント機能をプルリクエストワークフローに直接統合するGitHub Copilot [9]などがある。
III. エージェント能力の証拠
コーディングエージェントが人間のコードレビューを置き換えられるという主張を裏付けるために、我々は三つの次元にわたるエージェント能力の証拠を調査する。ソフトウェアエンジニアリングタスクにおけるベンチマークパフォーマンス、レビュー固有の能力、そして展開されたツールによる開発者の生産性である。
A. ベンチマークパフォーマンス
エージェント能力の最も直接的な証拠は、人気のあるオープンソースのPythonプロジェクトから抽出された実際の未修正の問題をシステムが解決できるかどうかを評価するベンチマークであるSWE-benchから得られる[10]。合成コーディング課題とは異なり、SWE-benchのタスクは、Issueの説明を理解し、複数ファイルのリポジトリをナビゲートし、正しいファイルを修正し、プロジェクトの既存のテストスイートをパスするパッチを生成することを要求する。初期の結果は厳しいものだった。検索ベースのコンテキスト選択を用いたGPT-4はタスクの約1.7%を解決した。SWE-agentは、ファイルシステムとシェルとのモデルの相互作用を構造化するエージェント・コンピュータインターフェースを導入することで、この数字を約12.5%に引き上げた[6]。2024年後半までに、SWE-bench Verified（検証済みの正しい解決策を持つキュレーションされたサブセット）で最高のパフォーマンスを発揮するシステムは50%を超えた。2025年後半までに、公開リーダーボードのトップエージェントはタスクの70%以上を解決した[20]。約2年で2%未満から70%以上への改善軌道は、自動化されたソフトウェアエンジニアリングツールの歴史において前例がない。
関連する証拠は隣接するタスクからも得られる。例えば、Xiaらは、LLMベースの修復アプローチがGenProgのような以前の生成・検証システムを大幅に上回り、手動で指定されたテストケースや修正テンプレートを必要とせずに、はるかに多くのベンチマークバグを修正することを示している[21], [22]。競技プログラミングのレベルでは、AlphaCodeはCodeforcesコンテストにおいて人間参加者の上位54%以内にランクインした[23]。これは、LLMが自明でないアルゴリズム問題について推論できることを立証している。
B. レビュー固有の能力
一般的なソフトウェアエンジニアリングを超えて、コードレビューに必要な能力に特に対処するいくつかの研究がある。PornprasitとTantithamthavornは、産業環境におけるLLMベースの自動レビューを評価し、エージェントが人間のレビュアーが対象とするのと同じ欠陥カテゴリ（正確性エラー、セキュリティ弱点、パフォーマンス非効率性、スタイル違反）を検出することを発見した[12]。Liらは、CodeReviewerが評価セットの大部分において、訓練された人間のレビュアーと少なくとも同等の品質で実行可能なインラインコメントを生成することを示している[11]。
エージェントは、人間のレビュアーが構造的に太刀打ちできない能力をもたらす。人間のレビュアーは差分を読むが、エージェントは同時にファイル全体、完全なテストスイート、触れられたすべての関数のGit履歴、プロジェクトのドキュメントをコンテキストに保持できる。人間のレビュアーは問題を特定し、コメントで説明できるが、エージェントは問題を特定し、修正を生成し、適用し、テストを実行し、人間のスケジューリングなしにレビューループを閉じることができる。人間のレビュアーにはカレンダー、タイムゾーン、限られた注意力があるが、エージェントは継続的に動作し、月曜の朝のスプリントと同じ精査を日曜の午前3時にも適用する。これらは、ソフトウェア開発の規模と速度が増大するにつれて複利的に効いてくる構造的優位性である。
IV. コードレビューの終焉：論証
A. 主張1：コードレビューのすべての目標は、エージェントによって低コストかつ高スループットで達成可能である。
バッケリとバードは、コードレビューの四つの主要な目標を特定している。欠陥検出、スタイルと標準の強制、知識移転、そしてチームの共通認識である[1]。我々は、現代のコーディングエージェントが各目標を少なくとも人間のレビュアーと同等に、そしていくつかの次元では著しく良好に満たすと主張する。
欠陥検出。人間のレビュアーは表面的な問題を特定するのには効果的だが、深い論理バグを捕捉するのには信頼性が低い[14]。対照的に、大規模言語モデルを搭載したエージェントは、網羅的なデータフロー推論を実行し、完全なテストスイートを相互参照し、数百万のオープンソースリポジトリから学習したパターンを適用することができる。最近の研究では、LLMベースのレビューシステムが、疲労やタイムゾーンの制約なしにすべてのコミットで動作しながら、訓練された人間のレビュアーと同等の品質の実行可能な欠陥レポートを生成することが示されている[11], [12]。
スタイルと標準の強制。リンター、フォーマッター、型チェッカーは、長年にわたり構文的および文体的な懸念事項を自動的に処理してきた。エージェントはこの能力を意味的なスタイルにまで拡張する。命名の一貫性、慣用的なAPI使用法、ドキュメント規約などはすべて、LLMベースの書き換えを通じて強制することができ、レビュアーのコメントのカテゴリ全体を排除する。
セキュリティ。セキュリティレビューは、まさに人間の注意力が最も過負荷となり、最も重大な結果をもたらす領域である。Pearceらは、GitHub CopilotがCommon Weakness Enumeration（CWE）違反を無視できない割合で導入することを示している[24]。しかし、同じ生成能力を検出に向けることで、エージェントは場当たり的なレビューを行う開発者よりもはるかに体系的に脆弱性クラスを列挙することができる[25]。AIベースのセキュリティスキャナーは、標準的な脆弱性ベンチマークにおいて多くの手動レビュアーをすでに上回っている[26]。
知識移転。エージェントは、オンデマンドの説明、アーキテクチャの要約、更新されたドキュメントをマージ時に能動的に生成できる。これは、忙しい同僚の付随的なコメントよりも、知識を伝播するための信頼性が高くスケーラブルなメカニズムである。
B. 主張2：素朴な統合（AIコーディングと人間のレビュー）は袋小路である。
AIコーディングツールの台頭に対するほとんどの組織の最初の反応は次の通りである。エージェントがコードを書き、人間がそれをレビューする。この取り決めは保守的で安全だと感じられる。我々は、これが二つの独立した根拠で失敗すると主張する。
人間のレビューは真の保証を提供しない。コードレビューの伝統的な根拠は、「人間の開発者がコードを書き、人間のレビュアーが独立したチェックを提供する」という暗黙の前提に基づいている。エージェントがコードを生成すると、この前提は崩壊する。大規模言語モデルは、数百行の尤もらしく内部的に一貫性のあるコードを生成できるが、そのコードには微妙な意味的エラーが含まれている可能性がある。これは、完全なテストスイートを実行するか、エージェントだけが体系的に実行できる網羅的なデータフロー分析を実行しなければ不可視のエラーである。画面上で差分を読んでいる人間のレビュアーは、AI生成コードが含む可能性のあるエラーを捕捉する立場に乏しい。実際には、エージェントが生成したコードのレビューは形骸化する。コードが正しく見えるから、テストがパスするから、そして真の精査の認知コストが法外だからという理由で、人間は承認する[14]。レビューが提供することになっている保証は幻影である。
人間のレビューはスケールしない。AIコーディングツールは開発者のスループットを向上させる。エージェントの支援を受けた開発者は、支援を受けない開発者よりも1日あたり多くのコミット、多くのプルリクエスト、多くの変更行を生成する[27]。人間のレビュー能力はスケールせず、その結果、AIコーディングがもたらす生産性向上に比例して成長するボトルネックが生じる。AIコーディングツールを展開しながら人間ゲートのレビューを維持する組織は、レビューキューが配信パイプラインの拘束条件になることに気付くだろう。エージェントの記述速度が速ければ速いほど、キューは長くなり、レビューは時間的圧力の下で行われる形式的なものへと劣化する。この文脈で人間のレビューを維持することは品質を保つことにはならない。それはAIコーディングの生産性利益と真のレビューの品質利益の両方を捨て去ることになる。
論理的に一貫したステップは、ループを閉じることである。すなわち、独立したエージェントがエージェント生成コードをレビューし、人間はエージェントが不確実性をフラグ付けした場合、または変更が明示的なリスク閾値を超えた場合にのみ介入する。
C. 主張3：費用対効果の計算は逆転した。
コードレビューは測定可能なコストを課す。大規模組織の開発者は労働時間の10～15％をコードレビューに費やし[2]、レビューの待ち時間は継続的デリバリーパイプラインに遅延をもたらす[3], [28]。これらのコストは、レビューが捕捉した欠陥によって歴史的に正当化されてきた。エージェントのカバレッジが成長するにつれて、その正当性は弱まる。
人間のレビューコメントの限界的な価値を考えてみよう。エージェントがすべてのファイル、すべてのテスト、すべてのコミットを増大する再現率でスキャンするにつれて、エージェントレビューを逃れるが人間のレビュアーによって捕捉されるであろう欠陥のセットは縮小する。同時に、時間、待ち時間、社会的摩擦における人間のレビューのコスト[4], [5]は一定のままである。人間のレビューの限界利益が限界費用をもはや正当化しないクロスオーバーポイントは、すでに到達されている。エージェントレビューは即時的で、決定論的であり、監査可能である。構造化されたレポートを生成し、非公式なスレッドコメントではなく、パイプラインの任意の時点で再実行できる。継続的デリバリーの競争優位性[28]は、レビューの待ち時間をソフトウェアチームにとってますます許容できない課税とし、エージェントはそれを完全に排除する。
V. インプリケーション
A. ソフトウェアエンジニアリング実践への影響
マージワークフローの再設計。エージェントベースのレビューの最も直接的な影響は、プルリクエストワークフローの再構築である。現在のモデルでは、開発者はプルリクエストを開き、同僚がレビューする時間を見つけるのを時には数日間待つ。我々は、このゲートステップを、すべてのマージ候補に対して自動的に実行されるエージェントインザループ検証パイプラインに置き換えることを提案する。マージゲートは、人間の承認チェックボックスから、構造化されたエージェントの承認へと移行する。テストカバレッジの閾値、セキュリティスキャンの結果、スタイル準拠レポート、推論トレースはすべて、人間のスケジューリングなしに生成される。人間の承認が排除されるわけではない。それは、高リスクの変更、新規アーキテクチャの選択、指名された人間が法的説明責任を負わなければならない規制対象のコードパスなど、真にそれを必要とする決定のために留保される。大多数のコミット（漸進的な機能、バグ修正、依存関係の更新、リファクタリング）にとっては、エージェントの承認で十分であり、それ以上を要求することは無駄である。
チーム構造と役割。エージェントレビューが成熟するにつれて、プロのコードレビュアーの役割は現在の形では縮小するだろう。開発者が同期的なレビューミーティングや非同期的なコメントスレッドに費やす時間は減少する。これは開発者の専門知識が重要でなくなることを意味するものではない。それは専門知識の方向性が変わることを意味する。開発者はますます、仕様策定者およびオーケストレーターになる。彼らはエージェントがそれに基づいて行動できるように要件を十分に正確に明確化し、エージェントが生成した成果物をより高い抽象度で評価し、エージェントの推論が不確実であるかリスクが高い場合に介入する。職人技は、行単位の検査からシステムレベルの判断へと移行する。これは多くの開発者が歓迎する変化である。なぜなら、一貫した調査結果として、コードレビューは仕事の中で最も楽しくない部分の一つであることが示されているからだ[2]。
オンボーディングと知識移転。コードレビューの最も引用される利点の一つは、チームメンバー間で知識を伝播する役割である[1]。エージェントは、マージ時に、急いでいるシニアエンジニアが慌ただしいコメントで提供するよりも豊富な、コンテキストにキー付けされたオンデマンドの説明を生成できる。真のリスクは、暗黙知とチーム文化が伝播する非公式な双方向の会話の減少である。組織は、この結束を維持するためにペアプログラミングや構造化されたメンターシップなどの補完的なメカニズムを必要とするだろう。
オープンソースのダイナミクス。オープンソースプロジェクトでは、メンテナの帯域幅が構造的なボトルネックである。貢献はレビューを何週間も待ち、パッチが届かなくなるからではなく、メンテナがレビュー能力を使い果たすためにプロジェクトは放棄される。エージェントレビューはこのボトルネックに直接対処し、フィードバックループを圧縮し、初回貢献者にとっての障壁を下げる。
B. ツールへの影響
CI/CD統合。エージェントレビューは、継続的インテグレーションパイプラインの自然な拡張である。ビルドシステムとテストランナーがすべてのプッシュで自動的に実行されるのと同様に、レビューエージェントは同じポイントで、機能ブランチへのすべてのコミットで、またはマージ前の必須ゲートとしてトリガーできる。これはレビューを非同期の社会的活動から、コンパイルに類似した第一級のエンジニアリングチェックへと再構成する。それは実行され、報告し、パスするかブロックするかのいずれかである[28]。エージェントは、CIダッシュボード、セキュリティプラットフォーム、分析システムが人間の仲介なしに消費できる構造化レポート（JSON、SARIF）を生成する。レビュー履歴は、劣化しやすい非公式なコメントのスレッドではなく、バージョン管理されクエリ可能な工学的成果物となる。
IDEとエディタの統合。エージェントが可能にする待ち時間の削減は、マージパイプラインに限定されない。開発者のエディタに組み込まれたエージェントは、コミット前に変更をレビューできる。開発者が書くにつれて、エージェントはコンテキストを読み取り、問題を特定し、インラインで表示する。これにより、フィードバックループは数時間または数日から数秒に短縮される。インタラクションモデルも変わる。レビューコメントのリストを読み、それぞれを受け入れるか拒否するかを決定する代わりに、開発者は自然言語でエージェントと会話し、説明を求め、代替実装を要求し、トレードオフを交渉する。これは伝統的なレビューよりもペアプログラミングに近く、同期的なペアリングを大規模に維持することを困難にする社会的オーバーヘッドなしに動作する。
バージョン管理プラットフォーム。エージェントレビューが第一級の活動として機能するためには、GitHubやGitLabなどのプラットフォームは、エージェントアクターをサポートするためにアイデンティティと権限モデルを拡張しなければならない。エージェントレビュアーは、暗号的に署名されたアイデンティティ、プラットフォームの監査ログにレコードをプッシュする能力、そして人間のレビュアーと同じ方法で承認、変更リクエスト、またはマージブロックを行う能力を必要とする[9]。プルリクエストのユーザーインターフェースもそれに応じて進化しなければならない。エージェントが生成した要約、信頼度スコア、分類された所見、インライン修正提案は、人間の行動を模倣する合成コメントスレッドとしてではなく、構造化されたUIコンポーネントとして提示されるべきである。このモデルにおけるレビュー履歴は、設計上機械可読になる。下流の分析は、欠陥傾向ダッシュボード、セキュリティ態勢追跡、コードベース健全性スコアリングなど、エージェントレビューレコード上で直接動作できる。
VI. 考察
A. 反論：幻覚と偽陰性。
LLMは、その訓練分布から外れた欠陥を見逃す可能性がある[25]。変更について不確かな人間のレビュアーは通常そう言うだろうが、LLMは黙って承認を生成するかもしれない。主な緩和策はアンサンブルレビューである。異なるモデルやプロンプト戦略に基づく可能性のある複数の独立したエージェントを実行し、承認前に合意を要求する。第二の緩和策は、キャリブレーションされた不確実性の報告である。レビュアーエージェントは、常に二元的な承認を発行するのではなく、「わからない」と棄権し、経験的な正しさを追跡する信頼度推定を出力するように訓練・評価されるべきである[29]。
B. 反論：エージェント生成コードのセキュリティ脆弱性。
Pearceらは、GitHub Copilotがセキュリティ関連のコーディングシナリオの範囲にわたり、無視できない割合で共通脆弱性タイプ（CWE）違反を導入することを実証している[24]。コードを生成するのと同じモデルファミリーがそれをレビューする責任も負う場合、生成とレビューの盲点が相関するリスクがある。つまり、エージェントは、その生成傾向が生み出す脆弱性のパターンそのものをフラグ付けできない可能性がある。緩和策は、セキュリティ承認のためにサイバー特化型の最先端レビュアーを使用することだ。最近のベンチマーク指向のレポートでは、最新モデルが脆弱性識別タスクにおいて従来の静的解析ツールや強力なベースラインを上回る可能性があることが示されている[30], [31]。
C. 反論：敵対的入力とプロンプトインジェクション。
プルリクエストを提出できる高度な敵対者は、レビューエージェントによって読み取られたときに、埋め込まれた自然言語命令を通じてエージェントの推論を操作するコードを作成する可能性もある。悪意を持って作成されたコメント、識別子、文字列リテラルは、脆弱性を見落とすか、ブロックすべき変更を承認するようエージェントに指示する可能性がある。これは、完全に解決された防御策が存在しないセキュリティ研究の活発な領域であり[32]、人間のレビュアーには存在しない質的に新しい攻撃対象領域を表している。エージェントレビューを展開する組織は、エージェントレビュアーのプロンプトインジェクションを第一級の脅威モデルとして扱わなければならない。
D. 反論：アーキテクチャの一貫性には人間の判断が必要である。
アーキテクチャレベルでは、レビュアーは変更がシステムの長期的な設計と一致しているかどうかを評価する。新しい抽象化が既存のものを重複させているか、局所的なトレードオフが戦略的な技術的負債を蓄積しているか、インターフェースの決定が将来の拡張を妨げているか、などである。これらの判断は、AIがまだ十分な忠実度で保持していない可能性のあるシステムアーキテクチャのメンタルモデルに依存する[1]。
この懸念は、プルリクエストレビューが実際に提供するものの範囲を誤認している。アーキテクチャの一貫性は、設計文書、アーキテクチャ決定記録、専用のアーキテクチャレビューを通じて最もよく強制されるものであり、コミット単位の差分検査を通じてではない。この二つを混同することは、人間のPRレビューが確実に提供するものを過大評価している。なぜなら、実証研究が示すように、レビュアーは戦略的なアーキテクチャの妥当性ではなく、表面的な欠陥とスタイルに圧倒的に焦点を当てているからである[1], [14]。
E. 反論：倫理的説明責任には人間の判断が必要である。
倫理的なレベルでは、コードの変更は、正しさの検証ではなく価値観に基づく判断を必要とする、ユーザープライバシー、アルゴリズムの公平性、環境フットプリントに対する結果をもたらす可能性がある。エージェントは技術的品質メトリクスを最適化するように調整されている。テレメトリの変更がユーザーの合理的なプライバシー期待に違反していることや、ランキングの修正が人口統計学的バイアスを増幅することを検出するための信頼できる装備はない[4]。法的および組織的説明責任フレームワークは、指名された人間の意思決定者を前提としている。変更が害を引き起こした場合、自動承認は説明責任の空白を残す。
エージェントはすでにセキュリティ上機密性の高いパターン（PIIロギング、安全でないランダム性、過剰な権限のAPI呼び出し）にフラグを立てており、コンプライアンス特性のカバレッジは成長している[24], [25]。より根本的には、必須のPRレビューはソフトウェアの倫理的精査のための適切な場ではない。この責任は要件工学と展開後監視に属する。エージェントレビューは、他の自動化された品質ゲートと同じ制度的メカニズムによって統治され、エージェントが不確実または高リスクとしてフラグを立てた変更のために人間のエスカレーションが留保される。
VII. 結論
コードレビューは半世紀にわたりソフトウェアエンジニアリングに貢献してきた。フェイガンの正式なインスペクション[13]から、現在では日々数百万のコミットを統治するプルリクエストモデル[1]に至るまで、マージ前に人間が互いのコードを読むことは、必須の工学的美徳として扱われてきた。我々は、この前提がもはや成り立たないと論じてきた。
コーディングエージェントは、コードレビューのすべての掲げられた目標を自動的に、より速く、そして人間のレビューが太刀打ちできない規模で達成できる能力レベルに達した。この移行は、業界における日常的な変更に対してすでに進行中である。エージェントは今日、依存関係のバンプ、リファクタリング、テストの追加をレビューし、人間は周辺でのみ監視を提供している。未解決の問題は、このシフトが起こるかどうかではなく、日常的な変更からソフトウェア開発の全領域にどれだけ早く拡大するか、そして専門家集団がその拡大をどのように管理するかである。
コードレビューは一夜にして消え去ることはないだろう。その役割は、長期的な影響を持つアーキテクチャ決定、規制対象システムのセキュリティクリティカルパス、およびどのエージェントもアクセスを許可されていない要件にその正しさが依存する変更といった、リスクの高い人間の監視の層に再焦点を合わせるだろう。他のすべてについては、必須の人間のレビューを擁護する事例は、技術的根拠に基づいて擁護するのが困難な点まで、すでに弱まっている。
我々がかつて現代のソフトウェアエンジニアリングの絶対的なベストプラクティスと考えたコードレビューの終焉は、ソフトウェアを構築するためのより生産的な方法の始まりである。
参考文献
A. Bacchelli and C. Bird, 'Expectations, outcomes, and challenges of modern code review,' in Proceedings of the 35th International Conference on Software Engineering (ICSE) . IEEE, 2013, pp. 712721.
C. Sadowski, E. Söderberg, L. Church, M. Sipko, and A. Bacchelli, 'Modern code review: a case study at Google,' in Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) . ACM, 2018, pp. 181-190.
M. Hilton, T. Tunnell, K. Huang, D. Marinov, and D. Dig, 'Usage, costs, and benefits of continuous integration in open-source projects,' in Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering (ASE) . ACM, 2016, pp. 426-437.
A. Bosu, M. Greiler, and C. Bird, 'Process aspects and social dynamics of contemporary code review,' in IEEE Transactions on Software Engineering , vol. 43, no. 1. IEEE, 2016, pp. 56-75.
A. Murgia, P. Tourani, B. Adams, and M. Ortu, 'Do developers feel emotions? an exploratory analysis of emotions in software artifacts,' in Proceedings of the 11th Working Conference on Mining Software Repositories (MSR) . ACM, 2014, pp. 262-271.
J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, 'SWE-agent: Agent-computer interfaces enable automated software engineering,' arXiv preprint arXiv:2405.15793 , 2024.
Cognition AI, 'Introducing Devin, the first AI software engineer,' Cognition AI Blog , 2024, https://www.cognition.ai/blog/introducing-devin.
X. Wang, B. Chen, Y. Yuan, Y. Zhang, B. Li, C. Qian et al. , 'OpenDevin: An open platform for AI software developers as generalist agents,' in arXiv preprint arXiv:2407.16741 , 2024.
GitHub, 'GitHub Copilot Workspace: Welcome to the Copilotnative developer environment,' GitHub Blog , 2024, https://github.blog/ 2024-04-29-github-copilot-workspace/.
C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, 'SWE-bench: Can language models resolve real-GitHub issues?' arXiv preprint arXiv:2310.06770 , 2023.
Z. Li, S. Lu, D. Guo, N. Duan, S. Jannu, G. Jenks, D. Majumder, J. Green, N. Sundaresan, M. Fu et al. , 'CodeReviewer: Pre-training for automating code review activities,' in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) . ACM, 2022, pp. 1536-1546.
C. Pornprasit and C. Tantithamthavorn, 'Automated code review in practice,' in Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 2023, pp. 394-405.
M. E. Fagan, 'Design and code inspections to reduce errors in program development,' IBM Systems Journal , vol. 15, no. 3, pp. 182-211, 1976.
J. Czerwonka, M. Greiler, and J. Tilford, 'Code reviews do not find bugs: How the current code review best practice slows us down,' pp. 27-28, 2015.
J. Lu, L. Yu, X. Li, L. Yang, and C. Zuo, 'Llama-reviewer: Advancing code review automation with large language models through parameterefficient fine-tuning,' in Proceedings of the 34th IEEE International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 2023, pp. 647-658.
R. Tufano, S. Masiero, A. Mastropaolo, L. Pascarella, D. Poshyvanyk, and G. Bavota, 'Using pre-trained models to boost code review automation.' ACM, 2022, pp. 1-12.
X. Tang, K. Kim, Y. Song, C. Lothritz, B. Li, S. Ezzini, H. Tian, J. Klein, and T. F. Bissyande, 'CodeAgent: Autonomous communicative agents for code review,' arXiv preprint arXiv:2402.02172 , 2024.
M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al. , 'Evaluating large language models trained on code,' arXiv preprint arXiv:2107.03374 , 2021.
Anthropic, 'The Claude 3 model family: Opus, Sonnet, Haiku,' Anthropic Technical Report , 2024.
S. bench Team, 'SWE-bench leaderboard,' https://www.swebench.com, 2025.
C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, 'A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each,' pp. 3-13, 2012.
C. S. Xia, Y. Wei, and L. Zhang, 'Automated program repair in the era of large pre-trained language models,' pp. 1482-1494, 2023.
Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago et al. , 'Competitionlevel code generation with AlphaCode,' Science , vol. 378, no. 6624, pp. 1092-1097, 2022.
H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, 'Asleep at the keyboard? assessing the security of GitHub Copilot's code contributions,' in Proceedings of the 43rd IEEE Symposium on Security and Privacy (SP) . IEEE, 2022, pp. 754-768.
R. Khoury, A. R. Avci, J. Brunelle, and B. Marc Camara, 'How secure is code generated by ChatGPT?' 2023.
J. W. Lin, E. K. Jones, D. J. Jasper, E. J.-s. Ho, A. Wu, A. T. Yang, N. Perry, A. Zou, M. Fredrikson, J. Z. Kolter et al. , 'Comparing ai agents to cybersecurity professionals in real-world penetration testing,' arXiv preprint arXiv:2512.09882 , 2025.
S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, 'The impact of AI on developer productivity: Evidence from GitHub Copilot,' arXiv preprint arXiv:2302.06590 , 2023.
M. Shahin, M. A. Babar, and L. Zhu, 'Continuous integration, delivery and deployment: A systematic review on approaches, tools, challenges and practices,' IEEE Access , vol. 5, pp. 3909-3943, 2017.
S. Kadavath, T. Conerly, A. Askell, T. Henighan, D. Drain, E. Perez, N. Schiefer, Z. Dodds, N. DasSarma, E. Tran-Johnson, S. Johnston, S. El-Showk, A. Jones, N. Elhage, T. Hume, A. Chen, Y. Bai, S. Bowman, S. Fort, D. Ganguli, D. Hernandez, J. Jacobson, J. Kernion, S. Kravec, L. Lovitt, K. Ndousse, C. Olsson, S. Ringer, D. Amodei, T. B. Brown, J. Clark, N. Joseph, B. Mann, S. McCandlish, C. Olah, and J. Kaplan, 'Language models (mostly) know what they know,' arXiv preprint arXiv:2207.05221 , 2022.
A. Yildiz, S. G. Teo, Y. Lou, Y. Feng, C. Wang, and D. M. Divakaran, 'Benchmarking llms and llm-based agents in practical vulnerability detection for code repositories,' arXiv preprint arXiv:2503.03586 , 2025.
Berkeley Risk and Decisions Initiative, 'Frontier ai's impact on the cybersecurity landscape (paper summary and blog),' https://rdi.berkeley. edu/frontier-ai-impact-on-cybersecurity/, 2025.
K. Greshake, S. Abdelnabi, S. Mishra, C. Endres, T. Holz, and M. Fritz, 'Not what you've signed up for: Compromising real-world LLMintegrated applications with indirect prompt injection,' arXiv preprint arXiv:2302.12173 , 2023.