AI コードレビューにCursor Bugbotを使うには？料金・設定・自動修正を解説

私の見解： PRでの指摘をCursorでの修正作業につなげたいチームなら、Bugbotは有力な候補です。人による承認と既存の自動チェックは引き続き必要です。Azure DevOpsではBugbot Autofixが使えないため、レビュー機能そのものの価値で評価してください。GitLabとBitbucketでは、Autofixを有効にする前に、PRブランチへの直接の修正を認める運用がチームに合うかを判断しましょう。

Cursor BugbotのAI コードレビューで確認できること

Bugbotは、プルリクエストの差分、つまりマージしようとしている変更を対象に、バグ、セキュリティ上の問題、コード品質の問題を探します。建物の改修工事を検査する場面を思い浮かべるとわかりやすいでしょう。変更した箇所が確認の出発点で、リポジトリのルールがその建物固有の要件に当たります。

レビューはPRの更新時に実行できるほか、コメントにcursor reviewまたはbugbot runと書いて実行することもできます。PR全体へのコメントやコード行に付いた既存のコメントも文脈として使われるため、それまでのフィードバックを踏まえたレビューにつながります。指摘には説明と修正案が付き、CursorやWebで作業を続けるためのリンクも表示されます。Bugbotの仕組み。

実務上の価値は、そのままならレビューをすり抜けていたかもしれない不具合に、早く目を向けられることです。コメント数では、その価値を測れません。実際の不具合を捉えているか、発生条件を説明しているか、有効な修正につながるかで指摘を評価しましょう。テスト、セキュリティスキャン、コードの担当者によるレビューも継続してください。

リポジトリごとにBugbotを設定する

Cursorの連携ダッシュボードからソース管理サービスを接続し、Automations内のBugbotを開いて、レビュー対象のリポジトリを有効にします。サービスの接続とリポジトリの有効化は別の手順です。CursorはGitHub、GitLab、Bitbucket、Azure DevOps Servicesのセットアップに対応しており、最初の3サービスについては、ドキュメントに記載されたセルフホスト版にも対応しています。Bugbotのセットアップ。

GitHub

Cursorの管理者権限とGitHub organizationの管理者権限が必要です。IntegrationsでGitHubの横にあるConnectを選びます。すでに接続済みならManage Connectionsを選んでください。All repositoriesまたはSelected repositoriesを選択して接続を完了し、Cursorに戻って、選んだリポジトリをBugbotで有効にします。GitHub Enterprise Serverには専用のセットアップタブとネットワーク設定の案内があります。CursorのGitHub連携。

GitLab

GitLab.comでは、Cursorの管理者権限、GitLabのMaintainer権限、有料のGitLab PremiumまたはUltimateプランが必要です。Cursorが必要とするプロジェクトアクセストークンは、GitLab Freeでは提供されません。IntegrationsでConnectまたはManage Connectionsを選び、GitLabへのインストールを完了します。その後、Manage → Sync Reposを実行してから、Bugbotでリポジトリを有効にしてください。セルフホスト環境には別の接続手順があります。CursorのGitLab連携。

Bitbucket

Bitbucket Cloudへの対応は現在パブリックベータです。Integrationsからアカウントを接続し、Cursorを認可します。ワークスペースにはCursorアプリも必要です。Bitbucketのワークスペース管理者がCursor内のBitbucket管理メニューを開き、Install Cursor appを選んでワークスペースにインストールします。次に、そのワークスペースにアクセスできるCursorのチーム管理者が、Bitbucketのワークスペース設定でForge Apps → Cursorを開き、Connect to Cursorを選んでチームを接続します。その後、Bugbotでリポジトリを有効にしてください。個人アカウントの接続だけでは、レビューコメントを投稿するアプリのIDは設定されません。Bitbucket Data Centerには別のセットアップ手順があります。CursorのBitbucket連携。

Azure DevOps

Azure DevOps Servicesでは、Bugbot専用のセットアップ手順を使います。Microsoft Entraのテナント管理者による同意が必要です。Project Collection AdministratorがAzure DevOpsを接続してリポジトリのBugbotを有効にすると、組織内でアプリケーションのIDとなるCursorのサービスプリンシパルが作成されます。プロジェクト管理者は、レビュー対象となる各プロジェクトのProject AdministratorsにこのIDを追加する必要があります。これにより、レビューを起動する通知であるサービスフックを管理できるようになります。

権限変更の反映には時間がかかることがあります。セットアップエラーがあれば解消し、リポジトリの有効化を再試行してください。Bugbotが対応するのはチームのリポジトリで、個人スコープのリポジトリには対応していません。CursorのAzure DevOps向けBugbotセットアップ。

レビューの実行条件を決める

有効にしたリポジトリごとに、更新のたびにレビューするか、PRごとに1回だけ実行するかを決め、必要に応じて作成者の許可リストや拒否リストを設定します。個人設定では、その作成者のPRについて、メンション時だけ実行する、PRごとに1回にする、ドラフトも対象にする、といった指定ができます。有効化したリポジトリでは、Cursorチームに所属していない貢献者の変更もレビューできます。リポジトリ設定と個人設定。

Azure DevOpsで手動実行する場合には、追加の条件があります。コメントした人のAzure DevOpsサインイン用アドレスが、そのリポジトリを所有するチーム内のCursorアカウントと一致していなければなりません。自動レビューにはこの制限はありません。Azure DevOpsでの実行条件。

.cursor/config/bugbot.yamlの設定例と読み込みルール

レビューの動作設定を変更するときにもコードレビューを通したいなら、設定をリポジトリに保存します。以下は、Cursorのリポジトリ設定ドキュメントに掲載されている例です。

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

リポジトリのルートを基準に、上記のパスへファイルを置き、コミットしてプッシュします。Bugbotが読むのは、変更のマージ先であるPRのベースブランチ上のファイルです。PRのheadブランチにあるファイルは使いません。そのため、提案中の変更が自身のレビュー設定を書き換えることはできません。リポジトリ内のファイルの担当者を定める仕組みであるCODEOWNERSを使い、設定変更を誰がレビューするかを管理してください。

すべてのフィールドは省略可能です。欠けているフィールドや無効なフィールドがある場合は、次に優先される設定が使われます。64 KBを超えるファイルは無視されます。優先順位は次のとおりです。

1. PR作成者が自分のPRに適用する個人設定のオーバーライド。
2. リポジトリのYAMLファイル。
3. チームおよび組織のダッシュボード設定。

この順序は重要です。YAMLだけを確認しても、ある作成者にどの設定が適用されるかは判断できません。また、autofix.modeではダッシュボードが許可した範囲を狭めることはできますが、ダッシュボードで無効にされているAutofixを有効にすることはできません。設定の動作と優先順位。

この例は要約をコメントとして投稿する設定を選んだもので、ダッシュボードのデフォルト設定をすべて列挙したものではありません。この指定がなければ、PRの要約はデフォルトで説明欄に記載されます。インクリメンタルレビューは、前回のBugbotレビュー以降の変更を調べます。レビューのeffortを高くすると、バグの探索に費やす時間や利用量が増える場合があります。Smartでは、与えた指示に応じてeffortの水準が決まります。要約、インクリメンタルレビュー、effort。

BUGBOT.mdにプロジェクトのレビュー指示を書く

プロジェクトをレビューするうえで必要な知識は、.cursor/BUGBOT.mdに記述します。ルートにあるファイルは常に読み込まれます。Bugbotは変更されたファイルから上位ディレクトリへたどり、下位階層に置かれた.cursor/BUGBOT.mdも探します。そのため、バックエンドのディレクトリに、フロントエンドとは異なる指示を持たせることができます。.cursor/rules/*.mdcにあるCursorエディターのルールは、Bugbotには適用されません。Bugbotのプロジェクトルール。

有効なルールは、必ず守るべき条件と、注意すべき不具合を具体的に示します。たとえば決済チームなら、処理を再試行しても顧客に二重請求してはならない、という要件を書けます。バックエンドのチームなら、どの状態遷移で監査ログへの記録が必要かを説明できます。これらはルールに盛り込む内容の例であり、Bugbotがすべての違反を検出するという約束ではありません。

チームのルール、プロジェクトのルールファイル、学習したルール、手動で設定したリポジトリのルールは組み合わせて使われます。ダッシュボードの学習ルールと手動ルールを使うには、組織とリポジトリで学習を有効にする必要があります。指示は要点を絞ってください。各ルールは30,000文字で切り詰められ、レビュールール全体の上限は100,000文字です。実際に読み込まれた内容を確認するには、bugbot run verbose=trueまたはcursor review verbose=trueとコメントします。応答には、読み込まれたルール、切り詰められたルール、省略されたルールが示されます。ルールと上限。

Bugbotの料金体系と予算の考え方

Bugbotの予算は利用量を基準に組み、Autofixの費用は別に見積もります。Cursorによる現在の説明は次のとおりです。

これが現在のBugbotの課金条件です。チームのエディター用利用枠でBugbotのレビュー費用もまかなえるとは考えないでください。AutofixはCloud Agentクレジットを消費し、契約中のプランの料金が適用されます。Autofixの課金。

5月の料金改定は、既存の契約には2026年6月8日より後の最初の更新時に適用されます。そのため、従来の年間契約は更新まで以前の条件が続く場合があります。Cursorの料金改定のお知らせ。

現在のBugbotドキュメントには、そのまま予算計算に使える固定のレビュー単価は示されていません。PRの複雑さ、レビューの頻度、effortの設定によって実行される作業は変わります。サービス提供元が示す平均実行コストは参考情報であり、自分たちのリポジトリに保証された単価ではありません。

費用対効果を判断する際は、レビュー費用＋Autofix費用＋エンジニアが指摘を評価する時間を、チームが減らせたレビューや手戻りの工数と比べます。既存の人によるレビューの予算も引き続き必要です。導入の判断を左右するのは、役立つ指摘が得られ、確認にかける労力が減るかどうかです。ボットがコメントを生成できること自体ではありません。

AutofixとMCP、それぞれの利用条件

Autofixは、リモートでコードを扱うエージェントであるCloud Agentを起動し、Bugbotの指摘に対応してPRへ結果を報告します。利用にはオンデマンド利用とストレージの有効化が必要です。Legacy Privacy Modeでは、このストレージ要件を満たしません。Bugbot Automationsで、対応しているモードを選んでください。Autofixの利用条件。

上記は、Cursorがドキュメントで示しているAutofixの対応モードです。既存ブランチを使うモードでは、ループを防ぐために試行回数がPRごとに最大3回に制限されます。私なら、生成された修正をどうレビューするかをチームで合意するまでは、Autofixを無効にして始めます。GitHubを使うチームなら、合意後に新しいブランチを使うモードを選び、修正を分けて確認できます。

MCPは、AIツールから他のツールやコンテキストへアクセスするためのプロトコルで、Bugbotのレビュープロセスを拡張できます。MCPサーバーを設定し、AutomationsでそのツールをBugbotに追加します。BugbotのMCP対応はTeamプランとEnterpriseプランに限られます。 MCPを利用できるプラン。

Bugbot・CodeRabbit・Greptileを比較する

普段の作業フローに合うか、管理できる料金体系かを基準に選びましょう。以下は公開されている料金の比較であり、比較テストの結果ではありません。

出典：Cursor Bugbot、CodeRabbitの料金、Greptileの料金。CodeRabbitの年払いの金額は、年間契約時の月額換算です。Greptileのクレジットは、Cursorの利用量やCodeRabbitのレビュー済みファイル単位の課金と同じ尺度では扱えません。

予算面での違いは明確です。CodeRabbitはシート単位の契約に加えて、継続レビューの費用が発生する場合があります。Greptileはシート数とクレジットを組み合わせます。現在のBugbotでは、レビューの利用量が費用を左右する中心的な変数です。シート料金だけを見て、チームにとってどれが最安かを断定することはできません。

より詳しい直接比較はGreptileとCodeRabbitの比較をご覧ください。候補を広げたい場合は、CodeRabbitの代替ツールと少人数チーム向けAIコードレビューツールも参考になります。

どのようなチームで価値が出やすいか

私なら、不具合を見逃した場合の損失が、指摘を確認するための労力を上回るワークフローから優先して導入します。以下は、私が着手する順に並べた活用例であり、実測した成果ではありません。

これらの例で使うレビュー、コンテキスト、ルール、Autofixの仕組みは、CursorのBugbotガイドに記載されています。実際にどれだけ役立つかは、コードとレビュー担当者次第です。

Bugbotの周辺で作る価値のあるツール

最も有望なのは、エンジニアリング責任者がレビューの費用と成果を把握できるようにすることです。すでに実績のあるツールがレビューを提供しているため、コメントを生成するツールをもう1つ作るだけでは、価値を打ち出しにくいでしょう。

レビュー費用と成果を記録するダッシュボード

プラットフォームチームなら、リポジトリごとの支出と、エンジニアが採用・却下・修正した指摘を結び付けるダッシュボードを作れます。購入者として想定するのはエンジニアリング責任者です。Greptile Proの1シートあたり月額$30という価格は、有料のレビュー製品という市場が成立している根拠にはなります。ただし、その顧客がこの追加ツールにもお金を払う証拠ではありません。Greptileの料金。

最小限でも役立つ形にするなら、指摘と請求記録に、人が付ける有用性のラベルを組み合わせます。CursorのEnterprise向けレビューAPIでは、指摘や請求額を含むレビュー分析データを取得できます。ただし、費用のフィールドに請求額が入っていない場合もあります。Enterprise以外の利用者向けに作るなら、このAPIを使えると想定せず、承認された手動入力が必要です。BugbotのAPIと分析機能。

注意点： 解決済みコメントの数は、価値のあるバグ検出の不完全な代替指標にすぎません。また、請求額を十分にひも付けられないと、ダッシュボードが誤解を招くおそれがあります。それでも私なら、これを最初に作ります。契約更新のたびに問われる「このレビューサービスは、総費用に見合っているか」に答えられるからです。

リポジトリのレビューポリシーを点検するツール

プラットフォームエンジニアリング部門には、リポジトリを調べ、承認済みのBugbot設定が使われているか、プロジェクトのルールが欠けていないか、レビューされていないポリシー変更がないかを確認するツールが考えられます。CodeRabbit Teamの月払い料金である開発者あたり月額$60は、チームのレビュー運用が有料製品の領域にあることを示しています。ただし、独立したポリシー管理ツールへの支払い意向は、別途検証する必要があります。CodeRabbitの料金。

最小構成なら、リポジトリのファイルを読み、担当者が確認できるレポートを出力します。注意点： 個人設定はYAMLより優先されるため、ファイルの点検だけでは、実際に適用されるレビューの動作を保証できません。この制約を明示し、アクセス権限で許可される範囲で、ダッシュボード設定も確認プロセスに組み込んでください。Bugbot設定の優先順位。

マージ承認の条件を明確にする

Bugbotのチェックを必須にしても、未解決の指摘が自動的にマージを止めるとは限りません。デフォルトでは、指摘があっても結果はneutralになります。ステータスを必須にする設定が保証するのは、チェックが実行されることです。組織でfail-on-unresolved-issuesを利用できる場合は、この設定により指摘を失敗ステータスに変えられます。ブランチ保護に頼る前に、その設定を確認してください。Bugbotのチェックステータス。

私が勧めるのは、Bugbotをレビュー担当者の判断材料を増やす手段として使うことです。指摘がないレポートだけでは、機能が要件を満たしている証明にはなりません。自動生成されたパッチにも、他のコードと同じ慎重な確認が必要です。

最初に取り組むこと

まずは、検出したい不具合を担当者が具体的に説明できるリポジトリを選びます。必要な権限を持つ管理者にサービスの接続を完了してもらい、そのリポジトリでBugbotを有効にします。設定をベースブランチへコミットし、要点を絞ったレビュールールを書いてください。予算の責任者を決め、Autofixの導入は別に判断します。対象を広げる前に、普段のレビュー業務の中で、役立った指摘、却下した提案、それぞれの評価に費やした時間を記録しましょう。

レビューのレポート機能やリポジトリ管理を開発・リリースのワークフローに組み込みたい場合は、AI自動化の導入をご支援します。