Microsoft Defender for Endpointの最小要件でまず確認すべきなのは、「ライセンス」「対応OS」「ネットワーク接続」「Microsoft Defender ウイルス対策の状態」「展開方法」の5点です。特にサーバーをオンボードする場合は、Microsoft Defender for Endpoint Plan 1/Plan 2だけでは足りず、別途サーバー向けライセンスが必要になる点に注意してください。(Microsoft Learn)
2026年5月29日時点で管理者が押さえるべき実務上のポイントは、単なる“必要スペックの確認”ではありません。Windows 7 SP1やWindows Server 2008 R2 SP1などの旧OS、Windows Server、VDI、プロキシ配下の端末、他社製ウイルス対策と併用している端末では、オンボード方法や移行手順を誤ると、端末がDefenderポータルに表示されない、EDRセンサーが通信できない、保護更新が止まるといった問題につながります。
この記事では、Microsoft公式情報「Minimum requirements for Microsoft Defender for Endpoint」をもとに、Microsoft Defender for Endpointの最小要件、2026年5月末に確認すべき変更点、影響範囲、管理者・開発者が確認すべき設定と展開上の注意点を整理します。
Microsoft Defender for Endpointの最小要件でまず押さえる結論
Microsoft Defender for Endpointの最小要件は、端末をオンボードするための前提条件です。対象はMicrosoft Defender for Endpoint Plan 1、Plan 2、Microsoft Defender for Businessです。公式ドキュメントでは、ライセンス、ハードウェア、ソフトウェア、ネットワーク、データ保存場所、Microsoft Defender ウイルス対策の構成などが要件として整理されています。(Microsoft Learn)
管理者が最初に見るべきポイントは、次の表の通りです。
| 確認項目 | 管理者が見るべきポイント | 見落とした場合の影響 |
|---|---|---|
| ライセンス | クライアント用とサーバー用を分けて確認する | サーバーをオンボードできない、監査でライセンス不足になる |
| OS | Windows、macOS、Linux、Android、iOSの対応状況を確認する | 端末がサポート外になり、期待した機能が使えない |
| 旧OS | Windows 7 SP1、Windows 8.1、Windows Server 2008 R2 SP1の展開方法を個別に確認する | MMA、SCEP、Defender deployment toolの選定を誤る |
| ネットワーク | IPv4、プロキシ、SSL検査、必要URLを確認する | センサー通信やセキュリティインテリジェンス更新に失敗する |
| データ保存場所 | 初回セットアップ時の保存リージョンを確認する | 後から変更できず、データ所在地要件に抵触する可能性がある |
| Defenderウイルス対策 | アクティブ、パッシブ、無効化ポリシー、改ざん防止を確認する | オンボード後もファイル情報や保護更新が正しく機能しない |
| 展開方法 | Intune、Configuration Manager、GPO、Defender deployment toolなどを選ぶ | 展開が二重化し、管理不能な端末が出る |
Microsoft Defender for Endpointの導入で失敗しやすいのは、「対応OSだから大丈夫」と判断してしまうケースです。実際には、サーバーライセンス、プロキシ、Defender Antivirusの状態、旧OSの展開方式まで合わせて確認する必要があります。
2026年5月末に確認すべき主な変更点
Microsoft Learn上の最小要件ページ自体は、オンボードに必要な要件をまとめた中核ページです。一方で、2026年5月末の関連ドキュメント更新では、Defender deployment toolの扱いが実務上の重要ポイントになります。GitHub上の公式ドキュメント履歴では、2026年5月25日に「Defender deployment tool」と「Windows 7 SP1 / Windows Server 2008 R2 SP1向けのDefender endpoint security solution」からプレビュー表記を外す変更が確認できます。(GitHub)
特に影響が大きいのは、旧Windows端末のオンボード方法です。以前は「プレビュー」と見なして慎重に扱っていた管理者も、今後はDefender deployment toolを標準的な候補として評価しやすくなります。ただし、すべての旧OSが同じ方法になるわけではありません。Windows 8.1は引き続きMicrosoft Monitoring Agent、いわゆるMMAを使う扱いが残っています。(Microsoft Learn)
| 変更・確認ポイント | 実務上の意味 | 対応すべき担当 |
|---|---|---|
| Defender deployment toolのプレビュー表記削除 | Windows 7 SP1やWindows Server 2008 R2 SP1の展開候補として検討しやすくなった | セキュリティ管理者、端末管理者 |
| Windows 7 SP1のオンボード方法整理 | Defender deployment toolを使う前提で手順を見直す | 情シス、SOC |
| Windows 8.1はMMA利用が残る | 旧手順を完全に廃止できない環境がある | インフラ管理者 |
| Windows Serverのライセンス要件 | Plan 1/Plan 2だけでサーバーを保護できると誤解しない | ライセンス管理者、クラウド管理者 |
| 展開方式の再選定 | Intune、Configuration Manager、GPO、Defender deployment toolを環境別に使い分ける | デバイス管理チーム |
Defender deployment toolのページでは、対応OSとしてWindows 7 SP1、Windows Server 2008 R2 SP1、Windows Server 2012 R2/2016/2019/2022/2025、Windows 10 1809以降、Windows 11が示されています。また、同ツールは軽量で自己更新するアプリケーションとして、前提条件の処理、旧ソリューションからの移行、ログ出力、コマンドライン展開などを支援します。(Microsoft Learn)
影響範囲は「新規導入」よりも既存環境の棚卸しに大きい
今回の最小要件確認で影響を受けやすいのは、新規導入よりも、すでにMicrosoft Defender for Endpointを一部導入している組織です。端末の世代、サーバーの契約、既存ウイルス対策、プロキシ、VDI、クラウドPCが混在しているほど、要件確認の重要度が上がります。
影響を受けやすい環境
| 環境 | 確認すべきこと | 優先度 |
|---|---|---|
| Windows 10 / Windows 11中心の一般端末 | 対応エディション、IntuneまたはConfiguration Managerの管理状態 | 高 |
| Windows Serverを含む環境 | サーバー向けライセンス、Defender for Cloud連携、オンボード方法 | 高 |
| Windows 7 SP1 / Windows Server 2008 R2 SP1が残る環境 | Defender deployment tool、前提更新、移行計画 | 高 |
| Windows 8.1が残る環境 | MMA、SCEP、プロキシ、廃止計画 | 高 |
| VDI / AVD / Windows 365 | サポートOS、再作成時のデバイス重複、イメージ更新 | 中〜高 |
| プロキシ配下・閉域に近い環境 | WinHTTP、EDR用プロキシ、Defender Antivirus用プロキシ、SSL検査除外 | 高 |
| 他社製ウイルス対策と併用中 | Defender Antivirusのパッシブモード、ELAMドライバー、除外設定 | 高 |
| macOS / Linux / Android / iOS | 各OS別の対応バージョンと機能差 | 中 |
「端末がDefenderポータルに表示されているか」だけでは十分ではありません。センサーが正常に通信しているか、セキュリティインテリジェンスが更新されているか、EDRや脆弱性管理など必要な機能がそのOSで使えるかまで確認する必要があります。
ライセンス要件：サーバーは別枠で確認する
Microsoft Defender for Endpointのライセンス確認で最も多い誤解は、「Microsoft 365 E5やDefender for Endpoint Plan 2があるから、サーバーもそのまま対象になる」というものです。
公式ドキュメントでは、サーバーをDefender for Endpointにオンボードするにはサーバーライセンスが必要とされています。選択肢としては、Defender for Cloudの一部として提供されるMicrosoft Defender for Servers Plan 1またはPlan 2、Microsoft Defender for Endpoint Server、Microsoft Defender for Business serversが挙げられています。(Microsoft Learn)
ライセンス確認の実務ポイント
| 対象 | 確認内容 | 判断基準 |
|---|---|---|
| Windowsクライアント | Plan 1、Plan 2、Microsoft Defender for Businessなど | 必要な機能が次世代保護中心か、EDRや脆弱性管理まで必要か |
| Windows Server | サーバー向けライセンスの有無 | Defender for Cloud連携か、単体サーバーライセンスか |
| 中小企業 | Microsoft Defender for Business serversの対象か | ユーザー数、契約形態、既存Microsoft 365プラン |
| ハイブリッド環境 | Azure上、オンプレミス、他クラウドのサーバー | Defender for Cloudで一元管理するか |
サーバーのライセンス確認は、技術担当だけで完結させない方が安全です。調達担当、Microsoft 365管理者、Azure管理者、セキュリティ責任者を含めて、どのサーバーをどのライセンスで守るのかを一覧化しましょう。
対応OSとハードウェア要件：古いOSほど展開方法に注意する
Microsoft Defender for Endpointは、Windows 10/11、Windows Server、Windows 365 Cloud PC、Azure Virtual Desktop、Azure Localノードのほか、macOS、Linux、Windows Subsystem for Linux、Android、iOSをサポート対象に含めています。(Microsoft Learn)
Windowsデバイスの最小ハードウェア要件は、OS自体の要件と同じです。公式情報では、コア数は最小2、推奨4、メモリは最小1GB、推奨4GBとされています。(Microsoft Learn)
ただし、実務では「最小要件を満たす」だけでなく、「EDR、脆弱性管理、他のセキュリティ製品、業務アプリが同時に動いても耐えられるか」を見る必要があります。特にVDI、古い物理端末、メモリ4GB以下のPCでは、ユーザー体感性能への影響も確認しましょう。
Windows系OSの確認ポイント
| OS・環境 | 確認ポイント |
|---|---|
| Windows 10 / Windows 11 | Enterprise、Education、Pro、Pro Educationなど対象エディションを確認 |
| Windows on Arm | サポート対象だが、利用機能や周辺ソフトとの互換性を検証 |
| Windows Enterprise LTSC | LTSC 2016以降が対象。仮想環境ではLTSC 2019以降が推奨される |
| Windows Enterprise multi-session | Azure Virtual Desktop環境ではオンボード方式とイメージ更新を確認 |
| Windows 7 SP1 | Defender deployment toolを使う前提で移行手順を確認 |
| Windows 8.1 | MMAを使う扱いが残るため、MMA更新と将来廃止計画を確認 |
| Windows Server 2008 R2 SP1 | Defender deployment tool利用時の前提更新と.NET要件を確認 |
| Windows Server 2012 R2以降 | サーバーライセンス、Defender Antivirusの状態、統合エージェントの有無を確認 |
| Windows 365 / AVD | 対応OSであることに加え、再作成・イメージ更新時のデバイス管理を確認 |
| Azure Local | Azure Stack HCI OS 23H2以降のノードが対象 |
Windows 11 24H2 Homeからサポート対象エディションへアップグレードした端末では、オンボード前に DISM /online /Add-Capability /CapabilityName:Microsoft.Windows.Sense.Client~~~~ の実行が必要になる場合があります。該当する端末がある場合は、標準展開手順にこの確認を追加してください。(Microsoft Learn)
OSサポート終了後も「使える」と「安全」は別問題
公式ドキュメントでは、OSサポート終了後もWindowsを使い続けること自体は可能ですが、OS本体の品質更新、新機能、セキュリティ更新は提供されなくなると説明されています。一方、Microsoft Defender for Endpointで保護されたデバイスは、既存チャネルを通じて製品更新を受け取り、検出・保護機能を最新に保つ扱いです。(Microsoft Learn)
ここで重要なのは、「Defender for Endpointが動くから、古いOSを使い続けてよい」という意味ではないことです。OS側の脆弱性修正が止まっている端末は、EDRで検知できても、侵入リスクそのものは残ります。
旧OSが残っている場合は、次の順で判断します。
| 判断項目 | 推奨アクション |
|---|---|
| 業務上どうしても残す必要があるか | アプリ依存、機器依存、ベンダー制約を文書化する |
| ネットワーク分離できるか | VLAN、ファイアウォール、プロキシ制御、アクセス制限を設計する |
| Defender for Endpointで何を監視するか | EDR、ファイル応答、脆弱性管理など利用可能機能を確認する |
| いつ移行するか | 代替アプリ、端末更新、サーバー更改の期限を設定する |
| 例外承認があるか | 情報セキュリティ責任者の承認記録を残す |
旧OSは「オンボードできたら完了」ではなく、「リスクを限定しながら移行まで監視する対象」として扱うのが現実的です。
ネットワーク要件：IPv4、プロキシ、SSL検査がつまずきやすい
Microsoft Defender for Endpointはクラウドサービスと通信します。公式ドキュメントでは、Defender for Endpointクラウドサービスとの通信が期待通りに動作するには、デバイスでIPv4スタックを有効にする必要があるとされています。IPv6のみの構成が必要な場合は、DNS64/NAT64などのIPv6/IPv4移行メカニズムを検討する必要があります。(Microsoft Learn)
また、端末は直接またはプロキシ経由でインターネット接続できる必要があります。プロキシ配下の環境では、EDRセンサー用のプロキシ設定とMicrosoft Defender Antivirus用のプロキシ設定を分けて確認する点が重要です。公式のプロキシ構成ドキュメントでも、EDRとDefender Antivirusの2種類のプロキシ設定を構成する必要があると説明されています。(Microsoft Learn)
プロキシ環境で確認する設定
| 確認項目 | 内容 |
|---|---|
| WinHTTP | Defender for EndpointセンサーはWinHTTPを使って通信する |
| WinINetとの違い | ブラウザーのプロキシ設定だけではセンサー通信を保証できない |
| EDR用プロキシ | テレメトリ、センサー通信、診断データ送信に関係する |
| Defender Antivirus用プロキシ | クラウド提供の保護、更新、EDR in block modeなどに関係する |
| SSL検査 | セキュアなクラウド接続を壊す可能性があるため除外設計が必要 |
| 認証プロキシ | LocalSystemなどサービスコンテキストの通信を考慮する |
| 閉域に近い環境 | 必要URL、証明書失効リスト、Windows Update到達性を検証する |
よくある失敗は、「ブラウザーではインターネットが見えるので問題ない」と判断することです。Defender for Endpointのセンサーはユーザーのブラウザー設定ではなく、システムコンテキストやWinHTTP設定の影響を受けます。オンボード前に、テスト端末でセンサー通信、更新、ポータル反映まで確認しましょう。
データ保存場所：初回セットアップ後に変更できない
Microsoft Defender for Endpointでは、オンボードウィザードを初めて実行するときに、関連情報の保存場所として欧州連合、英国、米国のデータセンターを選択します。公式ドキュメントでは、初回セットアップ後にデータストレージの場所を変更できないとされています。(Microsoft Learn)
これは、グローバル企業や個人情報・機密情報を扱う組織では非常に重要です。日本企業でも、海外拠点、欧州顧客、グループ会社のデータ管理方針によっては、どのリージョンを選ぶかを事前に合意しておく必要があります。
初回セットアップ前に決めておくこと
| 項目 | 確認先 |
|---|---|
| データ保存場所の希望 | セキュリティ責任者、法務、コンプライアンス部門 |
| テナントの利用地域 | Microsoft 365管理者 |
| 海外拠点の扱い | グローバルIT、現地法人 |
| 監査要件 | 内部監査、外部監査、顧客契約 |
| 後から変更できない点の承認 | システムオーナー、情報管理責任者 |
「とりあえずセットアップして後で直す」は避けるべきです。データ保存場所は、技術設定というよりも、ガバナンス上の意思決定として扱いましょう。
Microsoft Defender ウイルス対策の構成要件
Microsoft Defender for Endpointのエージェントは、ファイルをスキャンし、その情報を提供するためにMicrosoft Defender ウイルス対策に依存します。公式ドキュメントでは、Defender Antivirusがアクティブなマルウェア対策かどうかに関係なく、セキュリティインテリジェンス更新を構成する必要があるとされています。(Microsoft Learn)
他社製ウイルス対策を使っている場合、Microsoft Defender ウイルス対策はパッシブモードになることがあります。ここで誤ってDefender Antivirusをグループポリシーなどで完全に無効化していると、Defender for Endpointのオンボードやファイル情報の取得に支障が出る可能性があります。
Defender Antivirusまわりの確認ポイント
| 状態 | 確認すべきこと |
|---|---|
| Defender Antivirusがアクティブ | セキュリティインテリジェンス、プラットフォーム、エンジン更新を管理する |
| 他社製ウイルス対策がアクティブ | Defender Antivirusがパッシブモードで動作するか確認する |
| GPOでDefender Antivirusを無効化 | オンボード対象端末を無効化ポリシーから除外する |
| サーバー環境 | OSバージョンに応じてパッシブモードまたはアンインストール方針を確認する |
| 改ざん防止が有効 | 通常のグループポリシー変更が無視される場合がある |
| MDMまたはConfiguration Managerを利用 | Microsoft Defender Antivirus ELAMドライバーが有効か確認する |
Microsoft Defender ウイルス対策の更新も重要です。公式情報では、Defender Antivirusを最新の状態に保つことは、新しいマルウェアや攻撃手法からデバイスを保護するために重要であり、パッシブモードで実行されている場合でも更新すると説明されています。(Microsoft Learn)
ELAMドライバー：他社製ウイルス対策との併用時に見落としやすい
Microsoft以外のマルウェア対策クライアントを使い、MDMやMicrosoft Configuration Managerで管理している場合は、Microsoft Defender AntivirusのELAMドライバーが有効になっていることを確認する必要があります。ELAMはEarly Launch Antimalwareの略で、起動時に早い段階でマルウェア対策を機能させるための仕組みです。(Microsoft Learn)
実務では、他社製ウイルス対策を導入した際に「Defender関連はすべて無効化」としてしまう設計が残っていることがあります。Defender for Endpointを使う場合、この考え方は危険です。Defender Antivirusをアクティブに使わない場合でも、Defender for Endpointが必要とするコンポーネントまで止めないように設計を見直しましょう。
展開方法の選び方：管理基盤に合わせて選ぶ
Microsoft Defender for Endpointの展開方法は、組織の管理基盤によって変わります。Microsoft公式の展開戦略では、クラウドネイティブ、共同管理、オンプレミス、評価・ローカルオンボードといったアーキテクチャ別に考える流れが示されています。(Microsoft Learn)
環境別の展開方法
| 環境 | 推奨される考え方 |
|---|---|
| Intune中心 | Intune / MDMでオンボード、構成、修復を統合する |
| Configuration Manager中心 | 既存の配布基盤を活かしつつ、必要に応じてIntuneと共同管理する |
| Active Directory中心 | GPOやDefender deployment toolを使い、段階的に展開する |
| 小規模・検証環境 | ローカルスクリプトやDefender deployment toolでパイロットする |
| Windows Server | ローカルスクリプト、Defender for Cloud連携、Defender deployment toolを検討する |
| macOS | Intune、Jamf Pro、ローカルスクリプト、MDMを検討する |
| Linux server | Defender deployment tool、スクリプト、Ansible、Chef、Puppet、Defender for Cloud連携などを検討する |
| Android / iOS | Intuneを中心に展開する |
大切なのは、複数の展開方式を無計画に混在させないことです。たとえば、Intuneでオンボードした端末にGPOやローカルスクリプトを重ねると、トラブル時の原因切り分けが難しくなります。管理単位ごとに「どの方式でオンボードするか」を台帳化しましょう。
Defender deployment toolを使う場合の注意点
Defender deployment toolは、Windows端末のオンボードを効率化するツールです。公式ドキュメントでは、前提条件の確認、ブロッキング問題の修復、ログ出力、重複インストールの回避、UIフィードバック、オンボードイベントの記録、パッシブモード対応、コマンドライン自動化、構成ファイル利用などが機能として整理されています。(Microsoft Learn)
一方で、Defender deployment toolは独自のオンボード方式であり、他のオンボード方法と統合されるものではないとされています。つまり、Intune、Configuration Manager、GPO、ローカルスクリプトとどのように使い分けるかを事前に決める必要があります。(Microsoft Learn)
Defender deployment toolが向いている場面
| 場面 | 理由 |
|---|---|
| 旧Windowsのオンボード | Windows 7 SP1やWindows Server 2008 R2 SP1の展開候補になる |
| GPOで配布したい | コマンドラインパラメーターを使って自動実行できる |
| 既存ソリューションから移行したい | 前提条件確認や旧ソリューションからの移行を支援する |
| 小規模に検証したい | GUIでの対話的なオンボードが可能 |
| 大規模展開前に事前チェックしたい | -PreCheck で前提条件確認を実行できる |
展開前に確認したいコマンド例
DefenderDT.exe -?完全なコマンドリファレンスを確認するための基本コマンドです。
DefenderDT.exe -PreCheck -Verbose -Quiet大規模展開前に、前提条件の確認結果をログとして残したい場合に使いやすい形式です。
DefenderDT.exe -Proxy:192.168.0.255:8080 -AllowReboot -Quietプロキシを指定し、必要に応じて再起動を許可しながら非対話で実行する例です。実際のプロキシアドレス、再起動可否、ログ収集方法は自社環境に合わせて変更してください。
旧OSの移行：Windows 7、Windows 8.1、Server 2008 R2は分けて考える
旧OSを一括りにすると、展開設計を誤りやすくなります。公式情報では、Windows 7 SP1 Pro、Windows 7 SP1 Enterprise、Windows Server 2008 R2 SP1はDefender deployment toolを使う対象として整理されています。一方、Windows 8.1またはWindows 8.1 ProではMMAをインストールして構成する扱いが残ります。(Microsoft Learn)
旧OS別の整理
| OS | 主な方法 | 注意点 |
|---|---|---|
| Windows 7 SP1 Pro / Enterprise | Defender deployment tool | 前提更新、PowerShell、ローカルUI制約、移行計画を確認 |
| Windows Server 2008 R2 SP1 | Defender deployment tool | x64、SHA-2更新、.NET 3.5以上などを確認 |
| Windows 8.1 / 8.1 Pro | MMA | MMAのバージョン、SCEP、プロキシ、将来廃止計画を確認 |
| Windows Server 2012 R2以降 | サーバー向け方式を選択 | サーバーライセンス、Defender Antivirusの状態を確認 |
旧OSでは、機能制限もあります。たとえばWindows 7 SP1やWindows Server 2008 R2 SP1向けのDefender endpoint security solutionでは、利用できない機能や制限があるため、最新OSと同じ保護レベルだと考えない方が安全です。(Microsoft Learn)
展開前チェックリスト
本番展開前に、次の項目を最低限チェックしてください。
| チェック項目 | 確認内容 |
|---|---|
| 端末台帳 | OS、エディション、バージョン、CPU、メモリ、所有部署を把握したか |
| サーバー台帳 | Windows Server、Linux server、クラウドVM、オンプレミスを分類したか |
| ライセンス | クライアント用とサーバー用を分けて確認したか |
| データ保存場所 | 初回セットアップ前にリージョンを承認したか |
| ネットワーク | IPv4、必要URL、プロキシ、SSL検査除外を確認したか |
| Defender Antivirus | アクティブ、パッシブ、GPO無効化、改ざん防止を確認したか |
| 旧OS | Windows 7、Windows 8.1、Server 2008 R2を個別に扱ったか |
| 展開方法 | Intune、ConfigMgr、GPO、Defender deployment toolの役割を決めたか |
| パイロット | 部署、OS、ネットワーク条件を分けて検証したか |
| ロールバック | オフボード手順、ログ収集、問い合わせ先を用意したか |
このチェックリストは、ExcelやSharePointリストで管理すると運用しやすくなります。重要なのは、端末単位で「要件確認済み」「パイロット済み」「本番展開済み」「例外承認済み」を見える化することです。
オンボード後の確認方法
オンボードは、ポリシーを配布した時点では完了ではありません。端末がDefenderポータルに表示され、センサーが通信し、必要な保護機能が動作していることを確認して初めて完了です。
Defender deployment toolのトラブルシューティングでは、ログの場所として C:\ProgramData\Microsoft\DefenderDeploymentTool\DefenderDeploymentTool-<COMPUTERNAME>.log が示されています。また、サービス確認として sense と windefend の状態確認が案内されています。(Microsoft Learn)
基本的な確認コマンド
sc.exe query senseMicrosoft Defender for Endpointセンサーの状態を確認します。
sc.exe query windefendMicrosoft Defender Antivirusサービスの状態を確認します。
ポータル側で確認すること
| 確認箇所 | 見るべき内容 |
|---|---|
| デバイス一覧 | 対象端末が表示されているか |
| デバイスのタイムライン | オンボードイベントやセンサーイベントがあるか |
| アラート | テスト検知や想定外のエラーが出ていないか |
| セキュリティ推奨事項 | 脆弱性管理の情報が取得できているか |
| 高度なハンティング | 端末イベントがクエリ対象になっているか |
| 更新状態 | セキュリティインテリジェンス、エンジン、プラットフォームが古くないか |
本番展開では、「配布成功率」だけでなく「ポータル反映率」「センサー正常率」「更新正常率」をKPIにすると、展開品質を把握しやすくなります。
よくある失敗と回避策
Microsoft Defender for Endpointの最小要件に関するトラブルは、技術的な不具合よりも、事前確認不足で起きることが多いです。
| 失敗しやすいポイント | 原因 | 回避策 |
|---|---|---|
| サーバーがオンボードできない | サーバーライセンスを確認していない | サーバーだけ別台帳で契約を確認する |
| ポータルに端末が出ない | プロキシ、WinHTTP、必要URLの問題 | センサー通信を事前テストする |
| 更新が止まる | WSUS、ConfigMgr、プロキシ、Defender更新元の設定不備 | 更新経路を端末種別ごとに定義する |
| Defender Antivirusが無効 | 過去のGPOでDefenderを止めている | オンボード対象を無効化GPOから除外する |
| 設定変更が反映されない | 改ざん防止が有効 | IntuneやDefenderポータル側の管理方法に合わせる |
| 旧OSで想定機能が使えない | OSごとの機能差を確認していない | 旧OSは機能制限を前提に設計する |
| データ保存場所を誤る | 初回セットアップ時の確認不足 | セットアップ前に承認フローを通す |
| 展開方法が混在する | Intune、GPO、手動スクリプトを併用 | 管理単位ごとに展開方式を固定する |
| VDIでデバイスが重複する | 再作成・ホスト名・イメージ設計の不備 | VDI向けのオンボード設計を別途作る |
特にプロキシとDefender Antivirusの無効化ポリシーは、トラブルの原因になりやすい部分です。パイロット段階で、社内LAN、VPN、プロキシ配下、リモートワーク、VDIなど、通信条件の違う端末を必ず含めましょう。
開発者・SREが確認すべきポイント
Microsoft Defender for Endpointは、情シスやSOCだけでなく、開発者やSREにも影響します。CI/CD、ビルドサーバー、検証環境、VDI、コンテナホスト、スクリプト実行基盤では、EDRやウイルス対策の影響を受ける可能性があります。
開発・運用チーム向けの確認事項
| 対象 | 確認ポイント |
|---|---|
| ビルドサーバー | Defender Antivirusのスキャン影響、除外設定、サーバーライセンス |
| CI/CDエージェント | 一時ファイル、成果物、署名済みバイナリの扱い |
| PowerShellスクリプト | EDR検知、実行ポリシー、管理者権限 |
| 自社アプリ | 誤検知時の連絡経路、署名、ハッシュ管理 |
| VDI開発環境 | マスターイメージ更新、オンボード重複、端末再作成 |
| Linuxサーバー | ディストリビューション対応、カーネル、パフォーマンス影響 |
| API連携 | Defender for Endpoint APIの権限、監査ログ、運用自動化 |
除外設定は、安易に広く入れるべきではありません。たとえば、ビルドディレクトリ全体を無条件に除外すると、攻撃者にとって都合のよい隠れ場所になる可能性があります。除外する場合は、プロセス、パス、拡張子、ハッシュ、署名、期間を絞り、変更履歴を残してください。
移行・展開の進め方
Microsoft Defender for Endpointの展開は、いきなり全社適用するよりも、段階的に進める方が安全です。
| フェーズ | やること | 成果物 |
|---|---|---|
| 棚卸し | 端末、OS、サーバー、ネットワーク、ウイルス対策を洗い出す | 対象端末台帳 |
| 要件確認 | ライセンス、対応OS、プロキシ、データ保存場所を確認 | 要件確認シート |
| 設計 | 展開方式、ポリシー、更新経路、例外ルールを決める | 展開設計書 |
| パイロット | 部署・OS・ネットワーク条件を分けて小規模展開 | 検証結果 |
| 本番展開 | グループ単位で段階的にオンボード | 展開ログ |
| 運用移行 | アラート対応、更新監視、例外管理を定常化 | 運用手順書 |
| 改善 | 未オンボード端末、旧OS、失敗端末を潰す | 改善リスト |
パイロットでは、成功しやすい最新Windows 11端末だけを選ばないことが重要です。サーバー、VPN利用端末、プロキシ配下端末、他社製ウイルス対策が入っている端末、旧OS、VDIを少数ずつ含めると、本番展開前に問題を発見しやすくなります。
管理者が今すぐ確認すべきこと
Microsoft Defender for Endpointの最小要件は、導入前チェックだけでなく、既存環境の見直しにも使えます。まずは次の順番で確認してください。
- Defender for Endpointの対象端末とサーバーを一覧化する
- サーバー向けライセンスが不足していないか確認する
- Windows 7、Windows 8.1、Windows Server 2008 R2 SP1を別枠で抽出する
- Intune、Configuration Manager、GPO、Defender deployment toolのどれで展開するか決める
- プロキシ、IPv4、必要URL、SSL検査除外を確認する
- Microsoft Defender Antivirusが無効化されていないか確認する
- セキュリティインテリジェンスと製品更新の経路を確認する
- データ保存場所を初回セットアップ前に承認する
- パイロット端末でポータル反映、サービス状態、ログ、更新状態を確認する
- 旧OSはオンボードだけで終わらせず、移行期限を設定する
Microsoft Defender for Endpointは、端末を登録して終わる製品ではありません。ライセンス、OS、ネットワーク、ウイルス対策、更新、展開方式がそろって初めて、EDRや次世代保護の効果を発揮します。最小要件を「導入前の形式的なチェック」ではなく、「展開失敗と運用リスクを減らすための設計基準」として使うことが、管理者にとって最も重要です。
コメント