AIアシスタントを活用した自動開発が普及するにつれ、個人の開発現場でも「エージェントにコードを書かせ、別のエージェントにレビューさせる」という自動化アプローチが試みられています。
しかし、実際に試してみると「レビュー側と修正側が同じ指摘や修正を延々と繰り返し、泥沼のループに陥る」という問題に直面することがあります。なぜエージェント同士のやり取りは収束しにくくなるのでしょうか。また、安全性を担保しながら実用的にコードレビューを回すにはどのような設計が必要なのか。
2026年10月15日に公開された記事「How the Claude Code team does code review」（Addy Osmani, Morgan Westlee Lunt, Qing Wang）では、Claude Code開発チームにおける社内コードレビューの運用実態と、そこで直面した課題・対策が明かされています。本記事では、この同社の公開情報をもとに、エージェントレビューが不全に陥る仕組みと収束のための設計論を整理し、個人開発等に応用できる一般的な移植案とその限界について考察します。
1. エージェントレビューが循環する仕組み：夜間50回超の往復
Anthropicの報告によると、コーダーとレビュー役のエージェントを連携させた際、夜間に50回を超えて指摘と修正が往復する事例が発生したとされています。
ループが発生する主な現象
報告で挙げられている具体的な現象は以下の通りです。
- 同じ指摘の重複: 修正を試みても、レビュー側が同種の指摘を繰り返し出し続ける。
- スコープ外への指摘増大: 今回の変更点（diff）だけでなく、以前から存在していた周辺コードに対する指摘が増えていく。
（注：これらについて「AIが役割を誠実に果たそうとした」あるいは「修正側が手探りで対応した」といった心理的・内面的な因果関係は公開資料からは確認できず、報告されているのはあくまで上記の客観的な往復現象と指摘傾向です。）
このような無限ループや脱線を防ぐため、同社ではレビューの運用に対して以下のような明確な制御ルールを導入しています。
収束のための具体的なルール
- 3ラウンド後の再考 (Step Back): 3ラウンド（3往復）のレビューを経ても解決しない場合は、機械的に修正を続けるのではなく、一度立ち止まってアプローチや方針自体を再考する（
After three rounds, the reviewer asks the author to step back and reconsider the approach.）。 - 初期数回後の diff 限定化 (Diff-only re-review): 初期数回（
first few passes）のやり取りを終えた後の再レビューでは、PR全体ではなく、新しく生じた変更点（diff）を中心に点検する。 - 同類不具合の集約: 個別に出てくる同系統の指摘をまとめ、一括して扱えるようにする。
- 既出指摘の重複防止: 既に提示した指摘を繰り返さないフィルタリングを行う。
2. Anthropic社内における多層防御と人間の責任範囲
人間のレビュー時間を減らしつつ、事故やrevert（差し戻し）を増やさないために、同社では単一のエージェントに依存しない多層的なレビュー・検証体制を構築しています。
多層的検証アルゴリズムの全体像
- 証拠の重視: テスト実行結果、コマンド出力、画面ログなど、実行して確かめられる「証拠」をPR前に用意する。
- 複数エージェントによるノイズ削除: 不具合候補を探すエージェント群と、それを確かめる検証群を分離し、重複や誤検出（ノイズ）を落とす。
- 段階的なリスク管理: バグレビュー、専用セキュリティレビュー、CI、リスクに応じた人間の承認判断、merge queue、段階リリース、フラグ（flags）制御、監視、当番（on-call）による対応やrevertを重ねる。
なお、事故率に応じて自動的に承認条件を厳格化するサーキットブレーカー（circuit breaker）機能については、現時点では未実装とされています。また、障害発生時の対応体制として監視や当番、revert手続き等が説明されていますが、手動・自動を含めた詳細なロールバック実装の全容が公開されているわけではありません。
人間の承認権限と責任
社内制度において、変更のリスクに応じた人間の承認人数が定められています。
- 軽い経路の優遇: 信頼済み作者による低リスクな変更には簡易な経路が適用される。
- 人間の必須関与: 機微なパスやCIワークフローの変更等では人間の承認が必須であり、エージェントによる承認は人間の枠を満たさない。
- 特定コミットへの紐付け: 承認は特定コミットに対して行われる。システムが保証できない追加コミット（手動でのコンフリクト解消マージや外部プッシュ等）が入った場合は、再承認が必要となる。
同社において、人間は「作るべきかの意思決定」「全体設計」「危険な変更の判断」「証拠の読み解き」、そして「最終的な結果責任」を担っています。
レビュー精度の継続的評価
レビュー品質を維持するため、同社では以下の日次評価を行っています。
- 過去に事故を起こしたPRやその修正・revertを、該当コードに精通したエンジニアが確認して評価セットを作成する。
- 既知の正常なPRに対してもレビューを実施し、有害な変更を促してしまう「誤指摘」の発生率を測定・評価する。
3. 提供サービスとしての「Code Review」と社内運用の違い
Anthropicが一般ユーザー向けに提供している「Code Review」機能と、社内で実践されている運用体制は区別して理解する必要があります。
公開サービスの主な仕様
- 対象プランと設定: GitHub Appを組織Ownerが設定するTeam/Enterprise向け機能で、Anthropic側の基盤で実行される。
- レビューの深さ: Quick / Standard / Deep から選択可能。
- ブロック権限なし: サービス自体はPRの承認やマージブロックを行わない。指摘がゼロであっても、バグや脆弱性がないことを保証するものではない。
- 料金体系: 通常のプラン利用枠とは別の token usage credits による課金となる。1回あたりの固定料金ではなく、変更量、周辺コンテキスト、検証候補、深さ、起動回数等によって変動する。初期設定（新規登録リポジトリ）では「After every push」が選択されており、月額上限超過や残高不足時にはレビューがスキップされる。
- セッション内レビュー（/code-review）: ローカルCLI等での
/code-reviewコマンドは全プランで利用可能だが、通常プラン枠またはAPI課金を使用する。なお、「ローカル」という名称はオンデバイス推論や無料を意味するものではない。また、リポジトリ指示ファイルとしてCLAUDE.mdを参照するが、Webサービス向けのREVIEW.mdは読み込まない。
4. 個人開発・小規模運用への移植案とその限界
Anthropicの社内知見を参考に、個人の自動化スクリプトやCI環境へレビューロジックを移植する場合の一般的な設計案と、その技術的限界を整理します。
制御パターンの移植案（提案）
既存のエージェント運用において、泥沼化を防ぐために以下のようなデータ構造と検証フローを構築することが考えられます。
- 対象diffのハッシュ化とログ結合: 未コミットの編集を含むレビューに対応するため、対象となる
diff自体のハッシュ値を生成し、テスト実行ログや検証結果と一対一で対応付ける。 - 構造化された指摘フォーマット: 指摘ごとに「発生場所」「発生条件」「再現/反証根拠」「対処理由」を明確に記録させる。
- カウント制御: 往復回数をカウントし、3ラウンドに達した時点で自動的にイテレーションをストップし、人間にバトンタッチする。
移植案の限界と留意点
この移植案を実施するにあたっては、以下の限界を認識しておく必要があります。
- ハッシュ照合の限界: JSONやハッシュ値の整合チェックは、対象diffとテスト・検証記録の対応関係を照合できるに過ぎない。暗号論的な署名や信頼できる不変の基準がない環境で、diffとログのハッシュが同時に書き換え可能な場合、改ざん防止や改ざんの有無を証明することはできず、証拠内容の真偽、レビューの独立性、未検証範囲の網羅性、検出精度、セキュリティ、本人承認などを保証するものでもない。
- 品質実証の有無: 合成テストの通過やスクリプトの完走をもって「コード品質が向上した」と実証されたわけではない。
- モデル依存性: Anthropic社内の成果や数値を参照したとしても、異なるモデルや環境を用いた場合に同等の精度や効果が得られる保証はない。
- 再現の不完全性: この簡略化された移植案は、同社が実践している「多層レビュー体制」「並列合議」「専用セキュリティレビュー」「ブランチ保護」「merge queue」「事故評価の日次ループ」といった組織的・基盤的運用全体を再現するものではない。
5. まとめ
エージェント同士のコードレビューを成立させるためには、単にAI同士に対話させるのではなく、「3ラウンドでの打ち切り」「変更点（diff）へのフォーカス」「実証的な証拠の要求」といった明確な外生ルールと境界条件を設けることが不可欠です。
AIによる自動化を取り入れる際も、すべてのリスク判断や結果責任は人間側にあるという原則を踏まえ、適切なフィードバックループと上限を設定することが推奨されます。
参考リンク
- How the Claude Code team does code review (Anthropic Engineering Blog) — Claude Code開発チームにおける社内コードレビュー運用とループ防止・多層検証の解説。
- Claude Code Documentation - Code Review Overview — Team/Enterprise向けGitHub App連携コードレビュー機能の概要 docs。
- Claude Code Documentation - Code Review Setup — 組織OwnerによるGitHub App設定とリポジトリ連携手順。
- Claude Code Documentation - Code Review Costs — token usage creditsによる従量課金やスキップ条件に関する仕様。
- Claude Code Documentation - Local Code Review — CLI端末からの
/code-reviewコマンド仕様と設定ファイルの扱い。
この記事は Gemini Flash が執筆しました。