Claude Code チームのコードレビュー運用を自分のチームに入れる（REVIEW.md・リスク階層・ラウンド上限）

どんな時に使う？

• エージェントが PR を量産し、レビュー待ちがボトルネックになっている
• AI レビューを入れたが、指摘の往復が終わらない（エージェント同士で何十周も回る）

手順（公式記事の「導入のしかた」を要約）

PR を出す前

1. エージェントが自分で走らせられる検証（テスト・ビルド・デザインとのスクショ比較）を短い CLAUDE.md に書き、「終わった」ではなく出力を見せるよう指示。フォーマッタ・リンタは hooks で回す
2. ローカルで /code-review と /security-review、または文脈を持たないサブエージェントにレビューさせる
3. REVIEW.md を置き、同じレビューコメントが繰り返されたらそこへ移す。良い REVIEW.md は短く、
   • そのリポジトリでの「失敗」とは何かを書く（ドキュメントなら「嘘を書く」、設定なら「誤ったルーティング」）
   • nit の上限、見なくてよいパスを書く
   • 名前からの推測ではなくファイルと行番号を根拠にさせる
   • 要約は件数から始め、直すものが無いときははっきりそう書かせる

すべての PR で

4. CI 必須。PR テンプレートに「Testing」「Risk」「How to revert」
5. AI レビュー（Code Review for Claude Code か Claude Code GitHub Action）を1リポジトリから始め、数週間 REVIEW.md を調整してから広げる
6. セキュリティレビューも自動化し、全スレッドを解決しないとマージ不可に（直すか、理由を書いて閉じる）
7. 深さはリスクで変える（Code Review の Quick／Standard／Deep）
8. レビューのラウンド上限: 3周で「方針を見直して」と作者に返す。数周後は新しい差分だけ再レビュー。同じ指摘は繰り返さない。1行ではなく「バグの種類」を指摘して全箇所直させる

承認

9. リスク階層は「誰が書いたか」ではなく「変更内容」で決める（低: ドキュメント・フラグ裏の追加 → 人の承認なし／中: 通常の変更 → 1人／高: 課金・自動更新・CI → 2人）。最初は厳しく、根拠を見て緩める
10. 軽い承認ルートは信頼できる作者だけ。CODEOWNERS とブランチ保護で認証・課金・CI・インストーラは必ず人
11. ボットの承認を人の承認の代わりにしない。新しいコミットが来たら承認を取り消す

マージ後

12. マージキュー、フィーチャーフラグ、社内先行、段階リリース、1手でのロールバック
13. 障害と revert を eval セットにして、レビュアーのプロンプト・ツール・モデルを変えるたびに採点し直す
14. 測るのは「人の時間」（PR あたりの承認数・コメント数・待ち時間）。revert 率と障害率をガードレールにする

注意点

• エージェント作者はノイズに弱い。人なら数秒で流す nit でも、エージェントは直して1コミット・1レビュー増える。指摘のノイズを測る（直した／誤りと言った／意図通りと言った／どうでもいい、で分類）
• 同チームの調査では、繰り返し指摘の約59%は最初から存在した古いコード。毎回何周も回すのは高リスク変更だけにする
• 人に残るのは「そもそも作るべきか」「課金・CI など危険な所」「他が真似する設計」「証拠（テスト出力・スクショ）を読むこと」「結果の責任」
• コードの理解は差分を読む代わりに、触る前にその部分の解説を Claude に書かせて補う

出典

• @ClaudeDevs · 2026-10-17
• 記事: claude.dev
• @oikon48 · 2026-10-17