この記事は、単一エージェントによる AI レビューに対する 3 つの不満――スキルや指示を十分に整備しても指摘の質が安定しないこと、些細な指摘やハルシネーションが多いこと、同じ点がラウンドをまたいで繰り返し指摘されること――に対処するために著者が構築したコードレビューシステムを説明している。提案される解決策は 3 層エージェントオーケストレーション である。すなわち、レビューを観点ごとのエージェントに分割し、各観点を複数回実行し、独立した実行どうしが一致したものだけを残す。
この報告が単なる設計スケッチと異なるのは、チームのフィードバックを伴って本番運用中のシステムを報告しており、かつ自らの評価はまだ済んでいないと明言している点である。著者は、それぞれ 80% を合格ラインとする 3 つの定量的基準を示してそれを今後の課題と位置づけ、レビュー業務をエージェントに引き渡すかどうかは、まずその基準を満たすことを条件とすると明示している。
要点
- システムは 3 層で構成される。ブランチがどの技術領域にかかわるかを判断して実行をオーケストレーションする親エージェント、コンテキスト収集・静的解析・レビュー精査の各エージェントからなる中間層、そしてそれぞれ 1 つの観点に限定されたレビューエージェントからなる最下層である。
- どのエージェントを起動するかは、変更ファイルの拡張子から機械的に決まる。テスト以外の PHP ファイルはバックエンドの観点と PHPStan を、TypeScript/JavaScript/Vue/Twig はフロントエンドの観点と ESLint・型チェックを選択し、テストファイル（
*Test.php、*.spec.ts）はその代わりにテスト設計の観点を選択する。複数の領域にまたがる PR では、それぞれの領域のエージェントが起動する。 - 各観点は 4 つのエージェントが並列にレビューし、精査エージェントは、そのうち 2 つ以上が同じ箇所について同じ理由で挙げた指摘だけを残す。著者が述べる根拠は、1 つのエージェントだけが挙げた指摘はハルシネーション、過剰反応、あるいは些末なものである可能性が高い、というものである。
- 4 つのエージェントは意図的に 2 つのモデルファミリーに分けられている――2 つは Claude Opus 4.6、2 つは GPT-5.4 で動作する――ことで、モデル固有のバイアスやハルシネーションのパターンが強め合うのではなく打ち消し合うようにしている。著者は、ベンダーをまたいだ一致は、単一ベンダー内での一致よりも実際の問題の強い証拠になると論じている。
- レビューエージェントは 4 つの禁止事項のもとで動作し、いずれも各エージェントを目の前の変更に集中させることを狙っている。良い点を褒めないこと、実装を提案しないこと、YAGNI に反する指摘をしないこと、変更外の既存コードについて指摘しないこと、である。著者はそのうち 2 つ――実装提案の禁止と YAGNI の厳守――を、AI レビュー特有のノイズに対して特に効果的なものとして挙げている。レビューと修正の分離は明示的に論じられており、修正は修正を担うコーディングエージェントの役割だとされる。
- プロジェクト固有の知識は、各エージェントに関連する既存のスキルファイル（たとえばアーキテクチャ観点にはオニオンアーキテクチャのガイドライン）を参照させることでエージェントに届けられる。著者は、レビュー観点をまるごとスキルに移行し、スキルごとに 1 つのレビューエージェントを起動する形を望むと述べており、このシステムのために書いた観点ファイルは暫定的な措置だとしている。
- 指摘は、ユーザーの元のプロンプトとともに、プルリクエストへのインラインコメントとして投稿される。著者はこれにより、レビュー履歴が他のエンジニアにも見えるようになり、コーディングエージェントにそのコメントを示して修正させることができ、レビューの背後にある指示を監査可能にできるとしている。
- コンテキスト収集エージェントは PR の既存のレビューコメントと返信を読み、それらを既出の指摘と、エンジニアが対応を見送った指摘とに分類して、両方を後段に渡す。見送られた指摘のカテゴリーは箇所ごとではなくレビュー全体にわたる恒常的な指示として扱われ、「これはスコープ外です」という返信があれば、PR 内の他の箇所での同じ指摘も抑制される。
- 報告されたチームのフィードバックは好意的だが定性的である。レビュアーは、素のエージェントレビューでは出てこなかった可読性に関する指摘、コンパクションの際に見落とされていたデッドコードの検出、そしてどの観点がどの指摘を生み、フィルターがそれらをどう処理したかを確認できることを評価した。
- 著者はレビューの難しさを 3 段階に分けて捉えている。変更行だけで判断できる指摘、コードベースの複数箇所を必要とする指摘、そして仕様との整合、UX、ドメイン理解といったコード外の知識を必要とする指摘である。前の 2 つをツールとエージェントに割り当て、3 つ目はエンジニアに残している。
背景
この記事は、すでに開発者全体に GitHub Copilot を導入していたチームの内側から書かれており、著者は設計がその前提に依存していることを明言している。別のエージェントから起動されたカスタムエージェントは、プランの課金単位であるプレミアムリクエストを消費しないため、精度のためにエージェントを追加することをコストを考慮せずに決められた。これは執筆時点でチームが置かれていた条件についての記述であり、数十のエージェントを起動する設計がそもそも負担可能だった理由として述べられているものである。
著者はベンダーが提供するレビュー機能にも直接言及し、社内システムには、エンジニアがその手順や観点を自由に調整できるという利点が残ると論じている。記事は、そうした機能が今後改善され安価になることを見込み、社内でシステムを保守するよりも利用するほうが安くなった時点で移行する意向を述べている。著者はまた、ここで採ったアプローチ――複数のエージェントがレビューし、その結果をフィルタリングする――が大手ベンダーの方向性と一致しているように見えたことを喜んでおり、それを設計の妥当性の裏付けとして扱っている。
エージェント型コードレビュー および AIコードレビューの理想と現実 ─ Devinをチームに導入して気づいたこと も参照。