コードの約9割をClaudeが書くClaude Codeチームは、コードレビューで「人が読んだか」ではなく「何がまずくなりうるか」を問うことにしました。6月から9月にかけて、マージされたPRの数は2倍を超え、リバートが必要になったPRの割合は4割以上減りました。10月15日にclaude.devブログで公開された「How the Claude Code team does code review」に書かれていることです。前回の記事「AIが1日3万回マージし始めたら、Anthropicはgitを離れた」で取り上げたHacker Newsのコメントのうち、返信がいちばん多かったスレッドも、この速さでレビューはどうするのかと尋ねていました。数日後に投稿された「理解していないAIのコードを出荷してよいのか」という問いと並べて読み、小さなチームが取り入れられそうなルールを選びました。
「人が読んだか」を問わない
元記事は、コードレビューには2つの役割があると整理しています。出荷前に問題を見つけて直すこと、そしてチームがコードベースを共に理解できるようにすることです。チームは、変更がここまで押し寄せると1行ずつ読むレビューはほぼ不可能だと認めたうえで、1つ目の役割について立てる問いから変えました。
「人がコードを読んだか」は、「この変更で何がまずくなりうるか、それを見つけるのにふさわしいのは自動の検査か人か」を測るには不正確な物差しだ。
Claude Codeチーム「How the Claude Code team does code review」
そこで、節約すべき資源を人の時間と注意だと定めました。人の時間には、レビューする時間と、悪いコードが壊したものを直す時間の両方が含まれます。前者を減らしても後者が増えれば、節約にはなりません。目標は、ほとんどのPRが人1人以下を経てマージされることです。その1人は作成者本人でもかまいません。ただし、リバートや障害が増えてはいけません。そのためPRごとに、人による承認とコメントの数、人を待った時間を測り、リバート率と障害率を安全ラインとして見ています。
関門1つではなく、何層もの検査
レビューの大半は、いまやPRができる前に終わります。テストやビルド、デザインと見比べるスクリーンショットのように自分で確かめられる手段をClaudeに与え、「できました」と言う代わりに結果を実際に見せるよう求めます。そのあと、それまでの文脈を持たない新しいサブエージェントがdiffを見直します。Claude Codeを作ったBoris Chernyは、Claudeに自分の作業を検証する手段を与えることが、よい結果を得るうえでおそらくいちばん大切だと述べ、最終的な結果が2〜3倍よくなると見積もっています。
どのPRも、人より先にClaudeがレビューします。複数のエージェントが同時にバグを探し、別のエージェントたちが指摘ごとに投票して、十分な賛成を得たものだけをコメントとして残します。スタイルや整理だけの指摘は捨て、残ったものにはImportant・Nit・Pre-existingのラベルを付けます。Pre-existingは、そのPRが持ち込んだのではないバグが作成者のせいに見えないようにするためのラベルです。指摘にはすべて答えなければなりません。直すか、理由を書いて閉じます。このレビューを研究用プレビューとして始めたとき、実質的なレビューコメントが付いた社内PRは16%から54%に増えたそうです。
セキュリティのレビューも別に回ります。バグやセキュリティのレビューで付いた指摘が1つでも解決されていなければ、マージできません。その後ろにはリント・型チェック・全プラットフォームのテスト・ビルドが控えています。PRのテンプレートは「どうテストしたか」と「どう元に戻すか」を尋ねます。その欄はClaudeが埋めてもかまいませんが、変更を頼んだ人が自分で確認します。
人の承認はリスクに応じて
ドキュメントの修正と自動アップデート機能の修正ではリスクが違うので、レビューも変わります。区分を決めるのは作成者の判断ではありません。分類器が変更を読んで区分を選び、2つ目の分類器が「区分は低くても、この変更だけはもう1人が見るべきか」を改めて問います。ドキュメント・文言・社内専用の機能・機能フラグで隠した追加の変更はリスクが低く、自動レビューとセキュリティチェックが通れば人の承認は要りません。通常の製品の変更と、キャッシュ・自動アップデート・システムプロンプトのようなセンシティブな部分に触れる変更は1人、もっともリスクの高いコードは2人が承認します。この軽い道が開かれているのは、リポジトリの信頼リストに入った作成者だけです。
ルールはほかにもあります。エージェントの承認は、人の承認として数えません。エージェントが書いたPRでは、エージェントに仕事を頼んだ人が必要なレビュアーの1人として数えられます。自分で打ち込んだのと同じ扱いです。承認は1つのコミットにだけ有効で、エージェントがプッシュしたコミットのようにシステムが保証できないコミットが来たら、承認を取り直さなければなりません。コードオーナーがセンシティブだと指定したパスとCIのワークフローファイルは、いつも人が見ます。
PRが来ると、分類器が変更を読んでリスクの区分を選びます。
2つ目の分類器は、区分が低くても、この変更だけはもう1人が見るべきかを改めて問います。
リスク低の変更は、自動レビューとセキュリティチェックが通れば人の承認なしでマージされます。
中は1人、もっともリスクの高いコードは2人が承認します。
その上にルールが付きます。エージェントの承認は人の承認に数えず、エージェントに頼んだ人がレビュアーの1人に数えられます。
承認は1つのコミットにだけ有効で、軽い道は信頼リストに入った作成者にだけ開かれています。
マージキューは、mainに変更を載せた状態で検査をやり直します。別々には通った2つのPRが、合わさってmainを壊すのを防ぐためです。新しい機能はたいていフラグを付けて社員に先に届け、公開リリースもlatestチャンネルがstableチャンネルより先に進みます。フラグはデプロイせずに切れます。ある同僚は、速度を落とせばエラー率は下がるが、それはたいていあらゆる作業を減らしているからだと言ったそうです。チームはそれより、問題に早く気づいて直すほうを選びました。まだないものも書かれています。リバートや障害の指標が悪くなったら承認の基準を自動で引き上げるサーキットブレーカーはまだなく、人を介さずにマージされるコードがさらに増える前に、それを整えたいとエンジニアたちは考えているそうです。
レビュアーもレビューされる
AIレビュアーも毎日テストを受けます。チームは過去に障害を起こしたPRを集め、そのコードを知るエンジニアがバグと場所を1つずつ確かめて、評価セット（eval）にしました。レビュアーを変えるたびに、この評価セット全体で点数を付けます。無駄な指摘、つまりノイズも測ります。レビュアーが付けたコメントごとに、人がどう反応したかを分けます。直したのか、間違いだと言ったのか、意図した動作だと言ったのか、どうでもいいと判断したのかです。作成者がエージェントだと、ノイズはより高くつきます。人は細かい指摘を数秒で受け流せますが、エージェントはそれを直してコミットし、もう一度レビューを受けるからです。
エージェントの作成者とエージェントのレビュアーは、互いをいつまでも忙しくさせられます。あるCLIのPRは、一晩でレビューと修正を50回以上往復したところで、作成者が止めたそうです。レビュアーが何度も指摘した箇所にgit blameをかけると、59%ほどは最初のレビューのときからあったコードでした。新しいバグを見つけていたというより、古いバグを毎回いくつかずつ掘り出していたのです。そこでレビューの回数に上限を設けました。3回を超えると、レビュアーが作成者にやり方そのものを考え直すよう促します。最初の数回を過ぎたら、新しく変わった部分だけを見直します。バグはその1行ではなく同じ種類すべてを指摘し、すでに付けた指摘は繰り返しません。
では、コードを把握しているのは誰か
レビューの2つ目の役割、チームがコードを共に理解することはどうなったのでしょうか。元記事は、決まった手順はないと率直に書いています。ある部分を知りたい人は、Claudeにちょうどその部分だけを説明する文章を書いてもらいます。数分ででき、いまのコードをそのまま映すといいます。1行の文言修正をレビューしても学べることはほとんどないが、これから手を入れるモジュールの解説からは多くを学べる、という理屈です。そのかわり「マージした人が責任を持つ」という決まりを守ります。小さな変更やふつうの変更が問題を起こしたら、たいていマージした人が直します。責めるためではありません。その人が文脈をいちばんよく知っているからです。
チームにClaude Codeの全体像を頭の中に持っている人はいない。誰もそうする必要はないと考えている。
Claude Codeチーム「How the Claude Code team does code review」
3日後、615件のコメントに表れた不安
この記事がHacker Newsに載った3日後、「Ask HN: How to deal with shipping AI-written code you don’t understand?」が投稿されました（484ポイント）。投稿者は、MetaのあるエンジニアがLinkedInに書いた文章を引用しています。最近はコードを書いてもすべてがブラックボックスのようで、全体像はわかっても細部まではわからない、という告白です。目立った答えは3つに分かれました。
設計は人が決める。返信がいちばん多かったコメント（41件）は、LLMに設計を任せないと書いていました。抽象化と役割分担を先に決めて空いたところだけを埋めさせれば、各部分がどう実装されたかは知らなくても、何を担いどう噛み合うかはわかる、というのです。
危ないところは手で書く。あるコメントは、画面のコードは丸ごと任せても、SQLのスキーマはいまも手で書くと述べていました。間違えたときの代償がはるかに大きいからです。コーディングに使っていた時間を、いまはテストに使っているというコメントもありました。
それでも読むべきだ。反対側のコメントは、本番に出す前にコードは必ず読むべきで、社内にそのコードを説明できる人が少なくとも1人はいなければならない、と書いていました。
これは品質よりも責任の問題だ。
同じAsk HNスレッドのコメント
Claude Codeチームの記事に付いた479件のコメントも、好意的なものばかりではありませんでした。あるコメントは、小さなチームが「Googleはこうしている」と言ってGoogle規模のやり方をまね、苦い思いをした例を挙げていました。トークンを事実上いくらでも使える会社だからできるやり方だ、というのです。別のコメントは、自社のSOC 2の監査人から本番に出るすべてのコードを少なくとも1人のほかの人がレビューすべきだと言われたとして、このやり方がどう承認されたのかを尋ねていました。元記事は、コストや監査の規定には答えていません。「AIはコーディングの時間を節約してくれるが、責任は100%自分に残る」というコメントもありました。
道具か、自動化か
同じ2週間には、もっと根本的な反論も出ていました。Clojureを作ったRich Hickeyは「‘AI’ Is Not a Tool」（HN 318ポイント）で、LLMは手に持って扱う道具ではなく自動化だと書きました。ドライブスルーは料理の道具ではなく料理を避けるための自動化だ、というたとえを挙げ、自分で書いたり読んだりしなければ考え方を学ぶ機会を失うと述べています。すぐにHuahaiが「AI Is a Tool. Using It Well Takes Skill.」（805ポイント）で反論しました。のこぎりを持てばまっすぐ切れるわけではないように、LLMもうまく使うには技術が要る、というのです。低レイヤーのコードに8年ほど取り組んできたpurplesyringaは「Grieving the loss of details」（506ポイント）で、LLM中心の開発がプログラミングを耐えられるものにしていた部分をすべて削ぎ落としたと書きました。18日には、出荷のたびにそのコードを理解しているかクイズを出すフック、Sphinx（252ポイント）まで登場しています。
道具とは、それを使って自分が何かをするためのものであって、自分の代わりに何かをしてくれるものではない。
Rich Hickey「‘AI’ Is Not a Tool」
小さなチームが取り入れられること
元記事の最後には、ほかのチームが取り入れるためのリストがあります。トークンを好きなだけ使えない小さなチームでも、すぐにできるものだけを選びました。
リスク区分を文章にしておく。区分は誰が書いたかより何を変えたかで決め、最初は厳しく始めて根拠がたまったら緩める、というのが元記事の勧めです。認証・決済・CIやリリースのワークフロー・インストーラーは、CODEOWNERSとブランチ保護でいつも人を通るようにします。
PRのテンプレートに3つの欄を足す。「どうテストしたか」・「リスク」・「どう元に戻すか」です。
REVIEW.mdを置く。そのリポジトリで失敗がどんな姿をしているかを書きます。元記事の例では、ドキュメントなら「嘘をつく」、設定なら「誤った宛先に送る」です。細かい指摘には上限を設け、根拠としてファイルと行を求めます。同じレビューコメントが繰り返されたら、その内容をこのファイルに移します。
レビューの回数に上限を設ける。最初の数回を過ぎたら、新しく変わった部分だけをレビューし直します。
ボットの承認を人の承認の代わりにしない。新しいコミットが積まれたら、それまでの承認は無効にします。
人の時間を測り、リバート率を安全ラインにする。障害を起こしたPRとリバートしたPRを集めて、レビュアーの評価セットにします。
Scionの記事でAnthropicは、エンジニアの役割はClaudeに「ノー」と言うことだった場合が多いと書いていました。今回の記事が人に残した仕事も似ています。それを作るかどうかを決めること、決済や自動アップデートのように危ないコードを見ること、証拠を読むこと、結果に責任を持つことです。Ask HNの615件のコメントが「このコードを誰が把握しているのか」と問うたのなら、Claude Codeチームは「この変更に誰が責任を持つのか」で答えたことになります。2つが同じ問いなのかは、まだ誰にもわかりません。それでも小さなチームが先にやることははっきりしているように見えます。人が必ず見なければならない場所を、文章にしておくことです。