まず結論
試験導入する価値はあります。ただし、安全な導入順は今でも、先にレビューしてから修正する形であり、最初から自動修正する形ではありません。
重要なのは単発の発表ではなく、Cursor が 2026年3月に 3 つの公式アップデートを続けて出したことです。
| 日付 | 公式アップデート | 重要な理由 |
|---|---|---|
| 2026-03-05 | Cursor Automations 公開 | スケジュール、GitHub、Slack、Linear、webhook をトリガーに常駐 agent を走らせられるようになった。 |
| 2026-03-16 | 4つのセキュリティ自動化テンプレートを公開 | PR レビュー、依存関係 remediation、repo スキャン、invariant チェックの公式ブループリントが揃った。 |
| 2026-03-25 | Self-hosted cloud agents が GA | 制約の強い環境でも、コード実行や build artifact を自社ネットワーク内に残せる公式ルートができた。 |
この 3 つがそろったことで、「Cursor をセキュリティに使う」が曖昧な話ではなく、実際のワークフロー設計の問題になりました。安全な始め方は、1つの repo、review-only の出力、1人の人間による triage owner、そして意図的に選んだ hosting boundary です。
2026 年 3 月に変わったこと
Cursor はセキュリティ agent を単なる将来像として語っている段階をすでに過ぎている。現在は次がそろっています。
- 公式の Automations 製品
- 公式の security-agents ローンチ記事
- すでに公開されている Marketplace の自動化テンプレート
- データ処理と privacy mode を説明する、2026-04-01 時点の Cursor Security
- より厳しい環境向けの self-hosted cloud agent オプション
ここまでそろえば導入ガイドを書くには十分です。ただし、無条件に信頼してよい段階ではありません。
Cursorが今実際に提供しているもの
今回もっとも実務的なのは、Cursor のブログ内名称と Marketplace テンプレートの対応がかなり揃ってきたことです。つまり、具体的な導入レーンにそのまま落とし込めます。
| ブログ上の名称 | Marketplace テンプレート | デフォルト trigger | デフォルト output | 最初の使いどころ |
|---|---|---|---|---|
| Agentic Security Review | Find vulnerabilities | PR opened、PR pushed | PR comment + Slack + check run status | merge 前の新規コード review |
| Vuln Hunter | Scan codebase for vulnerabilities | 毎日の定期実行 | Slack のみ | 既存コードの古いセキュリティ負債を掘る |
| Anybump | Remediate dependency vulnerabilities | Linear issue created | PR + Slack。ただし confidence が高い場合のみ | 依存関係リスクをエンジニアにノイズを増やさず処理する |
| Invariant Sentinel | Monitor engineering invariants | 毎日の定期実行 | 状態変化があるときだけ Slack | drift と regression の監視 |
見出しより重要なのは、公式テンプレートに最初から入っている次の 2 点です。
- PR review テンプレートには、diff を見て finding を返すこと、そしてコードを push しないこと、fix PR を開かないことが明記されています。
- 定期 scan と invariant テンプレートは、検証済みの issue や状態変化だけを報告するように設計されています。これがセキュリティ自動化をノイズ化させない鍵です。
Tip 1: まずは Cursor がすでに用意している review-only テンプレートから始める
最初に 1 つだけ採用するなら、Find vulnerabilities です。
PR review が馴染みやすいからというだけではありません。Cursor 自身のデフォルトテンプレートが、最初に必要な安全境界をすでに持っているからです。
- PR の作成時と更新時に trigger する
- 優先度付きで finding を返す
- check run status を更新する
- コードは push しない
- このワークフローから fix PR を開かない
このデフォルトは、自前で autonomy を強めるより良い出発点です。修復権限を与える前に false positives を測れます。
実際の導入順としては、次のような流れが安全です。
- まずは private Slack reporting または PR comments のみにする
- 自明ではない finding はすべて人間が triage する
- 非常に狭い種類の依存関係 issue にだけ fix PR を許す
- signal が安定してから blocking checks を検討する
Cursor も security-agents 記事 の中で、private reporting → PR comment → blocking gate という似た順序を説明しています。
Tip 2: 4つのセキュリティ仕事を 1 つの「万能 security agent」にまとめない
PR review、依存関係 remediation、repo 全体の scan、invariant monitoring を 1 つの汎用 automation にまとめないでください。
公式テンプレートは、最初から別々の成功条件を前提にしています。
- PR review は速く、保守的であるべき
- repo scan は報告前に attack path を end-to-end で追うべき
- dependency remediation は upgrade が明らかに安全なときだけ PR を開くべき
- invariant monitoring は毎日の再チェックではなく、状態変化だけを通知すべき
これを 1 つの agent にまとめると、それぞれのレーンを信頼できる理由そのものが失われます。
Tip 3: 証拠の基準を attacker、input、path、impact まで引き上げる
Cursor 自身の定期 vulnerability-scan テンプレートは、多くのチームが思うより厳格です。すべての報告 issue に次を含めるよう求めています。
- 攻撃者は誰か
- 攻撃者が制御できる入力は何か
- その入力が脆弱コードへどう到達するか
- 最終的にどんな impact を得るか
この基準は、定期 scan 以外の review にも有効です。
reviewer 向けには、たとえば次のような指示で十分です。
この変更に含まれる、検証済みのセキュリティ issue だけをレビューしてください。
各 finding には以下を含めてください:
- severity
- attacker model
- attacker-controlled input
- 入力から impact までの具体的なコードパス
- 関係する正確なファイルまたは依存関係
- merge を止めるべきかどうか
推測に基づく issue、スタイル指摘、証拠のない best-practice コメントは報告しないでください。
不確実な点がある場合は、不確実性と、何があれば検証できるかを明記してください。
これで agent が正しくなるわけではありません。ただ、結果を信じる・退ける・監査するのはかなりやりやすくなります。
Tip 4: 依存関係の自動化は、最小で安全な範囲から触らせる
Remediate dependency vulnerabilities テンプレートが強いのは、最初から agent に次を求めているからです。
- 問題を解決できる最小の version を優先する
- changelog と breaking changes を確認する
- override より direct upgrade を優先する
- 影響コードパスに対する focused validation を走らせる
- upgrade が明らかに安全なときだけ PR を開く
このベースラインは悪くありませんが、導入時にはやはり境界が必要です。
より安全な第1段階の境界は、たとえば次のようになります。
- まずは direct dependencies のみ
- 最初は patch / minor upgrade のみ
- major-version jump は除外する
- すでにある最小の package-relevant test command を必須にする
- 生成された PR には必ず 1 人の human reviewer を付ける
handoff block はこの程度で十分なことが多いです。
以下をすべて満たす場合にのみ remediation PR を開いてください:
- 脆弱な package が実際に import されている、または reachable である
- 選んだ fix が advisory を解消する最も低リスクな version である
- 変更が major-version jump ではない
- 影響コードパス向けの focused tests が通っている
- PR summary に人間が確認すべき残余リスクが書かれている
それ以外の場合は、PR を開かず triage 結果だけを返してください。
Tip 5: invariant は「セキュリティっぽさ」ではなく、明文化された repo ルールとして書く
Monitor engineering invariants テンプレートには、多くのチームが残すべき注意書きがあります。デフォルトをそのまま使わず、自分たちが本当に気にする invariant に置き換えることです。
悪い invariant:
- authentication should be secure
有用な invariant:
/admin配下の route はrequireAdminを bypass してはいけない- secrets を production の log sink に出してはいけない
- billing の side effect は明示的な approval checks の後ろに置く
- データを露出するコードパスでは、permission checks が実際の read / write capability と一致していなければならない
Cursor の invariant テンプレートは、各 invariant ごとに memory entry を持ち、前回実行からの状態変化だけを報告するようにも指示しています。だからこそ invariant の一覧は短く、明確で、検証可能であるべきです。
Tip 6: ワークフローをつなぐ前に hosting boundary を決める
これは運用上もっとも大きな論点で、細部ではありません。
2026-04-01 時点の Cursor Security では、基盤のホスティングは主に AWS であり、AI 機能を動かすために code data が Cursor のサーバーへ送られること、そして privacy mode は任意ユーザーが有効化でき、team admins によってメンバーへ既定適用もできることが説明されています。
多くのチームにはこれで pilot に十分ですが、そうでないチームもあります。
課題が internal network access、private dependencies や cache、あるいは build artifact を環境外へ出したくないことなら、より適した選択肢は self-hosted cloud agents です。2026-03-25 の発表では、コード、tool execution、build artifacts を自社ネットワーク内に残しつつ、同じ automation / cloud-agent 体験を維持できると説明されています。同じ記事では inference と planning は Cursor 側で引き続き行われるとも書かれているので、strict な no-code-leaves 要件がある場合は、導入前に Cursor-hosted のデータ処理境界を別途確認すべきです。
単純な判断ルールで十分です。
| あなたの状況 | より安全な最初の選択 |
|---|---|
| public repo または低センシティブ repo、標準的な CI、通常の branch protection | Cursor-hosted automation の pilot |
| private dependencies、internal network endpoints、または build artifact locality に厳しい要件がある | self-hosted cloud agents を先に検討 |
Slack や GitHub にすでに接続したあとで、この判断をしないでください。
Tip 7: 成功は demo の見栄えではなく、remediation とノイズで測る
本当に見るべきなのは demo が派手かどうかではありません。このワークフローが security backlog を減らし、同時に second review backlog を作らないかどうかです。
最初の 2〜4 週間は、次のような地味な指標を追うのが有効です。
| 指標 | 重要な理由 |
|---|---|
| 週あたりの validated findings 数 | 本当に仕事が見つかっているか分かる |
| false-positive rate | 開発者が信頼するかどうかを左右する |
| 開かれて merge された dependency PR 数 | remediation が理論でなく運用になっているか分かる |
| finding から fix までの時間 | 実際のセキュリティ価値を測れる |
| 同じ invariant や package に対する繰り返し finding 数 | feedback loop が弱いかどうか分かる |
コメントは多いのに修正がほとんど merge されないなら、普通は autonomy を増やすのではなく、スコープを狭めるべきです。
安全に始めるための14日プラン
具体的な始め方が 1 つ欲しいなら、次の順番が無難です。
- まず 1 つの active repo で Find vulnerabilities を report-only で有効化する。
- 初回実行前に、本当に見たい finding category を 3〜5 個決めておく。
- Remediate dependency vulnerabilities は patch / minor upgrade に限定し、focused tests を要求する。
- Monitor engineering invariants を入れる前に、明示的な invariant を 3 つ書く。
- インフラ境界が本当の blocker なら、カバレッジを広げる前に self-hosted cloud agents へ移す。
- 毎週 signal、false positives、merged fixes を見直してから blocking gate を検討する。
FAQ
Cursor のセキュリティ自動化は SAST や依存関係 scanner の代わりになりますか？
なりません。Cursor の公式資料は、review、validation、remediation、follow-up をつなぐ agent workflow として位置付けています。既存の scanner、ticket、branch protection に重ねるのがいちばん自然です。
大半のチームは最初にどのテンプレートを試すべきですか？
Find vulnerabilities から始めてください。もっともクリーンな review-only 入口であり、デフォルトテンプレートの時点で自動コード変更を禁止しています。
どんなときに Cursor-hosted より self-hosted cloud agents を選ぶべきですか？
コード、build output、cache、internal endpoints を外部実行環境に触らせられないとき、あるいは Cursor-hosted 環境から触るべきでない private infrastructure へ agent が到達する必要があるときです。
どんなときは、このワークフロー自体を避けるべきですか？
repo の tests が弱い、branch protections が弱い、ownership が曖昧、あるいは findings を triage する人がいない場合は、広い rollout を避けるべきです。その状態では自動化はセキュリティより queue を増やしやすくなります。
検証メモ
2026-04-01 時点で、次の Cursor 公式ソースを確認しました。
- Build agents that run automatically で、2026-03-05 の Automations ローンチ、trigger、cloud sandbox、memory、automation architecture を確認。
- Securing our codebase with autonomous agents で、2026-03-16 公開の Agentic Security Review、Vuln Hunter、Anybump、Invariant Sentinel、および Cursor 内部の rollout sequence を確認。
- Run cloud agents in your own infrastructure で、2026-03-25 の self-hosted GA と、コード、tool execution、build artifacts を自社ネットワークに残せるという説明を確認。
- Cursor Security で、現在の privacy mode と infrastructure に関する記述を確認。
- Find vulnerabilities、Scan codebase for vulnerabilities、Remediate dependency vulnerabilities、Monitor engineering invariants で、現在の default trigger、証拠要件、output behavior を確認。