Microsoft Entra の条件付きアクセスで Microsoft Defender for Endpoint のリスク情報を使う場合、今回のポイントは「Defender、Intune、Microsoft Entra ID の3か所を正しい順序で接続し、Intune のコンプライアンスポリシーを経由してアクセス制御する」ことです。2026年6月30日に更新された公式ドキュメントでは、Microsoft Entra 登録済みデバイスだけではこのシナリオを満たせず、Intune 登録済みデバイスが前提である点が明確に示されています。対象は Microsoft Defender for Endpoint Plan 1 / Plan 2 で、Windows 10 / Windows 11 端末を中心に、端末の脅威レベルを条件付きアクセスの判断材料にしたい管理者が確認すべき内容です。(Microsoft Learn)
Microsoft Entra の条件付きアクセス連携で何が変わるのか
「Configure Conditional Access in Microsoft Defender for Endpoint」は、Microsoft Defender for Endpoint が検出した端末のリスク状態を、Intune のコンプライアンス評価に反映し、その結果を Microsoft Entra の条件付きアクセスで利用するための設定手順です。
重要なのは、Microsoft Entra の条件付きアクセスが Defender for Endpoint の検出結果を直接そのまま判定するのではなく、次の流れでアクセス可否を判断する点です。
| 役割 | 担当するサービス | 実務上の意味 |
|---|---|---|
| 脅威の検出・端末リスクの評価 | Microsoft Defender for Endpoint | マルウェア、脆弱性、疑わしい挙動などをもとに端末の脅威レベルを評価する |
| デバイスの準拠状態判定 | Microsoft Intune | Defender のリスク情報を使い、端末を「準拠」または「非準拠」として評価する |
| アクセス制御 | Microsoft Entra ID / 条件付きアクセス | 準拠していない端末から Microsoft 365 などのリソース利用を制限する |
この仕組みにより、単に「ユーザーが正しいパスワードと MFA を通過したか」だけでなく、「そのユーザーが使っている端末が安全な状態か」まで含めてアクセス制御できます。公式手順でも、Microsoft Defender ポータル、Intune 管理センター、Microsoft Entra 管理センターの3か所で設定が必要とされています。(Microsoft Learn)
更新ポイントの要点
今回の公式情報で管理者が最初に確認すべき点は、次の4つです。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 対象デバイス | Microsoft Entra 登録済みだけのデバイスは対象外。Intune 登録済みデバイスが必要 |
| 対象ライセンス | Microsoft Defender for Endpoint Plan 1 / Plan 2 が対象 |
| 設定場所 | Defender ポータル、Intune 管理センター、Microsoft Entra 管理センターを横断して設定する |
| 有効化方法 | 条件付きアクセスは最初から強制せず、Report-only で影響を確認してから On にする |
特に見落としやすいのは、Microsoft Entra registered devices がこのシナリオではサポートされない点です。Microsoft Entra ID に登録されているだけの BYOD 端末や、Intune 管理下にない端末を前提にポリシーを作ると、期待した準拠判定やアクセス制御にならない可能性があります。(Microsoft Learn)
影響範囲：誰が対応すべきか
この更新内容の影響を受けるのは、主に次のような組織です。
Microsoft 365 へのアクセスを端末リスクで制御したい組織
Exchange Online、SharePoint Online、Teams、OneDrive などへのアクセスを、端末の健全性に応じて制御したい場合に関係します。たとえば、Defender for Endpoint が高リスクと判定した端末を Intune で非準拠にし、Microsoft Entra の条件付きアクセスで会社リソースへのアクセスを止める設計ができます。
Intune と Defender for Endpoint を導入済みだが、条件付きアクセス連携が未整備の組織
Defender for Endpoint を導入していても、Intune 側の統合設定やコンプライアンスポリシーが未設定であれば、条件付きアクセスの判断材料として十分に活用できません。公式手順では、Defender ポータルで Microsoft Intune connection を有効にし、Intune 管理センター側でも Defender for Endpoint 統合を有効化する流れが示されています。(Microsoft Learn)
Microsoft Entra 登録済みデバイス中心で運用している組織
このシナリオでは、Microsoft Entra 登録済みデバイスのみでは不十分です。端末が Intune に登録され、Intune 管理下でコンプライアンス評価を受けられる状態になっているかを確認する必要があります。公式ドキュメントでも、Intune managed かつ Microsoft Entra joined の Windows 10 / Windows 11 デバイスが必要とされています。(Microsoft Learn)
設定変更の全体像
設定は大きく4段階です。順番を間違えると、ポリシーを作成してもリスク評価が反映されなかったり、端末が想定外に非準拠になったりします。
| 手順 | 実施場所 | 設定内容 |
|---|---|---|
| 1 | Microsoft Defender ポータル | Microsoft Intune connection を On にする |
| 2 | Microsoft Intune 管理センター | Defender for Endpoint 統合を有効化する |
| 3 | Microsoft Intune 管理センター | Defender の脅威レベルを使うコンプライアンスポリシーを作成する |
| 4 | Microsoft Entra 管理センター | 「準拠済みデバイスを要求する」条件付きアクセスを作成する |
実務では、先に条件付きアクセスポリシーだけを作るのではなく、Defender と Intune の連携状態、対象デバイスの Intune 登録状況、コンプライアンスポリシーの割り当て範囲を確認してから Microsoft Entra 側の制御に進むのが安全です。
Defender ポータルで Microsoft Intune connection を有効にする
最初の作業は、Microsoft Defender ポータルで Intune との接続を有効化することです。公式手順では、Microsoft Defender ポータルの「System > Settings > Endpoints > General > Advanced features」から、Microsoft Intune connection が On になっているか確認します。必要に応じてトグルを On にし、設定を保存します。(Microsoft Learn)
この設定は、Defender for Endpoint の端末リスク情報を Intune 側の評価に渡すための土台です。ここが無効なままだと、Intune 側でコンプライアンスポリシーを作っても、Defender のリスク情報を活用した制御が成立しません。
Intune 管理センターで Defender for Endpoint 統合を有効にする
次に、Microsoft Intune 管理センターで Defender for Endpoint との統合を有効にします。公式手順では「Endpoint security > Setup section > Microsoft Defender for Endpoint」に進み、Compliance policy evaluation の設定で Windows デバイスを Microsoft Defender for Endpoint に接続するトグルを On にします。対象は Windows devices version 10.0.15063 and above とされています。(Microsoft Learn)
ここで注意したいのは、「Defender for Endpoint を契約している」ことと「Intune のコンプライアンス評価に Defender のリスク情報を使える状態」は別物だという点です。ライセンスがあっても、統合トグルが無効であれば、条件付きアクセスまでつながりません。
Intune のコンプライアンスポリシーで脅威レベルを決める
Intune では、Windows 10 and later のコンプライアンスポリシーを作成し、Microsoft Defender for Endpoint の項目で「Require the device to be at or under the Device Threat Level」を設定します。公式手順では、Clear、Low、Medium、High の4段階が示されています。(Microsoft Learn)
| 脅威レベル | 判定の考え方 | 向いている運用 |
|---|---|---|
| Clear | 脅威が存在しない端末のみ準拠 | 金融、医療、重要システム管理端末など、厳格な運用 |
| Low | 低レベルの脅威までは許容。Medium / High は非準拠 | 多くの企業で現実的な初期値になりやすい |
| Medium | Low / Medium まで許容。High は非準拠 | ユーザー影響を抑えつつ高リスク端末を止めたい場合 |
| High | すべての脅威レベルを許容 | 実質的にはブロック目的ではなく、段階導入や監視寄りの設定 |
実務でいきなり Clear を全社展開すると、軽微な検出でもアクセス不可になる可能性があります。まずは Low または Medium を候補にし、Defender のアラート傾向、端末の管理成熟度、ヘルプデスクの対応体制を見て調整するのが現実的です。
非準拠時のアクションはユーザー通知まで設計する
公式手順では、非準拠時の基本アクションとして「Mark device noncompliant」が即時で設定され、これは変更できないとされています。一方で、エンドユーザーへのメール送信や、デバイスをリタイアリストへ追加するアクションは追加できます。(Microsoft Learn)
ここで重要なのは、ブロックだけを設計しないことです。端末が非準拠になったユーザーに対して、何が起きたのか、どの窓口に連絡すべきか、Defender の修復手順をどう実行するかを案内しないと、問い合わせが急増します。
たとえば、通知メールには次の要素を含めると実務で混乱を減らせます。
- 端末がセキュリティ基準を満たしていないため、会社リソースへのアクセスが制限される可能性があること
- Microsoft Defender の警告を確認し、推奨アクションを実行すること
- 解消しない場合の問い合わせ先
- 緊急業務時の代替手段
条件付きアクセスはセキュリティ制御ですが、ユーザー通知や復旧導線まで含めて初めて運用として成立します。
Microsoft Entra 条件付きアクセスで「準拠済みデバイス」を要求する
最後に Microsoft Entra の条件付きアクセスで、対象ユーザーと対象リソースを指定し、アクセス許可の条件として「Require device to be marked as compliant」を選択します。公式手順では、対象ユーザーは All users、対象リソースは All resources を含める構成例が示されています。さらに、緊急用の break glass 管理者アカウントや、ハイブリッド ID 環境の Directory Synchronization Accounts を除外する手順も示されています。(Microsoft Learn)
全ユーザー・全リソースを対象にする設計は強力ですが、影響範囲も大きくなります。特にグローバル展開では、国や地域ごとに端末管理の成熟度、ネットワーク品質、業務アプリの利用状況が異なるため、最初から全社強制にしないことが重要です。
Report-only で影響を確認してから有効化する
公式手順では、条件付きアクセスポリシーを作成する際、最初は Report-only にすることが示されています。Report-only は、ポリシーを評価してログには記録するものの、実際にはアクセス制御を強制しない状態です。Microsoft の別ドキュメントでも、Report-only ではポリシーの結果をサインインログや Conditional Access のレポートで確認でき、強制前の検証に使えると説明されています。(Microsoft Learn)
管理者は少なくとも次の観点で確認してから On に切り替えるべきです。
| 確認項目 | 見るべき内容 |
|---|---|
| 対象ユーザー | 想定外の役員、管理者、サービス担当者が影響を受けていないか |
| 対象端末 | Intune 未登録端末が大量に非準拠扱いになっていないか |
| 対象アプリ | 業務継続に必要なアプリが過剰にブロックされないか |
| 地域差 | 海外拠点やリモートワーカーで想定外の失敗が出ていないか |
| 例外設計 | break glass アカウントや同期アカウントが除外されているか |
Microsoft の情報では、Report-only の結果はサインインログで確認でき、Policy impact や Workbook を使った影響分析も利用できます。特に複数の条件付きアクセスポリシーがある環境では、個別ポリシーだけでなく、組み合わせによる影響を確認することが欠かせません。(Microsoft Learn)
移行期限は明記されているか
2026年6月30日更新の対象ドキュメントでは、この設定に関する新たな強制移行期限や廃止期限は明記されていません。したがって、現時点で管理者がすべきことは「期限対応」ではなく、「前提条件を満たした構成になっているかの棚卸し」です。(Microsoft Learn)
ただし、関連する Intune の Defender for Endpoint 統合ドキュメントでは、2023年8月以降、Intune は Defender for Endpoint 向けのクラシック条件付きアクセスポリシーを新規作成しないと説明されています。過去の統合で作られたレガシーポリシーが残っている場合は、Azure portal / Entra ID / Conditional Access / Classic policies で確認し、不要であれば削除を検討できます。(Microsoft Learn)
つまり、今回の確認ポイントは「いつまでに移行しなければならないか」よりも、「クラシックポリシーや古い例外設定が残っていないか」「現在の条件付きアクセスが Report-only から適切に本番化されているか」です。
管理者が確認すべきチェックリスト
本番環境で設定する前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft Defender for Endpoint Plan 1 / Plan 2 の対象であるか |
| 端末登録 | 対象端末が Intune に登録されているか |
| デバイス状態 | Microsoft Entra registered のみの端末を対象にしていないか |
| Defender 連携 | Microsoft Defender ポータルで Intune connection が On か |
| Intune 連携 | Intune 側で Windows デバイスを Defender for Endpoint に接続しているか |
| コンプライアンスポリシー | 脅威レベルのしきい値が業務影響を考慮して設定されているか |
| 条件付きアクセス | Grant controls で「Require device to be marked as compliant」を使っているか |
| 除外設定 | break glass 管理者アカウントと同期アカウントを除外しているか |
| 検証 | Report-only、サインインログ、Policy impact で影響を確認したか |
| 運用 | 非準拠時のユーザー通知、復旧手順、問い合わせ先を用意したか |
特に、break glass アカウントの除外は重要です。Microsoft は緊急アクセス用アカウントを条件付きアクセスから除外することを推奨しており、少なくとも2つの緊急アクセスアカウントを用意し、定期的に利用可能性を検証する考え方も示しています。(Microsoft Learn)
よくある失敗パターン
Intune 登録前に条件付きアクセスを強制してしまう
最も危険なのは、端末登録状況を確認せずに「準拠済みデバイスを要求する」条件付きアクセスを On にすることです。Intune に登録されていない端末は準拠状態を満たせず、ユーザーが業務アプリにアクセスできなくなる可能性があります。
対策として、まず Intune のデバイス一覧とコンプライアンスレポートを確認し、対象グループを小さく分けて段階的に展開します。
脅威レベルを厳しくしすぎる
Clear は最も厳格ですが、実務では軽微な検出や調査中のアラートでも非準拠になり得ます。セキュリティ部門だけで決めるのではなく、ヘルプデスク、端末管理、業務部門と合意したうえで、最初のしきい値を決めるべきです。
全リソース対象なのに例外設計が甘い
All resources を対象にする条件付きアクセスは、Microsoft 365 全体を守るうえで有効です。一方で、管理者用アカウント、緊急対応アカウント、同期用アカウント、監視用アカウントまで不用意に対象にすると、障害時の復旧手段を失う可能性があります。
Report-only のログを見ずに On にする
Report-only は作成時の飾りではありません。サインインログで「Report-only: Failure」や「User action required」が多く出ている状態で本番化すると、ユーザー影響が顕在化します。少なくとも主要部門、海外拠点、管理者、モバイル利用者のログを分けて確認することが重要です。
グローバル展開での判断基準
グローバル企業では、国や地域によって端末管理、ネットワーク、業務アプリの事情が異なります。全社一律の強制よりも、次の順で展開すると失敗しにくくなります。
| フェーズ | 対象 | 目的 |
|---|---|---|
| パイロット | IT部門、セキュリティ部門、一部の協力ユーザー | ポリシー動作とログを確認する |
| 限定展開 | 端末管理が整っている部門・地域 | ユーザー影響と問い合わせ件数を把握する |
| 段階展開 | 主要拠点、標準端末利用者 | 非準拠時の復旧手順を定着させる |
| 全社展開 | 例外整理後の全対象ユーザー | 条件付きアクセスを標準統制にする |
端末リスクベースの条件付きアクセスは、セキュリティ強化だけでなく、端末管理の不備を可視化する仕組みでもあります。ブロック件数だけを見るのではなく、「なぜ非準拠端末が残っているのか」「修復までに何日かかるのか」「例外が恒久化していないか」まで追うと、運用改善につながります。
まず実施すべきこと
Microsoft Entra の条件付きアクセスで Defender for Endpoint のリスク情報を使うなら、最初にやるべきことはポリシー作成ではなく、前提条件の確認です。対象端末が Intune 登録済みか、Defender と Intune の接続が有効か、コンプライアンスポリシーが適切なしきい値で作られているかを確認してください。
そのうえで、Microsoft Entra の条件付きアクセスでは Report-only から開始し、サインインログと影響分析を見てから段階的に On に切り替えます。移行期限に追われるタイプの更新ではありませんが、古いクラシック条件付きアクセスポリシー、未登録端末、break glass アカウントの除外漏れは、将来の障害やセキュリティ事故につながります。まずは小さな対象グループで検証し、端末リスクを使ったアクセス制御を安全に本番化することが、今回の更新で管理者が取るべき実務的な対応です。
コメント