メインコンテンツまでスキップ

SSPM製品選定 2026

先に結論​

SSPM製品の選定では、機能一覧や対応SaaS数を並べる前に、次の三つを決める必要がある。

  1. どのSaaSを、どの深さで管理したいのか
  2. 設定監査、ID・OAuth、脅威検知、データ露出のどこまでをSSPMへ求めるのか
  3. ライセンスがユーザー数、SaaS連携数、テナント数、モジュールのどれで増えるのか

特に重要なのは、企業が選んだ一部のSaaSだけへ導入できるかどうかなのだ。

ユーザー数で価格がほぼ決まる製品なら、追加費用の範囲内で接続SaaSを増やしたほうが投資を回収しやすい。一方、SaaS連携数やテナント数で価格が増える製品なら、重要度の高いSaaSだけを詳細監査へ載せる判断が合理的になる。

したがって、「何個のSaaSに対応するか」だけでは比較できない。自社で詳細監査したいSaaSを先に決め、その構成を各社へ同じ条件で見積もらせる必要があるのだ。

SSPMを何のために選ぶのか​

SSPM（SaaS Security Posture Management）は、SaaSテナントへAPIなどで接続し、設定、ID、権限、OAuth連携、外部共有、監査イベントを継続的に評価する製品カテゴリである。

2026年時点では、単なる設定チェックだけを指す言葉ではなくなっている。主要製品は、次の領域まで扱うようになった。

  • 設定不備と設定ドリフト
  • 管理者、休眠ID、孤立ID、過剰権限
  • サービスアカウント、APIキー、AIエージェントなどの非人間ID
  • OAuthアプリ、Connected App、SaaS間連携
  • 公開リンク、外部共有、機密データへのアクセス
  • 不審なログイン、大量API実行、アカウント侵害
  • 修復手順、チケット連携、承認付き自動修復

ただし、製品によって「SSPM」の中身はかなり違う。設定監査が深い製品、IDと脅威検知が強い製品、データ共有の制御が強い製品、Shadow SaaSの発見が得意な製品を、同じ物差しだけで順位付けしないほうがよい。

他のセキュリティ製品より先に導入すべきか​

SSPMは、EDR、IdP、メールセキュリティ、クラウドセキュリティを置き換えない。一般的には、端末防御、強固な認証、ID保護、メール対策、IaaS・PaaS保護など、主要な侵入経路への対策が先になる。

製品領域主な対象SSPMとの違い
EDR・XDR端末、サーバー上の実行と侵害SaaSテナント固有の設定、OAuth、共有状態までは通常扱わない
IdP・ITDR認証、ID侵害、特権悪用各SaaS内部の権限モデルや外部共有までは見えにくい
CASB・SSE利用者とクラウドサービス間の通信SaaS内部の設定やSaaS間API連携は別の観測点になる
CSPM・CNAPPIaaS、PaaS、コンテナMicrosoft 365やSalesforceなどのSaaSテナントは主対象ではない
DSPM・DLP機密データの所在、分類、持ち出しSSPMはデータそのものより設定、ID、共有関係を広く扱う
SaaS管理・SAM契約、利用状況、ライセンス費セキュリティ設定や脅威検知の深度が異なる
SaaSバックアップ誤削除、障害、ランサムウェアからの復旧SSPMは予防、検出、是正が中心で、復元機能とは別物

SSPMの優先順位が上がるのは、次のような企業である。

  • Microsoft 365、Salesforce、ServiceNow、Google Workspaceなどが基幹業務に近い
  • SaaS管理者が部門ごとに分散している
  • OAuthアプリ、APIトークン、サービスアカウントを棚卸しできていない
  • 公開リンク、外部ゲスト、退職者IDを継続監視できていない
  • SaaS設定監査を年次や四半期の手作業に依存している
  • SaaS上のアカウント侵害をSOCで検知できていない

EDRやIdPが未整備なら、先にそちらを片付ける場合が多い。ただし、重要情報の大半がSaaSにあり、発行済みトークンやSaaS間連携が見えていないなら、SSPMを後回しにする理由も薄くなるのだ。

2026年に選定範囲が広がった理由​

設定監査だけでは足りなくなった​

SaaSの侵害では、SaaS本体の脆弱性を直接突く必要がない。正規のOAuthトークン、接続アプリ、API、古い認証情報を使えば、攻撃者の操作も正規通信に混ざる。

2025年から2026年に公表された事例は、その傾向をよく示している。

事例観測された経路SSPM選定で見る点
Salesloft Drift関連するOAuthトークンからSalesforceへアクセス第三者アプリ、実効権限、大量API実行、トークン失効
GainsightとSalesforce信頼済み接続アプリに関連する異常活動承認済みアプリの再評価、接続関係の影響分析
Vercel第三者AIツールの侵害を起点としたGoogle Workspaceアカウント侵害AIツールの発見、OAuth権限、SaaS間の横移動
Kali365正規のMicrosoft認可画面を悪用したアクセストークン取得OAuth認可、不審なトークン利用、影響範囲、失効
KlueGitHub PATと連携サービスを経由したOAuth情報の収集非人間ID、古い認証情報、休眠連携、緊急失効

MFAは重要だが、発行済みトークンの利用をそれだけで説明できるわけではない。SSPMを選ぶときは、設定チェック数だけでなく、ID、OAuth、API活動、修復までを見る必要があるのだ。

非人間IDとAIエージェントが増えた​

サービスアカウント、APIキー、ワークフロー、ボット、AIエージェントは、人間のIDより長く残りやすい。人事異動や退職処理にも連動せず、所有者が分からなくなることがある。

AIツールはOAuthを使い、メール、ファイル、ソースコード、CRMへ横断的にアクセスする。製品比較では「AI対応」という表示だけでなく、次を確認する。

  • どのAIサービスを発見できるか
  • OAuthスコープと実効権限を取得できるか
  • 所有者、作成者、最終利用日時を追跡できるか
  • AIエージェントの操作を監査イベントとして取得できるか
  • 危険な権限や休眠連携を失効できるか

選定は重要SaaSの棚卸しから始める​

SaaSを三段階に分ける​

すべてのSaaSを同じ深さで監査する必要はない。まず、自社のSaaSを次のように分ける。

階層位置付け監視内容の例
Tier 1侵害時の事業影響が大きい重要SaaS設定、ID、OAuth、共有、脅威検知、修復まで詳細に確認
Tier 2重要だが、扱うデータや権限が限定されるSaaS設定、ID、主要連携を標準的に確認
Tier 3その他の利用SaaS、未承認SaaS発見、所有者、利用者、基本リスクを把握

Tierは利用者数だけで決めない。顧客データ、機密情報、管理権限、他SaaSへの接続、業務停止時の影響を見て決めるのだ。

「対応」と「詳細監査」を分ける​

ベンダーが示す対応SaaS数には、次のレベルが混ざる。

接続レベル取得できるもの
発見利用の有無、ドメイン、アプリ名
ID連携利用者、グループ、認証状態
設定監査SaaS固有の設定、設定ドリフト
データ露出ファイル、公開リンク、外部共有
脅威検知ログイン、API操作、異常行動
修復設定変更、権限削除、トークン失効

「200 SaaS対応」と書かれていても、200 SaaSすべてで設定監査、脅威検知、自動修復ができるとは限らない。Tier 1の各SaaSについて、どの接続レベルまで利用できるかを表で回答させる必要がある。

最重要論点はライセンス体系​

SSPMの費用は、同じ機能でも課金単位によって導入方針が変わる。製品比較表より先に、ライセンスの増え方を確認するのだ。

課金単位が導入範囲を決める​

主な課金単位費用が増える要因合理的な導入判断
ユーザー数対象となる従業員、ID、アクティブユーザー追加SaaS連携の費用が小さいなら、接続数を増やして利用価値を広げる
SaaS連携数接続するSaaS、アプリ、コネクターTier 1から優先し、詳細監査するSaaSを絞る
テナント数本番、開発、子会社、地域別環境同じSaaSでも複数テナントを数える方法を確認する
モジュールSSPM、ITDR、DLP、脅威検知、自動修復必要機能だけ選ぶ。名称が同じでも含まれる範囲を比較する
イベント・データ量監査ログ、APIイベント、保存容量、保持期間大量ログを出すSaaSと保存要件から上振れを試算する
非人間ID数サービスアカウント、APIキー、AIエージェント人間ユーザーと別課金か、上限があるかを確認する

ユーザー課金なら接続SaaSを増やす余地がある​

ユーザー数で年間費用の大半が決まる製品では、SaaS連携を1個から10個へ増やしても費用差が小さい場合がある。この場合、重要SaaSだけに閉じると、支払ったユーザーライセンスを使い切れない。

ただし、「接続数無制限」でも次の費用が別に発生することがある。

  • 上位コネクターや高度な診断パック
  • カスタムコネクター
  • 脅威検知やITDRモジュール
  • データ保持期間の延長
  • 子会社、複数テナント、検証環境
  • 導入支援と運用支援

ユーザー課金だから無条件に全SaaSをつなぐ、という話ではない。製品へ付与するAPI権限、データ取得範囲、運用アラートの増加も考える必要があるのだ。

SaaS連携数課金なら重要SaaSへ絞れる​

接続SaaS数やコネクター数で価格が増える製品では、Tier 1だけを詳細監査し、Tier 2とTier 3を別の手段で管理する構成が取りやすい。

たとえば、次のような分け方になる。

  • Tier 1：SSPMで詳細監査、脅威検知、修復
  • Tier 2：SSPMの標準監査、またはSaaS標準機能による定期確認
  • Tier 3：CASB、SSE、IdP、ブラウザ、経費データなどによる発見

この構成なら対象を絞れるが、SaaS間の接続関係がTierをまたぐ場合は注意が必要である。Tier 1のSalesforceへ接続する小規模SaaSが監視対象外なら、重要な侵入経路だけ残ることがある。

特定SaaSだけに導入できるかを確認する​

見積もり前に、ベンダーへ次を明示的に確認する。

  • 全従業員分の契約が必須か
  • 特定部門、特定ユーザー、特定SaaSだけを契約できるか
  • 契約ユーザーの定義は在籍者、SaaS利用者、監視対象IDのどれか
  • 同じユーザーを複数SaaSで監視すると重複課金されるか
  • 接続SaaS数に上限、最低契約数、追加単価があるか
  • 同一SaaSの複数テナントを別接続として数えるか
  • Sandbox、開発環境、子会社テナントをどう数えるか
  • 発見だけの接続と詳細監査の接続で料金が違うか
  • 非人間ID、外部ゲスト、休眠IDをユーザー数へ含めるか
  • OAuth、脅威検知、DLP、自動修復は基本料金に含まれるか
  • 契約途中で接続SaaSを入れ替えられるか
  • APIイベント数、ログ保存量、保持期間に従量課金があるか

この回答が曖昧なままでは、公開価格を円換算しても予算にはならない。

同じ構成で三つの見積もりを取る​

各社には、少なくとも次の三構成を同じ前提で提示させる。

見積もり接続範囲確認したいこと
最小構成Tier 1のうち3〜5 SaaS特定SaaSだけで契約できるか、最低契約額はいくらか
標準構成Tier 1全体と一部Tier 2重要SaaSへ広げたときの増分費用
全体構成Tier 1、Tier 2、Tier 3の発見ユーザー課金を活かして接続範囲を広げる余地

比較するのは総額だけではない。「SaaSを1個追加したとき」「テナントを1個追加したとき」「ユーザーが10%増えたとき」の増分価格も確認する。将来の構成変更に耐えるかどうかは、初年度価格だけでは分からないのだ。

評価軸と足切り条件​

採点する項目​

評価軸配点主な確認内容
Tier 1 SaaSへの診断深度18SaaS固有設定、権限、共有、監査ログ
設定不備とドリフト12基準値、変更履歴、例外、カスタムポリシー
IDと非人間ID12管理者、休眠ID、サービスアカウント、所有者
OAuthと第三者連携12スコープ、実効権限、最終利用、接続関係
脅威検知10アカウント侵害、大量API実行、横移動
修復能力10ガイド、承認、半自動化、ロールバック、証跡
データ露出8公開リンク、外部共有、機密度、退職者所有データ
対応SaaSの幅5標準コネクター、発見範囲、カスタム接続
運用統合5SIEM、SOAR、ITSM、IdP、HR、API
統制と証跡3フレームワーク、監査証跡、傾向レポート
ライセンスとTCO5課金単位、増分価格、導入費、サポート費
合計100

「対応SaaSの幅」より「Tier 1 SaaSへの診断深度」を重くする。大量のアプリを発見できても、守りたいSaaSの設定やOAuthが見えなければ、製品選定としては苦しいのだ。

採点せず足切りする項目​

次の項目は、点数ではなく必須条件として扱う。

  • 読み取り専用でPoCを開始できる
  • 製品へ付与するAPI権限を説明できる
  • 取得する設定、メタデータ、本文データを区別できる
  • データ保存地域と保存期間を選べる
  • 子会社と複数テナントを権限分離できる
  • ロールベースアクセス制御を利用できる
  • 修復操作へ承認フローを設定できる
  • 操作証跡を外部へ出力できる
  • API障害と監視停止を検知できる
  • 解約時のデータ削除手順を提示できる
  • 価格増加条件を契約前に明示できる

主要製品の特性比較​

2026年7月時点の公開情報を、製品の向いている方向で並べた。単純な総合順位ではない。

製品主な特性比較で見る点向く状況
CrowdStrike Falcon Shield設定、ID、脅威、AIエージェントをFalconへ統合Tier 1ごとの診断深度、既存Falcon契約とのバンドル、価格CrowdStrikeを既存基盤として使い、端末・ID・SaaSを相関したい
AppOmni複雑な重要SaaSへの深い診断、データ露出、脅威検知対応SaaS数より個別SaaSの深度、修復可能項目、接続単価Salesforce、ServiceNow、Workdayなどを重点的に監査したい
Obsidian SecuritySaaS ID、OAuth、行動分析、SaaS間の横移動設定監査と脅威検知の比重、ユーザー課金、モジュール範囲SOCでSaaSアカウント侵害と接続関係を分析したい
Valence SecurityOAuth、分散管理、利用部門を巻き込む修復自動修復の対象、承認制御、SaaSごとの診断深度検出後の是正が滞り、SaaS所有部門へ作業を割り当てたい
Reco広いSaaS発見、ID、Shadow AI、接続関係の可視化発見と詳細監査の差、ユーザー上限、接続無制限の条件SaaS数が多く、Shadow SaaSとShadow AIから把握したい
DoControlSaaS内データ、外部共有、DLP、利用者による修復設定監査の深度、対象SaaS、データ取得範囲Microsoft 365やGoogle Workspaceの外部共有と持ち出しを重視する
Grip SecurityShadow SaaS、Shadow AI、人間・機械ID、ライセンス可視化発見数と詳細診断数の差、SSPM設定監査の深度SaaS資産台帳とID棚卸しを先に整えたい
SpinOneSSPM、DLP、バックアップ、ランサムウェア復旧各機能の別料金、対応SaaS、運用統合Google WorkspaceやMicrosoft 365の保護と復旧をまとめたい
Netskope・ZscalerSSE、CASB、DLPとSSPMの統合独立系SSPMとの診断深度、上位エディション条件既存SSE契約へSSPMを追加し、管理面を統合したい

比較表から候補を選ぶときは、次のように読む。

  • 設定監査の深さを優先：AppOmni、Falcon Shieldなどを比較する
  • SaaS侵害とOAuthを優先：Obsidian Security、Falcon Shield、Valence Securityなどを比較する
  • 広い発見範囲を優先：Reco、Grip Securityなどを比較する
  • データ共有とDLPを優先：DoControlや既存SSEを比較する
  • SaaSバックアップも必要：SpinOneと専用バックアップ製品を比較する
  • 既存プラットフォームを活かす：CrowdStrike、Netskope、Zscalerの追加機能と独立系を比較する

名前の並びを固定的な順位として扱わない。自社のTier 1 SaaS、導入目的、ライセンス条件を入れると、候補の順序は簡単に変わる。

公開価格はそのまま比較しない​

公開されているMarketplace価格には、ユーザー帯、接続数、モジュール、Private Offer向けの参考SKUが混在する。単純な掛け算では、現実の大企業契約から大きく外れることがある。

たとえば、元の調査では次の公開価格を確認した。

製品・SKU公開価格の例読み方
Reco Advanced年額90,000米ドル接続数無制限の記載があっても、ユーザー上限と機能範囲を確認する
Grip Security10,001〜20,000人で年額300,000米ドル全ユーザー帯で同額なら、正式価格ではなく参考SKUの可能性を考える
SpinOne SpinSPM5,000人超で年額360,000米ドルDLP、ランサムウェア検知、バックアップの別料金を確認する
DoControl10,000人超で年額500,000米ドル対象となるCore integrationsと詳細監査範囲を確認する
Obsidian Security1ユーザー当たり年額100米ドル大口割引、最低契約、モジュール範囲を確認する
AppOmni100ユーザー・1 SaaS当たり年額7,500米ドル公開SKUを大企業へ機械的に掛けず、包括契約を取得する

価格換算の前提は1米ドル160円、税、国内代理店サポート、導入支援を含まない。これは2026年7月23日時点の参考情報であり、正式見積もりではない。

予算では、ライセンス以外に次も分けて出す。

  • 初期接続と権限設計
  • ベースラインとカスタムポリシー設計
  • SIEM、SOAR、ITSM連携
  • 例外管理と修復フロー
  • 管理者教育
  • 国内サポートとマネージドサービス
  • カスタムコネクター
  • ログ保存とデータ保持

初年度費用だけでなく、SaaS追加、ユーザー増加、子会社展開、保存期間延長の増分単価を含めて3年間のTCOを比較するのだ。

PoCでは同じSaaSと異常を使う​

PoCは製品デモではない。同じTier 1 SaaSへ、同じ設定不備、OAuthアプリ、非人間IDを用意し、検出から修復までを比較する。

対象SaaS​

  • Microsoft 365またはGoogle Workspace
  • Salesforce
  • ServiceNow
  • OktaまたはMicrosoft Entra ID
  • GitHub
  • Slack
  • 自社固有の重要SaaS

すべてを入れる必要はない。候補製品の得意なSaaSではなく、自社のTier 1から3〜5個を選ぶ。

検証シナリオ​

シナリオ確認内容
MFA未設定の管理者検出可否、検出時間、根拠、修復方法
退職者アカウントIdPとの差異、所有データ、残存トークン
過剰権限割り当てと実効権限、影響範囲
高権限OAuthアプリスコープ、利用者、最終利用、失効
休眠連携残存トークン、サービスアカウント、所有者
公開ファイル公開範囲、所有者、機密度、修復
外部ゲスト最終アクセス、所有データ、棚卸し
設定ドリフト設定変更から検出までの時間
大量API実行異常検知、アラート、遮断または失効
非人間ID所有者、資格情報、権限、最終利用
自動修復承認、実行結果、ロールバック、証跡
API障害監視停止の検知、通知、データ欠損

合格条件​

  • Tier 1 SaaSを必要な接続レベルで監視できる
  • 投入した重大設定不備を根拠付きで検出できる
  • 重大なOAuthアプリと非人間IDを特定できる
  • 誤検知と重複アラートを運用可能な量へ抑えられる
  • 修復の承認、実行結果、証跡を残せる
  • ServiceNow、Jira、SIEMなどへ必要情報を連携できる
  • 監視停止を検知できる
  • 月間運用工数を見積もれる

検出数が多い製品が勝つとは限らない。誰が、何を根拠に、どの手順で直すかまで流れた製品を残すのだ。

RFIと見積もりで揃える条件​

自社から提示する前提​

  • 従業員数と監視対象ユーザー数
  • Tier 1、Tier 2、Tier 3のSaaS一覧
  • SaaSごとの本番、開発、Sandboxテナント数
  • グループ会社と地域
  • 外部ゲスト数
  • 非人間ID数
  • 必要なログ保存期間とデータ保存地域
  • 必要なモジュール

ベンダーへ要求する回答​

  • SaaSごとの接続レベル
  • 取得する設定項目と監査イベント
  • OAuth、非人間ID、データ共有の取得範囲
  • 自動修復可能な項目
  • 必要なAPI権限とAPI制限時の動作
  • 接続障害とデータ欠損の検知方法
  • データ保存地域と保存期間
  • RBAC、承認、操作証跡
  • 日本語対応と重大インシデント支援
  • 基本ライセンスと課金単位
  • ユーザー、SaaS、テナント、非人間IDの追加単価
  • モジュール、ログ、保存容量の追加単価
  • 最低契約額、複数年割引、価格改定上限
  • 導入、教育、サポート、マネージドサービス費
  • 解約時のデータ返却と削除

回答は自由記述だけでなく、SaaSごとの表と価格内訳で受け取る。そうしないと、製品ごとに都合のよい「対応」の定義が混ざってしまう。

選定手順​

SSPM製品選定 2026の流れをまとめると、次の順になる。

  1. SaaSをTier 1、Tier 2、Tier 3へ分類する
  2. 設定、ID・OAuth、脅威、データ、修復のどこまで求めるか決める
  3. Tier 1 SaaSごとに必要な接続レベルを定義する
  4. 特定SaaSだけで契約できるか、課金単位と最低契約を確認する
  5. 同じ三構成で見積もりを取得する
  6. 足切り条件を満たす製品だけを採点する
  7. 同じSaaSと異常を使ってPoCする
  8. 初年度費用ではなく、構成変更を含む3年間のTCOで決める

製品比較は4番目からでよい。先に製品を眺めると、ベンダーが強調する機能へ選定軸が引っ張られる。守るSaaSとライセンスの増え方を先に置けば、比較表はかなり静かになるのだ。

主要ソース​

市場分析​

SSPMの解説​

製品​

公開価格​

インシデント​