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