CWPPとは？機能・CSPMとの違い・選び方を解説

CWPPとは、クラウド上で動く仮想マシンやコンテナ、サーバレス関数、およびオンプレミスの物理サーバを保護するセキュリティ製品の分類です。設定を外側から点検するCSPMに対し、CWPPは動いているサーバやコンテナの内側を見ます。守る対象も、見るタイミングも違います。

クラウド移行が進むと、管理対象はサーバ1台ずつの台帳から、日々生成と破棄が繰り返される実行環境の集合へ変わります。そこで、CWPP、CSPM、両者を束ねたCNAPPのどれが何を見ているのかが分からなくなります。

この記事では、CWPPの主な機能、CSPMやCNAPPとの違い、守備範囲から外れる脆弱性への対処、導入前に固める脆弱性管理の進め方、製品を選ぶときの確認項目を解説します。CSPMとCWPPのどちらを先に入れるか、製品より先に診断が要るのかを判断する際に参考にしてください。

CWPPとは？クラウドで稼働するワークロードを守る仕組み

CWPPとは、Cloud Workload Protection Platformの頭文字を取った略語であり、日本語では「クラウドワークロード保護プラットフォーム」と訳されます。クラウド上で動いている仮想マシンやコンテナ、サーバレス関数を保護対象とする、セキュリティ製品の分類を指します。
保護の対象には、クラウド上の仮想マシンやコンテナ、サーバレス関数だけでなく、オンプレミスの物理サーバも含まれます（Microsoft Security「CWPP とは」）。

なお、本文の「調査会社のGartnerが提唱した呼称で、特定のメーカーの製品名ではありません」という記述は、用語の由来を述べているだけですので、このままで問題ございません。
調査会社のGartnerが提唱した呼称で、特定のメーカーの製品名ではありません。利用者の手元にあるPCを守る製品とは、想定する対象がそもそも違います。
この項目では、CWPPがどの範囲を保護し、いつの時点を守るのかという点から、この製品分類について説明します。

保護の対象となるワークロードとは何を指すのか

ワークロードとは、アプリケーションを動かすために必要な処理とリソースの集合を指します。AWSであれば、仮想マシンのEC2インスタンス、ECSやEKS上で動くコンテナ、サーバレス関数のLambdaがこれにあたります。AzureやGoogle Cloudにも同等のサービスがあり、オンプレミスの物理サーバも、ハイブリッド環境の一部として保護対象に含まれます。
従来のサーバと違うのは寿命の短さです。コンテナは数分で生成され、役目を終えれば破棄されます。Excelの台帳では更新が追いつかず、誰も把握していないインスタンスが残り続けます。

CWPPが守るのは実行中のタイミング

中核となる役割は、ランタイム保護です。ランタイムとは、プログラムが実際に動いている状態を指します。設定を外側から点検するのではなく、稼働中のコンテナやVMの内部で何が起きているかを見る点に、この製品分類の軸があります。
ただし、守備範囲がランタイムだけに限られるわけではありません。Gartnerは、CWPPに求められる保護は開発時からランタイムまでをまたぐものだとしており、実際の製品もビルド時のコンテナイメージ検査を備えるのが一般的です。

CWPPが求められる背景と国内で起きている変化

CWPPが注目される背景には、国内の統計に表れた変化があります。クラウドの利用状況、公開サーバが受けている探索の量、実際の侵入経路の3点を確認したうえで、責任共有モデルにおける自社の責任範囲を押さえます。

クラウド利用は広がる一方でパッチ適用は半数に届かない

総務省の令和7年通信利用動向調査によると、クラウドサービスを一部でも利用している企業の割合は83.5%でした。全社的に利用している企業も60.0%に達しています。調査対象は公務を除く産業の、常用雇用者規模100人以上の企業です（※1）。
一方、同じ調査で「OSへのセキュリティパッチの導入」を実施していると回答した企業は43.4%にとどまります。インターネットを利用する企業の48.0%は、過去1年間に何らかのセキュリティ被害を受けたと回答しました（※1）。守る対象が増える速度に、基本的な脆弱性対策が追いついていません。

公開したサーバは立てた時点から探索されている

警察庁が設置したセンサーで検知した、脆弱性探索行為などの不審なアクセスは、1日かつ1IPアドレスあたり9,605.7件でした。前年比0.9%増で、高い水準が続いています（※2）。
検証用に立てた一時的なインスタンスでも、公開した瞬間から探索の対象になります。攻撃者は特定の企業を狙う前に、脆弱な機器を無差別に探しています。

侵入経路として狙われるのは未修正の脆弱性

警察庁への令和7年のランサムウェア被害報告は226件でした。被害組織へのアンケートでは、侵入経路はVPN機器が6割以上を占めます。攻撃者は未修正の脆弱性、漏えいした認証情報、簡易なパスワード、設定不備などを悪用して内部へ入っています（※2）。
被害の重さも数字に表れています。調査と復旧に総額1,000万円以上を要した組織は5割を超え、1か月未満で復旧できた組織は5割強でした。同じくランサムウェア被害に遭った企業・団体へのアンケートでは、サイバー攻撃を想定した業務継続計画を策定済みの組織は約18%です（※2）。
IPAの「情報セキュリティ10大脅威 2026」でも、組織向け脅威の4位に「システムの脆弱性を悪用した攻撃」が入りました（※3）。

責任共有モデルで自社が負う範囲

クラウドサービスの利用では、責任共有モデルという考え方が前提になります。AWSは、ホストOSと仮想化レイヤーから施設の物理的なセキュリティまでを自社が運用、管理、制御し、ゲストOSの更新とセキュリティパッチ、関連するアプリケーションソフトウェア、セキュリティグループの設定は利用者の責任範囲であると示しています（※4）。同じ考え方はAzureやGoogle Cloudにもありますが、分担の細かい線引きは事業者やサービスごとに異なります。
自社が負う範囲は、利用するサービス形態によって変わります。

マネージドサービスでもパッチ対応は不要になりません。AWSはRDSなどについて、自社がパッチを提供し、利用者が通知された期間内に適用するという分担を示しています（※5）。表の下2行は、どの形態でも利用者の責任から外れません。

※1　参考：総務省│「令和7年通信利用動向調査の結果」
※2　参考：警察庁│「令和7年におけるサイバー空間をめぐる脅威の情勢等について」
※3　参考：IPA│「情報セキュリティ10大脅威 2026」
※4　参考：Amazon Web Services│「責任共有モデル」
※5　参考：Amazon Web Services│「責任共有 - セキュリティの柱」

CWPPの主な機能と導入で得られる効果

CWPPの機能は製品によって幅がありますが、中心となるものは共通しています。機能と効果の対応は表のとおりです。つまずきやすい可視化、脆弱性管理、ランタイム保護と、導入方式の違いは表のあとで補足します。

複数のクラウドを使う場合は、一元管理による運用負荷の軽減、監査対応の証跡化、環境をまたいだ基準の統一も効果に含まれます。

ワークロードの可視化とインベントリ管理

複数のクラウドアカウントにまたがるワークロードを自動検出し、一覧にします。手作業の棚卸しでは、開発チームが独自に立てた検証環境や、担当者が退職したまま残るインスタンスが漏れがちです。

脆弱性管理

OSパッケージ、ミドルウェア、依存ライブラリを分析し、既知の脆弱性を照合します。検出結果はCVEで示されます。CVE（Common Vulnerabilities and Exposures）とは、公開された脆弱性1件ごとに割り当てられる共通の識別番号で、CVEプログラムが認定した採番機関が付与します。
検出件数の多さは危険度を表しません。数千件出ても、外部から到達できない環境と、インターネットに公開されたサーバでは緊急度が違います。コンテナの場合は、元になるイメージの検査も必要です。

詳細はこちら

ランタイム保護と通信の制御、コンプライアンス評価

稼働中のワークロード内部で、通常は起こらないプロセスの起動、不審なシェル実行、想定外の外部通信を検知します。侵入後の活動を捉える層にあたり、入口対策をすり抜けられた場合に被害の拡大を抑える役割を担います。ただし、これ1つで対策が完結するわけではなく、設定の点検や脆弱性診断と組み合わせて使う前提の機能です。
多くの製品はマイクロセグメンテーションも備えます。ネットワークを細かく区切り、必要な通信だけを許可する仕組みです。ベンチマークへの準拠状況を評価する機能もありますが、対応基準は製品ごとに異なるため個別に確認してください。

エージェント型とエージェントレス型の違い

導入方式は2種類あり、取得できる情報量と運用負荷が逆の関係になります。

ランタイム保護を重視するならエージェント型が前提です。まず全体像を把握したい段階なら、エージェントレス型から始める選択もあります。

CSPM、CNAPP、CASBなど周辺分野との違い

略語の見た目が近く、脆弱性の検出という機能が複数の分類で重複するため、混同が起きます。CSPMとの違いから始め、CNAPPとの関係、CASBやSSPMやEDRとの守備範囲、自社での優先順位という順で進みます。

CWPPとCSPMの違い

CSPM（Cloud Security Posture Management）は、クラウドの設定状態を点検する仕組みです。ストレージの公開設定、IAM権限の過不足、ログ取得の有無といった項目をAPI経由で確認します。
対してCWPPは、その設定の上で動いているサーバやコンテナの中身を見ます。設定ミスを外側から探すのがCSPM、動いているものの内側を見るのがCWPPという分け方が実務に合います。

CNAPPとの関係

CNAPP（Cloud Native Application Protection Platform）は、CWPPとCSPMを含む複数の機能を1つに束ねた分類です。近年の製品の多くはCNAPPとして提供され、CWPPはその構成要素になっています。
製品比較では、CWPP単体を探すより、CNAPP製品のワークロード保護機能がどこまで実装されているかを見るほうが実態に合います。

CASB、SSPM、EDRとの守備範囲の差

CASBはCloud Access Security Broker、SSPMはSaaS Security Posture Management、EDRはEndpoint Detection and Responseの略です。このうちCASBは、現在は単体の製品分野というより、SWGやZTNAとともにSSE（Security Service Edge）へ束ねられた機能として提供されるのが主流です。
似た略語の守備範囲は表のとおりです。

EDRとCWPPは技術的に近い部分があります。ただし端末向けの製品はユーザー操作を前提に設計されており、常時稼働するサーバで監視すべき事象とは取得対象が異なります。サーバ用途では、サーバを前提とした製品を選んでください。

自社にどちらを先に入れるべきか

判断の分かれ目は、直近で不安を感じている対象です。ストレージの公開設定や権限管理に自信がないならCSPM、稼働中のサーバのパッチ状況を誰も把握していないならCWPPの脆弱性管理から手をつけます。

CWPPだけでは見つからない脆弱性がある

CWPPを入れれば脆弱性対策が完了するわけではありません。検出できる範囲には明確な境界があり、そこから外れる欠陥が存在します。境界の内側と外側を分けたうえで、外側をどう埋めるかが本題です。

検出できるのは既知の脆弱性と異常な挙動

CWPPの脆弱性管理が照合しているのは、公開済みの脆弱性情報データベースです。OSやミドルウェア、オープンソースのライブラリのように世界中で共通して使われるソフトウェアには番号が振られており、バージョンを突き合わせれば検出できます。

自社で開発したアプリケーションの欠陥は対象外

自社で書いたコードの欠陥にはCVE番号が付きません。他人のIDを指定すると他人のデータが見える認可制御の不備、入力値の処理を誤ったSQLインジェクション、認証フローの設計ミス、決済処理の順序を悪用できる業務ロジックの穴などです。OWASPが2025年に公開した最新版のOWASP Top 10:2025でも、アクセス制御の不備（Broken Access Control）が引き続き1位に置かれています。
これらは、パラメータを1つ書き換えるだけで再現するものから、特定の画面を特定の順序で操作して初めて再現するものまで幅があります。いずれも、その機能がどう動くべきかを理解したうえで実際に操作しなければ確認できません。バージョンを照合するスキャンでは原理的に検出できません。CWPPの脆弱性管理で0件でも、自社アプリケーションの安全性は証明されていません。
自動でよいものとそうでないものの線引きが必要です。バージョン照合で判定できるOSやライブラリの脆弱性は、ツールによる自動検出が有効です。一方、認可制御や業務ロジックの欠陥は、判定の前提となる仕様が組織ごとに異なり、自動判定では真偽を確定できません。AIを用いた診断も登場していますが、悪用可能かの検証と誤検知の切り分けには技術者の手が要ります。

層ごとに手段を組み合わせる

守る対象を3つの層に分け、それぞれに合う手段を当てる形が実務に合います。

プラットフォーム診断とは、サーバやネットワーク機器のOS、ミドルウェア、公開ポートを対象に脆弱性の有無を確認する診断です。CWPPが継続的な監視を担い、診断が定点での深い確認を担います。
3層のうちどれかが手つかずのまま残っていると、そこが侵入口になります。自社開発のアプリケーションを公開しているなら、CWPPの導入有無にかかわらず診断の実施状況を確認してください。

CWPPを検討する前に固めたい脆弱性管理の流れ

CWPPは脆弱性管理を自動化し、常時化する製品です。管理の型そのものは導入前に決めておく必要があります。棚卸しから修正の確認までの4つの段階を、担当者が手を動かす単位で追います。

詳細はこちら

資産の棚卸しから始める

どのクラウドアカウントに何が動いているかを1枚にします。本番環境だけでなく、検証環境、外部委託先が構築した環境、過去のプロジェクトで残ったインスタンスまで含めてください。所有部署と担当者名をタグに入れておくと、後の修正依頼が滞りません。担当者不明のリソースは、停止できるかを先に判断します。

検出手段と頻度を決める

OSやミドルウェアの脆弱性は、ツールによるスキャンで日次または週次に確認できます。自社開発のアプリケーションは、大きな機能追加時とリリース前に診断を実施する形が現実的です。
年に1回の診断では、その間に加わった機能が漏れます。変更の多い画面や、認証と決済に関わる機能を優先対象に決めておくと、限られた予算でも守る範囲を保てます。

優先順位はCVSSスコアだけで決めない

CVSSは脆弱性の深刻度を0.0から10.0で表す指標です。ただし、CVSSが高い脆弱性がすべて実際に攻撃されているわけではありません。
併用したいのが、米国CISAのKEVカタログです。実際に悪用が確認された脆弱性の一覧で、掲載されたものは緊急度が高いと判断できます（※6）。これに、対象サーバが外部公開されているか、機密データを扱っているかという自社側の条件を掛け合わせて順位を決めます。
CISA自身も2026年6月に指令を改め、KEVに載っていれば一律の期限を課す方式から、外部公開されているか、攻撃を自動化できるか、悪用されるとシステムを完全に奪われるかを組み合わせて期限を決める方式へ切り替えました。KEVは順位付けの入力の1つであり、単独の判断材料ではありません。

詳細はこちら

修正と再確認を期限つきで回す

深刻度に応じた対応期限を決めておきます。たとえば外部公開かつKEV掲載の脆弱性は3日以内、外部公開のCVSS 9.0以上は2週間以内、内部限定のものは次回の定期メンテナンスといった形です。修正後は再スキャンまたは再診断を行い、指摘が閉じたことを記録に残してください。
この4つが回っていない状態でCWPPを導入すると、対応されないアラートだけが積み上がります。逆に流れができていれば、記録がそのままISMSやPCI DSSの監査対応の証跡として使えます。ただし、規格ごとに対象範囲や頻度、実施主体が定められているため、そのまま流用できるとは限りません。

※6　参考：CISA│「Known Exploited Vulnerabilities Catalog」

CWPP製品を選ぶときの確認項目

見積もりや製品資料を比較する段階で確認したい項目は表のとおりです。判断を誤りやすい導入方式、検出結果の扱い、サポートと費用の3点は、表だけでは足りない部分を補います。

対応するクラウドと導入方式を確認する

利用中のクラウドだけで判断すると、別のクラウドが加わったときに製品を買い増すことになります。導入方式では、エージェントの配布と更新の仕組みが社内にあるかを先に確かめてください。仕組みがないままエージェント型を選ぶと、導入漏れのワークロードが監視対象から外れます。専任者が少ない組織では、エージェントレス型で全体を把握し、重要度の高いサーバから順に入れる進め方が現実的です。

検出結果を運用に乗せられるかを確認する

優先順位付けは、そのライブラリが実際に読み込まれているか、対象サーバが外部公開されているかで重み付けできるかを見ます。この機能がないと、担当者が数千件を手作業で選別することになります。CI/CD連携はビルド段階でイメージを検査できるか、SIEMやチケット管理システムとの連携は検知後の対応を担当者以外に渡せるかが観点です。

サポート体制と費用の増え方を確認する

製品ベンダーは海外企業が中心です。日本語の問い合わせ窓口と緊急時の対応時間を契約前に確かめてください。ワークロード数に連動する課金では、オートスケールで台数が増えたときの扱いも同様です。繁忙期の台数で試算しておかないと、請求が想定を超えます。

まとめ：CWPPの死角は診断で確かめる

CWPPは、クラウドで動く仮想マシンやコンテナ、サーバレス関数を保護する製品分類です。設定を点検するCSPMとは対象が異なり、現在は両者を束ねたCNAPPとして提供される例が主流です。
ただし、CWPPが検出できるのは既知の脆弱性と異常挙動までです。自社開発のアプリケーションに潜む認可制御の不備や業務ロジックの欠陥は、守備範囲から外れます。この層を埋めるには、技術者による脆弱性診断やペネトレーションテストが必要です。
まずクラウド上の資産を1枚に洗い出し、直近1年で診断を受けていない領域、とくに自社開発のアプリケーションを特定してください。そのうえで、日々の監視を製品で担うか、まず診断で現状を把握するかを判断します。
ユービーセキュアでは、サーバやネットワーク機器を対象としたプラットフォーム診断と、自社開発のWebアプリケーションを対象とした手動診断を提供しています。自動判定では真偽を確定できない認可制御や業務ロジックの検証を含めて確認したい場合は、対象範囲のご相談からお問い合わせください。