Claude Code ReviewとCodeRabbitの違い — 設定・課金・提供条件

Claude Code ReviewとCodeRabbitは、どちらもGitHubのプルリクエストに自動でレビューコメントを付けます。違いが出るのは、使える条件、設定の置き場所、レビューの回数に対する課金の仕方の3点です。先に結論を表にします。

まず提供条件で絞られる

Claude Code Reviewは、組織のプランがTeamかEnterpriseでなければ入口に立てません。さらにZero Data Retentionを有効にした組織、HIPAA構成の組織、顧客管理の暗号鍵(CMEK)を使う組織は対象外です。コードの置き場はGitHubに限られます。

Team・Enterprise以外のプランや、GitLabでPRを回しているチームは、この時点で選択肢から外れます。BedrockやFoundry経由でClaude Codeを使っている場合も、レビューを使うにはClaude組織が別に要ります。

CodeRabbitは、GitHub、GitLab、Azure DevOps、Bitbucketの4つのGitに対応すると導入ページに書かれています。プランはFreeとOSS、有料のEssentials / Team / Advanced / Enterpriseです。

提供条件で悩むのは、おおむね次の3パターンです。

• GitLabやBitbucketのチーム: CodeRabbitしか選べません
• ZDRを有効にした組織: Claude Code Reviewは使えません。ローカルで /code-review を回す道は残ります
• Team以上のClaude組織があるGitHubのチーム: 両方を試せます

設定ファイルの置き場所と読まれ方

Claude Code Reviewの設定は、リポジトリのルートに置くMarkdownです。CLAUDE.md はプロジェクト全体の規約として読まれ、REVIEW.md はレビューだけに効く指示です。サブディレクトリにも REVIEW.md を置けます。

# Review instructions
 
## What Important means here
 
Reserve Important for findings that would break behavior,
leak data, or block a rollback. Style and naming are Nit at most.
 
## Cap the nits
 
Report at most five Nits per review.
 
## Do not report
 
- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file

ここで落とし穴になるのが、読まれるブランチです。REVIEW.md はPR自身の変更からは読まれず、ベースブランチかデフォルトブランチのものが使われます。デフォルトブランチを保護していないと、重要度を下げる指示やパスの除外、nit数の上限が効かない構成があります。ルールを変えたいときは、REVIEW.md の変更を先にマージします。

CodeRabbitの設定はYAMLです。ルートの .coderabbit.yaml に書き、レビュー対象のフィーチャーブランチ上の設定がそのレビューに使われます。つまり、設定の変更をPRに含めて試せます。Claude Code Reviewとは逆の作りです。

reviews:
  path_instructions:
    - path: "src/controllers/**"
      instructions: |
        - Focus on authentication, authorization, and input validation.
    - path: "tests/**"
      instructions: |
        - Descriptive test names are used to clearly convey the intent.
  auto_review:
    drafts: false

パスごとに指示を変えられる点は、REVIEW.md のサブディレクトリ版とほぼ同じ役割です。違うのは書式で、CodeRabbitはglobとYAMLのキー、Claude Code Reviewは自然文です。リポジトリ間で設定を共有したいときは、CodeRabbitに remote_config で別リポジトリのYAMLを参照する仕組みがあります。

CLAUDE.mdを書いているなら重複に注意する

CodeRabbitは CLAUDE.md や AGENTS.md、.cursorrules を自動で見つけ、追加設定なしにレビュー基準として使うと説明しています。ファイル名の大文字小文字は区別されます。

Claude Codeのために CLAUDE.md を整えているチームは、同じ規約を両方のレビューに効かせられます。両方を入れるなら、規約は CLAUDE.md に集め、レビュー専用の調整だけを REVIEW.md や .coderabbit.yaml に分けると二重管理を避けられます。

指摘の出し方

Claude Code Reviewは、複数のエージェントが差分と周辺コードを並行して読みます。その後の検証ステップが候補をコードと突き合わせて誤検知を落とし、重複を除いて重要度順に並べます。既定の関心は正しさで、本番を壊すバグを探し、書式やテスト不足は主眼にしません。

指摘は3段階の印が付きます。

指摘が消える条件や、スレッドの解消の挙動はResolve conversationの意味にまとめています。

CodeRabbitの導入ページは、AIによるコードレビューに加えて、PRの優先度づけ(Triage)、大きな差分を整理するChange Stack、セキュリティスキャンを一つの製品群として並べています。PRレビューのページには、バグ検出、ワンクリックの修正、リポジトリ全体を踏まえた提案、フィードバックを覚えて次に反映する仕組みが挙がっています。レビューコメントに @coderabbitai と返信して会話を続けることもできます。

つまり、前者は「見つけた指摘を検証して絞る」設計で、後者は「レビューの周辺工程まで含めた製品群」です。どちらのドキュメントも、指摘件数や誤検知率の数値は出していません。粒度は、次の節の調整手段をどこまで使うかで決まります。

粒度を調整する手段の違い

Claude Code Reviewで効くのは、REVIEW.md に書く文章です。どれを重要にするか、nitを何件で打ち切るか、どのパスを見ないか、根拠の引用を必須にするか、を指示できます。レビューの深さ自体は、組織またはリポジトリごとのレビューレベル(Quick / Standard / Deep)で変わります。モデルは選べません。

CodeRabbitでは、path_instructions で観点をパスごとに変えられます。自動レビューは auto_review で、対象ブランチ、下書きPR、ラベルなどの条件を絞れます。手動では @coderabbitai review(差分のみ)と @coderabbitai full review(最初から)を使い分けます。

課金の見方が根本的に違う

Claude Code Reviewに定額のレビュー単価はありません。1回の費用はレビューレベル、変更の大きさ、周辺コードの複雑さ、検証が要る候補の数で決まります。請求は利用クレジットで、プランの含有分とは別です。請求先は組織で、PRを開いた開発者個人ではありません。

回数側の変数はリポジトリごとの「Review runs」です。

• Once after PR creation: PRを開いたとき、再オープンしたとき、ready for reviewにしたとき
• After every push: pushのたびに走り、費用はpush回数に比例する
• Manual: @claude review のコメントで1回だけ走る

管理画面からリポジトリを追加した直後は、最も回数が多い「After every push」から始まります。見積もりは、少数のリポジトリで「Once after PR creation」か「Manual」にして試し、管理画面のAverage costに月間PR数を掛けて出します。上限はClaude Code Reviewのサービス単位で月額を設定でき、尽きるとレビューはスキップされてPRにコメントが出ます。

CodeRabbitの課金は、人数の側に寄っています。プランは開発者ごとに割り当てる席に紐づき、レビューやチャットの上限は開発者ごとに1時間の窓で数えられます。Free・OSSと有料4プランに加え、上限を超えた分をクレジットで払う使用量ベースのレビューを足せます。

気をつけたいのは、CodeRabbitの上限が開発者の識別ごとに効く点です。CIのボットや共有アカウントが全PRを開くと、組織全体のレビューがその1つの識別に集中し、他の席が余っていても上限に当たります。AIエージェントがPRを量産する運用では、起票アカウントの設計が課金の見え方を左右します。

プランごとの金額と時間あたりの上限値は、契約前にCodeRabbitの料金ページで確かめます。

費用を抑える入口の違い

回数を減らす手段も対になっています。

マージとの関わり方

Claude Code Reviewは、PRを承認もブロックもしません。チェックランは「Claude Code Review」という名前で出ますが、失敗として終了しません。マージを止めたいときは、チェックランの詳細の最終行に入っている重要度ごとの件数をCIで読み、Importantが1件以上なら落とす構成にします。手順はGitHub PR自動レビューの設定・運用に書いています。

CodeRabbitには request_changes_workflow という設定キーがあり、レビューの判断を解消済みのフィードバックやPre-Merge Checksと同期させる仕組みがあります。ゲートとして使うか、助言に留めるかを設定で選べる作りです。ただし、request_changes_workflow の設定リファレンスには、差し戻しを出す重大度の条件は載っていません。ゲートとして使う前に、テスト用のリポジトリで差し戻しが出る条件を確かめられます。

どちらを入れるかの判断

条件を並べると、判断はほぼ前提で決まります。

• GitHub以外を使っている: CodeRabbit
• ZDR、HIPAA構成、CMEKのいずれかを使っている: Claude Code Reviewは使えない
• 課金を「使った分」にしたい: Claude Code Review。上限は月額で一括管理できる
• 課金を「人数」で見積もりたい: CodeRabbit。ボットのアカウント設計に注意
• 規約を CLAUDE.md に集約している: どちらも読むので、共通化が効く
• Anthropicのモデルで、検証付きの指摘に絞りたい: Claude Code Review

併用もできます。ただし両方が同じPRにコメントすると、指摘が重なって読む量が増えます。併用するなら、片方を Manual やラベルでのopt-inにして対象PRを分けるのが無難です。

Claude Code自身にレビューを任せる別の経路は、自前のワークフローやサブエージェントです。観点別に専門エージェントを分ける方法はpr-review-toolkitで、チームの承認フローに組み込む考え方はコードレビューの7つの層で扱っています。

まとめ

差が出るのは、使える条件と課金の単位です。Claude Code ReviewはTeam / Enterpriseで、GitHub限定、トークン使用量ベースの課金。CodeRabbitは4つのGitに対応し、開発者ごとの席とレビュー上限で数えます。

指摘の質は公開された比較値が無いので、同じPRを数本、両方に通して比べるのが最短です。そのとき、REVIEW.md と .coderabbit.yaml に同じ除外ルール(生成ファイル、CIが見るもの)を先に書いておくと、比較がぶれません。