さんきょー

コードレビューで「人が全部読む」のは、もう前提じゃないっぽい Claude Code チームが、自分たちのコードレビューの仕組みを公開していた Claude Code のコードは約9割を Claude が書いていて、Anthropic のモノレポでは1日のマージ数が5月の約2,500件から9月には3万件超 もう人が1行ずつ読むのは無理、という前提から始まる 「人がコードを読んだか？」は「何が壊れうるか、どのチェックで捕まえるべきか」の不正確な代わりでしかない、という話 目標は、人の時間を最小にしつつ、リバートや障害を増やさないこと 7つの層による人の時間を守るレビュー ① PR 前に検証 テスト・ビルド・スクショで Claude に「動いた証拠」を出させ、別のサブエージェントが新しい文脈で diff を見る ② 全 PR に AI レビュー 複数のエージェントが並行でバグを探し、別のグループが投票して「本物」と合意したものだけ残す。スタイルの指摘は捨てる ③ セキュリティレビューで止める 指摘を直すか、理由をつけて閉じるまでマージできない ④ いつもの CI lint、型、全プラットフォームのテスト。PR テンプレには「どうテストしたか」「どう戻すか」 ⑤ 人の承認はリスクで変える docs や フラグ裏の変更は0人、普通の変更は1人、課金・自動更新・CI は2人。リスクは書いた人ではなく変更内容で決まる。エージェントの承認は人の代わりにならない ⑥ マージキューと段階リリース まず社内、次に latest、最後に stable ⑦ すぐ気づいて、すぐ戻す フラグはデプロイなしで切れる。障害レビューでは「どの層で捕まえるべきだったか」を問う レビュアー自体の改善も面白い ・過去の障害とリバートを評価セットにして、毎日レビュアーを回す ・エージェント同士が延々と直し合うのを防ぐため、3ラウンドで打ち切ってやり方から見直す（一晩で50往復した PR があったらしい） 人に残る仕事は5つ ・そもそも作るべきか ・課金や CI などの危険なコード ・真似されるアーキテクチャ ・証拠を読む ・結果に責任を持つ 結果、6〜9月でマージ数は2倍以上、リバート率は4割以上減った 結論、レビューは「最後の関門」から「書きながら走るスペルチェック」に変わって、人の仕事は「全部読む」から「何を見落としうるか判断する」に移ってきた claude.dev/blog/solving-code…