はじめに
2026年9月23日、Cursor は Teams / Enterprise プラン向けに2つの新しいボットを公開しました。
- Rollouts: デプロイ後の変更を環境ごとに監視し、リグレッションを検出するボット
- Security Review: PRごとに悪用可能な脆弱性を検出し、レビューコメントで報告するボット
これまでの AI コーディングアシスタントは「コードを書く」「レビューする」までが主戦場でした。しかし今回の発表は、**「デプロイした後、そのコードは本当に安全に動いているか」**という、出荷の最終段階までカバーする点が新しく、かつ重要です。コードレビューを通過したPRが本番で問題を起こす、という多くのチームが経験している課題に対して、Cursor がエコシステム全体で手を打ちにいった形です。
📌 影響を受ける人
- Cursor を Teams / Enterprise プランで利用しているチーム
- PRベースの開発フローで、デプロイ後の監視やセキュリティレビューを手動・別ツールで行っているチーム
- Bugbot をすでに使っていて、脆弱性検出まで自動化したいチーム
変更の全体像
今回の発表で、Cursor のPRワークフローは「コードを書く→レビュー→マージ→デプロイ」で終わらず、「デプロイ後の健全性確認」までがボットの守備範囲に入りました。
これまで空白だった「デプロイ後」の領域に Rollouts が入り、「PRの中身の安全性」を Security Review が担当することで、既存の Bugbot（スタイル・品質）と合わせて役割分担が明確になりました。
変更内容
1. Rollouts（デプロイ後の変更ヘルス監視）
Firetiger の Change Monitors を Cursor の Bot Development Kit で作り直したボットです。ダッシュボードで有効化し、ソース管理・デプロイシステム・テレメトリプロバイダを接続すると、次に開かれるPRから監視が始まります。
動作の流れ
| フェーズ | 内容 |
|---|---|
| 監視計画の作成 | PRが開かれると差分と影響システムを読み取り、リスク・意図した効果・確認するシグナル・計測不足の4点をPRコメントに投稿 |
| 計画の編集 | PR上でユーザーが計画を編集すると、Rollouts は編集後の版を使用 |
| デプロイ追跡 | 該当コミットのデプロイイベントで起動し、ログ・メトリクス・トレースを計画に沿って確認 |
| 判定 | 環境ごとに個別追跡し、「正常と確認」「リグレッション検出」「判定不能」のいずれかをPRに報告 |
| リグレッション時 | 原因と疑われる変更を特定し作成者に通知。設定次第で revert PR の作成やクラウドエージェントへの修正依頼が可能 |
⚠️ Breaking Change ではありませんが注意点
ステージングでは「正常と確認」でも、本番環境では別判定（リグレッション検出）が出ることがあります。環境ごとに独立して追跡される仕様のため、「ステージング通過=本番も安全」という前提が崩れる可能性があります。
💡 Tips
現時点で Rollouts は自動でのマージ・ロールバックは行いません。あくまで「検知と通知」までがスコープで、最終判断は人間に委ねられています。
連携先
- ソース管理: Cursor Origin または GitHub
- デプロイイベント: 継続的デリバリーシステム
- シグナル: Datadog などのテレメトリプロバイダ
- （近日対応）フィーチャーフラグとの連携
2. Security Review（PRごとの脆弱性検出）
すべてのPRをコードベース全体の文脈で読み、悪用可能なバグを1件のレビューコメントにまとめて報告するボットです。ダッシュボードでリポジトリを選んで有効化するだけで使えます。ドラフトPRはスキップされます。
検出対象
- インジェクション（SQL、コマンド、テンプレート）
- 認証・認可のバイパス（リファクタリングでチェックが実行されなくなったケースを含む）
- ソースにコミットされたシークレット・認証情報
- SSRF と未検証のリダイレクト
- 安全でないデシリアライズ
- 既知の脆弱性を持ち込む依存関係の変更
各指摘には深刻度・攻撃経路・修正案が付き、理由を添えて却下すると同じ指摘は再度出さない仕組みになっています。さらに「外部呼び出しは特定のクライアントを必ず経由する」といったコードベース固有のルールを追加し、全PRで強制することもできます。
Rollouts / Security Review 比較表
| 項目 | Rollouts | Security Review |
|---|---|---|
| 監視タイミング | デプロイ後 | PRオープン時 |
| 目的 | 環境別の変更ヘルス確認 | 悪用可能な脆弱性の検出 |
| 判定 | healthy / regression / inconclusive | 深刻度付きの指摘リスト |
| 自動アクション | revert PR作成・エージェント依頼（設定次第） | なし（レビューコメントのみ） |
| 対象外 | - | ドラフトPR |
| 提供プラン | Teams / Enterprise | Teams / Enterprise |
3. お試し利用クレジット（10日間限定）
本日から10日間、Rollouts を実際の変更で試せる利用クレジットが付与されます。目安は Teams が約50変更分、Enterprise が約500変更分です。「変更単位」でクレジットが計算されている点から、Rollouts が変更数に応じた従量課金である可能性がうかがえます。
影響と対応
- Teams / Enterprise ユーザー: ダッシュボードの automations タブから両ボットを有効化できます。特に Rollouts は10日間の無料クレジットがあるうちに試すのがお得です。
- Datadog などのテレメトリを既に導入しているチーム: 接続作業だけで監視計画の自動生成が始まるため、導入コストが低めです。
- 手動でのポストデプロイ監視やセキュリティレビューに工数を割いているチーム: 置き換え候補として評価する価値があります。ただし自動マージ・自動ロールバックはしないため、既存の運用フローの「判断」部分は残ります。
- フィーチャーフラグ運用チーム: 現時点では未対応のため、連携開始のアナウンスを待つ必要があります。
コード例
Security Review が指摘するような、リファクタリングで認可チェックが抜け落ちるケースの例です。
Before（認可バイパスが混入した例）
# リファクタリング前: 認可チェックあり
def get_invoice(request, invoice_id):
invoice = Invoice.objects.get(id=invoice_id)
if invoice.owner_id != request.user.id:
raise PermissionDenied
return invoice
# リファクタリング後: ヘルパー関数化の際にチェックが抜け落ちた
def get_invoice(request, invoice_id):
return _fetch_invoice(invoice_id) # 認可チェックが消えている
def _fetch_invoice(invoice_id):
return Invoice.objects.get(id=invoice_id)
このような変更は通常のコードレビューでは見落とされがちですが、Security Review は「認証・認可のバイパス（リファクタリングでチェックが実行されなくなったケース）」を明示的に検出対象としているため、PR上で指摘が付きます。
After（Security Review の指摘を反映）
def get_invoice(request, invoice_id):
invoice = _fetch_invoice(invoice_id)
if invoice.owner_id != request.user.id:
raise PermissionDenied
return invoice
def _fetch_invoice(invoice_id):
return Invoice.objects.get(id=invoice_id)
まとめ
- Cursor は Rollouts（デプロイ後の変更ヘルス監視）と Security Review（PRごとの脆弱性検出）を Teams / Enterprise プランで提供開始しました。
- Rollouts は環境ごとに独立して監視し、「正常と確認」「リグレッション検出」「判定不能」を判定。リグレッション時は revert PR 作成などの支援はしますが、自動マージ・ロールバックはしません。
- Security Review はインジェクション・認可バイパス・シークレット漏洩など悪用可能な脆弱性を検出し、Bugbot（スタイル・品質担当)と役割分担しています。
- Rollouts には10日間の試用クレジット（Teams: 約50変更分、Enterprise: 約500変更分）が付与されており、変更数に応じた従量課金の可能性が示唆されています。
- フィーチャーフラグとの連携は近日対応予定であり、今後の拡張にも注目です。
すでに Cursor を Teams / Enterprise で使っているチームは、まず automations タブから両ボットを有効化し、10日間のクレジットのうちに Rollouts の挙動を確認しておくことをおすすめします。