Defender for Cloudのsub-assessments API終了｜個別レコメンデーションへの移行手順

Microsoft Defender for Cloudでsub-assessments APIからデータを取得できなくなった場合、サービス障害として復旧を待つのではなく、個別レコメンデーションへの移行が必要です。

Microsoftは2026年7月31日、旧グループ化レコメンデーションの廃止完了を案内しました。旧データはAPIからアクセスできなくなり、今後はMicrosoft.Security/assessmentsとして公開される個別レコメンデーションを利用します。Azure portalとAzure Resource Graphへの反映には数日かかる可能性があるため、画面に旧レコメンデーションが残っていても、APIが復旧したと判断してはいけません。(Microsoft Learn)

本記事では、旧APIへの依存箇所を見つける方法、Azure Resource Graphクエリの書き換え、レコメンデーションIDの移行、disable rulesからexemptionsへの変更、移行後の検証方法までを具体的に解説します。

Defender for Cloudのsub-assessments API終了で何が変わったのか

旧モデルでは、複数の脆弱性や構成不備を1つの親レコメンデーションにまとめ、その配下にsub-assessmentsとして個別の検出結果を格納していました。

たとえば、仮想マシンに複数の脆弱なソフトウェアが存在していても、画面上は「Machines should have vulnerability findings resolved」という1つのグループ化レコメンデーションとして表示されていました。

新モデルでは、ソフトウェア更新、脆弱性、シークレット、SQL Vulnerability Assessmentのルールなどが、それぞれ独立したレコメンデーションとして扱われます。(Microsoft Learn)

比較項目	旧グループ化レコメンデーション	新しい個別レコメンデーション
データ構造	親レコメンデーションの配下に複数の検出結果	検出内容ごとに独立したレコメンデーション
ARGのリソースタイプ	`microsoft.security/assessments/subassessments`	`microsoft.security/assessments`
主な絞り込み方法	グループ化レコメンデーションID	recommendationCategoryまたは新しい固定ID
優先順位付け	グループ単位	個別の検出結果単位
例外管理	disable rules	exemptions
レポート件数	集約されるため少ない	個別化されるため増えやすい

廃止された旧REST API

旧構成では、次のようなREST APIが利用されていました。

GET https://management.azure.com/{scope}/providers/Microsoft.Security/assessments/{assessmentName}/subAssessments?api-version=2019-01-01-preview

サブスクリプション内のsub-assessmentsを一括取得するAPIもありました。

GET https://management.azure.com/{scope}/providers/Microsoft.Security/subAssessments?api-version=2019-01-01-preview

Microsoft Learnには旧REST APIのリファレンスが残っている場合があります。しかし、リファレンスページが閲覧できることと、実環境でAPIが引き続き提供されていることは別です。2026年7月31日付のリリースノートでは、旧データへAPIからアクセスできなくなったことが明記されています。(Microsoft Learn)

Azure portalやResource Graphに旧データが残る理由

今回の変更では、API、Azure portal、Azure Resource Graphの反映タイミングが完全には一致しません。

Microsoftは、APIから旧データへアクセスできなくなった後も、Azure portalとAzure Resource Graphへの反映に数日かかる可能性があると説明しています。(Microsoft Learn)

そのため、次のような状態が発生しても不思議ではありません。

確認された状態	正しい判断
旧APIからデータを取得できない	廃止による影響として移行を進める
Azure portalに旧グループ化レコメンデーションが表示される	表示更新の遅延である可能性が高い
ARGで旧sub-assessmentsが一時的に検索できる	残存データや反映遅延として扱う
新クエリの取得件数が旧クエリより増えた	個別化による正常な増加か確認する
REST APIのリファレンスページが残っている	APIの継続提供を意味しない

旧データが画面に見えるかどうかではなく、新しい個別レコメンデーションを使った処理が正常に動くかどうかを移行完了の判断基準にします。

影響を受けるシステムと設定

sub-assessments APIを直接呼び出していなくても、関連するクエリやIDを利用している処理は影響を受けます。

Microsoftは、グループ化レコメンデーションに依存していた自動化、レポート、ガバナンス、ワークフロー、クエリを検証するよう案内しています。(Microsoft Learn)

特に確認すべき対象は次のとおりです。

対象	確認ポイント
REST API	URLに`subAssessments`が含まれていないか
Azure SDK	`subAssessments.list`や`listAll`を使用していないか
Azure Resource Graph	リソースタイプが`assessments/subassessments`になっていないか
Power BI・CSVレポート	旧JSONフィールドを展開していないか
Logic Apps・Functions	旧レコメンデーションIDを条件にしていないか
SIEM・データレイク	旧スキーマを前提にパースしていないか
Governance rules	グループ化レコメンデーションキーを指定していないか
Continuous export	旧IDや旧データ形式で出力対象を指定していないか
Disable rules	脆弱性やCVEを抑制する旧ルールが残っていないか

Defender for Cloudのsub-assessments APIから移行する手順

旧APIへの依存箇所を検索する

最初に、アプリケーション、スクリプト、Infrastructure as Code、クエリ、レポート定義から旧APIへの依存を洗い出します。

最低限、次の文字列を検索してください。

subAssessments
subassessments
microsoft.security/assessments/subassessments
2019-01-01-preview
subAssessmentSettings

PowerShellでは、プロジェクトフォルダー内を次のように検索できます。

Get-ChildItem -Path . -Recurse -File -ErrorAction SilentlyContinue |
    Select-String -Pattern `
        'subAssessments',
        'assessments/subassessments',
        '2019-01-01-preview',
        'subAssessmentSettings'

Visual Studio CodeやGitリポジトリでrgを利用できる場合は、次のコマンドでも確認できます。

rg -n -i "subassessments|assessments/subassessments|2019-01-01-preview|subAssessmentSettings" .

検索対象には、ソースコードだけでなく次のファイルも含めます。

ARMテンプレート、Bicep、Terraform
Logic Appsのワークフロー定義
Azure FunctionsやAutomation Runbook
Power BIのPower Query
Azure Workbook
Kustoクエリ
Data FactoryやSynapseのパイプライン
GitHub ActionsやAzure Pipelines
運用手順書に記載された手動クエリ

旧レコメンデーションIDの移行先を確認する

旧レコメンデーションIDを、機械的に1つの新IDへ置き換えてはいけません。

グループ化レコメンデーションの移行先には、主に次の2種類があります。(Microsoft Learn)

移行パターン	新しい指定方法
複数の個別レコメンデーションへ分割される	`properties.metadata.recommendationCategory`で絞り込む
1つの新しいレコメンデーションへ置き換わる	新しい固定レコメンデーションIDを指定する

たとえば、旧レコメンデーション「Machines should have vulnerability findings resolved」のIDは次の値でした。

1195afff-c881-495e-9bc5-1486211ae03f

このレコメンデーションは、単一の新IDへ置き換えるのではなく、SoftwareUpdateカテゴリーの個別レコメンデーションへ移行します。

主なカテゴリーには次のようなものがあります。

旧レコメンデーションの内容	主な移行先カテゴリー
マシンやコンテナーの脆弱性	`SoftwareUpdate`
Azure Update Managerによる更新	`SystemUpdate`
Windows・Linuxの構成不備	`HostMisconfigurations`
マシン内のシークレット検出	`ExposedSecrets`
サービスのアップグレード	`ServiceUpgrade`
コードの脆弱性	`CodeVulnerabilities`
Infrastructure as Codeの問題	`IacVulnerabilities`
APIセキュリティ検出	`ApiVulnerabilities`

一方、一部のID関連レコメンデーションなどは、新しい固定assessment keyへ置き換えられます。このタイプではカテゴリーがUnknownになる場合があるため、カテゴリーだけで検索せず、新しいIDを直接指定します。(Microsoft Learn)

Azure Resource Graphクエリを書き換える

旧クエリでは、次のリソースタイプが使用されていました。

securityresources
| where type =~ "microsoft.security/assessments/subassessments"

移行後は、microsoft.security/assessmentsを対象にします。

次の例は、Azure仮想マシンを対象にSoftwareUpdateカテゴリーの個別レコメンデーションを取得するクエリです。

securityresources
| where type =~ "microsoft.security/assessments"
| extend RecommendationCategory =
    tostring(properties.metadata.recommendationCategory)
| extend Severity =
    tostring(properties.metadata.severity)
| extend ResourceType =
    tostring(properties.resourceDetails.ResourceType)
| extend Source =
    tostring(properties.resourceDetails.Source)
| where RecommendationCategory == "SoftwareUpdate"
| where ResourceType =~ "microsoft.compute/virtualmachines"
| project
    id,
    name,
    RecommendationCategory,
    Severity,
    ResourceType,
    Source,
    properties

CVEや修正バージョンまで展開する場合は、必要なフィールドを追加します。

securityresources
| where type =~ "microsoft.security/assessments"
| extend RecommendationCategory =
    tostring(properties.metadata.recommendationCategory)
| extend ResourceType =
    tostring(properties.resourceDetails.ResourceType)
| where RecommendationCategory == "SoftwareUpdate"
| where ResourceType =~ "microsoft.compute/virtualmachines"
| extend Severity =
    tostring(properties.metadata.severity)
| extend DetectedVersions =
    tostring(properties.additionalData.DetectedSoftwareVersions)
| extend FixedVersion =
    tostring(properties.additionalData.FixedVersion)
| extend CvesDetails =
    parse_json(tostring(properties.additionalData.CvesDetails))
| mv-expand Cve = CvesDetails
| extend CveId = tostring(Cve.CveId)
| project
    id,
    Severity,
    DetectedVersions,
    FixedVersion,
    CveId

Microsoftが示している脆弱性管理の移行例では、主に次のフィールド変更があります。(Microsoft Learn)

旧フィールド	新フィールド
`properties.status.severity`	`properties.metadata.severity`
`properties.additionalData.cve`	`properties.additionalData.CvesDetails`
`properties.additionalData.softwareVersion`	`properties.additionalData.DetectedSoftwareVersions`
`properties.additionalData.recommendedVersion`	`properties.additionalData.FixedVersion`

この対応表は脆弱性レコメンデーションの例です。シークレット、SQL、DevOps、構成不備などではadditionalDataの内容が異なる可能性があります。カテゴリーごとに実際のJSONを取得し、存在しないプロパティを安全に処理できるようにしてください。

SourceとResourceTypeを必ず絞り込む

個別レコメンデーションのカテゴリーは、複数のクラウドやワークロードを横断します。

たとえば、SoftwareUpdateだけを条件にすると、Azure VMだけでなく、EC2、GCP Compute Engine、AKSノード、コンテナーなどの結果まで含まれる可能性があります。Microsoftも、カテゴリーへの移行後は取得範囲が広くなるため、必要に応じてリソースタイプやクラウドソースを追加で絞り込むよう説明しています。(Microsoft Learn)

Azureだけに限定したい場合は、次の条件を追加します。

| where tostring(properties.resourceDetails.Source) == "Azure"

仮想マシンだけを対象にする場合は、ResourceTypeも指定します。

| where tostring(properties.resourceDetails.ResourceType)
    =~ "microsoft.compute/virtualmachines"

カテゴリーだけで集計すると、移行前より大幅に件数が増え、レポートや通知が意図せず拡大することがあります。

REST APIの取得先をassessmentsへ変更する

REST APIを利用している場合は、旧subAssessmentsエンドポイントではなく、Microsoft.Security/assessmentsを取得対象にします。

Microsoftが公開しているassessmentsの一覧APIは次の形式です。(Microsoft Learn)

GET https://management.azure.com/{scope}/providers/Microsoft.Security/assessments?api-version=2020-01-01

サブスクリプションを指定する例は次のとおりです。

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Security/assessments?api-version=2020-01-01
Authorization: Bearer {accessToken}

ただし、URLからsubAssessmentsを削除するだけでは移行できません。

レスポンスの階層、重要度の格納場所、CVE情報、修正バージョン、レコメンデーションIDの使い方が変わっています。旧レスポンス用のクラスやJSONパーサーをそのまま再利用せず、新しいレスポンスを保存してスキーマを確認してください。

Azure SDKを使っている場合も、旧SubAssessmentsクライアントから、利用しているSDKバージョンで提供されるAssessmentsの一覧取得処理へ変更します。SDKのメジャーバージョンによってクラス名やページング方法が異なるため、パッケージ更新とコード変更を同時に行うのではなく、段階的に検証するのが安全です。

レポートと自動化を新しい件数モデルに合わせる

個別レコメンデーションへの移行後は、取得件数が増えるのが通常です。

旧モデルで「1台のVMに10件の脆弱性」が1つのグループとして扱われていた場合、新モデルでは複数の個別レコメンデーションとして取得されます。これはセキュリティリスクが突然増えたことを意味するとは限らず、データの粒度が細かくなった結果です。(Microsoft Learn)

そのため、移行前後の総行数だけを比較してはいけません。

レポートでは、次の指標を分けて集計すると実態を把握しやすくなります。

影響を受ける一意のリソース数
CriticalまたはHighの個別レコメンデーション数
レコメンデーションカテゴリー別の件数
CVE別の影響リソース数
修正可能な脆弱性と修正不能な脆弱性の件数
Azure、AWS、GCP別の件数
新規発生、継続、解消済みの件数

通知やチケット作成では、同じリソースと同じCVEから大量の重複チケットが作られないよう、重複排除キーも見直します。

たとえば、次の項目を組み合わせて一意性を判定します。

assessment ID
対象リソースID
CVE IDまたは検出項目ID
カテゴリー

Governance rulesとContinuous exportを更新する

個別レコメンデーションでは、管理操作の対象も変わります。

複数の個別レコメンデーションへ分割されるタイプでは、グループ化レコメンデーションの固定IDではなく、レコメンデーションカテゴリーを対象にします。カテゴリーを指定することで、現在存在する個別レコメンデーションだけでなく、今後同じカテゴリーに追加されるレコメンデーションも対象にできます。(Microsoft Learn)

確認すべき設定は次のとおりです。

Governance rulesの所有者割り当て
修正期限やSLA
Logic Appsを呼び出すワークフロー自動化
Continuous exportの対象条件
Azure Policyや標準割り当て
Exemption rules
レポートやダッシュボードのフィルター

ただし、固定の新assessment keyへ置き換わるタイプは、カテゴリーではなく新しいIDを直接指定します。移行リファレンスで対象レコメンデーションの移行先を確認してから設定してください。

残っているdisable rulesをexemptionsへ移行する

旧グループ化レコメンデーションで使用していたdisable rulesは、新しい個別レコメンデーションではサポートされません。

Microsoftはexemptionsへの自動移行を提供していないため、既存ルールを確認して手動で再作成する必要があります。(Microsoft Learn)

既存のdisable rulesをAzure Resource Graphで確認する

Microsoftが案内している次のARGクエリで、旧sub-assessment用フィルターを持つポリシー割り当てを抽出できます。

policyresources
| where type =~ "microsoft.authorization/policyassignments"
| extend filters =
    todynamic(properties).metadata.subAssessmentSettings.filters
| where filters != ""

結果が返った場合は、ポリシー名、対象スコープ、CVE、重要度、CVSS、除外理由などを一覧化してください。

disable rulesの条件をexemptionsへ置き換える

主な対応関係は次のとおりです。(Microsoft Learn)

Disable ruleで使用していた条件	Exemptionでの指定方法
レコメンデーションID	Selected recommendations
カテゴリー	Recommendation category
セキュリティチェック	Selected recommendations
CVE	Vulnerabilities条件のCVE
CVSS	Vulnerabilities条件のCVSS
最低重要度	Minimum severity
パッチ提供なし	Non-patchable

exemptionsでは有効期限を設定できます。恒久的な除外にするのではなく、例外の期限と再確認日を設定することで、過去の判断がそのまま残り続けることを防げます。

REST APIでexemptionを作成する場合は、Standard Assignments APIを利用します。

PUT https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Security/standardAssignments/{standardAssignmentName}?api-version=2024-08-01

実際のリクエストでは、effectにExemptを指定し、対象assessment keyやCVE、重要度、CVSSなどの条件を設定します。旧ルールをそのまま広範囲へ適用すると、本来確認すべき新しいレコメンデーションまで除外する可能性があるため、移行時にスコープと条件を再評価してください。(Microsoft Learn)

移行後に実施する検証

APIやクエリを書き換えただけでは、移行完了とはいえません。

自動化、レポート、ガバナンス、例外処理を含め、次の観点で検証します。

検証項目	合格基準
旧API依存	コードや設定に`subAssessments`が残っていない
データ取得	`Microsoft.Security/assessments`から結果を取得できる
ページング	全ページを取得し、途中で欠落しない
スキーマ	nullや存在しないプロパティで処理が停止しない
対象範囲	SourceとResourceTypeが想定どおり絞り込まれている
重要度	`properties.metadata.severity`を参照している
件数	個別化による増加を考慮して比較している
自動化	通知やチケットが重複作成されない
レポート	旧列に依存せず、新しいカテゴリーで集計できる
Governance	カテゴリーまたは新IDへ更新されている
例外設定	disable rulesがexemptionsとして再作成されている
監査	exemptionの理由、承認者、有効期限を確認できる

本番環境へ反映する前に、少なくとも次の3種類のデータでテストしてください。

結果が0件になる環境
少数の個別レコメンデーションがある環境
複数クラウドや大量の脆弱性を含む環境

特に0件時の処理は重要です。旧APIから結果が返らない状態を「脆弱性なし」と判定する実装が残っていると、廃止されたAPIを正常なセキュリティ状態と誤認する可能性があります。

移行時によくある失敗

旧APIの復旧を待ってしまう

今回の変更は一時的な障害ではなく廃止です。再試行回数やタイムアウトを増やしても、根本的な解決にはなりません。

旧IDを1つの新IDへ置き換える

グループ化レコメンデーションの多くは、カテゴリー配下の複数レコメンデーションへ分割されます。必ず公式の移行リファレンスで、カテゴリー移行なのか固定ID移行なのかを確認します。(Microsoft Learn)

recommendationCategoryだけで全件取得する

SoftwareUpdateなどのカテゴリーは複数のクラウドやリソースを含みます。SourceとResourceTypeを追加しないと、通知数や集計値が想定以上に増えることがあります。

移行前後の行数を直接比較する

旧モデルと新モデルではデータの粒度が異なります。総行数ではなく、一意の対象リソース数や重要度別件数で比較してください。

Azure portalに旧表示があるため移行を戻す

Azure portalとAzure Resource Graphには反映遅延があり得ます。旧表示の残存をAPI復旧の根拠にしてはいけません。(Microsoft Learn)

Disable rulesを放置する

旧ルールは新モデルに自動移行されません。ARGで残存設定を抽出し、必要なものをexemptionsとして再作成します。(Microsoft Learn)

まず実施すべき対応

Defender for Cloudのsub-assessments APIが使えなくなった環境では、次の順番で対応すると混乱を抑えられます。

コードと設定からsubAssessmentsへの依存を検索する
使用中の旧レコメンデーションIDを一覧化する
移行リファレンスでカテゴリーまたは新IDへ対応付ける
ARGの対象をmicrosoft.security/assessmentsへ変更する
REST APIとSDKの取得処理、JSONパーサーを更新する
SourceとResourceTypeで対象範囲を絞る
レポートと通知を個別レコメンデーションの件数モデルへ変更する
Governance rulesとContinuous exportを更新する
Disable rulesをexemptionsへ移行する
0件、大量件数、複数クラウドの条件で検証する

最優先で実施すべきなのは、旧APIの再試行ではなく、依存箇所の検索とレコメンデーションIDの対応付けです。Azure portalやAzure Resource Graphに旧データが残っていても、それを移行延期の理由にせず、個別レコメンデーションを基準に自動化と運用を作り直してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Defender for Cloudのsub-assessments API終了｜個別レコメンデーションへの移行手順

Defender for Cloudのsub-assessments API終了で何が変わったのか

廃止された旧REST API

Azure portalやResource Graphに旧データが残る理由

影響を受けるシステムと設定

Defender for Cloudのsub-assessments APIから移行する手順

旧APIへの依存箇所を検索する

旧レコメンデーションIDの移行先を確認する

Azure Resource Graphクエリを書き換える

SourceとResourceTypeを必ず絞り込む

REST APIの取得先をassessmentsへ変更する

レポートと自動化を新しい件数モデルに合わせる

Governance rulesとContinuous exportを更新する

残っているdisable rulesをexemptionsへ移行する

既存のdisable rulesをAzure Resource Graphで確認する

disable rulesの条件をexemptionsへ置き換える

移行後に実施する検証

移行時によくある失敗

旧APIの復旧を待ってしまう

旧IDを1つの新IDへ置き換える

recommendationCategoryだけで全件取得する

移行前後の行数を直接比較する

Azure portalに旧表示があるため移行を戻す

Disable rulesを放置する

まず実施すべき対応

この記事を書いた人

コメント

コメントするコメントをキャンセル

Defender for Cloudのsub-assessments API終了｜個別レコメンデーションへの移行手順

Defender for Cloudのsub-assessments API終了で何が変わったのか

廃止された旧REST API

Azure portalやResource Graphに旧データが残る理由

影響を受けるシステムと設定

Defender for Cloudのsub-assessments APIから移行する手順

旧APIへの依存箇所を検索する

旧レコメンデーションIDの移行先を確認する

Azure Resource Graphクエリを書き換える

SourceとResourceTypeを必ず絞り込む

REST APIの取得先をassessmentsへ変更する

レポートと自動化を新しい件数モデルに合わせる

Governance rulesとContinuous exportを更新する

残っているdisable rulesをexemptionsへ移行する

既存のdisable rulesをAzure Resource Graphで確認する

disable rulesの条件をexemptionsへ置き換える

移行後に実施する検証

移行時によくある失敗

旧APIの復旧を待ってしまう

旧IDを1つの新IDへ置き換える

recommendationCategoryだけで全件取得する

移行前後の行数を直接比較する

Azure portalに旧表示があるため移行を戻す

Disable rulesを放置する

まず実施すべき対応

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル