コードレビューは1人で全部読むな——Claude Codeチームが6層に分けた理由
One reviewer per layer: splitting code review by the way code is read
Claude Codeチームのモノレポでは、マージされる変更が5月の1日約2,500件から9月には3万件超へと急増した。それでもレビューは止めていない。変更を意図・形式・局所的な意味・配線・実行時・利用という6つの層に分け、層ごとに別の読み手を置く仕組みだ。筆者はこれを、1972年にDavid Parnasが提唱した情報隠蔽の考え方をレビューに適用したものだと捉え、層×観点のマトリクスへと発展させる。
私たちはそのルールをコードでは守りながら、プロンプトでは破っている。diffと周辺ファイル、あらゆる抽象度の情報を1つのコンテキストウィンドウに詰め込み、モデルがうまく整理してくれることを期待しているのだ。
- jwpapi
今の問題は、あらゆる種類のレビュープロセスが不要な複雑さを追加し、それが後になってアジリティを低下させ、コストを増大させ、パフォーマンスを劣化させることです。
機能があって、6人の異なるレビュアーがそれを見ると、ロジックはすぐに膨れ上がります。他の人たちはどうやって対処しているのか気になります。私は全面的に賛成で、これを機能させたいと思っていますが、これが現在の制約です。
レビューモニターからは、何かを間違えているために悪い提案を受けることがよくあります。時には良いもの、非常に良いものもありますが、いくつかは悪いです。だからバグに関するレビューを見るのはいつでも歓迎ですが、6人のレビュアーの後では単なるテキストの山になって混乱し、実際の重要な部分を自分で見るよりも最終結果が悪くなるのではないかと心配です。私のコンテキストも限られていて、完全に手放しでは信頼性が十分ではありません…
皆さんはどうやっていますか？
- fg137
ベンチマークがないなら、これは私の一行「この変更についてコードレビューをして」と変わらない。
- visarga
今年のアプローチとしては良いと思いますが、重要な点が欠けています — 何週間も何ヶ月も、多くのセッションをまたいでステアリングした後、コードがまだあなたの意図を反映していることをどうやって知るのか？メッセージはセッション内を流れ、視界から消え、コンパクションや新しいセッションをまたぐと忘れ去られます。これを解決するために、私はすべてのユーザーメッセージをチャットログに記録し、時々見直して最新のユーザー意図を抽出しています。
ここやAnthropicの記事で言及されていない別の種類のレビューは、計画レビューです。ある程度の作業範囲の計画を生成し、その計画（ファイルとして保存）を1つ以上のエージェントにレビューさせます。これにより、実行前にプロジェクトの制約に対して計画をチェックします。
テストを解決できれば、コーディングはほぼ完全に自動化されます。残る唯一の問題は常に信頼でした — なぜそのコードを信頼すべきなのか？手動で読むなら、それはバイクを押して歩くようなものです。読まないなら、リスクを減らす何らかの方法が必要です。これについて多くのアイデアが飛び交っており、OPとAnthropicはそれぞれの見解を示しました。ただし、アプローチはプロジェクト固有だと思います。一般的な方法はありません。