Cursorでコードレビューをするときは、対象差分、レビューへ渡すルール、指摘の検証を分けます。ローカルのAgent Reviewと、PRを確認するBugbotでは入口が異なります。レビューが完了したことと、変更を安全に取り込めることも別です。
この記事は公式資料に基づく確認手順です。Cursor、Bugbot、GitHubでの実行・設定変更は行っていません。後半の差分と記録は説明用の架空例です。
目次
最初に、どの差分を読むか決める
レビューを始める前に、変更ファイル、変更理由、比較元ブランチを控えます。無関係な作業中の変更が含まれるなら、その扱いを決めます。レビュー範囲を狭めるために、他の人の変更を削除したり、履歴を戻したりする必要はありません。
表は横にスクロールできます
| 確認すること | 記録する内容 |
|---|---|
| 目的 | 修正したい不具合、維持したい仕様 |
| 対象 | ファイル、差分、比較元、対象コミット |
| 観点 | 認可、空入力、二重実行、互換性など |
| 実行結果 | 何のテストを、どの版で実行したか |
| 未確認 | 外部接続、運用設定、移行順など |
「全体をよくして」ではなく、確認したい失敗場面を示します。例えば、別の利用者のデータへアクセスできないこと、失敗時に部分更新が残らないこと、通常入力を受け付けることです。
ローカル変更はAgent Reviewで対象範囲を確認する
公式のAgent Review（新しいタブで開く）は、Cursor内でローカル変更をレビューする機能です。入力欄の/agent-reviewやSource Controlから開始する方法を案内しています。Source Controlの経路は、mainブランチに対するローカル変更全体を比較する説明です。「直前に編集した一ファイルだけ」と思い込まず、実際の差分を確認してください。
設定場所は、公式ではCursor SettingsのAgents内とされ、Cursor 3.11からはGit & PRsのPull Requestsへ移る説明があります。手元のバージョンに合わせて探します。
表は横にスクロールできます
| 深さ | 公式の用途例 | 選ぶ際の考え方 |
|---|---|---|
| Quick | 小さな差分、書式変更、短い確認 | 範囲が狭い変更をまず見る |
| Deep | 複雑なロジック、セキュリティ上重要なコード、大きな改修 | 影響する経路を丁寧に確認したい場合 |
深さの選択は、バグが見つからない保証ではありません。Deepでも実際のテスト結果とは別に扱います。自動実行については、同じ公式ページにタスク後とコミット後の説明があるため、特定のタイミングを一律に約束せず、利用版の設定と実行記録を確認します。
Bugbotには専用ルールを渡す
PRレビューのBugbot公式資料（新しいタブで開く）は、.cursor/rules/の.mdcをBugbotへ適用しないと説明しています。Agent用Project Rulesを置いただけでは、Bugbot向けの設定を済ませたことにはなりません。
Bugbot用には.cursor/BUGBOT.mdを使います。ルートのファイルは常に含まれ、変更ファイルから上位へたどる場所の追加ファイルも対象になります。Agent ReviewもBUGBOT.mdを読むと公式に記載されています。
架空の構成が次のような場合を考えます。
.cursor/BUGBOT.md：プロジェクト全体で確認する契約。backend/.cursor/BUGBOT.md：バックエンド変更で確認する条件。frontend/.cursor/BUGBOT.md：フロントエンド変更で確認する条件。
backend/api.tsの変更に対して、フロントエンド専用の指示まで当然に入るとは考えません。ルールには、対象と、問題とする条件を具体的に書きます。
認可対象の利用者IDを変更した場合、認証済み利用者と要求先リソースの所有者の対応を確認してください。不一致があると判断したら、該当箇所、到達する入力、影響を示してください。コードから確定できない条件は疑問として分けてください。
これはルール文の例です。検出を保証するものではありません。実行時に採用されたルールを調べるには、公式のbugbot run verbose=trueなどの方法で、その実行に含まれたルールと省略・切詰めを確認できます。コメント投稿はレビューを開始する操作なので、確認だけのメモと区別します。
まずは使ってみる
記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。
Cursor
PRのステータスと指摘を別に読む
BugbotのGitHubチェック名はCursor Bugbotです。公式の状態説明では、successは新しい問題も過去の未解決コメントもない状態、neutralは問題の検出、後続コミットによる取消、内部エラーを含みます。failureは未解決指摘で失敗させる設定に対応します。
必須チェックに指定しただけでは、指摘を理由にマージを止めるとは限りません。 指摘時の既定がneutralであるためです。未解決指摘で失敗させる動作が組織で利用できる場合は、その設定と対象PRの結果を確認します。設定変更をする前に、チームの取り込み方針と対応させてください。
表は横にスクロールできます
| 架空の記録 | その記録から言えること | 次の確認 |
|---|---|---|
| neutral、指摘コメントあり | 問題候補が提示された | 対象コード、入力条件、影響を確認 |
| neutral、後続コミットで取消 | その実行は取り消された | 最新コミットに対応した実行を探す |
| success、対象コミットは修正前 | 修正前の版でその状態だった | 追加差分のレビューとテストを確認 |
表示だけで原因を決めず、実行の詳細と対象コミットを見ます。指摘がない状態でも、外部サービスの障害や本番設定まで検証された証拠にはなりません。
指摘を修正へつなげる
一つの指摘ごとに、現在のファイルと行、呼出元、前提となる入力、既存仕様を確認します。再現できるなら小さなテストへ落とします。架空例として「空文字を拒否する修正」なら、空文字が保存されないことと、通常の名前が保存できることを別々に確認します。
表は横にスクロールできます
| 分類 | 確認する内容 | 扱い |
|---|---|---|
| バグ候補 | 到達する入力、期待と実際の差 | 修正と回帰確認 |
| 仕様上の疑問 | 現行の契約、未確定の要件 | 仕様を確認してから判断 |
| 書き方の提案 | 可読性、プロジェクトの慣習 | 必要性に応じて採用 |
| 誤検出 | 指摘の前提が成立しない根拠 | 理由を残して扱う |
レビューの指摘を直すついでに、別の仕様まで追加しないようにします。修正後は、対象差分と検証結果を対応させ直します。以前のレビューや緑色のテスト表示を、追加変更にも自動で引き継ぎません。
最後に、要求、最新差分、採用した指摘、実行した検証、未確認条件を一組にします。AIの評価語だけで優先度を決めず、利用者への影響と再現条件を根拠に取り込みを判断してください。
参考資料
資料確認日：2026年10月21日。機能、設定場所、利用条件は変わります。利用するCursorの版と組織の設定を確認してください。