AIにコードを書かせる量が増えるほど、気になってくる問いがあります。そのコードに穴が開いていないかを、誰が確かめるのか。
2026年9月23日、Cursor(コードを書くための専用ソフトにAIを組み込んだ開発ツール)が、この問いに答えにいく機能を2つ出しました。PR(プルリクエスト。コードの変更を本流に取り込む前に「この変更を見てください」と出す依頼)ごとに脆弱性を探す「Security Review」と、本番に出したあとの異常を見張る「Rollouts」です。10月8日時点の公式情報をもとに、何ができて何がまだできないのかを調べました。
AIが書いたコードを疑う役がいない
私がこの話を他人事だと思えなかった理由から書きます。
今年の春、Claude Codeに社内向けの小さな集計ツールを書かせました。動作は問題なし。ところが2週間ほどたって別件でコードを読み返したら、外部サービスの鍵(APIキーと呼ばれる、サービスを使うための合言葉のような文字列)が設定ファイルではなくコードに直接書かれていました。保管場所は非公開だったので実害はありませんでしたが、気づいたのは偶然です。
AIは頼んだ機能を作るのは得意です。ただ、頼んでいない安全性の確認まで毎回やってくれるとは限りません。人間がレビューする前提でも、量が増えると目が届かなくなります。
Claude Code側の基本的な注意点は以前まとめました。
Cursor Security Reviewは何を探すのか
Cursor Security Reviewは、PRが出るたびに、その変更を脆弱性の観点で読むボットです。変更部分だけでなく、そのアプリのコード全体の文脈を踏まえて判断すると説明されています。
公式ブログとチェンジログに挙がっている検出対象を、言い換えながら並べます。
- SQL・コマンドなどへのインジェクション(入力欄から命令文を紛れ込ませ、データベースやサーバーを不正に操作する攻撃)
- 認証や認可の抜け(ログインしていない人や権限のない人がデータを見られてしまう状態)
- パスワードや鍵がコードに書かれたままコミット(変更を履歴に記録すること)されている状態
- SSRF(サーバーをだまして、本来行かない場所へアクセスさせる攻撃)などの専門的な攻撃手法
- 既知の脆弱性を抱えた外部部品の利用と、サーバー設定の危ない初期値
私が春にやらかした鍵の直書きは、3つ目にそのまま当てはまります。
見つけた問題には深刻度、攻撃者がどうたどって悪用するかという攻撃経路、修正案が付きます。公式ブログは修正をワンクリックで当てられると書いています。誤検知なら、理由を書いて却下することもできます。
本番に出したあとを見張るRollouts
Rolloutsは守る場所が違います。Security Reviewが「取り込む前」なら、Rolloutsはマージ(PRの変更を本流に取り込むこと)して「本番に出したあと」です。
PRの段階で監視の計画をコメントとして書き、デプロイ(作ったものを実際に動く環境へ反映すること)のあとは環境ごとに様子を見ます。判定は「健全」「リグレッションあり(前は動いていたものが壊れた状態)」「判定できない」の3つ。エラーや応答速度だけでなく、その変更が狙った効果を出しているかも確認するそうです。
連携先は、コードの保管サービス(GitHubなど)、デプロイの仕組み、それに動作状況を記録する監視サービスです。公式ブログにはDatadog、Grafana、Honeycombの名前が出ています。
異常を見つけると、変更の作者に知らせます。設定次第で、段階的な公開を一時停止したり、変更を取り消すPRを承認待ちで用意したり、Cursorのクラウドエージェント(ネット上で動くAIの作業役)に修正を渡したりもできます。ただし自動でマージもロールバック(元の状態に戻すこと)もしない、とチェンジログに明記されています。最後に決めるのは人間です。
使えるのはTeamsとEnterpriseだけ
対象はTeamsとEnterpriseの2プランで、個人向けプランでは使えません。チームの管理者が設定画面のautomationsタブから、ボットごとに有効にします。
試用として10日間のクレジットが付きます。量はTeamsで変更約50件分、Enterpriseで約500件分です。
試用が終わったあとの料金は、10月8日時点でブログにもチェンジログにも書かれていません。料金ページにも両機能の項目は見当たりませんでした。Teamsプラン自体は1ユーザー月40ドルです。
10日で50件は、小さなチームが試すには足ります。ただ、試用中に役に立つ指摘がどれくらい出たかを記録しておかないと、有料になったときに続けるか決められません。私が試すなら、指摘の件数と、そのうち実際に直した件数だけは表にしておきます。
調べてわかったこと
最初の問いに戻ります。
Cursor Security Reviewが担うのは、PRという関所で、毎回同じ観点のチェックを欠かさずかけることです。人間のレビュアーは疲れますし、見る観点が日によってぶれます。決まった型の脆弱性を漏れなく拾う役は機械に向いています。
Rolloutsが自分では巻き戻さない設計には、むしろ納得しました。本番で何かを勝手に戻すこと自体が事故の種になります。判断は人間に残し、材料を揃えるところまでを機械にやらせる線引きです。
Claude Codeにも、PRを裏でレビューさせる仕組みがあります。
まだわからないこと
試用クレジットを使い切ったあとの課金方法と単価。日本語のコードやコメントへの対応の度合い。検出の精度を第三者が測った数字。この3つは10月8日時点で確かめられませんでした。公式の数字は同社のものだけなので、自社のコードで試すのが確実です。
エンジニアでない方にもできることがあります。社内でAIにツールを作らせている部署があるなら、そのコードを誰がどうチェックしているかを一度聞いてみてください。答えに詰まるようなら、こうした仕組みを検討する時期です。CursorとClaude Codeの使い分けはこちらにまとめています。
