Cursor BugbotがPRのやりとりから44,000のルールを自動生成した
44,000。これはCursor Bugbotが自動生成したコードレビュールールの数だ。人間が書いたのではない。PRのフィードバックを読んで、Bugbot自身が学習し続けた結果がこの数字に表れている。
数字の背景
Cursorが2026年4月8日に発表したBugbotの学習機能「Bugbot Learned Rules」は、ベータ開始時点で11万以上のリポジトリが有効化し、44,000を超えるルールが自動生成されている状態で正式ローンチを迎えた。
解決率の変化が機能の中身を物語っている。2025年7月のベータ版終了時点で52%だったものが、2026年4月時点で78.13%まで上昇した。同社は「最も近い競合製品より15ポイント上回っている」と説明している。月間200万件以上のPRをさばく規模での数字だ。
ルールはどこから来るのか
従来のコードレビューツールは、事前に定義したルールセットを適用する仕組みが中心だった。「このパターンはNG」「この関数は非推奨」という静的なリストに照らして判定する。
Bugbotのアプローチは違う。Bugbotが出したコメントに対して開発者がどう反応したかを見ている。
具体的には、コメントへのダウンボート（「この指摘は的外れだ」というシグナル）、開発者からの返信（「ここはこういう理由で問題ない」という説明）、そして人間レビュアーが別途指摘したコメント（「Bugbotが見落とした問題」）を継続的に収集する。これらのシグナルが一定量蓄積されると候補ルールに変換され、さらに評価が進むとアクティブなルールとして昇格し、以降のレビューに影響を与えるようになる。
役に立たなくなったルールは自動的に無効化される仕組みも持つ。
チームの慣習をAIに覚えさせる
従来のコードレビューで難しかったのは、「このチームならではのコーディング判断」をツールに伝えることだった。ドキュメント化されていない慣習、ビジネスコンテキストに依存するロジック、チームの優先事項——これらはルールセットに書き起こすのが難しく、結局人間のレビュアーの頭の中にだけある状態が続いていた。
Bugbotの学習機能は、このギャップを埋めようとしている。PRのやりとりから暗黙知を抽出し、ルールとして形式化する試みだ。
また、Teams・EnterpriseプランではBugbot DashboardからMCPサーバーへの接続設定が可能になり、コードレビュー時に追加のコンテキスト情報を参照できるようになった。
「育てる」というアプローチの課題
学習型であることは長所でもあり、注意点でもある。Bugbotが不適切なフィードバックシグナルを学習した場合、ルールの品質が下がる可能性はゼロではない。またチーム内でBugbotへのリアクションの仕方が統一されていない場合、生成されるルールが一貫しなくなるリスクもある。
44,000というルール数は、学習が確かに機能している証拠だ。ただし「多く生成された」と「質が高い」は別の話で、実際の運用の中でルールを定期的に見直す運用設計は引き続き必要になる。
Cursorはここ数週間で3.1 Canvas（インタラクティブUI生成）やMCPサポートの強化など複数のアップデートを続けている。コードエディタという位置付けから、開発ワークフロー全体のプラットフォームへと変わろうとしている動きが見えてくる。
関連記事
- Cursor 3登場——ペアプログラミングから「AIチームへの指示」へ、開発スタイルの転換点
- Cursor 3.1 Canvas登場、エージェントの出力がテキストからインタラクティブUIへ
- ターミナルを離れずにAIが計画・実行・テストを完結する — GitHub Copilot CLI がGA