Microsoft Defender の「Deploy endpoint detection and response policy with Intune」は、Microsoft Intune のエンドポイント セキュリティ ポリシーを使って、Defender for Endpoint の EDR 機能を Windows、macOS、Linux デバイスへ展開するための公式ガイドです。まず押さえるべきポイントは、これは単なる“設定手順”ではなく、デバイスを Defender for Endpoint テナントへオンボードし、セキュリティ テレメトリを送信できる状態にするための運用設計資料だという点です。(Microsoft Learn)
2026年7月1日のGitHub履歴では、このページに対して「Metadata updates」としてコミットが記録されています。一方、Microsoft Learn本文の表示上の最終更新日は2026年5月18日、ソースの ms.date も 05/18/2026 のままです。そのため、7月1日更新を「新しいEDR機能が追加された」「移行期限が新設された」と断定するのではなく、グローバル管理者が既存のEDR展開方式、対応OS、接続設定、監視レポート、オフボーディング運用を再点検するタイミングとして捉えるのが安全です。(GitHub)
Microsoft Defender の「Deploy endpoint detection and response policy with Intune」で確認すべき更新ポイント
今回の要点は、Defender for Endpoint の EDR 展開を Intune 側の Endpoint security から管理する流れが明確に整理されていることです。従来のようにオンボーディング パッケージを個別に配布するだけでなく、Intune と Defender for Endpoint のサービス接続を使い、最新のオンボーディング構成を取得してポリシー化する運用が推奨されています。(Microsoft Learn)
特に管理者が見るべきポイントは、次の4つです。
| 確認項目 | 実務上の意味 | 管理者が取るべき対応 |
|---|---|---|
| EDRオンボーディングの位置づけ | デバイスが Defender for Endpoint にテレメトリを送信できる状態にする | EDRポリシーが適用されているだけでなく、Defenderポータルにデバイスが表示されるか確認する |
| 自動展開と手動展開の使い分け | IntuneとDefenderの接続がある場合は Auto from connector を利用しやすい | 単一テナント・標準環境では自動、複数テナントや厳格な変更管理では手動を検討する |
| 対応プラットフォーム | Windows、macOS、Linux、Windows Server 2012 R2以降が対象になり得る | OS別にプロファイル、割り当て先、管理方式を分ける |
| 監視とトラブルシュート | EDR Onboarding Status report でオンボーディング状況を確認できる | Not onboarded、Pending、Inactive、Impaired の端末を定期的に洗い出す |
重要なのは、EDRポリシーは Defender for Endpoint へのオンボーディングとEDR関連設定を扱うものであり、攻撃面の縮小ルール、ファイアウォール、ウイルス対策ポリシー、カスタム検出、脅威ハンティング ルールまで一括で管理するものではないという点です。EDR展開後は、Attack surface reduction、Anti-malware、Firewall、Device compliance などのポリシーを別途設計する必要があります。(Microsoft Learn)
影響範囲：対象はWindowsだけではなくmacOSとLinuxにも広がる
このガイドの対象は Windows に限定されません。公式情報では、Linux、macOS、Windows が対象として示されており、Windows Server 2012 R2以降についても、Configuration Manager の tenant attach または Defender for Endpoint security settings management 経由で管理される場合に対象となります。(Microsoft Learn)
プラットフォーム別に見る管理ポイント
| プラットフォーム | 主なプロファイル | 確認すべきポイント |
|---|---|---|
| Windows | Endpoint detection and response | Auto from connector を使えるか、サンプル共有をどう扱うかを確認する |
| macOS | Endpoint detection and response | Device tags を使って国・部門・用途別に分類できるようにする |
| Linux | Endpoint detection and response、Microsoft Defender Global Exclusions (AV+EDR) | Device tags と除外設定を慎重に設計する |
| Windows Server 2012 R2以降 | Endpoint detection and response (ConfigMgr) | Configuration Manager コレクションへの割り当て、tenant attach、同期状態を確認する |
グローバル企業では、Windows端末だけを前提に設計すると抜け漏れが起きやすくなります。たとえば開発部門のLinuxサーバー、デザイン部門のmacOS、海外拠点のConfiguration Manager管理端末などが混在している場合、単一のWindows向けポリシーではカバーしきれません。
特にLinuxの Global Exclusions は便利ですが、除外を増やしすぎると検出範囲が狭くなります。公式情報でも、グローバル除外は他の除外ソースと結合され、除外範囲の和集合として扱われるため、脅威検出のカバレッジを下げる可能性があるとされています。(Microsoft Learn)
前提条件：ライセンス、権限、サービス接続を先に確認する
EDRポリシーを作成する前に、Intune と Defender for Endpoint の両方で前提条件を満たしているか確認します。公式情報では、Intune 側は Microsoft Intune Plan 1、Defender 側は Defender for Endpoint Plan 1、Microsoft 365 E5/A5/G5に含まれるDefender for Endpoint Plan 2、または Microsoft Defender XDR などが示されています。(Microsoft Learn)
権限確認で失敗しやすいポイント
EDRポリシーの作成には、Intune側で Endpoint Security Manager などの十分なRBAC権限が必要です。さらに、Intune と Defender for Endpoint のサービス接続を構成するには、Microsoft Entra ID の Security Administrator ロール、または同等のカスタム権限が必要です。(Microsoft Learn)
実務では、次のような失敗がよく起きます。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| Create Policy が表示されない、または操作できない | Intune側のRBAC権限不足 | Endpoint Security Manager または必要なカスタム権限を確認する |
| Auto from connector が選べない | IntuneとDefenderの接続が未構成、または反映待ち | Tenant administration で接続状態を確認し、反映まで待つ |
| Defenderポータルに端末が出てこない | ポリシー配布済みでもテレメトリ送信が完了していない | EDR Onboarding Status と Defenderポータルのデバイス一覧を両方確認する |
| 海外拠点だけオンボーディングに失敗する | ネットワーク到達性、プロキシ、セキュリティ製品の競合 | Defender関連エンドポイントへの通信と既存EDR製品との除外を確認する |
Intune と Defender for Endpoint の接続は、Intune管理センターの Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint から構成します。接続が有効になると、Intune は Defender for Endpoint から最新のオンボーディング パッケージを取得し、EDRプロファイルで Auto from connector を利用できるようになります。(Microsoft Learn)
設定変更の見方：既存ポリシーを“置き換える”前に競合を確認する
今回の公式情報を読むうえで重要なのは、「EDRポリシー」と「デバイス構成ポリシー」を混在させたときの競合です。Microsoft Learnでは、EDRポリシー以外に device configuration policy でも Defender for Endpoint へオンボードできる一方、同じデバイス設定を複数のポリシー種別で管理すると競合が発生する可能性があると説明されています。(Microsoft Learn)
たとえば、過去にデバイス構成プロファイルでオンボーディングしていた環境へ、新たに Endpoint security の EDRポリシーを割り当てると、管理者は「新しいEDRポリシーを作ったのに反映されない」「一部端末だけ状態が違う」と感じることがあります。これは機能不具合ではなく、同じ設定領域を複数ポリシーで管理していることが原因の場合があります。
既存環境で確認すべき棚卸し項目
| 棚卸し項目 | 確認場所 | 判断基準 |
|---|---|---|
| 既存のDefenderオンボーディング方法 | Intuneのデバイス構成、Endpoint security、Configuration Manager | 同じ端末に複数方式が重なっていないか |
| EDRポリシーの割り当て | Endpoint security > Endpoint detection and response | グループ、フィルター、除外グループが妥当か |
| Defender接続状態 | Tenant administration > Connectors and tokens | Connected になっているか |
| オンボーディング状態 | EDR Onboarding Status report | Onboarded、Not onboarded、Pending を確認する |
| Defenderポータル側の状態 | Assets > Devices | 端末が表示され、センサー状態が正常か |
設定変更を行う場合は、いきなり全社展開するのではなく、部署・国・OS・管理方式ごとに小さなリングを作り、オンボーディング成功率、センサー状態、業務アプリへの影響を確認してから拡大するのが現実的です。Defender for Endpoint のオンボーディング公式情報でも、段階的なリングベース展開が推奨されています。(Microsoft Learn)
自動展開と手動展開の使い分け
Intune の EDRポリシーでは、大きく分けて自動展開と手動展開の2つの考え方があります。標準的なIntune + Defender for Endpoint構成で、単一のDefenderテナントを使っているなら、自動展開が基本です。一方、複数テナント、エアギャップに近い環境、厳格な変更管理がある環境では、手動でオンボーディング パッケージを扱う方式が選択肢になります。(Microsoft Learn)
| シナリオ | 推奨される考え方 | 理由 |
|---|---|---|
| 標準的なクラウド管理端末 | Auto from connector | IntuneがDefenderから最新の構成を取得できる |
| 全Windows端末へ早く展開したい | Deploy preconfigured policy | EDR Onboarding Status タブから事前構成ポリシーを展開できる |
| 特定部門・特定OSだけに展開したい | カスタムEDRポリシー | 対象グループ、設定、タグを細かく制御できる |
| 複数Defenderテナントがある | 手動EDRポリシー | テナントごとのオンボーディング パッケージ管理が必要になる |
| 変更審査が厳しい環境 | 手動EDRポリシー | パッケージ内容と展開タイミングを明示的に管理しやすい |
自動展開を使う場合でも、管理者は「自動だから確認不要」と考えないほうがよいです。オンボーディング パッケージは安定しており、通常頻繁に更新するものではないと説明されていますが、テナント移行やデータセンター地域の変更など、例外的に見直しが必要になるケースがあります。(Microsoft Learn)
具体的な導入手順：最短ルートと安全な進め方
新規に導入する場合は、次の順序で進めると失敗を減らせます。
標準的な導入手順
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | ライセンスを確認する | Intune Plan 1 と Defender for Endpoint / Defender XDR の対象ライセンスを確認する |
| 2 | 管理者権限を確認する | IntuneのEndpoint Security権限とEntra IDのSecurity Administrator権限を確認する |
| 3 | IntuneとDefenderを接続する | 接続状態が Connected になるまで確認する |
| 4 | 展開方式を決める | Auto from connector、事前構成ポリシー、手動パッケージのどれを使うか決める |
| 5 | パイロットへ割り当てる | OS、拠点、ネットワーク条件が異なる端末を少数選ぶ |
| 6 | EDR Onboarding Status を確認する | Not onboarded と Pending の原因を潰す |
| 7 | Defenderポータルで検証する | Assets > Devices に端末が表示され、センサー状態が正常か確認する |
| 8 | 全社展開する | 監視レポートを見ながら段階的に対象を広げる |
手動でオンボーディングする場合は、Defenderポータルの Settings > Endpoints > Device management > Onboarding からOSと展開方法を選び、Mobile Device Management / Microsoft Intune 用のパッケージをダウンロードします。その後、Intune の Endpoint security > Endpoint detection and response > Create Policy で、Package type に Onboard または Offboard を選び、パッケージ内容を貼り付けてポリシーを作成します。(Microsoft Learn)
移行期限：今回の情報だけで新しい期限を断定しない
このトピックで注意したいのは、「2026年7月1日更新」と聞くと、何らかの移行期限や廃止期限が追加されたように見える点です。しかし、確認できる公式情報の範囲では、このEDRポリシー展開ガイド自体に新しい移行期限が追加されたとは読み取れません。
一方で、Windows 10 については別の重要な期限があります。Microsoft Learnでは、Windows 10 は2025年10月14日にサポート終了となり、品質更新と機能更新を受け取らないこと、Intuneでは許可されるバージョンではあるものの機能は保証されず変動し得ることが明記されています。(Microsoft Learn)
つまり、管理者が取るべき行動は「EDRポリシーの移行期限に追われる」ことではなく、次の2点を分けて管理することです。
| 項目 | 判断 |
|---|---|
| EDRポリシー展開ガイドの移行期限 | 公式情報上、新しい期限が追加されたとは断定しない |
| Windows 10端末の扱い | 2025年10月14日のサポート終了を踏まえ、Windows 11移行や例外管理を検討する |
| 既存オンボーディング方式 | 競合がある場合はEndpoint securityのEDRポリシーへ整理する価値がある |
| 監視運用 | EDR Onboarding Status report を定期確認の対象にする |
Windows 10端末が残っている組織では、EDRがオンボード済みかどうかだけでなく、OSライフサイクル、脆弱性管理、例外承認、更新不可端末の隔離方針まで含めて確認する必要があります。
EDR Onboarding Status reportで見るべき指標
EDRポリシーを展開した後は、Intune管理センターの Endpoint security > Endpoint detection and response から EDR Onboarding Status タブを確認します。このレポートでは、オンボーディング済み端末、未オンボーディング端末、保留中端末、センサー状態などを確認できます。(Microsoft Learn)
管理者が優先して見るべき状態
| 表示 | 意味 | 優先度 |
|---|---|---|
| Onboarded | Defender for Endpointへテレメトリ送信できている | 正常。継続監視する |
| Not onboarded | オンボーディングが完了していない | 高。割り当て、通信、権限を確認する |
| Pending | オンボーディング処理中 | 中。一定時間後に再確認する |
| Inactive | センサーが最近報告していない | 高。端末停止、通信遮断、センサー異常を確認する |
| Impaired | センサーに問題がある | 高。Defenderサービスや競合製品を確認する |
グローバル環境では、単純なオンボーディング率だけでは不十分です。国別、拠点別、OS別、管理方式別にフィルターし、「特定の海外拠点だけNot onboardedが多い」「Linuxだけセンサー状態が不安定」「Configuration Manager管理端末だけ反映が遅い」といった偏りを見つけることが重要です。
オフボーディング運用も事前に決めておく
Defender for Endpoint のEDRポリシーは、オンボーディングだけでなくオフボーディングにも対応します。テスト端末を本番対象から外す、テナント統合で別テナントへ移す、端末ライフサイクル管理で利用終了する、といった場面で使います。(Microsoft Learn)
特に注意すべきなのは、オフボーディング パッケージの有効期限です。公式情報では、セキュリティ上の理由から、Defenderからダウンロードしたオフボーディング blob またはパッケージは7日後に期限切れとなり、期限切れパッケージはデバイス側で拒否されると説明されています。(Microsoft Learn)
オフボーディングを行う場合は、次のように運用ルールを決めておくと安全です。
| 決めるべきこと | 例 |
|---|---|
| 誰が承認するか | SOC責任者、端末管理責任者、システム所有者 |
| どの単位で実施するか | テスト端末、廃棄端末、移行対象グループ |
| いつパッケージを取得するか | 実施直前。7日以内に完了できるタイミング |
| 成功確認をどこで行うか | Intuneのポリシー状態とDefenderポータルのデバイス状態 |
| 履歴をどう残すか | 変更申請、対象端末一覧、実施日時、確認者を記録 |
オフボーディングは日常的に頻繁に行う作業ではありませんが、手順が曖昧だとテナント移行や端末廃棄時に混乱します。オンボーディング設計と同じタイミングで、解除手順も文書化しておくべきです。
管理者が今すぐ確認すべきチェックリスト
最後に、Microsoft Defender と Intune でEDRポリシーを運用している管理者が確認すべき項目を整理します。
| チェック項目 | 確認内容 |
|---|---|
| 公式情報の日付 | 7月1日の履歴はメタデータ更新として扱い、本文の最終更新日も確認する |
| ライセンス | Intune Plan 1 と Defender for Endpoint / Defender XDR の対象ライセンスを確認する |
| RBAC | Endpoint Security Manager、Security Administrator、カスタム権限を確認する |
| サービス接続 | IntuneとDefender for Endpointの接続が Connected か確認する |
| 展開方式 | Auto from connector、事前構成ポリシー、手動オンボーディングの使い分けを決める |
| 既存ポリシー | デバイス構成ポリシーやConfiguration Managerとの競合を確認する |
| OS別設計 | Windows、macOS、Linux、Windows Serverを分けて設計する |
| Linux除外 | Global Exclusions を必要最小限にする |
| 監視 | EDR Onboarding Status report を定期的に確認する |
| Windows 10 | サポート終了後の端末を例外管理し、移行計画に組み込む |
| オフボーディング | 7日で期限切れになるパッケージを前提に手順化する |
今回の「Deploy endpoint detection and response policy with Intune」は、目立つ新機能の追加というより、Defender for Endpoint のEDRオンボーディングをIntuneで標準化するための実務ガイドとして読むべき内容です。管理者はまず、IntuneとDefenderの接続状態、既存ポリシーとの競合、未オンボーディング端末、Windows 10端末の残存状況を確認してください。そのうえで、OS別・拠点別・管理方式別にパイロット展開し、EDR Onboarding Status reportで状態を見ながら段階的に展開するのが安全です。
コメント