Microsoft Defender の Intune 連携で最初に押さえるべき結論は、Defender for Endpoint が検知したデバイスリスクを Intune のデバイス準拠ポリシーに反映し、危険な端末を Microsoft Entra Conditional Access で業務リソースから遮断できるという点です。単に Defender を端末へ展開するだけではなく、「検知」「準拠判定」「アクセス制御」までをつなげることで、侵害された端末から SharePoint、Exchange Online、Teams などへアクセスされるリスクを下げられます。Microsoft Learn の公式情報では、Defender for Endpoint と Intune の統合により、デバイスリスクをリアルタイムに評価し、侵害されたデバイスを自動的に非準拠として扱えると説明されています。(Microsoft Learn)
この記事では、Microsoft Defender の「Integrate Microsoft Defender for Endpoint with Intune for Device Compliance – Microsoft Intune」について、2026年7月時点で管理者が確認すべき更新ポイント、影響範囲、設定変更、移行・廃止に関する注意点を実務目線で整理します。
Microsoft Defender と Intune の連携で何ができるのか
この連携の中心は、Microsoft Defender for Endpoint を Mobile Threat Defense、いわゆる MTD のリスク評価ソースとして使い、Intune のデバイス準拠やアプリ保護、Conditional Access に反映することです。
大まかな流れは次のとおりです。
| 段階 | 役割 | 実務上の意味 |
|---|---|---|
| Defender for Endpoint | マルウェア、不審な挙動、脆弱性などを検知し、デバイスリスクを評価 | SOC やセキュリティ担当が端末の危険度を把握する |
| Intune | Defender のリスク信号を使って、デバイスを準拠または非準拠に判定 | 端末管理者がアクセス可否の条件として利用できる |
| Microsoft Entra Conditional Access | 非準拠デバイスからのクラウドアプリ利用をブロック | 危険な端末からの業務データアクセスを止める |
公式手順では、Intune と Defender for Endpoint のサービス間接続を作成し、デバイスを Defender for Endpoint にオンボードし、許容するリスクレベルをデバイス準拠ポリシーで設定し、最後に Conditional Access で非準拠デバイスをブロックする流れが示されています。(Microsoft Learn)
重要なのは、この仕組みが「検知したらアラートを出す」だけで終わらないことです。たとえば端末が高リスクと判断された場合、Intune がその端末を非準拠として扱い、Conditional Access が SharePoint Online や Exchange Online などへのアクセスを制限できます。セキュリティ運用と端末管理を分断せず、リスクに応じて自動的にアクセス制御へつなげられる点が実務上の価値です。
更新ポイントとして確認すべき主な変更点
今回確認すべきポイントは、「Defender と Intune をつなげる機能がある」という基本説明ではなく、管理者がどの設定を有効化し、どの範囲に影響するかを明確にすることです。
| 確認ポイント | 内容 | 管理者への影響 |
|---|---|---|
| サービス間接続 | Microsoft Defender ポータル側で Intune connection を有効化し、Intune 側で接続状態を確認する | Defender 管理者と Intune 管理者の権限調整が必要 |
| プラットフォーム別の評価 | Android、iOS/iPadOS、Windows の準拠評価で Defender リスク信号を使える | OS ごとに段階展開と検証が必要 |
| アプリ保護ポリシー | Android と iOS/iPadOS では、登録済み端末だけでなく未登録端末にもリスク評価を使える | BYOD や個人所有端末の保護設計に関係する |
| Android の MTD ロール | Android Enterprise の企業所有端末で Defender に強化された権限や自動起動を付与できる | Defender アプリが止められにくくなり、初期設定漏れを減らせる |
| Conditional Access | 非準拠デバイスをブロックするポリシーは Report-only で検証してから有効化する | 誤設定による一斉ブロックを避ける運用が必要 |
Intune の設定画面では、Endpoint security > Defender for Endpoint から、Android、iOS/iPadOS、Windows の準拠ポリシー評価を有効化できます。これらを有効にすると、現在 Intune で管理している対象デバイスと今後登録されるデバイスが、Defender for Endpoint による準拠評価の対象になります。(Microsoft Learn)
つまり、単なる「新しいトグル」ではありません。グローバル企業では、国や拠点ごとの端末登録状況、BYOD の扱い、個人所有 iOS/iPadOS デバイスのインベントリ共有方針まで確認してから有効化する必要があります。
影響範囲：誰が何を確認すべきか
この更新は、Microsoft Defender 管理者だけで完結しません。Intune、Microsoft Entra ID、SOC、ヘルプデスク、場合によっては法務・プライバシー部門にも影響します。
| 担当者 | 確認すべきこと |
|---|---|
| Intune 管理者 | Defender for Endpoint コネクタの接続状態、準拠ポリシー、アプリ保護ポリシー、オンボーディング状態 |
| Defender 管理者 / SOC | デバイスリスクの分類、検知後の調査フロー、脆弱性修復タスク |
| Entra ID 管理者 | Conditional Access の対象ユーザー、対象アプリ、除外アカウント、Report-only 結果 |
| ヘルプデスク | 非準拠になったユーザーへの案内、Defender アプリ未設定時の対応手順 |
| グローバル IT 管理者 | 地域別の展開リング、BYOD ルール、個人データ共有の説明責任 |
特に注意したいのは Conditional Access です。デバイス準拠を必須にするポリシーを全クラウドアプリへいきなり適用すると、対象ユーザー全員に即時影響します。公式手順でも、まず Report-only モードで作成し、サインインログで影響範囲を確認してから有効化することが推奨されています。(Microsoft Learn)
対象プラットフォームと使える保護の違い
Microsoft Defender for Endpoint と Intune の連携は、Windows だけを対象にした機能ではありません。ただし、プラットフォームによって使える機能や設定手順が異なります。
| プラットフォーム | 主な使い方 | 注意点 |
|---|---|---|
| Windows | Intune の EDR ポリシーで Defender for Endpoint へオンボードし、デバイスリスクを準拠ポリシーに反映 | 自動オンボーディングパッケージを使えるため、大規模展開に向く |
| macOS | Defender for Endpoint のアプリ展開と構成を行い、EDR 側の保護を有効化 | Windows のような自動パッケージ前提ではなく、手動構成が必要 |
| Android | Managed Google Play で Defender アプリを展開し、MTD としてリスク評価に使う | Android Enterprise の管理方式や MTD ロールの対象を確認する |
| iOS/iPadOS | Defender アプリ、アプリ保護ポリシー、必要に応じたアプリ脆弱性評価を組み合わせる | 個人所有端末で共有するアプリインベントリ情報の扱いに注意する |
公式手順では、Windows、macOS、Android、iOS/iPadOS のオンボーディングが扱われています。一方、デバイスリスクレベルを使った準拠ポリシーの対象としては、Android、iOS/iPadOS、Windows が示されています。(Microsoft Learn)
Windows では、Intune と Defender for Endpoint の接続後にオンボーディング構成パッケージを Intune が受け取り、EDR ポリシーから展開できます。macOS、Android、iOS/iPadOS は、それぞれ Defender アプリの展開やアプリ構成ポリシーなど、プラットフォームごとの準備が必要です。(Microsoft Learn)
設定変更で管理者が行うべき作業
実務では、次の順番で進めると失敗しにくくなります。
まず接続状態と権限を確認する
最初に、Intune 管理センターの Endpoint security > Defender for Endpoint で接続状態を確認します。未接続の場合は、Microsoft Defender ポータルの System > Settings > Endpoints > General > Advanced features で Intune connection を有効にします。接続状態の反映には時間がかかる場合があるため、設定直後に焦ってポリシーを作り込まないことが大切です。(Microsoft Learn)
権限面では、Intune 側で Mobile Threat Defense、Endpoint Detection and Response、Device compliance policies を扱う権限が必要です。組み込みロールでは Endpoint Security Manager が関連権限を含む最小権限に近い選択肢として示されています。ただし Conditional Access は Microsoft Entra ID 側の管理権限が別途必要です。(Microsoft Learn)
プラットフォーム別に連携トグルを有効化する
接続後は、Endpoint security > Defender for Endpoint で、準拠ポリシー評価に使うプラットフォームを有効化します。Android、iOS/iPadOS、Windows のトグルを有効にすると、対象デバイスが Defender for Endpoint の脅威評価を準拠判定に使うようになります。(Microsoft Learn)
モバイルでは、アプリ保護ポリシー評価も重要です。Android と iOS/iPadOS では、Intune 登録済み端末だけでなく、未登録端末に対してもアプリレベルでリスク評価を適用できます。BYOD が多い企業では、端末全体を管理できない場合でも、Outlook、Teams、SharePoint アプリなどの業務データを守る設計がしやすくなります。(Microsoft Learn)
デバイスを Defender for Endpoint にオンボードする
接続だけでは保護は完成しません。対象デバイスを Defender for Endpoint にオンボードし、リスク信号を送れる状態にする必要があります。
Windows では、Endpoint security > Endpoint detection and response から事前構成済みポリシーを展開する方法と、手動で EDR ポリシーを作成する方法があります。全社展開を急ぐ場合は事前構成済みポリシーが便利ですが、グループ単位で段階的に進めたい場合は手動作成の方が安全です。公式手順でも、デバイスグループへの割り当ては即時展開に向き、ユーザーグループはユーザーのサインインが必要になる点が示されています。(Microsoft Learn)
準拠ポリシーで許容リスクを決める
次に、Intune のデバイス準拠ポリシーで「Require the device to be at or under the machine risk score」を設定します。ここで決めるリスクしきい値が、実際のアクセス制御に直結します。
| リスクしきい値 | 動作の考え方 | 向いている場面 |
|---|---|---|
| Clear | 脅威を許容しない。最も厳格 | 特権管理者、機密情報を扱う端末、金融・医療など高セキュリティ領域 |
| Low | 低リスクのみ許容し、中・高リスクをブロック | 多くの企業の標準設定候補 |
| Medium | 高リスクのみブロック | 誤検知による業務影響を抑えたい初期段階 |
| High | 実質的にブロックせず、レポート中心 | 監視目的、導入初期の影響調査 |
公式手順では、Low が多くの組織においてセキュリティと生産性のバランスを取りやすい推奨設定として示されています。(Microsoft Learn)
ただし、すべての組織で Low をそのまま全社適用すればよいわけではありません。たとえば海外拠点で Defender アプリの展開が遅れている、Android の管理方式が混在している、買収した子会社の端末台帳が未整備といった状況では、いきなりブロックすると業務停止につながります。まずはレポートで非準拠候補を洗い出し、対象グループを限定して段階展開するのが現実的です。
Conditional Access は Report-only から始める
Defender のリスク判定を Intune の準拠状態に反映しても、Conditional Access を設定しなければアクセス制御としては完成しません。典型的には、SharePoint Online、Exchange Online、Teams、その他の業務アプリに対して「準拠デバイスであること」を要求します。
実務での推奨手順は次のとおりです。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 対象ユーザーを限定する | まずは IT 部門、パイロットユーザー、特定拠点から開始 |
| 2 | 緊急用管理者アカウントを除外する | ロックアウト防止のため、break-glass アカウントを必ず除外 |
| 3 | 対象アプリを選ぶ | いきなり全クラウドアプリにせず、Exchange Online や SharePoint Online から検証 |
| 4 | Grant control で準拠デバイスを要求する | 「Require device to be marked as compliant」を選択 |
| 5 | Report-only で作成する | ブロックせず、サインインログで影響を確認 |
| 6 | 問題がなければ On に切り替える | 非準拠理由、対象ユーザー、除外漏れを確認してから本番化 |
公式手順では、Conditional Access ポリシーを Report-only で作成し、サインインログで結果を確認してから有効化する流れが示されています。さらに、緊急用の break-glass 管理者アカウントを除外することも明記されています。(Microsoft Learn)
よくある失敗は、全社ユーザーと全クラウドアプリを同時に対象にしてしまうことです。これを行うと、Defender アプリ未展開のモバイル端末、古い Windows 端末、登録状態が不完全な端末が一斉にアクセスできなくなる可能性があります。まずは「誰が」「どのアプリに」「どの端末から」影響を受けるかを Report-only で確認しましょう。
移行期限・廃止関連で注意すべき点
この公式情報の範囲では、Defender for Endpoint と Intune のデバイス準拠連携そのものについて、新たな一律の移行期限が示されているわけではありません。一方で、周辺機能には見落としやすい廃止・移行ポイントがあります。
| 項目 | 状況 | 管理者が行うべきこと |
|---|---|---|
| Classic Conditional Access | Defender for Endpoint コネクタについて、Intune は 2023年8月リリース以降 Classic CA ポリシーを作成しない | 過去の統合で作成された Classic CA が残っていれば棚卸しし、不要なら削除 |
| Android device administrator | Google Mobile Services にアクセスできるデバイスでは非推奨かつ利用不可 | Android Enterprise への移行計画を確認 |
| Windows 10 | 2025年10月14日にサポート終了済み | Windows 11 移行、拡張セキュリティ更新、業務アプリ互換性を確認 |
| 未登録端末 | フル管理できない端末はデバイス準拠だけでは制御しづらい | Android/iOS のアプリ保護ポリシーと MTD 評価を組み合わせる |
Classic Conditional Access については、2023年8月の Intune サービスリリース以降、Microsoft Defender for Endpoint コネクタ用の Classic CA ポリシーは作成されなくなっています。過去の統合で残っている Classic CA ポリシーがある場合は、現在の Conditional Access ポリシーと重複していないか確認し、不要なものは削除対象にできます。(Microsoft Learn)
Android device administrator 管理方式についても注意が必要です。Google Mobile Services にアクセスできるデバイスでは非推奨であり、利用できないため、現在も Android DA 管理に依存している組織は Android Enterprise への移行を前提に設計を見直す必要があります。(Microsoft Learn)
Windows 10 については、Intune 上で許可されるケースがあっても、2025年10月14日にサポート終了済みであり、機能が保証されるとは限らない点が公式手順でも注意されています。(Microsoft Learn)
グローバル環境での設計ポイント
グローバル企業では、単一テナントでも国・地域・事業会社ごとに端末事情が異なります。Microsoft Defender と Intune の連携は強力ですが、全世界へ同じ設定を一括適用すると、現場の運用差によりトラブルが起きやすくなります。
地域ごとに展開リングを分ける
最初から全社展開せず、次のように段階を分けると安全です。
| 展開リング | 対象例 | 目的 |
|---|---|---|
| Ring 0 | IT 管理者、SOC、ヘルプデスク | 設定ミスやロックアウトの早期発見 |
| Ring 1 | 本社部門、標準端末を使うユーザー | 一般的な業務影響の確認 |
| Ring 2 | 海外拠点、モバイル比率が高い部門 | 地域差、通信環境、BYOD の問題確認 |
| Ring 3 | 全社 | 運用手順と問い合わせ対応が固まってから適用 |
特にモバイル端末は、国によってアプリ配布、個人所有端末の利用ルール、プライバシー要件が異なります。iOS/iPadOS ではアプリインベントリ共有に関する設定もあるため、個人所有端末では必要性と説明責任を事前に整理しておきましょう。MTD の App Sync や証明書インベントリの共有はオプトインであり、管理者が明示的に有効化する必要があります。(Microsoft Learn)
サードパーティ MTD との併用を整理する
すでに Lookout、Zimperium、CrowdStrike、Jamf などの MTD 製品を使っている組織では、Defender for Endpoint との役割分担が必要です。
Intune の MTD では、同一テナント・同一プラットフォームで複数ベンダーを使うと、対象デバイスが各 MTD アプリをインストールしてスキャンを送信する必要があり、いずれかが送信できないと非準拠になる可能性があります。ただし、Defender for Endpoint についてはこの推奨がそのまま適用されるわけではなく、サードパーティ MTD と併用し、異なる準拠ポリシーを別グループへ展開して評価できます。(Microsoft Learn)
買収や地域子会社で別の MTD が残っている場合は、いきなり統合せず、次の観点で整理するとよいでしょう。
- どの地域・端末種別でどの MTD を標準にするか
- Defender for Endpoint を全社標準に寄せる時期
- 既存 MTD アプリをアンインストールする条件
- 準拠ポリシーをグループ単位で分離できているか
- ヘルプデスクが非準拠理由を判別できるか
よくある設定ミスと回避策
Defender アプリを展開する前に Conditional Access を有効化する
MTD や Defender アプリが端末にない状態で、デバイスリスクを使った準拠ポリシーと Conditional Access を有効化すると、正しく評価できない端末が非準拠扱いになり、業務アプリへアクセスできなくなる可能性があります。
回避策は、先に Defender アプリを配布し、オンボーディング状態を確認してから準拠ポリシーと Conditional Access を本番化することです。公式手順でも、オンボーディング状態は EDR Onboarding Status や Defender ポータルの Device inventory で確認する流れが示されています。(Microsoft Learn)
リスクしきい値を厳しくしすぎる
Clear は最も厳格な設定で、わずかな脅威検知でもブロックにつながります。特権管理者や高機密部門には適していますが、一般ユーザーへいきなり適用すると問い合わせが増える可能性があります。
多くの組織では、まず Low を標準候補にし、Report-only とパイロット展開で影響を見ます。そのうえで、役員、開発者、財務、人事、管理者など高リスクユーザーには厳格な設定を検討するのが現実的です。
レガシー CA ポリシーを放置する
過去の MTD 統合で作られた Classic Conditional Access が残っていると、現在の Conditional Access ポリシーと意図せず重複することがあります。現在の Microsoft Entra Conditional Access で制御できているなら、Classic CA は棚卸しし、不要なものを削除します。
ポリシー競合を確認しない
Intune では、Endpoint security policies、Security baselines、Device configuration profiles、Compliance policies が同じ端末に重なることがあります。設定値が矛盾すると、ポリシー競合や適用失敗の原因になります。
Microsoft Learn でも、複数のポリシー種別を併用する場合は、同じ設定を別方式で管理しないように設計し、競合検出ツールを使うことが推奨されています。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
本番環境で作業する前に、次のチェックリストを確認してください。
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft Intune Plan 1 と Defender for Endpoint の必要ライセンスを確認 |
| 権限 | Intune の Endpoint Security Manager 相当、Entra ID の Conditional Access 管理権限を確認 |
| 接続状態 | Endpoint security > Defender for Endpoint で接続状態が Enabled か確認 |
| 対象端末 | Windows、macOS、Android、iOS/iPadOS の台数、所有形態、登録方式を棚卸し |
| Defender 展開 | 各 OS で Defender for Endpoint アプリまたは EDR ポリシーの展開状況を確認 |
| 準拠ポリシー | リスクしきい値を Low、Medium、Clear のどれにするか決定 |
| CA ポリシー | Report-only で影響を確認し、break-glass アカウントを除外 |
| レガシー設定 | Classic CA、Android DA、古い Windows 10 端末を棚卸し |
| 監視 | EDR Onboarding Status、Device compliance、Entra サインインログを確認 |
| ユーザー対応 | 非準拠時の通知文、ヘルプデスク手順、多言語案内を準備 |
実務でのおすすめ構成
標準的な企業であれば、最初から複雑な設計にせず、次の構成から始めると運用しやすくなります。
| 領域 | 推奨初期設定 |
|---|---|
| Windows | Intune の EDR ポリシーで Defender for Endpoint へオンボード |
| Android / iOS | Defender アプリを展開し、MTD として準拠評価とアプリ保護に利用 |
| 準拠ポリシー | 一般ユーザーは Low を候補に開始 |
| 高リスクユーザー | 特権管理者や機密部門は Clear またはより厳格な別ポリシーを検討 |
| Conditional Access | まず SharePoint Online、Exchange Online など主要アプリで Report-only |
| BYOD | アプリ保護ポリシーを組み合わせ、未登録端末でも業務データを保護 |
| 運用監視 | Defender のリスク、Intune の準拠状態、Entra のサインインログを定期確認 |
この構成なら、「Defender が検知しているのにアクセス制御へ反映されない」「Intune では準拠だが実際は危険な端末が残る」といったギャップを埋めやすくなります。
まとめ：Defender と Intune の連携は“検知後の遮断”まで設計する
Microsoft Defender for Endpoint と Intune のデバイス準拠連携は、Defender の脅威検知を Intune の準拠状態に変換し、Conditional Access で業務リソースへのアクセスを制御するための重要な仕組みです。
管理者が優先して行うべきことは、次の3つです。
- Defender for Endpoint と Intune の接続状態、対象プラットフォーム、必要権限を確認する
- デバイス準拠ポリシーのリスクしきい値を決め、いきなり全社適用せず段階展開する
- Conditional Access は Report-only で影響を確認し、break-glass アカウントを除外してから有効化する
特にグローバル環境では、OS、地域、BYOD、既存 MTD、プライバシー要件が混在します。まずは端末台帳と現在の Defender 展開状況を棚卸しし、パイロットグループで「検知」「非準拠化」「アクセスブロック」「復旧」まで一連の流れを検証してください。そのうえで、拠点やデバイス種別ごとに段階展開することが、セキュリティ強化と業務継続を両立する最短ルートです。
コメント