Microsoft Defender for Cloud の「セキュア スコア（Secure score）」は“高いほど良い”のは確かですが、「80%以上なら合格」「Azure利用者の平均は何%」のような公式ベンチマークが見つからず、顧客説明で困りがちです。この記事では、公式見解を踏まえて“合格ラインがない理由”と、代わりに何を軸に説明・運用すべきかを、実務テンプレと一緒に整理します。
結論：%で高い/平均/低いを判定する「公式基準」や「Azure全体の平均値」は公開されていない
最初に結論から言うと、Microsoft Defender for Cloud のセキュア スコアについて、「○%なら高い」「Azure全体の平均は○%」のような公式な合格ライン（ベンチマーク）や平均値は、公開された形では提示されていません。Microsoft Q&Aでも、Microsoft側（モデレーター/社員）から「スコアの解釈に関する特定の基準ドキュメントはない」「スコアは各組織に固有で比較が難しい」という趣旨の回答が示されています。
さらに同じQ&Aの別回答では、理想のセキュア スコアは常に100であり、80%を「良い」と言い切るのは適切でない場合がある（攻撃者は小さな穴1つで侵入できるため）、という考え方も明言されています。
そもそもセキュア スコアは「何を測る指標」なのか
セキュア スコアは、Defender for Cloud が提示する推奨事項（recommendations）の対応状況を集約し、現在のセキュリティ態勢を“ひと目で把握”して改善を促すための指標として設計されています。Microsoft Learn でも、スコアはセキュリティ状況を把握するために集約され、スコアが高いほど特定されたリスクレベルが低い、という位置付けで説明されています。
MCSB（Microsoft Cloud Security Benchmark）とセキュア スコアの関係
Defender for Cloud をサブスクリプションで有効化すると、既定で Microsoft cloud security benchmark（MCSB） が適用され、リソースの評価が始まります。そして、MCSBに由来する組み込み推奨事項がセキュア スコアに影響する、という整理になっています。
ここが重要で、セキュア スコアは「クラウド全般の理想状態」そのものではなく、Defender for Cloud が提示する推奨事項のうち、スコア計算対象になっているものへの準拠度を表します。したがって、同じクラウドでも、構成・運用・対象範囲が違えば、スコアの“意味”が変わります。
計算の基本（クラシックモデル）：%は「現在点 / 満点」の比率
クラシック（Azureポータル）側では、セキュア スコアは割合（%）として表示され、現在値と基になる値が示されます。
セキュア スコアは、推奨事項が束ねられたセキュリティ コントロール（security controls）ごとに「最大獲得点（Max score）」が設定され、コントロール内の推奨事項にどれだけ対応しているかで加点されます。Microsoft Learn では、コントロールで満点を取るには、そのコントロール内の推奨事項に対して対象リソースが準拠している必要がある、という考え方が説明されています。
また、コントロールのスコアは定期的に再計算され（例：一定間隔での評価）、推奨事項の更新頻度とコントロールの更新頻度が異なるため、画面上のリソース数に差が出ることがある点も注意事項として示されています。
2025年時点の注意：セキュア スコアには「2つのモデル」がある
近年の大きな変化として、Defender for Cloud には2つのセキュア スコアモデルが併存します。
- クラシック（Azureポータル）：従来の計算方式。Azureポータル側で確認する“Secure score”が中心。
- 新しい Cloud Secure Score（Defenderポータル）：資産のリスク要因や資産の重要度（criticality）を取り込み、よりリスクベースにスコアリングする新モデル。Defenderポータル側で利用でき、クラシックとは計算も値も異なります。
リリースノートでも、新しい Cloud Secure Score が資産リスク要因と重要度をベースにしており、Defenderポータルで利用できる一方、クラシックはAzureポータルに残る、という整理が示されています。
この「モデル差」があるため、顧客に“何%が高いか”を語る以前に、どの画面（どのモデル）のスコアを話しているかを明確にする必要があります。
なぜ「公式ベンチマーク」や「平均値」を出しにくいのか
「平均が分かれば説明しやすい」という気持ちはとても現実的です。一方で、セキュア スコアは“誰でも同じテスト”ではなく、環境依存の要素が多すぎて、組織間比較が成立しにくい設計になっています。Microsoft社員の回答でも、スコアは各組織に固有で比較が難しいこと、現実には実行が非現実的な推奨事項もあり得ること、除外を使うこともあることなどが述べられています。
| 比較が難しくなる要因 | 実務で起きること | 「%の平均」を出しても意味が薄い理由 |
|---|---|---|
| リソース構成が違う | VM中心、PaaS中心、Kubernetes中心などで該当推奨事項が変わる | “問題が出る領域”が違うため、同じ%でも中身が別物になる |
| 適用範囲（Azure/AWS/GCP）が違う | マルチクラウド連携の有無で評価対象が増減 | 母集団が変わり、単純平均が歪む |
| プラン/機能の有効化状況が違う | Defender CSPMや各Defenderプランのオン/オフで見える推奨事項が変わる | “測定できている範囲”が違い、比較が成立しにくい |
| 除外（Exempt）の方針が違う | 「リスク受容」「第三者で緩和」などで推奨事項を除外できる | 除外が多いとスコアが上がりやすく、比較がさらに難しくなる |
| 推奨事項が更新される | 新しい推奨事項追加・成熟度変更などで、突然スコアが上下する | “平均”は時点で変わり、説明が破綻しやすい |
「80%は高いですか？」と聞かれたときの現実的な答え方
セキュア スコアは“高いほど望ましい”ですが、80%を一律に「高い」と断言するのは危険です。理由は2つあります。
- 穴は1つで侵入され得る：攻撃者は平均点を取りに来ません。突ける穴が1つでもあれば成立します（＝80%でも重大な欠陥が残る可能性）。
- “80%の中身”が組織で違う：同じ80%でも、未対応が「低リスクの細かな運用」なのか、「インターネット露出の管理ポート」なのかで意味が変わります。
したがって、顧客説明では“スコア単体”より、残っている推奨事項のリスクレベルと、改善の推移を中心に組み立てるのが安全です。
「スコア」と「リスク優先度」は同じではない：まずは言葉を揃える
Defender for Cloud には、推奨事項を“いま本当に危ない順”に並べるためのリスク優先度（risk prioritization）の考え方があります。リスク優先度は、インターネット露出、データの機微性、ラテラルムーブメント可能性、攻撃パス（attack paths）などの環境コンテキストをもとに、推奨事項のリスクレベル（Critical/High/Medium/Low等）を算出して優先度付けします。
一方で、クラシック（Azureポータル）のセキュア スコアは、必ずしもリスク優先度そのものの重み付けで計算されるとは限りません（ドキュメント上も、リスク優先度がスコアに影響しない旨の注記があります）。
このため、顧客と会話するときは、次のように言葉を揃えると誤解が減ります。
- スコア：推奨事項にどれだけ対応できているかの集約指標（改善のトラッカー）
- リスクレベル：未対応の中で、いま放置すると危ないものの優先順位
顧客説明で刺さる「代替の伝え方」：%ではなく“リスクと推移”で語る
公式平均がないなら、顧客が納得しやすい説明材料をこちらで用意します。おすすめは次の4点セットです。
説明セット①：過去→現在の推移（改善の事実）
他社比較の代わりに、自社のベースラインからどれだけ改善したかを示します。セキュア スコア自体も推移を追えますし、スコアの推移レポート（Secure Score Over Time）をWorkbooksで可視化する方法も案内されています。
説明セット②：Critical/Highの残数（“危ないものがどれだけ残っているか”）
Defender for Cloud では、推奨事項をリスクレベル（Critical/High/Medium/Lowなど）で分類し、重大なリスクから対処する考え方が整理されています。
| 見せる指標 | 顧客に伝わる意味 | 例（見せ方） |
|---|---|---|
| Criticalの推奨事項数 | 「今すぐ塞ぐべき穴」が何個あるか | Critical 3件 → 0件（30日で解消） |
| Highの推奨事項数 | 「優先的に潰すべき穴」がどれだけあるか | High 18件 → 7件（毎週-2件ペース） |
| インターネット露出資産に関する推奨事項 | 外部から狙われやすい箇所の改善状況 | 公開管理ポート/過剰許可の解消など |
説明セット③：上位N件の“改善アクション”を合意する
スコアを上げるために全件対応を目指すと、現場は疲弊しがちです。そこで、「影響が大きい推奨事項（上位10件など）を、期限付きで合意」し、実行計画に落とします。これは“スコアを上げる”というより、リスクを減らすためにスコアを使う運用です。
説明セット④：変動検知（“急に下がった”のを見逃さない）
スコアは、VMの稼働状況や組織変更、推奨事項の更新などで上下し得ます。Microsoft社員の回答でも、週次以上で予期せぬ変動を監視し、継続的に改善を目指す運用例が触れられています。
社内で「目標ライン」を作る方法：公式ベンチマークの代わりに“合意済みKPI”を持つ
顧客や社内から「結局、何%を目標にすべき？」と聞かれたら、次のように答えられる状態が理想です。
| 作り方 | ポイント | 目標の例 |
|---|---|---|
| スコアを“唯一の目標”にしない | 数字を上げる行為より、リスクを下げる行為を評価する | スコアは参考、KPIはCritical/Highの削減 |
| 「0にすべきもの」を先に決める | 重大リスクは“閾値”ではなく“原則ゼロ”で合意する | Criticalは常に0（発生したらSLA内で解消） |
| 改善の速度（ペース）を目標にする | 環境拡大で新規課題が出ても、改善が継続しているかを見る | Highを月次で20%削減、または週次で-2件 |
| 除外は「統制された例外」にする | 除外の数・理由・見直し日を可視化し、監査に耐える | 除外は期限付き、四半期で棚卸し |
こうして作った“自社KPI”は、顧客説明でも強い武器になります。なぜなら、公式平均がなくても、「危険なものはゼロ」「改善は継続」「例外は統制」という説明は、どの組織でも理解しやすいからです。
除外（Exempt）をどう扱うか：やりすぎると“良い数字”だけが残る
Defender for Cloud には、推奨事項や特定リソースをExempt（除外）して、スコアや推奨一覧への影響を止める仕組みがあります。除外された推奨事項/リソースはセキュア スコアに影響しないこと、そして既定のフィルターでは「Not applicable」が非表示になり得ることも説明されています。
除外の代表的な使いどころ
| 除外理由（例） | 現実のケース | 運用上の注意 |
|---|---|---|
| 第三者で緩和（Mitigated） | 別製品で制御していて、Defender for Cloud が検知できない | “どのコントロールで代替しているか”を記録しておく |
| リスク受容（Waiver） | ビジネス要件で対応不可（例：レガシー制約） | 期限（見直し日）を付けて、永久放置を防ぐ |
| 技術的に非該当 | その推奨事項が環境に合わない | “本当に非該当か”の判断プロセスを作る |
また、除外の挙動には少しクセがあります。たとえば、推奨事項を「Mitigated」で除外した場合、直接ポイントが付与されるわけではないが、未健全リソースの扱いが変わることで結果としてスコアが上がる、という説明があります。数字だけ見ると“改善したように見える”ため、顧客説明では「除外で上がった分」と「実 remediation で上がった分」を分けて語ると誤解が減ります。
実務テンプレ：顧客へそのまま説明できる話し方
テンプレA：ベンチマーク質問への回答
結論として、セキュア スコアに「80%なら高い」などの公式合格ラインや、Azure全体の平均値は公開されていません。スコアは貴社環境に対する推奨事項の対応状況を集約したもので、リソース構成や適用可否が異なるため、他社と単純比較するよりも、貴社の改善の推移と、未対応項目のリスクレベルで評価するのが現実的です。
テンプレB：今日の状態を短く伝える（1分版）
本日時点のセキュア スコアはXXです。重要なのは点数よりも中身で、現在はCriticalがX件、HighがY件残っています。直近4週間でCriticalはX→0に改善し、HighもY→Y-Δで減少傾向です。次の2週間は、影響が大きい上位10件（特にインターネット露出と権限周り）を優先して対応します。
テンプレC：スコアが下がった時の説明（安心させつつ次アクションへ）
スコアが下がったのは、環境変更（新規リソース追加/推奨事項更新）により“未対応項目が増えた”ためです。異常ではなく、変更の影響を早期に検知できたのが価値です。下げ幅に影響した推奨事項を特定し、Critical/Highから順に対処して元の水準へ戻します。
運用のコツ：スコアを“数字ゲーム”にしないためのチェックリスト
- スコアを見る頻度を決める：週次が基本。急変動の検知が目的。
- 毎回「Critical/Highの残数」とセットで報告：%だけの報告を避ける。
- 除外は申請制にする：理由・代替コントロール・見直し日を必須にする。
- 上位N件で改善を回す：全件潰しの理想論より、重要項目を確実に減らす。
- 推移を残す：Workbooksの「Secure Score Over Time」や、継続的エクスポート（Continuous export）で履歴を持つ。
スコア推移を“ちゃんと資産化”する：Secure Score Over Time と継続的エクスポート
顧客説明に強いのは、やはり「推移」です。Defender for Cloud には Workbooks ギャラリーがあり、Secure Score Over Time workbook（スコア推移を可視化するテンプレート）も含まれます。
また、スコアや推奨事項を外部に出して、Power BI や SIEM、運用レポートに組み込むなら、Continuous export（継続的エクスポート）を使う構成が一般的です。Microsoft Learn では、継続的エクスポートが Log Analytics や Event Hubs などにストリーミングできることが説明されています。
“履歴がない”問題を避けるための実務ポイント
- 運用開始時点でベースライン（初回スコア、Critical/High数、上位推奨事項）を保存する
- 週次レポートは「スコア」「Critical/High数」「トップ改善」「除外件数」を固定フォーマット化する
- スコアが一定以上下がったらアラート（Teams/メール/チケット）に落とす
Microsoft Secure Score との混同に注意（検索ユーザー向け補足）
「Secure score」という言葉は、Defender for Cloud だけでなく、Microsoftの他領域（ID、デバイス、SaaSなど）でも使われます。Microsoft Learn でも、クラウド領域は Cloud Secure Score として、より広い文脈の “Microsoft secure score” の一部であることが整理されています。
そのため、検索や資料作成では、「Microsoft Defender for Cloud のセキュア スコア（Cloud Secure Score / Secure score）」と明記し、Microsoft 365側の Microsoft Secure Score（Defender XDR）と混同しないようにすると、読者の迷子が減ります。
参考資料（公式ドキュメント/動画）
顧客へ「根拠として公式情報も示したい」という場面では、次の資料が参考になります。
- Microsoft Learn：Cloud secure score in Microsoft Defender for Cloud（概要、計算、追跡、2つのモデル）
- Microsoft Learn：Exempt resources from recommendations（除外の考え方と挙動）
- Microsoft Learn：Review security recommendations（リスク優先度・リスクレベルの説明）
- Microsoft Learn：Azure Monitor workbooks with Defender for Cloud data（Secure Score Over Time workbook）
- Microsoft Learn：Continuous export（Log Analytics / Event Hubs 等への継続的エクスポート）
- Microsoft Learn：Defender for Cloud release notes（Cloud Secure Scoreのリスクベース化など最新動向）
- YouTube：Defender for Cloud のセキュア スコアを解説する製品担当PMの動画（Q&Aで案内されているもの）
よくある落とし穴（FAQ）
「スコアが高いのにインシデントが起きた」ことはありますか？
あり得ます。セキュア スコアは“推奨事項への準拠度”を集約した指標であり、侵害されない保証ではありません。だからこそ、%の高さで安心せず、Critical/Highの未対応を潰す運用が重要です。
「100%を目指すべきですか？」
思想としては「常に100を目指す」が公式回答に近いです。一方で現実には、すべての推奨事項が常に実行可能とは限りません。そのため、“100を目指して優先順位付けを継続する”という姿勢と、“除外の統制”を両立させるのが実務的です。
「スコアが突然下がる」主な原因は？
| よくある原因 | 起きる現象 | まずやること |
|---|---|---|
| 新規リソース追加 | 推奨事項が増えてスコア低下 | 新規追加分をフィルターして、未対応の中身を確認 |
| 推奨事項の更新/追加 | 何もしていないのにスコアが動く | 新規追加の推奨事項を把握し、影響度を評価 |
| 連携/評価対象の変化 | 評価が欠落・遅延し、指標が不安定になる | 監視対象のカバレッジ（Coverage）を確認 |
| 除外設定の変更 | スコアが上がった/下がったが実態とズレる | 除外ログと理由を確認し、説明可能性を担保 |
まとめ：合格ラインがないからこそ「説明の軸」を持つ
Microsoft Defender for Cloud のセキュア スコアには、%で高い/平均/低いを判定する公式ベンチマークやAzure全体平均が提示されていません。
その代わりに、実務では次の3点を押さえると、顧客説明と運用が一気に安定します。
- スコアは“合否”ではなく継続的改善のトラッカーとして扱う
- Critical/Highの未対応を減らす（%より中身）
- 推移を見せる（Secure Score Over Time / 継続的エクスポートで履歴化）
「平均がない＝説明できない」ではなく、“自社の改善ストーリー”をデータで語れるようになることが、セキュア スコアを最大限に活かす近道です。
コメント