Microsoft Entra のデバイスベースの Conditional Access は、Intune のデバイス コンプライアンス状態を使って、会社のアプリやサービスへアクセスできる端末を制御する仕組みです。今回確認すべきポイントは、新機能を有効化するというより、Intune 側で「準拠」と判定できるポリシーを先に整え、その結果を Microsoft Entra Conditional Access の「Require device to be marked as compliant」で正しく使うことです。Microsoft Learn の対象ページでは、Intune のデバイス コンプライアンス ポリシーの結果を Microsoft Entra Conditional Access で利用する構成が「device-based Conditional Access」と説明されています。(Microsoft Learn)
なお、公開ページ上の最終更新表示は 2026年5月20日ですが、GitHub の対象ファイル履歴では 2026年7月1日に「Metadata updates (#20499)」が記録されています。差分を見る限り、本文の設定手順そのものを大きく変える機能追加ではなく、メタデータ整理が中心です。そのため管理者は「新しい移行作業が発生した」と早合点するのではなく、既存のデバイス準拠ポリシー、除外アカウント、Report-only 検証、既存のアプリベース条件付きアクセスの移行状況を確認するのが現実的です。(GitHub)
Microsoft Entra と Intune のデバイスベース Conditional Access とは
デバイスベース Conditional Access は、ユーザーのサインインだけでなく、そのユーザーが使っている端末が組織の基準を満たしているかをアクセス判断に含める設計です。
たとえば、次のような運用ができます。
| 利用シーン | 条件付きアクセスで実現したいこと | Intune 側で確認する状態 |
|---|---|---|
| Microsoft 365 へのアクセス | 準拠した会社管理端末だけに許可する | デバイスが Intune に登録され、コンプライアンス ポリシーに合格している |
| BYOD 端末からのアクセス | 端末管理ではなく、アプリ保護ポリシーで制御する | デバイスベースではなく app-based Conditional Access を検討する |
| 管理者アカウントのアクセス | 特定の管理端末または準拠端末からのみ許可する | 管理者用デバイス グループ、デバイス フィルター、準拠状態を確認する |
| Exchange Online へのモバイル接続 | 古いクライアントや想定外の接続を制限する | デバイス プラットフォーム、クライアント アプリ条件を分けて設計する |
Intune と Microsoft Entra ID は連携して、管理済みかつ準拠したデバイスだけが、メール、Microsoft 365、SaaS アプリ、オンプレミス アプリへアクセスできるようにします。Intune admin center にある Conditional Access ノードは Microsoft Entra ID 側の Conditional Access と同じ設定領域であり、別々のポリシーが作られるわけではありません。(Microsoft Learn)
2026年7月1日時点で押さえる更新ポイント
今回の確認ポイントは、UI の新機能よりも「設計の前提を取り違えないこと」です。特に、Intune の準拠状態を使うには、Conditional Access だけを作成しても不十分です。先に Intune のデバイス コンプライアンス ポリシーを作成し、対象デバイスが評価される状態にしておく必要があります。Microsoft の手順でも、Intune のコンプライアンス ポリシーを先に構成し、その後に Microsoft Entra の Conditional Access ポリシーで準拠状態のシグナルを使う二段階構成として説明されています。(Microsoft Learn)
| 確認項目 | 2026年7月1日時点の読み取り方 | 管理者が取るべき対応 |
|---|---|---|
| 公式ドキュメントの更新 | GitHub 履歴上はメタデータ更新が中心 | 本文の設定手順に新しい強制変更があると断定しない |
| 設定場所 | Intune admin center から作成しても Microsoft Entra の Conditional Access ポリシーとして作成される | Intune と Entra の両方で同じポリシーを重複作成しない |
| 必須の Grant 設定 | デバイス準拠状態を使うには「Require device to be marked as compliant」を選ぶ | MFA だけ、または Block access だけで代替したつもりにならない |
| 展開方法 | いきなり全ユーザー・全リソースに適用するとロックアウトや問い合わせ増加につながる | 小さなグループで Report-only から検証する |
| 移行期限 | デバイスベース CA 自体に新しい移行期限は確認できない | 関連する「Require approved client app」の移行期限は別途確認する |
影響範囲：どのユーザーと端末が影響を受けるか
影響を受けるのは、Conditional Access ポリシーの対象に含まれるユーザー、グループ、クラウド アプリ、デバイス プラットフォームです。特に「All users」や「All resources」を選ぶ場合は、管理者自身、緊急アクセス アカウント、同期用アカウント、デバイス登録直後のユーザーまで影響範囲に入る可能性があります。
Microsoft の「Require device compliance with Conditional Access」では、緊急アクセスまたは break-glass アカウントを除外すること、サービス アカウントやサービス プリンシパルの扱いに注意することが推奨されています。ユーザーを対象にした Conditional Access ポリシーではサービス プリンシパルへの呼び出しはブロックされないため、必要な場合は workload identities 向けの Conditional Access を別途検討します。(Microsoft Learn)
影響が大きくなりやすいケース
| ケース | 起きやすい問題 | 事前確認 |
|---|---|---|
| All users に適用する | 管理者までブロックされ、復旧できなくなる | break-glass アカウントを除外し、サインイン監視を設定する |
| All resources に適用する | 予想外の業務アプリや管理ポータルに影響する | まず重要アプリやパイロット グループから始める |
| Intune 未登録端末が多い | 準拠状態を返せずアクセスできない | 登録済み端末数、準拠率、非準拠理由を確認する |
| macOS、iOS、Android を含めて Report-only にする | Report-only でも証明書選択プロンプトが出る場合がある | ユーザー通知、対象プラットフォーム、検証期間を決める |
| Exchange ActiveSync をまとめて保護する | 条件の組み合わせが期待通りに効かない | Modern authentication と Exchange ActiveSync は別ポリシーで検討する |
Report-only モードは、ポリシーを有効化する前に影響を確認できる重要な機能です。ただし、準拠デバイスを要求する Report-only ポリシーでは、macOS、iOS、Android でデバイス証明書の選択が求められることがあります。これはアクセス制御自体を強制していなくても、評価のために発生し得る挙動です。(Microsoft Learn)
設定前に確認すべき前提条件
デバイスベース Conditional Access を正しく動かすには、Microsoft Entra と Intune の両方で前提条件を満たす必要があります。
| 分類 | 確認内容 | 補足 |
|---|---|---|
| ライセンス | Microsoft Entra ID P1 または P2 | Conditional Access の利用に必要 |
| Intune | Microsoft Intune サブスクリプション | デバイス コンプライアンスの評価に必要 |
| ロール | Security administrator または Conditional Access administrator | デバイスベース CA の作成に必要 |
| デバイス | Intune に登録済みで、コンプライアンス状態を返せる | 未登録端末は準拠判定に使えない |
| ポリシー | Intune のデバイス コンプライアンス ポリシーが作成・割り当て済み | Conditional Access より先に作成する |
| 除外 | break-glass アカウント、同期用アカウント、検証用グループ | ロックアウト防止に必須 |
Intune のコンプライアンス ポリシーでは、最小 OS バージョンなど、デバイスが満たすべきルールを定義できます。デバイスが準拠していない場合、Conditional Access と組み合わせてデータやリソースへのアクセスをブロックできます。Intune 側の要件としては、Intune サブスクリプション、対象プラットフォーム、デバイス登録が重要です。(Microsoft Learn)
推奨設定手順
まず Intune のコンプライアンス ポリシーを整える
最初に行うべきことは、Conditional Access ポリシーの作成ではありません。先に「何を満たせば準拠なのか」を Intune で定義します。
実務では、いきなり厳しい条件を大量に入れるより、次の順で進めると失敗しにくくなります。
| 段階 | 作業 | 判断基準 |
|---|---|---|
| 可視化 | 既存端末の登録状況と準拠状態を確認する | 非準拠端末の理由が説明できるか |
| 最小条件 | OS バージョン、暗号化、セキュリティ設定など基本条件を定義する | 業務端末の多くが現実的に満たせるか |
| 通知 | 非準拠時のユーザー通知や猶予期間を設定する | ヘルプデスクが対応できる件数に抑えられるか |
| 検証 | 一部グループに割り当て、チェックイン後の状態を確認する | Compliant、NonCompliant、InGracePeriod の意味を運用側が理解しているか |
Intune は、対象ユーザーまたはデバイスが Intune にチェックインしたタイミングでコンプライアンスを評価します。ユーザーは Company Portal アプリから同期して、ポリシー更新の確認を早めることもできます。(Microsoft Learn)
Conditional Access ポリシーを作成する
Intune 側で準拠状態を確認できるようになったら、Conditional Access ポリシーを作成します。Microsoft Learn の手順では、Microsoft Intune admin center にサインインし、Endpoint security > Conditional Access > Create new policy から作成します。作成画面は Microsoft Entra の Conditional Access 設定ペインです。(Microsoft Learn)
推奨する流れは次のとおりです。
| 手順 | 設定箇所 | 推奨内容 |
|---|---|---|
| 1 | Users and groups | 最初はパイロット グループを Include し、break-glass アカウントを Exclude する |
| 2 | Target resources | いきなり All resources にせず、重要アプリから始める |
| 3 | Conditions | 必要に応じて Device platforms、Locations、Client apps、Filter for devices を使う |
| 4 | Grant | Grant access を選び、Require device to be marked as compliant を指定する |
| 5 | Enable policy | Report-only で開始し、サインイン ログ確認後に On へ切り替える |
重要なのは、Grant の選択です。Intune の準拠状態を Conditional Access で使うには、Grant access の条件として Require device to be marked as compliant を選択する必要があります。これを選ばない場合、Intune のデバイス コンプライアンス状態はアクセス可否の判断に使われません。(Microsoft Learn)
ポリシー名は後から監査できる形にする
Conditional Access は数が増えると、どのポリシーが何を制御しているのか分かりにくくなります。名前には、対象、条件、状態を入れると運用しやすくなります。
例：
CA-DEV-RequireCompliantDevice-M365-Pilot-ReportOnly
CA-DEV-RequireCompliantDevice-AllResources-Global-On
CA-ADM-RequireCompliantDevice-AdminPortals-Onポリシー名を標準化しておくと、監査、障害対応、引き継ぎのときに「何のためのポリシーか」をすぐ判断できます。
移行期限：デバイスベース CA 自体に新しい期限はあるか
今回の「Set up device-based Conditional Access policies with Intune」については、デバイスベース Conditional Access 自体に新しい移行期限が追加されたとは読み取れません。2026年7月1日の GitHub 差分も、対象ファイルでは author、ms.author、ms.reviewer、ms.collection などのメタデータ削除が中心です。(GitHub)
ただし、Conditional Access 全体では別の移行期限に注意が必要です。Microsoft は「Require approved client app」グラントの retirement date を 2026年6月30日に延長し、同日以降、このコントロールやそれを含む既存ポリシーが読み取り専用になると説明しています。既存ポリシーは有効であれば引き続きエンドユーザーに適用されますが、管理者はこのコントロールを使う新規ポリシー作成や既存ポリシー編集ができなくなります。(Microsoft Learn)
ここで混同しやすいのは、デバイスベース CA の「Require device to be marked as compliant」と、アプリベース CA の「Require approved client app」は別物という点です。
| 項目 | 対象 | 2026年7月1日時点の注意点 |
|---|---|---|
| Require device to be marked as compliant | Intune のデバイス準拠状態 | 今回の対象。新しい移行期限は確認できない |
| Require approved client app | 承認済みクライアント アプリ | 2026年6月30日以降は読み取り専用化に注意 |
| Require app protection policy | Intune アプリ保護ポリシー | モバイルアプリ保護の移行先として確認する |
すでにモバイル向け Conditional Access で「Require approved client app」だけを使っている場合は、デバイスベース CA とは別作業として、アプリ保護ポリシーへの移行状況を確認してください。
設定変更で失敗しやすいポイント
Intune のコンプライアンス ポリシーを作らずに CA だけ作る
最も多い失敗は、Conditional Access 側で「準拠デバイスを要求する」設定だけを作り、Intune 側のコンプライアンス ポリシーが未整備のままにすることです。Microsoft の手順でも、Intune のコンプライアンス ポリシーがないと意図した動作にならないため、先にポリシーを作成し、少なくとも 1 台の準拠デバイスを確認してから進めるよう警告されています。(Microsoft Learn)
All cloud apps を選んで自分を締め出す
All resources または All cloud apps は強力ですが、管理ポータルへのアクセスも対象になる場合があります。自分の管理者アカウントを除外せずに有効化すると、設定ミスの復旧が難しくなります。
最低限、次を用意します。
| 必須対策 | 理由 |
|---|---|
| break-glass アカウントを 2 つ以上用意する | 1 つが使えない場合に備える |
| ポリシー除外を個人単位ではなく専用グループで管理する | 監査と棚卸しがしやすい |
| 除外アカウントのサインインを監視する | 攻撃者に悪用された場合に気づける |
| Report-only でサインイン ログを確認する | 有効化前に影響範囲を把握できる |
Exchange ActiveSync を他の条件と同じポリシーに詰め込む
Exchange ActiveSync を含む設計では注意が必要です。Microsoft Learn では、Modern authentication クライアントと Exchange ActiveSync クライアントの両方を保護したい場合、それぞれ別の Conditional Access ポリシーを作成することが推奨されています。Exchange ActiveSync でサポートされる条件はプラットフォームのみであり、MFA など他の条件はサポートされません。(Microsoft Learn)
Report-only を短期間で終わらせる
Report-only は「とりあえず数分だけ確認する」ためのものではありません。通常業務、出張、在宅勤務、モバイルアクセス、夜間バッチ、管理者操作など、実際のアクセスパターンを見ないと影響を判断できません。
特にグローバル展開では、国・地域、タイムゾーン、端末種別、業務アプリの違いが出ます。少なくとも主要部門、主要拠点、主要デバイス プラットフォームを含む検証期間を確保したほうが安全です。
準拠状態の反映タイミングを即時だと思い込む
Intune のコンプライアンス評価は、デバイスのチェックインや同期タイミングに左右されます。設定を変更した直後に全デバイスへ即時反映される前提で展開すると、「正しい設定なのにブロックされる」「準拠に戻したのにアクセスできない」という問い合わせが増えます。猶予期間やユーザー通知を組み合わせ、ユーザーが Company Portal から同期できる手順も案内しておくと、運用負荷を下げられます。(Microsoft Learn)
管理者が確認すべきチェックリスト
| 確認項目 | 確認方法 | 完了の目安 |
|---|---|---|
| Intune ライセンスと Entra ID P1/P2 | 管理センターのライセンス割り当てを確認 | 対象ユーザーに必要ライセンスが割り当て済み |
| 管理ロール | Entra ロールを確認 | Conditional Access Administrator または Security Administrator が利用可能 |
| コンプライアンス ポリシー | Intune > Devices > Compliance を確認 | 対象プラットフォームごとのポリシーが割り当て済み |
| 準拠デバイス | Intune のデバイス一覧を確認 | パイロット対象で Compliant 端末を確認済み |
| 除外アカウント | Conditional Access の Exclude を確認 | break-glass、同期用、検証用アカウントを整理済み |
| 対象アプリ | Target resources を確認 | 最初の対象アプリが明確 |
| Grant 設定 | Access controls > Grant を確認 | Require device to be marked as compliant が選択済み |
| 検証状態 | Report-only、サインイン ログ、Policy impact を確認 | 想定外の Failure が解消済み |
| 既存ポリシー | Entra ID > Conditional Access > Policies を棚卸し | Require approved client app の残存を確認済み |
| ユーザー案内 | 社内ヘルプ、FAQ、Company Portal 同期手順を準備 | 非準拠時の対応がユーザーに伝わる |
グローバル展開での実務的な判断基準
グローバル向けに展開する場合は、「全社一律で強制するか」よりも、「どのアクセスを最初に守るべきか」から決めると失敗しにくくなります。
優先度が高いのは、管理ポータル、Exchange Online、SharePoint、Teams、基幹 SaaS、機密データを扱うアプリです。これらに対して、まずはパイロット グループで準拠デバイス要求を検証し、問題がなければ部門単位、地域単位、全社へ広げます。
一方、個人所有端末や委託先ユーザーが多い環境では、デバイス登録を前提とするポリシーだけでは業務影響が大きくなります。その場合は、デバイスベース Conditional Access とアプリベース Conditional Access を分けて設計し、BYOD には Intune アプリ保護ポリシー、会社支給端末にはデバイス準拠ポリシーを使うと整理しやすくなります。
また、compliant network location 条件は MDM 登録済みデバイスでのみサポートされます。未登録デバイスを含むユーザーにこの条件を使うと、ポリシーチェックに失敗してブロックされる可能性があるため、対象ユーザーやデバイスの除外設計が必要です。(Microsoft Learn)
まとめ：まずは既存ポリシーの棚卸しから始める
Microsoft Entra の「Set up device-based Conditional Access policies with Intune」で重要なのは、Intune の準拠状態を Microsoft Entra Conditional Access に渡し、対象アプリへのアクセスを「準拠デバイス」に限定することです。2026年7月1日の更新履歴はメタデータ整理が中心で、デバイスベース Conditional Access 自体に新しい移行期限が追加されたとは読み取れません。
管理者が次に行うべきことは、次の 3 つです。
- Intune のデバイス コンプライアンス ポリシーが実際に対象端末を評価できているか確認する。
- Conditional Access の既存ポリシーを棚卸しし、Require device to be marked as compliant、Report-only、除外アカウント、対象アプリを確認する。
- モバイル向けに Require approved client app を使っている場合は、2026年6月30日の読み取り専用化を踏まえ、Require app protection policy への移行状況を別途確認する。
最初から全社適用を目指すより、準拠状態の可視化、パイロット、Report-only、段階的な有効化の順に進めることが、セキュリティ強化と業務影響の最小化を両立する近道です。
コメント