Microsoft Defender Antivirus health reportの確認ポイント｜2026年6月更新で管理者が見るべき影響範囲

Microsoft Defender for Endpoint の Device health Microsoft Defender Antivirus health report は、組織内デバイスのウイルス対策状態を確認するためのレポートです。結論から言うと、管理者が最初に見るべきポイントは「Microsoft Defender Antivirus が有効に動いているか」「エンジン・セキュリティインテリジェンス・プラットフォームが最新か」「Unknown や No data available の端末が放置されていないか」の3点です。公式ドキュメントでは、このレポートで antivirus status と Microsoft Defender Antivirus の engine、intelligence、platform versions を追跡できると説明されています。(Microsoft Learn)

あわせて、2026年6月2日の関連公式変更として、Microsoft Defender for Endpoint の接続先一覧に reflector.defender.microsoft.com が追加されています。厳格なプロキシやファイアウォール制御をしている環境では、ヘルスレポートの数値だけを見るのではなく、接続先・更新経路・オンボード条件までセットで確認することが重要です。(Microsoft Learn)

Microsoft Defender Antivirus health reportで分かること

Device health の Microsoft Defender Antivirus health report は、単なる「定義ファイルのバージョン一覧」ではありません。Defender for Endpoint にオンボードされた端末について、ウイルス対策の動作モード、最近のスキャン結果、エンジン・セキュリティインテリジェンス・プラットフォームのバージョンと更新状態を確認するための運用レポートです。

Microsoft Defender ポータルでは、Reports から Device health and compliance を開き、Microsoft Defender Antivirus health タブで確認します。公式情報では、このタブに8種類のカードがあり、Microsoft Defender Antivirus の機能状態と更新状態を把握できるとされています。(Microsoft Learn)

確認項目	実務での見方
Antivirus mode	Active、Passive、Disabled、Others、EDRBlocked の状態を確認する
Recent antivirus scan results	クイックスキャン・フルスキャンの完了、キャンセル、失敗を確認する
Antivirus engine version	マルウェア検出エンジンのバージョンが古くないか確認する
Antivirus security intelligence version	セキュリティインテリジェンス、いわゆる定義情報が古くないか確認する
Antivirus platform version	Microsoft Defender Antivirus のプラットフォーム更新が適用されているか確認する
Engine / Security intelligence / Platform updates	Up to date、Out of date、Unknown の比率を確認する

特に重要なのは、バージョン番号を単体で見るのではなく、端末が「なぜ古いのか」まで追うことです。たとえば、同じ Out of date でも、WSUSの承認漏れ、端末の長期オフライン、プロキシ遮断、クラウド保護の無効化、古いOSビルドなど、原因はまったく異なります。

2026年6月2日の関連変更で見るべき接続先の影響

2026年6月2日の Microsoft Defender for Endpoint の接続先リストでは、reflector.defender.microsoft.com が Common endpoints に追加されました。この接続先は IPv6 接続性のプローブに使われる任意のエンドポイントとして説明されています。(Microsoft Learn)

この変更だけで、すべての環境に即時の設定変更が必要になるとは限りません。ただし、次のような環境では確認対象に入れるべきです。

環境	確認すべきこと
プロキシ許可リストを厳格に管理している	新しい接続先がブロックされていないか確認する
ファイアウォールでFQDN単位の制御をしている	Defender for Endpoint の最新URLリストと差分を照合する
閉域・半閉域ネットワークで運用している	WSUS、ConfigMgr、UNC共有、ミラー配布などの更新経路を再確認する
Unknown の端末が増えている	接続先、クラウド保護、レポート更新イベントの到達状況を切り分ける
macOS / Linux を含む混在環境	Windowsだけでなく、LinuxやmacOSの更新URL・リポジトリも確認する

Defender for Endpoint の接続先一覧では、オンボードと維持に必要なURL、更新用URL、証明書検証用URLなどが整理されています。たとえば、コア機能では *.endpoint.security.microsoft.com、更新では Windows Update 系や Defender のセキュリティインテリジェンス配布先が示されています。(Microsoft Learn)

今回のポイントは「レポートの見方」と「接続・更新条件」の両方

Microsoft Defender Antivirus health report を使う際、画面に表示された Up to date や Unknown だけで判断すると誤った対応になりがちです。今回の確認ポイントは、レポートの表示仕様と、端末が正しく報告できる前提条件を分けて整理することです。

項目	変更・確認ポイント	管理者の対応
接続先	2026年6月2日に reflector.defender.microsoft.com が追加	プロキシ、FW、SSLインスペクション、許可リストを確認
レポート対象	Defender for Endpoint にオンボードされた端末が対象	未オンボード端末を別途棚卸しする
古いWindows	Windows 10 1607 LTSB などは Sense バージョン要件を満たせない場合がある	OSアップグレードまたは対象外管理を検討
Windows Server 2012 R2 / 2016	Device health report に表示するには modern unified solution package でのオンボードが必要	MMAベースの古いオンボード方式を見直す
最新状態の判定	Signature refresh time が7日超の場合、Unknown または No data available になり得る	端末の通信、クラウド保護、更新経路を確認
API連携	JSONレスポンスとファイル経由の取得方法がある	小規模はJSON、大規模はプレビュー扱いを理解して設計

公式ドキュメントでは、端末がレポートに正しく表示されるための条件として、Defender for Endpoint へのオンボード、対象OS、MsSense.exe のバージョン要件が示されています。また、Windows Server 2012 R2 と Windows Server 2016 については、modern unified solution package でオンボードする必要があるとされています。(Microsoft Learn)

影響を受ける主な環境

今回の内容で特に影響を受けやすいのは、次のような環境です。

対象	影響
Microsoft Defender for Endpoint Plan 2 を利用している組織	Device health レポートの確認対象
Windows 10 / Windows 11 端末	Antivirus mode、更新状態、スキャン結果の確認対象
Windows Server 2012 R2 / 2016	modern unified solution package でのオンボード確認が必要
Windows Server 2019 / 2022	更新経路、EDRセンサー、Defender Antivirus の状態確認が必要
macOS / Linux	プラットフォームバージョン、クラウド保護、更新元の確認が必要
プロキシ・閉域ネットワーク環境	Defender for Endpoint のURL許可、更新配布方法、証明書検証の確認が必要
APIでレポートを集計している環境	API権限、スロットリング、履歴保存設計の見直しが必要

なお、最新状態の判定に関する公式情報では、Windows の up-to-date reporting は Windows 10 1809 以降、一定以上の engine version、platform version、Sense version、Cloud Protection enabled などの条件を満たす端末で生成されると説明されています。Linux と macOS についても、一定以上の platform version が条件として示されています。(Microsoft Learn)

管理者が最初に確認すべき設定

レポート閲覧権限

Device health and antivirus compliance report を確認するには、Microsoft Defender ポータルで必要な権限が付与されている必要があります。公式情報では、View Data の Threat and vulnerability management (TVM) 権限が必要とされています。また、Microsoft は最小権限のロール利用を推奨しており、Global Administrator は緊急時などに限定すべき高権限ロールと説明しています。(Microsoft Learn)

実務では、セキュリティ運用担当者にGlobal Administratorを付けるのではなく、レポート確認に必要なロールだけを割り当てます。委託先やSOCが閲覧する場合も、RBACグループ単位で見える端末範囲を整理しておくと、後の監査で説明しやすくなります。

オンボード状態とセンサー要件

レポートに端末が出ない、または一部項目が Unknown になる場合、まずオンボード状態を確認します。古いWindowsでは Microsoft Defender for Endpoint センサーのバージョンがOSビルドに依存し、単体でアップグレードできないケースがあります。公式情報では、Windows 10 2016 LTSB 1607 は MsSense.exe 10.1407.* を使用し、Windowsを新しいビルドへアップグレードしない限り 10.8210+ に到達できないと説明されています。(Microsoft Learn)

ここでの失敗例は、古いOSの端末を「Defenderの更新漏れ」として扱ってしまうことです。実際には、OSやオンボード方式そのものがレポート要件を満たしていない可能性があります。対策は、Defenderの再インストールではなく、OSアップグレードや modern unified solution への移行です。

更新経路

Microsoft Defender Antivirus は、セキュリティインテリジェンス、エンジン、プラットフォームを継続的に更新して運用します。公式情報では、セキュリティインテリジェンス更新は構成可能なスケジュールで実行され、プラットフォーム更新は月次更新として提供されると説明されています。更新配布方法としては、Windows Update、WSUS、Microsoft Configuration Manager、通常のWindows更新配布、UNCファイル共有などが挙げられています。(Microsoft Learn)

WSUSやConfigMgrを使う場合は、承認ルールと配布リングを確認します。特に「一部の端末だけ古い」場合、更新元の障害ではなく、対象コレクション、境界グループ、メンテナンスウィンドウ、再起動待ちが原因になっていることがあります。

クラウド保護

Unknown や No data available が多い場合は、クラウド保護の有効化も確認します。公式情報では、up-to-date reporting の条件に Cloud Protection enabled が含まれています。(Microsoft Learn)

閉域環境では、更新ファイルの配布だけに注目しがちです。しかし、Defender for Endpoint のヘルス情報やクラウドベースの保護は、接続先やプロキシ設定の影響を受けます。更新は成功しているのにポータル上は Unknown になる場合、端末ローカルの状態とクラウドへの報告状態を分けて調査してください。

Unknown と No data available をどう切り分けるか

Unknown は「安全」でも「最新」でもありません。公式情報では、up-to-date status は Up to date、Out of date、No data available の3状態で示され、端末が7日を超えてレポートと通信していない場合、Unknown または No data available として扱われると説明されています。(Microsoft Learn)

表示	よくある原因	確認する場所	対応例
Unknown	端末が長期間オフライン	Last seen、資産管理台帳	退役端末か稼働端末かを判別
Unknown	Signature refresh time が7日超	レポートの詳細列	ネットワーク、プロキシ、更新元を確認
No data available	クラウド保護が無効	Defenderポリシー、Intune、GPO	Cloud Protection を有効化
Out of date	更新元に到達できない	Windows Update、WSUS、ConfigMgrログ	更新配布ルールと到達性を確認
Out of date	段階的ロールアウト中	更新リング、対象グループ	影響範囲を見て計画的に展開
Disabled	Defender Antivirus が無効化	Antivirus mode、ポリシー	意図したサードパーティAV運用か確認
Passive	別のAVが主製品として動作	EDRオンボード状態、AV製品	Passive運用でも更新が継続されているか確認

公式情報では、No data available や Unknown の原因例として、端末がネットワークから切断されている、電源オフや休止状態、Microsoft Defender Antivirus の無効化、Macデバイス、クラウド保護の無効化、前提条件未達などが挙げられています。(Microsoft Learn)

開発者・自動化担当者が確認すべきAPI連携

ポータルでの確認だけでは、数千台以上の端末を継続監視するには限界があります。Microsoft Defender Antivirus health report はAPIでのエクスポートも用意されています。公式情報では、JSONレスポンス方式は10万台未満の小規模組織に適し、ファイル経由の方式は10万台を超える大規模組織向けに、より大量のデータを高速かつ信頼性高く取得する方法として説明されています。ただし、ポータル側の説明では、一般提供はJSON Responseで、files経由やAdvanced Huntingのカスタムクエリはパブリックプレビュー扱いとされています。(Microsoft Learn)

API連携で特に注意したいのは、取得できるデータが「現在状態のスナップショット」であり、履歴データではない点です。過去推移を見たい場合は、日次または定期的に取得して、自社のデータストアに保存する必要があります。(Microsoft Learn)

開発時は、次の点を設計に入れてください。

項目	注意点
権限	JSON方式では Application の Machine.Read.All、Delegated の Machine.Read などが必要
トークン	一部APIでは legacy resource の https://api.securitycenter.microsoft.com を要求する場合がある
レート制限	APIには呼び出し回数制限があるため、全件取得ジョブは分割する
履歴管理	API結果はスナップショットのため、自社側で時系列保存する
Unknown の扱い	False と同じ扱いにせず、通信不良・前提条件未達として分類する
バージョン比較	バージョン文字列の固定比較ではなく、公式リリース情報と組み合わせて評価する

APIの例は次のような形式です。実装では、RBAC、ページング、再試行、スロットリング、ログ出力を必ず組み込みます。

GET https://api.security.microsoft.com/api/deviceavinfo
Authorization: Bearer {token}

公式情報では、/api/deviceavinfo が Microsoft Defender Antivirus device antivirus health details を取得するAPIとして示されています。ODataフィルター、$top、$skip も利用できますが、サポートされるプロパティに制限があります。(Microsoft Learn)

現場で使える確認手順

Microsoft Defender ポータルで全体傾向を確認する

まず、Microsoft Defender ポータルで Reports、Device health and compliance、Microsoft Defender Antivirus health の順に開きます。最初に確認するのは、全体の割合です。

見る順番は、次の流れが実務的です。

順番	確認内容	判断基準
1	Antivirus mode	Disabled、Others、意図しない Passive がないか
2	Recent antivirus scan results	スキャン失敗・キャンセルが集中していないか
3	Security intelligence updates	7日超の古い状態がないか
4	Engine updates	月次更新が適用されているか
5	Platform updates	古いプラットフォームや再起動待ちが残っていないか
6	Unknown	端末オフライン、通信遮断、前提条件未達を切り分ける

一部のカードでは、古いバージョンをクリックすると詳細フライアウトを開き、対象端末を確認できます。古いバージョンの場合は Remediation required や Security recommendation への導線が表示されることがあります。(Microsoft Learn)

端末ローカルでも状態を確認する

ポータル表示と端末の実状態がずれる場合は、Windows端末でローカル状態を確認します。PowerShell の Get-MpComputerStatus は、インストールされているマルウェア対策ソフトウェアの状態を取得するコマンドです。(Microsoft Learn)

Get-MpComputerStatus |
  Select-Object AMRunningMode,
                AntivirusEnabled,
                AMEngineVersion,
                AMProductVersion,
                AntivirusSignatureVersion,
                AntivirusSignatureLastUpdated,
                QuickScanEndTime

この結果でローカルの定義やエンジンが新しいのに、ポータルで Unknown のままなら、端末からクラウドへの報告経路、プロキシ、証明書検証、Defender for Endpoint センサーの状態を疑います。逆に、ローカルでも古い場合は、更新元、WSUS承認、ConfigMgr配布、Windows Update到達性を確認します。

移行・展開時に失敗しやすいポイント

古いサーバーをMMAのまま残す

Windows Server 2012 R2 や Windows Server 2016 を長く運用している環境では、古い Microsoft Monitoring Agent ベースのオンボードが残っていることがあります。公式情報では、これらのサーバーを Device health reports に表示するには modern unified solution package でオンボードする必要があるとされています。(Microsoft Learn)

サーバー移行では、Defenderのポリシーだけでなく、オンボード方式、EDRセンサー更新、KB5005292、プロキシ設定まで含めて計画してください。

Passive を安全と誤解する

サードパーティ製AVを併用している場合、Microsoft Defender Antivirus が Passive mode になることがあります。Passive mode自体が直ちに誤りとは限りませんが、公式情報では Passive mode でもMicrosoft Defender Antivirusを最新に保つことが重要とされています。(Microsoft Learn)

「主製品ではないから更新しなくてよい」と考えるのは危険です。EDR、脆弱性管理、検出補助、将来の切り替えを考えると、Passive運用でも更新状態を監視するべきです。

Unknown を単純に除外する

レポート作成時に Unknown を集計から外すと、実態よりも健全に見えてしまいます。Unknown は「未評価」や「報告不能」を含むため、むしろ優先的に分類すべきグループです。

おすすめの分類は次の4つです。

分類	例	対応
廃止・休眠端末	Last seen が古く、資産管理上も利用なし	資産台帳から整理
通信問題	稼働中だが Signature refresh time が古い	プロキシ、FW、証明書、URL許可を確認
更新問題	端末は報告しているがバージョンが古い	WSUS、ConfigMgr、Windows Updateを確認
前提条件未達	古いOS、古いSense、古いオンボード方式	OS更新または移行計画に入れる

更新リングの差を障害と決めつける

Microsoft Defender Antivirus のプラットフォームやエンジン更新は段階的に展開されることがあります。公式情報でも、月次更新は段階的にリリースされ、WSUSに複数パッケージが表示される場合があると説明されています。(Microsoft Learn)

全端末のバージョンが一時的に一致しないこと自体は、必ずしも障害ではありません。重要なのは、対象リング内で異常に遅れている端末や、7日超の報告停止端末を見つけることです。

セキュリティ運用での実用的な対応フロー

実務では、次の順番で進めると対応漏れを減らせます。

ステップ	作業	成果物
1	Defender for Endpoint の最新接続先リストを確認	プロキシ・FW変更要否
2	Microsoft Defender Antivirus health report を確認	Out of date と Unknown の台数
3	フライアウトまたはCSV/APIで端末一覧を出力	対象端末リスト
4	原因を「通信」「更新」「ポリシー」「前提条件未達」に分類	対応優先度
5	WSUS、ConfigMgr、Intune、GPO、プロキシを修正	是正内容
6	次回レポート更新後に再確認	改善率と残課題
7	定期エクスポートを自動化	監査・月次報告用データ

優先度は、Disabled、Out of date、Unknown の順ではなく、業務影響とリスクで決めます。たとえば、インターネット公開サーバーや管理者端末、重要業務端末で Disabled や Unknown が出ている場合は、台数が少なくても先に対応すべきです。

管理者が今すぐ行うべきこと

まず、Microsoft Defender for Endpoint の接続先一覧を確認し、2026年6月2日に追加された reflector.defender.microsoft.com を含め、自社のプロキシ・ファイアウォール許可リストとの差分を確認します。次に、Microsoft Defender Antivirus health report で Disabled、Out of date、Unknown の端末を抽出します。

そのうえで、端末を次のように分けて対応してください。

対象端末	次の対応
稼働中で Unknown	通信、クラウド保護、レポート更新イベント、プロキシを確認
Out of date	更新元、WSUS承認、ConfigMgr配布、Windows Update到達性を確認
Disabled	意図した構成か、ポリシー逸脱かを確認
古いWindows / 古いServer	OS更新、modern unified solution、移行計画を検討
大規模環境	APIで定期取得し、履歴を自社側に保存

Microsoft Defender Antivirus health report は、見るだけのダッシュボードではなく、端末保護の穴を見つけるための運用起点です。今回の確認では、表示されているバージョンだけでなく、接続先、更新経路、オンボード方式、クラウド保護、API運用まで含めて見直すことが、実効性のあるセキュリティ対策につながります。