エージェント型脆弱性管理をエンドツーエンドで検証:119,443件の検出から絞り込んだ2,731件、承認された修正はわずか1件

Sysdigのエージェント型クラウドセキュリティの仕組み

要点: Sysdig Secure AIのライブセッションでは、エージェントが119,443件に及ぶ検出結果のバックログをトリアージし、SLA違反となっている2,731件の検出結果をたどってベースイメージの修正1件に集約しました。そして人間がその結果生成されたJiraチケット「DEJI-342」を承認しました。同じエージェントは、SysdigのMCPサーバーを通じてClaude上でもヘッドレスで動作します。

脆弱性管理プログラムを担当したことがある人なら誰でも、その居心地の悪い実情を知っています。問題は検出結果そのものではなかったのです。「知る」ことは簡単です。スキャナーを使えば、昼までに6桁件数の検出結果を手に入れられます。本当の問題は、「知る」ことと「対処する」ことの間にある距離です。CVEを実際に影響を受けるワークロードに紐づけ、担当者を探し出し、チケットを起票し、SLAを追跡する——この一連の作業には、アナリストの労働時間という物差しでしか測れない距離があります。そしてアナリストは、組織の中で最も希少なリソースなのです。

攻撃者が人間のスピードで動いていた時代なら、このギャップも「何とか耐えられるもの」でした。しかし、もはやそうではありません。Sysdig Threat Research Teamは最近、LLMがエンドツーエンドで主導する恐喝キャンペーン、初のエージェント型ランサムウェア運用であるJADEPUFFERについて報告を行いました。また、当社の2026年版クラウドネイティブセキュリティレポートは、この変化を数字で裏付けています。攻撃者は今や、脆弱性が公表されてから数時間以内にそれを武器化しているのです。従来からの痛みそのものは変わっていません。変わったのは、その痛みにかけられる時間です。

ここでエージェント型モデルが計算式を書き換えます。以下は、セキュリティ分野で最も困難な業務の一つに取り組むSysdig Secure AIを、実際の環境で記録したウォークスルーです。文章より動画で見たい方は、こちらの動画版をご覧ください。

運用方針を決めるのは人間

エージェントに自由裁量が与えられているわけではありません。与えられるのはあくまで「目標」です。セットアップは、本来リスクについて議論する際に行うべき手順から始まります。まず重要度の高い資産にタグを付け、次に深刻度ごとにSLAの猶予期間を定義します。この環境では、Critical(緊急)およびHigh(重要)の脆弱性は30日以内に修正する必要があります。

目標は「継続的な計画」になる

Secure AIは、こうしたポリシーを継続的な計画へと変換します。今回のケースでは「SLAコンプライアンス」と「エクスポージャー時間の削減」です。ここで見落としがちな重要な変化があります。エージェントはタスクリストをこなしているのではなく、ある成果に向けて働いているという点です。

この違いはすべてを左右します。タスクキューとは、人が中身を詰め、消化し、また詰め直すものであり、空になった瞬間に作業は止まります。一方、計画はエージェントが継続的に追い求める目標であり、その目標は「あなた自身」のものです。それはチームのSLA、リスク許容度、そして許容可能なエクスポージャーの定義から生まれます。人間が目的を定め、エージェントはその実現に向けて、誰かがキューを再投入しなくても、日々前進し続けるのです。

エージェントが動くのは「チケットキュー」ではなく「指標」

SLAコンプライアンスの計画を開くと、エージェントはまるで同僚のように報告してきます。「現在値28.3%、前日比2.9ポイント増」といった具合に、その根拠まで書き出してくれます。この計画が何を追跡しているのか、どの検出結果が指標に算入されるのか、キューがどのように順位付けされたのか——すべてが説明されます。エージェントは、この指標を最も動かす作業のランキングリストを常に維持しています。このキューが存在するために、アナリストが何かに気づく必要は一切なかったのです。

結論:CVSSの当て推量ではなく、ランタイムのコンテキストがものを言う

ランキング1位のタスクは、人間がすぐ行動に移せる結論に行き着きます。あるNode.jsイメージ(node:17.9.1-bullseye)が2,731件のSLA違反検出結果を抱えており、そのうち273件はCriticalで、最も古いものは期限を90日超過している——というものです。メンテナンスされているNode 17系のベースイメージに入れ替えれば、これらはすべて解消します。これはCVSSスコアの一覧表ではなく、ランタイムインサイトが優先順位付けを行った結果です。この計画は、SLA違反の中で最も深刻なものを基準にランク付けし、かつすでに修正パッチが公開されている検出結果のみに絞り込むため、キューにはチームが今日にでも実行できる作業だけが残ります。ほかの計画では異なるランタイムシグナルを用いており、たとえば「エクスポージャー時間の削減」計画はリスクスコア・検出件数・経過日数でランク付けし、本稿後半で紹介するヘッドレスクエリはEPSSによる悪用確率とCISA KEVの照合結果でランク付けします。

この背後にあるシグナルについては、正確に理解しておく価値があります。というのも、今や多くのツールが「到達可能性(reachability)」を謳っているからです。しかし、その大半が指すのは「静的な到達可能性」、つまり依存関係グラフ上のどこかに理論的には存在する経路にすぎません。Sysdigのランタイム到達可能性はより厳密です。脆弱なパッケージが、まさに今この瞬間、稼働中のプロセスにロードされているという事実であり、さらにワークロードのエクスポージャーは別のシグナルとして評価されます。これは「到達し得るもの」と「実際に稼働しているもの」の違いです。これほどの規模のバックログを1つの実行可能な修正にまでたどり着かせる作業は、通常であればエンジニアの1日をまるごと費やすものです。しかしエージェントは、それをすでに終わらせた状態でやって来ました。

制御の要は人間が握る

エージェントは修正チケット(概要、影響範囲、修正案)の下書きを作成し、たった一つだけ質問を投げかけます。「担当者は誰ですか?」。そして人間がレビューを行い、「承認」をクリックします。このクリック一つに、自律性をめぐる議論のすべてが集約されているのです。分析はエージェントが行い、変更を許可するのは人間です。

「なぜ」を丸ごと引き継いだ、本物のチケット

承認から数秒後には、それは実在するJiraチケット「DEJI-342」となり、担当者にアサインされ、generated-by-sysdigというラベルが付き、完全な根拠——このタスクが重要な理由、SLAの計算根拠、修正の提案内容——を引き継いだ状態になります。SLA追跡はこれを自動的に取り込みます。ここに示されているものはモックアップではありません。実際にこのデモ環境に接続されているJiraインスタンスそのものです。

同じ「頭脳」が、AIアシスタント上ではヘッドレスで動く

ここまではコンソールの話です。しかし、エンジニアが日常的に使う場は、ますますコードエディタやAIアシスタントへと移っています。そこでSysdigは、同じ機能をSysdig MCPサーバー(GitHub上でオープンソース公開中)を通じてヘッドレスでも提供しています。

ここには3つの要素が伴っており、それらを分けて考える価値があります。というのも、世に言う「エージェント型」ツールの大半は、最初の要素しか備えていないからです。まずサーバーが「アクセス」を担い、ランタイムデータをアシスタントに公開します。次にスキルが「ノウハウ」を担います。検出結果を実際の悪用可能性に基づいてどうランク付けするか、6桁規模のバックログをどう1つの修正にまでたどり着かせるか、新たなCriticalを生まないアップグレード経路をどう見極めるか——といったSysdigの10年分の知見がここに凝縮されています。そして、エージェント型ワークフローが「指示を待たない」部分を担います。コンソール上と同じ継続的な計画、「SLAコンプライアンス」と「エクスポージャー時間の削減」は動き続け、バックログのランク付けを続けます。そのため、エンジニアが一文字入力する前から、すでに修正案は浮かび上がっているのです。

ここが決定的な違いです。いくつかのAPI呼び出しをMCPサーバーで包んで「エージェント型」と名乗ることは、誰にでもできます。配管(プラミング)が与えてくれるのは「アクセス」だけです。スキルが与えてくれるのは「良い答え」です。そしてエージェント型ワークフローが意味するのは、答えがすでに用意されているということなのです。

以下はClaude上での実例です。権限確認プロンプトが何を示しているか、具体的なツール名と具体的なクエリの内容に注目してください。

Allow Claude to use List Vulnerability Findings
(Aws-us1 Sysdig Secure MCP Server)?

{
 "severity_in": [
   "critical"
 ],
 "limit": 5,
 "hasFix": false,
 "hasExploit": false
}

ランタイムからのリアルタイムな回答

上位5件のCritical脆弱性を尋ねると、古くなったエクスポート結果ではなく、ランタイムから直接回答が返ってきます。CVE-2026-55200と、3件のlibheif関連のCVE-2026-32740のバリアントを含む5件すべてが、ECS Fargate上の単一のnginxサービス上に存在しており、EPSSによる悪用確率とCISA KEVの照合結果でランク付けされています。使う計画もデータも同じで、違うのはインターフェースだけです。これこそが重要なポイントです。

ガードレールは明示的に定められている

修正の実行に同意すると、エージェントはSysdig Remediateスキルを起動します。実行前に、エージェントは自らの行動規範を提示します。「エージェント型」という言葉が信頼を勝ち取れるかどうかは、まさにここにかかっています。

• 実行すること:対象イメージに影響を及ぼすCriticalおよびHighのCVEを取得し、チェーン解析によって安全な修正バージョン(新たなCriticalを持ち込むアップグレードは除外)を特定した上でパッチを作成し、追跡用チケットを更新する。
• 実行しないこと:リポジトリへのコミットやプッシュ、認証情報のログ出力や表示、明示的な承認なしでの変更は一切行わない。前提条件が満たされていない場合はそれを検知し、プルリクエストにするか、ローカルのパッチファイルにするか、進め方を確認する。

ワークフローの「導入前」と「導入後」

コスト構造も同じ曲線を描いており、注目すべきは「上限」です。人手のみのチームでは、制約要因がアナリストの労働時間である以上、年間925件程度の調査が限界です。一方、エージェント型ワークフローは年間10,000件以上をこなせ、制約要因はもはや「人」ではなくなります。コスト面の試算も良好です。当社の内部分析によれば、人手のみによる調査1件あたりのコストは約135ドルであるのに対し、エージェント型ワークフローではAIのトークンコストを含めても約16ドルで、88%の削減となります。とはいえ、このコストの数字はあくまで上司を説得するための材料にすぎません。チームの防御能力を実際に変えるのは、この「上限」の違いなのです。

数値はSysdig社内分析によるものであり、実際の環境や料金体系によって変動します。

より大きな変化:一つの頭脳が、あらゆるインターフェースに宿る

ここで取り上げた機能そのものは脆弱性管理ですが、その先にあるのはアーキテクチャレベルの大きな変化です。同じエージェント、同じ計画、同じランタイムデータが、人間向けにはSysdigのUIとして、AIアシスタント向けにはヘッドレスツールとして、どちらでも利用可能になっています。一つの頭脳が、あらゆるインターフェースに宿るのです。これは、当社がエージェント型クラウドセキュリティおよびSysdig Sageで示してきた方向性と同じであり、また「防御の要はポスチャーではなくランタイムである」と当社が主張し続けている理由でもあります。エージェントの有能さは、それが推論の材料とするデータの質に左右されます。そして、「今この瞬間何が真実か」を語れるデータは、ランタイムデータをおいてほかにありません。

そして、エージェントの有能さは、それを動かす専門知識の質にも左右されます。MCPという配管部分は、誰にでも模倣できる、いわば当然の前提条件にすぎません。しかし、どの検出結果が本当に重要かを見極める10年分のSysdigの知見を、実際に動くスキルへと落とし込むこと——これは模倣できません。

攻撃者はすでにマシン速度への移行を果たしました。検知と対応の分野における当社の答えが555ベンチマークだったとすれば、エージェント型脆弱性管理は、バックログ問題に対する同じ答えです。検出結果が届くのと同じ速度で修正を行いつつ、何をリリースするかは人間が決める——それがこのアプローチの本質です。

もし自分がバックログの責任者であるなら、ぜひ実際の検出結果に対してこの仕組みが動くところを見てみてください。このデモは当社の環境ではなく、あなた自身の環境上で行われます。まずはヘッドレスワークフローから試してみたいという方には、Sysdig MCPサーバーがGitHub上でオープンソース公開されています。

よくある質問