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

Claude Code ReviewとBugbotは、どちらもPull Requestに自動でコメントを付けるAIレビューです。違いが出るのは、動かせる条件、設定ファイルの置き場所、再レビューの範囲、請求の単位、そしてマージとの関わり方です。

先に結論を表にします。

使えるかどうかは、コードホストとプランで先に決まる

Claude Code Reviewは、GitHubにあるリポジトリが対象です。GitHub Enterprise ServerとGitHub Enterprise Cloud(データレジデンシー)も含みます。GitLabやBitbucketのリポジトリには使えません。

プランの条件もあります。TeamかEnterpriseの組織で、Claude組織のOwnerが有効化します。次の組織は対象外です。

• Zero Data Retentionを有効にしている組織
• HIPAA構成を適用している組織
• 顧客管理の暗号化キー(CMEK)を使う組織

Amazon Bedrock、Google Cloud、Microsoft Foundryの経由でClaude Codeを使っていても、Code Reviewのためには上記プランのClaude組織が別に要ります。

Bugbotは接続先が広く、GitHub(Enterprise Server含む)、GitLab(Self-Hosted含む)、Bitbucket(Data Center含む)、Azure DevOps、Originが並びます。GitHubでは、接続すると権限を与えたリポジトリでBugbotがオンになります。GitLab、Bitbucket、Azure DevOps、Originではリポジトリごとにオンにします。

GitLabやBitbucketでPRレビューを回しているチームにとって、この表は選択肢をほぼ決めてしまいます。Claude Code ReviewはGitHubのPR向けの機能なので、GitHub以外のホストで使う前提には置けません。

設定ファイルは、どのブランチから読まれるか

両者に共通する設計があります。レビューの指示は、PRの変更の中ではなく、マージ先の側から読まれます。

Claude Code ReviewはREVIEW.mdを、PRのベースブランチかデフォルトブランチから読み、PR自身の変更からは読みません。ルートのファイルに加え、サブディレクトリに置いたREVIEW.mdで、そのパス以下の変更だけに足すチェックを書けます。デフォルトブランチを保護していることが、重大度を下げる、パスを除外する、nitの上限を決めるといった指示が効く条件です。

# Review instructions
 
## What Important means here
 
Reserve Important for findings that would break behavior or leak data.
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/`

Bugbotの.cursor/config/bugbot.yamlも、リポジトリルートのファイルをPRのベースブランチから読みます。PRのヘッド側は読まないので、PRが自分自身のレビュー方法を書き換えることはできません。64KBを超えるファイルは無視されます。

# .cursor/config/bugbot.yaml
version: 1
 
triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr
 
review:
  effort: default # low | default | high | smart
  incremental: true
 
prSummary:
  mode: comment # disabled | description | comment
 
autofix:
  mode: disabled # disabled | newBranch | existingBranch

役割分担は異なります。bugbot.yamlが動作(いつ、どの強さで、どこに要約を出すか)を決め、レビューの観点は.cursor/BUGBOT.mdに書きます。REVIEW.mdは観点そのものを書くファイルで、いつ・どの深さで走らせるかは管理画面側の設定です。

優先順位にも違いがあります。Bugbotは、PR作者の個人設定、bugbot.yaml、チーム・組織のダッシュボード設定の順で効きます。Claude側は、深さ(Quick / Standard / Deep)と実行タイミングをOwnerが組織・リポジトリ単位で決め、リポジトリのファイルは観点だけを受け持ちます。

観点の書き方で、そろえにくいところ

同じチェックを両方に書く場合の差を挙げます。

• ネスト: Bugbotは.cursor/BUGBOT.mdを、変更ファイルから上へたどって見つかったものまで含めます。Claude側は、サブディレクトリのREVIEW.mdが読まれるのはデフォルトブランチが保護されているときなど、ブランチ保護の条件を満たすときです。
• 既存の規約ファイルとの関係: Claude Code ReviewはCLAUDE.mdもプロジェクトの文脈として読み、違反を指摘にします。Cursorのプロジェクトルール(.cursor/rules/の*.mdc)は、Bugbotには適用されません。
• 学習するルール: Bugbotにはチームの活動から自動で作るルールがあり、PR上で@cursor rememberと書いて覚えさせることもできます。ルール1件は30,000文字、合算は100,000文字が上限です。REVIEW.mdに同じ仕組みはありません。
• ローカルでの再現: ローカルの/code-reviewはCLAUDE.mdを読み、REVIEW.mdは読みません。両方で効かせたい規約はCLAUDE.mdに置きます。Bugbotは/review-bugbotで手元から走らせられ、同じ差分のパッチIDなら、PR側のレビューをスキップします。

Claude Codeを使うチームなら、CLAUDE.mdに書いた規約をそのままCode Reviewの観点にできる点が、移行コストの差になります。

再レビューは、どこまでを見直すのか

pushのたびに走る構成では、同じ指摘が毎回出ると読む側が疲れます。両者はここで似た手当てをしています。

Bugbotは、既定で前回のBugbotレビュー以降の変更だけを見ます。ダッシュボードでIncremental Reviewを切ると、pushごとにPR全体の差分を見ます。

Claude Code Reviewは、pushなどで自動的に始まる再レビューを、前回からの変更に絞ります。nitや既存バグの指摘も少なくなり、見送った件数は要約に書かれます。PR全体をもう一度見てほしいときは、@claude reviewとコメントします。

指摘への応答の仕組みも違います。Claude側は、スレッドをresolveするか修正をpushすると、次のレビューで直ったと判断した指摘のスレッドを閉じます。返信だけでは指摘は消えず、返信ではレビューも始まりません。BugbotはPRのコメント(トップレベルとインライン)を文脈として読み、重複した提案を避けます。

重大度と、マージを止めるかどうか

Claude Code Reviewの指摘は3段階です。

• 🔴 Important: マージ前に直すべきバグ
• 🟡 Nit: 軽微な問題
• 🟣 Pre-existing: このPRが入れたものではない既存のバグ

レビューは承認もブロックもしません。Claude Code Reviewというcheck runは、失敗で終わることがなく、neutralか、変更ファイルのない自動レビューではskippedになります。マージを止めたいときは、check runの詳細にあるbughunter-severityの行をCIで読み、Importantの件数(normalキー)が0を超えたらジョブを落とす手順が用意されています。行が無いのは判定なしとして扱い、0件とは読みません。

Bugbotのチェック(GitHubではCursor Bugbot)の結論は次の3つです。

ブランチ保護でBugbotのチェックを必須にしても、既定では指摘があってもマージは止まりません。neutralだからです。未解決の指摘で失敗させる設定が自分の組織で使えるなら、それをオンにします。

どちらも、既定のままでは「走ったことは保証されるが、直したことは保証されない」状態です。止めたい場合は、Claude側はCIでスクリプトを書き、Bugbot側は設定を選びます。止める仕組みが設定で済むか、自前のコードが要るかが差です。

課金は、請求先も数え方も別物

Claude Code Reviewはトークン使用量に応じて、使用量クレジットから課金されます。プランに含まれる使用量とは別で、請求先は開発者個人ではなく組織です。月ごとの上限を組織単位で決められ、上限・組織全体の上限・クレジット残高のどれかが尽きると、そのレビューは見送られます。見積もりは、リポジトリごとの平均コストにPR数を掛け、「After every push」ならpush回数も掛けます。詳しい手順はClaude Code Reviewの費用を見積もり、月額上限で止める方法にあります。

Bugbotは使用量ベースの課金です。個人でもチームでも、含まれる使用量を先に使い、超えた分のレビューは前払いクレジット(旧Cursorプランではオンデマンド利用)から引かれます。単価はCursorの料金ページに載っていて、プランの改定で変わります。レビューの強さを選ぶEffort(Low / Default / High / Smart)は、使用量ベースのプランでのみ使えます。

実行回数を抑える手段は、両者で近い形です。

Claude側で注意したいのは、リポジトリを追加した直後の設定がAfter every pushになっている点です。最も実行回数が多い設定なので、パイロットでは先にOnce after PR creationかManualへ変えます。

Bugbotにあって、Code Reviewに無いもの

機能の幅ではBugbotが広い面もあります。

• Autofix: 指摘を直すCloud Agentを起動し、新しいブランチか既存ブランチにpushします。既存ブランチへのコミットは1PRあたり最大3回です。GitHub以外では選べるモードが減り、Azure DevOpsではどちらも使えません。使うには追加の利用枠(前払いクレジットなど)とストレージ有効化が要ります。
• PRの要約: 既定では説明欄(In Description)に要約を置き、コメントへの切り替えもできます。レビューのたびに更新します。
• Fix in Cursor / Fix in Web: 指摘から直接エディタかWebのエージェントへ移れます。
• MCP対応: TeamとEnterpriseでのみ使えます。
• 認証情報ファイル: .envや*.pemのようなパスのファイルは中身を読みません。.env.exampleのようなテンプレートは通常どおりレビューします。

Claude Code Reviewの側に特徴があるのは、仕組みの設計です。複数のエージェントが並行して差分と周辺コードを読み、検証ステップで候補をコードと照らして偽陽性を落とし、重複を除いて重大度順に並べます。リポジトリへのアクセスは読み取り専用で、レビュー中にコードをビルドも実行もしません。コミットをpushすることもありません。

モデルは選べません。調整できるのは、Quick / Standard / Deepのレビュー深度です。

併用するなら、ここで衝突する

同じPRにどちらも走らせることはできますが、先に決めておくことがあります。

1. 必須チェックを何にするか: どちらのチェックも既定で失敗にならないので、必須にしても止まりません。止める役を片方に決めます。
2. 観点を二重に書かない: 規約はCLAUDE.mdに1つ置けば、Claude側のCode Reviewとローカルの/code-reviewの両方が読みます。Bugbot側のBUGBOT.mdには、Claudeと重複しない規約だけを足します。
3. 手動起動の文言: Claude Code GitHub Actionを対話モードで使い、既定の@claudeトリガーのままだと、@claude reviewのコメントでActionも起動します。trigger_phraseを別の語にして切り分けます。
4. コスト: 請求は別々に発生します。pushごとに両方が走る構成は、請求が合算されます。

Claudeのレビューがスキップされたときの切り分けは、Claude Code Reviewがスキップ・失敗するときの切り分けにまとめています。

どちらを選ぶか

• GitLab、Bitbucket、Azure DevOpsが主戦場: 候補はBugbotです。
• GitHubで、すでにTeam・Enterpriseプランがある: Claude Code ReviewはOwnerが有効化するだけで始められ、課金も同じAnthropicの請求に載ります。
• ZDR・HIPAA・CMEKが必須: Claude Code Reviewは使えません。
• 指摘の自動修正まで回したい: Autofixを持つBugbotが前に出ます。
• 規約をCLAUDE.mdに集約したい: Claude Code Reviewなら、ローカルのレビューと同じ文脈で動きます。
• CursorをIDEとして使っている: エディタ側の選択はClaude CodeとCursorの違いが扱っています。レビューだけを別に選ぶ余地は残ります。

他社のレビューツールとの比較は、CodeRabbitとの違いとCopilot code reviewとの違いにあります。ローカルで観点別に回すなら、pr-review-toolkitが別の選択肢です。

まとめ

二つの違いは、AIの賢さの差より運用の枠組みの差として現れます。対応ホスト、設定の読まれ方、再レビューの範囲、請求の単位、止める手段の五つを先に見れば、自分のチームでどちらが成立するかはほぼ決まります。

両者に共通するのは、設定をマージ先から読み、既定では指摘がマージを止めない点です。ここを理解せずに入れると、「入れたのに何も止まらない」という不満になります。入れる前に、止める役をだれが担うかを決めておくと、導入後の迷いが減ります。