Microsoft Entra の Conditional Access と Microsoft Intune のコンプライアンスポリシーを組み合わせると、「誰が」「どのデバイスから」「どのアプリで」組織リソースへアクセスできるかを、より実務的に制御できます。結論から言うと、管理者が確認すべきポイントは、デバイス準拠状態をアクセス条件に使う設計、アプリ保護ポリシーへの移行、レポート専用モードでの事前検証、除外アカウントの設計の4つです。
対象となる公式ドキュメント「Use Conditional Access with Microsoft Intune compliance policies」は、Microsoft Entra Conditional Access に Intune のデバイス準拠情報やアプリ保護情報を信号として加え、メール、Microsoft 365、SaaS、オンプレミスアプリへのアクセスを制御する考え方を整理しています。なお、対象ページ自体は Microsoft Learn 上で 2026年5月20日更新と表示されています。本記事では、2026年7月1日時点で確認すべき Microsoft Entra / Intune 関連の公式情報も踏まえ、影響範囲、設定変更、移行期限、管理者が取るべき対応を実務目線で整理します。(Microsoft Learn)
Microsoft Entra の新機能・変更点：「Use Conditional Access with Microsoft Intune compliance policies」で確認すべきポイント
Microsoft Entra の Conditional Access は、ユーザー、グループ、場所、デバイス、アプリ、リスクなどの信号を使ってアクセス可否を判断する仕組みです。Intune と連携すると、単に「MFAを求める」だけでなく、「Intuneで管理され、かつ準拠しているデバイスだけ許可する」「Intuneアプリ保護ポリシーが適用されたアプリだけ許可する」といった制御が可能になります。(Microsoft Learn)
この更新ポイントを一言でまとめると、Microsoft Entra 側の条件付きアクセスを、Intune のデバイス管理・アプリ保護と一体で設計する必要性が高まっているということです。
特にグローバル企業や複数地域で Microsoft 365 を利用する組織では、次のような課題が出やすくなります。
| 課題 | よくある状態 | 見直すべきポイント |
|---|---|---|
| BYOD端末の扱い | 個人所有スマートフォンから Outlook や Teams にアクセスできる | アプリベースの Conditional Access と Intune アプリ保護ポリシーを使う |
| 会社支給端末のアクセス制御 | MDM登録済みかどうかだけで判断している | Intune のコンプライアンスポリシーで準拠状態を判定する |
| 旧ポリシーの残存 | Require approved client app に依存している | Require app protection policy への移行を確認する |
| 管理者ロックアウト | All cloud apps / All resources に強い制御を一気に適用している | 緊急アクセスアカウントとレポート専用モードを使う |
| 海外拠点・外部ユーザー | 地域や端末状態ごとの例外が増えている | ポリシーの命名、対象範囲、除外条件を棚卸しする |
Conditional Access と Intune コンプライアンスポリシーの関係
Conditional Access は Microsoft Entra の機能です。一方、デバイスが安全かどうかを判定する材料は Intune 側で作ります。つまり、Entra と Intune は役割が異なります。
| 領域 | 主な役割 | 具体例 |
|---|---|---|
| Microsoft Entra Conditional Access | アクセス可否を判断する | Microsoft 365 へアクセスする際に MFA、準拠デバイス、アプリ保護を要求する |
| Microsoft Intune コンプライアンスポリシー | デバイスが組織の基準を満たすか評価する | OSバージョン、暗号化、パスコード、脱獄・root化、脅威状態などを確認する |
| Intune アプリ保護ポリシー | アプリ内の業務データを保護する | コピー・貼り付け制限、保存先制限、PIN要求、条件付き起動などを設定する |
Microsoft の説明では、Intune のデバイス準拠状態やモバイルアプリ管理データを Conditional Access の判断材料として使える点が重要です。これにより、ユーザー認証だけでなく、利用している端末やアプリの状態まで含めてアクセスを制御できます。(Microsoft Learn)
実務では、次のような「if-then」の考え方で設計すると分かりやすくなります。
| 条件 | 制御例 |
|---|---|
| 営業部のユーザーが SharePoint にアクセスする | MFAを要求する |
| 経理部のユーザーが給与システムにアクセスする | MFAと準拠デバイスを要求する |
| 個人所有スマートフォンから Exchange Online にアクセスする | アプリ保護ポリシーが適用された Outlook のみ許可する |
| 準拠していないWindows端末から Microsoft 365 にアクセスする | アクセスをブロックする、または修復手順へ誘導する |
| 管理者が管理ポータルへアクセスする | フィッシング耐性の高い認証方法や管理端末を要求する |
影響範囲：誰が、どの端末で、どのリソースに影響するか
今回の確認対象は、Microsoft Entra だけで完結する変更ではありません。影響は、Intune で管理するデバイス、Microsoft 365 アプリ、モバイルアプリ、条件付きアクセスの既存ポリシーに広がります。
影響を受けやすいユーザー
影響を受けやすいのは、次のようなユーザーです。
| ユーザー種別 | 想定される影響 |
|---|---|
| モバイル端末で Outlook / Teams / OneDrive を使うユーザー | アプリ保護ポリシーやブローカーアプリの有無によりアクセス可否が変わる |
| BYOD利用者 | MDM登録なしでもアプリ保護ポリシーで制御される可能性がある |
| 会社支給PC利用者 | Intune の準拠状態が NG の場合、Microsoft 365 やSaaSにアクセスできない可能性がある |
| 管理者 | 管理センターへのアクセス制御が厳しい場合、除外設計を誤るとロックアウトのリスクがある |
| 海外拠点・出張者 | 場所条件、デバイス条件、MFA条件の組み合わせで追加認証やブロックが発生する可能性がある |
| 外部ユーザー・ゲスト | テナント間アクセス設定やMFA信頼設定の影響を受ける可能性がある |
影響を受ける主なリソース
Conditional Access と Intune の連携で制御対象になりやすいリソースは、次のとおりです。
| リソース | 管理上の注意点 |
|---|---|
| Exchange Online | モバイルメールアクセスの制御で影響が出やすい |
| SharePoint Online / OneDrive | 個人端末への保存やコピー制御とセットで設計する |
| Microsoft Teams | モバイル・デスクトップ双方のアクセス条件を確認する |
| SaaSアプリ | Entra ID連携アプリは条件付きアクセスの対象になり得る |
| オンプレミスアプリ | Microsoft Entra アプリケーションプロキシ等と組み合わせる場合は設計確認が必要 |
| Microsoft Intune admin center | 管理者自身がアクセスできなくならないよう除外条件を設計する |
Intune のシナリオ別ドキュメントでは、デバイスベースとアプリベースの2種類の Conditional Access が説明されています。デバイスベースでは、Intune のコンプライアンスポリシー評価結果が Entra ID に送られ、その準拠状態を使ってアクセスを許可またはブロックします。アプリベースでは、デバイス全体ではなくアプリ単位で業務データを守るため、未登録の個人端末にも適用しやすい設計です。(Microsoft Learn)
デバイスベース Conditional Access で確認すべきこと
デバイスベース Conditional Access は、Intune によって管理され、準拠と判定されたデバイスだけにアクセスを許可する方法です。会社支給PC、業務用スマートフォン、管理対象タブレットなどで特に有効です。
Microsoft の公式手順では、デバイスベース Conditional Access を構成する前に、Intune のデバイスコンプライアンスポリシーを作成しておく必要があります。そのうえで Conditional Access の Grant 制御にある Require device to be marked as compliant を選びます。(Microsoft Learn)
実務での設定イメージ
| 設定項目 | 推奨される考え方 |
|---|---|
| 対象ユーザー | まずはパイロットグループから開始する |
| 対象リソース | Microsoft 365 全体、または重要度の高いアプリから開始する |
| デバイス条件 | Windows、macOS、iOS/iPadOS、Android など利用実態に合わせる |
| Grant制御 | Require device to be marked as compliant を使用する |
| 有効化方法 | Report-only で影響を確認してから On にする |
| 除外 | 緊急アクセスアカウント、移行中のサービスアカウント、検証用アカウントを整理する |
デバイス準拠条件に入れたい代表的な項目
デバイスコンプライアンスポリシーは、厳しくすれば安全になる一方で、ユーザーの業務停止につながることがあります。最初から過剰にブロックするのではなく、業務リスクに合わせて段階的に設計するのが現実的です。
| 項目 | 確認する理由 |
|---|---|
| 最小OSバージョン | サポート切れOSや古い脆弱性を持つ端末を排除する |
| ディスク暗号化 | 紛失・盗難時の情報漏えいリスクを下げる |
| パスコード・画面ロック | 端末の物理的な不正利用を防ぐ |
| 脱獄・root化検出 | OSのセキュリティモデルが破られた端末を排除する |
| Microsoft Defender for Endpoint 連携 | 脅威状態をアクセス判断に反映する |
| セキュリティパッチレベル | 更新されていない端末を特定する |
注意したいのは、準拠ポリシーの失敗理由がユーザーに伝わらないと、ヘルプデスクへの問い合わせが急増する点です。「なぜアクセスできないのか」「どの操作で修復できるのか」を Company Portal や社内FAQで案内できるようにしておく必要があります。
アプリベース Conditional Access で確認すべきこと
アプリベース Conditional Access は、特に BYOD やモバイル利用が多い組織で重要です。端末全体をMDM管理しなくても、Outlook、Teams、OneDrive、Word、Excel などの業務アプリ内のデータを Intune アプリ保護ポリシーで制御できます。
Microsoft の公式情報では、アプリベース Conditional Access は、Intune アプリ保護ポリシーに対応したクライアントアプリだけが Exchange Online や Microsoft 365 サービスへアクセスできるようにする仕組みと説明されています。iOS では Microsoft Authenticator、Android では Company Portal などのブローカーアプリが関係します。(Microsoft Learn)
デバイスベースとアプリベースの使い分け
| 比較項目 | デバイスベース | アプリベース |
|---|---|---|
| 主な対象 | 会社支給端末、MDM管理端末 | BYOD、モバイルアプリ利用 |
| 制御単位 | デバイス全体の準拠状態 | アプリ内の業務データ |
| 必要な準備 | Intune登録、コンプライアンスポリシー | アプリ保護ポリシー、対応アプリ |
| 向いている用途 | 重要業務、管理者端末、社給PC | 個人スマホの Outlook / Teams 利用 |
| 注意点 | 非準拠時に業務停止しやすい | 対応していないアプリでは利用制限が発生する |
実務では、社給PCや業務用スマートフォンにはデバイスベース、個人所有スマートフォンにはアプリベースを使う構成がよく合います。すべてをMDM登録させようとすると、個人端末利用のルールやプライバシー面で反発が出る場合があります。一方、アプリ保護ポリシーだけではOS全体の状態を十分に制御できないため、高リスク業務にはデバイス準拠条件を組み合わせる判断が必要です。
移行期限：Require approved client app 依存のポリシーは必ず棚卸しする
Microsoft Entra Conditional Access で特に確認すべき移行ポイントが、Require approved client app から Require app protection policy への移行です。
Microsoft の移行ドキュメントでは、Require approved client app grant の退役日が 2026年6月30日まで延長されたこと、既存の「Require approved client app のみ」を使う Conditional Access ポリシーは移行が必要であること、新規ポリシーでは Require app protection policy を使うべきことが説明されています。また、2026年6月30日以降、この制御を含むポリシーは読み取り専用になり、管理者は新規作成や編集ができず、無効化または削除は可能とされています。(Microsoft Learn)
管理者が確認すべき移行対象
| 確認項目 | 対応 |
|---|---|
| Require approved client app のみを使うポリシーがある | Require app protection policy への移行を検討する |
| iOS / Android 向けのモバイルアクセス制御がある | 対象アプリがアプリ保護ポリシーに対応しているか確認する |
| 古い業務アプリやLOBアプリを利用している | Intune SDK対応やモダン認証対応を確認する |
| 例外アプリが多い | 例外理由、所有者、廃止予定を台帳化する |
| すでに読み取り専用になったポリシーがある | 無効化・削除・代替ポリシー作成の順序を決める |
移行時に失敗しやすいポイント
| 失敗例 | 何が起きるか | 回避策 |
|---|---|---|
| 対応アプリを確認せずに Require app protection policy を有効化する | 一部アプリから Microsoft 365 にアクセスできなくなる | 対象アプリの対応状況を先に確認する |
| Report-only を使わずに本番適用する | 問い合わせや業務停止が一気に発生する | 少なくともパイロットグループで検証する |
| 「Require all selected controls」と「Require one of the selected controls」を誤る | 想定以上に厳しい条件になりアクセス不可になる | Grant制御の組み合わせ条件をレビューする |
| 除外アカウントを未設定にする | 管理者がポータルに入れなくなる | 緊急アクセスアカウントを必ず除外する |
| 古いアプリを延命する | セキュリティ設計が複雑化する | 業務部門と廃止・代替計画を決める |
Microsoft の Grant 制御ドキュメントでは、複数の Grant 制御を選んだ場合、既定では選択したすべての制御が必要になると説明されています。移行時に「承認済みクライアントアプリまたはアプリ保護ポリシー」のつもりが、実際には両方必須になっていないか確認が必要です。(Microsoft Learn)
2026年7月時点で管理者が確認すべき設定変更
2026年7月時点では、Conditional Access と Intune の連携を「設定済みかどうか」だけで判断するのは不十分です。既存ポリシーが最新の推奨構成に合っているか、ユーザー体験を壊さずに運用できるかを確認する必要があります。
確認すべきチェックリスト
| チェック項目 | 確認方法 | 優先度 |
|---|---|---|
| Conditional Access ポリシーの一覧 | Entra ID > Conditional Access > Policies | 高 |
| Report-only のまま放置されたポリシー | ポリシー状態を確認 | 中 |
| Require approved client app の利用有無 | Grant制御を確認 | 高 |
| Require app protection policy の適用状況 | 対象アプリとユーザーグループを確認 | 高 |
| Intune コンプライアンスポリシーの対象 | Devices > Compliance policies | 高 |
| 非準拠デバイスの理由 | Intune のデバイスレポートを確認 | 高 |
| 緊急アクセスアカウントの除外 | 各ポリシーの Exclude を確認 | 高 |
| サービスアカウント・自動化アカウント | ユーザー対象ポリシーに巻き込まれていないか確認 | 中 |
| ユーザー通知・FAQ | 非準拠時の修復手順を整備 | 中 |
| サインインログ | Conditional Access の適用結果を確認 | 高 |
特に、グローバルテナントでは地域、雇用形態、デバイス所有形態、ネットワーク条件が複雑になりがちです。日本本社の基準だけで「すべてのユーザー・すべてのリソース」に適用すると、海外拠点や委託先で想定外のブロックが発生することがあります。
推奨される安全な展開手順
Conditional Access は強力ですが、設定を誤ると業務影響が大きい機能です。Microsoft の展開計画ドキュメントでも、事前計画、緊急アクセスアカウント、テストユーザー、段階的な展開、Report-only の利用が重視されています。(Microsoft Learn)
推奨手順
| 手順 | 作業内容 | 実務上のポイント |
|---|---|---|
| 1 | 既存ポリシーを棚卸しする | ポリシー名、対象、Grant制御、除外条件を一覧化する |
| 2 | 緊急アクセスアカウントを確認する | すべての強制ポリシーから除外し、サインイン監視を行う |
| 3 | Intune の準拠基準を見直す | OS、暗号化、パッチ、脅威状態などを業務リスクに合わせる |
| 4 | アプリ保護ポリシーを作成・確認する | Outlook、Teams、OneDrive など主要アプリから始める |
| 5 | Conditional Access を Report-only で作成する | サインインログで影響ユーザーを確認する |
| 6 | パイロットグループで有効化する | 情シス、ヘルプデスク、代表部門で検証する |
| 7 | ユーザー案内を出す | 非準拠時の修復方法、問い合わせ先、期限を明記する |
| 8 | 段階的に全社展開する | 部門・地域・端末種別ごとに分ける |
| 9 | サインインログと問い合わせを監視する | ブロック理由を分析し、必要最小限の例外にする |
| 10 | 例外を定期的に削除する | 一時除外が恒久化しないよう期限を設定する |
ポリシー名の付け方
ポリシー名は、後から見たときに目的が分かるようにします。大規模環境では「CA-001」のような番号だけでは運用が難しくなります。
例：
CA-M365-Mobile-RequireAppProtection-AllUsers
CA-SharePoint-RequireCompliantDevice-Finance
CA-AdminPortal-RequirePhishingResistantMFA-Admins
CA-Exchange-BlockLegacyAuth-AllUsers
CA-IntuneEnrollment-RequireMFA-AllUsers含めたい要素は、対象リソース、対象ユーザー、要求する制御、適用条件です。ポリシー数が増えても、名前だけで目的が分かる状態にしておくと、障害対応や監査が楽になります。
よくある設計パターン
会社支給PCから Microsoft 365 へアクセスさせる
会社支給PCでは、Intune 管理と準拠状態を条件にするのが基本です。
| 項目 | 設計例 |
|---|---|
| 対象ユーザー | 正社員、契約社員 |
| 対象デバイス | Windows、macOS |
| 対象リソース | Microsoft 365 |
| 条件 | Intuneで準拠済み |
| Grant | Require device to be marked as compliant |
| 例外 | 緊急アクセスアカウント、移行中端末の一時グループ |
この構成では、端末が暗号化されていない、OSが古い、セキュリティ設定が不足しているといった場合にアクセスを制御できます。ただし、準拠ポリシーを厳しくしすぎると、OS更新直後やセキュリティ製品の一時的な検出で業務影響が出るため、非準拠理由の監視が欠かせません。
個人スマートフォンから Outlook を使わせる
BYODでは、端末全体を管理するよりも、アプリ保護ポリシーで業務データを守るほうが現実的な場合があります。
| 項目 | 設計例 |
|---|---|
| 対象ユーザー | モバイル利用者 |
| 対象デバイス | iOS/iPadOS、Android |
| 対象リソース | Exchange Online、Microsoft 365 |
| 条件 | モバイルアプリ・デスクトップクライアント |
| Grant | Require app protection policy |
| 補足 | Outlook、Teams、OneDrive など対応アプリを事前確認 |
この構成では、個人端末に会社のMDM管理を入れずに、業務アプリ内のデータコピー、保存、PIN、条件付き起動を制御できます。ユーザー体験としては受け入れられやすい一方、アプリ保護ポリシーに対応していないアプリは利用できない場合があるため、業務アプリの棚卸しが必要です。
管理者アクセスを強化する
管理者アカウントは攻撃者に狙われやすいため、通常ユーザーより厳しい条件を設定します。
| 項目 | 設計例 |
|---|---|
| 対象ユーザー | Global Administrator、Privileged Role Administrator など |
| 対象リソース | 管理ポータル、Azure管理、Microsoft Graph 関連操作 |
| 条件 | すべての場所、または信頼済み場所以外 |
| Grant | 強力なMFA、認証強度、準拠デバイス |
| 注意点 | 緊急アクセスアカウントを除外し、サインインを監視する |
管理者向けポリシーでは、セキュリティを高めるほどロックアウトリスクも上がります。緊急アクセスアカウントは「作るだけ」では不十分です。定期的にサインインできることを確認し、利用時にはアラートが上がるようにしておくべきです。
既存環境で起きやすいトラブルと対処
非準拠デバイスが急増する
コンプライアンスポリシーを更新した直後に、非準拠デバイスが増えることがあります。原因は、OSバージョン条件、パッチ条件、暗号化条件、Defender 連携、最終チェックイン遅延などです。
対処としては、いきなりアクセスをブロックするのではなく、まず Intune レポートで非準拠理由を確認します。多くの端末が同じ理由で失敗している場合は、ポリシー条件が現実の端末状態に合っていない可能性があります。
ユーザーが「昨日まで使えたのに」と問い合わせる
Conditional Access の影響は、ユーザーから見ると突然のサインイン失敗に見えます。特にスマートフォンでは、アプリ更新、OS更新、ブローカーアプリ未導入、アプリ保護ポリシー未適用が原因になりやすいです。
ヘルプデスクには、最低限次の情報を確認する手順を用意しておきます。
| 確認項目 | 例 |
|---|---|
| ユーザー | UPN、所属、対象グループ |
| 端末 | OS、OSバージョン、管理状態、準拠状態 |
| アプリ | Outlook、Teams、OneDrive、ブラウザなど |
| 発生時刻 | サインインログ検索に必要 |
| エラー画面 | More details、Correlation ID |
| ネットワーク | 社内、VPN、海外、モバイル回線など |
Microsoft の計画ドキュメントでも、トラブルシューティング時にはユーザー、OS、時刻、対象アプリ、クライアント種別、Correlation ID などを収集することが推奨されています。(Microsoft Learn)
All resources に強い制御をかけて管理者が入れない
All resources は広い範囲を守れる反面、設計を誤ると Microsoft Entra admin center や Microsoft Intune admin center へのアクセスまで失う可能性があります。特に Block access と All resources の組み合わせは慎重に扱う必要があります。
対処としては、次の3点を徹底します。
- 緊急アクセスアカウントをすべての強制ポリシーから除外する
- 本番有効化前に Report-only と What If で確認する
- 変更直後にサインインログを確認し、想定外のブロックがないか見る
グローバル企業での設計ポイント
グローバル向けに Microsoft Entra と Intune の Conditional Access を運用する場合、日本国内だけの設計よりも考慮点が増えます。
地域ごとのネットワーク条件を分ける
国や地域ごとに通信経路、VPN、プロキシ、ゼロトラストネットワーク製品が異なる場合、場所条件を単純に「日本以外はブロック」とすると業務に影響します。拠点IP、VPN出口、出張時の利用パターンを整理し、Named locations の運用責任者を決めておく必要があります。
端末標準化のレベルを合わせる
本社では Windows 11 + Intune 管理が進んでいても、海外拠点では macOS、Android、共有端末、委託先PCが混在することがあります。デバイスベース Conditional Access を全社一律で適用する前に、地域ごとの端末管理成熟度を確認します。
法規制とプライバシーに配慮する
BYODにMDM登録を求めるか、アプリ保護ポリシーにとどめるかは、国や地域の労務・プライバシー慣行にも影響されます。グローバルでは「技術的にできる」だけでなく、「従業員に説明できる」設計が必要です。
例外をローカル任せにしない
海外拠点ごとに例外を自由に増やすと、Conditional Access の全体像が分からなくなります。例外はグループ化し、所有者、理由、期限を記録します。3か月または6か月ごとに棚卸しし、期限切れの例外は削除する運用が望ましいです。
管理者向けの実務チェックリスト
最後に、今回の更新ポイントを踏まえた管理者向けチェックリストを整理します。
| 分類 | 確認内容 | 対応の目安 |
|---|---|---|
| 既存ポリシー | Conditional Access ポリシーを一覧化したか | すぐ確認 |
| 移行 | Require approved client app のみのポリシーが残っていないか | 最優先 |
| アプリ保護 | Require app protection policy を使う設計に移行できているか | 高 |
| デバイス準拠 | Intune コンプライアンスポリシーが現行OS・端末実態に合っているか | 高 |
| BYOD | 個人端末に対して MDM と MAM の使い分けを決めているか | 高 |
| 管理者保護 | 管理者向けに強い認証と準拠端末条件を設定しているか | 高 |
| 除外 | 緊急アクセスアカウントを除外しているか | 最優先 |
| 検証 | Report-only、What If、サインインログで確認しているか | 高 |
| 周知 | ユーザー向け修復手順とヘルプデスク手順があるか | 中 |
| 運用 | 例外、ポリシー数、命名規則を定期的に見直しているか | 中 |
まとめ：次にやるべきこと
Microsoft Entra の Conditional Access と Microsoft Intune のコンプライアンスポリシー連携は、ゼロトラストの実装において重要な基盤です。今回確認すべき本質は、新しい画面や単独機能の追加ではなく、アクセス制御をユーザー認証だけで終わらせず、デバイス準拠状態とアプリ保護状態まで含めて判断することにあります。
管理者がまず行うべきことは、既存の Conditional Access ポリシーを棚卸しし、Require approved client app に依存したポリシーが残っていないか確認することです。次に、Intune のコンプライアンスポリシーとアプリ保護ポリシーを見直し、Report-only で影響を確認してから段階的に本番適用します。
特に、2026年6月30日を境に Require approved client app を含むポリシーの扱いが変わっているため、古いモバイルアクセス制御をそのままにしている環境は早めの確認が必要です。セキュリティを強化するほど、ユーザー影響と管理者ロックアウトのリスクも高まります。緊急アクセスアカウント、パイロット展開、ログ確認、ユーザー周知をセットで進めることが、失敗しない Conditional Access 運用の近道です。
コメント