Microsoft Entra Conditional Access展開計画の要点｜管理者が確認すべき影響範囲と設定

Microsoft Entraの条件付きアクセスは、MFAを強制するだけの機能ではありません。ユーザー、デバイス、場所、アプリ、リスクなどの条件を組み合わせて、「誰に、どのアプリへ、どの条件で、どの制御を求めるか」を決めるアクセス制御の中核です。

2026年6月上旬に更新されたMicrosoft公式情報では、Microsoft Entra Conditional Accessの展開計画について、セキュリティ強化と業務生産性のバランスを取りながら、段階的に設計・テスト・本番展開することが強調されています。特に管理者が確認すべきポイントは、緊急用アカウントの除外、レポート専用モードでの検証、ポリシー数の抑制、ゲストやサービスアカウントへの影響、ロールバック手順の準備です。(Microsoft Learn)

この記事では、Microsoft Entraの条件付きアクセス展開計画について、変更点の見方、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。

Microsoft Entra Conditional Accessの更新で押さえるべき結論

今回の公式情報の要点は、条件付きアクセスを「個別アプリごとの場当たり的な制御」ではなく、組織全体のゼロトラスト方針に基づくアクセス制御基盤として計画する点にあります。

特に重要なのは、次の5点です。

確認ポイント	管理者が取るべき対応
緊急用アカウント	すべての条件付きアクセスポリシーから除外する
展開方法	いきなり有効化せず、レポート専用モードとパイロットグループで検証する
ポリシー設計	アプリ単位で増やしすぎず、共通要件ごとに統合する
影響確認	サインインログ、What Ifツール、Insights and Reporting workbookで確認する
ロールバック	無効化、除外、一時的な例外、削除済みポリシーの復元手順を事前に用意する

条件付きアクセスは柔軟性が高い反面、設定を誤ると管理者自身がサインインできなくなる、業務アプリが突然使えなくなる、モバイル利用者やゲストユーザーだけが影響を受ける、といった問題が起きます。公式情報でも、展開前の計画と検証の重要性が明確に示されています。(Microsoft Learn)

条件付きアクセスは何を制御する機能なのか

Microsoft Entra Conditional Accessは、サインイン時の状況に応じてアクセス可否や追加認証を制御する仕組みです。

典型的には、次のような条件を組み合わせます。

条件の種類	例
ユーザー・グループ	全社員、管理者、経理部門、ゲストユーザー
対象リソース	Microsoft 365、社内SaaS、特定のクラウドアプリ
場所	社内ネットワーク、信頼済みIP、海外からのアクセス
デバイス	準拠済みデバイス、Microsoft Entra hybrid joinedデバイス、モバイル端末
クライアントアプリ	ブラウザー、モバイルアプリ、レガシー認証クライアント
リスク	サインインリスク、ユーザーリスク
制御	MFA要求、準拠デバイス要求、アクセス拒否、セッション制御

たとえば「経理部門が給与システムへアクセスする場合はMFAと準拠済みデバイスを要求する」「経理部門以外は給与システムへのアクセスをブロックする」といった制御を設計できます。

ここで注意したいのは、MFA要求ポリシーだけでは、対象外ユーザーのアクセスを自動的に拒否するとは限らないことです。公式情報では、特定グループにMFAを求めるポリシーとは別に、対象外ユーザーをブロックするポリシーを作る例が示されています。条件付きアクセスは「条件に合ったときに制御を適用する」仕組みであり、許可・拒否の境界を明確に設計する必要があります。(Microsoft Learn)

今回の公式情報で特に重要な変更・強調点

2026年6月上旬の公式情報では、単に「ポリシーを作る方法」ではなく、組織として安全に運用するための計画項目が強調されています。

ポリシー数を増やしすぎない設計が重要

Microsoft Entraの条件付きアクセスポリシーには、テナントあたり240個という上限があります。この上限には、有効、無効、レポート専用モードのポリシーも含まれます。(Microsoft Learn)

そのため、アプリごと、部署ごと、例外ごとにポリシーを乱立させる設計は避けるべきです。短期的には分かりやすく見えても、数か月後には「どのポリシーが誰に効いているのか分からない」状態になりやすくなります。

実務では、次のようにまとめると管理しやすくなります。

避けたい設計	推奨される設計
アプリ1つにつき1ポリシーを作る	同じ要件のアプリをまとめて1ポリシーにする
ユーザーを個別に列挙する	グループやロールで対象を指定する
例外ユーザーを場当たり的に追加する	例外の理由、期限、承認者を別管理する
命名規則なしで作成する	目的、対象、制御、範囲が分かる名前にする

たとえば、すべてのMicrosoft 365アプリに同じMFA要件を適用するなら、Excel、SharePoint、Teams、Outlookなどを個別に分けるより、共通要件としてまとめた方が運用しやすくなります。

All resourcesの利用は有効だが、ブロック条件との組み合わせに注意

公式情報では、すべてのアプリに少なくとも1つの条件付きアクセスポリシーが適用される状態を推奨しています。新しいアプリを追加するたびにポリシーを更新しなくて済むため、セキュリティの抜け漏れを減らせるからです。(Microsoft Learn)

一方で、「All resources」と「ブロック」を同じポリシーで強く使いすぎると、管理者のロックアウトにつながる恐れがあります。Microsoft Graphなど重要なエンドポイントには単純な除外を構成できないケースもあるため、全体適用のブロックポリシーは特に慎重に扱う必要があります。

実務上は、最初から全社ブロックを有効化するのではなく、次の順序が安全です。

段階	内容
設計	対象ユーザー、対象アプリ、除外条件、緊急用アカウントを整理
レポート専用	実際のサインインに対する影響をログで確認
パイロット	情シス、ITリテラシーの高い部門、限定ユーザーで検証
段階展開	部門・拠点・利用シナリオごとに順次拡大
本番化	問い合わせ窓口とロールバック手順を用意して有効化

管理者操作そのものを保護する「protected actions」も確認対象

条件付きアクセスの管理画面を操作できるアカウントが侵害されると、攻撃者がMFA要件を弱めたり、特定ユーザーを除外したりするリスクがあります。

公式情報では、条件付きアクセスポリシーの作成、変更、削除といった重要操作に対して、追加の検証を求める「protected actions」の有効化が推奨されています。(Microsoft Learn)

管理者は、条件付きアクセスで一般ユーザーを守るだけでなく、条件付きアクセスを変更できる管理者操作も守るという視点を持つ必要があります。

影響範囲：誰に、どの業務に影響するのか

条件付きアクセスの展開では、影響範囲を「全ユーザー」とだけ考えると見落としが出ます。実際には、ユーザー種別、端末種別、アプリ種別、認証方式ごとに影響が異なります。

対象	起こりやすい影響	確認すべきこと
一般ユーザー	MFA登録や追加認証が必要になる	認証方法の登録状況、問い合わせ導線
管理者	管理ポータルやGraph操作に影響	緊急用アカウント、PIM、protected actions
ゲストユーザー	外部テナントのMFAやデバイス状態の扱いが問題になる	クロステナントアクセス設定、ゲスト向け案内
モバイル利用者	承認済みアプリやアプリ保護ポリシーが必要になる	Intune設定、対象アプリ、BYOD方針
開発者・自動化処理	スクリプトやサービスプリンシパルの認証に影響	ユーザー認証依存の処理、マネージドIDへの移行
レガシー認証利用者	古いメールクライアントや古い認証方式が使えなくなる	レガシー認証の利用状況、代替手段

特に見落としやすいのが、開発者や運用担当者が使っているスクリプトです。個人ユーザーの資格情報を使ってバッチ処理や管理操作を行っている場合、MFA強制やサインイン頻度の変更で処理が止まる可能性があります。

公式情報でも、サービスアカウントやサービスプリンシパルについては、ユーザー対象の条件付きアクセスポリシーとは扱いが異なる点が示されています。スクリプトやコードで使っているアカウントは、可能であればマネージドIDなど、用途に合った認証方式へ見直すことが重要です。(Microsoft Learn)

展開前に管理者が確認すべき設定

条件付きアクセスの展開前には、ポリシーを作る前に棚卸しを行うべきです。画面上でいきなり設定を始めると、例外や依存関係を見落としやすくなります。

ライセンス要件を確認する

条件付きアクセスの利用には、Microsoft Entra ID P1、P2、または試用版ライセンスが必要です。また、Microsoft Entra ID Protectionのリスク情報を条件付きアクセスに組み込む場合は、Microsoft Entra ID P2が必要です。(Microsoft Learn)

確認すべきポイントは次の通りです。

確認項目	見るべきポイント
Microsoft Entra ID P1	条件付きアクセスの基本ポリシーを使えるか
Microsoft Entra ID P2	ユーザーリスク、サインインリスクを使う予定があるか
Microsoft 365やEMSの契約	既存契約に必要なEntra機能が含まれているか
ゲスト・外部ユーザー	適用対象とライセンス要件の考え方を整理しているか

リスクベースのポリシーを後から追加する予定があるなら、最初の設計段階でP2要件を考慮しておくと、移行時の手戻りを減らせます。

管理者ロールを最小権限で割り当てる

条件付きアクセスを閲覧するだけならSecurity Reader、作成・変更・復元を行うならConditional Access Administratorなど、作業内容に応じたロールが必要です。公式情報では、最小権限の原則に従い、Privileged Identity Managementを使ったジャストインタイムの権限有効化も推奨されています。(Microsoft Learn)

実務では、常時グローバル管理者で運用するのではなく、次のように役割を分けると安全です。

役割	推奨される運用
設計担当	ポリシー案、対象、例外、影響範囲を整理
承認者	セキュリティ・業務影響の観点でレビュー
実装担当	Conditional Access Administratorなど必要最小限の権限で設定
監査担当	サインインログ、変更履歴、例外管理を確認

緊急用アカウントを必ず除外する

条件付きアクセス展開で最も危険なのは、管理者全員がサインインできなくなることです。公式情報では、緊急アクセス用、いわゆるbreak-glassアカウントをポリシーから除外することが推奨されています。(Microsoft Learn)

緊急用アカウントは、単に作るだけでは不十分です。次の観点で管理します。

項目	推奨対応
アカウント数	少数に限定する。ただし単一障害点にならないよう複数用意する
通常利用	日常業務では使わない
パスワード管理	厳格に保管し、利用時は記録を残す
監視	サインインが発生したら検知できるようにする
除外設定	すべての条件付きアクセスポリシーから除外されているか確認する

緊急用アカウントを除外し忘れると、MFA障害、認証方式の設定ミス、場所条件の誤判定などで管理者が復旧操作をできなくなる可能性があります。

ポリシー設計で確認すべき質問

公式情報では、条件付きアクセスポリシーを作成する前に、対象や制御について質問形式で整理することが推奨されています。実務では、以下のような設計シートを作るとレビューしやすくなります。

設計項目	確認する質問
ユーザー	対象は全員か、特定グループか、管理者か、ゲストか
除外	緊急用アカウント、例外ユーザー、サービスアカウントは含まれていないか
対象アプリ	Microsoft 365全体か、特定SaaSか、ユーザー操作か
条件	場所、デバイス、プラットフォーム、クライアントアプリ、リスクを使うか
制御	MFA、準拠デバイス、承認済みアプリ、ブロック、利用規約同意のどれを求めるか
セッション	サインイン頻度、永続ブラウザーセッション、アプリ制御を使うか
影響確認	レポート専用モードでどのログを見るか
ロールバック	失敗時に無効化するか、除外するか、別ポリシーへ切り替えるか

この設計を残しておくと、後から「なぜこのポリシーが存在するのか」を説明しやすくなります。条件付きアクセスは一度作って終わりではなく、組織変更、アプリ追加、拠点変更、セキュリティ要件の変化に合わせて継続的に見直す必要があります。

推奨される段階的な展開方法

公式情報では、条件付きアクセスの展開を大きく3つのフェーズに分ける考え方が示されています。組織規模や変更管理の体制によって期間は調整できますが、最初から全機能を一気に有効化しないことが重要です。(Microsoft Learn)

Phase 1：基盤整備

最初に行うべきなのは、強力な制御を追加することではなく、基本的なリスクを減らし、MFA展開の準備を整えることです。

代表的な内容は次の通りです。

項目	目的
レガシー認証のブロック	古い認証方式を悪用した攻撃を防ぐ
MFA登録ページの保護	認証方法の登録プロセスを安全にする
特権ロールへの強力な認証要求	管理者アカウントの侵害リスクを下げる

ここで重要なのは、ユーザーがMFAを登録できる状態になっているかを事前に確認することです。登録導線が整っていないままMFAを強制すると、問い合わせが急増します。

Phase 2：中核となる認証制御

次に、全ユーザーやゲストユーザーに対する強力な認証、モバイル利用時の保護を展開します。

項目	想定される影響
全ユーザーの強力な認証	サインイン時にMFAなどが求められる
ゲストアクセスの保護	外部ユーザーにも追加認証が必要になる
承認済みクライアントアプリ・アプリ保護	モバイル利用時に利用アプリが制限される
デバイス参加・登録時のMFA	新規端末登録時の操作が変わる

この段階では、ユーザー体験への影響が大きくなります。社内告知、FAQ、ヘルプデスク向け手順書を用意してから展開するべきです。

Phase 3：高度な保護

最後に、リスクベースの制御や高度な攻撃対策を追加します。

項目	注意点
高リスクサインインの制限	Microsoft Entra ID P2が必要
高リスクユーザーの制限	ユーザーリスクの判定結果を運用に組み込む必要がある
トークン保護	対応状況や対象範囲を確認する
デバイスコードフロー制限	特定の認証フローを使う業務に影響しないか確認する
認証転送のブロック	利用シナリオによって影響確認が必要
PAW向けポリシー	専用端末や運用体制の準備が必要

特にPAW、つまりPrivileged Access Workstation向けのポリシーは、端末調達や運用プロセスの整備が必要です。ポリシーだけを先に有効化すると、管理者が通常業務を行えなくなる可能性があります。

レポート専用モードで確認すべきこと

条件付きアクセスを安全に展開するうえで、レポート専用モードは非常に重要です。公式情報では、各ポリシーを有効化する前に少なくとも1週間はレポート専用モードで確認し、サインインログやユーザーへの周知を行ってから次の段階へ進むことが推奨されています。(Microsoft Learn)

レポート専用モードでは、ポリシーを実際に強制せず、適用された場合の結果を確認できます。確認すべき観点は次の通りです。

確認項目	見るべき内容
想定外の対象者	役員、管理者、外部ユーザー、サービス用アカウントが含まれていないか
想定外のアプリ	業務継続に必要なアプリがブロック対象になっていないか
場所条件	社内IP、VPN、海外拠点、出張時のアクセスが想定通りか
デバイス条件	BYOD、共有端末、VDI、macOS、モバイルが想定通りか
クライアントアプリ	Outlook、Teams、ブラウザー、古いクライアントの挙動
他ポリシーとの重なり	別ポリシーによりMFAやブロックが二重に適用されないか

「レポート専用で問題がなさそう」という判断だけでは不十分です。対象ユーザーのサインインが実際に一定数発生しているか、休日・出張・在宅勤務など複数の利用パターンが含まれているかまで確認しましょう。

開発者・運用担当者が確認すべき移行ポイント

条件付きアクセスは、一般ユーザーだけでなく、開発者や運用担当者の作業にも影響します。特に、古い運用スクリプトや個人アカウント依存の自動化は要注意です。

ユーザー資格情報を使うスクリプトを棚卸しする

たとえば、次のような運用は影響を受けやすいです。

• PowerShellスクリプトで管理者アカウントのID・パスワードを使っている
• CI/CD処理で個人ユーザーの認証に依存している
• 夜間バッチがユーザーアカウントでMicrosoft Graphや管理APIにアクセスしている
• 古いメール送信処理がレガシー認証に依存している
• 退職者や異動者のアカウントを処理用として流用している

MFAやサインイン頻度の制御を有効化すると、これらの処理が突然失敗する可能性があります。条件付きアクセス展開前に、認証方式、利用アカウント、実行場所、対象APIを一覧化しておきましょう。

マネージドIDやアプリ認証への移行を検討する

サービスアカウントやサービスプリンシパルは、通常のユーザーとは扱いが異なります。公式情報では、スクリプトやコードで使うアカウントについて、可能であればマネージドIDへの置き換えを検討することが示されています。(Microsoft Learn)

移行時の判断基準は次の通りです。

現在の状態	推奨される見直し
個人ユーザーで自動化	専用のアプリ登録、マネージドID、適切な権限へ移行
パスワードをスクリプトに保存	シークレット管理、証明書、マネージドIDを検討
レガシー認証を利用	モダン認証対応のライブラリやAPIへ移行
管理者権限を常時利用	最小権限、PIM、承認フローを導入
処理所有者が不明	オーナー、用途、影響範囲を台帳化

開発者向けには、「条件付きアクセスのせいで動かなくなった」と考える前に、そもそも人間のサインイン前提で自動化していないかを見直すことが大切です。

ゲストユーザーと外部組織への注意点

Microsoft Entraの条件付きアクセスは、B2Bコラボレーションのゲストユーザーにも影響します。外部パートナー、委託先、グループ会社のユーザーがSharePoint、Teams、業務アプリにアクセスしている場合、条件付きアクセスの変更によって追加認証やアクセス制限が発生します。

管理者は次の点を確認しましょう。

確認項目	内容
ゲストユーザーの利用アプリ	Teams、SharePoint、業務SaaSなど
外部組織との信頼関係	相手テナントのMFAやデバイス準拠を信頼するか
ゲスト向け通知	MFA登録やアクセス手順を案内しているか
サポート窓口	自社と外部組織のどちらが問い合わせを受けるか
例外管理	一時的な除外を誰が承認し、いつ戻すか

外部ユーザーは自社のヘルプデスクで端末状態を直接確認できないことがあります。そのため、ゲスト向けポリシーは社内ユーザー向けよりも説明と例外対応を丁寧に設計する必要があります。

ブロックポリシーで失敗しやすいポイント

条件付きアクセスで最も強い制御が「ブロック」です。公式情報でも、ブロックは強力な制御であり、影響を理解したうえでテストと検証を行ってから大規模に有効化する必要があるとされています。(Microsoft Learn)

よくある失敗は次の通りです。

失敗例	起こる問題	防止策
国・地域ブロックを急に有効化	出張者、海外拠点、VPN利用者がアクセスできない	named locationsとログを事前確認
All resourcesで広範囲にブロック	管理ポータルや重要APIに影響	緊急用アカウント除外とレポート専用検証
例外を個人単位で増やす	後から管理不能になる	グループ化し、期限付きで管理
レガシー認証ブロック前に棚卸ししない	古いメールクライアントや処理が停止	サインインログで利用状況を確認
他ポリシーとの重複を見ない	想定外のMFA要求や拒否が発生	What Ifツールとサインインログで確認

国・地域ブロックを使う場合は、「拒否したい国を列挙する」よりも、「許可する国・地域を定義し、それ以外を対象にする」方が管理しやすいケースがあります。ただし、海外出張やグローバル拠点がある企業では、例外設計と連絡手段を必ず用意してください。

命名規則と台帳管理が運用を左右する

条件付きアクセスポリシーは、数が増えるほど名前の付け方が重要になります。公式情報では、ポリシー名にシーケンス番号、対象アプリ、制御内容、対象者、適用条件などを含める考え方が紹介されています。(Microsoft Learn)

実務では、次のような命名にすると管理しやすくなります。

CA01 - M365 - Require MFA - All Users - External Network
CA02 - Admin Portal - Require Phishing-resistant MFA - Privileged Roles
CA03 - Legacy Auth - Block - All Users
EM01 - ENABLE IN EMERGENCY - MFA Disruption - Exchange SharePoint

ポイントは、ポリシーを開かなくても目的が分かることです。

また、条件付きアクセスポリシーには組み込みの所有者属性がないため、別途台帳を持つと運用が安定します。

台帳項目	記録する内容
ポリシー名	実際の表示名
目的	何を防ぐためのポリシーか
所有部門	情報システム、セキュリティ、業務部門など
承認者	変更時に確認する人
対象	ユーザー、グループ、アプリ、条件
除外	緊急用アカウント、例外グループ
検証状況	レポート専用、パイロット、本番
最終レビュー日	定期見直しの日付
ロールバック方法	無効化、除外、代替ポリシーなど

この台帳がないと、退職者や異動者が作成したポリシーの意図が分からなくなり、不要な例外や重複ポリシーが残り続けます。

トラブル発生時に集めるべき情報

条件付きアクセスの問い合わせでは、「ログインできません」だけでは原因を特定できません。公式情報では、トラブルシューティング時に収集すべき情報として、ユーザープリンシパル名、表示名、OS、タイムスタンプ、対象アプリ、クライアントアプリ種別、相関IDなどが挙げられています。(Microsoft Learn)

ヘルプデスク向けには、次のテンプレートを用意しておくと初動が速くなります。

項目	ユーザーに確認する内容
ユーザー名	サインインに使ったメールアドレス
発生時刻	何時ごろ発生したか
利用端末	Windows、macOS、iPhone、Androidなど
利用場所	社内、在宅、VPN、海外など
対象アプリ	Teams、SharePoint、Outlook、業務アプリなど
利用方法	ブラウザー、デスクトップアプリ、モバイルアプリ
エラー画面	More detailsの内容、相関ID、スクリーンショット
直前の変更	端末変更、パスワード変更、MFA再登録など

管理者側では、サインインログのConditional Accessタブ、Report-onlyタブ、What Ifツールを使い、どのポリシーが適用されたかを確認します。

ロールバック手順は展開前に決めておく

条件付きアクセスの展開では、問題が起きてからロールバック方法を考えるのでは遅すぎます。公式情報では、ロールバック方法として、ポリシーの無効化、ユーザーやグループの除外、不要になったポリシーの削除などが示されています。また、削除した条件付きアクセスポリシーやnamed locationsは、30日間のソフトデリート期間内であれば復元できるとされています。(Microsoft Learn)

ただし、安易な除外はリスクを残します。例外を作る場合は、次のルールを決めておきましょう。

ルール	理由
例外には期限を設定する	恒久的な穴を作らないため
承認者を明確にする	現場判断だけで弱体化させないため
例外ユーザーを定期確認する	退職者・異動者・不要な例外を残さないため
対応後に元へ戻す	一時対応を標準運用にしないため
変更履歴を残す	監査や障害分析で説明できるようにするため

特に本番有効化直後は、問い合わせが集中します。無効化する基準、除外で対応する基準、展開を中断する基準を事前に決めておくと、現場が迷いません。

実務で使える展開チェックリスト

Microsoft Entra Conditional Accessを展開する前に、最低限次の項目を確認してください。

チェック項目	完了の目安
緊急用アカウントを用意した	通常利用しないアカウントが複数あり、監視されている
すべてのポリシーから緊急用アカウントを除外した	新規ポリシー作成時も除外が確認される
対象ユーザーとアプリを整理した	全社、部門、管理者、ゲストの分類がある
サービスアカウントを棚卸しした	スクリプトや自動化の認証方式が把握されている
MFA登録状況を確認した	対象ユーザーが必要な認証方法を登録済み
レポート専用モードで検証した	少なくとも主要な利用パターンのログを確認済み
パイロット展開を実施した	限定ユーザーで業務影響を確認済み
ユーザー向け案内を用意した	MFA手順、エラー時の連絡先、FAQがある
ヘルプデスク手順を用意した	収集情報、確認ログ、エスカレーション先が明確
ロールバック手順を決めた	無効化、除外、復元の判断基準がある
命名規則を決めた	ポリシー名から目的と対象が分かる
定期レビューを予定した	例外、重複、不要ポリシーを見直す日程がある

このチェックリストを満たさない状態で全社展開すると、認証トラブルや業務停止のリスクが高まります。

まず取るべき対応

Microsoft Entraの条件付きアクセスをこれから展開する、または既存ポリシーを見直す管理者は、最初に次の順序で進めるのが現実的です。

1. 既存の条件付きアクセスポリシーを一覧化する
2. 緊急用アカウントがすべてのポリシーから除外されているか確認する
3. レガシー認証、管理者ロール、ゲストアクセス、モバイル利用、自動化処理の影響を棚卸しする
4. 命名規則とポリシー台帳を整備する
5. 新規または変更ポリシーはレポート専用モードで検証する
6. パイロットグループで業務影響を確認する
7. ユーザー通知とヘルプデスク手順を用意してから本番展開する

条件付きアクセスは、強く設定すれば安全になるという単純な機能ではありません。重要なのは、誰のどのアクセスを、どの条件で、どの程度制御するのかを明確にし、ログで確認しながら段階的に展開することです。

今回の公式情報を踏まえると、管理者が今すぐ確認すべきなのは、新機能の有無だけではありません。既存ポリシーが増えすぎていないか、例外が放置されていないか、緊急時に復旧できるか、開発・運用スクリプトがユーザー認証に依存していないかまで含めて見直すことが、Microsoft Entra Conditional Accessを安全に運用する第一歩です。