AI にコードの大半を書かせるようになると、先に詰まるのは実装ではなくレビューです。PR の数が増え、1 本ずつ人が行単位で読む運用が追いつかなくなります。かといってレビューを緩めると、戻しや障害が増えるのではないかという不安が残ります。
2026 年 10 月 15 日、Anthropic が How the Claude Code team does code review を公開しました。Claude Code のコードの約 90% を Claude が書く前提で、自分たちがどうレビューしているかを書いた記事です。この記事では、公開された運用と数字、REVIEW.md の書き方、Code Review for Claude Code の仕様を、公式情報の範囲で整理します。AI が書いたコードのレビュー設計の一般論は AI 生成コードのレビュー設計 で扱っているので、あわせてご覧ください。
Anthropic が公開した Claude Code チームのレビュー運用
ブログの趣旨は、読む作業の多くを自動検査へ移し、人の注意は危険な変更や判断の要る変更に残す、というものです。著者は Addy Osmani、Morgan Westlee Lunt、Qing Wang の 3 名です。
ブログが挙げる主な数字を表にまとめます。
| 項目 | 内容 |
|---|---|
| Claude が書く割合 | Claude Code 自身のコードの約 90% |
| マージされた PR | 6 月から 9 月にかけて 2 倍超。revert された割合は 4 割超減 |
| モノレポの 1 日あたりの変更 | 5 月は約 2,500 件、9 月は 3 万件超 |
| 実質的なコメントが付く社内 PR | 16% から 54% |
| 1 回のレビューと修正で通る PR | 65% から 78% |
| 5 回以上のレビューが必要な PR | 8.9% から 1.5% |
| 通るまでの平均レビュー回数 | 2.08 回から 1.32 回 |
人のレビューの目標は、revert や障害を増やさずに、ほとんどの PR を人が 1 人以下の関与でマージすることだと書かれています。
収束の工夫も具体的です。レビュー担当が繰り返し指摘していたもののうち、約 59% は最初のレビューの時点からあったコードだったと、ブログは書いています (git blame で確認したとのことです)。夜間に 50 回超のレビューを回した CLI の PR もあり、3 回を超えるとレビュー担当が作成者に方針の再考を求めます。
数字は Anthropic の社内データです
上の数字は、Anthropic が自社のリポジトリで測ったものです。リポジトリの性質、テストの整備、PR の大きさ、使っているモデルが違えば、結果は変わります。「16% から 54%」を、自社で同じ値になる目標として社内に出すのは避けてください。
FIXITAnthropic が 16% から 54% って言うなら、うちも同じになるの？
Tsukasa同じになるとは言えません。社内データですから、効果は自社の PR で測り直します。
FIXITじゃあ、この記事の数字は何の役に立つの？
Tsukasa結論から言うと、運用の設計図として読んでください。何を自動化し、どこに人を残すかの参考になります。
人が読む前に通す検査
ブログによると、典型的な CLI の PR は、人が見る前に数十の自動チェックを通ります。構成する層は次のとおりです。
- CI
- 並列エージェントと検証エージェントによる AI レビュー (Code Review for Claude Code)
- セキュリティレビュー (/security-review と、オープンソースの GitHub Action)
- merge queue、フィーチャーフラグ、段階的なリリース
セキュリティレビューで見つかった指摘は、修正されるか理由つきで閉じられるまで、マージを止めます。リリースは latest チャンネルが先で、stable チャンネルはそれより遅れて追随します。
プロジェクトの文脈は CLAUDE.md に置き、毎回のレビューで読み込ませます。スタック、規約、目標、目標にしないことを書く場所です。
Code Review for Claude Code の仕組み
ブログは、Code Review for Claude Code が Team と Enterprise で一般提供されていると書いています。公式ドキュメントの内容は次のとおりです。
- 複数のエージェントが、差分と周辺のコードを並行して読み、論理エラーやセキュリティ上の問題などを探す
- 検証の段階が、候補の指摘をコードと照らし合わせ、誤検知を除く
- 残った指摘は重複を除いて重大度順に並び、インラインコメント、要約、チェックランとして PR に付く
- 既定では、本番を壊すバグなどの正しさに絞って指摘する。書式の好みやテストの不足は対象にしない
- レビューは PR を承認もブロックもしない。マージの判断はチームに残る
- レビューはコードをビルドも実行もせず、差分と周辺のコードを読んで行う
レベルは Quick・Standard・Deep から選びます。Standard が既定で、Deep は最も時間と費用がかかります。組織で 1 つのレベルを決め、リポジトリごとに変えることもできます。たとえば、定型的なコードベースは Quick、重要なコードベースは Deep、といった使い分けです。
実行のタイミングは、PR を開いたとき 1 回、push のたび、手動 (@claude review のコメント) から選べます。管理画面で追加したリポジトリの初期値は「push のたび」で、これが最も実行回数が多くなります。
使える条件と費用
公式ドキュメントでは、対象は Team と Enterprise のプランで、コードのホスト先は GitHub です。ゼロデータ保持や HIPAA 構成を適用した組織、顧客管理の暗号鍵 (CMEK) を使う組織では使えません。
料金は定額ではありません。トークン使用量に応じて、プランに含まれる利用量とは別の使用量クレジットから課金され、請求は PR を開いた開発者ではなく組織に付きます。1 回あたりの費用は、レベル、変更の大きさ、周辺コードの複雑さ、検証が必要な候補の数で変わります。月額の上限を組織で設定でき、上限に達するとレビューはスキップされます。広げる前に、少数のリポジトリで「PR 作成時に 1 回」か「手動」に設定して平均費用を測る、という手順が公式に示されています。
ローカルの /code-review との違い
Claude Code のセッションで実行する /code-review は、どのプランでも使えます。公式ドキュメントでは、サービス版は CLAUDE.md と REVIEW.md の両方を読み、ローカルの /code-review は CLAUDE.md だけを読んで REVIEW.md は読まない、と区別されています。両方に効かせたい指示は CLAUDE.md に書き、REVIEW.md は PR レビュー専用の規則に使います。
REVIEW.md の書き方
REVIEW.md は、リポジトリのルートに置くレビュー専用の指示です。自由な Markdown で、レビューの形式は変えず、何を見つけて何を報告するかを変えます。サブディレクトリにも置け、そのパス配下の変更に対する検査を、ルートのファイルに上乗せできます。
ブログが示す、よい REVIEW.md の指針は次のとおりです。
- 短く保つ
- そのリポジトリで失敗とは何かを書く (ドキュメントなら「嘘をつくこと」、設定なら「誤った経路に流すこと」)
- 細かい指摘 (nit) の上限数を決める
- 見なくてよいパスを挙げる
- 根拠として、名前からの推測ではなく、ファイルと行を求める
- 要約は件数から始め、直すものが無いときはそう書く
公式ドキュメントの例も、同じ方向です。「Important」の意味を定義し直し、nit は 1 回のレビューで 5 件までに抑え、CI がすでに検査している lint や書式、生成ファイルは報告させません。「新しい API ルートには統合テストがあること」のような、自分たちの規則も書けます。
どのブランチの REVIEW.md が読まれるか
Code Review は、PR 自身の変更ではなく、PR の基準ブランチかデフォルトブランチの REVIEW.md を読みます。つまり、REVIEW.md を変えたい場合は、先にその変更をマージします。デフォルトブランチを保護しておくと、重大度を下げる、パスや分類を対象から外す、nit の数を抑える、といった指示がルートのファイルから反映されます。保護の条件など細かい点は、公式の Customize Code Review で確認してください。
リスクに応じた人の承認
人の承認を何人にするかは、リスクで決めます。ブログの区分は次のとおりです。
| リスク | 例 | 人の承認 |
|---|---|---|
| 低 | ドキュメント、文言、社内向け機能、フラグの裏の追加的な変更 | 不要 (自動レビューとセキュリティ検査が通っていること) |
| 中 | 通常のプロダクトの変更。キャッシュ、自動アップデータ、システムプロンプトなどの慎重を要する領域 | 1 人 |
| 高 | 最もリスクの高いコードと、常に 2 人を要するパス | 2 人 |
さらに、次の規則が添えられています。
- 区分は分類器が、作成者ではなく変更の内容から付ける
- 軽い経路を使えるのは、信頼された作成者だけ。それ以外は 2 人目の承認が要る
- エージェントの承認は、人の承認に数えない
- エージェントが書いた変更をプロンプトで指示した人は、必須のレビュー担当に数える
- 承認は特定のコミットに対するもの
FIXIT低リスクなら、人が誰も見なくていいのは不安だな。
Tsukasaブログでは、自動レビューとセキュリティ検査が通ることが条件です。区分は作成者ではなく、変更の内容で決まります。
自社に持ち込むときの順番
ブログの数字も運用も、Anthropic の環境のものです。持ち込むときは、全部を一度に真似せず、次の順に進めるのが安全です。
- 人の承認を残す変更の範囲を決める。どのパスを高リスクにし、区分を誰が付けるかも決める
- 自動検査が通ることを、マージの条件にする
- 少数のリポジトリで AI レビューを試し、自社の PR で指摘の質と費用を測る
- 測った結果をもとに REVIEW.md を育てる。nit の上限と、見なくてよいパスから始める
- 承認を減らす区分は、2 から 4 の結果を見てから広げる
「AI のレビューが通ったから大丈夫」とは言えません。公式ドキュメントも、AI のレビューは見落とすことがあり、指摘が無くても欠陥が残っている場合があると注記しています。人の注意を減らす区分と、残す区分を分けて決めるのが、この運用の中心です。
FIXIT の運用 — レビューの前提となる利用ルールを整える
FIXIT は、AI 駆動開発のクリエイティブスタジオとして、Claude Code などの AI 開発ツールの導入と定着を支援しています。レビュー体制の見直しは、ツールの利用ルールやガバナンスの整備と切り離せません。どの変更を AI に任せ、どこで人が判断するかは、組織ごとに答えが違うためです。
この記事の内容を自社に当てはめるのに迷う場合は、AI 開発ツール定着支援 で、承認の区分や利用ルールの整理からご相談いただけます。
次の一歩
まず、自社の PR を高・中・低に分けるとしたら、どのパスが高リスクかを書き出してみてください。区分の案ができれば、AI レビューを試す範囲と、人の承認を残す範囲が決まります。
Claude Code をチームで導入する流れは Claude Code のチーム導入プレイブック に、品質保証の考え方は AI 駆動開発の品質保証 にまとめています。個別の事情に合わせた整理が必要な場合は、お問い合わせ からご相談ください。