CWPPとは？ワークロード保護の仕組みとCSPMとの違い・導入判断を実装視点で解説

CSPMを入れて設定不備は潰した。それでも、稼働中のコンテナの中で何のプロセスが起動したかは見えないままです。この空白を埋める道具がCWPPにあたります。ただし、エージェントを配れば守りが完成するわけではありません。この記事では、CWPPの定義と保護対象、収集方式の分かれ目、VM・コンテナ・サーバーレスで変わる打ち手、主要製品の実装差、採用と見送りの判断基準を実装者目線で整理しました。

まとめ：CWPPが守る範囲と導入判断の分かれ目

先に結論を置きます。CWPP（Cloud Workload Protection Platform）は、クラウド上で実際に動いているサーバー・VM・コンテナ・サーバーレス関数の内部を実行時に観測し、脆弱性と不審な挙動を検出して止めるための仕組みです。クラウドの設定を外側から点検するCSPMとは、見ている層がそもそも違います。

収集方式は2つ。ワークロードにエージェントを常駐させてカーネルのイベントを拾う方式と、ディスクのスナップショットを経由して外から調べるエージェントレス方式です。実務での着地点は、エージェントレスを土台に敷き、外部トラフィックを直接受ける層だけエージェントを載せる構成になります。

判断の順序はこう置いてください。まずCSPMで設定不備という一番安い穴を塞ぐ。そのうえで、OS以上を自社で保守するワークロードが本番で常時動いていて、なおかつ検知を受けて動く当番がいる場合にCWPPを足す。アラートを受け取る人がいない段階での導入は、通知が積み上がったまま誰も見ない画面を1つ増やすだけの結果に終わります。

CWPPの定義と保護対象｜実行中のワークロード内部を守る仕組みの境界

まず、この製品カテゴリが何を対象にしているのかを揃えます。「ワークロード」という語の指す範囲が、書き手によって伸び縮みするためです。

CWPPの定義とクラウドワークロードとして扱われる4つの実行形態

CWPPは、Gartnerが整理した製品カテゴリ名で、クラウド環境で稼働するワークロードの内部を保護対象とするセキュリティ基盤を指します。日本語では「クラウドワークロード保護プラットフォーム」と訳されます。

ここでいうワークロードは、実行形態で4つに分かれます。オンプレミスや専有環境の物理サーバー、IaaS上の仮想マシン、コンテナ、そしてサーバーレス関数。この4つを1つの管理画面で扱えることが、個別のサーバー用セキュリティ製品との差になっています。

保護の中身は、脆弱性の検出、マルウェア検知、ファイルの改ざん検知、プロセスとネットワークの挙動監視、そしてワークロード間の通信制御。「そのワークロードが何を積んでいるか」と「いま何をしているか」の両方を見る作りです。IAM権限設計やストレージの公開設定といったコントロールプレーン側は守備範囲から外れます。

責任共有モデルでCWPPが受け持つ利用者側の守備範囲と線引きの基準

どこまでを自分で守るのかは、責任共有モデルの分界点で決まります。IaaSでVMを立てた場合、ハイパーバイザーから下はクラウド事業者、ゲストOSから上は利用者の責任です。この「OSから上」がCWPPの主戦場になります。

コンテナを使うと分界が少し上がり、マネージドなKubernetesではコントロールプレーンが事業者側、ノードのOSとイメージの中身が利用者側になります。

サーバーレスまで進むとOSは触れず、関数のコードと依存ライブラリ、実行ロールの権限だけが持ち分として残ります。この線引きを先に確認しておくと、「エージェントを置けないから守れない」のか「守る対象が事業者側に移っている」のかを取り違えずに済みます。

CSPM・CNAPPとの守備範囲の違いと役割分担を決める判定軸

混同されやすい3語の関係を、見ている層で切り分けます。CSPMの指摘は「このバケットが公開されている」といった構成の問題。対してCWPPが返すのは「このコンテナで想定外のシェルが起動した」という実行中の事象です。

この2つとCIEMなどを1つの製品へ束ねたものがCNAPPで、単体ツールが乱立して起きるアラートの分断を解消する狙いを持ちます。統合基盤としてどう選ぶかはCNAPの構成要素と採用判断の整理にまとめました。本記事は、その中でワークロード保護を担う部分の実装に絞って進めます。

エージェント方式とエージェントレス方式｜収集の仕組みと使い分けの分岐点

CWPPの製品比較でいちばん効いてくるのが、この収集方式の違いです。機能一覧の見た目が似ていても、拾えるイベントが根本から変わります。

エージェント方式がカーネルイベントを捉える仕組みとeBPFの役割

エージェント方式は、OS上に常駐プロセスを置き、カーネルが処理するシステムコールを観測します。プロセスの起動、ファイルの読み書き、ソケットの接続。これらを逐次拾うため、侵入後に攻撃者が何をしたかの系列が残ります。

収集の実装は主に2通り。カーネルモジュールを読み込む古典的な方式と、eBPFでカーネル内に検証済みのプログラムを差し込む方式です。CNCFのgraduatedプロジェクトであるFalcoは、公式ドキュメント（2026-08-06時点）で既定ドライバをmodern eBPF probeとし、kernel moduleも選択肢として残す構成を採っています。旧世代のlegacy eBPF probeは2026年5月18日の更新で削除されました。

eBPFが選ばれる理由は運用側にあります。カーネルモジュールはカーネル更新のたびにビルドと再配布が必要になるのに対し、CO-RE方式のeBPFプログラムは幅広いカーネルへ同じバイナリで載せられる。カーネル側の仕組みそのものはeBPFがLinuxカーネルを拡張する仕組みで解説しています。

エージェントレス方式が見られる範囲と検知できない実行時の事象

エージェントレス方式は、ワークロードに何も入れません。クラウドのAPIでディスクのスナップショットを取得し、それを別の環境でマウントして中身を走査する作りです。導入の手間がほぼ発生せず、既存のVMを1台ずつ触らずに全台を対象にできます。

この方式で分かるのは、インストール済みパッケージの版数と既知脆弱性、ディスク上に置かれたシークレット、そしてマルウェアのシグネチャ一致。Microsoft Defender for Servers プラン2のエージェントレススキャンも、ソフトウェアインベントリ・脆弱性・マシンシークレット・マルウェアを対象とすると公式ドキュメントに明記されています（2026-08-06時点）。

見えないものもはっきりしています。スキャン間隔が数時間から1日単位である以上、検知から対応までの遅れが構造的に発生し、実行中の挙動そのものは記録に残りません。

エージェントレスを土台にエージェントを絞って載せる構成の基準

2つの方式は択一ではありません。実務で機能する組み方は、まずエージェントレスを全ワークロードへ広く敷き、資産の把握と脆弱性の棚卸しを済ませること。ここまでは、対象サーバーの担当者と調整せずに進められます。

そのうえでエージェントを載せる対象を絞ります。判断軸は3つ。外部トラフィックを直接受けるか、決済や個人情報など被害額の大きいデータを扱うか、侵害時に横移動の起点になり得る権限を持つか。どれか1つでも当てはまる層に絞れば、保守対象は全体の2〜3割に収まります。

ワークロード種別ごとの保護設計｜VM・コンテナ・サーバーレスの打ち手

同じCWPPを名乗る製品でも、対象がVMかコンテナかで実装の勘所が変わります。種別ごとに何を押さえるかを分けて見ていきます。

VMとサーバーで押さえるEDR・脆弱性評価・改ざん検知の3点と運用負荷

長期稼働するVMで先に入れるべきものは、優先順位をつけると3つです。1つ目はEDRによるプロセス挙動の検知、2つ目は稼働中のパッケージに対する脆弱性評価、3つ目が設定ファイルとバイナリの改ざん検知。この順で効き目が大きくなります。

3つ目のファイル整合性の監視は、導入前に運用コストを見積もってください。監視対象のパスを広く取ると、パッケージ更新やログローテーションのたびに変更が記録され、通知の大半が正常な変更で埋まります。まずは設定ディレクトリと起動スクリプトに絞る進め方が現実的です。

コンテナで効くイメージスキャンとランタイム検知の役割分担と配置

コンテナでは、検査のタイミングを2つに分けて考えます。ビルド時にイメージの中身を調べる静的な検査と、稼働中のコンテナの挙動を見る動的な検知。前者はCI上で完結し、後者はクラスタ側に常駐する仕組みが要ります。

ビルド時の検査は、パイプラインへ組み込めるスキャナで実施します。ベースイメージに含まれるOSパッケージと、アプリケーションの依存ライブラリの両方を対象にできるTrivyの使い方とインストール手順のようなツールが定番です。ここで既知CVEを落としておけば、ランタイム側の検知は「イメージに無かったはずのもの」に集中できます。

ランタイム側は、ノード上にDaemonSetとしてエージェントを配置する形が一般的。コンテナ内でのシェル起動、ホストのファイルシステムへのマウント、想定外の外部通信を検知します。拾いたいのは「イメージが正しくても起きる侵害の兆候」です。

サーバーレスでエージェントを置けない環境での代替手段とその限界

サーバーレス関数には常駐エージェントを置けません。実行環境が呼び出しのたびに立ち上がって消えるため、常駐という前提が成り立たない構造です。ここでの打ち手は3つに絞られます。

デプロイパッケージの依存関係スキャンで公開前に既知脆弱性を潰すこと、実行ロールの権限を関数ごとに絞って侵害時に届く範囲を狭めること、そしてクラウド側の脅威検知サービスで異常なAPI呼び出しを拾うことの3つです。

限界も認識しておいてください。関数の実行時間が数百ミリ秒で終わる以上、実行中の挙動を観測して止めるという発想自体が成立しにくい。サーバーレス中心の構成では、CWPPの導入よりも権限設計とデプロイ前検査へ投資したほうが、同じ予算で得られる守りが厚くなります。

主要製品の実装差｜Defender for ServersとGuardDutyの選定軸

製品ごとの機能表は似通って見えますが、有効化の単位と対応リソースの制約に差が出ます。公式ドキュメントで確認できる範囲を実測して並べます。

Defender for ServersのP1とP2の機能差と有効化スコープの制約

Microsoft Defender for Cloudのサーバー向けプランは2階層です。公式ドキュメント（2026-08-06時点）の機能表では、次のように分かれています。

選定で効くのは、機能差より有効化スコープの制約です。プラン1はサーバー単位で有効化と無効化ができるのに対し、プラン2はサブスクリプション単位でしか有効化できず、リソース単位では無効化のみ。段階導入を計画するなら、この非対称性を先に押さえておく必要があります。

もう1点、エージェント構成の前提が変わっています。Log AnalyticsエージェントとAzure Monitorエージェントはサポート対象から外れ、エージェントレススキャンとDefender for Endpoint統合が置き換える形になりました。AWSやGCPのマシンでファイル整合性の監視とOSベースライン評価を使うには、Azure Arcへのオンボードが条件になります。

GuardDuty Runtime Monitoringの対応リソースと導入形態

AWS側でワークロード内部を見る仕組みが、GuardDutyのRuntime Monitoringです。公式ドキュメント（2026-08-06時点）によると、対応リソースはEKS、Fargate上のECS、EC2の3種類。当初はEKS専用で、後からECSとEC2へ広がりました。

ここに例外が1つあります。AWS Fargateで動作するEKSクラスターは対象外という制約で、EKSをFargateプロファイルで運用している場合はランタイム側の可視化が得られません。設計段階で見落とすと、稼働後に構成変更を迫られます。

導入形態はセキュリティエージェントの管理方式で分かれ、GuardDutyへ導入と更新を任せる自動管理と、自前で入れる手動管理を選べます（FargateのECSのみ自動管理）。観測対象はファイルアクセス、プロセス実行、コマンドライン引数、ネットワーク接続。サービス全体の位置づけはAmazon GuardDutyの脅威検出の仕組みで確認できます。

FalcoをOSSで組む場合に自前で負う運用範囲と商用との分界点

商用製品を入れずに、OSSで揃える選択肢もあります。CNCFのgraduatedプロジェクトであるFalcoは、カーネルからsyscallを取得してルールエンジンへ流し、条件に一致したらアラートを出す3段構成。ルールはYAMLで記述するため、自社固有の禁止操作を条件として書き足せます。

自前で負う範囲は明確です。ルールのチューニング、アラート転送先の構築、検知結果の保管と検索、ドライバとカーネル版数の互換性追従。商用製品が価格に含めているのは、この4つと脅威情報の更新にあたります。

分界点はこう置いてください。SREかセキュリティ担当が専任でいて、既にログ基盤を運用しているならFalcoで足ります。担当が兼務で通知先も検索基盤もこれから作る段階なら、商用のマネージド機能を買ったほうが総コストは下がる。OSSの初期費用ゼロは、人件費を勘定に入れた時点で意味を失います。

CI/CDと運用への組み込み｜検知を止めずに回す設計と失敗パターン

導入して数か月で無効化される事例には、共通した進め方があります。通知の設計とロールアウトの順序で、結果が大きく変わります。

ビルド時スキャンとランタイム検知の重複を避ける通知設計の決め方

同じ脆弱性が、ビルド時のイメージスキャンとランタイムの脆弱性評価から二重に上がってくる。これが通知疲れの最初の入口になります。役割を分けてください。

ビルド時の検出は、開発チームへ即座に返してマージを止める種類の情報です。ランタイム側で同じCVEが出た場合は「修正済みのイメージが本番へ届いていない」というデプロイの問題を示します。宛先も緊急度も別物として扱ってください。

実装としては、ランタイム側の脆弱性通知を日次のダイジェストへ寄せ、即時通知はプロセス起動や外部通信といった挙動系に限定する。夜間に鳴る通知が、人を起こす価値のあるものだけに収束します。

検知ルールを本番へ広げる前に踏む段階的ロールアウトの手順と基準

全ワークロードへ一斉に配布する進め方は勧めません。次の順序で広げてください。

1. 検証環境の1サービスへ導入し、遮断せず記録のみのモードで2〜4週間動かす
2. 検知件数の上位ルールを洗い、正常な運用操作が起点のものを例外へ回す
3. 本番の外部公開層へ広げ、CPUとメモリの増分を1週間実測する
4. 内部層へ展開し、遮断動作を有効にする対象を影響範囲の小さいものから選ぶ

各段階の通過基準も決めておきます。目安は、1ノードあたりの日次アラートが一桁に収まり、担当者が全件に説明を付けられる状態。満たさないまま次へ進むと、説明できない通知が増えて全体が放置されます。

CWPPを採用すべき条件と見送るべき場面｜投資判断の基準と代替策

ここは判断を言い切ります。CWPPは、条件が揃わない組織が入れると運用負荷だけが残る種類の投資です。

CWPPの採用が費用に見合う3つの前提条件と社内体制の最低ライン

採用を勧めるのは、次の3条件が同時に成立する場合です。第1に、OS以上を自社で保守するワークロード（IaaSのVMまたは自前運用のコンテナ基盤）が本番で常時稼働していること。第2に、外部からのトラフィックを直接受ける層があること。第3に、検知を受けて一次対応する当番が社内か委託先に決まっていることです。

体制の最低ラインは、平日日中に通知を見て切り分けられる担当が1名以上。24時間体制までは初期段階で不要ですが、誰も見ていない時間帯が週の大半という状態では検知の価値が消えます。

見送りを勧める3つの構成条件とクラウド標準機能だけで足りる範囲

見送りを勧める条件は3つ。1つ目は、構成がSaaSとフルマネージドのPaaS中心で、OSを触るワークロードがほとんど無い場合。守るべき実行環境が事業者側にあり、CWPPを載せる先がありません。

2つ目は、対象が検証環境と社内向け参照系だけの場合。被害額に対してエージェントの保守工数が見合わない計算になります。3つ目は、一次対応の当番が決まっていない場合。この状態で導入しても、3か月後には通知がフィルタで捨てられているのが実情です。

これらに当てはまるなら、クラウド標準の脅威検知（GuardDutyの基本機能やDefender for Cloudの無料の態勢管理）と、デプロイ前の依存関係スキャンで十分に足ります。追加投資は、ワークロードが増えて手作業の点検が回らなくなった時点で検討すれば間に合います。

受託開発でCWPPを前提に設計するときの引き渡し範囲の決め方

受託でシステムを構築する場合、CWPPの扱いは契約範囲の線引きの問題になります。エージェントの導入までを構築側が担い、その後の検知運用は発注側が持つ分け方が最も揉めません。運用まで含めるなら、対応時間帯と一次切り分けの範囲を仕様として書き出します。

引き渡し時に添えるべきものは3点。導入済みエージェントの版数と対象ノードの一覧、例外設定の一覧とその根拠、そして検知が出た場合の連絡経路です。特に例外設定は、根拠を残さないと数か月後に誰も外せない状態になります。

体制を整える前に現状の穴を把握したい場合は、外部からの診断を先に受ける進め方も取れます。手法別の費用感や実施範囲は脆弱性診断・セキュリティ診断で整理しており、常時監視の仕組みへ投資する前に、いま何が空いているかを確かめる用途に向きます。

よくある質問

CWPPの検討でよく受ける質問を整理します。

CWPPとCSPMはどちらを先に導入すべきですか？

CSPMが先です。CSPMはクラウドのAPIを読むだけで動き、ワークロードへ手を入れずに公開設定の不備や過剰権限を洗い出せる。侵入経路そのものを塞ぐ作業のため、同じ予算で減らせるリスクが大きくなります。CWPPが効くのは、その経路を塞いだうえで残る「侵入されたあと」の局面。順序を逆にすると、玄関を開けたまま室内に監視カメラを置く構図になります。

エージェントレス型だけでランタイムの脅威検知はできますか？

できません。エージェントレス型が読むのはディスクのスナップショットで、取得時点の静止画にあたります。パッケージの版数やディスク上のシークレットは分かりますが、いつどのプロセスが起動してどこへ通信したかという時系列は残らず、メモリ上だけで完結するファイルレス攻撃も対象外です。実行時の挙動を捉えたいなら、対象を絞ってでもエージェントを載せてください。

コンテナを使っていない環境でもCWPPは必要ですか？

IaaS上のVMを本番で運用しているなら、対象になります。CWPPはコンテナ専用の仕組みではなく、物理サーバーやVMも保護対象に含むカテゴリです。むしろ長期稼働するVMのほうが、運用中の手作業による構成変更が蓄積しやすく、脆弱性評価と改ざん検知の値打ちが出ます。判断の分かれ目は、コンテナの有無ではなく「OS以上を自社で保守しているかどうか」です。

CWPPとEDRは何が違いますか？

技術としては近く、対象範囲と管理単位が違います。EDRは端末（PC・サーバー）の挙動検知に軸足があり、資産管理も端末単位。CWPPはクラウド上のワークロードを対象とし、コンテナやサーバーレスという短命な実行単位まで扱い、脆弱性評価も含みます。実際、Defender for ServersはEDR製品であるDefender for Endpointを統合する構成で、EDRを内包する製品も珍しくありません。

CWPPの検知アラートは誰が運用すべきですか？

初期段階では、インフラ運用の担当者が兼務する形で構いません。上がってくる検知の多くは、正常な運用操作を拾った誤検知だからです。判別にはシステムの通常動作を知っている人が向いており、セキュリティ専任者よりも運用担当のほうが早く切り分けられます。検知が落ち着いた段階で対応手順を文書化し、当番制へ移す順序が現実的です。

関連記事

• Microsoft Defender for Cloud の全体像とセキュリティ強化：サーバー保護を含むDefender全体の構成を確認できます。
• AWS Security Hubとは？CSPMとの違い・料金と導入判断：AWS側で構成点検を担う仕組みの選び方です。
• クラウドセキュリティとは？責任共有モデルから見た企業の守り方：分界点の考え方を全体像から整理しています。
• GitHub Actionsにtracee-actionを統合する方法：CIへランタイム脅威検知を組み込む具体手順です。
• SBOMとは？部品表の目的・フォーマットと作成・運用の判断：ワークロードの構成部品を把握する前段の仕組みです。