多様な開発組織のコード／PRレビューを“図鑑”のように紹介する連載「コードレビュー図鑑」。ニーリー株式会社の増田（おます）さんに、コードレビューの“いい塩梅”を探るための実践について紹介いただきました。 [1]
株式会社ニーリーでサクセスエンジニアリングチームのリーダーをしている増田と申します。
ニーリーは、BtoBtoCのVertical SaaSとして「Park Direct」を運営しています。月極駐車場のオンライン契約を、管理会社と借り手の双方にとって扱いやすくするサービスです。私が所属するサクセスエンジニアリングチームは、プロダクトの外側から事業のトップラインを上げるために動きます。業務効率化のためのプラットフォームやアプリケーション開発など、扱う領域は幅広いです。
コードレビューの目的をどう捉えるか
コードレビューは、目的を全部満たそうとすると時間が溶けやすい作業です。どこまで見るべきかの判断にも迷いが出ますし、ドメインやアーキテクチャに詳しいメンバーへ負担が偏りがちです。結果として、その人がボトルネックになり、開発速度が落ちることもあります。
さらに厄介なのが、せっかく指摘しても意図が伝わらない問題です。頭の中の考えを一発で完璧に言語化するのは難しく、経験の差も解像度のギャップになります。短いコメントは曲解されやすく、長い説明は読まれにくいというジレンマもあります。
そんな中、コードレビューで多くの人が探しているのは、品質を担保しつつ負担を抑えたい、「いい塩梅」だと考えています。
そこで今回は、「いい塩梅」を探るための実践を、大きく2つのアプローチに分けてご紹介します。1つは「PRの指摘を減らす」ためのセルフレビュー、もう1つは「指摘を適切に伝える」ためのAI巻き込み型コミュニケーションです。
PRに出す前の品質を上げる
1つ目のアプローチであるセルフレビューの狙いは、PRを出す前に自分で品質を高めることです。簡単なミスをできる限り減らし、レビュアーが本質的な議論に集中できる状態を作ります。
私たちのチームでは、ローカルでAIにレビューさせるサイクルを回しています。コードを書いてAIに見てもらい、修正して、また見てもらう。納得いくまで繰り返すことで、PRに出す前に品質を上げます。
まずはPR Review Toolkitを使ってみる
「何から始めればいいか」で迷うなら、私のおすすめはClaude Codeの公式プラグイン「PR Review Toolkit」です。これを使うと、6つの専門エージェントが並列に走り、結果を集約してくれます。レビュー観点の違いを同時に拾えるので、セルフレビューの入口として扱いやすいと感じています。
ただし、汎用チェックだけではプロジェクト固有のルールや設計パターンを拾えません。ドメイン知識に基づく判断も難しく、ここはギャップが出ます。
そこで私たちは、カスタムエージェントの導入も進めています。コミュニティが公開している「Awesome Claude Code Sub Agents」などを参考にしつつ、プロジェクトに合わせて調整します。
例としてはdomain-knowledge-checkerのように、設計書と実装の整合性を見たり、テスト要件が設計と一致しているかを検証したりします。他にもrefactoring-expertなど、役割ごとにエージェントを使い分けています。
さらに、使い方自体を仕組みに寄せています。私たちは/code-reviewというSkillを用意し、レビューレベルを選べる形にしました。「Lite」なら少数のエージェント、「Full」なら8つのエージェントを並列で走らせます。PRの難易度や実装の規模に応じて、トークンを使いすぎないように調整します。
それでも、すべてのドメイン知識をドキュメント化するのは現実的ではありません。暗黙知や文脈依存の判断は残ります。だからこそ、現時点（2026年2月）では人のレビューが重要だと考えています。
指摘を適切に伝える
2つ目のアプローチとして、「指摘を適切に伝える」ための方法を紹介します。前提として、ニーリーでは「CodeRabbit」を使っています。 CodeRabbitには大きく3つの要素があります。自動レビュー、対話機能、そしてコンテキスト理解です。ここからは、具体例を交えて使い方を説明します。
まずAIの指摘を解消してから、人がレビューする
PRを作ると、CodeRabbitが自動でレビューして指摘を一覧化します。変更内容のサマリーや、ファイルごとの変更点の解説も作ってくれたり、実装内容を可視化する図を出してくれたりすることもあります。
さらに、問題点の指摘だけでなく、修正案や、AIに修正させるためのプロンプトまで生成します。私たちのチームでは、CodeRabbitの指摘をいったんすべて解消してから、人がレビューに入る運用にしています。
この順番にすることで、議論が必要なポイントへ集中しやすく、人のレビュー負担が下がります。
“いい塩梅”のつくり方
では、人の介在が必要なフェーズになってから、どう“いい塩梅”を実現するか。答えはシンプルで、コメント末尾に「@coderabbitai」を付けるだけです。 これを付けると、AIがコメント内容とリポジトリを読み取り、返信してくれます。とにかく積極的に付けるのがポイントです。
大事なのは「AIとの議論の過程が、そのままレビューへの説明になる」点です。議論そのものが、あとから読む人にとっての文脈になります。
「@coderabbitai」の使い方
使い方のひとつは、違和感の壁打ちです。「ここが少しおかしい気がする」という段階で巻き込むと、背景や意図を含めてAIが説明してくれます。そのログが、チーム全体の共有コンテキストになります。
次に「意見を求める」使い方があります。IMO（In My Opinion）を投げ、同意や反論をもらいながら整理します。これがパブリックに残ることで、レビューが“思考の共有”になっていきます。
レビューを受ける側も使えます。指摘に対してどう直したかをAIに確認させると、反映されている点・漏れている点を教えてくれます。第三者の指摘内容も含めて確認できるので、やり取りの往復が減ります。
さらに、暗黙知を言語化する場にもなります。過去の経緯や、来月予定している実装など、背景を説明した上で議論すると、AIがそれを踏まえた提案を返します。場合によっては、その情報を学習して次回以降に参照することもあります。
最後に、議論をそのまま修正指示へ落とし込みます。これまでの過程を踏まえ、コーディングエージェントへ渡すプロンプトを作らせる。議論がそのまま実装の入力になります。
5つのメリット
このやり方のメリットは、まず「言語化の限界を補える」ことです。対話を通じて段階的に考えを整理できます。次に「経験・認知の差を埋められる」点があります。前提知識の説明が議論として残るため、異なるレベルのメンバーでも追いやすくなります。
3つ目は「曲解による手戻りを防げる」ことです。短いコメントでも対話が補ってくれるので、意図がねじれにくくなりました。4つ目は「修正時のコンテキストになる」ことです。何を考えてそう直したのかがログに残ると、後から読む人の理解も変わります。
そしていちばん大きいのが「心理的安全性が高まる」ことです。指摘が合っているか不安なときも、AIに壁打ちしてから出せます。結果として、誰でもレビューに参加しやすくなります。
加えて、対立構造もやわらぎます。「レビュアーとレビュイー」の対立ではなく、第三者を交えたディスカッションに近づくからです。
導入の成果
実際、私たちのチームでは導入前は1PRあたりコメントが1件程度でした。それが今は約5倍になっています。心理的安全性が上がり、ジュニアメンバーでも気軽に議論へ参加できるようになったことが背景です。
最後に、CodeRabbitに「LGTM（Looks Good To Me）をアスキーアートで祝って」と頼むと、盛大に祝ってくれることがあります。道具として頼るだけでなく、可愛がることでチームの空気も少し柔らかくなるかもしれません。
アーカイブ動画・発表資料
本記事は、2026年2月6日に開催されたイベントでの発表をもとに編集したものです。
イベントのアーカイブ動画・資料は以下のリンクからご覧ください。
アーカイブ動画：「コードレビューどうしてる？各社のTips共有会」
※動画の視聴にはFindyへのログインが必要です。
執筆者へのお便り
-
本記事は、2026年2月6日に開催されたイベントでの発表をもとに編集したものです。 ↩