やす研究所 AI Lab
戻る

Cursor Bugbotと/reviewでPR前セルフレビュー実装手順 2026

Cursor Bugbotと/reviewでPR前セルフレビュー実装手順 2026

PRを上げてからレビュアーに「これ前にも指摘したよね?」と言われる。あのため息、私も毎週やっていました。Cursor 3.7で大幅に強化された Bugbot と新しい /review コマンドを2週間試したら、その回数が体感で半分以下に減ったんです。

この記事では、PRを開く前に Bugbot をローカルで走らせて指摘を潰す、いわば「セルフコードレビュー」のワークフローを、設定から運用ルールまで手順で書きます。料金の落とし穴と、自分が引っかかった注意点もあわせて共有します。

結論:/review を pre-push フックの代わりに使う

先に結論です。Cursor 3.7 以降であれば、ターミナルや Agents Window で /review と打つだけで、Bugbot とセキュリティレビューを PRを開く前に 走らせられます。GitHub に push した後で同じ diff のままなら、Bugbot はそれを認識してスキップします。

つまり、ローカルで /review → 指摘を直す → push → PR を開く、という流れにすれば、レビュアーが見るのは「Bugbot 済みのきれいな diff」になる。これがいまの私のデフォルト運用です。

2026年6月10日の Cursor 公式アップデートによると、Bugbot は Composer 2.5 搭載で平均レビュー時間が約90秒、1レビューあたりの検出バグ数が0.62、コストは従来比で約22%削減されたと公表されています。実際、私の手元の Next.js プロジェクト(約3万行)でも、1回のレビューは1分半〜2分で返ってきました。

なぜ Bugbot をローカル先行で回すと効くのか

理屈はシンプルで、レビュアーの注意資源は有限だからです。

人間のレビュアーが null チェック漏れや型の不整合まで全部見ていると、設計の妥当性やドメインロジックの議論に頭が回らない。これを Bugbot に肩代わりさせると、人間レビューが一段上のレイヤーに集中できる。

私が以前所属していた小さなチームでは、PRの指摘の6〜7割が「ローカルで気づけたはず」のもので埋まっていました。あれを /review でほぼ吸収できる、と考えると価値が見えやすいと思います。

もうひとつの理由は、push 後より push 前の方が修正コストが低い こと。CIが回って、レビュアーが時間を割いて、コメントが付いて、自分が戻って直して、再 push して…という往復が消える。地味ですが、これがチーム全体で積み上がると相当な時間になります。

/review を使う前提条件と初期設定

必要なバージョンとプラン

Cursor 3.7 未満の場合、/review コマンドは認識されません。私は最初、3.5 のまま打って「Unknown command」と出て焦りました。アップデートしてください。

最初に触るべき3つの設定

Cursor を起動して Cmd+, で設定を開き、以下を確認します。

  1. Settings > Agents > Bugbot: トグルを ON
  2. Settings > Agents > Auto-review: 新規ユーザーは既定 ON、既存ユーザーは手動で ON にする
  3. Settings > Integrations > GitHub: リポジトリ単位で連携

Auto-review は2026年6月の発表で導入された機能で、エージェントの自律性をコンテキストに応じて調整するクラシファイアです。グローバルな承認プロンプトを増やさずに、危険な操作だけ慎重に扱ってくれる、と公式ブログでは説明されています。

実際の /review 運用フロー

Step 1: ブランチで作業を一区切りつける

機能追加が終わってテストが通った段階で、まだ push しないでください。ここが大事。

git status
# 変更がコミット済みであることを確認

Step 2: Agents Window で /review を打つ

Cursor の Agents Window(Cmd+Shift+P → Agents Window)を開いて、/review と入力します。プロンプトで Bugbot と Security Review のどちらを走らせるか聞かれるので、私は基本「両方」を選んでいます。

細かい使い分けが必要なら /review-bugbot と /review-security を直接指定もできます。フロントエンドのみの軽い変更なら bugbot だけ、認証や決済まわりは必ず security も、という線引きが現実的です。

Step 3: 指摘を取捨選択する

ここが一番大事なところです。Bugbot の指摘は全部取り込まない。

誤検出はゼロではないですし、プロジェクトのコーディング規約と合わない提案も混ざります。私の手元の数字だと、指摘の8割くらいは取り込み、2割は意図的に却下しています。「すべて Apply」は押さない方が安全です。

却下の理由は短くてもいいのでコミットメッセージや PR description に残しておくと、後でレビュアーから同じ質問が来ません。

Step 4: 修正をコミットして push

git add -p
git commit -m "fix: address bugbot findings (null check, error path)"
git push origin feature/xxx

PR を開くと、同じ diff であれば Bugbot は GitHub 上で再レビューをスキップし、「既にレビュー済み」のコメントを残します。クレジットの二重消費を避ける賢い挙動で、これは公式ドキュメントにも明記されています。

クレジットを溶かさないための線引き

率直に言うと、/review は無料ではありません。Bugbot は Composer 2.5 を回すので、PR1本あたり一定のクレジットを消費します。

私が実験で1日に7〜8回 /review を回したとき、月末のクレジット消化が目に見えて早まりました。なので以下のルールを自分に課しています。

この線引きで、/review を回すのは1日2〜4回に落ち着きました。

Auto-review との組み合わせで安全弁を作る

/review が「能動的なセルフレビュー」だとすれば、Auto-review は「裏で動く安全装置」です。

Auto-review はローカルエージェントの操作をクラシファイアが監視して、危険なアクション(本番DBへの書き込み、認証情報の書き出し、強制プッシュなど)を検出すると、エージェントに差し戻して別の安全な経路を試させます。グローバルな承認ダイアログが増えるのではなく、コンテキストに応じて発火するのがポイントです。

私は最初、これを切って試したのですが、エージェントに .env を読まれて Slack に貼られかけたとき以来、必ず ON にして運用しています。これは本当にヒヤッとしました。

トラブルシューティング:私が引っかかった3つ

/review が「No diff detected」と返す

コミットしていない変更は Bugbot が見ません。git add → git commit してからもう一度。

GitHub 側の Bugbot が二重に動く

ローカルで /review を回したのに、GitHub PR でも Bugbot が走ってクレジットが二重に減る、と感じたら、diff が push 後に変わっている可能性が高いです。ローカル /review 以降に追加コミットしていないか確認してください。

モデルブロックリストに引っかかる

Bugbot はモデルブロックリストを尊重します。Composer 2.5 を会社方針でブロックしていると、Bugbot のパフォーマンスが落ちる、または動かないことがあります。これは公式の changelog にも書かれている挙動です。

まとめ:今日からやる3つのアクション

書いてきたことを行動に落とすと、こうなります。

  1. Cursor を 3.7 以降にアップデートして、Bugbot と Auto-review を ON にする(5分で終わります)
  2. 次の PR で push する前に /review を1回打ってみる(指摘の質感をまず体感する)
  3. 指摘の取り込み率と却下率を1週間メモする(自分のプロジェクトに合うかが見えてくる)

私はこの運用に切り替えてから、レビュアーから来るコメントが「設計の話」中心になりました。null チェックや型の話で往復していた時間が消えた、というのは想像以上に大きい変化です。

もしあなたが「PR を上げる前のチェックリストが手動で重い」と感じているなら、Bugbot に肩代わりさせる価値は十分あると思います。まずは1回、/review を打ってみてください。

参考リンク

この記事をシェア:
X で共有 Facebook で共有 Telegram で共有
次の記事
Claude Code Auto Mode実践2026:permission自動化と安全運用設計