コードレビューエージェント（code review agent、CRA）とは、プルリクエストに参加し、レビュー対象の
コードについてレビューのフィードバックを投稿する自動化された参加者である。このカテゴリは実装ではなく
機能によって定義される。プルリクエストにコメントする他のボットと CRA を分けるのは、CRA がコードについての
フィードバックを生み出すという点であり、github-actions[bot] のようなボットはその代わりに継続的
インテグレーションやワークフローの自動化を行う。この区別は手作業で引く必要がある。GitHub 自身の
プルリクエストデータでは、すべてのボットが同じ Bot ユーザータイプで記録されており、レビュアーと
ビルドランナーを区別するものは何もない。
業界の主張から実証的な現実へ：プルリクエストにおけるコードレビューエージェントの実証研究 は、データから個々のボット名を抽出し、
それぞれを何をするかによって手作業で分類し、CI/CD やワークフロー自動化のアカウントを除外することで
これに対処した。
用法
CRA は、自律的なコーディングエージェントが作成するプルリクエストの増加とともに、プルリクエストの ワークフローの日常的な一部となった。これを導入する論拠は量にある。人間のレビュアーが読むよりも速く コードが届くとき、レビューがボトルネックになり、自動化されたレビュアーはその負担を軽減する手段を求める 先の一つとなる。
CRA は、レビュープロセスにおいて人間のレビュアーよりも構造的に弱い立場にある。 業界の主張から実証的な現実へ：プルリクエストにおけるコードレビューエージェントの実証研究 が調べたプルリクエストのデータでは、 CRA だけがレビューしたプルリクエストは Commented のレビュー状態にしか現れず、Approved、 Changes Requested、Dismissed になることは一度もなかった。同研究はこれを、単独の CRA は明示的な マージの判断を下せないことを示すものと解釈している。CRA はコードについて何かを言うことはできるが、 それ単独では変更を承認することも、正式に修正を求めることもできない。
同研究は、CRA がその仕事をどれだけうまくこなすかも測定した。CRA だけがレビューしたプルリクエストの マージ率は 45.20% で、人間だけによるレビューの 68.37% を下回っており、その差はフィードバックの量では なく質に起因することを突き止めた。調べた 98 件の放棄された CRA のみのプルリクエストのうち 60.2% が、 シグナル対ノイズ比（コードレビュー） の最も低い 0〜30% の帯に入っていた。同研究の推奨は、特化した チェックのほうが誤検知が少ないという論拠に基づき、CRA をセキュリティの脆弱性やスタイル違反のような 狭く具体的なチェック向けに設定すること、そしてマージの前に人間による承認のステップを残しておくことで ある。
個々の CRA が生み出すものの質には大きなばらつきがある。同研究は、調べた放棄されたプルリクエスト 全体で 13 の異なる CRA を特定し、そのうち 12 がシグナルの平均で 60% を下回っていたと報告している。 また、エージェントがレビューするプルリクエストの数は、そのコメントがどれだけ役に立つかの目安には ならないとも指摘している。
ある実務者の記録は、独立に同じ絞り込みにたどり着き、それが何のためだったかを報告している。これは 同研究より前に公開されており、同研究を引用してもいないため、両者が共有しているのは系譜ではなく 結論である。AIコードレビューを「単一責任の原則」で育てた話 は、汎用のレビュアーが 的外れなコメントを多く出したために同僚がその出力を無視し始めたチームについて記録しており、そのチームの 対応は、1 つのレビュアーを多数に分割すること — レビューの関心事ごとに 1 つずつとし、それぞれがその 関心事に必要なコンテキストだけを持つようにすること — であった。記事はこれを、レビュアーに適用した 単一責任の原則として位置づけている。その例は同研究が推奨するとおりの狭さを持っている。あるエージェントは テストスイートを不安定（flaky）にするテストのパターンを探し、別のエージェントは並び順が一意でない ページネーションのクエリを探す。
この記録のうち 2 つの点は、そのチームについてではなく、このカテゴリそのものに関わる。1 つ目は、 記事が名指しする失敗モードである。シグナルの低い出力は単に読み手の時間を無駄にするだけではなく、 レビュアーから聞き手を奪う。これは上で測定されたマージ率の差とは種類の異なる損失である。2 つ目は、 その狭さがどこから来たかである。チームは自分たちの過去の失敗を検出パターンとしてフィードバックし、 欠陥を直すこととレビュアーを拡張することが一つの行為になったと報告しており、また、静的解析のルールでは 表現するのが厄介すぎると判明したある種の欠陥に対して、特に LLM のレビュアーを用いたと報告している。
関連用語
- シグナル対ノイズ比（コードレビュー） — CRA のフィードバックのうちどれだけが対応可能なものかを判断する ために使われる指標