📖 はじめに
本記事は、claude.dev ブログの How the Claude Code team does code review（2026-10-15公開、著者: Addy Osmani, Morgan Westlee Lunt, Qing Wang）の日本語要約です。
Claude Code チームは「incident や revert を増やさない範囲で、人間のレビュー時間を最小化する」ことを目標にしています。6〜9月でマージされたPRは2倍以上になり、revert が必要になったPRの割合は40%以上減少したとのことです。Claude Code 自身のコードの約90%は Claude が書いています。
イメージが掴みやすいよう、記事の「PRテンプレートに『Testing』『Risk』『How to revert』を追加する」という提案を元にした例を示します（※記事掲載のコードではなく、要約者による説明用の例です）。
## Testing
どうテストしたか
## Risk
影響範囲・リスク
## How to revert
どう元に戻すか
✨ 3行まとめ
- 🎯 レビューの目的は「問題の発見」と「チームの共有コンテキスト作り」。希少資源は人間の時間と注意。
- 🧱 変更は「事前検証 → AIレビュー → セキュリティ → CI → リスクに応じた人間承認 → マージキュー/フラグ → 高速検知・ロールバック」の7層で守る。
- 📈 レビュアー自体も eval で継続的に改善し、「You land it, you own it」の文化で運用する。
🧭 レビューの目的の捉え直し
- Anthropic のモノレポは、5月の約2,500 changes/日から9月には3万超へ増加（Claude Code は別リポジトリ）。
- コードレビューには2つの役割がある：出荷前に問題を見つけて直すことと、チームの共有コンテキストを作ること。
- レビューは最後の関門から「書きながらのスペルチェック」のような継続的なものへ変化した。
⏳ 希少資源は人間の時間と注意
- 目標：CLI・デスクトップ/Web・モバイルの各リポジトリで、ほとんどのPRが人間1人以下の関与でマージされること（revert や incident は増やさない）。
- 指標：PRあたりの人間承認数（中央値と95パーセンタイル）、人間のコメント数、人を待つ時間。revert/incident 率はガードレール。
🧱 変更が通る7つのレイヤー
1️⃣ 誰かが見る前に作業を検証する
- Claude がテスト・ビルド・linter を実行して出力を示す。サブエージェントが新しいコンテキストで diff をレビューする。
- 社内スキルで、バグ確認・diff の簡素化・E2Eの動作確認を行う。UI変更はデザインガイドラインと照合。
- Boris Cherny は、Claude に検証手段を与えると結果が2〜3倍良くなると見積もっている。
- 繰り返し出る指摘は、スキル・lintルール・指示ファイルで根本から直す。
-
CLAUDE.md：プロジェクト規約（短く保つ） -
REVIEW.md：コードオーナーが「このコードで重要なこと」をレビュアーに伝える。良い例は、そのリポジトリでの失敗の姿を書き、nit に上限を設け、スキップするパスを列挙し、ファイルと行の根拠を求める。
-
2️⃣ 全PRにAIレビュー
- diff をリポジトリ全体とPRの意図に照らして読む。複数エージェントが並列でバグを探し、別グループが各指摘に投票し、十分な合意があるものだけを投稿。スタイルや掃除系の指摘は除外。
- 指摘は Important / Nit / Pre-existing のタグ付き。すべて修正するか、理由付きで解決する必要がある。
- research preview 開始時、社内PRで実質的なレビューコメントが付く割合が16%→54%に。1,000行超のPRの多くは指摘が付き、小さいPRの多くはクリーンで返る。リポジトリごとに Quick / Standard / Deep を設定。
3️⃣ ブロックできるセキュリティレビュー
- バグレビューやセキュリティレビューの未解決指摘はマージをブロック。後続の修正コミットで自動的に解消される。
4️⃣ ブロックする自動チェック
- lint・型チェック・全プラットフォームのテスト・ビルド。PRテンプレートで「どうテストしたか」「どう戻すか」を問う。変更を依頼した人が承認する。
5️⃣ リスクに応じた人間の承認
| ティア | 必要な承認 |
|---|---|
| Low | 自動チェックが緑なら不要 |
| Medium | 1人 |
| High | 2人 |
- 分類器が著者ではなく変更内容からティアを決める。常に人が必要なパスもあり、軽いパスは信頼された著者のみ。
- エージェントの承認は人間の承認としてカウントしない。エージェントが書いたPRでは、指示した人が必須レビュアー。承認は特定の1コミットに対して有効。
6️⃣ マージキュー・フラグ・段階リリース
- マージキューは、変更を適用した main に対してチェックを再実行。新挙動はまず社員向けフラグで公開。一般リリースは
latestチャンネル →stableの順。
7️⃣ 高速な検知とロールバック
- フラグはデプロイなしでオフにできる。週次のオンコール当番がある。revert/incident の数値に応じて承認を厳しくするサーキットブレーカーはまだ無いとのこと。
🛠️ レビュアー自体を改善する
- すべての incident を eval ケース化（専門家が確認）し、レビュアーを毎日そのセットで実行。
- ノイズは、コメントへの反応（修正した/誤り/意図的/どうでもいい）で測定。既知のクリーンなPRでも実行する。
- 収束性の問題：あるCLIのPRで一晩に50回超のレビューラウンドが発生。指摘の約59%は初回から存在したコードだった。対策は、ラウンド上限（3回後は著者にアプローチの再考を促す）、数回後は差分のみ再レビュー、バグの「クラス」を指摘する、同じ指摘を繰り返さない、など。既存コードへの夜間レビューも実施。
- 収束対策の前後（社内PR）：
| 指標 | 前 | 後 |
|---|---|---|
| 1回のレビュー+修正で通過 | 65% | 78% |
| 5ラウンド以上必要 | 8.9% | 1.5% |
| 通過までの平均レビュー数 | 2.08 | 1.32 |
🙋 人間が残る場所
人間が判断するのは、作るかどうか、リスクの高いコード（課金、自動アップデータ、CIワークフロー）、アーキテクチャ、証拠を読むこと、結果に責任を持つこと。
🤝 チームでの文脈共有・文化
- 正式なプロセスは無く、特定コード範囲の解説を Claude に頼んだり、小さな可視化を作らせたりする。オープンなSlackチャンネルも有効。
- "You land it, you own it."：変更は小さく、すべて元に戻せるように。基準は影響範囲（blast radius）で決め、回帰はテレメトリと社内利用で発見する。非難のためではない。
- エージェントで着手が安くなったため、PRが閉じられたり方向転換されることもある。別の方向性は完成後のブロックコメントではなく、スレッドの早い段階で提起する。
✅ 導入チェックの例（記事より）
- PRテンプレートに「Testing」「Risk」「How to revert」を追加する
- マージ前にすべてのレビュースレッドの解決を必須にする
- 機密パスには CODEOWNERS とブランチ保護を使う
- ボットの承認で、必須の人間の承認を代替させない
今後の方向性として、Code Review は承認ではなく指摘を投稿する製品であり、承認は人間の判断のまま。Anthropic の社内リポジトリでは、低リスクの変更を自動チェックのみでマージするかをオーナーが決められる。
🎬 まとめ
- まず自分のリポジトリで検証手段（テスト・linter）をエージェントに与えるところから始めましょう。
-
REVIEW.mdや PRテンプレート（Testing / Risk / How to revert）を整備し、リスクに応じた承認ルールを検討してみてください。 - 詳細（各チェックリストや図）は元記事をぜひ読んでみてください。