Claude Code チームのコードレビュー運用：7層と導入手順、実測つき

Anthropic が2026年10月15日に claude.dev で公開した「How the Claude Code team does code review」によると、Claude Code チームはコードレビューをやめたのではなく、コードを読む作業の大半を機械に移しています。変更は作者の手元での検証から、すべての PR への AI レビュー、セキュリティレビュー、CI、リスクに応じた人の承認、マージキューと段階リリース、すばやいロールバックまで7つの層を通ります。人の承認はドキュメントのような低リスクの変更なら0人、通常の変更は1人、最もリスクの高いパスは2人で、その区分は作者ではなく変更の中身で決まります。

自分のチームでまねするなら、プランに関係なく使えるローカルの /code-review から始め、レビューで守らせたいルールは CLAUDE.md に書いてください。2026年10月23日に Claude Code 2.1.309 で試すと、REVIEW.md に書いた「TODO を含む変更は Important」というルールはローカルの /code-review に無視され、同じ一文を CLAUDE.md にも書き足したら（REVIEW.md はそのまま）指摘されました。REVIEW.md が効くのは、Team / Enterprise プラン向けに GitHub 上で動くマネージドサービスの Code Review です。あわせて PR テンプレートに「テスト方法」「リスク」「戻し方」の3項目を足し、CODEOWNERS とブランチ保護で認証・課金・CI まわりの変更には必ず人の承認を求めます。

勘違いしやすいのは「AI レビューがマージを止める」という点です。Code Review は初期状態では PR を承認もブロックもしません。Anthropic 社内で未解決の指摘があるとマージできないのは自社リポジトリにそう設定しているからで、同じ止め方をしたいなら、ブランチ保護でレビューのスレッド解決を必須にするか、自分の CI で Code Review の結果を読んでジョブを失敗させる必要があります。

Claude Code の変更が通る7つの層と、外部チームが使える道具

Claude Code チームのレビューは、最後に1人のレビュアーが関門を守る形ではなく、それぞれがいくつかの問題を捕まえ、いくつかを見逃す層を重ねる形です。原文はこれを「書いている間に動くスペルチェック」にたとえ、多くの変更は人が見る前に少なくとも一度 Claude にレビューされ、修正されていると説明しています。各層の役割と、社外のチームが2026年10月23日時点で代わりに使える道具は次のとおりです。

1層目について、Claude Code の作者 Boris Cherny は、自分の仕事を検証する手段を Claude に与えると最終的な結果は2〜3倍良くなると見積もっています。これは本人の推定で、計測値ではありません。PR を開く前に多くのエンジニアが社内スキル（バグ探し、差分の簡素化、端から端までの動作確認）を回していますが、これらは公開されていません。公開されている近いものはバグを探す /code-review と、整理だけを見て修正まで適用する /simplify で、使い分けは Claude CodeのおすすめSkills：用途別の選び方と公式スキルの導入手順 で比べられます。

AI レビュアーが同じ指摘を繰り返すとき、チームはその場で直すだけでなく、スキル、lint ルール、指示ファイルのどれかに原因を戻します。CLAUDE.md はプロジェクトの構成、慣習、目的と非目的を書くファイルで、毎回のレビューで読み込まれるため短く保ち、詳細は別の文書に任せます。REVIEW.md はコードオーナーが書くレビュー専用の指示です。良いものは短く、そのリポジトリで何が失敗にあたるか（ドキュメントなら「嘘を書くこと」、設定なら「誤った宛先に流すこと」）を書き、Nit の数に上限を置き、飛ばしてよいパスを挙げ、名前からの推測ではなくファイルと行番号を根拠に求めます。CLAUDE.md がいつ読み込まれるかは Claude Code Memory ガイド（2026）：CLAUDE.md、auto memory、プラグインの分担 が詳しく扱っています。

2層目の AI レビューでは、複数のエージェントが並行してバグを探し、別のグループが各指摘に投票して、十分な数が本物と認めたものだけを投稿します。スタイルや整理だけの指摘は落とされ、このフィルタは自社の PR で A/B テストしてから採用されました。残った指摘は重大度順のインラインコメントになり、Important（マージ前に直すべきバグ）、Nit（軽微でマージを止めない指摘）、Pre-existing（この PR が持ち込んだのではない既存のバグ）のラベルが付きます。

承認0人・1人・2人を分けるのは作者ではなく変更の中身

Claude Code のリポジトリでは、人の承認が何人必要かを変更のリスクで決めています。分類器が変更を読んで区分を選び、別の分類器が「区分上は不要でも、この変更には人がもう1人要るか」を判断します。原文の区分は次の3つです。

この表だけを見ると「ドキュメントは誰も読まずにマージされる」と受け取れますが、軽い経路には条件があります。使えるのはそのリポジトリの信頼済み作者リストに載った人（主にそのコードを持つチーム）だけで、それ以外の人には2人目の承認が要ります。オーナーが機密と指定したパスと CI のワークフローファイルは、区分に関係なく必ず人が見ます。エージェントの承認は人の承認として数えず、エージェントが書いた PR では、そのエージェントに指示した人が必要なレビュアーの1人になります。承認は特定のコミットに対するもので、エージェントの push や手で解決したマージのように検証できないコミットが加わると、承認をやり直します。

変更の中身を読んで区分を決める分類器は公開されていません。社外のチームがまねするときは、CODEOWNERS でパスごとに承認者を決め、ブランチ保護で必要な承認数と新しいコミットでの承認取り消しを設定する、というパス単位の近似になります。

人はもうコードを読まないのか：人が手放していない5つの判断

読む量は減っていますが、人が判断から外れたわけではありません。原文によると、チームの人間が責任を持ち続けているのは、そもそもそれを作るべきかという方向性・好み・範囲の判断、課金や自動アップデーター、CI ワークフローのような危険なコードのレビュー、他の人がまねする設計パターンのレビュー、テスト出力や実行したコマンドと結果、スクリーンショット、レビュアーの指摘といった証拠を読むこと、そして出荷したすべての変更への責任です。証拠を読むときの基準は、チェックが何を見逃しうるかを言えないなら、気軽な承認ではなくきちんとしたレビューを頼む、という一文にまとめられています。

レビューのもう一つの役割だった「チームでコードの理解を共有する」部分には、正式な手順を設けていません。変更する前にその部分の解説を Claude に書かせたり、小さな可視化を作らせたりし、Slack のオープンなチャンネルで他の人の作業が見えるようにしています。小さな変更が問題を起こしたらマージした人が直すのがチームの約束（You land it, you own it）ですが、これは責めるための仕組みではなく、変更が小さく、フラグやリバートで数分以内に戻せることが前提です。方向を変えるべきだと思ったら、完成した PR へのブロックコメントではなく、早い段階でスレッドで言うよう求めています。

「9割」「PR 2倍」「リバート40%減」の数字が測っているもの

見出しになった数字はどれも Anthropic の自己申告で、母数が公開されていないものが多く、測っている対象もばらばらです。読み違えやすい点は次のとおりです。

「リバート率を目標にすると、その数字だけが良くなるのでは」という疑問には、原文自身が答えています。目標は人の時間を減らすことで、PR あたりの人の承認数（中央値と95パーセンタイル）、人のコメント数、PR が人を待つ時間を測っています。リバート率とインシデント率は、上がったら人の時間を節約したのではなく別の場所に移しただけだと判断するための歯止めです。また、これらの数字が悪化したときに自動で承認を厳しくする仕組み（サーキットブレーカー）はまだなく、人の承認なしのマージを広げる前に欲しいとエンジニア自身が書いています。

プラン別に使えるレビュー：/code-review と Code Review

どのプランでも始められるのはローカルの /code-review で、Pro / Max ならクラウドで動く ultrareview も試せます。PR ごとに自動でレビューを付けるマネージドの Code Review と、それを調整する REVIEW.md は Team / Enterprise だけのものです。2026年10月23日時点の Claude Code ドキュメントにもとづく比較は次のとおりです。

Code Review は2026年10月15日に一般提供が始まり、ほとんどのレビューが6〜10分で終わるようになりました（リサーチプレビュー中は約20分）。レビューレベルは Quick、Standard（既定）、Deep の3つで、組織の既定とリポジトリごとの上書きを Owner が選びます。Pro / Max の個人開発者でも、7つの層のうち2層目以外は近いものを組めます。PR ごとに自動で AI レビューを付ける部分だけは、Team / Enterprise の Code Review か、API キーで動かす GitHub Action が必要です。

ローカルの /code-review は REVIEW.md を読まない：2026年10月23日の実測

ローカルの /code-review は CLAUDE.md に従い、REVIEW.md は読みません。Claude Code のドキュメントは、-p を付けた非対話の実行でも CLAUDE.md に従うこと、REVIEW.md はマネージドの Code Review を設定するファイルであることを明記しています。両方で効かせたいルールは CLAUDE.md に、PR レビューだけのルールは REVIEW.md に、というのがドキュメントの勧める分け方です。

この違いを確かめるため、2026年10月23日に macOS 上の Claude Code 2.1.309 で、問題を4つ仕込んだデモリポジトリに claude -p "/code-review low" --output-format json を2回実行しました。add-discount ブランチが追加する discountedTotal() には、(a) ループ条件 i <= limit のため1件多く割引し、limit が商品数以上だと TypeError になるバグ、(b) 2つ目のループが limit から始まり同じ商品を二重に数えるバグ、(c) CLAUDE.md の「金額は常に整数のセントで保存・計算する」に反する浮動小数点の計算、(d) // TODO コメントがあります。(d) については REVIEW.md に「変更行に TODO を含むコメントは Important。TODO はマージしない」と書きました。コード中の (a)〜(c) の注記は説明のために足したもので、実行時のコードにはありません。

// TODO: support coupon codes
function discountedTotal(items, percent, limit) {
  let total = 0;
  for (let i = 0; i <= limit; i++) {            // (a)
    const line = items[i].priceCents * items[i].qty;
    total += line * (1 - percent / 100);         // (c)
  }
  for (let i = limit; i < items.length; i++) {  // (b)
    total += items[i].priceCents * items[i].qty;
  }
  return total;
}

1回目は TODO のルールを REVIEW.md だけに書いた状態で、17.2秒で終わり、(a)(b)(c) を行番号つきで指摘しました。(c) では CLAUDE.md のルールを名指しし、999 × 0.85 = 849.15 のように端数のセントが出ると説明しています。しかし (d) の TODO には触れませんでした。2回目は同じ TODO のルールを CLAUDE.md の末尾に足しただけで、ほかは変えていません。今度は8.7秒で (a)(b)(c) に加えて (d) を挙げ、プロジェクトのルールにより TODO を含む変更はマージできず Important にあたると指摘しました。CLI が出力したコストの推定値は1回目 $0.19、2回目 $0.09 で、API 価格で見積もったセッションの金額であり請求額ではありません。出力が中国語だったのはこのマシンの Claude Code の応答言語設定のためで、ここに書いた指摘内容は日本語での要旨です。

この結果は各条件1回、effort low、1台のマシンでの観察です。low は最も確信の高い指摘だけを返す設定で、モデルの出力は実行ごとに揺れます。Team / Enterprise のマネージド Code Review、ultrareview、/security-review は実行しておらず、それらについての記述は Claude Code のドキュメントにもとづきます。

Code Review は悪い PR を止めるか：初期状態では承認もブロックもしない

マネージドの Code Review は、PR を承認もブロックもしません。ドキュメントによると、レビューは指摘のインラインコメントと要約、「Claude Code Review」という名前のチェックランを残しますが、チェックランの結論は neutral（変更のない push の後は skipped）で、失敗にはなりません。必須チェックに入れても、指摘があるだけではマージは止まらないということです。

原文の「バグレビューかセキュリティレビューの指摘が残っている間は PR をマージできない」は、Anthropic が自社のリポジトリに設定しているルールです。指摘は修正するか、短い理由を書いてスレッドを閉じれば解除でき、誤検知はこの方法で外します。後のコミットで問題が直れば、指摘は自動で消えます。同じことを社外で再現する方法は2つあります。1つは、原文のチェックリストにあるとおり、GitHub のブランチ保護で「Require conversation resolution before merging」を有効にし、レビューのスレッドをすべて解決しないとマージできないようにする方法です。もう1つは、Code Review のドキュメントが紹介している、チェックランの詳細の最終行を自分の CI で読む方法です。

<!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->

normal が Important の件数なので、これが1以上ならジョブを失敗させます。この行がないときは「指摘0件」ではなく「判定なし」として扱うよう、ドキュメントは注意しています。この方法は gh と jq を使うドキュメントの手順で、2026年10月23日の実測には含まれていません。手順の全体は Claude Code ドキュメントの「Read and request reviews on a pull request」 にあります。

Code Review と ultrareview の費用：定額はなく、使用クレジットで決まる

Code Review に1回いくらという定額はありません。2026年10月23日時点の Claude Code ドキュメントの Code Review の費用ページ によると、トークン使用量に応じて使用クレジット（usage credits）から課金され、プランに含まれる利用枠とは別に、PR の作者ではなく組織に請求されます。1回の費用はレビューレベル、変更の大きさ、周辺コードの複雑さ、検証する候補の数で変わります。管理画面から追加したリポジトリは「After every push」で始まるため、push の回数だけ費用が増えます。

ドキュメントが勧める見積もり方は試験導入です。月の上限額を設定し、代表的な数リポジトリを「Once after PR creation」か手動（@claude review）で有効にし、Admin settings > Claude Code の Average cost 列にある1回あたりの平均費用に、月の PR 数を掛けます。After every push にする場合は、さらに PR あたりの push 回数を掛けます。リサーチプレビューの頃に第三者の記事などで出回った「1回 $15〜25」という数字は、現行のドキュメントにはありません。対象の Enterprise 組織は2027年1月15日までに少なくとも $10,000 分の Code Review クレジットを受け取れ、受け取りから30日で失効します。

ultrareview は Pro / Max で一度きりの無料3回があり、その後は変更の大きさに応じて通常1回 $5〜25 の使用クレジットがかかります。ローカルの /code-review は普段のセッションと同じくプランの利用枠か API 課金に含まれ、2026年10月23日の実測（数十行の差分、effort low）では1回 $0.2 未満の推定値でした。使用クレジットの仕組みと上限の付け方は Claude 追加利用の料金：クレジット、Max、Claude Code の見極め で確認できます。

自分のチームに Claude Code のレビューを導入する手順

原文の最後にあるチェックリストを、どのファイルに何を書くかに落とすと次の順番になります。ほとんどはどのプランでもできますが、3の REVIEW.md が効くのは Code Review だけで、5には Team / Enterprise か API キーが必要です。

1. CLAUDE.md に、Claude が実行できる確認コマンド（npm test など）と、レビューでも守らせたいプロジェクトのルールを短く書きます。ローカルの /code-review と Code Review の両方がここを読みます。フォーマッタや lint は hooks で毎回回すと、レビューの指摘がスタイルで埋まりません。設定例は Claude CodeのHooks・Skills・スラッシュコマンドを使い分ける：呼び出し方と設定例 にあります。
2. PR を開く前に /code-review と /security-review をローカルで実行し、指摘を直してから push します。/code-review --fix を付けると修正まで適用されます。
3. リポジトリのルートに REVIEW.md を置き、レビューで繰り返し出る指摘をここに移します。Code Review は REVIEW.md を PR 自身の変更からではなくベースブランチかデフォルトブランチから読むので、先にマージしておきます。Important の基準を下げる、パスを除外する、Nit に上限を置くといった指示は、保護されたデフォルトブランチにあるルートのファイルからしか反映されません。
4. PR テンプレートに「テスト方法」「リスク」「戻し方」の3項目を足します。Claude に埋めさせてもかまいませんが、変更を頼んだ人が内容を確認します。
5. AI レビュアー（Code Review か Claude Code GitHub Action）を1つのリポジトリだけで有効にし、数週間 REVIEW.md を調整してから広げます。Code Review なら月の上限額を設定し、レビューレベルは普段のリポジトリを Quick、1つの見逃しが高くつくリポジトリを Deep にします。
6. CODEOWNERS とブランチ保護で、認証、課金、CI とリリースのワークフロー、インストーラーの変更には必ず人の承認を求めます。bot の承認を必要な人の承認の代わりにせず、新しいコミットが来たら承認を取り消す設定にします。
7. マージキュー、フィーチャーフラグ、段階リリース、ワンステップのロールバックを用意し、リバート率とインシデント率を記録してから承認の条件を緩めます。

手順3の REVIEW.md は、Code Review ドキュメントの例を縮めると次のような形になります。原文が勧める「このリポジトリで何が失敗か」「Nit の上限」「飛ばすパス」「根拠の要求」がそれぞれ1節です。

# Review instructions

## このリポジトリでの Important
本番の挙動を壊す、データを漏らす、ロールバックを妨げる指摘だけを Important にする。
命名やリファクタリングの提案は最大でも Nit。

## Nit の上限
1回のレビューで Nit は最大5件まで。

## 報告しない
- CI がすでに見ているもの（lint、フォーマット、型エラー）
- `src/gen/` 以下の生成ファイルと `*.lock`

## 必ず確認する
- 振る舞いについての指摘には、名前からの推測ではなく file:line の根拠を付ける
- 新しい API ルートには結合テストがある

手順6の CODEOWNERS は、必ず人が見るパスと担当チームを対応させます。GitHub のブランチ保護で「Require review from Code Owners」と「Dismiss stale pull request approvals when new commits are pushed」を有効にすると、該当パスの変更にはオーナーの承認が要り、新しいコミットが来るたびに承認が取り消されます。

# .github/CODEOWNERS
/.github/workflows/  @your-org/platform
/src/auth/           @your-org/security
/src/billing/        @your-org/billing
/scripts/install*    @your-org/release

AI 同士のレビューが終わらないとき：往復回数を抑える4つのルール

作者も AI、レビュアーも AI だと、互いに仕事を作り続けることがあります。原文では、ある CLI の PR が一晩で50回を超えるレビューと修正を繰り返し、作者が止めるまで続きました。繰り返し指摘されたコードを git blame で調べると、約59%はレビュアーの最初の回から存在していたコードで、新しいバグではなく古いバグを毎回少しずつ見つけていただけでした。人なら数秒で流せる Nit も、エージェントの作者は直そうとしてコミットとレビューを1回ずつ増やします。チームが入れた次の4つの変更は、自分のレビュー設定や REVIEW.md にそのまま持ち込めます。

• 3回往復したら、レビュアーが作者にやり方そのものの見直しを求める。
• 最初の数回の後は、新しく変わった差分だけを再レビューする。
• 1行ではなくバグの種類を指摘し、同じ種類の箇所をまとめて直させる。
• 一度投稿した指摘は繰り返さない。

チームはこれに加えて、過去にインシデントを起こした PR と、その修正やリバートを集めた評価セットでレビュアーを毎日走らせ、レビュアーを変えるたびにその全体で採点しています。優先順位は、本物のバグを捕まえることが1番目、レビューの往復を減らすことが2番目と明文化されています。