Microsoft が 2026年4月上旬に Intune での Microsoft Defender for Endpoint 統合ガイダンスを更新しました。結論から言うと、今回のポイントは新機能の大量追加ではなく、Intune と Defender の連携を「接続 → オンボード → リスク評価 → コンプライアンス → 条件付きアクセス → 脆弱性修復」まで一気通貫で見直せる形に整理したことです。すでに Intune や Defender を導入済みでも、接続だけ有効で実際のブロックや修復まで到達していない環境は少なくありません。この記事では、更新の要点、統合が Microsoft のエンドポイント セキュリティ スタックを支える理由、いま管理者が見直すべき設定を、実務目線でまとめます。 (Microsoft Learn)
今回のガイダンス更新で押さえるべきこと
執筆時点で Microsoft Learn の公開ページには 2026-03-26 更新の表示がありますが、同じドキュメントの GitHub 履歴では 2026年4月7日と4月8日に更新が入り、コミット名として「Article put into Protect node」「Deduplication and detail/link validation」が確認できます。つまり、今回の更新は「まったく新しい統合方式が登場した」というより、関連ドキュメントの再配置、重複整理、リンクや説明の精査を通じて、運用手順を迷いにくくした更新と見るのが自然です。 (Microsoft Learn)
更新後のガイドで特に分かりやすくなったのは、次の3点です。
| 再整理されたポイント | 実務で効く理由 |
|---|---|
| サービス接続から条件付きアクセスまでを一つの流れで説明 | 「接続だけして終わり」を防ぎやすい |
| Windows のオンボードを Quick setup と Custom setup に分離 | 小規模即展開と段階展開を選びやすい |
| モバイル向けアプリ保護と未登録端末向け管理まで導線を明示 | BYOD や混在環境まで設計対象にしやすい |
上の整理は、ガイド本文にある「What you’ll accomplish」「Quick navigation」、Windows の Quick setup / Custom setup、モバイル向け App protection、未登録端末向け Security Management への導線から読み取れます。 (GitHub)
なぜ Intune と Defender の統合が“アンカー”なのか
Microsoft Intune と Microsoft Defender for Endpoint の統合が重要なのは、単に製品同士が連携するからではありません。Defender が検知したリスクを、Intune が「運用できるポリシー」に変え、最後に Microsoft Entra の条件付きアクセスで業務システムへの到達を止めるからです。さらに、その後の是正は Defender Vulnerability Management と Intune のセキュリティ タスクでつなげられます。つまりこの統合は、検知・評価・制御・修復を分断しないための中核です。 (Microsoft Learn)
| コンポーネント | 主な役割 | 欠けると起きやすいこと |
|---|---|---|
| Microsoft Defender for Endpoint | 脅威検知、デバイスリスク評価 | リスクベース制御が始まらない |
| Microsoft Intune | オンボード、コンプライアンス、アプリ保護、展開管理 | 検知を運用ポリシーへ落とし込めない |
| Microsoft Entra 条件付きアクセス | 非準拠端末のアクセス遮断 | 危険端末が SharePoint や Exchange に到達する |
| Defender Vulnerability Management + Intune セキュリティ タスク | 修復依頼と追跡 | 検知後の是正が属人的になりやすい |
この役割分担は、公式の統合ワークフロー、条件付きアクセス前提、脆弱性修復フローの説明と一致します。 (Microsoft Learn)
まず確認したい設定はこの6つ
ガイド更新後に、管理者が最初に確認すべきポイントを絞ると次の6項目です。
| チェック項目 | どこで確認するか | 合格ライン | ありがちな失敗 |
|---|---|---|---|
| サービス間接続 | Intune 管理センターの Endpoint security > Microsoft Defender for Endpoint と Defender ポータルの System > Settings > Endpoints > General > Advanced features | Connection status が Enabled、Defender 側の Microsoft Intune connection が On | Intune 側だけ見て Defender 側のトグルを見落とす |
| コンプライアンス評価トグル | Intune の Microsoft Defender for Endpoint 設定 | Android / iOS / Windows の必要なプラットフォームが On | 一部プラットフォームだけ未有効で、リスク評価が飛ばない |
| アプリ保護評価トグル | 同上 | Android / iOS の必要分が On | BYOD を使うのにアプリ保護連携を無効のまま運用する |
| Windows オンボード方法 | Endpoint security > Endpoint detection and response | 小規模は Quick setup、大規模は Custom setup とリング配布 | ユーザーグループ割り当てで、サインインまで適用が遅れる |
| 条件付きアクセス | Intune から開く CA か Entra 管理センター | まず Report-only、緊急用アカウントを除外 | いきなり本番有効化してロックアウトを起こす |
| 旧 classic CA の整理 | Entra の Conditional Access | 旧 classic ポリシーが不要なら削除 | 過去の名残を放置して原因切り分けが難しくなる |
接続状態の反映は最大 15 分、Windows デバイスのオンボード確認は 15〜30 分が目安です。加えて、コンプライアンス評価トグルを有効にすると、いま管理中の適用可能なデバイスと今後の登録端末が評価対象になります。検証なしで一気に広げると影響範囲が想定より大きくなりがちです。 (GitHub)
環境別に見る、実務でハマりにくい設計
社給 Windows PC が中心の組織
Windows 中心なら、まずは サービス接続 → EDR オンボード → コンプライアンス → 条件付きアクセス の王道構成で十分です。Quick setup は All Devices に即時展開されるため、小規模環境やまず全体の接続性を確認したい場面に向いています。一方、拠点別・部門別・段階展開をしたいなら Custom setup の方が現実的です。閉域寄りの環境では onboarding blob を使う選択肢もあります。なお、ポリシー割り当てはデバイス グループ推奨で、ユーザー グループだとサインインまで適用されない点は見落としやすいポイントです。 (GitHub)
もう一つ見逃したくないのが OS 世代です。公式ガイドではコンプライアンス対象として Windows 10 and later を選べますが、Windows 10 は 2025年10月14日にサポート終了しており、Intune では登録できても機能保証はできないとされています。今回のガイダンス更新を機に、Windows 10 例外運用を前提にした設計は一度見直した方が安全です。 (Microsoft Learn)
BYOD やモバイル中心の組織
BYOD を含むなら、デバイス登録だけで考えない方が実務に合います。更新ガイドでは、App protection policy evaluation が Android と iOS/iPadOS で使え、登録済み・未登録の両方の端末に対して Defender ベースのリスク判定を使えることが明確です。アプリ保護ポリシーでは、脅威レベルが閾値を超えたときに アプリへのアクセス遮断やアプリ内の企業データのワイプまで設定できます。MAM 中心で守りたい組織には、ここが一番効きます。 (GitHub)
iOS/iPadOS は一歩踏み込んだ設定も用意されています。たとえば、App Sync を使った脅威分析向けメタデータ共有や、個人所有端末で送るアプリ インベントリ情報の粒度調整が可能です。監督対象の iOS/iPadOS では、アプリ構成ポリシーで issupervised に {{issupervised}} を渡す supervision detection の設定までガイドに含まれています。Android 側も Web 保護、VPN ベースのスキャン、プライバシー制御などを組み合わせられるため、「モバイルは後回し」ではなく、最初から別設計にするのが成功しやすい進め方です。 (GitHub)
未登録端末、Windows Server、Linux、macOS を含む混在環境
混在環境では、今回のガイダンス整理が特に役立ちます。公式ドキュメントでは、Intune にフル登録できない端末でも Security Management for Microsoft Defender for Endpoint を使って Defender の設定を Intune のエンドポイント セキュリティ ポリシーで管理できると案内されています。対象は Windows、Windows Server 2012 R2 以降、Linux、macOS です。 (Microsoft Learn)
ただし、ここで混同しやすいのが管理チャネルです。すでに Intune に登録済みの端末は、Defender for Endpoint security settings management のポリシーを処理しません。 その端末は通常どおり Intune で管理すべきです。逆に未登録端末向け管理がうまく機能しているかは、Intune 管理センターや Defender ポータルの Managed by が MDE になっているかで確認しやすくなります。混在環境では「どの端末をどのチャネルで管理するか」を先に分けておかないと、ポリシー競合と責任分界が曖昧になりがちです。 (Microsoft Learn)
リスク閾値は Low から始めるのが現実的
統合の成否を分けるのは、実は接続そのものよりリスク閾値の設定です。公式ガイドでは Require the device to be at or under the machine risk score の閾値として Clear / Low / Medium / High が示され、多くの組織には Low が推奨されています。 (Microsoft Learn)
| 閾値 | 通る状態 | 向いているケース | 注意点 |
|---|---|---|---|
| Clear | 脅威なしのみ許可 | 共有端末、厳格な高統制環境 | ヘルプデスク負荷が上がりやすい |
| Low | 低リスクのみ許可 | 多くの一般企業の標準構成 | まずここから始めるのが無難 |
| Medium | 低・中リスクまで許可 | 例外が多い移行期 | ブロック精度が緩くなる |
| High | すべて許可 | 監視中心の暫定運用 | 実質的にブロックしない |
特に注意したいのは High が「緩い」ではなく、ほぼレポート用途に近いことです。高めの閾値なら安全に始められると思いがちですが、公式の説明では High は「All threat levels permitted / Blocks: None」です。最初の本番値に選ぶなら、Clear で強く締めるよりも Low で始め、例外の傾向を見てから調整した方が現実的です。 (Microsoft Learn)
失敗しやすいポイント
接続だけ有効にして満足すること。 サービス間接続は出発点にすぎません。実際にアクセスを止めるには、オンボード、コンプライアンス ポリシー、条件付きアクセスまでつながっている必要があります。 (Microsoft Learn)
条件付きアクセスをいきなり本番有効化すること。 公式ガイドでも、全クラウド アプリに対する準拠必須ポリシーは影響が大きいため、まず Report-only で評価し、サインイン ログを見てから On にするよう案内しています。緊急用の break-glass アカウント除外も必須です。 (Microsoft Learn)
Windows のオンボードをユーザー グループで配ること。 ガイドではデバイス グループが推奨で、ユーザー グループはサインイン後までポリシー適用が遅れます。パイロットで「なぜか端末が出てこない」ときは、ここが原因になりやすいです。 (Microsoft Learn)
BYOD にデバイス コンプライアンスだけを期待すること。 未登録端末まで視野に入れるなら、モバイル向けの App protection policy evaluation を有効にしないと、アプリレベルの制御が抜けます。 (GitHub)
Intune 登録端末と MDE security settings management を同じ発想で混在させること。 すでに Intune 管理下の端末は、Defender 側の security settings management ポリシーを処理しません。管理チャネルを曖昧にすると競合の切り分けが難しくなります。 (Microsoft Learn)
過去の classic Conditional Access を放置すること。 Intune は 2023年8月以降、Microsoft Defender for Endpoint 向けの classic 条件付きアクセスを新規作成しません。古いポリシーを残したままだと、トラブル時の原因追跡が複雑になります。 (GitHub)
迷ったら、この順番で進めればいい
最小構成で安全に始めるなら、次の順番が失敗しにくいです。
- 権限と契約を確認する。 Intune Plan 1、Defender for Endpoint の契約、Intune 側の Endpoint Security Manager 相当、Entra 側の Conditional Access Administrator 相当を整理します。 (Microsoft Learn)
- テナント接続を確認する。 Intune 管理センターで Connection status が Enabled、Defender ポータルで Microsoft Intune connection が On かを確認します。 (GitHub)
- 評価トグルを必要なプラットフォームだけ有効にする。 Windows、iOS/iPadOS、Android のコンプライアンス評価、必要ならモバイルのアプリ保護評価も有効にします。 (GitHub)
- Windows のパイロットを 1 グループで始める。 小規模なら Quick setup、大規模なら Custom setup でデバイス グループへ配り、EDR Onboarding Status と Defender の Device inventory で確認します。 (GitHub)
- リスク閾値は Low で開始する。 いきなり Clear にせず、まずは Low で誤検知や例外の出方を観察します。 (Microsoft Learn)
- 条件付きアクセスは Report-only で作る。 SharePoint Online と Exchange Online など主要 SaaS に絞り、緊急用アカウントを除外して 24 時間程度ログを確認します。 (Microsoft Learn)
- 最後に修復フローまでつなげる。 Defender Vulnerability Management と Intune セキュリティ タスクを使い、検知後の是正を属人化させないようにします。混在環境なら security settings management も追加で検討します。 (Microsoft Learn)
今回の Microsoft の Intune / Defender for Endpoint 統合ガイダンス更新で本当に重要なのは、「両製品を契約しているか」ではなく、Defender の検知が Intune の準拠判定と Microsoft Entra のアクセス制御までつながっているかです。まずはテナント接続、Windows パイロット、Low のリスク閾値、Report-only の条件付きアクセスという最小構成を今日中に確認し、その後に BYOD、未登録端末、脆弱性修復へ広げていくと、遠回りせずに効果を出せます。 (Microsoft Learn)
コメント