Claude Code チームのやり方で、私たちもコードレビューをしています

Anthropic は先日、Claude Code チームのコードレビューの進め方を公開しました（How the Claude Code team does code review）。その目標はひと言で表せます。差し戻しや障害を増やさずに、人がレビューにかける時間をできるだけ減らすこと。レビューはもはやマージ前の最後の関門ではありません。自動チェックが全工程で働き、人の注意はリスクのある部分にだけ向けられます。

この記事には大いに共感しました。私たちは十数人のエンジニアリングチームで、この 1 年あまり同じことに取り組んできたからです。人の労力は本当に必要なところに注ぎ、それ以外は AI に任せる。そのために使っているのが、私たちが開発した AI コードレビューサービス HeyDeer です。ここでは Anthropic の記事と照らし合わせながら私たちのやり方を紹介し、HeyDeer がなぜこのように設計されているのかを説明します。

1. 人がすべての行をレビューできなくなった理由

Anthropic によると、Claude Code のコードの約 90% は Claude が書いており、マージされる PR の数は数か月で 2 倍以上に増えたそうです。私たちもよく似た道をたどってきました。

以前の私たちは、コードレビューに厳しい基準を設けていました。誰かがすべての行を丁寧に読み、もっと良い書き方がないかを検討する。質の悪いコードは一度コードベースに入ると、取り除くのが難しいからです。

Opus 4.1 の頃には、すでにコードの 70〜80% を AI が書いており、GitHub でレビュー待ちの PR は増える一方でした。人のレビューが追いつかなくなりつつあったのです。そして Opus 5.5 の今、モデルは十分に賢くなり、エンジニアは主に目標を決めて実装はコーディングエージェントに任せるようになりました。AI が書くコードの割合はほぼ 100% です。それでも人がすべての行をレビューしていたら、人がプロセス全体で最も遅い工程になってしまいます。

同時に、1 行ずつのレビューの価値そのものも下がっています。かつて私たちが最も気にしていたコードの臭い（code smell）は、今では AI が簡単に片付けられるので、人が 1 行ずつ目を凝らす必要はありません。その方法については、別の記事で紹介する予定です。

つまり、問うべきは「どうすれば人がもっと速くレビューできるか」ではなく、次の 2 つです。

1. 人が本当に見るべき変更はどれか？
2. 人が見ない変更の品質を、どう高く保つか？

順に見ていきましょう。

2. 人が見るべき変更：リスクで振り分ける

Anthropic の答えはリスクに応じた人による承認です。誰が書いたかではなく、変更そのものから分類器がリスクレベルを判定します。低リスクの変更は自動チェックを通過すれば人の承認は不要、中リスクは 1 人、高リスクは 2 人の承認が必要です。

HeyDeer も同じ考え方で動きます。レビューのたびに PR のリスクレベル（低・中・高）を評価し、その理由を説明します。設定の「HeyDeer が承認できる PR」で、HeyDeer にどのリスクレベルまで承認を任せるかを選べます。

低リスクと中リスク：HeyDeer が承認

私たちのチームは「低リスクと中リスクの PR」を選んでいます。PR が高リスクでなく、HeyDeer の完全なレビューで問題が見つからなければ、HeyDeer が承認し、PR は自動で main にマージされます。

この運用を始めて 8 か月になりますが、バグのあるコードをマージして本番サービスが落ちたことは一度もありません。

高リスク：方向性は人が判断し、細部は HeyDeer に任せる

高リスクの PR には、引き続き別のエンジニアの承認が必要です。ただし、その人の役割は変わりました。1 行ずつ間違いを探すのではなく、PR のアプローチや方向性が正しいかを、より高い視点から判断します。これは、Anthropic の記事が人の関与を残すとしている場面、つまり何かを作るべきかの判断、アーキテクチャのレビュー、変更の裏付けとなる根拠の確認と一致しています。細かな点は HeyDeer に任せれば十分です。

人が重要な箇所をすばやく見つけられるように、HeyDeer はウォークスルーを提供しています。

• 関連する変更をグループにまとめ、各グループに「必読」「推奨」「流し読み」の印を付けます。本筋から外れた変更は「その他」に、それぞれの理由とともにまとめます。何を飛ばしてよいかがひと目でわかり、最も重要な部分に注意を向けられます。
• PR のリスクレベルとその根拠を示すので、どこを慎重に確かめるべきかがわかります。

レビュアーは最初のファイルから最後のファイルまで順に読む必要がなくなり、人の判断が最も必要な数か所に直行できます。

3. 人が見ない部分の品質を高く保つ

PR の大半の承認を AI に任せられるのは、そのレビューが信頼できる場合だけです。問題をきちんと見つけ、しかも人をノイズで埋もれさせてはいけません。HeyDeer はこの両方を満たすように設計されており、チームごとのレビューのやり方に合わせて調整できます。

正確さ：複数のモデルが相互にレビューし、検証し合う

Anthropic の AI レビューでは、複数のエージェントが並行してバグを探し、別のエージェントが各指摘事項に投票して、通過したものだけを投稿します。

HeyDeer はさらに一歩進んで、異なるベンダーのモデルが各変更をレビューし、互いに検証し合います。単一のモデルは問題を見落としやすく、誤った指摘もしやすいうえ、同じモデルを複数並べても同じ間違いを犯しがちです。モデルごとに死角が異なるため、相互にレビューすることで見つかる問題は目に見えて増え、相互に検証することでノイズや誤検知の多くを取り除けます。

ノイズを減らすことは、人の注意を守ることでもあります。誤検知が多すぎると、人は対応しきれず、やがて読まなくなります。かといってすべてをコーディングエージェントに任せると、誤検知をうのみにして修正し、コードベースを肥大化させかねません。レビューを AI に任せられるのは、その結果が正確な場合だけです。

網羅性：リポジトリのチェックでチームの規約を守る

Anthropic のやり方では、同じレビューコメントが繰り返し出るなら、その根本で解決します。skills、lint ルール、CLAUDE.md、REVIEW.md に書き込むのです。

私たちの経験では、汎用のレビューツールは特定のコードベースならではのニーズに応えるのが苦手です。たとえば、ボタンのラベルの大文字・小文字の使い方、UI の文言のトーン、チームでの React の使い方の約束事などです。こうした規約を AGENTS.md やスキルに書いておけば、コーディングエージェントはコードを書くときに従います。しかし、コードレビュー全体の中では、大量のコンテキストに埋もれて見落とされがちです。

HeyDeer のリポジトリのチェックは、まさにそのための機能です。チェックしたい要件を .agents/checks に普通の言葉で書いておくと、HeyDeer はチェックごとに専任のレビュアーを割り当てます。レビュアーは該当するファイルを変更するすべての PR を、その要件ひとつに照らしてレビューするので、見落としがありません。

調整可能：チームのレビュースタイルに合ったフィードバックの範囲

レビューのフィードバックに求めるものはチームによって異なるため、HeyDeer にはフィードバックの範囲の設定があります。

• 簡潔：金融系など、今も人によるレビューが中心のチーム向け。重要な問題だけに絞り込むので、人は最も大事なところに時間を使えます。
• バランス（デフォルト）または網羅的：レビューと修正の大部分をコーディングエージェントや HeyDeer に任せるチーム向け。AI にとって小さな問題の修正はほぼコストがかからないため、細かな問題まで解消できます。

4. レビューのあと：PR が収束するまで Autopilot が修正

レビューで問題が見つかっても、誰かが直さなければなりません。ラウンドのたびにエンジニアが戻ってきてコメントを読み、エージェントに修正を頼み、次のレビューを待つのでは、結局注意を奪われたままです。

Anthropic の記事は、とても現実的な問題を率直に認めています。AI レビューは収束しないことがあるのです。ある PR では、一晩で 50 ラウンド以上のレビューと修正が繰り返されました。レビュアーが指摘し続けた問題の約 59% は、最初のレビューの時点からあったコードに関するものでした。各ラウンドで見つかっていたのは新しいバグではなく、古いバグが少しずつ掘り起こされていただけだったのです。その後、ラウンド数の上限を設ける、最初の数回以降は新しい変更だけを再レビューする、投稿済みの指摘事項を繰り返さない、といった一連の改善が行われました。

HeyDeer は当初から、収束をレビューの設計目標にしてきました。HeyDeer が小さな問題をまとめて見つけたら、Autopilot に任せられます。Autopilot は未対応の項目を修正して PR のブランチにプッシュし、自分の変更をレビューします。これを PR がマージできる状態になるか、人の判断が必要な質問が出るまで繰り返します。私たちの使い方では、ほとんどの PR は 2 ラウンド、複雑なものでも 3 ラウンドで完了します。Autopilot は最大 5 ラウンドまで実行し、停止したときはその理由と、まだあなたの対応が必要なことを説明します。

これは私たちにとってとても大切なことです。人にとってコンテキストスイッチのコストは非常に高く、エンジニアに 2 つのことを同時に抱えてほしくありません。新しい機能を書きながら、前の PR へのコメントに対応できたかを気にし続ける、といった状態です。Autopilot を開始すれば、エンジニアは安心して次のタスクに移れます。

これらをまとめると、私たちのチームの日常はこうなります。エンジニアは PR を出したら、すぐに別の作業に移れます。HeyDeer がレビューし、見つかった問題は Autopilot が修正します。低リスクと中リスクの PR は HeyDeer が承認して main にそのままマージされ、高リスクの PR は別のエンジニアがウォークスルーを使って方向性を確かめます。

5. このやり方が向いているチーム

「高リスクの変更だけを人がレビューする」というこのやり方は、どんなチームに向いているのでしょうか。いまの AI の能力を考えれば、扱う業務に特に機密性の高い情報が含まれない限り、ほとんどのスタートアップや中小企業はこのやり方で進められると私たちは考えています。まずは HeyDeer に低リスクの PR だけを承認させ、チームに自信がついたら中リスクまで広げるとよいでしょう。

おわりに

Anthropic の実践と、私たちの HeyDeer の使い方の対応はおおよそ次のとおりです。

ツールやモデルは変わっても、目標は変わりません。人の注意はチームで最も貴重な資源です。だからこそ、最も価値のあるところに使うべきです。AI がコードを書く速さに人のレビューが追いつかなくなってきたと感じているなら、ぜひ HeyDeer を試してみてください。