Cursorのセキュリティエージェントのプロンプトを読んでみた。皆さんは読まなくて大丈夫です

これがプロンプトの全容です。

You are a security reviewer for pull requests.
Goal: Detect and clearly explain real vulnerabilities introduced or exposed by this PR. Review only added or modified code unless unchanged code is required to prove exploitability.
1. Inspect the PR diff and surrounding code paths.
2. For every candidate issue, trace attacker-controlled input to the real sink.
3. Verify whether existing controls already block exploitation: auth or permission checks, schema validation or type constraints, framework escaping, ORM parameterization, allowlists or bounded constants.
4. Report only medium, high, or critical findings with a plausible attack path and concrete code evidence.
Prioritize: injection risks, authn or authz bypasses, permission-boundary mistakes, secret leakage or insecure logging, SSRF, XSS, request forgery, path traversal, and unsafe deserialization, dependency or supply-chain risk introduced by the change.

これはCursorのAgentic Security Review自動化の中核です。週に3,000件以上の社内PRをレビューし、200件以上の実際の脆弱性を検出しています。役割の定義、目標、4段階の手法、そして優先順位リスト。複雑な思考過程の足場も、数ページにわたるFew-shotの例も、複雑なJSON出力スキーマもありません。

2年前に、これほど簡潔なプロンプトで大規模に運用し、CIをブロックする価値のある結果を出せると言われたら、私は疑っていたでしょう。AIへのプロンプトには、何ページもの指示、細心の注意を払って作成した例、詳細な出力仕様といった、手の込んだエンジニアリングが必要だと、私たちは皆思い込まされてきました。Cursorがオープンソース化したテンプレートを見ると、セキュリティレビューでは、明確な役割の定義と体系的な手法だけで十分なのかもしれません。

これは、現時点で最先端モデルがどこまで到達しているかを示す、注目すべき兆候です。モデルはすでに、SQLインジェクションがどのようなものか、認証回避がどう機能するか、安全でないデシリアライズとは何かを「知って」います。必要なのは、その知識を体系的に適用するための枠組みだけです。今日、これほど少ない指示でモデルがここまでできるのなら、今後6〜12か月の進展には本当に期待が持てます。

もちろん、プロンプトは氷山の一角にすぎません。ここでの真のエンジニアリング上の成果は、15行の指示ではなく、その下にあるすべてです。永続化と重複排除を担うカスタムMCPサーバー、Terraformで管理されるデプロイパイプライン、どのエージェントをいつ起動するかを判断するWebhookオーケストレーション、そして実行をまたいでエージェントが検出結果を比較できる状態管理。周辺のインフラがシンプルではないからこそ、プロンプトはシンプルなのです。これは重要な違いであり、実はより興味深い点でもあります。Cursorは巧みなプロンプトを書いただけではありません。本番運用に耐えるエージェントオーケストレーションプラットフォームを構築し、その上にシンプルなプロンプトを載せたのです。

ただし、結論を急ぐ前に、Cursorが構築したものの全体像、それぞれの優れた点、そして不足している点を見ていきましょう。そのためには、エージェント型開発環境のセキュリティを考える枠組みが役立ちます。

エージェント型セキュリティの3つの側面

Snykでは、エージェント型開発のセキュリティを3つの側面から考えています。エージェントが生成するコード、エージェントが依存するサプライチェーン、そしてエージェント自体の振る舞いです。コードの側面は、最も注目されている領域です。AIは安全なコードを書いているか、リリース前に脆弱性を検出できているか。サプライチェーンの側面は比較的新しく、見落とされがちです。MCPサーバー、自動化テンプレート、エージェントスキル、プラグインはすべてエージェントが依存するコンポーネントであり、サードパーティーの依存関係と同じリスクを伴います。振る舞いの側面は最も複雑です。エージェントは意図された範囲内で動作しているか、すべきでない判断をしていないか、組織全体で実際に何をしているかを可視化できているか。

Cursorのセキュリティエージェントが主に担うのは、コードの脆弱性を検出する1つ目の側面です。これは価値があり、欠かせない取り組みです。しかし、以下のウォークスルーで見るように、残る2つの側面も同じくらい重要であり、特にエンタープライズ規模ではその重要性が増します。CursorとSnykを併用して複数年にわたる脆弱性の滞留を解消したLabelboxのように、最高の成果を上げている組織は、3つすべてに取り組んでいます。

4つのエージェント：優れている点と不足している点

本日、Travis McPeakがブログ記事を公開し、CursorのセキュリティチームがCursor Automations（同社のクラウドエージェントプラットフォーム）上に4つの自律型セキュリティエージェントを構築した方法と、誰でも利用できるようテンプレートをオープンソース化したことを紹介しました。9か月でPRの処理速度が5倍に伸び、従来の静的解析では追いつけなくなっていました。そこで、対応できるエージェントを構築したのです。

システム全体は、注目に値する基盤の上に成り立っています。サーバーレスのLambda関数としてデプロイされたカスタムMCP（Model Context Protocol）サーバーです。永続的な状態追跡、Gemini Flash 2.5を使った重複排除レイヤー（異なるエージェントが同じ検出事項を別の表現で報告するのを防ぐ）、そして却下・スヌーズ操作付きの統一されたSlack出力フォーマットを提供します。すべてTerraformで管理されています。堅実なエンジニアリングです。

各エージェントの概要と、特に優れていると感じる点、そしてエンタープライズのセキュリティチームが検討すべき点を紹介します。

Agentic Security Review：PRのゲートキーパー

機能：すべてのプルリクエストをCursor固有の脅威モデルに照らしてレビューします。非公開のSlackチャンネルに検出結果を投稿し、PRに直接コメントを付け、セキュリティ上の問題が見つかった場合はCIパイプラインをブロックできます。Cursor’s Bugbotのような汎用レビューBotとの大きな違いは、コード品質の細かな指摘ごとにブロックすることなく、セキュリティに特化してプロンプトを調整できる点です。

優れている点：成果がすべてを物語っています。過去2か月で、このエージェントは数千件のPRで稼働し、数百件の問題が本番環境に到達するのを防ぎました。先ほど紹介したとおり、すべてを動かすプロンプトは驚くほど簡潔です。LLMベースのレビューとして、シグナル対ノイズ比は実に驚くべきものです。

検討すべき点：LLMは、データフローを読み違えたために、安全なパラメーター化クエリを「重大なSQLインジェクション」と自信満々に指摘することがあります。また、大規模なコードベースでは注意が散漫になり、実際の脆弱性を見逃すこともあります。セキュリティの文脈では、どちらの失敗も大きな代償を伴います。誤検知は開発者の信頼を損ない、見逃しは実際の脆弱性を本番環境に残します。検出レイヤーが完全に確率的な場合、両方のリスクを受け入れることになります。ここでの原則はシンプルです。エージェントに自分自身の答案を採点させてはいけません。LLMの検出結果を確認する独立した検証レイヤーが必要です。だからこそ、LLMレビューの下層に決定論的なSAST解析（Snyk Codeなど）を組み合わせることが重要です。決定論的エンジンは既知のパターンを機械的な精度で検出し、LLMはルールベースのツールでは見つけられない、新規の複数ファイルにまたがるロジックのバグを検出します。両方が必要です。

もう1つ注目したいのは、プロンプトテンプレートの末尾です。

Post a short Slack summary with the overall outcome and the top findings, if any.
Do not push changes or open fix PRs from this workflow.

レビューエージェントは、修正をプッシュしないことを明示しています。検出し、報告し、ブロックはしますが、その後どうするかは人間が決めます。Cursor自身のセキュリティチームも、自社ツールの運用では人間を介在させています。これは、自律型AIセキュリティが現時点でどの段階にあるかを示しています。強力な加速手段ではありますが、人間の判断に取って代わるものではありません。少なくとも、今はまだ。

Vuln Hunter：既存のコードベースをスキャン

機能：新しいコードの取り込みを監視するのではなく、既存のコードベースをスキャンします。リポジトリを論理的なセグメントに分割し、それぞれで脆弱性を検索します。セキュリティチームはSlackから検出結果をトリアージし、多くの場合、Slackから@Cursorに直接指示して修正PRを生成します。

優れている点：LLMの推論をレガシーコードに活用するのは賢明です。AIが力を発揮する領域です。複雑でドキュメントのないコードベースを理解し、静的ルールでは見つけられない脆弱性を特定できます。ファイルをまたぐロジックのバグ、アクセス制御の欠陥、何年も前のコードに潜む認証回避などです。従来のスキャナーは、照合するための明確なパターンが必要なため、こうした問題への対応が困難です。

検討すべき点：大規模な運用では、このエージェントが最も誤検知を起こしやすいでしょう。対象を絞ったPR差分ではなくコードベース全体をスキャンするため、モデルが扱うコンテキストは格段に大きくなります。そのとき、LLMの注意散漫が現実的な懸念になります。ETH Zurich、UC Berkeley、INSAITによるベンチマークBaxBenchでは、最高のモデルでさえ生成したソリューションの62%が誤りを含むか、セキュリティ上の脆弱性を抱えていることが分かりました。モデルが大規模で複雑なコードベースを推論する場合、「エージェントに自分自身の答案を採点させない」という原則が一層重要になります。誰かが修正に時間を費やす前に、LLMの検出結果を決定論的に検証し、正しいかどうかを確認する必要があります。

Anybump：依存関係の自動パッチ適用

機能：アプリケーションセキュリティで最も骨の折れる作業、依存関係へのパッチ適用に取り組みます。到達可能性解析で実際に影響のある脆弱性に絞り込み、コードパスを追跡し、テストを実行して問題がないか確認します。テストに合格するとPRを作成します。すべて自動化されており、最後の安全策としてCursorのカナリアデプロイパイプラインが機能します。

プロンプトの要点は次のとおりです。

You are a dependency-vulnerability remediation automation.
Goal: When a new Linear issue describes a vulnerable dependency, determine whether it can be upgraded safely and open a PR only when confidence is high.
Decision rule: Create PR only when upgrade is clearly safe; otherwise do not make changes.

優れている点：これは、すべてのセキュリティチームがよく知る悩みに応えるものです。依存関係へのパッチ適用には非常に時間がかかるため、多くのチームはやがて諦めてエンジニアリングチームに任せます。そして、バックログに何か月も（あるいは何年も）放置されます。到達可能性解析、テスト、PR作成を自動化することは、ワークフローを大きく改善します。

検討すべき点：Anybumpは、依存関係管理で最も難しい部分、つまりパッチを実際に適用し、テストして、PRに反映する作業を解決します。一方、そのパッチを取り巻く作業は対象外です。SBOMの生成、ライセンスコンプライアンスの確認、コンプライアンスチーム向けの監査証跡はありません。これはエージェントの欠点というより、まったく別のカテゴリの課題です。自動パッチ適用とエンタープライズ向けソフトウェアコンポジション分析には重なる部分もありますが、同じものではありません。規制業界に属している場合や、コンプライアンス要件を含む顧客との契約の下でソフトウェアを提供している場合は、自動化とともに、より広範な基盤が引き続き必要です。

リポジトリが1つのスタートアップなら、Anybumpだけで十分かもしれません。しかし、何百ものリポジトリを抱え、規制業界に属し、特定のコンプライアンス認証を求める顧客と契約しているようなエンタープライズ規模で事業を運営するなら、ソフトウェアに何が含まれているのか、どのライセンスを使っているのかを正確に把握し、それを証明できなければなりません。これが自動パッチ適用とエンタープライズグレードのソフトウェアコンポジション分析の違いです。両者には重なる部分もありますが、根本的に異なる課題を解決します。

Invariant Sentinel：コンプライアンスの逸脱を検出

機能：セキュリティとコンプライアンスに関する一連のプロパティからの逸脱がないか、毎日チェックします。リポジトリの論理的なセグメントごとにサブエージェントを起動し、自動化メモリを使って現在の状態を過去の実行結果と比較します。変更があれば、セキュリティチームにアラートを送ります。

優れている点：状態を保持する仕組みが巧みです。自動化のメモリ機能を使って実行結果を比較することで、エージェントはある時点のスナップショットだけでなく、セキュリティ態勢の変化を検出できます。分析と並行して検証コードを記述・実行できるため、LLMの推論だけでは得られない厳密さが加わります。

検討すべき点：コンプライアンスの逸脱検出は有用ですが、コンプライアンスガバナンスはより広範な課題です。Invariant Sentinelは変更を知らせますが、何百ものリポジトリにわたってポリシーをコードとして強制したり、監査人向けのコンプライアンスレポートを生成したり、CISOにリスクの推移を時系列で示すダッシュボードを提供したりはしません。これらは単独のエージェントでは提供できない、プラットフォームレベルの機能です。

これは依然としてCIです。セキュリティをCIから始めるべきではありません。

アーキテクチャ図やエージェントオーケストレーションに注目すると、見落としやすいことがあります。Cursorが構築したのは、根本的には非常に高度なCIレイヤーです。PRの作成やプッシュをきっかけに、GitHub Webhook経由でエージェントが起動します。差分をレビューし、コメントを投稿し、パイプラインをブロックして、修正PRを作成します。これは、従来のセキュリティツールが長年使ってきたものと基本的に同じ制御ポイントですが、正規表現ベースのルールエンジンの代わりにLLMが分析を行うため、より賢くなっています。

そして、これは確かな改善です。異論はありません。しかし、CIは依然として、セキュリティを始めるには適切な場所ではありません。

CIからではセキュリティ対策が遅すぎる理由

考えてみてください。IDEでコードを書くのにCursorを使っていて、脆弱なコードが誰かに見つかる前にPRまで到達してしまったら、すでに時間をロスしています。開発者は自分が書いたコードから意識を切り替えなければならず、PRレビューのサイクルで遅延が生じます。CIチェックでブロックされた場合は、問題の内容を理解し、修正して、再度プッシュし、もう一度レビューを待たなければなりません。もちろん、本番環境で脆弱性が見つかるよりはましですが、それでも「スキャンしてチケットを起票する」モデルを、PRのタイムラインに押し込んだだけです。

シフトレフトの実際の姿

本当に必要なのは、IDE内でセキュリティツールを直接動かし、新しいコードが追加されるとすぐにスキャンと修正を実行することです。そうすれば、脆弱なコードがそもそもコミットに含まれることはありません。Gitの履歴をクリーンに保てます。セキュリティの問題は、開発者が変更をステージングする前に作業の流れの中で検出・修正されるため、PRがブロックされることもありません。さらに、コストのかかる人手を介したレビューの必要性を大幅に減らせます。脆弱性がPRに入らなければ、誰もトリアージする必要はなく、金曜日の午後4時30分に誰かのパイプラインがブロックされることもありません。

IDEファーストのセキュリティとCIファーストのセキュリティ

Snyk Studioでは、まさにこのように機能します。開発者がAIの提案を受け入れる前に、セキュリティガードレールが安全でないコードを検知します。AIアシスタントは新しいコードに対してリアルタイムでsnyk_code_scanを実行し、セキュリティ上の問題が見つかれば、その場で作業の流れを止めずに修正します。Cursorをはじめ、主要なAIコーディングアシスタントすべてで直接利用できます。CIパイプラインのブロックも、コンテキストスイッチも、煩雑なGit履歴もありません。

多層防御が必要な理由

両方を併用することを考えてみてください。IDE層のSnyk Studioが大半の問題を発生時点で検出し、CI層のCursorのセキュリティエージェントが、すり抜けた問題を検出するセーフティネットになります。多層防御を実現し、大半の作業はIDE内で目立たない形で処理される一方、コストのかかる人手によるレビューは本当に複雑なケースに集中できます。BaxBenchが示すAI生成コードの脆弱性率（トップモデルのソリューションの62%に脆弱性が含まれる、または正しくない）を考えれば、こうした多層防御は「あればよい」ものではありません。不可欠です。

さらに、CIの問題にとどまらず、セキュリティプログラムはCIチェックだけではありません。何百ものリポジトリにわたるリスクを集約する一元管理ダッシュボードも必要です。SASTの検出結果をDASTの結果と関連付け、同じエンドポイントが実行時に悪用可能であることを確認します。SCAエンジンは、利用しているORMライブラリに特定のエッジケースでパラメータ化を回避する既知のCVEがあることを特定し、同じコントローラーメソッドに対するSASTの検出結果と関連付けます。それぞれ単独では個別のデータポイントにすぎません。しかし、同じプラットフォーム上で相関させれば、何が起きているのか、なぜなのか、何を優先して修正すべきかが明確になります。4つのエージェントと優れたPR処理能力を備えた自律型コードスキャナーであっても、こうした問いには答えられません。答えられるのはセキュリティプラットフォームです。

競争ではなく、必要性を裏付けるもの（そして、すでに連携しています）

数週間前、AnthropicのClaude Code Securityのローンチについて記事を書き、AIコーディングプラットフォームがセキュリティに投資するのは、破壊ではなく必要性を裏付けるものだと論じました。同じことが今回にも当てはまります。AI開発ツールの大手がセキュリティ機能を作り始めているのは、AI支援開発におけるセキュリティが、任意の追加機能ではなくインフラだと業界が理解したということです。

CursorとSnykの連携

CursorとSnykは、すれ違うだけの関係ではありません。SnykはすでにCursorのMCP Directoryに掲載されています。検証済みの拡張機能を提供し、Evo Agent Guard via Hooksをリリースしています。2週間前には、Cursorが当社のAI Innovation Partner of the Yearに選ばれました。これは対立関係ではなく、二層アーキテクチャの実践です。AIエージェントは研究者のように、スピードと創造性を発揮して脆弱性を発見し、修正を提案します。決定論的な検証はピアレビューの役割を担い、検出結果が実在すること、修正が適切であることを独立して確認します。

二層のセキュリティアーキテクチャ

ピアレビューなしで論文を発表しないように、決定論的な検証なしにセキュリティ修正をリリースすべきではありません。Cursorは、エージェントのオーケストレーション、Webhookトリガー、自動PR作成といった研究レイヤーを提供します。Snykは、ソフトウェアサプライチェーン全体にわたるピアレビュー、ガバナンス、幅広いカバレッジを提供します。

そして、これはすでに実際の現場で機能しています。Labelboxは本番環境でCursorとSnykを併用し、何年も蓄積していた脆弱性のバックログを解消できました。Cursorが修正ワークフローを自動化し、Snykが修正の実効性とエンタープライズ基準への適合を確認します。

エージェント型サプライチェーンが新たな攻撃対象領域に

Cursorの具体的な実装から少し視点を広げ、業界全体で何が起きているかを見てみましょう。この1年で、まったく新しいソフトウェアサプライチェーンが生まれ、急速に拡大しています。MCPサーバー、エージェントスキル、自動化テンプレート、AIツールのプラグイン、カスタムモデル構成などです。これをエージェント型サプライチェーンと呼びましょう。AI搭載の開発ツールが動作するために依存するコンポーネント群のことですが、現時点で、これらを保護できている組織はほとんどありません。

これは理論上の懸念ではありません。2026年1月、Snykの研究チームは、AIエージェントのエコシステムを標的とした初の大規模なサプライチェーン攻撃として、ClawHub上で数百件の悪意あるスキルを発見しました。Cursorがオープンソース化したばかりのものを考えてみてください。コードベース、CIパイプライン、Slackチャンネル、GitHubリポジトリへのアクセス権を持って動作する自動化テンプレートです。組織内のすべてのセキュリティ検出結果を処理する、Lambda関数としてデプロイされたMCPサーバーもあります。これらは強力で、幅広い権限を持つコンポーネントです。そして、それらを配布・発見するためのエコシステム（マーケットプレイス、テンプレートギャラリー、オープンソースリポジトリ）は、それを取り巻くセキュリティ対策よりもはるかに速いペースで拡大しています。

従来のソフトウェアサプライチェーンでは、現在頼りにしているツールが整うまでに数十年かかりました。署名検証機能を備えたパッケージレジストリ、SBOM、ライセンススキャナー、脆弱性データベースなどです。エージェント型サプライチェーンには、まだそうしたインフラがありません。それにもかかわらず、すでに大規模に導入されています。MCPサーバーのインストール、自動化テンプレートのインポート、エージェントスキルの開発環境への接続を行うたびに、組織の攻撃対象領域は広がります。どれほど高度なコードレベルのスキャンであっても、こうしたリスクには対処できません。

まさにこの課題を解決するためにEvo by Snykが開発されました。Evoは、AIネイティブな開発環境向けに設計されたエージェント型セキュリティオーケストレーションシステムです。コードから最新の脅威モデルを構築するAI脅威モデリング、モデルやエージェントに対して継続的に敵対的テストを行うAIレッドチーミング、組織内で稼働するAIモデルやフレームワーク（セキュリティチームも把握していない「シャドーAI」を含む）を正確に把握できるAI-SPM、そしてすべてのツールチェーンを可視化し、リアルタイムのガードレールを提供するAgent Scanningを備えています。

コードベース全体で自律型セキュリティエージェントを運用するなら、そのエージェント自体も保護する必要があります。エージェント型サプライチェーンのツールは、node_modules内のnpmパッケージと同じくらい重要です。同じ厳格さで保護する必要があります。

次に考えるべきこと

すでに書いた主張をまとめて締めくくるのではなく、Cursorの発表が投げかける、これからを見据えた問いで終わりたいと思います。過去を振り返るよりも、こちらのほうが興味深いからです。

ぜひお試しください

Snyk Studioは無料で、セットアップは数分で完了します。Cursorをはじめ、ほぼすべてのAIコーディングアシスタントで動作します。約5分で、決定論的なスキャンと/snyk-fix修正コマンドをIDE内で使えるようになります。多層防御を実際に試すなら、これが最も手早い方法です。

AIスタックそのものを保護する必要があるなら、Evo by Snykをご利用ください。脅威モデリング、レッドチーミング、AI-SPM、エージェントスキャン、エージェント型セキュリティのオーケストレーションを提供します。組織でAIコーディングツールを大規模に導入しているなら（正直、きっとそうでしょう）、Evoが可視性とガードレールを提供し、安全な導入を支援します。

Cursorの自動化テンプレートはGitHubでオープンソースとして公開されています。Cursorユーザーなら、ぜひ試してみてください。Snykと併用すれば、エージェントによる自動化と、エンタープライズ基準の検証の両方を活用できます。

必要な要素はすべてそろっています。あとは組み合わせるだけです。