.png)
Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年8月4日に Blair Howard が投稿したブログ (https://www.sysdig.com/blog/agentic-vulnerability-management-end-to-end-2-731-findings-one-approved-fix) を元に日本語に翻訳・再構成した内容となっております。
Sysdig のエージェント型クラウドセキュリティの仕組み
TL;DR: 実際の Sysdig Secure AI セッションにおいて、エージェントは 119,443 件の検出結果からなるバックログをトリアージし、SLA 違反となっている 2,731 件の検出結果を 1 件のベースイメージ修正まで辿り、人間がその結果として作成された Jira チケット DEJI-342 を承認しました。同じエージェントは、Sysdig の MCP サーバー を通じて Claude 内でヘッドレスに動作します。
脆弱性プログラムを担当したことのある方なら、居心地の悪い事実をご存じでしょう。問題は検出結果そのものではありませんでした。知ること自体は簡単です。スキャナーは昼までに 6 桁の検出結果を平然と差し出してきます。問題は、知ることと実行することの間にある距離です。CVE を実際に影響を受けるワークロードに対応付け、担当者を探し出し、チケットを作成し、SLA を追跡する。その距離はアナリストの工数で測られ、そしてアナリストは社内で最も希少なリソースです。
攻撃者が人間の速度で動いていた時代であれば、このギャップは「何とか許容できる」ものでした。しかし、もはやそうではありません。Sysdig Threat Research Team は先日、JADEPUFFER という初のエージェント型ランサムウェア活動、つまり LLM がエンドツーエンドで駆動する恐喝キャンペーンを報告しました。また、2026 年クラウドネイティブセキュリティレポートは、この変化を数字で示しています。攻撃者は今や、公開された脆弱性を数時間のうちに武器化しています。古くからある痛みは変わっていません。変わったのは時計です。
ここでエージェント型のモデルが計算式を変えます。以下は、セキュリティ業務の中で最も難しい仕事のひとつに取り組む Sysdig Secure AI を、実環境から記録したウォークスルーです。読むよりも見たいという方は、動画版をご覧ください。
行動指針を決めるのはお客様です
エージェントに自由裁量は与えられません。与えられるのは目標です。セットアップは、あらゆるリスクの議論がそうあるべき形で始まります。まず価値の高い資産にタグを付け、次に重大度ごとの SLA 期限を定義します。この環境では、Critical と High は 30 日以内に修正する必要があります。
目標が常設プランになる
Secure AI はこれらのポリシーを常設プランに変換します。今回の場合は SLA Compliance（SLA 準拠）と Reduce Exposure Time（エクスポージャー時間の削減）です。ここが見落としやすい変化です。エージェントはタスクリストを処理しているのではありません。成果に向かって動いているのです。
この違いがすべてです。タスクキューは、満たし、消化し、また満たすものであり、空になった瞬間に作業は止まります。一方でプランは、エージェントが継続的に追求する目標であり、その目標はお客様のものです。それはチームの SLA、リスク許容度、そして許容できるエクスポージャーの定義から生まれます。お客様が目的を設定すれば、エージェントは誰かがキューを再投入しなくても、日々そこに向かって進み続けます。
エージェントはチケットキューではなく指標に取り組む
SLA Compliance プランを開くと、エージェントは同僚のように報告します。現在値 28.3%、前日比 2.9 ポイント上昇といった内容を、その根拠とともに文章で示します。プランが何を追跡しているのか、どの検出結果が指標に算入されるのか、キューがどのようにランク付けされたのか。エージェントは、指標を最も大きく動かすジョブのランク付きリストを維持します。このキューが存在するために、アナリストが何かに気づく必要はありませんでした。
判定：CVSS の推測ではなく、ランタイムのコンテキスト
最上位にランクされたジョブは、人間が行動に移せる判定に落ち着きます。1 つの Node.js イメージ（node:17.9.1-bullseye）が SLA 違反の検出結果を 2,731 件抱えており、うち 273 件が Critical で、最も古いものは期限を 90 日超過しています。メンテナンスされている Node 17 のベースイメージがそれらを解決します。これは CVSS スコアの一覧表ではなく、ランタイムインサイトが優先順位付けを行っているということです。このプランは最悪の SLA 違反の重大度でランク付けし、すでに修正が公開されている検出結果に限定します。そのため、キューにはチームが今日リリースできる作業だけが含まれます。他のプランは異なるランタイムシグナルに依拠します。Reduce Exposure Time はリスクスコア、検出結果数、経過期間でランク付けし、本記事で後述するヘッドレスのクエリは、CISA KEV を確認した上で EPSS の悪用確率でランク付けします。
この基盤となるシグナルについては正確に述べる価値があります。今では多くのツールがリーチャビリティを謳っているためです。その大半が意味しているのは静的な到達可能性、つまり依存関係グラフのどこかに理論上存在する経路です。Sysdig のランタイム到達可能性（runtime reachability）はより厳格です。脆弱性のあるパッケージが今まさに実行中のプロセスにロードされていることを指し、さらにワークロードの露出度を別のシグナルとして重ねて評価します。到達され得るものと、実際に動いているものの違いです。その規模のバックログを 1 件の実行可能な修正まで辿る作業は、通常であればエンジニアの 1 日を丸ごと消費します。エージェントはそれを済ませた状態で現れました。
人間が制御点であり続ける
エージェントは修正チケット（概要、影響、推奨される修正）を起草し、たったひとつだけ質問します。これは誰の担当か、と。そして人間がレビューし、Approve をクリックします。そのクリックは、自律性に関する議論のすべてを 1 つの UI 要素で解決します。エージェントが分析を行い、人間が変更を承認するのです。
「なぜ」をすべて備えた実際のチケット
承認から数秒後には、それは実際の Jira チケット DEJI-342 になります。担当者に割り当てられ、generated-by-sysdig というラベルが付き、完全な根拠を備えています。なぜこのジョブが重要なのか、SLA の計算、そして修正の提案です。SLA の追跡は自動的に開始されます。ここにあるものはモックアップではありません。デモ環境が接続されている実際の Jira インスタンスです。
同じ頭脳を、AI アシスタント内でヘッドレスに
ここまではコンソールの話です。しかし、エンジニアはますますコードエディターや AI アシスタントの中で過ごすようになっているため、Sysdig は同じ機能を Sysdig MCP サーバー（GitHub でオープンソース公開）を通じてヘッドレスで提供します。
それに伴って 3 つのものが移動します。これらを区別しておく価値があります。ほとんどの「エージェント型」ツールは最初のものしか備えていないためです。サーバーはアクセスです。ランタイムデータをアシスタントに公開します。スキルはノウハウです。検出結果を実際の悪用可能性でランク付けし、6 桁のバックログを 1 件の修正まで辿り、新たな Critical を持ち込まずに安全なアップグレード経路を導き出す、Sysdig の 10 年分の専門知識です。そしてエージェント型ワークフローは、尋ねられるのを待たない部分です。コンソールと同じ常設プラン、SLA Compliance と Reduce Exposure Time が動き続け、バックログをランク付けし続けるため、エンジニアが一言入力する前に修正はすでに浮かび上がっています。
それが違いです。誰でもいくつかの 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 件の CVE-2026-32740 libheif 変種を含む 5 件すべてが、ECS Fargate 上の 1 つの nginx サービスに存在し、CISA KEV を確認した上で EPSS の悪用確率でランク付けされています。同じプラン、同じデータ、異なるインターフェース。それこそが要点です。
ガードレールは明示的
修正に同意すると、エージェントは Sysdig Remediate skill を起動します。実行前に、自らの行動ルールを宣言します。ここが「エージェント型」が信頼を得るか得ないかの分かれ目です。
- 実行すること：イメージに影響する Critical および High の CVE を取得し、チェーン分析を通じて安全な修正バージョンを導き出し（新たな Critical を持ち込むアップグレードは除外）、パッチを起草し、追跡チケットを更新します。
- 実行しないこと：リポジトリへのコミットやプッシュ、認証情報のログ出力や表示、そして明示的な承認なしの変更は行いません。前提条件が欠けている場合はそれを検出し、どう進めるかを尋ねます。プルリクエストか、ローカルのパッチファイルかです。
ワークフローのビフォーとアフター
経済性も同じ曲線を描きますが、注目すべき数字は上限です。人間のみのチームは年間 925 件程度の調査で頭打ちになります。制約がアナリストの工数であり、その数には限りがあるためです。エージェント型ワークフローは年間 10,000 件を超えて稼働し、制約は人員ではなくなります。コストの計算も有利です。当社の社内分析では、人間のみによる調査が約 135 ドル、エージェント型ワークフローは AI のトークンコストを含めて約 16 ドルで、88% の削減となります。ただし、コストの数字は上司に持っていく弾薬です。チームが守れる範囲を実際に変えるのは、上限のほうです。
数値は Sysdig の社内分析によるものです。環境や単価によって異なります。
より大きな変化：ひとつの頭脳、あらゆるインターフェース
ここで取り上げた具体的な機能は脆弱性管理です。しかし、より大きな話はアーキテクチャーに関するものです。同じエージェント、同じプラン、同じランタイムデータが、人間のためには Sysdig UI で、AI アシスタントのためにはヘッドレスなツールとして利用できます。ひとつの頭脳を、あらゆるインターフェースから。これはエージェント型クラウドセキュリティと Sysdig Sageで示したのと同じ方向性であり、真の防御はランタイムであり、単なるポスチャーではない理由でもあります。エージェントの能力は、推論の対象となるデータの質を超えることはなく、今この瞬間に何が真実かを語れるデータはランタイムだけです。
そして、エージェントの能力はそれを動かす専門知識の質を超えることもありません。MCP の配線部分は、誰でもコピーできる最低条件です。どの検出結果が実際に重要なのかを知る Sysdig の 10 年分の蓄積を、実作業を行うスキルに組み込んだもの。これはコピーできません。
攻撃者はマシンの速度へと移行しました。555 ベンチマークは、検知とレスポンスに対する当社の答えでした。エージェント型の脆弱性管理は、バックログに対する同じ答えです。検出結果が届く速度で修正し、何をリリースするかは人間が決めるのです。
バックログを担当されている方は、お客様の検出結果に対して動かしてみてください。デモは当社の環境ではなく、お客様の環境で行います。ヘッドレスのワークフローから始めたい場合は、Sysdig MCP サーバーが GitHub でオープンソース公開されています。
よくあるご質問
エージェント型の脆弱性管理とは何ですか？
SLA 準拠のようにお客様が設定した目標に向かって、ライブのランタイムデータ上で動作する AI エージェントです。継続的にトリアージし、最も多くのリスクを削減する修正をランク付けし、修正案を起草し、すべての変更を人間の承認を経て実行します。
エージェントは承認なしに変更を行いますか？
いいえ。UI では人間が各チケットを承認します。ヘッドレスでは、すべてのツール呼び出しに権限のスコープが設定されており、修正スキルはコミットやプッシュを行わず、認証情報にも触れません。
CVSS ベースの優先順位付けとはどう違うのですか？
CVSS は理論上の重大度です。エージェントは、実際にロードされ、露出し、悪用可能なものでランク付けします（EPSS の確率、KEV の該当状況、そしてランタイム到達可能性、つまりグラフ上に存在するだけでなく、実行中のプロセスにコードがロードされていること）。そのうえで、最も多くを解決する 1 件の修正で検出結果をグループ化します。
Claude や他のアシスタントから利用できますか？
はい。UI を支えているものと同じエージェント、プラン、ランタイムデータが、Sysdig MCP サーバーを通じて MCP 対応のあらゆるアシスタントに公開されます。そのため、誰かがコンソールにログインしているかどうかにかかわらず、エージェント型ワークフローは動き続けます。これはチャットボットの後付けではありません。チームが使っているものと同じ頭脳に、エンジニアがすでに働いている場所からアクセスできるということです。
他の MCP サーバーとはどう違うのですか？
MCP サーバー単体はアクセスです。データをアシスタントに公開します。Sysdig は 3 つのレイヤーを提供します。サーバーがアクセスを提供します。スキルがノウハウを提供します。検出結果を実際の悪用可能性でランク付けし、6 桁のバックログを 1 件の修正まで辿り、新たな Critical を持ち込まずに安全なアップグレード経路を導き出す、Sysdig の 10 年分の専門知識です。エージェント型ワークフローは、尋ねられるのを待たないレイヤーです。同じ常設プランが動き続け、バックログをランク付けし続けるため、エンジニアが一言入力する前に修正はすでに浮かび上がっています。配線はアクセスをもたらします。スキルは良い答えをもたらします。エージェント型ワークフローとは、答えがすでに待っているという意味です。
当社の検出結果ではなく、お客様の検出結果でご確認ください。
今すぐ Sysdig Secure AI のデモを依頼する