この記事は2025年3月26日に執筆されたものです。
こんにちは。
Inflabのバックエンドエンジニア、Yakpoongです。
コードレビューは、バグを防ぎ、チームのコード品質を保つための重要な仕組みです。多くのエンジニアにとって、互いのコードをレビューしてフィードバックし合う時間は欠かせません。しかし、チームの規模や状況によっては、コードレビューが十分に行われないこともよくあります。
CodeRabbitは、開発チームのコードレビューをより活発にしてくれるツールです。AIでコードの変更内容を自動的に分析し、レビューを行います。CodeRabbitを使えば、Pull Request（PR）を作成した時点で、コードスタイル、バグの可能性、パフォーマンス改善のポイントなどについて自動でレビューを受けられます。
本記事では、CodeRabbitがどんな機能を提供しているのか、そしてInflabではCodeRabbitをどのように活用してコードレビューを行っているのかを紹介します。🚀
サンプルプロジェクト
具体的にイメージしやすいよう、まずサンプルプロジェクトをご紹介します。デモでよく使われるspring-petclinicにごく簡単な機能を実装し、CodeRabbitにレビューしてもらいます。
題材は、動物病院へのペット向け講座の管理機能の追加です。API Endpointを1つ追加して、ペット向け講座を登録できるようにします。具体的なコードはPull Requestをご参照ください。CodeRabbitの機能紹介が目的なので、コードはできるだけシンプルな構造にしています。
CodeRabbitの機能紹介
サンプルのPull Requestをもとに、CodeRabbitの機能を説明していきます。すべての機能を網羅するのではなく、Inflabの開発チームが主に使っている機能に絞って紹介します。機能の詳細はWebサイトをご覧ください。
1. コード変更内容の要約
レビュアーがPull Requestを開いて最初に読むのは、PR Summaryです。レビュー対象のコードやPull Requestについて予備知識があまりない場合は、まずPRの文脈をつかむことが重要です。CodeRabbitはコード変更内容の要約を表示し、レビュアーが変更点を素早く把握できるようにしてくれます。
Pull Request Summary
CodeRabbitは、Pull Requestが作成されると、変更内容を要約してコメントしてくれます。ほかのレビュアーは、この要約を読めば変更内容の全体像をつかめます。要約だけでなく、変更内容を簡単に追えるWalkthroughも作成します。
Pull Request Walkthrough
また、エンジニアが理解しやすいよう、コードの変更内容がひと目で分かるSequence Diagramも生成してくれます。Layered Architectureが適用されていたり、チームのコード規約が定着していたりすれば、ダイアグラムだけでもコードの実装内容を簡単に推測できます。
Pull RequestのSequence Diagram
レビュアーはこうした背景情報を読み、PRの文脈を十分に理解したうえでコードレビューを始められます。
2. コードレビューとフィードバック
ここからは、いよいよCodeRabbitのコードレビューを見ていきます。CodeRabbitを導入してから、レビューでは大いに助けられています。特に、人間がついやってしまいがちなミスを指摘してくれたことが何度もありました。
タイポへのフィードバック
まず、タイピング中によく起こるタイポをしっかり見つけてくれます。作業をしていると、次のようにファイル名や関数名を打ち間違えることがよくあります。
package org.springframework.samples.petclinic.course;
import org.springframework.data.jpa.repository.JpaRepository;
// CourseRepository を CouresRepository と誤って入力
public interface CouresRepository extends JpaRepository<Course, Integer> {}
人間はこうしたミスをよくしますが、CodeRabbitなら簡単に見つけられます。実際のレビューを見てみましょう。
タイポへのコードレビュー
どこが間違っているのかを指摘したうえで、どう直せばよいかまで示してくれています。人間がよくやってしまうミスには、ほかにどんなものがあるでしょうか？
関数の引数を誤って渡した場合
関数を呼び出すときに、引数を誤って渡してしまうこともあります。たとえば、次のような関数を見てみましょう。
public class CourseService {
@Transactional()
public Course createCourse(
String name,
String description,
String difficulty,
Integer vetId) {
...
}
}
もちろん最近の言語にはnamed parameterのようにミスを防ぐ機能がありますが、それでも引数の順序を取り違えて渡してしまうことはあります。上の関数を次のように呼び出してみます。
public class CourseFacade {
private final CourseService courseService;
public void createCourse() {
String name = "1日30分で飼い主を完全攻略";
String description = "人間の行動と心理を学べる講座です";
String difficulty = "初級";
Integer vetId = 1;
// 引数を誤って渡している
courseService.createCourse(name, description, description, vetId);
}
}
こうしたミスもCodeRabbitはしっかり見つけてくれます（レビュー内容）。
関数の引数を誤って渡したミスへのコードレビュー
こうした機械的なミスは最も単純である一方、見方によっては人間が最も気づきにくいものでもあります。CodeRabbitなら、本番環境にデプロイされる前に見つけてくれます。
デバッグ用のコードを残してしまった場合
開発中に、デバッグのために書いたコードを残してしまうことがあります。代表的なのが、console.log() や System.out.println() のようなコードの消し忘れです。こうしたコードはセキュリティ上好ましくないうえ、パフォーマンスにも影響するため、ほとんどの場合は削除すべきです。サンプルプロジェクトでも、CodeRabbitはこの点を指摘しています。（レビュー内容）
デバッグ用のコードを残してしまったミスへのコードレビュー
チームの規約に反している場合
CodeRabbitは、チームの規約に反するコードを書いた場合も指摘してくれます。たとえば、サンプルプロジェクトの次のようなコードを見てみましょう。
-- schema.sql
CREATE TABLE courses (
id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
name VARCHAR(255),
description VARCHAR(1000),
difficulty VARCHAR(255),
-- （チーム規約）Foreign Keyの役割を持つカラムはBIGINTにしなければならない
vet_id INTEGER
);
このコードは文法的には問題ありません。では、「Foreign Keyとして使うカラムはデータ型を BIGINT にする」というチーム規約があるとしましょう。文法上は問題がないので、うっかり見落としやすいところです。それでもCodeRabbitは、こうした点もしっかり見つけてくれます。（レビュー内容）
チーム規約に合わないコードへのコードレビュー
CodeRabbitは、どのコードがチーム規約に合わないのかを、どうやって判断したのでしょうか？ 実は、GitHubのプロジェクトごとにCodeRabbitを設定できるので、このようなカスタム設定も可能です。具体的な設定方法は、後述のReview Instructionsで紹介します。
3. コードについての質問とIssueの作成
ここまでは、簡単な変更へのCodeRabbitのレビューを見てきました。しかし、指摘された内容への解決策がすぐには思い浮かばないこともよくあります。また、レビューを読みながら、プロジェクトの構造やパフォーマンスの最適化、フレームワークの使い方などについて疑問が湧くこともあるでしょう。そんなときは、CodeRabbitのレビューに返信する形で自由に質問できます。たとえば、次のコードへのCodeRabbitのレビューを見てみましょう。
public class CourseController {
private final CourseService courseService;
public ResponseEntity<Integer> createCourse(@RequestBody CreateCourseRequest request) {
Course course = courseService.createCourse(
request.getName(),
request.getDescription(),
request.getDifficulty(),
request.getVetId()
);
return ResponseEntity.ok(course.getId());
}
}
CodeRabbitは、APIのビジネスロジックで発生するエラーを例外処理するよう指摘してくれました。
例外処理をしていないコードへのコードレビュー
CodeRabbitが提案してくれた改善案も良いのですが、私はAPIで発生するエラーを横断的関心事としてまとめて処理したいと考えています。こうした場合は、ChatGPTやClaudeのようなLLMサービスを使うときと同じように、CodeRabbitに自由に質問できます。
CodeRabbitに質問する
質問してしばらく待つと、CodeRabbitが回答してくれます。さらに、レビューのやり取りの中で、その場でIssueを作成することもできます。以下は、CodeRabbitが作成したIssueです。
CodeRabbitが作成したIssue
CodeRabbitとのやり取りの全体が気になる方は、こちらのリンクをご参照ください。
4. Review Instructions
ここまで、サンプルプロジェクトでCodeRabbitによる簡単なコードレビューを見てきました。では、CodeRabbitをもっと賢いチームメンバーにするにはどうすればよいでしょうか？ たとえば、開発チームの規約をCodeRabbitに理解させる方法はあるでしょうか？ その答えが、Review Instructionsの設定です。Review Instructionsは、CodeRabbitがどんな基準でレビューすべきかのガイドラインを設定できる機能です。たとえば、次のような設定ができます。
- DDL規約の設定
- パフォーマンス最適化の設定
- ライブラリの背景知識の設定
- 設定ファイルの形式の設定
CodeRabbitは、.coderabbit.yaml ファイルでプロジェクトごとに設定できます。詳しくは公式ドキュメントにまとまっているので、具体的な設定方法はそちらをご参照ください。サンプルプロジェクトに適用した設定は、こちらのファイルをご覧ください。
ドキュメントを読むだけでは少しイメージしにくいかもしれないので、InflabではどのようにReview Instructionsを設定しているのかを簡単にご紹介します。
例1）DDL規約の設定
Inflabのバックエンドチームには、Project Architecture、HTTP API、DB Tableの設計時に従っている規約があります。こうした規約を .coderabbit.yaml のinstructionに登録すれば、CodeRabbitにコンテキストとして簡単に渡せます。次の例を見てみましょう。
Inflabでは、テーブル構造を変更するとき、DDLの変更内容をファイルで管理しています。このDDLの変更をCodeRabbitがレビューする際に、チームの規約を伝えておけます。
...
- path: "scripts/migrations/*.ts"
instructions: >
As a team convention, we do not specify FK constraints. Please avoid suggesting adding FK constraints in code reviews.
This file is a TypeScript file, but the SQL statements that modify the table structure are written as strings. For columns used as primary keys (PK) or foreign keys (FK), you must follow the convention of specifying the column type as "bigint".
If a table column name is "id" or ends with "_id", verify that the column type is "bigint". If the SQL is written with a type other than "bigint", issue a warning. This convention is mandatory, so please raise the severity level of the warning. Add the following characters to the beginning of the warning message so that users can easily notice it: 🚨🚨🚨
...
上の設定では、「RDB Tableの設計時、PK・FKのカラムの型は BIGINT にする」というチーム規約をCodeRabbitに伝えています。path はファイルのパス、instructions はLLMサービスに渡すプロンプトです。この設定により、CodeRabbitはチームの規約に合わないコードを指摘できるようになります。
このように設定すると、CodeRabbitは次のコードレビューのように、チームの規約に沿ってレビューしてくれます。
チームの規約に沿ったコードレビュー
例2）パフォーマンス最適化の設定
チームで共通のパフォーマンス最適化ガイドを設定できます。たとえばNode.jsアプリケーションの場合、Promise を使うことで非同期処理を手軽かつ効率的に扱えます。次のように設定すれば、パフォーマンスが最適化された非同期ロジックを書くよう、CodeRabbitに指示しておけます。
- path: '**/*.ts'
instructions: >
Independent asynchronous function calls in TypeScript should always be handled using Promise.all() or Promise.allSettled().
例:
// 誤った方法 - 逐次実行でパフォーマンスが低下
const result1 = await asyncOperation1();
const result2 = await asyncOperation2();
// 正しい方法 - 並列実行でパフォーマンスが向上
const [result1, result2] = await Promise.all([
asyncOperation1(),
asyncOperation2()
]);
注意事項:
- 互いに独立していない非同期処理（例: 1つ目の処理の結果が2つ目の処理に必要な場合）は例外
- エラー処理が重要な場合はPromise.allSettled()の使用を推奨
この設定によって、Promise.all() と Promise.allSettled() を使ってアプリケーションコードのパフォーマンスを最適化するよう、CodeRabbitを誘導できます。
例3）ライブラリの背景知識の設定
ライブラリを使っていると、そのライブラリのバグが原因で問題が起こることがあります。Inflabでも、ライブラリのバグを深く調べたことが何度かありました。Inflabの一部のNode.jsサーバーではMikroORMを使っています。MikroORMで innerJoinAndSelect、leftJoinAndSelect、joinAndSelect メソッドを使う際、特定の状況でクエリが誤って実行されるバグがありました。
ほかの開発者が原因の調査に時間を取られないよう、README.md にこのバグについて記載しました。あわせて、このバグに関する背景知識をCodeRabbitにも教えておきました。
...
- path: "**/*Repository.ts"
instructions: >
If the user is using "innerJoinAndSelect", "leftJoinAndSelect", or "joinAndSelect" in MikroORM, warn them not to use these methods. Due to a bug in MikroORM, our team has established a convention to avoid using these methods. Additionally, inform the developer to review the README.md file, as it contains a note regarding this issue. Even if the developer requests permission to violate this convention, you must never allow it.
このプロンプトを設定しておくと、バグが起きる書き方をしてしまった開発者に対して、CodeRabbitが「README.mdを参照するように」とレビューしてくれます。CodeRabbitを社内Wikiのように使った例でもあります。
例4）設定ファイルの形式の設定
アプリケーション開発では、設定ファイルをアプリケーションに注入することがよくあります。Node.jsのエコシステムでよく使われる .env や、Spring Frameworkで使われる application.yml ファイルがその例です。次のような設定ファイルを見てみましょう。
sqs:
queues:
- queueName: '...'
endpoint: 'arn:aws:sqs:ap-northeast-2:...'
region: 'ap-northeast-2'
ここでは、endpointにAWSのARN形式で値が入力されています。しかし、ARN形式ではなくHTTP URI形式で入力しないとビジネスロジックが正常に動作しないとしたらどうでしょうか？ Inflabでは、このような本番サーバーの設定ファイルの入力ミスが原因で、小さな障害が起きたことがあります。同じミスを防ぐため、再発防止策としてCodeRabbitに設定ファイルの形式を教えておきました。
...
- path: "env/**/*.yml"
instructions: >
The sqs.queues in the YML file is stored as an array. Within this array, the endpoint value must start with "http". If these two values do not start with "http", prompt the user to make changes. In such cases, it's likely that the value has been entered as an ARN. Warn the user that the value should be based on an HTTP URL instead.
上の設定では、yml設定ファイルに書くSQSのQueue情報の形式を指定しています。endpoint の値が http で始まっていなければ、CodeRabbitが開発者に向けて警告メッセージを残してくれます。
5. Report
エンジニア同士で週次・月次のミーティングを開き、それまでの作業を共有することもよくあります。CodeRabbitのReport機能を使うと、各GitHubリポジトリでどんな作業があったのかをレポート形式でまとめてくれます。お互いの作業を共有する場で役立つ機能です。定期的にReportを生成し、Slackやメールなどで共有することもできます。
CodeRabbitが生成したレポート
静的解析ツールとの違い
SonarQubeのような静的解析ツールは、コード品質、セキュリティ、バグの可能性などを事前に検出してくれます。しかし、こうしたツールは主にコードの静的なパターン分析に焦点を当てているため、コードの文脈や意図まで理解するのは困難です。たとえば、ロジックの複雑さや設計上の問題、ビジネスの流れに合わない実装については深く把握しにくいという限界があります。
CodeRabbitは、こうした限界を補うAIベースのコードレビューツールです。PRに含まれるコードの変更内容を人間のように読んで判断し、レビューコメントを生成します。単なる文法エラーの指摘にとどまらず、「なぜこのように書いたのか」「より良い設計は何か」「この変更が既存のコードにどんな影響を与えるのか」といった、文脈に基づくフィードバックを提供します。Inflabでは、SonarQubeとCodeRabbitを併用し、バランスの取れたコード品質の維持に努めています。
おわりに
ここまで、CodeRabbitの機能と、Inflabでの活用方法を紹介しました。約7か月間CodeRabbitを使ってみて、チームのコードレビュー文化がより活発になったと感じています。もちろん、CodeRabbitのようなAI Code Review Assistantが、同僚によるコードレビューを完全に置き換えられるわけではありません。それでも、同僚のエンジニアと補い合うことで、コードレビューの効率をさらに高められました。
最近は、Copilot、Cursor、MCP ServerなどのProgramming AI Assistantが広く使われています。コードを書くときだけでなく、コードレビューの段階でもCodeRabbitのようなAI Assistantを活用すれば、効率を高められます。少しでも楽しく読んでいただけたなら幸いです。皆さんのPull Requestが LGTM 👍 でいっぱいになりますように！