Cursor、RolloutsでPRの変更をデプロイ後まで監視

PRの変更をデプロイ後まで追う

PRをマージしても、その変更が各環境で意図どおり動いたかは別途確認が必要です。エラー率や遅延が悪化したとき、複数の変更から原因になったPRを人が探す運用では発見と切り分けに時間がかかります。

2026年9月23日にCursorが発表したRolloutsは、PRを起点に変更をデプロイ後まで追います。各環境の状態を「正常」「回帰を検出」「判定不能」に分け、結果をPRへ戻します。

監視計画をPRコメントとして作成する

PRが開かれると、Rolloutsは差分と影響するシステムを読み、監視計画をPRコメントとして作ります。計画には、見つけたリスク、変更で起きるはずの効果、確認する信号、観測不足で判断しにくい箇所が含まれます。人が計画を編集した場合は、その内容を使って監視します。

デプロイイベントを受けると、Rolloutsはログ、メトリクス、トレースを使って計画を実行します。ステージングと本番のように環境を分けて追うため、ステージングでは正常でも本番では回帰として報告することがあります。

回帰を検出すると疑わしい変更を示して作者へ通知します。設定によって差し戻しPRを開いたり、クラウドエージェントへ修正を渡したりできます。ただし、2026年9月23日時点ではRollouts自身が自動でマージやロールバックを行うわけではありません。

Security Reviewは9月に初めて登場した機能ではない

同じ9月23日の更新ではSecurity ReviewもRolloutsと並べて紹介されていますが、Security Review自体は2026年4月30日にTeams / Enterprise向けbetaとしてすでに公表されています。当時は、PRを確認するSecurity Reviewerと、コードベースを定期走査するVulnerability Scannerが案内されていました。

9月23日の説明では、Security Reviewは各PRをコードベースの文脈と合わせて読み、悪用可能な不具合を一つのレビューコメントで報告する役割として示されています。スタイルや一般的なコード品質はBugbotの担当です。

このため今回の中心的な新要素は、既存のマージ前確認に対して、変更をデプロイ後まで追うRolloutsが加わったことです。この記事ではSecurity Reviewを新規追加機能として扱わず、Rolloutsとの役割分担を説明するための既存機能として整理します。

利用には接続設定が必要

Rolloutsはダッシュボードで有効にし、ソース管理、デプロイシステム、テレメトリ提供元を接続すると次のPRから監視を始めます。公式説明ではソース管理としてOriginまたはGitHub、信号の取得先としてDatadogなどが挙げられています。

RolloutsとSecurity Reviewはいずれも、2026年9月23日の公式案内ではTeams / Enterprise向けです。

確認範囲

この記事は、2026年9月23日のCursor公式更新にあるRolloutsの監視方法と自動化範囲を中心に整理し、Security Reviewについては2026年4月30日の公式更新も照合して初出時期を区別しています。実際のリポジトリで回帰検出精度やSecurity Reviewの検出精度を独自に測定したものではありません。