MENU

CrowdStrikeがFrost Radarランタイム保護で首位|CSPMとCWPPの違いから読み解くクラウド防御の選定軸

「CSPMはもう入れている。それなのに、なぜランタイム保護をもう一本足せと言われるのか」
クラウドのセキュリティツールを検討していると、CSPM・CWPP・CNAPPと似た略語が並び、どこまで重ねれば守れるのかが見えにくくなります。オンプレのサーバーを20年以上見てきた感覚で言えば、これは「設定ファイルの監査」と「稼働中プロセスの監視」を別物として扱ってきたのと同じ構図です。静的なチェックと、動いているものを見る監視は、守る対象も検知できるタイミングも違います。

この記事では、2026年6月11日にCrowdStrikeが発表した「Frost Radar: Cloud and Application Runtime Security」での首位評価を題材に、CSPM(静的な姿勢管理)とCWPP(ランタイム保護)の違いを起点として、AIワークロード保護まで含めたクラウド防御ツールの選定軸を整理します。製品の宣伝ではなく、自社のクラウド環境にどのレイヤーの保護が足りていないかを判断するための地図を描くのが目的です。設定ミス検知(CSPM)そのものの入門は姉妹記事(CSPM入門|マルチクラウド構成ミス検知ツール比較と運用フロー設計)で扱っているので、本記事はその一段先、ランタイム側に軸を置きます。

CrowdStrikeがFrost Radarランタイム保護で首位|CSPMとCWPPの違いから読み解くクラウド防御の選定軸 - 解説

目次

Frost Radar首位の何が「市場の転換点」なのか

まず憶測を排して、一次情報ベースで事実を整理します。

CrowdStrikeは2026年6月11日(米テキサス州オースティン発表)、調査会社Frost & Sullivanの「2026 Frost Radar: Cloud and Application Runtime Security」において、Growth and Innovation Leader(成長・革新リーダー)に選出されたと公表しました。同社にとってこの分野での首位評価は2年連続で、評価対象ベンダーの中で最高スコアを得たとしています。
発表日: 2026年6月11日(CrowdStrike公式プレスリリース)
評価レポート: Frost & Sullivan「Frost Radar: Cloud and Application Runtime Security」
評価軸: クラウドランタイムセキュリティ、Cloud Detection and Response(CDR)、AIワークロード保護、統合プラットフォーム(CNAPP)
Frostの市場認識: 「姿勢中心(posture-centric)のクラウドセキュリティから、ランタイムでの検知・対応へ」という市場全体のシフト

ここで重要なのは「どのベンダーが一位か」ではありません。注目すべきは、評価レポートが市場のシフトを「設定の姿勢を整える段階から、動いているものをリアルタイムで見る段階へ」と表現している点です。つまり、CSPM中心の対策が一巡し、ランタイム保護(CWPP)の比重が業界全体で増しているという潮目を、第三者の調査機関が裏付けたわけです。特定ベンダーの数値や個別の受賞回数を競うのではなく、自社の防御がまだ「静的な姿勢チェック」止まりなら、そこにランタイム側の穴が空いている可能性が高い、という読み方をすべきニュースです。

なお、報道では同社のクラウドセキュリティ事業の急成長を示す数値も触れられていますが、ベンダー個社の業績数字は選定の本質ではないため本記事では深追いしません。エンジニアとして拾うべきは「ランタイム保護が選定の主戦場に移った」という構造変化のほうです。

CSPM(静的姿勢管理)とCWPP(ランタイム保護)は何が違うのか

ここが本記事の核心です。両者は「クラウドセキュリティツール」という同じ棚に並びますが、守る対象も検知のタイミングも別物です。

CSPM(Cloud Security Posture Management)は、クラウドの「設定(コンフィグレーション)」を静的に評価する仕組みです。S3バケットが公開状態になっていないか、セキュリティグループが0.0.0.0/0で全開放されていないか、暗号化やログ取得が有効か——こうした構成上のミスや基準違反を継続的にスキャンします。オンプレで言えば、サーバー構築後にチェックリストで「設定が基準どおりか」を点検する作業に近い。問題は、設定が正しくても、その上で動くプロセスが攻撃されたら検知できないことです。

CWPP(Cloud Workload Protection Platform)は、稼働中の「ワークロード」——仮想マシン、コンテナ、サーバーレス関数——の内部を実行時に保護する仕組みです。想定外のプロセス起動、ファイルシステムの改ざん、不審な外部通信、既知の脆弱性を突いた挙動などを、動いている最中に検知・遮断します。オンプレで言えば、稼働中のサーバーにEDR(エンドポイント保護)を入れて、プロセスの振る舞いを常時監視するのに相当します。

そしてCNAPP(Cloud Native Application Protection Platform)は、CSPMとCWPP、さらにCIEM(権限管理)やIaCスキャンなどを一枚の基盤に統合したプラットフォームを指します。Frost Radarが評価したのは、まさにこの統合の中でランタイム側(CWPP/CDR)をどれだけ強く速く回せるか、という観点です。

観点 CSPM(静的姿勢管理) CWPP(ランタイム保護)
守る対象 クラウドの設定・構成(コンフィグ) 稼働中のVM/コンテナ/サーバーレス
検知のタイミング 設定変更時・定期スキャン(事前・静的) 実行中(リアルタイム・動的)
典型的な検知例 公開S3バケット、暗号化漏れ、過剰権限 不審プロセス起動、ファイル改ざん、横展開
オンプレ類推 構築後の設定チェックリスト監査 稼働サーバーのEDR/振る舞い監視
検知できないもの 正しい設定の上で起きる実行時攻撃 そもそもの設計ミス・基準違反
主な利用フェーズ 構築・移行・継続的ガバナンス 本番運用・インシデント対応

要するに、CSPMは「正しく作れているか」を見て、CWPPは「正しく作ったものが今どう動いているか」を見ます。どちらか一方では穴が残るため、Frost Radarの評価が示すように、業界の重心はCSPMで土台を固めたうえでCWPPを足す方向へ動いている、という整理になります。

PR

AWSではじめるクラウドセキュリティ クラウドで学ぶセキュリティ設計/実装

クラウドセキュリティを「設定の姿勢」と「運用時の保護」の両面から体系立てて学べる一冊。CSPMとCWPPの守備範囲の違いを、AWSの具体サービスに落として理解したい人の足場になります。

AIワークロード保護がなぜランタイム側の論点なのか

Frost Radarの評価軸にAIワークロード保護が含まれていた点は、見過ごせません。生成AIや機械学習の推論基盤をクラウドに載せる企業が増え、ここが新しい攻撃対象になっているからです。

AIワークロードの特徴は、設定チェック(CSPM)だけでは守りきれないところにあります。たとえば学習・推論コンテナが外部のモデルやパッケージを実行時に取り込む、プロンプトを介して想定外のコマンドが走る、モデルファイルが実行中にすり替えられる——こうした事象はすべて「動いている最中」に起きるため、構成が基準どおりでも検知できません。だからこそランタイム側(CWPP/CDR)の守備範囲に入る、という整理になります。

実務でAIワークロードを抱えている、あるいはこれから載せる予定があるなら、選定時に「このツールは推論コンテナ・GPUワークロードの実行時挙動まで見られるか」を確認軸に加えるべきです。CSPMだけで「セキュリティ対策済み」と判断していると、AI基盤の実行時リスクがまるごと死角になります。
静的に見える穴: コンテナイメージの既知脆弱性、過剰なIAM権限(CSPM/イメージスキャンで検知可能)
実行時にしか見えない穴: 推論プロセスの異常な外部通信、モデル差し替え、想定外プロセス起動(CWPP/ランタイム保護の領域)

クラウド上のLinuxワークロードそのものの基礎は、姉妹サイトLinuxMaster.JPでも扱っています。コンテナやプロセスの振る舞いを理解しておくと、ランタイム保護のアラートを読み解く力が上がります。

クラウド防御ツールの選定軸——5つのチェックポイント

ここまでの整理を、実際の選定に使える5つの軸に落とし込みます。CSPMとCWPPのどちらが優れているかという二択ではなく、自社環境に「どのレイヤーの保護が足りていないか」を診断する観点として使ってください。

1つ目は保護レイヤーのカバー範囲です。設定の姿勢(CSPM)だけか、稼働中ワークロード(CWPP)まで見るか、権限(CIEM)やIaCスキャンも含むか。現状で持っているツールがどこまでカバーしているかを棚卸しし、空白のレイヤーを特定します。

2つ目は検知から対応までの速度(CDR)です。ランタイム保護は検知して終わりではなく、いかに早く封じ込めるかが価値になります。アラートが上がってから自動隔離・遮断までを分単位で回せるか、それとも人手の調査が前提かで、運用負荷も被害規模も変わります。

3つ目はAIワークロード対応です。前章のとおり、推論コンテナやGPUワークロードの実行時挙動を見られるか。AI基盤を持つなら必須、まだなくても今後の拡張余地として確認しておくと安心です。

4つ目は統合の有無(CNAPP化できるか)です。CSPMとCWPPを別ベンダーでバラバラに入れると、アラートが分断され、相関分析ができません。同一プラットフォームで姿勢とランタイムを横断して見られると、「設定ミスを突かれて実行時攻撃に至った」という連鎖を一本で追えます。

5つ目は運用負荷とアラート品質です。検知範囲を広げるほどアラートは増えます。誤検知をどれだけ抑え、優先度づけできるか。ツールを入れただけで運用が回らなければ意味がありません。アラート疲労への向き合い方は、CSPM運用の文脈でマルチクラウド×AIアラート疲労を解消する運用設計でも整理しています。

選定軸 確認する問い 不足時のリスク
保護レイヤー 姿勢/ランタイム/権限のどこまで見るか 実行時攻撃が死角になる
検知・対応速度 検知から封じ込めまで自動化されているか 初動が遅れ被害が拡大する
AIワークロード対応 推論コンテナの実行時挙動を見られるか AI基盤の実行時リスクが無防備
統合(CNAPP化) 姿勢とランタイムを横断分析できるか アラート分断で攻撃連鎖を追えない
運用負荷 誤検知を抑え優先度づけできるか アラート疲労で対応が形骸化

コスト感覚——ツールを重ねる前に確認すべきこと

CSPM・CWPP・CNAPPは、課金体系がそれぞれ異なります。導入を検討する前に、コスト構造の違いを掴んでおくと過剰投資を避けられます。

CSPMはおおむね「管理対象のクラウドアカウント数」や「資産(リソース)数」で課金されることが多く、静的スキャンが中心なので比較的読みやすいコスト構造です。一方CWPP(ランタイム保護)は、保護対象の「ワークロード数」「ホスト数」「コンテナ・vCPU数」など、稼働している実体の量で課金される傾向があり、本番環境がスケールするほど費用も伸びます。CNAPPとして統合すると、個別契約より単価が抑えられる場合がある反面、フル機能を有効化すると総額は上がります。
CSPM: アカウント数・資産数ベースが多い(静的・読みやすい)
CWPP: ワークロード/ホスト/vCPU数ベースが多い(スケール連動で伸びる)
CNAPP統合: バンドル割引の余地あり。ただしフル機能化で総額上昇

実務では、まず「本番で常時稼働しているワークロードの数」を把握することが、CWPP系のコスト見積もりの出発点になります。開発・検証環境まで全部に最上位のランタイム保護を掛けると過剰になりがちなので、本番・重要度の高い系統から段階的に適用し、効果と費用を見ながら広げるのが現実的です。なお、各製品の具体的な価格は時期・契約形態で変動するため(2026年6月時点でも改定が続いています)、必ず見積もり時点の公式情報で確認してください。本記事では特定ベンダーの金額は断定しません。

PR

AWS設計スキルアップガイド サービスの選定から、システム構成、運用・移行の設計まで

セキュリティツールの選定はクラウド全体の設計の一部です。サービス選定から運用設計までの判断軸を体系的に押さえたい人に。CSPM/CWPPをどの設計フェーズに組み込むかの土台づくりに役立ちます。

よくある疑問(FAQ)

Q1. CSPMを入れていればCWPPは不要ですか?

不要とは言えません。CSPMは設定の姿勢を見るだけで、正しい設定の上で起きる実行時攻撃(不審プロセス、横展開、ファイル改ざん)は検知できません。Frost Radarが示すとおり、業界の重心は姿勢管理からランタイム保護へ移っています。土台をCSPMで固め、本番ワークロードにCWPPを足すのが基本形です。

Q2. CNAPPを入れればCSPMもCWPPも全部カバーできますか?

多くのCNAPPはCSPM・CWPP・CIEMなどを統合していますが、製品によって各機能の強弱があります。「統合されている」ことと「ランタイム保護が実用レベルで速いか」は別問題です。選定時は統合の有無だけでなく、本記事の5つの軸(特に検知・対応速度とAIワークロード対応)で個別に評価してください。

Q3. 小規模なクラウド環境でもランタイム保護は必要ですか?

規模が小さくても、本番でインターネットに公開しているワークロードがあるなら検討価値があります。ただし全環境に一律で掛けると過剰になりやすいので、公開系・重要度の高い系統から段階適用し、コストと効果を見ながら広げるのが現実的です。

Q4. AIワークロードを持っていなければAIワークロード保護の確認は不要ですか?

現時点で不要でも、将来生成AIや機械学習基盤を載せる可能性があるなら、選定軸に残しておくと安心です。後から別ツールを追加するより、最初から対応範囲を持つ製品を選んだほうが運用が分断されません。

Q5. CSPMとCWPPを別ベンダーで入れるのは問題ですか?

動作上は可能ですが、アラートが分断され「設定ミスを突かれて実行時攻撃に至った」という連鎖を一本で追いにくくなります。相関分析や運用の一元化を重視するなら、同一プラットフォーム(CNAPP)での統合に寄せるメリットがあります。

CrowdStrikeがFrost Radarランタイム保護で首位|CSPMとCWPPの違いから読み解くクラウド防御の選定軸 - まとめ

本記事のまとめ

2026年6月のCrowdStrikeのFrost Radar首位評価は、特定ベンダーの勝敗より「クラウド防御の重心が静的姿勢管理(CSPM)からランタイム保護(CWPP)へ移った」という市場の転換点として読むべきニュースでした。
CSPMは「正しく作れているか」を静的に見る(設定・構成の監査)
CWPPは「動いているものが今どうか」をリアルタイムに見る(実行時保護)
AIワークロード保護は実行時にしか見えないリスクなのでランタイム側の論点
選定は5軸で診断: 保護レイヤー/検知速度/AI対応/統合/運用負荷
コストは本番ワークロード数を起点に段階適用で過剰投資を避ける

自社のクラウド防御がCSPM止まりなら、まずは本番で公開しているワークロードにランタイム側の穴が空いていないかを点検するところから始めてください。設定を整える段階は終わり、動いているものをどう守るかが次の主戦場です。

『Cloud Security』の記事をもっと読む

CSPM・CWPP・IAMなど、クラウドセキュリティの実務に直結するノウハウをまとめています。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次