Microsoft Defender for Endpointを導入済み、またはこれから展開する管理者がまず確認すべきなのは、「自社のOSで同じ機能が使えるとは限らない」という点です。Windows 10/11とWindows Serverでは多くの防御・検出・対応機能を利用できますが、macOSやLinuxでは一部の機能が非対応またはプレビュー扱いになります。
2026年5月29日に公開または更新された公式情報「Supported Microsoft Defender for Endpoint capabilities by platform」は、Microsoft Defender for Endpointの対応機能をWindows、Windows Server、macOS、Linuxのプラットフォーム別に整理したものです。この記事では、単なる対応表の読み替えではなく、管理者や開発者が確認すべき影響範囲、設定、移行、展開時の注意点を実務目線で整理します。
Microsoft Defender for Endpointのプラットフォーム別対応表で分かること
Microsoft Defender for Endpointは、エンドポイント上の脅威を防御、検出、調査、対応するための企業向けセキュリティ基盤です。Microsoft Defenderポータルでは、エンドポイントのシグナルをID、メール、クラウドアプリなどのアラートと関連付け、インシデント全体を追跡できる構成になっています。(Microsoft Learn)
今回確認すべきポイントは、Microsoft Defender for Endpointの機能が「ライセンスを持っていれば全OSで同じように使える」わけではないことです。公式の対応表では、Windows 10/11、Windows Server、macOS、Linuxごとに、予防、防御、検出、対応系の機能が整理されています。(GitHub)
特に重要なのは、次の3点です。
- Windows 10/11とWindows Serverは、ASRルール、Firewall、EDR Block、AIRなどを含めて対応範囲が広い
- macOSとLinuxでもEDR、Advanced Hunting、脆弱性管理、Live Responseなどは利用できるが、予防系の一部機能に差がある
- LinuxではNetwork Protection、Web Protection、Custom network indicatorsなどがプレビュー扱いの機能として示されている
つまり、Defender for Endpointの設計では「全端末を同じポリシーで一括管理する」のではなく、OSごとの対応機能を前提にポリシー、検知ルール、運用手順を分ける必要があります。
主な変更点と管理者が見るべき影響範囲
今回の公式情報で管理者が読み取るべき変更点は、「何か一つの機能が追加された」というより、プラットフォームごとの対応可否を前提に、運用設計を見直す必要がある点です。
影響が大きいのはWindows以外を含む環境
Windows中心の組織では、Microsoft Defender for Endpointの機能差を意識しなくても運用できてしまうことがあります。しかし、開発部門でmacOSを使っている、Linuxサーバーを運用している、クラウド環境にLinux VMが多い、といった環境では注意が必要です。
たとえば、Windows 10/11ではAttack Surface Reduction（ASR）ルールが利用できますが、macOSとLinuxでは公式対応表上は非対応です。ASRルールを前提にしたマルウェア対策やOfficeマクロ対策を、macOSやLinuxにも同じように適用できると考えると、実際の防御範囲にギャップが生まれます。(GitHub)
サーバーはライセンスとオンボーディング方式を再確認する
Windows ServerやLinuxサーバーをDefender for Endpointにオンボードする場合、クライアントOSとは別にサーバー向けライセンスが必要です。公式ドキュメントでは、Microsoft Defender for Servers Plan 1/Plan 2、Microsoft Defender for Endpoint for servers、Microsoft Defender for Business serversなどが選択肢として示されています。(Microsoft Learn)
特にWindows Server 2012 R2やWindows Server 2016を運用している場合は、モダンな統合ソリューションの利用が前提になります。古いMMAベースの構成が残っている環境では、機能差や運用負荷だけでなく、将来的な移行計画にも影響します。(Microsoft Learn)
Linuxのプレビュー機能は本番展開の扱いに注意する
Linuxでは、Network Protection、Web Protection、Custom network indicatorsがプレビュー扱いとして記載されています。プレビュー機能は検証には有用ですが、本番環境の必須統制として設計する場合は、対象ディストリビューション、エージェントバージョン、サポート条件、ロールバック手順を必ず確認してください。(GitHub)
本番サーバーでプレビュー機能を有効化する場合は、全台展開ではなく、代表的なワークロードを持つ少数のサーバーから段階的に検証するのが安全です。
OS別に見るMicrosoft Defender for Endpoint対応機能の要点
以下は、管理者が実務で判断しやすいように、公式の対応表を運用観点で整理したものです。
| 機能領域 | Windows 10/11 | Windows Server | macOS | Linux | 実務上の見方 |
|---|---|---|---|---|---|
| ASRルール | 対応 | 対応 | 非対応 | 非対応 | Windows中心の攻撃面縮小策。Office、スクリプト、実行ファイル対策で重要 |
| Device Control | 対応 | 非対応 | 対応 | 非対応 | USB制御などを設計する場合、サーバーとLinuxは別手段も検討 |
| Firewall | 対応 | 対応 | 非対応 | 非対応 | Windowsファイアウォール管理をDefender運用に含める場合に重要 |
| Network Protection | 対応 | 対応 | 対応 | 対応、プレビュー扱い | Linuxでは本番適用前に検証が必要 |
| Next-generation protection | 対応 | 対応 | 対応 | 対応 | 基本のマルウェア対策として全OSで確認したい領域 |
| Tamper Protection | 対応 | 対応 | 対応 | 表上は明示的な対応なし | 改ざん防止の設計はOS別に確認 |
| Web Protection | 対応 | 対応 | 対応 | 対応、プレビュー扱い | 悪性サイトやカテゴリ制御の運用方針に影響 |
| Advanced Hunting | 対応 | 対応 | 対応 | 対応 | KQLによる横断調査の中核 |
| Custom file indicators | 対応 | 対応 | 対応 | 対応 | ファイルハッシュベースの許可・ブロック運用に使う |
| Custom network indicators | 対応 | 対応 | 対応 | 対応、プレビュー扱い | IP/URL/ドメインベースの制御でLinuxは慎重に検証 |
| EDR Block | 対応 | 対応 | 非対応 | 非対応 | 他社AV併用時の追加防御としてWindowsで重要 |
| Passive Mode | 対応 | 対応 | 対応 | 対応 | 既存AVからの移行期間に重要 |
| AIR | 対応 | 対応 | 非対応 | 非対応 | 自動調査・修復はWindows中心に設計 |
| Live Response | 対応 | 対応 | 対応 | 対応 | 端末調査や緊急対応の共通基盤として活用しやすい |
| 脆弱性管理 | 対応 | 対応 | 対応 | 対応 | デバイスの露出管理や修復優先度付けに有効 |
この表から分かる通り、Windows 10/11とWindows Serverは「防御、検出、対応」を一体で設計しやすい一方、macOSとLinuxでは一部の防御機能を別製品、OS標準機能、MDM、構成管理ツールで補完する設計が必要です。
Windows 10/11端末で確認すべき設定
Windows 10/11はMicrosoft Defender for Endpointの対応機能が最も広く、管理者にとっては展開効果が出やすい領域です。ただし、機能が多い分、誤検知や業務影響にも注意が必要です。
ASRルールはAuditから始める
ASRルールは、Officeマクロ、スクリプト、資格情報の窃取、疑わしい子プロセスなどを抑制する強力な機能です。ただし、業務アプリ、社内ツール、署名されていないスクリプトを多用している環境では、いきなりBlockにすると業務停止につながることがあります。
Microsoftは、標準保護ルールはBlockまたはWarnで有効化できる場合がある一方、その他のASRルールはAuditモードで検証してからBlockまたはWarnに切り替える考え方を示しています。(Microsoft Learn)
実務では、次の順で進めると失敗しにくくなります。
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 事前調査 | 対象部門、業務アプリ、スクリプト、Officeマクロを洗い出す | 開発部門、経理、人事など例外が出やすい部門を把握 |
| Audit設定 | ASRルールをAuditで展開 | どのルールがどのアプリに影響するか確認 |
| 例外設計 | 必要な除外を最小限で作成 | ファイルパス全体の広すぎる除外を避ける |
| Warn展開 | 利用者に警告を出しながら段階展開 | ヘルプデスク問い合わせを確認 |
| Block展開 | 影響が小さいルールから本番適用 | 監視、問い合わせ、ロールバック手順を準備 |
EDR Blockは他社AV併用環境で特に重要
既存のウイルス対策製品からMicrosoft Defenderへ移行する場合、すぐにMicrosoft Defender Antivirusをアクティブモードにできないケースがあります。この場合、Defender AntivirusをPassive Modeで動かしながら、EDR Blockによって追加の検出・修復を担わせる設計が候補になります。
ただし、EDR Blockは公式対応表上、Windows 10/11とWindows Serverが対象です。macOSやLinuxにも同じ効果を期待しないよう、移行計画書や運用手順書に明記しておくべきです。(GitHub)
Windows Serverで確認すべき設定と移行ポイント
Windows Serverでは、Defender for Endpointの対応範囲は広いものの、クライアント端末とは確認すべきポイントが異なります。
サーバーライセンスを必ず確認する
Microsoft Defender for Endpoint Plan 1/Plan 2だけでは、サーバーオンボーディング用のライセンスは含まれません。サーバーをオンボードするには、Microsoft Defender for Servers Plan 1/Plan 2などのサーバー向けライセンスが必要です。(Microsoft Learn)
ありがちな失敗は、Microsoft 365 E5を持っているため「サーバーもそのまま対象」と誤解することです。サーバー台数、Azure上のVM、オンプレミスサーバー、他クラウド上のVMを棚卸しし、どのライセンスで保護するのかを整理してください。
Windows Server 2012 R2/2016はモダン統合ソリューションを確認する
公式情報では、Windows Server 2012 R2とWindows Server 2016について、モダンな統合ソリューションの利用が案内されています。従来のMMAベースの実装から移行することで、オンボーディング手順の簡素化や機能範囲の拡張が見込まれます。(Microsoft Learn)
特に確認したいのは次の項目です。
- MMAエージェントが残っていないか
- Microsoft Defender Antivirusが無効化または削除されていないか
- 最新のSSU、LCU、プラットフォーム更新が適用されているか
- Windows Server 2016ではDefender Antivirus機能が有効で最新化されているか
- OSアップグレード時にオフボードとアンインストールが必要な構成ではないか
Windows Server 2016以前では、Defender for Endpointを入れたままOSアップグレードできないケースが示されているため、サーバー更改やOS更新のプロジェクトとDefender移行を別々に進めると手戻りが発生します。(Microsoft Learn)
macOSで確認すべきポイント
macOSでは、Next-generation protection、Advanced Hunting、Custom indicators、Vulnerability Management、Live Responseなどの重要機能が利用できます。一方で、ASRルール、Firewall、EDR Block、AIRなど、Windows前提の運用機能はそのまま使えません。(GitHub)
そのため、macOSを含む環境では「Windowsと同じ防御ポリシーを展開する」のではなく、次のように役割分担を考えます。
- マルウェア対策とEDR検知はDefender for Endpointで統一する
- 構成管理やデバイス制御はIntuneやJamfなどの管理基盤と組み合わせる
- ファイアウォールやOS設定はmacOS標準機能やMDMプロファイルで管理する
- Live Responseを利用するSOC手順をWindowsとは別に整備する
開発者向けMacでは、ビルドツール、ローカルサーバー、パッケージマネージャー、コンテナ関連ファイルが検査対象になります。パフォーマンス影響や誤検知が出やすいパスを事前に洗い出し、必要な除外を最小限で設計してください。
Linuxで確認すべきポイント
Linuxでは、サーバー用途での導入が多く、Windowsクライアントとは運用リスクが異なります。公式対応表では、Next-generation protection、Advanced Hunting、Sense detection sensor、Vulnerability Management、Live Responseなどが対応しています。一方で、ASRルール、Device Control、Firewall、EDR Block、AIRは対応表上では利用対象外です。(GitHub)
Linux運用で特に注意したいのは、プレビュー扱いの機能です。Network Protection、Web Protection、Custom network indicatorsはLinuxでプレビューとされているため、重要サーバーにいきなり展開するのは避けるべきです。(GitHub)
Linuxサーバーでは、次のような観点で検証します。
| 確認項目 | 具体例 | 判断基準 |
|---|---|---|
| 対象ディストリビューション | Ubuntu、RHEL、SLESなど | Defender for Endpointのサポート対象バージョンか |
| ワークロード影響 | Web、DB、CI/CD、コンテナホスト | CPU、I/O、レイテンシへの影響が許容範囲か |
| 更新方式 | パッケージ管理、構成管理ツール | Ansible、Chef、Puppet、手動展開など既存運用と合うか |
| 通信要件 | プロキシ、FW、閉域網 | Defenderクラウドサービスと安定通信できるか |
| 緊急対応 | Live Response、隔離、調査手順 | SOCがLinuxコマンド前提で対応できるか |
Linuxは「Defenderを入れたからWindowsと同じ統制になる」と考えるのではなく、EDRと脆弱性管理の可視化を軸にしながら、OS標準のアクセス制御、ログ管理、構成管理と組み合わせるのが現実的です。
オンボーディング方式は管理基盤に合わせて選ぶ
Microsoft Defender for Endpointの展開では、OSごとに利用できるオンボーディング方式が異なります。公式ドキュメントでは、WindowsクライアントはIntune、Configuration Manager、Group Policy、ローカルスクリプトなど、Windows Serverはローカルスクリプト、Defender for Cloud、Configuration Manager、Group Policyなどが選択肢として示されています。macOSではIntune、Jamf Pro、ローカルスクリプト、MDM、LinuxではAnsible、Chef、Puppet、SaltStack、手動展開、Defender for Cloud連携などが候補になります。(Microsoft Learn)
選定の目安は次の通りです。
| 環境 | 推奨しやすい方法 | 理由 |
|---|---|---|
| Microsoft Intuneで端末管理しているWindows/macOS | Intune | ポリシー配布、準拠性、レポートを一元化しやすい |
| オンプレミス中心のWindows環境 | Configuration ManagerまたはGroup Policy | 既存の配布基盤を活用しやすい |
| Azure VMやマルチクラウドのサーバー | Defender for Cloud連携 | サーバー保護とクラウドセキュリティを統合しやすい |
| Linuxサーバーが多い環境 | Ansibleなどの構成管理ツール | パッケージ展開、設定変更、更新をコード化しやすい |
| 小規模検証、DMZなど管理基盤がない環境 | ローカルスクリプト | 少数台での検証に向く |
注意点として、ローカルスクリプトは便利ですが、台数が増えると展開状況、失敗端末、バージョン差異の管理が難しくなります。本番展開では、できるだけIntune、Configuration Manager、Defender for Cloud、構成管理ツールに寄せるべきです。
段階展開で見るべき成功条件
Defender for Endpointは、最初から全社・全サーバーに展開するよりも、リングベースで段階展開する方が安全です。公式ドキュメントでも、Evaluate、Pilot、Full deploymentのようなリングを使い、各段階で条件を満たしてから次へ進む考え方が示されています。(Microsoft Learn)
実務では、次のような成功条件を設定します。
| 展開段階 | 対象例 | 成功条件 |
|---|---|---|
| 評価 | IT部門、SOC、検証サーバー | デバイスインベントリに表示される、センサーが正常、検出テストが成功 |
| パイロット | 各部門の代表端末、代表サーバー | 業務アプリ影響が許容範囲、アラート運用が回る |
| 本番第1波 | リスクの低い一般端末 | 問い合わせ件数、誤検知、パフォーマンスに問題がない |
| 本番拡大 | 重要部門、サーバー群 | ロールバック手順と例外申請フローが整っている |
| 全体最適化 | 全社対象 | 脆弱性管理、EDR、インシデント対応が定常運用に入る |
特にASRルールやNetwork Protectionのように業務影響が出やすい機能は、展開リングを分けるだけでなく、部門ごとのチャンピオンを決めてフィードバック経路を用意しておくと、問題の早期発見につながります。
更新チャネルと運用体制も確認する
Defender for Endpointは導入して終わりではありません。Microsoft Defenderのコンポーネント更新は、EDR、Next-generation protection、Attack Surface Reductionなどの保護機能に関わります。Microsoftは月次更新について段階的リリースの仕組みを説明しており、Beta、Preview、Staged、Broadなどのチャネルを使って更新タイミングを制御できます。(Microsoft Learn)
本番環境では、次のような分け方が現実的です。
- 検証端末：BetaまたはPreview
- 情シス・SOC端末：PreviewまたはStaged
- 一般端末の一部：Staged
- 重要サーバー、本番端末の大部分：Broadまたは慎重な段階展開
- 影響を極力抑えたい重要環境：必要に応じて遅延設定を検討
ただし、更新を遅らせすぎると、新しい脅威への防御が遅れる可能性があります。セキュリティ製品の更新は「安定性」と「防御力」のバランスが重要です。
管理者・開発者が今すぐ確認すべきチェックリスト
Microsoft Defender for Endpointのプラットフォーム別対応機能を確認したら、次に行うべきことは自社環境への落とし込みです。
| 確認項目 | 管理者が見るポイント | 開発者・運用担当が見るポイント |
|---|---|---|
| OS棚卸し | Windows、Server、macOS、Linuxの台数とバージョン | 開発用Mac、Linuxビルドサーバー、コンテナホストの有無 |
| ライセンス | クライアント用とサーバー用の不足がないか | 検証環境や一時VMも対象に含めるか |
| 対応機能 | OSごとに使える機能と使えない機能を整理 | Windows前提の検知・防御に依存していないか |
| オンボーディング | Intune、ConfigMgr、Defender for Cloud、スクリプトのどれを使うか | CI/CDや構成管理ツールと衝突しないか |
| 通信要件 | プロキシ、FW、DNS、閉域網の制約 | ビルド環境やサーバーがクラウドへ通信できるか |
| 既存AV | Passive Mode、EDR Block、除外設定 | 開発ツールやスクリプトが誤検知されないか |
| ASR/保護設定 | Audit、Warn、Blockの段階設計 | マクロ、スクリプト、社内ツールへの影響 |
| サーバー移行 | MMA、旧エージェント、統合ソリューションの状態 | メンテナンス時間、再起動、ロールバック |
| 運用手順 | アラート対応、Live Response、隔離手順 | 障害時に誰へ連絡するか |
| 更新管理 | 更新チャネル、検証リング | 更新後のビルド失敗や性能劣化の確認 |
このチェックリストを使い、まずは「利用中のOS」と「使いたいDefender機能」を突き合わせてください。ここでギャップが見つかれば、追加のMDM設定、OS標準機能、既存セキュリティ製品、運用手順で補完する必要があります。
よくある失敗と回避策
全OSに同じポリシーを割り当ててしまう
Windows向けのASRルールやFirewall設定を前提にしたポリシーを、macOSやLinuxにも同じ考え方で展開すると、期待した防御効果が得られません。OSごとに対応機能が異なるため、ポリシーグループはWindowsクライアント、Windows Server、macOS、Linuxで分けるのが基本です。
サーバーライセンスを後回しにする
端末展開だけを先に進め、サーバー保護を後で考えると、監視対象に抜けが出ます。特にインターネット公開サーバー、ドメインコントローラー、ファイルサーバー、CI/CDサーバーは攻撃時の影響が大きいため、ライセンスとオンボーディング方式を早めに決めてください。
プレビュー機能を本番前提で設計する
Linuxの一部機能はプレビュー扱いです。プレビュー機能は検証価値がありますが、業務継続に直結する必須統制として設計する場合は慎重に判断しましょう。代替策や無効化手順を用意してから展開することが重要です。
除外設定を広くしすぎる
誤検知対策としてフォルダー全体を除外すると、攻撃者に悪用される余地を作ることがあります。除外は、対象ファイル、プロセス、パス、ハッシュなどをできるだけ限定し、定期的に棚卸ししてください。
オンボーディング成功だけで完了扱いにする
デバイスがポータルに表示されることは第一歩です。実際には、検出テスト、アラート確認、Live Responseの権限確認、脆弱性管理の表示、更新チャネル、インシデント対応手順まで確認して初めて運用開始といえます。
まずはOS別の機能ギャップを可視化する
Microsoft Defender for Endpointのプラットフォーム別対応情報は、単なる仕様表ではなく、セキュリティ運用の設計図として使うべき資料です。Windows 10/11とWindows Serverでは多くの防御・検出・対応機能を活用できますが、macOSやLinuxでは機能差やプレビュー扱いの領域を前提にした設計が必要です。
管理者が次に取るべき行動は明確です。まず、自社の端末とサーバーをOS別に棚卸しし、公式対応表と照合してください。そのうえで、ライセンス、オンボーディング方式、ASRやWeb Protectionなどの有効化方針、既存AVからの移行、サーバーの統合ソリューション対応を順番に確認します。
最も避けたいのは、「Defenderを導入したから全端末が同じレベルで守られている」と思い込むことです。プラットフォームごとの違いを理解し、足りない部分を設定・運用・別機能で補完できれば、Microsoft Defender for EndpointはWindows中心の環境だけでなく、macOSやLinuxを含むハイブリッド環境でも強力な防御基盤になります。
コメント