- はじめに
- システム概要
- 仕組み1：レビュー観点の分割
- 仕組み2：複数エージェントによるレビュー精査
- 仕組み3：GitHub上でのレビュー・修正ループ
- チーム展開とフィードバック
- 今後の展望
- Claude Code のCode Review機能
- おわりに
はじめに
こんにちは、生まれて初めてワカサギ釣りに行ったが1匹も釣れなかった、WEBアプリケーションエンジニアの山元です！
みなさんAIエージェントのコードレビュー精度に満足していますか？ 私自身、自分のPRをチームのエンジニアにレビュー依頼する前や、AIエージェントが生成したコードを自分でレビューする前など、よくAIエージェントにコードレビューを依頼しています。しかし、単純にAIにレビューを依頼すると
- SkillsやInstructionsを充実させているにも関わらず、指摘の精度が安定しない
- 瑣末な指摘が多かったり、ハルシネーションが発生する
- 同じことを何度も指摘される
といった問題が発生します。これらの問題を解消し人間と同様の精度でコードレビューを実施するため、3層エージェントオーケストレーションによるコードレビューシステムを構築しましたので、ご紹介させていただきます。
このシステムは以下の3つの仕組みで構成されています。仕組みの詳細はそれぞれのセクションで順番に説明していきます。
仕組み1: レビュー観点の分割
小さな単位に分割したレビュー観点ごとに専任のエージェントを配置し、レビューの抜け漏れを防ぐ
仕組み2: 複数エージェントによるレビュー精査
同じ観点を複数エージェントでレビューし、2体以上が指摘した箇所のみ採用する
仕組み3: GitHub上でのレビュー・修正ループ
PRへのコメント投稿や、既存レビュー結果やコメントをコンテキストとして渡すことで、レビューと修正のループを既存の開発フロー上で回しやすくする
システム概要
まずコードレビューシステムの全体を簡単にご説明します。
画像中のAGはエージェントの略。
親エージェント (第1層)
レビュー全体をオーケストレーションします。ブランチの変更内容からレビューが必要な技術領域（バックエンド/フロントエンド/テスト）を判定。必要なカスタムエージェントをサブエージェントとして複数並列起動し、結果を統合してPRにコメントを投稿します。
コンテキスト収集エージェント (第2層)
PRの既存レビューやコメントを取得し、指摘済みの内容と未対応の内容を分類、コンテキスト用のテキストとしてまとめます。
静的解析エージェント (第2層)
静的解析可能な部分については、PHPStanやESLint/TypeScript型チェックで実施します。
レビュー精査エージェント (第2層)
観点ごとに4体のレビュー実施ーエージェントをサブエージェントとして並列起動します。レビュー実施エージェントの結果を精査し、レビュー結果の統合を行います。
レビュー実施エージェント (第3層)
特定の1観点に絞ってコードレビューを実行します。この際、コンテキスト収集エージェントの集めたコンテキストも考慮します。
仕組み1：レビュー観点の分割
目的：タスクが大きいことによる出力精度低下を防止する
1体のAIエージェントに「全観点でレビューして」と依頼すると、タスクが大きすぎてレビュー精度が落ちます。「アーキテクチャ」「セキュリティ」「パフォーマンス」などレビュー観点を限定的にした方が人間もレビューしやすいですよね。同じように、AIエージェントも依頼するタスクが小さい方が出力結果の精度が高くなりやすいです。
そこで、コードレビューの観点をあらかじめ分割し、その観点ごとに専任のカスタムエージェントを配置する構造にしました。
技術領域と観点の自動判定
親エージェントが変更ファイルの拡張子に基づいて技術領域を自動判定し、対応するエージェントを起動します。
| 技術領域 | 判定基準 | レビュー実施エージェント | 静的解析エージェント |
|---|---|---|---|
| バックエンド | *.php（テスト除く） |
アーキテクチャ、ビジネスロジック、コードの明確性、コード品質、パフォーマンス、セキュリティ | PHPStan |
| フロントエンド | *.ts, *.js, *.vue, *.twig |
アーキテクチャ、コードの明確性、コード品質、フロントエンド固有、パフォーマンス | ESLint / TypeScript型チェック |
| テスト | *Test.php, *.spec.ts |
テスト設計 | — |
もちろん技術領域をまたいでいるPRでは、複数の技術領域に対応する観点エージェントと静的解析エージェントが起動します。 また、レビュー実施エージェントに加えて、PHPStanやESLint/TypeScript型チェックの静的解析エージェントも用意しました。
各レビュー実施エージェントの設計方針
各レビュー実施エージェントには、以下の共通ルールを設けています。
- 良い点の指摘は禁止
- 実装案の提案は禁止
- レビューと修正の責務を分離する。修正は修正を実施する際のコーディングエージェントに任せればよく、レビューエージェントがその作業を一部担う必要はない
- YAGNIの原則に反した指摘は禁止
- 既存実装への指摘は禁止
全て目の前のコードレビューに集中してもらうためのルールです。 特に実装案の提案禁止とYAGNI原則の厳守はAIレビュー特有のノイズを抑制するために有効だと考えています。この制約なしに動かすと、細かい実装の提案や将来を見越したリファクタリング提案をしてきて、コードの問題点の指摘から逸れてしまうことが多いです。
プロジェクト固有の知識
skillsなどのAIエージェント用ドキュメントにレビューして欲しい観点が含まれている場合は、明確にそのファイルを参照してレビューを行うようにしました。例えば、アーキテクチャ観点のエージェントはオニオンアーキテクチャのガイドラインskillを、テストコード観点のエージェントはテストコードの実装規約skillを参照させています。
今回このシステムを作成するにあたって、直接レビュー観点を記載したレビュー実施エージェントファイルも作成しました。しかし、本来的にはレビュー観点などskillsなどで管理すべきです。最終的にはskillsにすべて移管し、skills単位でレビュー実施エージェントを起動する設計にすることも検討しています。
カスタムエージェントファイル例
--- name: review-agent-name description: multi-agent-reviewから呼びだされるカスタムエージェント。〇〇〇〇に関するコードレビューを実施する user-invocable: false --- ## Goal 実装に対して、〇〇〇〇の観点からコードレビューを実施し、問題点・改善点のみを報告する。 ## 手順 1. プロンプトで指定されたレビュー対象のコードを読み取る 2. 以下のチェック項目に基づきレビューを実施する 3. 問題点を出力フォーマットに従い報告する ## レビュー時の注意点 - プロンプトで説明されている、現在の開発状況や制約条件などの情報を考慮せずに指摘することは禁止 - YAGNIの原則に反した指摘をすることは禁止 - 今回の修正範囲及び、修正の影響範囲についてのみレビューすること。修正に関係のない既存実装について指摘することは禁止 ## チェック項目 ### 1. 〇〇〇〇 （レビュー観点） ### 2. 〇〇〇〇 （レビュー観点） ## 出力時のルール - 問題点・改善点のみ報告する。良い点を指摘するのは禁止 - 実装案の提案は禁止 - コードの変更は禁止 ## 出力フォーマット 各指摘は以下の形式で報告すること: ``` - **[重要度]** ファイル:行番号 — 指摘内容 ``` 重要度: Critical / Major / Minor
仕組み2：複数エージェントによるレビュー精査
目的：瑣末な指摘やハルシネーションや排除する
観点を分割してタスクを小さくしても瑣末なスタイル指摘を大量に報告したり、ハルシネーションで存在しない問題を指摘することは避けられません。 そこで、同じ観点を複数のエージェントでそれぞれレビューさせ、2体以上が共通して指摘した内容のみを採用することで、瑣末な指摘やハルシネーションなどのAIエージェントの出力のブレを排除する仕組みを導入しました。
レビューの流れ
- 1つのレビュー観点に対し、4体のレビュー実施エージェントが 並列でコードレビューを実行する
- 4体の出力をレビュー精査エージェントが比較する
- 2体以上が同じ箇所・同じ趣旨で指摘した内容のみを採用する
- 採用された指摘の重複を排除し、最も明確な表現を選んで出力する
1体だけが指摘した内容はハルシネーションや過剰反応、瑣末な指摘の可能性が高いため、フィルタリングで除外されます。
異なるモデルを併用
4体のレビューエージェントには、意図的に異なるLLMモデルを使用しています。
- Claude Opus 4.6: 2体
- GPT-5.4: 2体
同一モデルのみでフィルタリングすると、指摘の偏りやハルシネーションのパターンなどモデル固有のバイアスが強く出る可能性があります。 異なるモデルを混在させることで、モデル固有のバイアスを相互に打ち消し合いブレの少ないレビュー結果を出力することを狙っています。ClaudeとGPTが共に指摘した内容であれば、それは特定モデルの癖ではなく、実際に問題がある可能性が高いと判断できます。
サブエージェント複数起動のコスト
サブエージェントを大量に起動すると単純に入出力のトークン数が増えるため、発生するコストが気になります。
弊社ではGitHub Copilotを開発チーム全体で導入しており、このレビューシステムは特にGitHub Copilot CLIから使用する前提で作成しました。 github.com
GitHub Copilotではカスタムエージェントに追加料金が発生しません。*1 このため、観点ごとに4体、合計で数十体のエージェントを起動する本構成でも、コストが増大することはありません。精度向上のためにエージェント数を増やす設計判断を、コストを気にせず採用できるのはGitHub Copilotの大きな利点ですね。Thank you GitHub!
仕組み3：GitHub上でのレビュー・修正ループ
目的：レビューと修正のループにAIコードレビューを自然に組み込む
コードレビューは複数回繰り返すものですが、普通にAIエージェントにコードレビューを依頼するだけでは実施したレビュー結果が保持されません。また2回目以降のレビューで、前回のレビュー時に対応しないと判断した内容を指摘されることもあります。このようにコードレビューの結果をターミナルに出力するだけでは、レビューと修正を繰り返してコード品質を上げていくという開発フローに載せづらいです。
そこで本システムでは、レビュー結果のPRへの投稿と、既存レビューコメントのコンテキスト活用という2つの仕組みでこれを実現しています。
PRへのコメント投稿
レビュー結果はPRのインラインコメントとして投稿するようにしたため、 指摘箇所ごとにコードの該当行にコメントが残ります。またレビュー本文にはユーザーが投げた元のプロンプトも記載されるため、どのような指示でレビューが行われたか追跡可能です。
これにより以下のメリットが生まれます。
- レビュー履歴の可視化
- AIレビューの実施有無や指摘内容を、他のエンジニアがPR上で確認できる
- 修正対応の自動化
- コーディングエージェントにレビューコメントへの対応を指示することで、修正作業もAIに委ねられる
- プロンプトの透明性
- レビューがどのような指示で行われたか、チームの誰もが確認できる
既存コメントのコンテキスト活用
前回と同じ指摘が繰り返される問題を解消するために、コンテキスト収集エージェントがPRの既存コメントを分析し、レビューエージェントに渡します。
まず、PRの過去レビュー履歴から、前回のAIレビュー以降のコミットのみをレビュー対象として検出します。 次にPRの既存レビューコメントとその返信を取得・分析し、2つのカテゴリに分類してレビューエージェントに渡します。
- 指摘済みの事項 → 同一箇所の指摘は行わない
- エンジニアが対応不要であると判断した事項 → 同一箇所でなくとも同じ指摘を行わない
- 例えばデザイン実装をスコープ外としているPRにおいて、デザイン実装の不備をAIが指摘 → エンジニアが「デザイン実装はスコープ外のため対応しない」と変更 → それ以降のレビューではデザインの不備を指摘しない
特に開発フロー上重要なのは対応不要と判断された事項の扱いです。レビューコメントに対してエンジニアが「意図的にこうしている」「今回のスコープ外で対応しない」と返信した場合、その返信内容はレビュー全体に対する要望として解釈されるようにしました。これにより同様の指摘がPR内の他のファイルで繰り返されることを防ぎます。
チーム展開とフィードバック
カスタムエージェントをチームに展開し、実際のPRで使ってもらった際のフィードバックを紹介します。
レビュー精度
「可読性の観点でのコメントが良い。並行して通常モードでもレビューしたが、そちらには出てこなかったコメントだった」
「デッドコードの削除漏れを検知してくれた。作業中にcompactionで漏れたものを拾ってくれた。別セッションで検証するとこのあたり安心感がある」
観点を分割して深くレビューさせることで、素のAIレビューでは見逃される指摘が出てくる点が評価されました。
結果の透明性
「レビュー結果で各観点の結果が出る＆フィルタリングの結果が確認できる点が良い。精度や観点の品質保証ができれば、レビュー時の安心につながる」
「4/4が同じ結論だった」*2
レビュー結果がどの観点でどのような指摘があったか、どの指摘が複数エージェントで一致していたかがわかる点も好評でした。
今後の展望
レビュー精度の定量評価
今後、以下の3つの観点で精度を定量評価していき、人間と同程度以上の精度が出せる状態だと証明できれば、コードレビューの作業を部分的にAIエージェントに任せることを考えています。
| 観点 | 評価方法 | 合格ライン |
|---|---|---|
| レビュー結果が安定するか？ | 同一PRに3回レビューし、共通指摘の割合を測定 | 80%以上 |
| 指摘した内容が正しいか？ | AIの指摘をエンジニアがレビューし、妥当性を判断 | 80%以上 |
| 人間であれば指摘する内容を取りこぼさないか？ | 同一PRを人間とAIでレビューし、指摘の一致度を測定 | 80%以上 |
レビュー精度はエージェント用ドキュメントの量と質にも左右されるため、一度作って終わりではなく、精度を継続的に監視し続ける仕組みが必要だと考えています。
コードレビューの再定義
AIがコードレビューを担えるようになると、人間のレビュアーは何を見るべきか整理し直す必要が出てきます。
簡単にではありますが、コードレビューの難しさを3つのレベルで整理しました。
| レベル | 判断に必要な情報 | 具体例 | 担当 |
|---|---|---|---|
| レベル1 | コードの該当箇所のみ | 構文エラー、型不整合、コーディング規約逸脱 | 静的解析ツール、AIエージェント |
| レベル2 | コードの複数箇所 | 設計、責務分離、可読性、再利用性 | AIエージェント |
| レベル3 | コード外の知見 | 仕様との整合性、UX、深い技術的知見、深いドメイン知識 | エンジニア |
レベル1, 2のAI代替により、人間のエンジニアはレベル3のレビューやレビュー以外の業務に注力できる体制を目指しています。
ただし、AIエージェント由来のコードによる大規模障害が発生したなどの報道もあるため、精度の定量評価や実際の運用を通じて慎重に判断していく必要があると考えています。
Claude Code のCode Review機能
私が本記事で紹介したシステムを作成していた2026年3月、Anthropic社からClaude Code のCode Review機能がリリースされました。
非常に高精度なコードレビューが実施できる機能がAIベンダーから提供されるようになったわけですが、現時点ではまだこのレビューシステムにも、レビューの手順や観点を社内のエンジニアで自由に調整が可能などのメリットがあります。コスト面でもClaude Code Reviewは1件につき平均$15〜25/レビューがかかるということで、日常的に利用するには高額です。
しかし、 今後確実にこうした高品質なAIコードレビュー機能が各社から次々にリリースされ、精度もどんどん向上し、利用料も下がっていくはずです。どこかのタイミングで、レビューシステムの内製コストをレビュー機能の利用コストが上回り、外部のレビュー機能を利用する方がコストパフォーマンスが良くなるタイミングが来ると思います。そうなった際には、内製のレビューシステムから外部のレビュー機能への移行も視野に入れていきたいと考えています。
ただ、複数エージェントでレビューを行い、レビュー結果のフィルタリングを行うというアプローチ自体がAnthropic社のアプローチと一致していた点は非常に嬉しかったです。設計の方向性が妥当であったことの裏付けになりました。
おわりに
レビュー観点の分割、複数エージェントによるレビュー精査、GitHub上でのレビュー・修正ループの3つの仕組みにより、単体のAIレビューより高精度かつ開発フローに組み込みやすい実用性を備えたコードレビューシステムを構築しました。
今回構築したAIコードレビューの精度はまだ発展途上ですし、将来的に価値がなくなることも考えられます。ですが、エージェントオーケストレーションのアプローチは、どのようなツールでどのようなタスクを実行するかに関係なく有望な方向性だと考えています。 今後も改善を重ね、開発チーム全体の生産性向上に貢献していきたいと思います。
このようにオープンワークではAI活用を通じた生産性の向上を積極的に進めています。この記事を読んで一緒にAI活用にトライしたいと思っていただけた方、弊社に興味を持っていただけた方はぜひ採用サイトを覗いてみてください！
