AI エージェントでコードレビューを自動化する方法
1 つのエージェントがコードを書き、別のエージェントがレビューする自動化された AI コードレビューパイプラインを、実例と設定付きで構築します。
コードレビューは、ソフトウェア開発において最も価値の高い作業の 1 つです。バグを見つけ、標準を守らせ、チーム全体に知識を広げます。一方で、レビュアーが自分の作業と届いた PR を行き来する間、レビューはキューにたまり続けるボトルネックでもあります。
AI エージェントはコードを即座にレビューできます。適切に構成すれば、1 つのエージェントがコードを書き、別のエージェントがレビューし、問題を修正し、再レビューするという一連の流れを、すべて手動操作なしで自動化できます。
その設定方法を見ていきましょう。
基本パターン
Writer Agent → Review Agent → Writer Agent (fix) → Review Agent (approve)- Writer エージェントが機能または修正を実装します。
- 完了すると、出力が自動的に Review エージェントへ送られます。
- Reviewer が変更を分析し、問題点を報告します。
- 問題点は Writer に戻され、修正されます。
- Reviewer が承認するか、ラウンド上限に達するまで繰り返します。
ステップ 1: レビュー基準を定義する
Review エージェントには明確な基準が必要です。基準がないと、「エラーハンドリングを追加するとよいでしょう」のような一般的なフィードバックしか返せず、役に立ちません。
良いレビュー用プロンプトには、具体的な基準を含めます。
Review the changes for:
1. Correctness — Does the logic handle all cases, including edge cases?
2. Security — Are there SQL injection, XSS, or authentication bypass risks?
3. Performance — Are there N+1 queries, unnecessary allocations, or blocking calls?
4. Error handling — Are errors caught, logged, and propagated correctly?
5. Consistency — Does the code follow existing patterns in the codebase?
If all criteria pass, respond with "LGTM" (Looks Good To Me).
If issues found, list each one with the file path and line number.「LGTM」というキーワードは重要です。レビューが通過したことを示し、ルーティングループを停止させます。
ステップ 2: Writer エージェントを設定する
Writer エージェントには、焦点を絞ったタスクを与えます。
Implement rate limiting for the /api/auth/login endpoint.
Use a sliding window algorithm with a limit of 5 attempts per minute per IP.
Store the window in Redis using the existing Redis client at src/lib/redis.ts.具体的なタスクほど具体的な変更が生まれ、レビュー品質も上がります。
ステップ 3: ルーティング接続を設定する
Writer と Reviewer を次の設定で接続します。
| 設定 | 値 | 理由 |
|---|---|---|
| Trigger | on-idle | レビュー前に Writer が完全に終わるのを待つ |
| Transform | ai-routing | AI がコンテキストを理解したレビュー用プロンプトを生成する |
| Max rounds | 3 | 無限レビューを防ぐ |
| Stop keyword | LGTM | Reviewer の承認で終了する |
| Cooldown | 5s | エージェントが完全な応答を返す時間を確保する |
ai-routing 変換がここでは重要です。Writer エージェントの完全な応答（Claude Code なら JSONL セッション解決経由）を読み取り、何が実装されたかを理解したうえで、変更された具体的なファイルと実装コンテキストを含むレビュー用プロンプトを生成します。
ステップ 4: 逆方向の接続を設定する
レビューのループを機能させるには、Reviewer から Writer への接続も必要です。
| 設定 | 値 | 理由 |
|---|---|---|
| Trigger | on-idle | ルートバック前にレビュー全体を待つ |
| Transform | ai-routing | レビュー指摘を修正指示に変換する |
| Max rounds | 3 | 反対方向でも同じ上限を使う |
| Stop keyword | LGTM | 承認済みなら戻さない |
逆方向の変換は、レビューコメントを実行可能な修正指示へ変換します。たとえば「src/middleware/rate-limit.ts:42 のレート制限バイパスを修正してください。プロキシ配下の X-Forwarded-For ヘッダーを考慮していません」のような指示です。
期待される流れ
典型的な自動レビューサイクルは次のようになります。
Round 1（Writer → Reviewer）:
- Writer が 3 ファイルにまたがるレート制限を実装する。
- ルータが実装サマリーを抽出し、Reviewer に送る。
- Reviewer が 2 つの問題を見つける。
X-Forwarded-Forの処理漏れと、429 応答のテスト不足。
Round 2（Reviewer → Writer → Reviewer）:
- ルータがレビュー指摘を修正指示へ変換する。
- Writer が両方の問題を修正し、欠けていたテストを追加する。
- ルータが更新後の実装を Reviewer に送る。
- Reviewer が「LGTM — rate limiting correctly handles proxy headers and has test coverage.」と返す。
停止: 「LGTM」キーワードが停止条件を発火させる。合計時間は約 8 分、2 ラウンドです。
自動レビューが特に有効な場面
- 焦点の絞られた変更 — 1 つの機能やバグ修正など、範囲が明確なもの。大規模で散漫な変更はレビューがノイジーになります。
- 明確な基準 — 何をもって「良い」とするかを定義できる場合。OWASP 基準によるセキュリティレビューや、特定 SLA を持つパフォーマンスレビューなど。
- 反復的な改善 — 最初の実装が 80% ほど正しく、完全な書き直しではなく仕上げが必要な場合。
人間のレビューを使うべき場面
- アーキテクチャ判断 — AI エージェントは実装品質をレビューできますが、そのアプローチ自体が正しいかまでは判断しません。
- チーム横断の影響 — 他チームに影響する変更には、組織上の優先度に関する人間の文脈が必要です。
- 機微なコード — 認証、暗号化、金融ロジックは、AI に加えて人間の目で見るべきです。
自動 AI レビューは、人間レビューの代替ではなく補完です。機械的な問題を先に拾う一次フィルタとして使い、人間のレビュアーが戦略的な問いに集中できるようにしましょう。
自動レビューのためのツール
このパイプラインは、2 つのターミナルウィンドウを使って手動でも設定できますが、レビュー出力のコピー、修正指示への再フォーマット、Writer への貼り付けといった手動の引き継ぎは面倒です。
MadoHub はこの流れを丸ごと自動化します。2 つのターミナルエージェントをキャンバスに配置し、接続を引き、trigger/transform/stop の設定を行って Writer を起動するだけです。あとはルーティングシステムが、抽出、変換、配信、ループ終了まで処理します。
まとめ
AI によるコードレビューの自動化は、マルチエージェントワークフローの中でも特に ROI の高い用途の 1 つです。
- 速い — レビューは数時間ではなく数秒で終わる。
- 一貫している — レビュー基準が毎回同じ。
- 反復しやすい — 問題はフォローアップ PR ではなく即座に修正される。
- 補完的 — 人間レビューと併用すると、より網羅的になる。
設定に必要なのは 5 分ほどです。節約できる時間は毎日積み上がります。