AI コードレビューツール CodeRabbit を導入した話

こんにちは。dfplus.io でフロントエンド開発を担当している城畑です。

最近は Claude Code などのコーディングエージェントでコードを書く機会が圧倒的に増えてきた中で、大量のコードをレビューすることやAI が書いたコードの品質をどう担保するかということに課題を感じている方も多いのではないでしょうか。

dfplusio の開発チームではそのような課題を解決するため、AI コードレビューツール「CodeRabbit」を導入しました。

本記事では、導入の背景から実際に使ってみての感想まで紹介します。

CodeRabbit とは

CodeRabbit は AI による自動コードレビューツールです。

GitHub や GitLab と連携し、PR が作成されると自動でレビューを開始します。

複数の AI モデルと静的解析ツールを組み合わせて分析し、数分以内に結果を返してくれます。
レビュー結果として返ってくるのは、変更内容のサマリーやシーケンス図、行単位のレビューコメントなどです。指摘の内容を修正する提案やワンクリックで修正をコミットできるものもあるので、簡単にコードの修正が可能です。

強みはチームの規約などの独自のコンテキストを学習していく点です。
yaml ファイルでコーディングガイドラインを設定したり、レビューコメントへの返信を通じてレビューの基準を学習させることができます。使い続けることでレビューの精度が上がっていく設計になっています。

導入の背景

まずはコードレビューについて抱えていた課題についてお話しします。

AI やエージェントが生成した大量のコードを読むのがしんどい
実装者視点では視野が狭くなっていてミスに気づきにくい
指摘する側も受ける側も、言い方や受け取り方を多少なりとも意識してしまう
レビューが返ってくるタイミングによってはコンテキストスイッチが発生する

以上のような悩みを解決したいことに加え、開発チームを分割するタイミングとも重なり、コードレビューがボトルネックになりやすい状況にもなっていました。

AI エージェントによるコード生成が増えるにつれ、生成されるコードの量も増えていきます。品質を保ちながらレビューし続けることへの課題を感じていた中で、AI コードレビューツールの導入を検討することにしました。
AI であれば数分以内にレビューが返ってきますし、人間の指摘に比べ心理的に楽というのも導入の動機のひとつでした。

2週間のトライアルと振り返り

AI コードレビューを導入するにあたって、まずいくつか候補をリストアップしました。その中からトライアルすることにしたのが、CodeRabbit と Greptile の2つでした。

どちらも無料 2週間のトライアルがあり、日本では CodeRabbit、海外では Greptile の評判が良かったことが、両者を比較することにした理由です。同じ PR に対してどう指摘が違うかを見ながら比較できるよう、2つを並行して検証する形を取りました。

2週間のトライアル終了後にチームでそれぞれのツールの比較と感想について振り返りを実施し、各自が良かった点・課題に感じた点を付箋に書き出した上でどちらのツールを継続したいかを投票するという形で進めました。

どちらのツールにも共通して好評だったのが PR サマリーによるレビュアーの負担軽減です。「この PR で何をしているかを要約してくれるのはよかった。レビュアーの負荷を下げる」というコードレビューをする立場でのポジティブな声も上がりました。

また、人間の目で見落としがちなケアレスミスを拾ってくれる点も評価が高かったです。非機能要件について指摘してくれる点も評価のポイントでした。

一方で課題として挙がったのは、PR に要件や仕様を書いておかないと的確な指摘が来ないこと、コメントが増えて PR の見通しが悪くなることで、これは両ツールに共通していました。

CodeRabbit に決めた理由

結果として、レビューの詳細度と指摘の分かりやすさで CodeRabbit が上回るという評価がチームの複数メンバーから挙がりました。 Greptile はレスポンスの速さや Confidence score の表示など独自の特徴はあるものの、「CodeRabbit と比べて指摘が浅い印象」という声が多く、最終的に CodeRabbit を使っていくという結論になりました。

使ってみての感想

半年使ってみて、「レビュー依頼を出す前にまず CodeRabbit に見てもらう」というフローが当たり前になりました。やはり「レビューを依頼する前に考慮漏れに気づける」というメリットが大きく、セルフレビューの一段階前に機能している感覚があります。セキュリティヘッダーの抜けや、日本語ドキュメントでは古い情報をもとに実装してしまっていた箇所を英語の公式ドキュメントを参照して指摘してくれた例もありました。

一方で、設計思想やエラーハンドリングへの指摘は的外れなものが多いという声もありました。この点はチューニングで改善できる部分もあるので後の章で触れようと思います。

そうした中で、特に便利だと感じている使い方をいくつか紹介します。

Issue 起票

PR をレビューしていると「これは直したいけど今の PR では棚上げしたい」という場面はよくあると思います。そのたびに人間が issue を立てるのは地味に面倒です。 CodeRabbit にコメントで「issue 立てておいて」と伝えるだけで起票してくれるので、この使い方は特に重宝しています。

また、E2E テストなど機能実装後に忘れないように issue を立てておくといった使い方もしています。

学習機能

的外れな指摘が来たとき、「うちではこういう理由でこうしています」と CodeRabbit に返信しておくと、次回以降はその指摘をしてこなくなります。逆に、以前の会話を踏まえて学習に基づいた指摘をしてくれることもあります。

対応しない場合も「意図的にこうしています」と一言残しておくだけで、次第にチームの文脈を理解してくれるようになります。指摘に対してはスルーせずコメントを返しておくのがおすすめです。

エージェントとの併用

AI エージェントでコードを生成した後、自分でコードを見る前にまず CodeRabbit にレビューで最低限の品質を担保することで開発者のコードレビューの負担を削減しています。

自分が全体を見る前に CodeRabbit が一次チェックをしてくれることで、確認すべきポイントが絞られてレビューのコストを減らせます。

.coderabbit.yaml でチームに合わせてチューニングする

前述のとおり、設計思想やエラーハンドリングのように「チームの文脈に依存する観点」では的外れな指摘も出ます。これはリポジトリ直下に置く .coderabbit.yaml で、レビューの観点や厳格さを設定することである程度コントロールできます。
dfplus.io で実際に効いている設定をいくつか紹介します。

ディレクトリごとにレビュー観点を変える（path_instructions）

path_instructions で、ファイルのパスごとに「何を見てほしいか」を指示できます。dfplus.io は Atomic Design や Redux Toolkit など層ごとに守りたい規約が違うため、パスごとに観点を切り替えています（抜粋）。

reviews:
  path_instructions:
    # React コンポーネントには React 固有の観点を
    - path: 'src/components/**/*.tsx'
      instructions: |
        - 過剰な useState、useEffect の使用を避けているか
        - メモ化（useMemo、useCallback、React.memo）が適切か
        - Atomic Design 階層に応じた責務が守られているか

    # Redux モジュールにはアーキテクチャの観点を
    - path: 'src/modules/**/*.ts'
      instructions: |
        - Redux Toolkit Slices パターンの遵守
        - 状態の正規化（normalizr）が適切か
        - immutable な更新（Immer）が行われているか

こうしておくと、その場所で本当に見てほしいことに絞った指摘が返ってくるようになり、ノイズが減ります。

チームのレビュー基準そのものを読ませる（knowledge_base）

さらに効果が大きかったのが、もともとチームで使っていたレビュー観点のドキュメントを CodeRabbit に読ませることでした。knowledge_base.code_guidelines に Markdown を登録すると、その基準に沿ってレビューしてくれます。

knowledge_base:
  code_guidelines:
    enabled: true
    filePatterns:
      - '.claude/skills/review/basic.md'
      - '.claude/skills/review/architecture.md'
      - '.claude/skills/review/react.md'
      - '.claude/skills/review/test.md'

人間のレビューで使っている基準と AI のレビュー基準を一本化できるため、「人によって・AI によって言うことが違う」状態を避けられます。

レビューの厳格さを変える（profile）

reviews.profile を assertive にすると、より踏み込んだ指摘をしてくれます。逆に指摘が多すぎてノイズに感じるチームは、標準の chill から始めるのがよいと思います。

reviews:
  profile: 'assertive'

Devin Review・Copilot Review との使い分け

現在は CodeRabbit 単体ではなく、Devin Review や GitHub Copilot Review と併用しています。レビューのレスポンス速度という点では Devin や Copilot の方が早い印象です。

一方で CodeRabbit ならではの強みもあります。コメントに返信すると CodeRabbit がさらに返信してくれるので、会話を続けながら指摘の意図を深掘りしたり、自分の意図を説明したりできます。また、前章で触れたように .coderabbit.yaml で細かくチューニングできる点も、Devin や Copilot と差別化できる強みです。的外れな指摘もチューニングで減らせるため、使い続けるほど自分たちのチームに合ったレビューに育てていける点が CodeRabbit の強みです。