Cursorが「Rollouts」と「Security Review」を追加──デプロイ監視とPRの脆弱性レビューを担う新ボット2つ

2026年9月25日未明（日本時間）時点、Cursor（開発元Anysphere）の公式changelogに9月23日付で掲載された記事によると、Cursorは「last mile of shipping code（コードを出荷する最後の工程）」向けに2つの新しいボットを追加した。デプロイ後の変更を監視する「Rollouts」と、プルリクエスト（PR）ごとに悪用可能な脆弱性を報告する「Security Review」だ。RolloutsはPRの変更がデプロイされる様子を環境ごとに追い、verified healthy・regression detected・inconclusiveのいずれかをPRに報告する。Cursorはこれを「Firetiger Change Monitors」のCursor版と説明している。Security ReviewはSQL・コマンド・テンプレートインジェクション、認証・認可バイパス、ソースにコミットされたシークレット、SSRFなどをPR1件につき1コメントで報告する。スタイルと品質のレビューは引き続きBugbotが担う、とchangelogは書いている。

3行まとめ

1. Cursorは2026年9月23日、デプロイ後の健全性を追う「Rollouts」と、PRごとに脆弱性を1コメントで報告する「Security Review」を公式changelogで発表した。
2. Rolloutsは環境ごとに verified healthy / regression detected / inconclusive のいずれかをPRに報告する。Cursor自身が「Firetiger Change MonitorsのCursor版」と説明しており、公式によれば発表時点では自らマージもロールバックもしない。
3. Security ReviewはSQL/コマンド/テンプレートインジェクション、認証・認可バイパス、ソースにコミットされたシークレット、SSRF、安全でないデシリアライズ、既知脆弱性を持つ依存関係の変更を検出対象とし、スタイル・品質レビューは引き続きBugbotが担当する。両ボットはTeams/Enterpriseで即日利用可能で、発表から10日間はRolloutsを試すための使用クレジットが付く。

2つのボットをchangelogの記述で並べる

以下はすべて公式changelog（2026年9月23日付）の記述をもとにした。

Rollouts──PRの変更がデプロイ先でどう動いたかを環境ごとに追う

公式changelogは、Rolloutsの位置づけをこう説明している。

"Rollouts attaches a monitor to every pull request and watches the change as it deploys, reporting change health per environment: verified healthy, regression detected, or inconclusive. It's the Cursor version of Firetiger Change Monitors, rebuilt with the Bot Development Kit." （Rolloutsはすべてのプルリクエストに監視を取り付け、変更がデプロイされる様子を追い、環境ごとの変更の健全性を verified healthy・regression detected・inconclusive のいずれかで報告する。Bot Development Kitで作り直された、Cursor版のFiretiger Change Monitorsだ）

Firetigerは、Cursorが2026年8月13日の公式ブログ「Firetiger joins Cursor」でチームの合流を発表した会社だ。同ブログはFiretigerを「本番に届いたソフトウェアを扱うエージェントを作っている」と紹介し、今後の取り組みとして次のように予告していた。

"That work also includes Cursor Origin, our Git forge built for the agentic era, and soon Change Monitors, which watch deployed changes and flag problems as they appear." （その取り組みには、エージェント時代向けに作ったGitフォージのCursor Originと、近く出す、デプロイされた変更を監視して問題が現れた時点でフラグを立てるChange Monitorsも含まれる）

9月23日のchangelogは、Rolloutsを「Firetiger Change Monitors」のCursor版と説明している。導入は「dashboardから有効化し、ソース管理・デプロイシステム・テレメトリプロバイダを接続する。次のPRから監視が始まる」という説明だ。

動作は3段階に分けて書かれている。

PRが開いたとき: Rolloutsは差分と影響するシステムを読み、「監視計画」をPRコメントとして書き出す。

"The plan lists the risks it identified, the effect the change is meant to have, the signals it will check, and any gaps in instrumentation that would make the change hard to verify. Edit the plan in the PR and Rollouts uses your version." （計画には、特定したリスク・変更が意図する効果・確認するシグナル・検証を難しくする計測の欠落が列挙される。PR内で計画を編集すれば、Rolloutsはその編集後の版を使う）

デプロイされたとき: 該当コミットのデプロイイベントで起動し、ログ・メトリクス・トレースに対して計画を実行する。

"It tracks each environment separately, so a change can be verified in staging and still flagged in production. Rollouts checks the change's intended effect alongside error and latency signals, and reports back on the PR when it reaches a verdict." （環境ごとに個別に追跡するため、ある変更がステージングでは検証済みでも本番ではフラグが立つ、ということが起こり得る。Rolloutsは変更の意図した効果をエラー・レイテンシのシグナルと合わせて確認し、判定に達したらPRに報告する）

回帰を検知したとき: 疑わしい変更を名指しして作者に通知する。

"Depending on configuration, it can also open a revert PR for review or hand the finding to a cloud agent for a fix. Rollouts does not merge or roll back on its own today." （設定によっては、レビュー用のrevert PRを起票するか、修正のためにクラウドエージェントへ引き継ぐこともできる。Rolloutsは現時点では、自らマージやロールバックを行わない）

連携先については次のように書かれている。

"Rollouts connects to Origin or GitHub for source control, to your continuous delivery system for deploy events, and to Datadog and other telemetry providers for signals. Feature flag integration is coming soon." （Rolloutsはソース管理にOriginまたはGitHub、デプロイイベントに継続的デリバリーシステム、シグナルにDatadogなどのテレメトリプロバイダと接続する。Feature flag連携は近日対応予定）

「Origin」は、Cursorが2026年8月17日付のchangelogで全有料プラン向けに早期ベータの提供開始を告げたコードホスティング機能で、本サイトの既報で扱った。上で引いた8月13日のFiretiger合流のブログも、OriginとChange Monitorsを同じ一文の中で挙げていた。

Security Review──PRごとに1コメントで脆弱性を報告

Security Reviewについて、公式changelogはこう説明する。

"Security Review is available today. It reads every pull request in the context of the codebase and posts one review comment reporting exploitable bugs. Style and quality stay with Bugbot." （Security Reviewは今日から利用できる。コードベースの文脈の中ですべてのプルリクエストを読み、悪用可能なバグを報告するレビューコメントを1件投稿する。スタイルと品質のレビューは引き続きBugbotが担う）

有効化は「dashboardでレビュー対象のリポジトリを選ぶ」形で、「Draft PRs are skipped（ドラフトPRはスキップされる）」と明記されている。

検出範囲は次の一文にまとまっている。

"Security Review looks for injection across SQL, command, and template surfaces, along with authentication and authorization bypasses, including checks that a refactor stopped running. It also flags secrets and credentials committed to source, SSRF and unvalidated redirects, unsafe deserialization, and dependency changes that introduce known vulnerabilities. It traces where user input enters and what it passes through." （Security ReviewはSQL・コマンド・テンプレートの各面にまたがるインジェクションと、認証・認可バイパス──リファクタリングによって動かなくなったチェックの検出も含む──を探す。また、ソースにコミットされたシークレットや認証情報、SSRFと未検証のリダイレクト、安全でないデシリアライズ、既知の脆弱性を持ち込む依存関係の変更にもフラグを立てる。ユーザー入力がどこから入り、どこを通過するかを追跡する）

各指摘の扱いについては、次のように書かれている。

"Each finding carries a severity, the attack path, and a proposed fix. Dismiss one with a reason and Security Review won't raise it again on that PR." （各指摘には重大度・攻撃経路・修正案が添えられる。理由を付けて却下すれば、Security Reviewはそのpull requestで同じ指摘を再度出さない）

自社ルールの追加も可能だとしている。

"Add rules for your codebase, such as which client external calls must go through or which tables are never queried from a request handler, and Security Review enforces them on every PR." （「外部呼び出しはどのクライアントを通さなければならないか」「どのテーブルはリクエストハンドラから決して問い合わせないか」といった、自社コードベース向けのルールを追加でき、Security Reviewはそれをすべてのpull requestで適用する）

changelogの記述どおりに読むと、同じPRに対して、悪用可能な脆弱性の指摘はSecurity Review、スタイルと品質の指摘はBugbot、という分担になる。changelogは、Bugbotがこれまで脆弱性も扱っていたかどうか、今回その範囲が変わるのかどうかには触れていない。

誰が、いつから使えるか

利用条件は次の一文にまとめられている。

"Rollouts and Security Reviewer are available today on Teams and Enterprise plans. Enable either bot from the automations tab." （RolloutsとSecurity ReviewerはTeams・Enterpriseプランで今日から利用できる。どちらのボットも automations タブから有効化する）

原文はここで「Security Review」ではなく「Security Reviewer」という表記を使っており、見出し（h1・h2）や機能説明部分の「Security Review」と一致しない。ページのURL（rollouts-and-security-reviewer）とOG画像の文言（「Rollouts and Security Reviewer updates」）も「Reviewer」のほうだ。同じchangelog記事の中で名称表記が揺れている、という点はそのまま書いておく。この記事では見出しと本文の大半に合わせて「Security Review」と書く。

クレジットについては次のように書かれている。

"For the next 10 days, we're including usage credits so teams can try Rollouts on real changes. Teams and Enterprise customers receive credits for roughly 50 and 500 changes, respectively." （向こう10日間、実際の変更でRolloutsを試せるよう使用クレジットを含める。Teams・Enterpriseの顧客は、それぞれおよそ50件・500件分の変更に相当するクレジットを受け取る）

この一文が名指ししているのは「Rolloutsを試すためのクレジット」だ。changelogの中でクレジットに触れているのはこの一文だけで、Security Review向けのクレジットや、両ボットの通常の料金については書かれていない。

確認できなかった範囲

この記事は、Cursor公式changelogと公式ブログのページが返すサーバー側レンダリング済みのHTMLを取得し、上に引いた英語の原文はすべて一字一句突き合わせて確認した。一方で、次の点はこの記事の執筆時点で確認できていない。

• 実際のCursorダッシュボードの automations タブの画面は、ログイン権限がなく確認していない。changelogがリンクしている https://cursor.com/automations をcurlで開くと、ログイン画面（authenticator.cursor.sh）へ転送され、そこで403が返る。この記事では本文中のリンクとして貼っていない。
• RolloutsとSecurity Reviewが実際のPRでどう表示されるかは、自分のリポジトリで動かして確かめてはいない。公式changelogには、Rolloutsの節に動画が1本、Security Reviewの節にPRコメントの例を写したスクリーンショットが1枚載っている。
• 「Teams約50件・Enterprise約500件」の「件」が何を指すか（PR単位か、監視対象の変更1件ごとか）は、原文の "changes" という語以上の定義がchangelog本文に無く、それ以上は特定できない。

出典はいずれも2026年9月25日（日本時間）に取得・確認した。続報があれば追記する。