Microsoft Defender for Endpoint on macOSで「保護が有効なはずなのに動いていない」「盾アイコンに×が出る」「mdatp healthでunavailableになる」とき、最初に疑うべきはDefender本体の故障ではなく、macOSのシステム拡張・ネットワーク拡張・フルディスクアクセスなどの承認不足です。特にIntune、Jamf、その他MDMでMacを管理している環境では、アプリのインストール完了だけでなく、必要な構成プロファイルが端末に配布されているかを確認することが重要です。
2026年6月2日に更新されたMicrosoft Defender for Endpoint on macOSの公式ページでは、macOS版DefenderがAppleのSystem Extensionアーキテクチャ上で動作し、Intune、Jamf、その他MDM、Microsoft Defenderポータルと連携して管理できることが整理されています。関連する「Troubleshoot system extension issues in Microsoft Defender for Endpoint on macOS」では、システム拡張が未承認の場合の症状、原因、確認コマンド、MDMプロファイルの確認ポイントが示されています。(Microsoft Learn)
Microsoft Defender for Endpoint on macOSのシステム拡張トラブルでまず見るべきポイント
Microsoft Defender for Endpoint on macOSのシステム拡張トラブルは、次のように考えると切り分けやすくなります。
| 確認観点 | 起きやすい問題 | 管理者が最初に確認すること |
|---|---|---|
| System Extension | Endpoint Security Extensionが承認されず、リアルタイム保護が使えない | systemextensionsctl listとmdatp health --details system_extensions |
| Network Extension / Network Filter | ネットワークイベントの取得やネットワーク保護が期待通り動かない | Network Filter用プロファイルの配布状況 |
| Full Disk Access | full_disk_access_enabled: falseになり、監視や保護が不完全になる | PPPC/TCCプロファイル、手動展開時の権限付与 |
| Background Services | Defender関連サービスがバックグラウンド実行できない | Background Services用プロファイル |
| Notifications | ユーザー通知やアクション要求が見えにくい | 通知設定プロファイル |
| MDM配布 | 端末によって正常・異常が混在する | Intune、Jamf、MDMの割り当て、同期、除外グループ |
macOS Big Sur 11以降では、システム拡張は端末上で明示的に承認される必要があります。Microsoft Defender for Endpointもこの仕組みに依存しているため、アプリがインストールされていても、OS側の承認やMDMプロファイルが不足していると正常に動作しません。(Microsoft Learn)
今回の公式情報で管理者が押さえるべき変更点
今回確認すべきポイントは、「新しいマルウェア対策エンジンに置き換わった」という話ではありません。運用上の影響が大きいのは、macOS版Defenderの前提がSystem Extension、Network Extension、フルディスクアクセス、MDMプロファイルに強く依存している点です。
また、Intuneを使っている場合は特に注意が必要です。Microsoftは、IntuneのmacOS extensionsポリシーサポートが2024年8月のサービスリリースで非推奨になり、既存ポリシーは動作し続けるものの、新規作成はできないと説明しています。新しいIntuneポリシーでは、Settings catalogを使ってSystem Extension payloadを構成する必要があります。(Microsoft Learn)
| 変更・確認ポイント | 影響 | 対応方針 |
|---|---|---|
| macOS版DefenderはSystem Extensionアーキテクチャ前提 | OS権限が不足すると、保護機能が「有効設定」でも実際には使えない | インストール後にmdatp healthで実効状態を確認する |
| Intuneの旧macOS extensionsポリシーは新規作成不可 | 新規展開や再設計時に旧手順を流用できない | Settings catalogでSystem Extension payloadを作る |
| Network ExtensionとEndpoint Security Extensionの両方が必要 | 片方だけ承認されても保護やイベント取得が不完全になる | Bundle IDとTeam IDを正しく登録する |
| フルディスクアクセスやバックグラウンド実行も必要 | システム拡張だけ承認しても正常動作しないことがある | PPPC、Background Services、Notificationsも同時に確認する |
| 手動承認に頼ると端末ごとに差が出る | リモートワーク端末や開発者端末で未承認が残りやすい | 可能な限りMDMでプロファイル配布する |
なお、Microsoft Learn上では、macOS版Microsoft Defender for Endpointの全体ページは2026年6月2日更新と表示されています。一方、システム拡張トラブルシュート個別ページでは別の更新日表示があるため、社内告知や変更管理では「macOS版全体ページの更新」と「トラブルシュート手順の参照」を分けて記録しておくと安全です。(Microsoft Learn)
影響範囲：どのMacが確認対象になるか
影響を受けやすいのは、Microsoft Defender for Endpointを導入している、またはこれから導入するmacOS端末です。特に次の端末は優先して確認してください。
| 対象 | 優先度 | 理由 |
|---|---|---|
| 新規導入したMac | 高 | インストール後に承認プロファイルが未適用のまま残りやすい |
| Intuneで新規ポリシーを作る環境 | 高 | 旧macOS extensionsポリシーではなくSettings catalog対応が必要 |
| Jamfで構成プロファイルを分けている環境 | 高 | System Extension、PPPC、Network Extensionの一部だけ不足することがある |
| MDM未参加、または手動展開のMac | 高 | ユーザー操作による承認漏れが起きやすい |
| 開発者用Mac | 中〜高 | コンパイラ、ビルドツール、パッケージマネージャーが大量のファイルアクセスを発生させる |
| 複数のEDR/AV製品を併用しているMac | 中〜高 | 競合やパフォーマンス問題が発生しやすい |
すでにmdatp healthが正常なMac | 中 | 直ちに障害対応は不要だが、MDM移行時は再確認が必要 |
Microsoft Defender for Endpoint on macOSの公式ページでは、macOS版がMicrosoft Defenderポータル、Intune、Jamf、その他MDMと連携し、EDR、次世代保護、ネットワーク保護、改ざん防止などの機能を提供することが説明されています。つまり、単なるウイルス対策アプリではなく、OS権限・MDM・クラウド接続を含めたエンドポイント管理の一部として見る必要があります。(Microsoft Learn)
よくある症状：盾アイコンの×とmdatp healthを見逃さない
システム拡張が未承認の端末では、Microsoft Defenderの盾アイコンに×が表示されることがあります。公式トラブルシュートでは、この状態で「Action needed」を選ぶ流れや、mdatp healthでリアルタイム保護が有効でも利用不可と報告される例が示されています。(Microsoft Learn)
端末でまず実行するコマンドは次の2つです。
mdatp healthmdatp health --details system_extensions問題がある場合、次のような状態が見つかることがあります。
healthy : false
health_issues : ["no active event provider", "network event provider not running", "full disk access has not been granted"]
real_time_protection_enabled : unavailable
real_time_protection_available : unavailable
full_disk_access_enabled : falseまた、システム拡張そのものの状態は次のコマンドで確認します。
systemextensionsctl list[activated waiting for user]のような状態が見える場合、Defenderの拡張機能が端末上では検出されているものの、ユーザーまたはMDMによる承認が完了していない可能性があります。(Microsoft Learn)
原因の切り分け：インストール済みでも「承認済み」とは限らない
Microsoft Defender for Endpoint on macOSのシステム拡張トラブルでよくある誤解は、「Defenderアプリがインストールされているから保護も動いているはず」と判断してしまうことです。実際には、インストール、オンボーディング、システム拡張の承認、ネットワークフィルター、フルディスクアクセス、バックグラウンド実行がそろって初めて、期待した状態に近づきます。
| 見つかった状態 | 想定原因 | 次に確認すること |
|---|---|---|
network_extension_installed: trueだがnetwork_extension_enabled: false | Network Extensionは入っているが承認・有効化されていない | Network Filterプロファイル、System Extension payload |
endpoint_security_extension_installed: trueだがendpoint_security_extension_ready: false | Endpoint Security Extensionが未承認 | System ExtensionのBundle ID、Team ID、配布対象 |
full_disk_access_enabled: false | PPPC/TCCプロファイル不足、または手動許可漏れ | Full Disk Accessプロファイル、DLP利用時はAccessibilityも確認 |
| Profilesが端末に見えない | MDM未参加、MDM同期失敗、割り当て漏れ | Intune/Jamf側のデバイス状態、除外グループ、同期 |
| 一部端末だけ失敗 | OSバージョン、管理方法、既存セキュリティ製品の差 | 正常端末と異常端末でプロファイル一覧を比較 |
| CPU使用率が高いが拡張は有効 | システム拡張問題ではなくパフォーマンス問題の可能性 | Activity Monitor、top、リアルタイム保護統計 |
公式ドキュメントでは、MDM管理下で不足している可能性があるファイルとして、System Extension、Network Filter、PPPC/TCC、Notifications、Background Services、Accessibilityに関する管理プロファイルが挙げられています。ここを見落とすと、mdatp healthの一部だけが異常な状態で残ります。(Microsoft Learn)
Intune環境で確認すべき設定
IntuneでMicrosoft Defender for Endpoint on macOSを展開している場合、まず旧macOS extensionsポリシーを新規作成しようとしていないかを確認します。既存ポリシーは動作し続けるとされていますが、新規作成はSettings catalogを使う流れに変わっています。(Microsoft Learn)
IntuneでSystem Extensionを承認する際の重要値は次のとおりです。
| 項目 | 設定値 |
|---|---|
| Allowed System Extensions | com.microsoft.wdav.epsext、com.microsoft.wdav.netext |
| Team identifier | UBF8T346G9 |
| Allowed System Extension Types | NetworkExtension、EndpointSecurityExtension |
| Profile type | Settings catalog |
| Platform | macOS |
実務では、次の順番で確認するとミスを減らせます。
- Intune管理センターで対象ポリシーのProfile typeがSettings catalogになっているか確認する。
- Settings pickerでSystem Extensions関連の設定を追加しているか確認する。
- Bundle IDとTeam IDに誤字がないか確認する。
- 対象デバイスグループにMacが含まれているか確認する。
- 端末側で
mdatp health --details system_extensionsを実行する。 - Intuneのレポートで、成功、競合、エラー、未適用の端末を確認する。
Settings catalogではポリシー単位や設定単位の状態確認、競合確認、割り当て失敗の確認ができます。システム拡張の問題に見えても、実際には「ポリシーが配布されていない」「別ポリシーと競合している」ケースがあるため、端末ログだけでなくIntune側のレポートも確認しましょう。(Microsoft Learn)
Jamf環境で確認すべき設定
Jamfでは、System Extensions、Privacy Preferences Policy Control、Network Extensionを分けて確認します。MicrosoftのJamf向け手順では、System Extension承認にTeam ID UBF8T346G9を使い、com.microsoft.wdav.epsextとcom.microsoft.wdav.netextをAllowed System Extensionsに追加する流れが示されています。(Microsoft Learn)
Jamfで特に注意したいのは、Full Disk AccessとNetwork Extensionです。System Extensionだけを承認しても、PPPCが不足していればフルディスクアクセスが有効にならず、Network Extension用のポリシーが不足していればネットワーク関連機能が期待通りに動作しません。
| Jamfで見る場所 | 確認内容 |
|---|---|
| Configuration Profiles > System Extensions | Team ID、Bundle ID、Allowed System Extensions |
| Privacy Preferences Policy Control | com.microsoft.wdav.epsextへのFull Disk Access許可 |
| Network Extension Policy | Defenderのネットワーク拡張が有効化される構成 |
| Smart Group / Scope | 対象Macがプロファイル配布対象に入っているか |
| 端末側Profiles | 実際にプロファイルが降りているか |
Jamfではプロファイルのスコープ設計が原因で、パイロット端末だけ正常、本番端末だけ異常という状況も起きます。正常端末と異常端末を1台ずつ選び、プロファイル名、Payload、Bundle ID、Team IDを比較すると原因を見つけやすくなります。
その他MDMや手動展開での注意点
IntuneやJamf以外のMDMでも、Microsoft Defender for Endpoint on macOSを展開できる場合があります。ただし、Microsoftは公式にサポートする展開・管理ツールとしてIntuneとJamfを挙げており、その他MDMについては、macOSの.pkg配布、システム構成プロファイル配布、管理者権限でのツールやスクリプト実行などをMDM側が備えているかが前提になります。(Microsoft Learn)
その他MDMで確認するべき最低条件は次のとおりです。
| 条件 | 不足した場合の問題 |
|---|---|
wdav.pkgを改変せず配布できる | インストール失敗や更新失敗の原因になる |
| onboarding情報を正しいドメインで配布できる | Defenderポータルに端末が正しく登録されない |
| System Extension用mobileconfigを配布できる | Endpoint Security ExtensionやNetwork Extensionが承認されない |
| PPPC/TCCプロファイルを配布できる | Full Disk Accessが有効にならない |
| スクリプト実行や状態収集ができる | 障害時に集中管理で切り分けにくい |
手動展開の場合、インストール後にmacOSのPrivacy & Security設定でシステム拡張を許可し、ネットワークトラフィックのフィルター許可、フルディスクアクセス付与、バックグラウンド実行の確認が必要です。Microsoftは手動インストールでプライバシーとセキュリティ設定の変更が必要になること、またインストールパッケージの再パッケージ化はサポート対象外であり、改ざんアラートや更新失敗につながる可能性があると説明しています。(Microsoft Learn)
開発者端末ではパフォーマンス問題も同時に見る
開発者用Macでは、システム拡張の未承認とパフォーマンス問題が混同されやすい点に注意してください。たとえば、Xcode、コンパイラ、Node.jsやPythonのパッケージ管理、Docker関連の処理、CI用スクリプトなどは、短時間に大量のファイルアクセスを発生させます。この場合、システム拡張が正常でも、リアルタイム保護のスキャン負荷が目立つことがあります。
Microsoftのパフォーマンストラブルシュートでは、アプリケーションやシステムプロセスが短時間に多くのリソースへアクセスする場合、Defender for Endpoint on macOSでパフォーマンス問題が起きる可能性があると説明されています。また、Activity Monitorで負荷の高いアプリを確認し、リアルタイム保護統計を使ってスキャンを多く発生させているプロセスを特定する手順も示されています。(Microsoft Learn)
確認に使える代表的なコマンドは次のとおりです。
mdatp health --field real_time_protection_enabledmdatp config real-time-protection-statistics --value enabledmdatp diagnostic real-time-protection-statistics --output json > real_time_protection.json除外設定を検討する場合は、いきなり大きなフォルダーを丸ごと除外するのではなく、実測結果に基づいてプロセス、パス、拡張子を絞るべきです。Microsoftの除外設定ドキュメントでは、除外は誤検知やパフォーマンス問題の緩和に役立つ一方、保護を低下させるため、リスク評価を行い、信頼できるものだけを除外するよう注意されています。(Microsoft Learn)
複数のセキュリティ製品を併用している場合の注意点
他社EDRやアンチウイルス製品とMicrosoft Defender for Endpoint on macOSを併用している環境では、システム拡張トラブルとは別に競合やパフォーマンス問題が起きることがあります。Microsoftは、複数のセキュリティ製品が競合してホストのパフォーマンスに影響する可能性を警告しており、非Microsoftのエンドポイント保護製品を併用する場合は予測しにくい副作用が起こり得ると説明しています。(Microsoft Learn)
実務上は、次のように判断します。
| 状況 | 推奨される確認 |
|---|---|
| Defenderと他社AVが両方リアルタイム保護を実行 | どちらを主たるAVにするか決める |
| 他社EDRからDefender関連プロセスが監視・ブロックされる | 相互除外が必要か確認する |
| Defender導入後にCPU負荷が増えた | wdavdaemon_unprivileged、wdavdaemon_enterpriseなど負荷プロセスを見る |
| セキュリティ要件上、他社製品を外せない | Passive modeを含めた設計を検討する |
| 除外設定を増やしたい | 期限、理由、承認者、対象範囲を記録する |
セキュリティ製品の併用は「入れておけば安全」ではありません。監視対象が重複すると、ファイルアクセスやネットワーク処理を互いに検査し合い、ユーザー体感やビルド時間に影響することがあります。開発者端末では特に、パフォーマンス改善を理由に広範囲な除外を入れすぎないよう、セキュリティチームと開発チームで合意した基準を作っておきましょう。
展開・移行時に失敗しやすいポイント
Microsoft Defender for Endpoint on macOSの展開で失敗しやすいのは、インストール手順そのものよりも、周辺プロファイルの抜け漏れです。次のチェックリストを使うと、展開前レビューや障害対応で確認漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| インストールパッケージ | Microsoft Defenderポータルから取得したwdav.pkgを改変していない |
| オンボーディング | 対象テナントのonboarding packageを使っている |
| System Extension | com.microsoft.wdav.epsextとcom.microsoft.wdav.netextを許可している |
| Team ID | UBF8T346G9を設定している |
| Extension Type | NetworkExtensionとEndpointSecurityExtensionを許可している |
| Network Filter | web content filter関連の構成が端末に配布されている |
| Full Disk Access | PPPC/TCCでDefenderとDefender Security Extensionに許可している |
| Background Services | バックグラウンド実行プロファイルを配布している |
| Notifications | エンドユーザー通知を許可している |
| Accessibility | DLP利用時に必要なAccessibility設定を確認している |
| MDM同期 | 端末がMDM参加済みで、Profilesに構成が見えている |
| 正常性確認 | 展開後にmdatp healthを実行している |
Microsoftのトラブルシュートでは、必要なプロファイルが端末に降りているか確認すること、また構成プロファイルの命名規則を整えることも推奨されています。たとえばFullDiskAccess (piloting) - macOS - Default - MDEのように、設定内容、対象、プラットフォーム、ポリシー種別が分かる名前にしておくと、端末側でプロファイルを確認するときに判断しやすくなります。(Microsoft Learn)
管理者向けの実践手順
障害対応では、闇雲に再インストールするよりも、次の順番で確認する方が早く解決できます。
| 手順 | 作業 | 判断基準 |
| -: | ——————————————— | ———————————————————————— |
| 1 | 端末でmdatp healthを実行 | healthy、health_issues、full_disk_access_enabledを見る |
| 2 | mdatp health --details system_extensionsを実行 | Network ExtensionとEndpoint Security Extensionの状態を見る |
| 3 | systemextensionsctl listを実行 | activated waiting for userがないか確認 |
| 4 | macOSのProfilesを確認 | System Extensions、Accessibility、Background Services、Notificationsなどが見えるか |
| 5 | MDM管理画面を確認 | 配布成功、競合、エラー、除外グループを確認 |
| 6 | 正常端末と異常端末を比較 | プロファイル、OS、Defenderバージョン、MDM状態の差を見る |
| 7 | 必要ならプロファイルを修正して再同期 | いきなり再インストールせず、まず構成を直す |
| 8 | 修正後にmdatp healthを再確認 | unavailableやfalseが解消しているか確認 |
端末がMDM未参加の場合、Profiles自体が表示されないことがあります。この場合はDefenderの問題として扱う前に、MDM登録、ユーザー承認済みMDM、プロファイル配布対象、同期状態を確認してください。
社内運用で決めておくべき判断基準
システム拡張トラブルを一度直しても、運用ルールが曖昧なままだと再発します。特にMacの台数が多い組織では、次の基準を決めておくと安定します。
| ルール | 具体例 |
|---|---|
| 展開完了の定義 | インストール完了ではなく、mdatp healthが正常であることを完了条件にする |
| パイロット対象 | 情シス端末、開発者端末、標準事務端末を最低1台ずつ含める |
| 除外設定の承認 | 開発チーム申請、SecOps確認、期限設定、棚卸しを必須にする |
| Intune移行方針 | 旧macOS extensionsポリシーの棚卸しとSettings catalogへの移行計画を作る |
| 障害時の一次対応 | 再インストール前にmdatp health、Profiles、MDM配布状況を確認する |
| 端末入れ替え時 | 新規MacにもSystem Extension、PPPC、Network Filterが配布されるか確認する |
独自の観点として、MacのDefender展開では「アプリ配布担当」と「セキュリティ設定担当」が分かれている組織ほど事故が起きやすい点があります。アプリ配布だけ完了しても、PPPCやNetwork Filterが別チーム管理のプロファイルに入っていると、どちらのチームも「自分の作業は終わった」と判断してしまうためです。展開チケットには、インストール、オンボーディング、システム拡張、ネットワーク拡張、フルディスクアクセス、正常性確認までを1つの完了条件として入れておきましょう。
最初にやるべきこと
Microsoft Defender for Endpoint on macOSのシステム拡張トラブルでは、まず代表端末1台でmdatp health、mdatp health --details system_extensions、systemextensionsctl listを実行してください。そこで異常が見つかったら、Defenderの再インストールではなく、Intune、Jamf、その他MDMから配布されるSystem Extension、Network Filter、PPPC/TCC、Background Services、Notificationsの構成プロファイルを確認します。
Intune環境では、旧macOS extensionsポリシーに依存していないかを棚卸しし、新規ポリシーはSettings catalogで作成します。Jamfやその他MDMでは、Team ID、Bundle ID、Network Extension、Full Disk Accessの設定漏れを優先して確認します。
最終的なゴールは、「Defenderがインストールされている状態」ではなく、「macOSが必要な拡張機能と権限を承認し、mdatp healthで保護機能が利用可能と確認できる状態」です。ここを運用基準にすれば、macOSのアップデート、MDM移行、開発者端末の増加があっても、Microsoft Defender for Endpointの保護状態を安定して維持しやすくなります。
コメント