Claude Codeのコードは、いまや約9割をClaude自身が書いています。モノレポに入る変更は、5月の1日2,500件から9月には3万件になりました。人間が全部の差分を読むのは、もう物理的に無理な量です。
それでもチームは、6月から9月でマージしたPRを2倍超に増やしながら、リバートされる割合を4割以上減らしました。Anthropicが10月15日にclaude.devブログで公開した記事は、その仕組みを7つの層とチェックリストで明かしています。
私がこの記事から持ち帰るべきだと思ったのは「AIにレビューさせろ」ではありません。人の注意を、変更のリスクに応じて配る仕組みを先に決めることです。そして、そのまま真似すると引っかかる落とし穴が、公式ドキュメント側に2つあります。小さなチームが今週から始められる順番と合わせて書きます。
「人間が読んだか」をやめて「何が壊れうるか」で決める
記事の出発点は、レビューの目的の捉え直しです。チームは「人間がコードを読んだか」を、変更の安全性を測るには不正確な物差しだと言い切りました。代わりに問うのは、その変更で何が壊れうるか、そしてそれを見つけるのは自動チェックと人のどちらが向いているか、です。
レビューの位置も変わりました。以前はPRを開いた後の最終関門でしたが、今は書いている最中にスペルチェックのように回り続けます。人に声がかかる時点で、ほとんどの変更はClaudeによるレビューと修正を少なくとも1回経ています。
自動レビューを入れた後、実質的なレビューコメントが付くPRの割合は16%から54%に上がりました。素通りしていたPRの多くに、中身のある指摘が付くようになったわけです。
人の承認は「変更」で決まる。作成者の肩書きでは決まらない
7つの層は、PR前の検証、AIレビュー、独立したセキュリティレビュー、CIの自動チェック、人の承認、マージキューとフィーチャーフラグ、そして素早いロールバックです。このうち、ほかのチームがいちばん参考にしやすいのは5つ目の人の承認の決め方です。
| 区分 | 例 | 必要な人の承認 |
|---|---|---|
| 低 | ドキュメント、文言、社内限定の機能、フラグの裏に隠れた追加 | なし（自動チェックが通れば） |
| 中 | 通常の製品変更、キャッシュや自動更新、システムプロンプトなど敏感な領域 | 1人 |
| 高 | 最もリスクの高いコードと、常に2人が必要と決めたパス | 2人 |
区分は分類器が変更内容を読んで決めます。目を引くのは、その周りのルールです。区分は作成者ではなく変更で決まる。軽い承認経路を使えるのは信頼された作成者だけ。エージェントの承認は人の承認に数えない。承認は特定のコミットに対するもので、エージェントが新しくプッシュしたら承認し直し。CIのワークフローファイルは、どの区分でも必ず人が見ます。
「AIが書いたコードの責任は誰が持つのか」という問いにも、はっきり答えています。変更を指示した人が、その変更の責任者です。
AI同士のレビューは放っておくと終わらない
記事の中で私がいちばん実務的だと感じたのは、作成者もレビュアーもエージェントのときに起きる問題です。両者は延々とお互いを忙しくさせ続けます。
理由の説明が鋭いです。人間なら細かい指摘は数秒で流せますが、エージェントは律儀に直してしまう。直せばコミットが1つ増え、レビューがもう1回走ります。雑音のコストは、作成者がエージェントのほうが高いのです。
チームが入れた対策は4つです。3ラウンドを終えたらレビュアーが作成者に一歩引くよう求める。最初の数回の後は新しい差分だけを見直す。個別の箇所ではなくバグの種類を指摘し、全箇所を直させる。一度出した指摘は繰り返さない。これで1回で通るPRは65%から78%に、5回以上かかるPRは8.9%から1.5%に減り、平均のレビュー回数は2.08回から1.32回になりました。
Claude CodeやCodexに「レビューして直して」を繰り返させている人なら、思い当たる節があるはずです。往復の回数に上限を決めるだけでも、トークンと待ち時間の両方が減ります。
REVIEW.mdの落とし穴：ローカルの/code-reviewは読まない
記事のチェックリストは、PR前にローカルで/code-reviewと/security-reviewを回し、REVIEW.mdを追加して、繰り返し出る指摘をそこへ移すよう勧めています。ここで1つ目の落とし穴があります。
ローカルの/code-reviewのドキュメントには、このコマンドはCLAUDE.mdに従うがREVIEW.mdは読まない、と明記されています。REVIEW.mdを読むのは、GitHubのPRに対して動くマネージドのCode Reviewサービスだけです。手元のレビューにもPRのレビューにも効かせたいルールは、CLAUDE.mdに書く必要があります。
2つ目は、どのブランチのREVIEW.mdが読まれるかです。カスタマイズのドキュメントによると、Code ReviewはPR自体の変更からではなく、ベースブランチかデフォルトブランチから読みます。新しいルールを試すなら、先にREVIEW.mdの変更をマージしておかなければなりません。
さらに、デフォルトブランチを保護していないと、サブディレクトリに置いたREVIEW.mdは読まれず、ルートのファイルだけになります。保護の状態を確認できない構成では、何も読まれません。指摘の重大度を下げる、パスを除外する、細かい指摘の件数に上限を設けるといった指示が確実に効くのは、保護されたデフォルトブランチ上のルートのファイルです。
「REVIEW.mdを書いたのに効いていない」と感じたら、まずブランチ保護を疑うのが近道です。
料金：マネージド版は従量課金で、既定は一番高い設定
記事自体はコストに触れていません。導入を判断するなら、ここは自分で押さえる必要があります。
マネージドのCode ReviewはTeamとEnterpriseプラン向けで、GitHubのリポジトリが対象です。コストのドキュメントによると、1回あたりの定額はなく、プランに含まれる使用量とは別の使用クレジットからトークン量で課金されます。費用はレビューのレベル（Quick、Standard、Deep）、変更の大きさ、周辺コードの複雑さ、検証する候補の数で変わります。
注意したいのは、管理ページから追加したリポジトリが「After every push」、つまりプッシュのたびにレビューする設定から始まる点です。エージェントが細かくプッシュするチームほど、回数がそのまま費用になります。
費用の目安として、3月の提供開始直後にCanlyのCTOがZennで公開した記録があります。約70行のMarkdownのPRで31.54ドル、大きめのGoのPRで77.96ドルでした。同じ記事では、ローカルの/code-reviewは約4分で終わり、追加の費用はかからなかったとしています。現在はレビューのレベルを選べるので、今の金額はこの記録と同じではないはずです。それでも、1件あたり数ドルで収まるとは限らない、と見積もっておいたほうが安全です。
公式が勧める見積もり方は単純です。
- 管理画面の使用量設定で、Code Reviewの月間上限を先に決める
- 代表的なリポジトリを2〜3個選び、実行タイミングを「PR作成時に1回」か「手動」にする
- 数件回したら、管理画面のリポジトリ一覧でレビュー1回あたりの平均費用を見る
- 平均費用に、そのリポジトリの月間PR数を掛ける（プッシュごとにするなら、さらに平均プッシュ回数を掛ける）
たとえば平均が1回10ドルで月80件のPRなら、PR作成時に1回の設定で月800ドルです。プッシュごとにして1件あたり平均4回プッシュするなら、3,200ドルになります。この差を見てから、どのリポジトリに入れるかを決めれば十分です。上限に達するとレビューはスキップされ、PRに理由が書き込まれるので、上限を先に置いておけば請求が膨らむ心配はありません。
TeamやEnterpriseでなければ、ローカルの/code-review --commentでPRに直接コメントを残せますし、APIキーを使ってGitHub Actionsから動かす方法もあります。GitHub Copilot側のレビュー自動化と比べたい人は、Copilotのコードレビュー自動化の記事も参考になります。
小さなチームはこの順番で真似すればいい
記事のチェックリストは15項目あります。全部を一度に入れる必要はありません。私なら次の順番にします。
1週目：エージェントに自分で確かめさせる
最初にやるのは、CLAUDE.mdに「変更後に必ず実行するテスト、ビルド、リンタのコマンド」を短く書くことです。記事の1層目も、Claudeがテストとビルドとリンタを回し、別のコンテキストのエージェントが差分を見直すところから始まっています。人に回す前の手戻りがここで一番減ります。
同じ週に、PRテンプレートへ「Testing」「Risk」「How to revert」の3項目を足します。どう確かめたか、何が壊れうるか、どう戻すか。エージェントにPRを書かせる場合も、この3つを埋めさせるだけで人の読む量が減ります。
2〜4週目：1リポジトリだけでAIレビューを育てる
AIレビューは1つのリポジトリで始め、数週間かけて指示を調整してから広げる、というのが記事の勧めです。マネージド版を使うならREVIEW.mdを、ローカル中心ならCLAUDE.mdのレビュー用の節を育てます。書き出しは、たとえばこの程度の短さで構いません。以下は記事と公式ドキュメントの考え方を基に、私が書いた例です。
# Review instructions
## このリポジトリでの「壊れた」の意味
- 請求額や在庫数が誤って計算される
- ログやエラーメッセージに個人情報が出る
## 報告しないもの
- CIが検査済みの書式、lint、型エラー
- 自動生成ファイルとロックファイル
## 根拠
- 動作に関する指摘は、名前からの推測ではなく file:line を示す
- 細かい指摘は1回のレビューで最大5件まで記事によれば、良いREVIEW.mdは短く、そのリポジトリにとって何が「失敗」なのかを書いています。ドキュメントなら「嘘を書くこと」、設定なら「誤った宛先に流すこと」。記事は、繰り返し出る指摘をそこへ移すよう勧めています。私なら、同じ指摘を3回書いた時点で移すと決めておきます。それだけで、指示は運用しながら育っていきます。
1か月後：承認ルールを紙に書く
リスク区分は、厳しく始めて、証拠が集まったら緩めるのが記事の方針です。認証、課金、CIとリリースのワークフロー、インストーラーは、GitHubのCODEOWNERSとブランチ保護で必ず人が見るようにします。ブランチ保護は、前の節で書いたREVIEW.mdの読み込みにも効くので、一石二鳥です。
真似しなくていいところもある
数人のチームが、高リスクの変更に2人の承認を求めるのは現実的ではありません。分類器で区分を自動判定する仕組みや、過去の障害を集めてレビュアーを毎日採点する評価セットも、1日3万件の変更を前提にした装備です。最初は、区分を人が決めてPRテンプレートの「Risk」欄に書く運用で十分だと私は考えます。
逆に、規模に関係なく真似したいのは記事にある次の考え方です。リバートと障害の率をガードレールにする。それが上がっているなら、人の時間を節約したのではなく、別の場所に移しただけだ、と。AIレビューを入れたら、レビューにかかった時間だけでなく、月ごとのリバート件数も数えておくべきです。数字がなければ、楽になったのか、問題を先送りしただけなのか、区別できません。
今日やるなら、CLAUDE.mdに3行足すところから
今日できることは小さくて構いません。CLAUDE.mdに、変更後に回すテストとビルドのコマンドを書く。手元で/code-reviewを1回回して、出た指摘のうち毎回言われそうなものをCLAUDE.mdに移す。マネージド版を入れるなら、その前にデフォルトブランチを保護し、月間上限を設定しておく。
Claude Codeチームの数字は、AIに書かせる量を増やしても、壊れる率は下げられることを示しました。差を生んだのはモデルの賢さより、人がどこを見るかを決めた設計のほうだと私は読んでいます。
コメント