「MFAは全員に有効化した」「条件付きアクセスも設定した」。そう答えられる組織でも、実際のサインインを1件ずつ追うと、想定していたポリシーが適用されていないアクセスが見つかることがあります。
しかも、その原因が設定ミスではなく仕様どおりの挙動だったとしたら、気づくのは相当難しい。この記事では、条件付きアクセスで実際に起きていたその挙動と、2026年6月にマイクロソフトが行った変更、そして変更に振り回されないための設計の原則を扱います。
「すべてのリソース」に除外を1つ足すと、何が起きていたか
こういうポリシーを考えてください。
- 対象ユーザー: 全員
- 対象リソース: すべてのリソース
- アクセス制御: MFAを要求
この状態なら、どのアプリへのサインインでもMFAが求められます。ここまでは直感どおりです。
ところが、業務上どうしても外せないアプリが1つ出てきて、リソースの除外に1つだけアプリを追加したとします。このとき、除外したアプリだけがポリシーの対象外になる——とは限りませんでした。
除外したアプリとまったく関係のないサインインでも、ポリシーが適用されなくなるケースがあったのです。たとえば Visual Studio Code のデスクトップクライアントや Azure CLI でのサインインが、MFAを求められずに通ってしまう。
これはバグではなく、公開されている仕様です。鍵になるのが ベースラインスコープという考え方でした。
ベースラインスコープという抜け道
アプリがサインイン時に要求する権限（スコープ）のうち、次の範囲だけを要求するアプリが対象です。
OpenID Connect のスコープ
email/offline_access/openid/profile
ベースラインのディレクトリスコープ
User.Read/User.Read.All/User.ReadBasic.AllPeople.Read/People.Read.AllGroupMember.Read.All/Member.Read.Hidden
これらは「サインインした本人や同僚の基本情報を読む」程度の、権限としては軽いものです。従来の挙動では、「すべてのリソース」を対象にしたポリシーにリソースの除外が1つでもあると、これらのスコープだけを要求するサインインはポリシー評価の対象から自動的に外れていました。
Azure CLI は User.Read しか要求しません。VS Code のデスクトップクライアントは openid と profile だけです。つまり、管理者が日常的に使う入口ほど、この抜け道を通っていたことになります。
ポリシーの画面上は「すべてのリソース・MFA必須」と表示されたままなので、設定を見ているだけでは永久に気づけません。
2026年6月、この挙動は変わった
マイクロソフトはこの挙動を変更しました。ベースラインスコープだけを要求するサインインも、ディレクトリへのアクセスとして評価され、条件付きアクセスの対象になります。
展開は 2026年6月15日に開始され、数週間かけて全テナントへ進みました。マイクロソフトは2026年7月6日のメッセージセンター（MC1418116）で、展開が完了したことを通知しています。つまり、今この記事を読んでいる時点では、原則として新しい挙動になっています。
変更後は、次のようなサインインでMFAやデバイス準拠の要求が新たに出るようになりました。
| サインインの例 | 変更前 | 変更後 |
|---|---|---|
VS Codeデスクトップクライアント（openid・profile） |
MFAを求められない | MFAを求められる |
Azure CLI（User.Read のみ） |
MFAを求められない | MFAを求められる |
ポリシーから除外した機密クライアントアプリ（User.Read・People.Read のみ） |
MFAを求められない | MFAを求められる |
逆に、ベースラインスコープ以外を1つでも要求するアプリは、もともと条件付きアクセスの対象だったので、今回の変更で挙動は変わりません。OneDrive同期クライアントのように Mail.Read などを要求するアプリが該当します。
この挙動は、実際のポリシー画面で見たほうが腹に落ちます。除外設定の挙動を13分で実演した回（無料）では、設定したつもりの範囲と実際に効く範囲がどうずれるのかを画面で追っています。
自分のテナントが影響を受けるかの判定
次の3つが全部当てはまるときだけ影響があります。
- すべてのリソースを対象にした条件付きアクセスポリシーがある
- そのポリシーにリソースの除外がある
- ベースラインスコープだけを要求するアプリでユーザーがサインインしている
除外を1つも持たないなら、この変更の影響は受けません。
挙動を選ぶこともできる
「ベースラインスコープの設定」（Microsoft Entra 管理センターの条件付きアクセス内）で、テナント単位の有効化・無効化と、ポリシー単位で従来の挙動を残す「動作のカスタマイズ」を選べます。従来の挙動を残す場合は、プレースホルダー用のアプリを登録し、そのアプリを対象のポリシーから除外したうえで、ベースラインスコープの対象として指定します。
ただし無効化は推奨されていません。テナント全体で条件付きアクセスの穴が空いたままになるためです。どうしても必要な業務シナリオがある場合に限り、ポリシー単位のカスタマイズを使います。
ここから学ぶべきこと——設計の原則
この挙動を「覚えて回避する」のは、あまり意味がありません。細かい仕様は製品の改善で変わります。実際、この記事で扱った挙動自体が変わりました。
10年20年の単位で通用するのは、次の原則のほうです。
1. 明確な評価軸を組織として先に決める
ポリシーを作る前に、ユーザーの種類（正社員・契約社員・外部ゲスト）、デバイスの種類（会社所有・BYOD）、アプリケーションの重要度といった軸を決めます。軸があれば、新しいポリシーを作るたびに「これはどの軸のためのポリシーか」を確認できます。
2. 1つのポリシーには1つの役割
「全社員向けMFA必須」「管理者向け管理デバイス必須」のように、ポリシー名だけで役割が分かる状態にします。複数の目的を1つに詰め込むと、変更したときの影響範囲が予測できなくなります。
3. 除外は最小限にして、理由を書き残す
この記事の前半が、まさに「除外が1つあるだけで挙動が変わる」実例でした。除外を増やすほど、ポリシーの実際の効果は読みにくくなります。
現場でよく見る壊れ方は決まっています。「一時的な例外」として追加した除外が消えないまま残り、数年後には「この除外は誰が何のために入れたのか」が誰にも分からなくなる。除外を追加するときは、理由と、外す条件を必ず書き残してください。
4. 緊急アクセス用アカウントを用意する
すべてのポリシーから除外した緊急アクセス用アカウント（Break Glass Account）を用意します。ポリシーの設定ミスで管理者全員が締め出される事故は、実際に起きています。
ただし、マイクロソフトはAzure・Entra ID・Intuneなどの管理ポータルへのMFAを段階的に強制しています。緊急アクセス用アカウントも例外ではないため、パスキー（FIDO2セキュリティキー）や証明書ベース認証でMFAを構成しておきます。物理キーは別々の安全な場所に保管し、定期的に動作を確認します。
5. 本番適用の前にレポート専用モードで測る
条件付きアクセスには、実際にはブロックせず「適用されたらどうなるか」だけを記録するレポート専用モードがあります。影響範囲を見てから有効化する。これは設定の良し悪し以前の、運用の作法です。
サインインログを見る習慣が、最後の砦になる
今回のような挙動は、ポリシーの設定画面をいくら眺めても見つかりません。実際のサインインが、どのポリシーの評価を受けて、どう判定されたのかを記録しているのはサインインログだけです。
条件付きアクセスは「設定して終わり」の静的な仕組みではありません。判断に使えるシグナルは増え続け、マイクロソフト管理のポリシーがテナントに自動作成されることもあります。変更に追従し続ける前提で運用する——それが、この機能と長く付き合う唯一の方法です。
参考
- Enforcement for baseline scopes in Conditional Access（Microsoft Learn）
- Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions（Microsoft Entra Blog）
本記事は2026年9月18日時点の公開情報にもとづきます。条件付きアクセスは変更の多い領域のため、設定の前に必ず最新のドキュメントを確認してください。
