Anthropic社は2026年10月15日に、「Claude Codeチームはどのようにコードレビューをしているか（How the Claude Code team does code review）」という記事を公開しました。
生成AIを使うと、コードが爆速でできる。でも人間のチェックが追い付かない。
どうしたらいいんだ！
こんなふうに悩むチームのための記事です。
ただ、チーム開発だけでなく、個人開発にも役立つポイントが色々と掲載されています。
本記事では、個人開発でも、すぐ活用できそうな方法を分かりやすくまとめていきます。
自分自身の経験も織り交ぜつつ、役立つと思う部分を取り上げていきますね。
Anthropic社がレビューを見直した成果
まずは、Anthropic社がレビュー方法を見直した成果から。
Anthropic社によると、Claude Codeの開発では、2026年6月から９月にかけて、マージされたプルリクエストは２倍以上に増えたが、取り消しになる割合は、40パーセント以上減ったとのこと。次の3点を行った成果です。
- 読む作業の大半を生成AIに移した
- 人間の時間と注意を節約し、人間が必要な作業に注力させた
- ミスを簡単に戻せるようにした
具体的なレビュー方法
ここからは具体的な方法で、今すぐ取り入れられそうなことをご紹介していきます。
「きっとこれが大事だろう」という部分を独断でピックアップして、【極意】としていきますね。
極意1：コードは書きながらレビュー
文章を書く時に、リアルタイムでスペルチェックをかけたりしますよね。それと同じように、コードもリアルタイムでレビューをかけること。
つまり、コードを書き終えてからまとめてレビューするのではなく、開発途中からこまめにレビューを行う。これによって、簡単なミスをすぐに止められます。
スペルチェックのように、と言われると分かりやすいですね。
AI開発では、レビューのタイミングが変わったと感じます。
極意2：人間の注意は有限のものと心得る
人間の注意力は有限です。なので人間でしかできない作業のために、温存することが重要です。
「やっぱり人がチェックしたほうが」と思いがちですが、「人間がコードを読んだかどうか」は、実はあまり当てにならない目安ともいえます。
本当に問うべきは「この変更で何が壊れうるか、それはどのチェック（自動か人か）で捕まえるべきか」です。
ここ、どきっときました。やっぱり自分の中にも、「人間が見ると安心」という思い込みはある気がします。
なおAnthropicでは、変更リスクに応じて、次のようにレビューする人の数を変えています。通常の機能追加は、やはり１人のチェックは必要です。
- 低リスク：人なし（ドキュメントや文言の修正など）
- 中リスク：1人
- 高リスク：2人
極意3：Claudeに「自分の作業を検証する手段」を与える
Claude Codeの生みの親、ボリス・チャーニー（Boris Cherny）氏は、Claudeに自分の作業を検証する手段を与えることが「おそらく最も大事」で、最終結果が2〜3倍良くなると推定しています。
検証とは、テストを走らせる、ビルドする、画面をデザインと見比べる、など。
また、Claudeに単に「終わりました」と言わせるのではなく、実行結果を提出させることがポイントです。
実効結果としては、テストの結果やコマンドの出力、画面のスクリーンショットなどが使えますね。
極意4：AIレビュワーを役割ごとに用意する
人間の代わりに生成AIレビュワーたちを使うわけですが、これはもちろん、ステップや用途に応じて、レビュワー係をいくつか用意しておきます。たとえば次のような感じです。
- 差分レビュー係
- バグ探し係
- 指摘の検証係
- セキュリティチェック係
いろんな係が考えられますが、このあたりは案件の規模によると思います。
極意5：レビュワーたちの能力もレビューする
AIレビュワーも完璧ではありません。そこで、レビュワーのチェックも行います。
Anthropicでは、過去に障害や取り消しを起こした変更をテスト問題にして、レビュワーが見抜けるかを毎日採点しています。
いってみれば、毎日過去問を使って、テストを実施しているのですね。
またAIレビューに対して、人間がどう反応したか（直した／指摘が間違っていた など）を元に、無駄な指摘の多さも測っています。
極意6：AI同士のレビューは「やめ時」を決めておく
AI同士でレビューと修正を繰り返すと、直した行にまた小さな指摘が付き、レビュー往復がずっと続くこともありえます。Anthropicでは3往復（レビュー→修正で1往復）を上限にしています。
使える道具
極意のあとは、実際に使えるファイルやツールについて紹介していきます。
CLAUDE.md
これはお馴染みのプロジェクトの基本説明書（技術スタック・規約・目標・やらないこと）。
レビューのたびに読み込まれるので、短くまとめるのが肝です。
REVIEW.md
レビューで重視することの指示書。レビュワーたちが見る指示書です。
名前はREVIEW.mdでなくてもOKです。ただ、後でご紹介するCode Review機能を使う場合は、このファイル名のほうがよいです。
同じ指摘が何度も出たら、その場で直すだけでなくここに書き足します。
型チェック・lint・テスト
生成AIで確実に止められるものは生成AIで。Claudeに実行させて、結果を確認させます。
/code-review
Claude Codeの機能。今の差分をレビューして、バグや簡素化できる箇所を指摘してくれるコマンド。
プランの使用量または API の課金にカウントされます。コミット前などに実施。
どのプランでも使えますが、プルリクエストを自動レビューする「Code Review」はTeam・Enterpriseプラン向けとなります。
/security-review
セキュリティ専門のレビュー。SQLインジェクション、XSS、認証・認可の不備などを探します。
こちらもプランの使用量または API の課金にカウントされます。コミット前などに実施。
わたし自身のプロジェクトの進め方
わたし自身は、
Fableを司令塔にして、Sonnetにコードを書く
→別SonnetがE2Eテスト
→Opusがレビュー
という流れで開発をすすめることが多いです。FableがSonnetやOpusを使う流れです。
E2Eテストでは、スクリーンショットを取ってもらいます。Fableがチェックして、さらにわたしも見るという流れです。
レビューには、他社のモデルを使うのも良いかもしれません。
コードは、基本、自分自身でチェックをいれています。セキュリティに直結する認証・認可は特に時間をかけて見ています。
コマンドを使ったレビューは、最近実施しています。
今回ご紹介した極意の中にある方法は、実践できている部分もありましたが、レビュワーたちへのレビューなど、実施していなかった部分もあります。今後取り入れていこうかなと思いました。
ただ…いちからのプロジェクトである場合には、最初からレビュープロセスの効率化を行うのも難しいとも感じます。
まずは人間がチェックしつつ、レビュープロセスも意識して整えていく、こういった形のほうが現実的かもしれませんね。
さいごに
Anthropic社の記事をもとに、生成AI（主にClaude Code）を使った開発のレビューについて、まとめてみました。
今の段階では、この方法は最適だと思います。ただ、正直、数か月先には分かりません。
生成AIの進化が激しい中で、コードを書く速度は上がったものの、そのほかのフローがボトルネックになっていきます。そのため、絶えず、そのボトルネック部分の見直しがせまられる気がします。そして結局、全体の進め方もアップデートする必要がでてきます。
常にアンテナをはって学びつつ、良いものを取り入れていく。既存の方法も見直していく。
このスピード感と試行錯誤が今まで以上に大事だと感じています。
コメント