CodeRabbit使いこなしTips × 11選

CodeRabbitを導入したものの、デフォルト設定のまま使っていたり、レビューコメントを確認するだけになっていたりするというチームも少なくありません。

CodeRabbitには、レビューの厳しさを調整する設定やリポジトリごとのルール適用をはじめ、レビューをチームの開発プロセスに合わせるための仕組みが用意されています。

この記事では、CodeRabbitのレビューをチームやプロジェクトに合わせて最適化するための11のポイントを紹介します。

1. .coderabbit.yamlでレビュー設定をコードとして管理する

まず押さえておきたいのが、リポジトリルートに配置する.coderabbit.yamlです。

.coderabbit.yamlはUI設定より優先され、Gitで管理できるため、設定変更そのものをPRとしてレビューできます。誰がいつ、どのようにレビュー方針を変更したのかを追跡できるのもメリットです。

特に重要なのがreviews.profileです。

reviews:
  profile: chill
  auto_review:
    enabled: true

CodeRabbitでは、レビューのスタイルを次の3種類から選択できます。

Profile	特徴	向いているケース
chill	バランス型。確度の高い指摘を中心にレビュー	多くのチームの初期設定
assertive	Nitを含め、より多くの指摘を出す	セキュリティ重視、品質強化期間、新規コードベース
quiet	重要度の高い指摘に絞る	コメント量が多すぎる、指摘が無視され始めている場合

profileは、レビュー量や開発者がコメントを受け入れやすいかどうかに大きく影響します。まずはchillから始め、チームの反応を見ながら調整するとよいでしょう。

また、CodeRabbitは40種類以上のLinterやSASTツールを利用でき、必要なツールだけを有効化したり、独自の設定ファイルを指定したりできます。

reviews:
  tools:
    pmd:
      enabled: true
      config_file: .config/pmd/ruleset.xml
    semgrep:
      enabled: true
    eslint:
      enabled: true

最初から大量の設定を追加するより、まずはprofile、tone_instructions、auto_review.enabled程度から始め、レビュー結果を見ながら徐々に設定を増やしていくのがおすすめです。

2. パスごとの指示で場所ごとにレビュー基準を変える

すべてのコードを同じ基準でレビューする必要はありません。たとえばAPIではセキュリティを厳しく確認したい一方、フロントエンドではReact Hooksのルールを重点的に確認したい、といったケースがあります。

そこで利用できるのがパスごとの指示（Path-Based Instructions）です。

reviews:
  path_instructions:
    - path: "src/api/**"
      instructions: >
        セキュリティへの注力：入力値の検証、SQLインジェクションのリスク、
        全エンドポイントでの認証チェック、および不適切なエラー情報の露出の有無を確認してください。
    - path: "src/components/**/*.tsx"
      instructions: >
        React Hooksのルールを強制します。関数コンポーネントの外部で呼び出されたHooksや、
        条件付きで呼び出されたHooksを指摘します。

    - path: "**/__generated__/**"
      instructions: レビューをスキップ — このディレクトリは自動生成されたものです。

globパターンによって対象パスを指定し、その場所だけに適用するレビュー指示を記述します。APIやUI、データベース、インフラ、テストなど、コードの役割によって確認すべき内容が異なるプロジェクトでは特に有効です。

ポイントは質問系ではなく、レビュー時に実行してほしい命令として記述することです。また、1つの指示にはできるだけ1つの関心事を持たせると管理しやすくなります。

3. コーディングガイドラインでチームの開発ルールをレビューに反映する

パスごとの指示と似ていますが、コーディングガイドラインは役割が異なります。Path-Based Instructionsが、どのコードをどのようにレビューするかを指定するのに対して、コーディングガイドラインは「チームとしてどのようなコードを書くべきか」という標準をCodeRabbitへ伝えるための仕組みです。

CodeRabbitは、リポジトリに存在する以下のようなファイルを利用できます。

• CLAUDE.md
• .cursorrules
• CODING_STANDARDS.md
• コーディングガイドラインとして明示的に登録したファイル

たとえば、すでにClaude CodeやCursor向けに開発ルールを書いているのであれば、それをCodeRabbitでも利用できます。

明示的に指定する場合は、次のように設定できます。

knowledge_base:
  code_guidelines:
    - path: "docs/ENGINEERING_STANDARDS.md"
    - path: "frontend/.cursorrules"
    - path: "backend/CLAUDE.md"

ここで注意したいのが、CLAUDE.mdなどをpath_instructionsへ指定しないことです。

そうすると、CLAUDE.mdをレビューするという意味になってしまいます。コーディングガイドラインとして参照させたいファイルはknowledge_base.code_guidelinesへ設定してください。

4. MCPで外部コンテキストをレビューに取り込む

コードだけでは正しいレビューができないケースもあります。たとえば、以下のような情報です。

• Jiraに書かれた要件
• NotionやConfluenceの設計ドキュメント
• Figmaの仕様
• Jenkinsのビルド結果
• SonarQubeの解析結果

それらの情報を利用するために、CodeRabbitではMCP（Model Context Protocol）で外部システムへ接続し、レビュー時のコンテキストとして利用できます。つまり、CodeRabbitはMCPクライアントとして動作し、接続したMCPサーバーから必要な情報を取得します。

重要なのが、MCPサーバーごとに設定できるユーザーガイダンスです。

ここには少なくとも、以下のような情報を記述してください。

1. そのMCPサーバーに何が保存されているか
2. CodeRabbitに何を探してほしいか
3. 情報がどのように整理されているか

たとえばNotionなら、以下のような指定になります。

このワークスペースにはエンジニア向けドキュメントがあります。
レビュー時には、エンジニアリングスペースにある以下の情報を参照してください。

- アーキテクチャについて
- API仕様書
- サービス手順書

HRやFinanceの情報は参照しないでください。

単にMCPを接続するだけではなく、どの情報をどう探してほしいかまで指定することが重要です。

5. 設定継承で組織共通設定を展開する

リポジトリが増えてくると、すべての.coderabbit.yamlを個別に管理するのは大変になります。底で使ってほしいのがConfiguration Inheritance（設定継承）です。これを利用すれば、組織共通の設定を親として持ちつつ、各リポジトリで必要な部分だけ上書きできます。

inheritance: true

reviews:
  profile: assertive

設定継承はデフォルトでは無効です。利用するには明示的にinheritance: trueを設定する必要があります。

Cloud/SaaS環境では、次の優先順位で設定が扱われます。

優先度	設定元
1	リポジトリの.coderabbit.yaml
2	組織のcoderabbitリポジトリにあるCentral YAML
3	リポジトリのUI設定
4	組織のUI設定
5	CodeRabbitのデフォルト値

また、値の種類によって継承方法も異なります。

型	マージ方法
オブジェクト	ディープマージ
配列	継承側を優先し、親側のユニークな値を追加
文字、数字	継承側の値で上書き

「組織として最低限守るルール」と「リポジトリ固有のルール」を分離したい場合に有効です。

6. 複数リポジトリ参照でリポジトリをまたいだ影響を確認する

ポリレポやマイクロサービスでは、1つのリポジトリだけを見ても変更の影響を判断できないことがあります。たとえばバックエンドのAPIレスポンスを変更する際、そのAPIを利用しているWebアプリやモバイルアプリは別リポジトリで開発されているといったケースです。

複数リポジトリ参照（Multi-Repo Analysis）を利用すると、CodeRabbitが関連リポジトリも参照しながらレビューできます。

確認できるものには、以下のような情報があります。

• API変更によるConsumerへの影響
• OpenAPI、GraphQL、ProtobufなどのContract Drift
• 共有型の変更
• Internal SDKや共通ライブラリの影響

CodeRabbitはpackage.json、go.mod、pyproject.toml、pom.xmlなどのパッケージマニフェストや、Docker/Kubernetesの参照、ワークスペース設定、Git Submoduleなどから関連リポジトリを検出できます。

なお、YAMLで個別に指定することもできます。

knowledge_base:
  linked_repositories:
    auto_link: true
    include:
      - org/payments-service
      - org/billing-contracts
    exclude:
      - org/archived-legacy-api

ポリレポやマイクロサービス環境では特に活用してほしい機能です。

7. カスタムマージ前チェックで品質ゲートを作る

CIが確認するのはビルドできるか、テストが通るかといった機械的な条件です。一方、CodeRabbitのカスタムマージ前チェック（Pre-Merge Checks）では、コード品質やレビューの完了状態をマージ条件として扱えます。

たとえば、次のような設定が考えられます。

チェック	推奨設定
重大コメントが未解決	マージをブロック
重要度の高いのセキュリティ上の指摘	マージをブロック
重要度の高いコメントが未解決	警告
Public APIのDocstring不足	警告
PR概要がない	情報

さらに、単純な重要度だけでなく、チーム固有の品質条件も設定できます。たとえば、以下のようなチェックを設定として記述できます。

• DBマイグレーションが後方互換性を維持しているか
• API変更が既存クライアントを破壊しないか
• ロール/権限/パーミッションのチェックが漏れていないか
• ログ、メトリクス、アラート、ロールバック手段が用意されているか
• 重大なセキュリティ上のIssueが残っていないか

最初からすべてをブロックにするのではなく、まず警告として運用した上で、どのチェックが頻繁に失敗するのかを確認してからブロックへ移行するとよいでしょう。

8. Learningsを育ててチーム固有の判断を覚えさせる

AIコードレビューでは、一般論としては正しくても、そのチームには当てはまらない指摘が出ることがあります。そのたびにコメントを却下するだけではなく、なぜその指摘が不要なのかをCodeRabbitへ伝えることで、Learningsとして蓄積できます。

たとえば、以下のようにコメントをしてください。

@coderabbitai

このModuleはNode 12との互換性を維持する必要があるため、
意図的にasync/awaitではなくcallbackを使用しています。
このDirectoryではasync/awaitへの変更を提案しないでください。

CodeRabbitはこの内容をナレッジベースへLearningとして保存し、その後のレビューコンテキストとして利用します。

Learningsには、たとえば次のような情報が向いています。

• 意図的なアーキテクチャ上の判断
• 命名規則
• テスト戦略
• 意図的に許容しているトレードオフ

一方で、組織全体で必ず守るべきルールについては、Learningのままにするのではなくコーディングガイドラインとして管理する方が良いです。Learningsは、正式なルールではカバーしきれない例外や細かな判断を扱う用途に向いています。

大規模組織では、Learningを登録する際に承認を必須にすることもできます。これにより、一人の開発者が意図せず組織全体のレビュー挙動を変更してしまうのを防げます。

9. IDE / CLIでPRを作る前にレビューする

CodeRabbitはPR上だけで利用する必要はありません。VS CodeやCursor、Devin Desktopでは、まだCommitしていないコードに対してフィードバックを受けられます。さらにCLIを利用するとステージング（前・後）、ローカルコミットした状態のファイルをプッシュ前にレビューできます。

CLIの場合、基本的な実行方法は次の通りです。

coderabbit --plain

AIエージェントから利用する場合には、以下のように行います。

coderabbit --prompt-only

シーン	推奨
コーディング中のリアルタイム確認	VS Code
プッシュ前の差分レビュー	coderabbit --plain
AIエージェントからの利用	coderabbit --prompt-only
CIでの自動チェック	CLI
通常のPRレビュー	CodeRabbitのPRレビュー

PRを作成してから指摘を受けるのではなく、開発者自身がプッシュ前に問題を解消できれば、人間のレビュアーに届く時点でのコード品質を高められます。

10. SkillsでAIコーディングとコードレビューをループさせる

Claude CodeやCursorなどのAIコーディングエージェントを利用している場合は、CodeRabbit Skillsも利用できます。SkillsはSKILL.mdとして定義され、AIエージェントにCodeRabbit CLIの使い方を教える仕組みです。

たとえば開発者が、 コードをレビューして と指示するだけで、SkillがCodeRabbit CLIを実行できます。CodeRabbitでは、次の2種類のSkillを利用できます。

Skill	用途
code-review	現在の変更をCodeRabbit CLIでレビューする
autofix	PR上の未解決CodeRabbitコメントを取得して修正する

特に重要なのが、AIによる実装とレビューをループできることです。

1. AIエージェントがコードを書く
2. CodeRabbit CLIでレビューする
3. 重大、重要の順に修正する
4. もう一度CodeRabbitでレビューする
5. 重大と重要がなくなるまで繰り返す

上記のようなフローを組むことで、AIにコードを書かせて終わるのではなく、レビュー工程をループ内へ組み込んで生成と検証を分離できます。

11. Change Stackで大規模PRを理解しやすくする

最後はChange Stackです。通常のGitHubのPR画面では、ファイルが一覧として並び、レビュアー自身が「どの順番で読めば変更を理解できるのか」を判断しなければなりません。

Change Stackでは、変更を関連性によってコホートへまとめ、基盤となるスキーマや定数、プロパティなどの変更を上位に、それを利用するクラス、関数、実装、テストへと各変更をレイヤーとして整理します。

主な機能は次の通りです。

機能	内容
コホート	関連する変更を概念単位でまとめる
レイヤー	変更を理解しやすい順番に整理する
レイヤーサマリー	各レイヤーの変更内容を要約する
図	シーケンス図やERDなどを生成する
コードピーク	シンボルの定義や利用箇所をその場で確認する
チャットエージェント	PR全体について質問する

特に、大規模なリファクタリングやスキーマ変換、API仕様変更、モノレポやマイクロサービスにまたがる変更などに向いています。

レビュー時にはレイヤーを上から順番に読むことで、ベースとなる変更から実装へ進みながら、変更全体の理解を進められます。

複数リポジトリ参照と組み合わせれば、以下のような組み合わせで大規模な変更を複数の観点からレビューできます。

• Change Stack
  このPRで何が変わったのかを理解
• 複数リポジトリ参照
  他のシステム・モジュールに与える影響を確認

まとめ

CodeRabbitを使いこなすポイントは、単にAIから多くのレビューコメントを出してもらうことではありません。プロジェクトのアーキテクチャやコーディングガイドライン、品質ゲート、外部ドキュメント、他リポジトリとの依存関係など、チームが実際にレビューするときに使っているコンテキストをCodeRabbitにも渡していくことが重要です。

まずは.coderabbit.yamlでレビューの基本方針を定義し、Path-Based Instructionsやコーディングガイドラインでチーム固有のコンテキストを追加するところから始めてみてください。

CodeRabbit