要点

対象：AIにコードを書かせているチーム

  1. 低リスクはAIレビューが通れば承認なし
  2. AIの承認は人の承認に数えない
  3. レビューが3回を超えたら方針を見直す

AnthropicのClaude Codeチームは、承認する人の数を、変更のリスクに応じて0〜2人にしています。どのPR（プルリクエスト）もAIがレビューしますが、AIの承認は人の承認に数えません。1

この記事の目次（5節）
  1. 3つのリスク区分と承認の人数
  2. マージしたPRは倍以上、リバートの割合は4割以上減少
  3. 人が判断し続ける5つのこと
  4. AIのレビューが終わらない問題の直し方
  5. 自社で試すときの主な方法と料金

チームは10月15日、このやり方をブログで公開しました。1

自社で試すなら、開発者が自分のブランチで/code-reviewを実行するのが手軽です。Team・Enterpriseプランなら、GitHubのPRを自動でレビューする「サービスのCode Review」も試せます。23

3つのリスク区分と承認の人数

区分ごとに、人の承認の数が決まっています。1

区分変更の例人の承認
低ドキュメント・UIの文言・社内向け機能・フィーチャーフラグで切り替えられる機能追加AIレビューとセキュリティのチェックが通れば不要
中ふつうの機能の変更と、キャッシュ・自動アップデート・システムプロンプトのような慎重に扱う箇所1人
高最もリスクの高いコードと、常に2人の承認を必須にしている一部のファイルやディレクトリ2人

区分は、書いた人ではなく変更の中身で決まります。変更を読んで区分を選ぶのは、人ではなく分類器（変更を読んで区分を選ぶ仕組み）です。1

ただし、承認を減らせるのは、リポジトリごとに決めた信頼できる作成者の名簿に載った人のPRだけです。名簿に載るのは、多くがそのリポジトリを持つチームの人です。名簿に載っていない人のPRは、区分が低くても、別の人の承認が要ります。1

AIの承認の扱い

AIレビューは、低リスクの変更を通すことはできます。ただ、人の承認が要る変更では、AIの承認を1人分に数えません。1

承認は、承認したときのコミットにだけ有効です。あとからエージェントがpushしたコミットや、手でコンフリクトを解消したマージが入ったら、承認し直します。1

マージしたPRは倍以上、リバートの割合は4割以上減少

Claude Codeのコードの約9割は、Claudeが書いています。6月から9月にかけて、マージしたPRは倍以上に増えました。1

同じ期間に、リバートしたPRの割合は4割以上減りました。1

人が判断し続ける5つのこと

AIが多くのコードを読むようになっても、チームは次の5つを人に残しています。1

  • 作るべきかどうか（方向性・センス・スコープ）
  • リスクの高いコード（課金・自動アップデート・CIのワークフロー）
  • ほかの人が踏襲する設計
  • 根拠を読むこと（テストの出力・実行したコマンド・スクリーンショット・AIの指摘）
  • 結果への責任（誰が書いたコードでも、リリースした変更の責任は人が持つ）

人の確認が追いつかない問題そのものは、t-wadaさんの「レビュー解体」の記事に詳しく書きました。

AIのレビューが終わらない問題の直し方

あるPRでは、AIのレビューと修正が一晩で50回を超え、書いた人が止めました。1

チームがgit blameで調べると、繰り返し指摘されたコードの約59%は、最初のレビューのときにはもうありました。AIは毎回、古いバグを少しずつ見つけていたことになります。1

そこで、AIレビューのやり方を4つ変えました。1

  1. 3回目のレビューの後は、AIのレビュアーが書いた人に方針の見直しを求める
  2. 最初の数回が済んだら、前回からの差分だけを見る
  3. 同じ種類のバグをまとめて指摘し、全部を直してもらう
  4. 一度出した指摘を、もう一度出さない

社内のPRの数字は次のとおりです。1

社内のPR4つを変える前変えた後
1回のレビューと修正で通った65%78%
5回以上かかった8.9%1.5%
通るまでのレビューの回数（平均）2.08回1.32回

自社で試すときの主な方法と料金

方法使える条件どこで動くか
サービスのCode ReviewTeam・Enterpriseプランで、GitHubのリポジトリを使う組織。組織のオーナー（Owner）が有効にするAnthropicの環境
コマンドの/code-reviewどのプランでも自分のClaude Codeのセッション
GitHub ActionsやGitLabのCIClaudeのAPIキーか、Amazon Bedrockなどクラウド事業者の認証情報がある自前のCI

サービスのCode ReviewはPRを承認もブロックもしないので、マージを決めるのはチームのままです。Zero Data Retentionを有効にした組織などでは使えません。2

REVIEW.mdに書くこと

サービスのCode Reviewには、リポジトリのルートにREVIEW.mdを置いて指示を出せます。何を重要な指摘とするか、Nit（細かい指摘）の数の上限、見なくてよいファイルを書けます。4

REVIEW.mdの指示のうち、指摘の重大度を下げる・見ないファイルを外す・Nitの数を絞るの3つが守られるのは、デフォルトブランチにブランチ保護を設定しているときです。4

PRの中でREVIEW.mdを変えても、そのPRのレビューには効きません。サービスのCode Reviewは、マージ先かデフォルトブランチにあるREVIEW.mdを読みます。4

コマンドの/code-reviewはREVIEW.mdを読まず、CLAUDE.mdを読みます。両方に効かせたいルールはCLAUDE.mdに書きます。34

サービスのCode Reviewの料金

1回あたりの決まった料金はありません。費用は使った分だけ、プランの利用枠とは別に、組織の利用クレジットから引かれます。5

1回の費用は、レビューの深さ（Quick・Standard・Deep）、変更の大きさ、周りのコードの複雑さなどで変わります。25

リポジトリを追加すると、最初は「After every push」になっています。pushのたびにレビューが走るので、レビューの回数がいちばん多い設定です。5

試す順番

  1. 開発者が、自分のブランチで/code-reviewを実行し、返ってきた指摘を読む
  2. オーナーが、サービスのCode Reviewの月の支出上限を決める5
  3. オーナーが、試すリポジトリで「Review runs」を「Once after PR creation」にする5
  4. 何回か動いたら、管理画面の「Average cost」で1回あたりの平均費用を見て、その平均に月のPRの数を掛ける5
  5. チームでリスク区分の表を作り、最初は厳しめに決めて、根拠がそろったら緩める1
  6. CODEOWNERSとブランチ保護で、認証・課金・CIやリリースのワークフロー・インストーラーの変更には、必ず人の承認が要るようにする1

Microsoft社内でPRがどれだけ増えたかは、研究者の分析にまとめています。Claude Codeの動き方は、Claude Codeの仕組みで図にしています。

先週マージしたPRを並べ、人が読まなくてもよかったPRが何本あったか数えるところから始められます。

出典

  1. Claude Blog「How the Claude Code team does code review」（2026年10月15日）（参照 2026-10-18）
  2. Claude Code Docs「Code Review」（参照 2026-10-18）
  3. Claude Code Docs「Review locally with /code-review」（参照 2026-10-18）
  4. Claude Code Docs「Customize Code Review」（参照 2026-10-18）
  5. Claude Code Docs「Code Review costs and usage」（参照 2026-10-18）