Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年7月16日に Crystal Morinが投稿したブログ (https://www.sysdig.com/blog/the-cisos-guide-to-headless-cloud-security) を元に日本語に翻訳・再構成した内容となっております。
セキュリティアーキテクチャーに、まだアナリストのマジック・クアドラントには載っていない変化が起きています。しかもそれはベンダーから生まれたものではありません。この変化は、ヘルスケア、テクノロジー、製造、運輸といった、皆さんと同じような業界の組織——AI 支援ツールを限界まで使い込み、壁にぶつかったセキュリティチーム——から生まれました。
その壁とは、UI そのものです。
その壁の向こう側には、根本的に異なるアーキテクチャーがあります。エンジニア、開発者、セキュリティ担当者が全員同じ CLI を使うアーキテクチャーです。人間がブラウザを開く前にエージェントがトリアージと修正対応を済ませ、取締役会向けの指標は手作業でエクスポートするのではなくクエリ一つで得られる——そんな世界です。目指すのは、目に見えず、プログラム可能で、勝てるだけの速さを備えたセキュリティです。
その仕組みを説明します。
敵はすでに動いている
私がほぼすべての会話で最初に取り上げるところ、すなわち脅威の状況から始めましょう。
攻撃者はエージェント型へと移行しました。単に「AI 支援」という意味ではなく、人間のオペレーターがリアルタイムで判断を下すことなく、探索し、悪用し、ピボットする真に自律的なエージェントを指します。いまや皆さんが防御しなければならないのは、これなのです。
Sysdig 脅威リサーチチーム（TRT）にはその証拠もあります。ある攻撃では、エージェント型脅威アクター（ATA）が、人間のオペレーターのように事前に用意されたプレイブックを実行するのではなく、リアルタイムでアクションを実行しました。1 時間足らずのうちに、ATA は環境内を 4 回ピボットし、内部データベース全体の内容を持ち出しました。別の攻撃では、ATA がコンテナエスケープを実行——これは熟練した人間の攻撃者でさえめったに試みないものです——した上で、Kubernetes の認証情報を再生（リプレイ）してクラスターのシークレットストア全体をダンプしました。さらに TRT は、初めて文書化されたエージェント型ランサムウェアの事例だと評価するもの、JADEPUFFER と名付けられた事案も確認しました。これは大規模言語モデル（LLM）によって端から端まで駆動された、完全な恐喝オペレーションでした。
残りの物語は、3 つの数字が物語っています。これらの数字を合わせると、ほとんどの組織が運用しているセキュリティモデルが構造的に破綻している理由が見えてきます。
10 分：初期アクセスからクラウド侵害までの時間です。データベースが持ち出されるにせよ、認証情報が奪われるにせよ、クラウド攻撃が起きるまでにかかる平均時間がこれです。最近では、わずか3 分で認証情報が消えた例も目にしています。
10 時間：脆弱性の公開から実際の武器化までの時間です。この数字は、見た目以上に不気味です。これは CVE 番号が付与された時点ではなく、GitHub Security Advisory（GHSA）が公開された瞬間からの時間なのです。MITRE がレビューする前、NIST がカタログ化する前、そしておそらくは皆さんの脆弱性スキャナーがその存在を知る前の時間です。脅威アクターは GitHub を監視し、LLM を使ってほぼ即座にエクスプロイトを書いています。私たちは4 時間未満で行われた事例や、非常に人気のある Langflow フレームワークに対して20 時間以内に実際に悪用された事例を確認しました。
30 分：これはまったくの当て推量、楽観的な予想にすぎません。調子の良い日に、皆さんの SOC が真陽性のアラートをトリアージするのに実際どれくらいかかるでしょうか。ここに皆さん自身の数字を当てはめてみてください。
多くの組織が、いまだ 10 分未満で脅威に対処できておらず、数時間以内に脆弱性を発見・修正できてもいない、と考えて差し支えないでしょう。計算してみれば、ほとんどのセキュリティチームは毎回負けています。それは彼らに能力がないからではなく、構造的な時間軸のミスマッチです。この課題を上回るために人を増やしたりツールを追加したりすることはできません。必要なのはアーキテクチャの変革です。
解決すべき問題
ダッシュボードやポータルへのログインは、そのたびにレイテンシを生みます。アナリストがアラートを調査するためにページを開くたびに、任務は一時停止します。彼らはコンテキストを切り替え、状況を把握し、関連データを見つけ、判断を下し、実行しなければなりません。これが、検知から解決までのギャップ（detection-resolution gap）——脅威が発見された瞬間と、それが実際に無力化される瞬間との隔たり——を広げているのです。10 分未満の侵害ウィンドウでは、人間が初めてアラートに目を向けたときには、そのプロセスはすでに終わってしまっています。
そうしたダッシュボード内の AI 支援機能は本物であり、確かに価値を加えます。コパイロット、チャットボット、自動トリアージ——いずれも状況を前進させ、遅延を減らします。しかし、アーキテクチャー上の現実はこうです。それらの機能はすべて、依然としてダッシュボードの中に存在しています。情報は依然としてポータルに縛られ、それに基づいて行動するには依然として人間がログインして動き回らなければならないのです。
Headless Cloud Security とは？
「ヘッドレス（Headless）」とは、単にソフトウェアのバックエンドが UI レイヤーから切り離されている状態を指す言葉です。これにより、機能上の制約という設計上の縛りが取り除かれます。ヘッドレスセキュリティとは、UI のない「セキュリティ（security）」のことです（"security" から "ui" を抜くと "secrty"……お分かりでしょうか？）。
検知エンジン、ポリシーエンジン、リスクスコアリング——それらすべてが API ファーストのプリミティブとして公開されます。AI エージェントは、誰もブラウザを開くことなくクエリを実行し、判断し、行動できます。対応の連鎖は次のように変わります。
アラート → 人間によるレビュー → 手動対応
から
アラート → エージェントによるトリアージ → 自動修正対応
Headless Cloud Security にはアクティブなランタイムテレメトリが必要
Headless Cloud Security が機能するための基盤要件の一つは、データレイヤーにあります。古くなったデータの上で自律的な防御を運用することはできません。
従来のロギングが実際には何であるかを考えてみましょう。プロセスが生成されたり、ネットワーク接続が開かれたり、ファイルが変更されたりすると、そのイベントはログに書き込まれます。そのログはコレクターに拾われ、コレクターはそれをパイプラインへ転送し、パイプラインはそれを正規化・エンリッチし、最終的に SIEM に到達してアラートをトリガーします。そのアラートはおそらく、人間が優先順位順に管理する SOC のキューに入ります。
各ハンドオフはレイテンシをもたらし、10 分未満の侵害ウィンドウでは、そのレイテンシは致命的になり得ます。これが「事後ログ（post-mortem logging）」が実際に意味するところです。皆さんは環境で起きたことを読んでいるのであって、それを見ているのではありません。SIEM は何が起きたかの記録であって、検知システムではないのです。
さらに、今日のエージェント型攻撃は、攻撃の「実行者」がマシン速度で動く AI エージェントである場合、これをいっそう悪化させます。従来のロギングには LLM が生成したアクティビティという概念がそもそも存在せず、SIEM はアイデンティティのコンテキストの追跡をすぐに見失います。しかし適切なコンテキストがあれば、アクティビティのパターンや行動の痕跡から AI の指紋を特定する方法があります。
必要なのは、アクティブなランタイムテレメトリ、すなわちライブなシステム状態です。これには、いまメモリ上で何が実行されているか、たった今どのネットワーク接続が開かれたか、どのプロセスが生成されたか、そしてそれらが何をしているかが含まれます。これこそが、根拠はあっても遅れた推測ではなく、リアルタイムで確定的な判断を下すためのコンテキストを AI エージェントに与えるデータレイヤーなのです。
これをインラインかつ間に合う形で機能させるために、セキュリティは呼び出し可能なスキルとして AI エージェントに提供されます。スキルとは、ログアーカイブではなく、環境のライブ状態にクエリを実行する関数です。エージェントは、過去に何が起きたかではなく、いま何が起きているかについて質問し、答えを得られる必要があります。
Headless Cloud Security の 3 本の柱
1. エージェント駆動のオペレーション
AI コーディングエージェントが、日々のセキュリティプロセスの主要なオペレーターとなり、皆さんのチームはオーケストレーターの座へと移ります。エージェントは継続的な監視、検知、対応、適応を担い、マシン速度で実行します。人間はエージェントに対して意図とガードレールを設定します。
2. MCP サーバー、API、専門家が作り込んだスキル
これは、すべてを現実にする技術レイヤーです。セキュリティのデータと機能は、MCP サーバーと API を通じてアクセスされます。専門知識はスキルとしてパッケージ化され、セキュリティワークフローのロジックをエンコードします。これによって、汎用のコーディングエージェントを皆さんの主要なセキュリティツールとして動作させられるようになります。しかも、それは組織内のすべての開発者やエンジニアがおそらく使っているのと同じツール、同じ CLI レベルのものです。ハーネスは一つ、データレイヤーも一つ、そして信頼できる唯一の情報源（source of truth）も同じです。基盤となるデータが優れ、スキルがよく作り込まれているほど、下流のあらゆるエージェントのアクションはより効果的になります。
3. 画一的なダッシュボードではなく、パーソナライズされたワークフロー
UI の制約を取り除くと、セキュリティを皆さんのビジネス、チーム構成、既存のツールに合わせて仕立てられるようになります。エンジニアは、必要なものを見つけるためにベンダーの情報アーキテクチャをたどる必要がありません。彼らは CLI から、IDE から、あるいは CI/CD パイプラインから作業し、セキュリティデータは彼らが選んだ任意の形で彼らのもとに届きます。また、機能豊富な UI を探し回るのをやめて、データの品質や API のセキュリティと堅牢性を評価し始めることができます。
Sysdig がここに至るまで
Claude Code が登場したとき、何かが変わりました。初めて、コーディングエージェントがセキュリティツールとネイティブに——ブラウザを通してではなく、API とスキルを通じて——やり取りできるようになったのです。私たちの顧客のエンジニアたちは、CLI からセキュリティを自らのワークフローに組み込み始めました。これは 10 年前の CISO なら夢に見ることしかできなかったことです。私たちがそう設計したからではなく、彼らがセキュリティの向かうべき先を示してくれたからこそ、私たちはそこへ導くのを助けるアーキテクチャーを構築しました。私たちは、彼らがすでに有効だと証明していたことを形式化したのです。
UI はほぼ一夜にして任意のものとなり、私たちの顧客が先に動きました。そのパターンを目にした私たちは、すべてを API として公開するという、意図的なアーキテクチャー上の決断を下しました。
- ランタイム検知 API：ポータルへのログインなしで、ライブなコンテナおよびワークロードの脅威にクエリを実行
- ポリシー・アズ・コード・エンジン：Falco ルールとセキュリティポリシーはプログラム可能で、CI/CD パイプラインからデプロイ可能
- MCP サーバー連携：Sysdig Secure は MCP ツールとして公開され、Claude Code が直接クエリ、修正対応、監査を実行可能
- インベントリおよびリスク API：資産インベントリ全体、CVE の露出、アイデンティティリスクをリアルタイムでクエリ可能
- イベントおよびアラートのストリーミング：エージェントのコンシューマーへプッシュ型でアラートを配信。待機も確認もダッシュボードも不要
エンジニアはいまや、CLI から、Claude Code から、あるいは CI/CD パイプラインからセキュリティを実行できます。スキルはほぼ毎週追加されており、Headless Cloud Security の提供価値は追加のたびに複利的に高まっています。そして、一晩で完全にヘッドレス、あるいはエージェントネイティブへ移行する準備ができていない組織のために、UI も依然として存在します。UI がなくなることはありません。
これはパラダイムシフトであり、それが一度にすべて起こるわけではなく、組織によってはまったく起こらないこともあると私たちは分かっています。ほとんどのセキュリティチームは、しばらくの間、両方のモデルを並行して運用するでしょう——一部はヘッドレスのワークフロー、一部はポータルベース——そしてチームが自信を深めるにつれて、徐々にバランスを移していくはずです。アーキテクチャの移行とは、こうして進むものです。
CISO が Headless Cloud Security から得られる 6 つのメリット
アーキテクチャーのアップグレードは、ほんの始まりにすぎません。ヘッドレスは、皆さんのセキュリティチームがおそらくずっと望んでいた、あるいは実現しようとしてきた能力も解き放ちます。移行を後押しする 6 つの論拠をご紹介します。
- コンテキストスイッチをなくす。現代の攻撃の速度を考えると、セキュリティインテリジェンスはエンジニアがすでに働いている場所に存在する必要があります。ログインして操作する別個のポータルは、一つひとつが、セキュリティプログラムの時間・対応速度・有効性に課される生産性の税金です。何を購入し、それをどう展開するかは、CISO の決断事項です。
- プログラム可能なガードレール。セキュリティをコードとして扱うということは、組織内の他のチームが許可を求めてチケットを起票しなくなることを意味します。その代わり、彼らはセキュリティチームが事前に定義した自動化された境界の内側で作業します。コンプライアンスに違反するデプロイは API レイヤーで即座にブロックされ、2 週間もレビューキューに放置されることはありません。
- 確定的な信頼境界。破壊する力を与えることなく、エージェントに修正対応する力を与えるにはどうすればよいでしょうか。その答えは「エージェントを使わない」ではありません。答えは、エージェントが上書きできないハードコードされたスキルの境界——スコープを限定したアクセス、変更不可能なポリシー、完全な監査証跡など——です。これはエージェントの問題ではなくプラットフォームの問題であり、皆さんはこの点でベンダーを評価する必要があります。
- ペルソナに対応したインテリジェンス。CISO と SOC アナリストは、同じデータから異なる情報を必要とします。今日、両者が同じダッシュボードを開くと、同じものが見えてしまい、どちらにとっても役に立ちません。ヘッドレスモデルでは、要求に応じて、同じデータが異なる形で表示されます。皆さんには取締役会レベルのリスク指標を、アナリストにはトリアージのコンテキストを、という具合にです。
- 取締役会向けの指標を、オンデマンドで。MTTR、本番環境における重大な脆弱性の推移、リスクポスチャーの傾向——これらはいずれも、ほとんどの UI ではネイティブに表示されません。データは存在しますが、それを取締役会用の資料に載る形式へ抽出するには手作業が必要です。API でアクセスできるセキュリティデータがあれば、必要なものだけを、必要な形式で、クエリして取り出せます。
- 時間とともに賢くなるセキュリティ。あらゆるクエリ、検知、修正対応が、皆さんの環境をより精緻にモデル化するためのフィードバックとなります。セキュリティは画一的なものであることをやめ、皆さんのスタックを——リスク許容度、チームのパターン、ベースラインを——理解し始めます。
オペレーターからオーケストレーターへ
今日、セキュリティチームはツールを操作し、ポータルにログインしています。皆さんが優れた UI を備えた製品を購入するのは、UI こそがチームがその機能とやり取りする手段だからです。
ヘッドレスモデルでは、皆さんのチームはセキュリティガバナンスをオーケストレーションします。エンジニアは自分の CLI からセキュリティを利用します。エージェントがトリアージと修正対応を担い、エスカレーションのポリシーは皆さんが定義するものです。皆さんが購入するのは、優れたデータと安全な API を備えたツールです。なぜなら、それこそがエージェントが機能するために必要なものだからです。
エージェント型セキュリティにおける人間の制御には 3 つの異なるレベルがあり、ほとんどのプログラムは状況に応じてその 3 つすべてを使い分けることになります。
- Human in the loop（人間がループ内）：エージェントは検知し、調査し、修正対応を準備しますが、実行前に人間の承認を待ちます。このモデルは、IAM ポリシーの変更のようなリスクの高い変更、人間の判断を要する新種の攻撃パターン、あるいは監査証跡に文書化された人間の意思決定を必要とするコンプライアンス環境に適しています。
- Human on the loop（人間がループ上）：エージェントは自律的に検知し、調査し、修正対応を行います。そして人間はそのアクションを能動的に監督し、リアルタイムで介入・上書き・実行停止する能力を保持します。このモデルは、速度が重要でありながら、エージェントの判断の境界に対する自信を築いている段階で、なお運用や環境に目を配っておきたいワークフローに適しています。SOC アナリストは、ラテラルムーブメントのパターンの最中にエージェントが予期しない動きをした場合に調査を止めたり、コンテナの隔離や認証情報の失効といった封じ込めのシーケンスの最中にエージェントを止めたりできます。
- Human out of the loop（人間がループ外）：エージェントは自律的に検知し、検証し、修正対応し、報告します。皆さんは事後にサマリーを目にします。このモデルは、クリプトマイナー、ポリシードリフトの自動ロールバック、既知の攻撃者インフラのブロックなど、高い確信度を持つ既知の悪性インジケーターに適しています。エージェントのアクションに対する確信度が高く、行動できるウィンドウが数秒しかないため、その連鎖に人間は介在しません。
これらのモデルはいずれも、Headless Cloud Security なしに、ベンダーの UI の中でさえ実行できます。ヘッドレスが皆さんに与えるのはポータビリティであり、これらのモデルを皆さん自身のハーネスの中で実行できるようにします。エスカレーションのポリシーが設定内容であり、ヘッドレスのインフラこそが、それを皆さんのものにするものです。すべてのアラートを手作業で追いかけることは、キャリアではありません。ガードレールを定義し、信頼境界を設定し、マシンによる攻撃に対してマシン速度で動作するエージェントの群れを監督すること——それこそが、存在すべき仕事なのです。
まとめ
Headless Cloud Security は、単なる新しいツールではありません。実のところ、ツールですらまったくありません。これは、人間はもはや脅威が到来する速度にはついていけないという認識であり、そして正しい対応とは、より速い人間を用意することでも、さらに多くの AI を積み重ねることでもなく、一歩引くことだという認識です。それは、よりシンプルで、異なるアーキテクチャーなのです。
セキュリティツールのオペレーターから、セキュリティインテリジェンスのオーケストレーターへの移行は、より小さな仕事になるのではなく、セキュリティがずっと到達しようとしてきた仕事そのものです。
これからは、あらゆるベンダーを評価する際に携えるべき問いが一つあります。それは「このツールは、完全で文書化された API を公開しているか？」です。
その答えが「いいえ」なら、皆さんはレガシーなアーキテクチャを買っていることになります。どれほど多くの AI 機能を備えていようと、コパイロットがどれほど優れていようと、関係ありません。インテリジェンスが依然として UI の背後に閉じ込められているなら、アーキテクチャは何も変わっていないのです。
Sysdig の MCP サーバーと Headless Cloud Security の機能について、詳しくはこちらをご覧ください。