2026年9月23日、Cursor が Rollouts と Security Review という 2 つのボットを公開しました。どちらも Teams（1 ユーザーあたり月 $40・税別）と Enterprise の各プランで当日から使え、有効化は automations タブからです。Rollouts は PR ごとに監視計画を書いてデプロイ後の変化を環境別に「verified healthy／regression detected／inconclusive」の 3 値で判定し、Security Review は PR ごとに 1 件のレビューコメントで「悪用できるバグ」だけを報告します。公開から 10 日間は試用クレジットが付き、その量は公式表現で Teams が約 50 変更ぶん、Enterprise が約 500 変更ぶんです。
この記事は、Cursor の changelog と公式ドキュメントに書かれている範囲だけで、2 つのボットが何を見るのか、既存の Bugbot とどう住み分けるのか、どこから有効化するのかを整理します。筆者側で実際に動かした結果ではないため、動作の記述はすべて公式の説明として書いています。
結論｜PR 前の「悪用できるバグ」と、デプロイ後の「壊れたかどうか」を別のボットに分けた
Cursor はこの 2 つを「コードを出荷する最後の 1 マイル（the last mile of shipping code）」向けのボットと説明しています。AI がコードを書く量が増えるほど、レビュー待ちとデプロイ後の確認が詰まる。そこを 2 か所に分けて自動化した、という構図です。
| ボット | 見る場所 | 出力 | 人が判断する部分 |
|---|---|---|---|
| Security Review | マージ前の PR（コードベース全体を文脈として読む） | 1 件のレビューコメント。重大度・攻撃経路・修正案つき | 指摘を直すか、理由を添えて却下するか |
| Rollouts | デプロイ後の各環境（ログ・メトリクス・トレース） | PR コメントに監視計画 → 判定（健全／回帰検知／判定不能） | 回帰と言われた変更を戻すか、修正を出すか |
重要なのは、どちらも最後の操作を自分ではしないことです。changelog は Rollouts について「今日時点では自分で merge も rollback もしない（Rollouts does not merge or roll back on its own today）」と明記しています。Security Review も指摘コメントを置くだけで、マージを止める仕組みは PR Routing & Approval 側の設定に委ねられています。
なお、Rollouts は 2026年9月24日時点で Cursor の docs に専用ページがありません。docs のサイドバーに並ぶ Cursor 管理のエージェントは Bugbot／Security Agents／PR Routing & Approval の 3 つで、Rollouts の仕様の出どころは changelog だけです。この記事でも Rollouts の記述は changelog の原文に限定しています。
Rollouts とは｜PR に監視計画を書き、デプロイ後の健全性を環境別に 3 値で返す
Rollouts は、すべての PR に監視役を貼り付けて、その変更がデプロイされていく様子を追いかけ、環境ごとに変更の健全性を報告します。動きは 4 段階です。
1. 監視計画を PR コメントとして書く
PR が開かれると、Rollouts は差分とその変更が触るシステムを読み、監視計画（monitoring plan）を PR のコメントとして書きます。計画に載るのは次の 4 つです。
- 見つけたリスク
- その変更が起こすはずの効果（the effect the change is meant to have）
- チェックするシグナル
- 計測が入っていないせいで検証しにくくなる箇所（gaps in instrumentation）
この 4 つ目が地味に効きます。「この変更は本番で検証できない」と先に言ってくれる相手がいるかどうかで、リリース後の調査コストが変わるからです。計画は PR 上で編集でき、編集した場合は自分の版が使われます。
2. デプロイイベントで起きて、計画をログ・メトリクス・トレースに当てる
Rollouts はその変更のコミットに対するデプロイイベントで起動し、計画をログ・メトリクス・トレースに対して実行します。環境は別々に追跡されるため、ステージングでは検証済みなのに本番ではフラグが立つ、という状態がそのまま表現されます。見るのはエラーとレイテンシのシグナルだけではなく、上で書いた「起こすはずの効果」も含みます。判定に到達したら PR 上で報告します。
3. 回帰を検知したら、疑わしい変更を名指しして作者に通知する
回帰を検知すると、Rollouts は疑っている変更を名指しし、作者に通知します。設定次第で、レビュー用の revert PR を開くか、その指摘を cloud agent に渡して修正させることもできます。ただし繰り返しになりますが、自分で merge も rollback もしません。
4. 連携先は source control・CD・テレメトリの 3 系統
| 連携の種類 | つなぐ先（公式表記） |
|---|---|
| ソース管理 | Origin または GitHub |
| デプロイイベント | 継続的デリバリー（CD）のシステム |
| シグナル | Datadog その他のテレメトリプロバイダ |
| フィーチャーフラグ | coming soon（2026年9月24日時点で未提供） |
Security Review 側が GitHub／GitLab／Bitbucket の PR・MR イベントに反応するのに対し、Rollouts のソース管理は Origin と GitHub の 2 つだけが明記されています。GitLab や Bitbucket を使っているチームは、Rollouts だけ対象外になる可能性がある点に注意してください。
Rollouts の出自も公式に書かれています。changelog は「Firetiger の Change Monitors を Bot Development Kit で作り直した Cursor 版」と説明しており、Firetiger は 2026年8月13日に Cursor へ合流したチームです。Cursor のブログによれば、Firetiger は 2024年に Rustam Lalkaka 氏と Achille Roussel 氏が創業し、「ロールアウトを監視し、回帰を捕まえ、インシデントを調査し、見つけたものをコーディングエージェントへ返す」エージェントを作っていました。8月の発表時点で「近く Change Monitors を出す」と予告されており、今回はその予告どおりの製品化にあたります。
Security Review とは｜悪用できるバグだけを 1 コメントにまとめて返す
Security Review は、すべての PR をコードベースの文脈の中で読み、1 件のレビューコメントとして「悪用可能なバグ（exploitable bugs）」を報告します。スタイルと品質の指摘は従来どおり Bugbot の担当で、Security Review 側には持ってきません。指摘が何本もぶら下がって PR が読めなくなる問題への答えが「1 コメントにまとめる」という設計です。
何を見るのか（changelog に列挙されている 6 種類）
| 種類 | 公式の説明 |
|---|---|
| インジェクション | SQL・コマンド・テンプレートの各面をまたいで探す |
| 認証・認可のバイパス | リファクタリングによってチェックが動かなくなった箇所を含む |
| ソースに入った秘密情報 | コミットされた secrets と認証情報 |
| SSRF と未検証のリダイレクト | — |
| 安全でないデシリアライズ | — |
| 脆弱な依存の追加 | 既知の脆弱性を持ち込む依存関係の変更 |
加えて、ユーザー入力がどこから入り、何を通るかを追跡すると書かれています。単なるパターン照合ではなく、入力の流れを追った上で「悪用できるか」を判断する、という位置づけです。2 行目の「リファクタで動かなくなった認可チェック」は、静的解析より AI レビューのほうが拾いやすい典型例と言えます。
指摘の中身と却下のしかた
1 件ずつの指摘には重大度・攻撃経路・修正案が付きます。理由を添えて却下（dismiss）すると、その PR では同じ指摘を二度と出しません。この「理由つき却下が効く」部分は、誤検知が積み上がって無視されるようになる AI レビューの寿命を延ばすための仕掛けです。
Team rules でチーム固有の決まりを足せる
コードベース固有のルールを追加すると、Security Review が毎回の PR でそれを強制します。changelog が挙げている例は具体的です。
- 外部呼び出しがどのクライアントを経由しなければならないか
- どのテーブルはリクエストハンドラから絶対に参照してはいけないか
いずれも「一般的な脆弱性リスト」には載らない、そのチームだけの取り決めです。レビューで毎回同じことを言っている項目があるなら、ここに移す候補になります。
docs 側の Security Agents｜PR 前レビューと常時スキャンの 2 種類
changelog は「Security Review」と呼んでいますが、Cursor の docs では Security Agents という枠の中に 2 種類のエージェントが定義されています。
| 種類 | 役割 | トリガー |
|---|---|---|
| Security Reviewer | マージ前の PR を確認する | Git 由来のトリガー（PR・MR のイベント） |
| Vulnerability Scanner | 静止状態のコードベースを走査し、既存の脆弱性や長年の問題、PR レビューで漏れたものを探す | cron（定期実行） |
どちらも Automations プラットフォーム上で動き、Cloud Agents を必要とします。docs には設定上の差もはっきり書かれていて、Security Reviewer は保存前に最低 1 つのツールか MCP が必要、Vulnerability Scanner はツールなしでも保存でき、見つけたものは Flagged vulnerabilities の一覧へ入ります。一覧は Status（Active／Dismissed）・Feedback（Useful／False Positive／Unimportant）・Severity（Critical／High／Medium）などで絞り込め、各項目から「Fix in Cursor」で Cloud Agent を起動して修正に入れます。
手元で先に回したいときは、エージェントから /review-security か /review のスキルを使います。Cursor 3.7 以降、cursor.com/agents、Cursor CLI で利用できます。
# 手元のブランチ変更（コミット済み＋未コミット）を base ブランチと比べて確認する
/review-security
# セキュリティ・バグ・品質をまとめて回す
/review既定では「base ブランチとの差分すべて（コミット済みも未コミットも）」が対象で、base が既定ブランチでない場合はどのブランチと比べるかをエージェントに伝えます。未コミット分だけに絞りたいときはそう指示します。
Bugbot・Security Review・Rollouts｜3 層の位置関係を表で整理する
Cursor 管理のボットは今回の追加で役割が明確に分かれました。Automations の docs には Cursor 管理のエージェントが 3 つ載っています（Bugbot／Security Agents／PR Routing & Approval）。そこに changelog 由来の Rollouts を足すと、PR の前後がこう並びます。
| 層 | ボット | タイミング | 主な対象 | プラン |
|---|---|---|---|---|
| 品質 | Bugbot | PR 更新のたび（増分レビューが既定） | バグ・セキュリティ問題・コード品質 | Pro 以上（使用量課金） |
| 脆弱性 | Security Review（Security Agents） | PR・MR のイベント／cron | 悪用できるバグ、既存コードの脆弱性 | Teams・Enterprise |
| 出荷後 | Rollouts | デプロイイベント | 環境別の変更健全性・回帰 | Teams・Enterprise |
| 合流点 | PR Routing & Approval | PR のイベント | レビュアー割り当て・低リスク PR の承認 | GitHub・Origin のみ |
4 段目を足したのには理由があります。PR Routing & Approval の docs には Security Review Context という設定があり、有効にすると Security Agents の指摘を承認判断の材料に使います。そして「Bugbot か Security Agents が人のレビューを要する指摘を出した場合、PR Routing & Approval はその PR を承認しない」と明記されています。つまり Security Review を「マージを止める仕組み」として効かせたいなら、承認側の設定が要るわけです。Security Review を入れただけでは、指摘は出ても PR は通ります。
Bugbot 側の挙動も同じ注意が必要です。Bugbot は GitHub に Cursor Bugbot という名前のチェックを出しますが、docs は「指摘がある場合の既定の結論は neutral」「ステータスを必須にするだけでは指摘を理由にマージを止められない」と書いています。ブランチ保護で止めたいなら、未解決の指摘で失敗ステータスを出す設定（組織で利用可能な場合）を有効にする必要があります。
AI コードレビューのツール選定そのものを見直すなら、主要 5 ツールを横並びにしたAIコードレビューエージェント解説｜主要5ツール比較と、ハイブリッド運用を扱ったOpen Code Reviewとは｜AIコードレビュー導入法が起点になります。
有効化の手順｜automations タブから入れて、連携を 3 つつなぐ
changelog と docs に書かれている操作だけを並べます。
- automations タブを開く。Cursor の dashboard から automations（cursor.com/automations）へ行き、どちらのボットも同じ場所で有効化します。
- Security Review を対象リポジトリで有効にする。docs 側では Security Agents を開き、エージェントの種類（Security Reviewer か Vulnerability Scanner）を選んで設定します。Security Reviewer は保存前にツールか MCP を 1 つ以上つなぐ必要があります。
- Rollouts の連携を 3 つつなぐ。ソース管理（Origin または GitHub）、デプロイイベントを出す CD システム、シグナルを出すテレメトリ（Datadog ほか）。つないだ時点から「次の PR」で監視が始まります。
- 組み込み済みのセキュリティチェックを取捨選択する。docs によれば、どちらの Security Agent にも組み込みのチェックが入っており、個別に有効・無効を切り替えられます。
- 必要なら custom instructions と Team rules を書く。優先して見てほしい問題の種類、プロジェクト固有のセキュリティ上の前提、エージェントの振る舞い方を文章で足します。
Automations の共通仕様として押さえておくべき点が 2 つあります。1 つは請求先で、Run as が「Me」なら自分に、「Service account」ならチームの利用枠に課金されます。Security Agents は docs に「チームの利用枠に課金され、共有のチームサービスアカウントで動くため、個々のメンバーの利用量に影響しない」と明記されています。もう 1 つはフォークからの PRで、ソース管理トリガーはフォーク発の PR では動かず、「Fork pull requests not supported」で失敗します（マージ済みトリガーだけは例外）。
Automations と Cloud Agents の関係、Cloud Agent の起動・設定まわりはCursor Agentの使い方｜Cloud Agentの設定・料金・実力に手順をまとめてあります。
試用クレジットは 10 日間・Teams 約 50 変更ぶん
changelog には「今後 10 日間、チームが実際の変更で Rollouts を試せるように利用クレジットを含める」「Teams と Enterprise の顧客はそれぞれおよそ 50 変更ぶんと 500 変更ぶんのクレジットを受け取る」とあります。公開日が 2026年9月23日なので、この窓は 10 月上旬までという計算になります（終了日の明示は 2026年9月24日時点でありません）。単位が「PR 本数」ではなく「変更（changes）」である点と、クレジットの対象が Rollouts と書かれている点は、原文どおりに読んでおくのが安全です。
GitHub Copilot のコードレビュー・Copilot Autofix との違い
同じ「PR に AI がコメントする」でも、GitHub 側は組み立てが違います。公式ドキュメントの説明の範囲で並べます。
| 観点 | Cursor Security Review | GitHub Copilot code review | GitHub Copilot Autofix |
|---|---|---|---|
| 扱う範囲 | 悪用できるバグに限定（品質は Bugbot） | 言語を問わずコード全般に複数観点でフィードバック | CodeQL のコードスキャン警告に対する修正案 |
| 出力の形 | 1 件のレビューコメント（重大度・攻撃経路・修正案） | 指摘と、数クリックで適用できる修正提案 | 警告に紐づく修正候補のコード |
| 必要なプラン | Teams・Enterprise | 有料の Copilot プラン全般 | CodeQL の解析。Copilot の契約は不要 |
| 裏で動くもの | Cloud Agents（Automations 基盤） | GitHub Actions ランナー（エージェント機能の実行に使う） | コードベースとコードスキャンの結果を使った LLM |
| 費用の目安 | チームの利用枠から（Cloud Agent の使用量課金） | 1 レビューあたり Lite で $0.05〜$1、Balanced で $0.25〜$5 の AI クレジット（Actions 分は別） | — |
公平に見ると、GitHub 側が勝っている点がはっきりあります。Copilot code review は GitHub.com・GitHub CLI・GitHub Mobile・VS Code・Visual Studio・Xcode・JetBrains・Azure DevOps（パブリックプレビュー）と対応面が広く、1 レビューあたりの費用感がドキュメントに金額レンジで書かれています。Cursor 側は Cloud Agent の使用量課金としか書かれておらず、2026年9月24日時点で「Security Review 1 回いくら」という公式の目安はありません。Copilot Autofix に至っては Copilot の契約なしで CodeQL の警告に修正案を付けられます。
逆に Cursor 側の強みは、品質・脆弱性・出荷後が別々のボットとして分かれていて、承認判断（PR Routing & Approval）にそれぞれの結果を材料として渡せる点、そして Rollouts がデプロイ後まで面倒を見る点です。GitHub 側に「デプロイ後の変更健全性を環境別に判定するボット」に相当する標準機能は、公式ドキュメント上で確認できませんでした。
エージェント開発での使いどころ｜AI が書いた差分のどこに人を残すか
AI にコードを書かせる比率が上がると、詰まる場所が「書く」から「確かめる」へ移ります。今回の 2 つは、その確かめる側を 2 か所に割り当てる道具です。エージェント開発の文脈では、次の 3 通りの使い方が現実的です。
1. 自動生成した PR の門番として Security Review を置く
cloud agent や自動化から出てくる PR は本数が多く、人の目が薄くなります。Security Review は「悪用できるバグ」だけに絞って 1 コメントで返すので、量が増えても読む対象が増えません。マージを実際に止めたいなら、前述のとおり PR Routing & Approval の Security Review Context と Maximum Risk Threshold を併用します。
2. エージェントの本番挙動を Rollouts の監視計画で言語化する
エージェント基盤の変更は、単体テストが通っても本番の振る舞いが変わりやすい領域です。Rollouts の監視計画には「この変更が起こすはずの効果」と「計測が入っていないせいで検証しにくい箇所」が書かれるので、デプロイ前に「何をもって成功とするか」が PR 上に文章として残るという副次的な効果があります。回帰検知の考え方そのものはAIエージェントの継続的評価とCI/CD回帰検知 運用ガイドで扱った内容と地続きです。
3. 既存コードの棚卸しは Vulnerability Scanner の cron に寄せる
PR レビュー型のボットは「変更された部分」しか見ません。すでに入っている脆弱性は永遠に残ります。docs にある Vulnerability Scanner は cron トリガーで静止状態のコードベースを走査する側なので、PR レビューと定期スキャンを分けて持つ構成が取れます。見つかったものは Flagged vulnerabilities に溜まり、そこから Cloud Agent を起動して直す流れです。本番運用側の設計はAIエージェント本番デプロイ・サービング実践ガイドも合わせて見てください。
注意点｜自動 merge も rollback もしない・Draft PR は対象外・10 日クレジットの条件
- Rollouts は自分で merge も rollback もしない。changelog に「today」と付けて明記されています。設定次第で revert PR を開くか cloud agent に修正を渡すところまでで、最後の操作は人が行います。「自動ロールバック機構」として運用設計に書き込まないでください。
- Draft PR は Security Review の対象外。changelog に「Draft PRs are skipped」とあります。下書きの段階で見てほしければ、手元で
/review-securityを回します。 - Rollouts のソース管理は Origin と GitHub だけが明記。GitLab・Bitbucket については changelog に記載がありません。Automations のソース管理トリガー自体は GitHub・GitLab・Bitbucket Cloud に対応していますが、Rollouts で同じ範囲が使えるかは 2026年9月24日時点で公式の記載がありません。
- フィーチャーフラグ連携は未提供。changelog に coming soon とあります。フラグでの段階リリースを前提にした監視は、現時点では組み込めません。
- 10 日間のクレジットは Rollouts を試すためのものと書かれており、Teams が約 50 変更ぶん、Enterprise が約 500 変更ぶん。「約（roughly）」が付いている数字なので、正確な消費量は自社の dashboard で確認してください。
- 料金はプランと使用量の 2 段構え。Teams は 1 ユーザーあたり月 $40（税別・年額と月額の選択あり）、Enterprise は個別見積もりです。ボットの実行分は Cloud Agent の使用量として別に乗ります。公式の目安では「日常的にエージェントを使う人で月 $60〜$100 の使用量、複数エージェントや自動化を回すヘビーユーザーで月 $200 以上」とされています（Rollouts・Security Review 単体の目安ではありません）。
- Automations のメモリと MCP は untrusted input に注意。docs は「メモリは実行をまたいで残るため、信頼できない入力を扱う自動化では注意して使うこと。入力が誤ったメモリや悪意あるメモリにつながり、将来の実行に影響しうる」と警告しています。MCP サーバーを接続するとそのサーバーの全ツールにアクセスできる点も同様です。
- この記事は公式ドキュメントの記述のみに基づく。検知率・誤検知率・レビュー時間といった実測値は、2026年9月24日時点で公式に公表されていません。
失敗パターン 4 つ｜設定した気になって穴が開く場所
公式ドキュメントの記述から読み取れる、設定の取り違えが起きやすい箇所を挙げます。
❌ Security Review を入れたからマージは止まると考える
⭕ Security Review は指摘コメントを置くだけです。マージを止めるのは PR Routing & Approval 側の役割で、Security Review Context を有効にして初めて「人のレビューが要る指摘があるなら承認しない」が効きます。Bugbot のチェックも同様に、既定の結論は neutral なのでブランチ保護に入れるだけでは止まりません。
❌ Rollouts の監視計画を読まずに PR をマージする
⭕ 監視計画は PR コメントとして書かれ、編集すればその版が使われます。「計測が入っていないので検証できない」と書かれた箇所を読まずにマージすると、デプロイ後の判定が inconclusive（判定不能）で返ってきます。計画のレビューまでを PR レビューに含めるのが本来の使い方です。
❌ Draft PR で回して「動かない」と判断する
⭕ Draft PR はスキップされる仕様です。Bugbot 側には「Draft PR でも自動レビューを有効にする」という個人設定がありますが、Security Review について同じ設定があるかは 2026年9月24日時点で公式の記載がありません。下書きで見たいときは手元の /review-security を使ってください。
❌ Bugbot のルールを .cursor/rules/*.mdc に書く
⭕ docs に「Cursor のプロジェクトルール（.cursor/rules/ の *.mdc ファイル）は Bugbot の実行には適用されない」と明記されています。Bugbot 用のルールは .cursor/BUGBOT.md に書きます。ルールが効いているかは PR コメントで確認できます。
# PR にコメントするとレビューを手動実行する
cursor review
bugbot run
# そのレビューで使われたルールの一覧表を出す
bugbot run verbose=true
cursor review verbose=trueルールは Team Rules → プロジェクトの .cursor/BUGBOT.md（入れ子のファイルを含む）→ 学習ルール → 手動ルールの順で 1 つのブロックにまとめられます。1 ルールあたり 30,000 文字で切られ、1 回のレビューに入る合計は 100,000 文字が上限です。上限を超えると一部が落ちるため、verbose で truncate や omit の表示を確認します。
Enterprise チームなら Bugbot の API からレビューを起動し、結果を取り出すこともできます（公式ドキュメントの例）。
curl --request POST \
--url https://api.cursor.com/bugbot/review \
-u YOUR_API_KEY: \
--header 'Content-Type: application/json' \
--data '{ "prUrl": "https://github.com/your-org/your-repo/pull/42" }'dryRun を true にすると、SCM 側へコメント・チェックを出さずに解析だけ走らせられます（結果は analytics から取得可能・dry-run も課金対象）。レート制限はチームあたり毎分 30 リクエスト、dry-run はさらに毎分 10 リクエストです。
よくある質問
Cursor Rollouts と Security Review はどのプランで使えますか？
changelog に「どちらも本日から Teams と Enterprise のプランで利用可能」と明記されています。Teams は 1 ユーザーあたり月 $40（税別）、Enterprise は個別見積もりです。個人向けの Pro／Pro Plus／Ultra では Bugbot と Cloud Agents は使えますが、Security Agents については「team または enterprise プランが必要」と PR Routing & Approval の docs に書かれています。
Rollouts は問題を見つけたら自動で切り戻してくれますか？
いいえ。changelog は「Rollouts does not merge or roll back on its own today」と明記しています。回帰を検知すると疑わしい変更を名指しして作者へ通知し、設定次第でレビュー用の revert PR を開くか、cloud agent に修正を渡すところまでです。
Bugbot を使っていれば Security Review は要りませんか？
役割が分かれています。changelog は「スタイルと品質は Bugbot に残る（Style and quality stay with Bugbot）」と書いており、Security Review は悪用可能なバグに絞って 1 コメントで返す側です。Bugbot の説明にも「バグ・セキュリティ問題・コード品質」とあるため重なる部分はありますが、Cursor 側の設計としては別の層に置かれています。
GitLab や Bitbucket のリポジトリでも使えますか？
Security Reviewer は「PR・MR のイベントを含む Git 由来の Automations トリガー」に対応すると docs にあり、Automations のソース管理トリガー自体は GitHub・GitLab・Bitbucket Cloud に対応しています（Bitbucket Server と Data Center は非対応）。一方 Rollouts のソース管理として changelog が挙げているのは Origin と GitHub だけです。PR Routing & Approval は GitHub と Origin のみ対応と明記されています。
10 日間の試用クレジットはどれくらいの量ですか？
changelog の表現では、Teams の顧客がおよそ 50 変更ぶん、Enterprise の顧客がおよそ 500 変更ぶんです。「roughly（およそ）」が付いた概算なので、実際の消費は dashboard の使用量で確認してください。公開日は 2026年9月23日で、終了日の明示は 2026年9月24日時点でありません。
PR を開かずに、手元で先にセキュリティレビューを回せますか？
できます。docs によれば /review-security または /review のスキルをエージェントから実行すると、push 前に Security Agent を走らせられます。既定では base ブランチとの差分すべて（コミット済みと未コミットの両方）が対象です。Cursor 3.7 以降、cursor.com/agents、Cursor CLI で使えます。
まとめ
2026年9月23日に出た Rollouts と Security Review は、「AI が書く量が増えた後の最後の 1 マイル」を PR の前後で分担するボットです。Security Review はマージ前に悪用できるバグだけを 1 コメントで、Rollouts はデプロイ後に環境別の健全性を 3 値で返します。どちらも Teams・Enterprise プランで、automations タブから有効化します。
導入時にいちばん誤解しやすいのは、この 2 つはどちらも最後の操作をしない点です。マージを止めるには PR Routing & Approval の設定が要り、切り戻しは人が判断します。逆に言えば、止める仕組みを別に持っているチームほど、この 2 つを素直に足せます。まずは 10 日間のクレジットの範囲で Rollouts を実際の変更に当て、監視計画に何が書かれるかを見てから、常用するかを決めるのが現実的な進め方です。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Cursor Changelog「Rollouts and Security Review」（2026年9月23日・参照日 2026年9月24日）
- Cursor Docs「Security Agents」（参照日 2026年9月24日）
- Cursor Docs「Automations」（参照日 2026年9月24日）
- Cursor Docs「Bugbot」（参照日 2026年9月24日）
- Cursor Docs「PR Routing & Approval」（参照日 2026年9月24日）
- Cursor「Pricing」（参照日 2026年9月24日）
- Cursor Docs「Models & Pricing」（参照日 2026年9月24日）
- Cursor Blog「Firetiger joins Cursor」（2026年8月13日・参照日 2026年9月24日）
- GitHub Docs「About GitHub Copilot code review」（参照日 2026年9月24日）
- GitHub Docs「Responsible use of Copilot Autofix for code scanning」（参照日 2026年9月24日）
