Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本稿は、2026年5月18日にBlair Howardが投稿したブログ(How to create custom cloud security controls faster with headless cloud security)を元に日本語に翻訳・再構成した内容となっております。
本記事では、Sysdig Headless Cloud Securityのスキルを使って、自然言語で記述したセキュリティ要件からCSPMのカスタムコントロール（Regoで記述したポリシー）を作成・検証し、Terraformでデプロイする方法を紹介します。ポリシーの作成と検証はAIエージェントが担い、コントロールの内容の確認と、環境への適用の承認は人間が行います。
- Regoによるポリシー作成が、なぜカスタムコントロール運用のボトルネックになるのか
- 従来のポリシー作成プロセスと、Headless Cloud Securityを利用した場合の違い（Before／After）
- スキルが自律的に進める工程と、人間が確認・承認する工程
Sysdigなどの最新のクラウドセキュリティポスチャ管理（CSPM）プラットフォームは、設定ミスやリスク、そして環境がCISなどのベンチマークにどの程度準拠しているかについて、強力な可視性を提供します。
Sysdigはヘッドレスクラウドセキュリティをいち早く導入し、CSPMのカスタムコントロールなどの機能をユーザーインターフェイスの枠を越えて、チームがすでに業務を行っているワークフローへと拡張しています。
多くの組織にとっての課題は、リスクを特定することではありません。本当の課題は、セキュリティ要件をいかに迅速かつ一貫性をもって環境全体に運用化するかという点にあります。
この課題は、特定のコンプライアンス要件や独自要件、運用要件に紐づいたカスタムコントロールを構築する必要が生じたときに、特に顕著になります。こうした要件を実際に適用可能なポリシーへと落とし込むには、ベンチマークの記述内容を解釈し、複数の条件を一つのルールにまとめ、その論理を検証したうえで、コントロールをインフラのワークフローに統合する作業が求められます。
各ステップで遅延が発生し、運用負荷が増大し、深いポリシー知識を持つ一部の担当者に依存する状況を生み出してしまいます。環境が拡大するにつれて、カスタムコントロール全体での一貫性を維持することは、さらに難しくなっていきます。
動画内のAIへの指示は日本語でも入力可能です。実際の運用イメージをご覧になりたい方は、デモをご依頼ください。
policy-as-code がボトルネックになる理由
Regoなどの policy-as-code のフレームワークは、強力なカスタムコントロールを作成するために必要な柔軟性と精度を備えています。しかし、セキュリティ要件をポリシーへと変換する作業には、依然として専門知識と時間が必要です。
たとえばアクセス条件と設定状態、除外条件を組み合わせるような比較的単純な要件であっても、すぐに詳細なポリシー定義へと膨らみ、デプロイ前に入念な検証が必要になります。
課題は言語そのものの能力ではなく、ポリシーを大規模に一貫して実装するために必要な運用の手間にあります。ここがカスタムコントロールのワークフローを停滞させる要因であり、組織が要件から適用までを進めるスピードを制限してしまうのです。
ヘッドレスクラウドセキュリティによるカスタムクラウドセキュリティコントロール
ヘッドレスクラウドセキュリティは、API、自動化、Sysdigのエージェントスキルを通じて機能を提供することで、固定的なユーザーインターフェイスの枠を越えてセキュリティを拡張します。SaaSとしての利用体験を置き換えるのではなく、ターミナルから自動化パイプラインに至るまで、チームがすでに業務を行っているワークフローや環境にセキュリティを直接組み込めるようにします。
カスタムコントロールについては、これにより手作業によるポリシー作成から、意図に基づくガイド付きのワークフローへと体験が変わります。アナリストは、コントロールに何を検知させ、何を強制させたいのかを自然言語で記述するだけで、カスタムコントロールスキルがその意図を検証済みのポリシーロジックへと変換るのを支援します。
これにより、Regoの高度な専門知識への依存を減らしつつ、コントロール作成を効率化し、環境全体での一貫性を高めることができます。ポリシーを生成する前に、スキルが条件、除外、重大度、適用の意図といった重要な項目の候補を示し、アナリストがその内容を確認します。
検証後のポリシーは、Terraformのコードとして自動的に生成されます。アナリストが承認すると、インフラの管理にすでに使われているインフラ・アズ・コードのワークフローを通じてデプロイされるため、同じ自動化プロセスを使って、カスタムコントロールを運用できるようになります。
結果として、カスタムコントロールの作成は、より迅速かつスケーラブルなアプローチになります。手作業のポリシー開発と分断されたワークフローに頼るのではなく、繰り返し実行可能な自動化を通じて、コントロールの作成・検証・デプロイを行えるようになり、不要な複雑さを増やすことなく運用効率を向上させることができます。
従来のポリシー作成プロセスとの違い（Before／After）
カスタムコントロールを作成する工程ごとに、従来の進め方と、Headless Cloud Securityのスキルを利用した場合の進め方を比べると、次のようになります。
スキルが担う工程と、人間が確認・承認する工程
Headless Cloud Securityのスキルは、ポリシーの作成と検証を自律的に進めますが、コントロールの内容を決めることと、環境に変更を加えることは人間が判断します。カスタムコントロールを作成する流れは、次の6つの工程に分かれます。
スキルが自律的に進める工程（2・4・5）は、いずれもSysdigの環境を変更しない作業です。スキルは、SysdigのAPIを通じてポスチャのリソースを直接作成・変更・削除することはなく、変更はすべて、ユーザーが管理するTerraformのファイルを通じて行われます。そのため、カスタムコントロールの追加や変更も、インフラの変更と同じように、変更内容の確認や履歴の管理を行えます。
調査や分析はAIエージェントが自律的に進め、環境に影響を与える操作は人間が承認する、という役割分担は、Headless Cloud Security全体に共通する考え方です。AIエージェントにどこまで任せ、どこで人間が判断するかについては、「ヘッドレスクラウドセキュリティとは？【完全ガイド】」で詳しく解説しています。
カスタムコントロール運用の加速
カスタムコントロールは、セキュリティ要件を環境全体で実際に機能させるための要となるものです。Sysdigスキルを通じてコントロール作成をヘッドレスでプログラマブルなワークフローへと拡張することにより、組織はポリシーの作成と適用に従来伴っていた運用負荷を軽減できます。
シニアメンバーが手作業でポリシーを開発したり、分断されたワークフローに頼ったりするのではなく、繰り返し実行可能な自動化とインフラ・アズ・コードのプラクティスを通じて、カスタムコントロールをより速く作成・検証・デプロイできるようになります。これにより、環境間での一貫性を高め、適用をより効率的にスケールさせ、セキュリティ要件が運用可能なコントロールへと結実するまでのスピードを加速できます。Headless Cloud Securityのスキルは、既存のSysdigのお客様にご利用いただけます。セキュリティリーダーの方で、エンジニアがAIを活用してセキュリティスタックの周辺で開発を始めているのであれば、ぜひデモをリクエストし、実際の動作をご覧ください。