【CodeRabbit】でAIコードレビューを導入してみた

開発

# CodeRabbit # AI # コードレビュー

原

公開日:2025/12/24

読了目安:約2分で読めます

今回は CodeRabbit（コードラビット） を題材に、「これ読めばだいたい分かる」ブログを書きます。

読み終わったらこんな状態になるのがゴールです👇

CodeRabbitが どういうサービス で 何ができるか が分かる
料金感 が分かる
導入方法 が分かる（まず動かせる）
チーム運用で効く いい設定（.coderabbit.yaml） が分かる

CodeRabbitってなに？

一言でいうと、 GitのPR上で動くAIコードレビュー です。
PRを作ると、CodeRabbitがレビューコメントを付けてくれて、必要ならそのままPR上で会話できます。

対応してるGitプラットフォームも幅広くて、 GitHub / GitLab / Azure DevOps / Bitbucket あたりは普通にいけます。

何ができる？（ざっくり機能）

使ってて「助かる〜」ってなるのは、このへんです。

1) PRの要約を作ってくれる

レビューって、そもそも「このPR、何してるの？」の把握から時間かかるじゃないですか。
そこを 先に要約して出してくれる のが地味に効きます。

2) 変更行に対してレビューコメントしてくれる

「ここバグりやすそう」
「ここ可読性落ちるかも」
「この条件漏れそう」
「この命名だと誤解しそう」

みたいな“人がよく指摘するやつ”を、まず一発目で拾ってくれます。

3) PR上で会話できる（ここが強い）

PRコメントで @coderabbitai 宛に質問すると、追加で観点を変えたレビューをしてくれたりします。

料金は？（2025年12月時点）

料金はプランがいくつかありますが、ざっくり押さえるならここ。

Free：$0（個人のrepoのみ）
Pro： $24/月（年払い） or $30/月（月払い） / 開発者

※「開発者課金」って書くと不安になるけど、要は PRを作る側（contributing developers） を軸に考える感じです。
まずはFreeで触って、いけそうならPro、が一番ラクです。

導入方法（まず動かす）

ここでは GitHub想定 で最短導入を書きます。
（他のプラットフォームも公式ガイドがあるので、流れはほぼ同じです）

手順

CodeRabbitにGitHubでログイン
連携したいOrganization（または個人）を選ぶ
CodeRabbitアプリをインストール（対象リポジトリを選ぶ）
PRを作る
PR上にCodeRabbitのコメントが付いたら成功！

「PR作ったけど反応ない…」ときの確認ポイント

アプリのインストール対象にそのrepoが含まれてるか
権限（Permissions）周り
PRがDraftになってないか

“いい設定”のやり方：`.coderabbit.yaml` を育てる

CodeRabbit、導入だけでも動くんだけど、 真価は設定 です。
おすすめは リポジトリ直下に .coderabbit.yaml を置いて、レビュー方針をコード化 するやり方。

さらに、今UIでいじってる設定があるなら、PRコメントでこれ叩くとYAMLで吐き出せます👇

@coderabbitai configuration

最小構成：まずはこのくらいでOK

まずは「 日本語 」「 要約あり 」「 自動レビューON 」くらいから始めるのが無難です。

# まずは「日本語」「要約あり」「自動レビューON」くらいから
language: "ja-JP"

reviews:
  profile: "chill"              # 最初はchillが無難（うるさすぎない）
  high_level_summary: true
  auto_review:
    enabled: true
    drafts: false               # Draft PRはレビューしない

chat:
  auto_reply: true

profile は chill と assertive があって、assertive の方が指摘多め（＝ノイズ増えがち）です。
最初は chill → 慣れたらassertive がおすすめ。

チーム運用で効く：おすすめ設定6つ

ここからが本題。
「導入したけど、結局使われなくなる」を防ぐなら、これが効きます。

1) まず “うるさくしない”

最初から指摘が多すぎると、みんなミュートします（あるある）。
なので最初は profile: chill でスタート。

2) Draft PRはスキップ

WIP段階でコメントされるとノイズになるので、Draftは切るのが無難。

reviews:
  auto_review:
    enabled: true
    drafts: false

3) 高レベル要約はON

レビューする側が読むコストが下がるので、これはON推奨。

reviews:
  high_level_summary: true

4) “ディレクトリ別に観点を変える”（これが一番うまい）

フロントとバックで「見てほしいポイント」って違うじゃないですか。
それをルール化できると、レビューが一気に実用寄りになります。

（例：UHDっぽく、React/TS と Go/SQL を分ける）

reviews:
  path_instructions:
    - path: "frontend/**"
      instructions: |
        React/TypeScriptの観点でレビューしてください。
        - Hooksの依存配列、再レンダリング
        - 型の安全性（any回避、null/undefinedの扱い）
        - MUI/Tailwindのスタイルの無駄・可読性
    - path: "backend/**"
      instructions: |
        Goの観点でレビューしてください。
        - エラーハンドリングとreturn漏れ
        - deferでのリソース解放
        - goroutine競合や共有データの扱い
    - path: "**/*.sql"
      instructions: |
        SQLの観点でレビューしてください。
        - JOINでNULLになるケースの考慮
        - インデックス/検索条件
        - 意図しない全件スキャンの可能性

5) ノイズの元を避ける（自動生成・依存系など）

例えば dist/ とか vendor/ とか、レビューしても意味薄いところは対象外にしたくなります。
（ここはチームの構成に合わせて調整）

6) 静的解析・セキュリティ系ツールと組み合わせる

AIの指摘は「気づき」に強い。
一方で lint / SAST は機械的に強い。

まとめ：CodeRabbitは“レビューの相棒”にちょうどいい

CodeRabbitは、ざっくり言うと PRレビューの初速と品質の底上げ に効くツールです。

まず導入してPRで動かす
.coderabbit.yaml を置く
profile と path_instructions を育てる

これだけで、レビュー体験がだいぶ変わります。

特に、レビューが属人化しがちなチームや、レビュー待ちで手が止まりがちな場面では、 「最初の一歩のレビュー」をAIに任せられる のがかなり助かります。
人のレビューを置き換えるというより、 人が本当に見るべきポイントに集中できる状態 を作れるのが良さですね。

UHDでもまずは小さめのリポジトリや、変更が多い機能開発のPRから試して、profile や path_instructions を育てつつ、チームに合う形に寄せていきたいと思います。
うまくハマれば、レビューのスピードも品質も一段上がるはずなので、 今後も積極的に活用していきます！

CordRabbit