エージェント型コードレビューとは、AI エージェントがレビュアーの役割を担うコードレビューを指す。この wiki が保持する 2 つの情報源はこの用語を異なるレベルで使っており、どちらも他方の特殊な場合ではない。一方はプロジェクトのレビュー実践の一局面を指し、もう一方は単一のレビューについてのタスク定義を指している。
人間中心からエージェント型のコードレビューへ：生成 AI 技術の世代の違いがレビュー品質に与える影響 は、この用語を、プロジェクトが経験しうる 3 つのコードレビューの時代のうち最も新しいものに対して用いている。この研究は、レビューが主に人間のプロセスである人間中心のレビュー、LLM 支援のレビュー、そして AI エージェントのレビュアーが人間のレビュアーや大規模言語モデルのレビュアーと並んでレビュープロセスに参加するエージェント型コードレビューを区別している。これらの時代は、研究が導き出したカテゴリーではなく、研究が前提とする枠組みである。研究が実証的に特定しているのは、207 の GitHub プロジェクトにおける 102 万件のレビュー済みプルリクエストから得られた、プロジェクトがそれらの時代を移行していく 3 つの導入実践である。
SWE-Review: エージェント型コードレビューによるイシュー解決のループの閉鎖 は代わりに、これをリポジトリに根ざしたタスクとして定式化している。レビューのインスタンスは、該当するコミット時点のリポジトリのチェックアウト、自然言語のイシュー、そして差分・タイトル・本文を伴う候補プルリクエストを提供し、正解パッチと隠しテストの結果は与えない。レビュアーは、2 つの欄を持つレポートを提出する前に、ファイルを閲覧し、コードを検索し、依存関係を調べ、コマンドを実行することができる。2 つの欄とは、承認するか変更を要求するかの二値の判断と、変更を要求する場合には、具体的な欠陥を特定し、可能であればコードの位置を示し、下流の修正エージェントのために実行可能な修正案を提示する診断である。
用法
時代という意味では、この用語は特定のツールではなく実践の一局面を示す。プロジェクトは、その時代に移行する際にどの 3 つの導入実践 — Gradual AI Adoption（段階的な AI 導入）、Rapid LLM Adoption（急速な LLM 導入）、Rapid AI Agent Adoption（急速な AI エージェント導入）— をたどったかによって特徴づけられ、レビューの議論は人間・LLM・エージェントのレビュアー間のやり取りの系列としてモデル化される。
その研究がこの時代について報告しているのは、一つの分かれ目である。エージェントが関与する協働パターン、特に AI エージェントが起点となるレビューや複数の AI エージェントが関与するレビューは、2 つの導入実践のもとでより速いレビュー判断と関連しているが、著者たちは、効率の向上がより良いレビュー品質にはつながらないと述べている。
タスクという意味では、決定的な点は、レビュアーが差分を単独で読むのではなくリポジトリの中で行動することにある。測定された優位性もまさにそこにある。SWE-Review: エージェント型コードレビューによるイシュー解決のループの閉鎖 は、エージェント型レビューが、単一ターンで固定されたコンテキストのレビューを、判断の正確さと修正後の解決率の両方で上回り、その差が最も大きいのはリポジトリ全体にまたがる非局所的な推論を必要とするタスクであったと報告している — これは、探索こそが追加された能力によって得られるものであるなら、予想されるとおりの結果である。この枠組みでは、レビューは最後に添えられる論評のステップではなく、生成・レビュー・修正ループ の要となる。
2 つの用法は、何を証拠とみなすかについて異なる方向を向いている。時代の説明は観察的なものであり、GitHub 上のプロジェクトが実際に行ったことから導かれ、速いことが良いことではないと慎重に述べている。タスクの説明は構成的かつ実行可能なものであり、レビューを、その後にパッチがイシューを解決したかどうかによって採点する。エージェント型コードレビューについての主張を見るときは、情報源がこの 2 つのどちらを意味しているかを確認する価値がある。
ベンダーによる用法
この形容詞の 3 つ目の用法はベンダー側から来ており、上の 2 つの意味のどちらよりも具体的なものを指しているので、記録しておく価値がある。GitHub の GitHub Copilot コードレビュー のドキュメントには「Agentic capabilities for Copilot code review」という見出しの節があり、その見出しのもとに置かれているのはレビュー全体ではなく 2 つの特定の能力である。すなわち、変更の文脈をよりよく理解するためにリポジトリ全体を分析するプロジェクト全体のコンテキスト収集と、提案を Copilot クラウドエージェントに渡す能力であり、後者は提案された修正を適用した新しいプルリクエストを作成する。同じドキュメントはこの形容詞をレビューそのものにも用いており、特定のプルリクエストはエージェント型レビューの対象になると述べているので、狭い読み方は一つの節での強調であって、ドキュメント全体を通じて一貫して保たれている定義ではない。
その強調が落ち着く先は、おおむね上のタスクという意味が線を引く場所と同じである — レビューをエージェント型にするのは、差分だけを読むのではなくリポジトリに対して行動することである。ドキュメントは、どちらの研究の説明にも付け加える理由のないコストをそれらの能力に結びつけている。それらの能力は GitHub Actions 上で動作するため、デフォルトでは、差分の外に及ぶレビューはモデルの使用量に加えて GitHub Actions の実行時間を消費する。このデフォルトが唯一の構成というわけではない — ドキュメントは、セルフホストランナーは Actions の実行時間を消費しないこと、そして GitHub ホストランナーを無効にした組織はセルフホストランナーを使えること、使わない場合にはレビューがより限定された形式にフォールバックすることを述べている。それらの能力が使えない場合でもレビューは生成されるが、能力がもたらすものは欠けることになる。これは一ベンダーが自社製品について記したドキュメントであって、この用語の独立した特徴づけではなく、ここではそのようなものとして記録している。
ツールによる用法
この wiki の情報源にある 2 つのオープンソースプロジェクトは、上の 2 つ目の意味が定義するリポジトリに根ざしたタスクのために作られており、その結果生じるループのうちどれだけをエージェントに任せて実行させてよいかについて意見を異にしている。この呼び名を採用しているのは 2 つのうち一方だけである。AsyncReview は自らをはっきりとエージェント型コードレビューと呼んでいるが、Open Code Review はこの形容詞を一度も使っておらず、自らをハイブリッドアーキテクチャを持つ AI 駆動のコードレビュー CLI と説明している。Open Code Review をここに記録するのは、その議論がこの能力に関するものだからであって、この用語を名乗っているからではない。
AsyncReview は最大限の読み方をとる。その README は、単純な差分分析を超えて、回答する前にリポジトリを自律的に探索し、コンテキストを取得し、サンドボックスで発見を検証することを説明しており、それは推論し、Python コードを生成し、それを実行し、結果を観察するという再帰的なループで行われる。他のレビューツールとの対比として同プロジェクトが挙げるのは 4 つの対である。限られたコンテキストに対してリポジトリ内の任意のファイルを読むこと、コードがどう動くかを推測する静的解析に対して検索クエリや検証スクリプトを実行すること、ライブラリのメソッドをでっち上げることに対して実在するファイルパスと行を引用すること、そして一発の生成に対して回答する前に反復すること、である。3 つ目の対は、このアプローチが取り除こうとする失敗としてハルシネーションを名指ししており、これはタスクという意味がグラウンディングについて主張していることと同じである。
Open Code Review は同じ前提を受け入れている — そのエージェントはファイルの内容全体を読み、コードベースを検索し、変更された他のファイルも調べる — が、別のことに反対している。それはリポジトリへのアクセスではなく、レビューのプロセスをモデルに任せることである。同プロジェクトはこれを、汎用エージェントがこの仕事をしてきた実績から論じている。その README は、汎用エージェントをコードレビューに使うことに起因するとする 3 つの問題を挙げている。大きな変更セットではエージェントが手を抜き、一部のファイルだけをレビューして他を見落とすこと、報告された問題が実際のコードの位置からずれること、そしてプロンプトのわずかな違いで品質が揺らぐことである。同プロジェクトの診断は、純粋に言語駆動のアーキテクチャにはレビュープロセスに対するハードな制約が欠けているというものであり、その対応は 4 つのステップをモデルから取り上げることである — どのファイルをレビューするか、関連するファイルをどのように独立したサブエージェント単位にまとめるか、どのルールがどのファイルに該当するか、そしてコメントの位置決めと振り返りのための一対の外部モジュールである。エージェントに残されるのは動的な判断と動的なコンテキスト取得だけである。同じモデル上の汎用エージェントと比較して、同プロジェクトはおよそ 9 分の 1 のトークンでより高い適合率と F1 を達成し、意図的なトレードオフとして再現率はより低かったと報告しており、この比較は同プロジェクト自身が AACR-Bench で実施したものである。
どちらの説明もそれぞれのプロジェクト自身による自己記述であり、2 つ目の数値は同プロジェクトが自ら実施した比較で報告した結果である。両者が合わせて示しているのは確定した答えではなく、この用語のタスクという意味が争点となる領域になったということである。共有されている前提はレビューにはリポジトリへのアクセスが必要だということであり、生きている問いは、その結果生じるループのうちどれだけをモデルが実行すべきかということである。