Cursor Security Review がベータ提供。常時稼働の AI レビュアーが PR ごとに脆弱性を指摘

Cursor、開発者向けに常時稼働のセキュリティレビュー機能を出してきた。

4 月 30 日付の changelog で、Cursor Security Review がベータ提供開始。Teams と Enterprise プラン限定、無料プランでは使えない。

要するに、PR を出すたびに AI レビュアーが脆弱性を指摘してくる仕組みだ。常時稼働の「Security Reviewer」と、定期スキャンの「Vulnerability Scanner」の 2 本立てになっている。

Security Reviewer は「PR ごとに inline コメント」

Security Reviewer のチェック対象は公式が 5 つ列挙している。脆弱性、認証退行、プライバシーとデータ取扱いリスク、エージェントのツール自動承認、プロンプトインジェクション。差分の該当行に直接 inline コメントが付き、severity（深刻度）と remediation（修正案）まで添えてくる。

レビュー疲れの現場には効く話。プロンプトインジェクションを PR レビュー対象に入れているのは、ここがポイント。エージェント時代のレビュー観点として、ほぼ標準装備になりつつある。

Vulnerability Scanner は「定期スキャン＋ Slack 通知」

Vulnerability Scanner はリポジトリ全体の定期スキャン側。既知の脆弱性、依存関係の古さ、設定ミスを見にいく。発見事項は Slack に流せる設定が用意されている。

Snyk や GitHub Dependabot がやってきた領域に、Cursor が同じ画面の中で乗ってきた、という話。

数字を見よう

提供開始 2026-04-30（ベータ）
対象プラン Teams / Enterprise
利用枠  既存の usage pool から消費
個別有効化 管理者が Cursor dashboard で有効化
拡張 MCP サーバ経由で既存 SAST / SCA / secrets スキャナを併用可

「既存の usage pool から消費」はコスト計算上のポイントだ。別枠課金ではない一方、開発タスクと同じプールを食う。レビューをどこまで常時回すかで、運用感はかなり変わる。

注意点

ベータである、という事実は外せない。誤検知や過剰指摘は当然出る前提で運用設計したほうがいい。Cursor 自身も「runtime / harness / モデルを継続改善中」と明記している。

それと、有効化は admin 操作だ。開発者の手元で勝手に試す類いではないので、社内導入時は誰が運用主体かを先に決めておいたほうがいい。

で、開発チームはどう動くか

結論：Teams プラン以上を契約済みのチームは「ベータ参加候補」、無料／Pro 個人は「対象外」。

Snyk / GitHub Advanced Security を既に入れている組織は、当面は二重持ちで比較するのが現実解。MCP 経由で既存スキャナと併用できる作りなので、いきなり置き換える必要はない。むしろ Cursor 側を「PR レビュー観点の自動化」、既存ツールを「依存関係 SBOM 管理」と役割分担させる構成のほうが事故が少ない。

新規導入を検討中なら、Cursor の枠内にセキュリティレビュー層が入ってくるのは選定上の加点材料になる。まずは admin が dashboard 側で有効化し、誤検知率と修正案の質を見ながら試すのが無難だ。

Cursor 公式 Changelog（2026-04-30）— Cursor Security Review

Cursor 公式 Docs — Security Review