Microsoft Entraの条件付きアクセス条件を見直すなら、最初に確認すべき答えは「どの条件を使うか」よりも「どの条件を組み合わせると業務影響が出るか」です。特に2026年5月17日の公式ドキュメント差分では、AppleデバイスのデバイスIDキー保管先がApple KeychainからApple Secure Enclaveへ移行する流れに関連して、Safariを含む非MSALアプリでMicrosoft Enterprise SSOプラグインを有効にする重要性が追記されました。iOS、iPadOS、macOSで「準拠デバイスを要求する」「デバイスのフィルター」を使っている管理者は、優先的に確認すべき更新です。(GitHub)
この記事では、Microsoft Entraの条件付きアクセス条件について、ユーザーリスク、サインインリスク、インサイダーリスク、デバイス、ネットワーク、クライアントアプリの使い分けを整理します。あわせて、管理者や開発者が確認すべき設定、移行、展開時の注意点まで、実務で使える判断基準としてまとめます。
Microsoft Entraの条件付きアクセス条件で確認すべき変更点
Microsoft Entraの条件付きアクセスは、ユーザー、デバイス、ネットワーク、アプリ、リスクなどのシグナルを組み合わせて、アクセスを許可するか、MFAを要求するか、ブロックするかを判断する仕組みです。公式ドキュメントでは、条件としてエージェントリスク、ユーザーリスク、サインインリスク、インサイダーリスク、デバイスプラットフォーム、クライアントアプリ、デバイスのフィルター、認証フローなどが整理されています。(Microsoft Learn)
| 確認項目 | 内容 | 管理者が取るべき対応 |
|---|---|---|
| Apple Secure Enclave関連の追記 | AppleデバイスでデバイスIDキーの保管先がSecure Enclaveへ移行する流れに合わせ、Safariなど非MSALアプリでEnterprise SSOプラグインが重要になる | iOS、iPadOS、macOSのMDM構成、Enterprise SSOプラグイン、Safariや業務アプリの動作を確認する |
| エージェントリスク | エージェントが侵害されている可能性を条件付きアクセスで評価するプレビュー項目 | AIエージェントや自動化エージェントを使う環境では、対象範囲を限定して検証する |
| ユーザーリスク／サインインリスク | アカウント侵害の可能性や、本人以外によるサインインの可能性を条件にできる | ユーザーリスクとサインインリスクは別ポリシーで設計する |
| インサイダーリスク | Microsoft Purviewのリスクシグナルを条件付きアクセスに組み込める | 内部不正、情報持ち出し、退職予定者リスクなどの運用ルールと合わせて設計する |
| デバイス状態 | 非推奨。代替としてデバイスのフィルターを使う | 既存ポリシーで「デバイス状態」を使っていないか棚卸しする |
| 場所条件 | LocationはNetworkへ移動・名称変更。既存ポリシーは引き続き動作する | 運用手順書や管理者教育では「Network」表記に更新する |
| クライアントアプリ | 新規ポリシーは未構成でもすべてのクライアントアプリ種別に適用される | レガシ認証、Exchange ActiveSync、古いOfficeクライアントへの影響を事前に確認する |
重要なのは、これらを単独で見るのではなく、「誰が」「どのアプリへ」「どの端末から」「どのネットワークで」「どのリスク状態で」アクセスするかを組み合わせて評価することです。複数の条件付きアクセスポリシーが同時に適用される場合、該当する要件はすべて満たす必要があり、ブロック制御が該当するとそこでアクセスは停止します。(Microsoft Learn)
2026年5月17日の実務ポイントはAppleデバイスとEnterprise SSO
今回の差分で最も見落としやすいのは、Appleデバイスの条件付きアクセスです。Microsoft Entra IDでは、AppleデバイスのデバイスIDキーをApple KeychainからApple Secure Enclaveへ移行する方針が示されており、2025年8月以降のSecure Storageロールアウトでは、新規デバイス登録でSecure Enclaveが既定のキー保管先になります。これにより、Keychain内のデバイス登録キーへ依存しているアプリやMDMソリューションは、MSALとEnterprise SSOプラグインへの対応が必要になります。(Microsoft Learn)
特に影響を受けやすいのは、次のような環境です。
| 対象 | 確認すべきポイント | 影響が出やすい例 |
|---|---|---|
| Safariを使うiOS／macOSユーザー | Enterprise SSOプラグインが有効か | SafariからSharePointや業務SaaSへアクセスすると「管理対象デバイスが必要」と判定される |
| 非MSALの業務アプリ | Apple標準のネットワーク技術や標準プロトコルを使っているか | 独自実装の通信レイヤーを持つアプリでSSOやデバイス判定が失敗する |
| Chrome／Firefox／Edge on macOS | 必要なSSO拡張機能やブラウザポリシーが設定されているか | 準拠デバイス条件を満たすはずの端末が未管理扱いになる |
| MDM管理者 | Enterprise SSOプラグインのプロファイルが対象デバイスに配布されているか | IntuneやJamfなどで一部グループだけ構成漏れがある |
| アプリ開発者 | Keychain上のデバイス登録キーへ直接依存していないか | デバイス登録情報を参照する独自処理がSecure Enclave移行後に失敗する |
サインインログでエラーコード530003、失敗理由として「Device is required to be managed to access this resource.」が出る場合は、まずEnterprise SSOプラグインや必要なアプリ固有の拡張機能が有効かを確認します。Secure Enclaveを無効化する設定はトラブルシューティング用途に限定すべきで、保管先の変更を反映するにはデバイスの登録解除と再登録が必要です。(Microsoft Learn)
条件ごとの使い分けと判断基準
ユーザーリスクとサインインリスクは別ポリシーで管理する
ユーザーリスクは「IDまたはアカウントが侵害されている可能性」、サインインリスクは「その認証要求が本人によるものではない可能性」を示します。公式ドキュメントでは、サインインリスクとユーザーリスクの条件を同じ条件付きアクセスポリシーで組み合わせず、別々のポリシーとして作成するよう警告されています。(Microsoft Learn)
実務では、次のように分けると運用しやすくなります。
| 条件 | 向いている対応 | 具体例 |
|---|---|---|
| ユーザーリスク：高 | リスク修復を要求する | アカウント侵害の疑いがあるユーザーに、強力な再認証やセキュアなパスワード変更を求める |
| サインインリスク：中／高 | MFAまたは認証強度を要求する | 普段と異なる場所や不審なサインインに対して、追加認証を求める |
| 低リスク | すぐにブロックせず監視から始める | 誤検知が多い業務環境では、レポート専用モードで傾向を見る |
ライセンス面では、条件付きアクセス自体にはMicrosoft Entra ID P1が必要で、リスクベースのポリシーにはMicrosoft Entra ID Protection、つまりMicrosoft Entra ID P2相当の機能が必要です。運用前に、対象ユーザーのライセンス範囲を確認してください。(Microsoft Learn)
また、従来のMicrosoft Entra ID Protectionのレガシーリスクポリシーは、2026年10月1日に廃止予定とされています。既存環境でID Protection側のユーザーリスクポリシーやサインインリスクポリシーを使っている場合は、条件付きアクセス上に同等のポリシーをレポート専用モードで作成し、影響確認後に本番化してから古いポリシーを無効化する流れが安全です。(Microsoft Learn)
インサイダーリスクは「アクセス制御」だけでなく運用設計が重要
インサイダーリスク条件は、Microsoft Purviewのアダプティブ保護から得られるシグナルを条件付きアクセスに組み込むものです。ユーザー行動、過去のパターン、異常検出などをもとに、アクセスブロック、より強い認証方法の要求、利用規約への同意要求などを実行できます。(Microsoft Learn)
ただし、インサイダーリスクは単純な「怪しいからブロック」では運用に失敗しやすい条件です。たとえば、退職予定者、機密部門の異動者、大量ダウンロードが発生したユーザーなどを対象にする場合、セキュリティ部門、人事、法務、監査部門の対応フローも同時に決めておく必要があります。条件付きアクセスは入口を制御できますが、調査、例外承認、証跡保存まで自動で整うわけではありません。
エージェントリスクはプレビューとして慎重に扱う
エージェントリスクは、エージェントが侵害されている可能性を条件付きアクセスで評価するプレビュー機能です。AIエージェントや自動化エージェントがMicrosoft 365や業務アプリへアクセスする環境では重要な確認項目になりますが、プレビュー機能は仕様や提供範囲が変わる可能性があります。まずは対象エージェント、アクセス先、実行権限、ログの見え方を小さな範囲で検証し、本番全体の必須条件にする前に運用手順を固めるべきです。(Microsoft Learn)
デバイス、ネットワーク、クライアントアプリ条件の注意点
デバイスプラットフォームだけを信頼しない
デバイスプラットフォーム条件は、Android、iOS、Windows、macOS、Linuxなどを対象にできます。ただし、判定にはユーザーエージェント文字列などデバイスが提供する情報が使われ、この情報は変更可能です。Microsoftも、デバイスプラットフォーム条件はIntuneのデバイス準拠ポリシーと組み合わせるか、ブロック条件の一部として使うことを推奨しています。(Microsoft Learn)
実務では、「Windowsだけ許可する」ではなく、「WindowsかつIntuneで準拠済み」「管理者はセキュア管理端末のみ」「未サポートOSはブロック」といった条件に落とし込むのが安全です。Chrome OSなどサポート対象外のクライアントをブロックしたい場合は、任意のデバイスを含め、サポート対象プラットフォームを除外し、ブロック制御を設定する設計が考えられます。(Microsoft Learn)
LocationはNetworkへ移動・名称変更された
従来の場所条件はNetworkへ移動・名称変更されました。既存のLocationを使った条件付きアクセスポリシーは変更なしで動作しますが、Microsoft Entra管理センター上の表記や運用ドキュメントでは「Network」として扱う場面が増えます。(Microsoft Learn)
ネットワーク条件では、任意のネットワーク、信頼済みネットワーク、Global Secure Accessの準拠ネットワーク、選択した名前付き場所を使い分けます。IPアドレス範囲、国や地域、GPS座標による場所判定も扱えますが、GPSベースの条件はMicrosoft Authenticatorアプリによる位置共有が必要で、ユーザーに定期的な通知が出る場合があります。機密性の高いアプリに限定し、一般業務アプリへ安易に広げないほうがよいでしょう。(Microsoft Learn)
クライアントアプリ条件ではレガシ認証を見落とさない
新しく作成した条件付きアクセスポリシーは、クライアントアプリ条件を構成していない場合でも、既定ですべてのクライアントアプリ種別に適用されます。ここを誤解すると、「ブラウザだけに効くと思っていたポリシーがOutlookや古いメールクライアントにも影響した」という事故につながります。(Microsoft Learn)
特にレガシ認証クライアントはMFAをサポートせず、デバイス状態情報も渡せません。そのため、MFAや準拠デバイスを要求するポリシーではブロックされます。SMTP、POP、IMAP、EWS、古いOfficeクライアント、Exchange ActiveSyncを使っている可能性がある場合は、サインインログで実利用を確認してから段階的にブロックしてください。(Microsoft Learn)
デバイス状態からデバイスのフィルターへ移行する
「デバイスの状態」条件は非推奨です。以前この条件で実現していたシナリオは、条件付きアクセスの「デバイスのフィルター」で置き換える必要があります。デバイスの状態とデバイスのフィルターは同じポリシー内で併用できません。(Microsoft Learn)
デバイスのフィルターでは、trustType、isCompliant、deviceOwnership、operatingSystem、extensionAttribute1-15などのデバイス属性を使って、対象デバイスを含めたり除外したりできます。たとえば、特権管理者に対して「セキュア管理端末としてマークされた端末以外はAzure管理APIをブロックする」といった設計が可能です。(Microsoft Learn)
注意したいのは、未登録デバイスの扱いです。Microsoft Entra IDに登録されていないデバイスでは、デバイス属性は判定できません。未登録デバイスを対象にしたい場合は、肯定条件ではなく否定演算子を使う設計が有効です。たとえば「準拠している端末だけ許可」よりも、「準拠していない、または条件に合わない端末をブロック」と設計したほうが、未登録デバイスを取りこぼしにくくなります。(Microsoft Learn)
管理者が確認すべき設定チェックリスト
条件付きアクセス条件を見直すときは、個別のポリシーだけでなく、組織全体の適用関係を確認します。複数ポリシーが重なった場合、ユーザーはすべての該当要件を満たす必要があるため、単体テストでは問題がなくても本番ではブロックされることがあります。(Microsoft Learn)
| 確認項目 | 具体的に見る場所 | 完了基準 |
|---|---|---|
| 緊急アクセスアカウント | 条件付きアクセスの除外設定 | ブレークグラスアカウントが全主要ポリシーから除外され、サインイン確認済み |
| リスクポリシー | ID Protectionと条件付きアクセス | レガシーリスクポリシーの有無を確認し、条件付きアクセスへの移行計画がある |
| Appleデバイス | Intune、Jamf、MDM構成、サインインログ | Enterprise SSOプラグインが対象端末へ配布され、Safariや非MSALアプリで検証済み |
| デバイス状態 | 既存ポリシーの条件 | 非推奨のデバイス状態を使うポリシーを洗い出し、デバイスのフィルターへ置き換える |
| ネットワーク条件 | Named locations、Network assignment | Location表記の運用手順をNetworkへ更新し、信頼済み場所のIP範囲が最新 |
| クライアントアプリ | サインインログ、レガシ認証の利用状況 | POP、IMAP、SMTP、EAS、古いOfficeクライアントの影響を確認済み |
| レポート専用モード | Conditional AccessのEnable policy | 本番化前にReport-onlyで影響を確認し、想定外のブロック対象がない |
| What If | Entra ID > Conditional Access > Policies > What If | 主要ユーザー、管理者、ゲスト、サービスプリンシパル相当のシナリオを検証済み |
Report-onlyモードでは、ポリシーを適用せずに評価結果をサインインログへ記録できます。ただし、準拠デバイスを要求するReport-onlyポリシーでは、macOS、iOS、Androidでデバイス証明書の選択プロンプトが出る場合があります。ユーザー影響を避けたい場合は、検証対象のプラットフォームを絞ることが大切です。(Microsoft Learn)
What Ifツールは、ユーザー、エージェントID、単一テナントのサービスプリンシパルに対して、指定した条件でどのポリシーが適用されるかをシミュレーションできます。ただし、Microsoft Teamsに対するExchange Onlineのようなサービス依存関係まではテストしないため、最終判断はサインインログや実ユーザーのパイロット検証と組み合わせて行う必要があります。(Microsoft Learn)
開発者とアプリ担当者が確認すべきポイント
アプリ開発者にとって重要なのは、「条件付きアクセスは管理者側の設定だけで完結しない」という点です。特にAppleデバイスでは、アプリがMSALを使っているか、Apple標準のネットワーク技術を使っているか、Enterprise SSOプラグインに参加できるかが、デバイスベースの条件付きアクセス成功に影響します。(Microsoft Learn)
非MSALアプリでも、Appleの標準的なネットワーク技術を使い、OAuth 2.0、SAML、WS-Federationなどの標準プロトコルでMicrosoft Entra IDと通信し、ネイティブUIで平文のユーザー名やパスワードを収集しない場合は、Enterprise SSOプラグインによるSSOの対象にできます。逆に、独自の通信レイヤーや独自の資格情報収集を行うアプリは、デバイスベースの条件付きアクセスで問題が出やすくなります。(Microsoft Learn)
サービスプリンシパルや自動化処理も確認が必要です。ユーザーを対象にした条件付きアクセスポリシーは、サービスプリンシパルにそのまま適用されません。サービスプリンシパルを制御するには、Conditional Access for workload identitiesを使い、対象サービスプリンシパルをポリシーへ直接指定します。グループにサービスプリンシパルを入れても、そのグループ割り当ての条件付きアクセスポリシーはサービスプリンシパルには適用されません。(Microsoft Learn)
展開時に失敗しやすいポイント
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| Apple端末が準拠済みなのにブロックされる | Enterprise SSOプラグインやブラウザ拡張が未構成 | MDMプロファイル、Safari、Chrome、Firefox、Edgeの構成を確認する |
| レガシ認証ブロックで業務メールが止まる | POP、IMAP、SMTP、EASの利用実態を未確認 | サインインログでクライアントアプリ種別を確認してから段階適用する |
| リスクポリシーが複雑で追跡できない | ユーザーリスクとサインインリスクを同一ポリシーに混在 | リスク条件ごとにポリシーを分け、命名規則を統一する |
| 未登録デバイスがすり抜ける | デバイスフィルターで肯定条件だけを使っている | 未登録デバイスを想定し、否定条件やブロック条件を設計する |
| GPS条件でユーザーから問い合わせが増える | 位置情報共有の通知や再承認が頻発する | GPS条件は高機密アプリに限定し、事前に利用者へ周知する |
| 管理者自身がロックアウトされる | ブロックポリシーをいきなり全体適用した | ブレークグラスアカウントを除外し、Report-onlyとWhat Ifで検証する |
| Secure Enclaveを無効化して恒久対応にしてしまう | 一時的なトラブルシュート設定を残した | 無効化は検証用途に限定し、MSALとEnterprise SSO対応を本筋にする |
ブロック制御は強力ですが、誤設定すると正規ユーザーや管理者まで締め出します。特に「すべてのユーザー」「すべてのリソース」「任意のネットワーク」「ブロック」を組み合わせる場合は、必ず小さなパイロットから始めてください。(Microsoft Learn)
まず実施すべき対応
Microsoft Entraの条件付きアクセス条件を見直す際は、最初にAppleデバイスとデバイスベース条件付きアクセスの組み合わせを確認してください。iOS、iPadOS、macOS、Safari、非MSAL業務アプリ、Enterprise SSOプラグイン、Secure Enclaveの影響は、ユーザーのサインイン失敗として表面化しやすい領域です。
次に、リスクベースポリシーを確認します。レガシーID Protectionポリシーが残っている場合は、条件付きアクセスへ移行する計画を立てます。ユーザーリスクとサインインリスクは別ポリシーにし、Report-onlyで影響を確認してから本番化してください。
最後に、非推奨のデバイス状態、LocationからNetworkへの表記変更、レガシ認証、デバイスのフィルター、サービスプリンシパルの扱いを棚卸しします。条件付きアクセスは一度設定して終わりではなく、端末、認証方式、アプリ、リスクシグナルの変化に合わせて継続的に見直すセキュリティ基盤です。
コメント