「このアプリケーションは対象外にしているから、条件付きアクセスの制約を受けない」。多くの企業のID基盤担当者が、そう考えてポリシー設計をしてきたはずだ。しかし2026年6月15日から段階的に始まった変更で、この前提の一部が崩れる。Microsoft Entra ID（旧Azure AD）の条件付きアクセスにおいて、リソース除外を設定していても一部のサインインでは強制適用されるようになったからだ。さらに同じ時期にCustom Controls（サードパーティ多要素認証と連携するための拡張機能）の廃止も進んでおり、数千人規模のテナントでカスタム認証を組み込んでいる企業ほど、設定の総点検が必要になる。
予備知識
- 条件付きアクセス（Conditional Access）: サインイン時の条件（場所・デバイス・アプリケーションなど）に応じて、多要素認証の要求やアクセス拒否を自動適用するEntra IDの仕組み。
- リソース除外: 特定のアプリケーションやサービスを条件付きアクセスポリシーの適用対象から外す設定。
- OIDCスコープ: OpenID Connectでアプリケーションが要求する権限範囲。openid・profile・email・offline_accessなど、ごく限られた情報のみを求める軽量なスコープを指すことが多い。
- Custom Controls: サードパーティの多要素認証プロバイダーと条件付きアクセスを連携させるための拡張機能。External MFA（外部MFA）という標準ベースの仕組みに置き換えられる。
第9章で条件付きアクセスを扱っており、デバイス管理と組み合わせた設計を実務目線で学べる一冊。
何が変わったのか：除外設定があっても強制適用される場面が生まれた
Microsoft Learnによれば、ベースラインスコープの強制適用は2026年6月15日から段階的に展開されている[3]。Microsoftは「すべてのリソース」を対象とする条件付きアクセスポリシーについて、リソース除外の扱いを変更する展開を段階的に始めた[1]。これまでは、クライアントアプリケーションがOIDCの基本スコープや限定的なディレクトリスコープ（openid・profile・email・offline_access・User.Readなど）のみを要求してサインインする場合、ポリシーにリソース除外が1つでも設定されていれば、そのサインインには条件付きアクセスが適用されなかった。変更後は、こうした限定スコープのみのサインインであっても、除外設定の有無にかかわらず「すべてのリソース」ポリシーが適用されるようになる[2][3]。
これと並行して、Custom Controlsの廃止も進む。Microsoftは2026年9月以降、Custom Controlsの新規作成と既存設定の変更を停止し、2027年5月には完全に廃止する予定だ[4]。サードパーティの多要素認証プロバイダーと条件付きアクセスを連携させてきた企業は、標準ベースのExternal MFAへ移行する必要がある[5]。
今回の変更の背景にあるOAuth/OIDCのスコープと認可の考え方を、実装レベルから理解し直したい担当者向け。
なぜ「除外設定」への依存が危ういのか
多くの企業は、社内システムやレガシーアプリケーションへの影響を避けるため、条件付きアクセスポリシーに複数の除外設定を積み重ねてきた。特に「すべてのリソース」を対象とする包括的なポリシーを組んでいる場合、除外リストが唯一の安全弁になっているケースは少なくない。しかし今回の変更は、限定スコープのみを要求するサインインという特定の条件下では、その安全弁が機能しなくなることを意味する。
影響を受けるのは主に、OIDCの基本スコープだけを要求するカスタムアプリケーションや、簡易的なサインイン連携を組んでいるシステムだ。除外設定を根拠に「このアプリは対象外」と運用してきた担当者にとっては、突然MFAやデバイス準拠のチャレンジが発生するようになり、ユーザーからの問い合わせが増える可能性がある。
| 変更点 | 従来の挙動 | 2026年6月15日以降の挙動 |
|---|---|---|
| リソース除外の効力 | 限定スコープのサインインには適用免除 | 除外があっても一部シナリオで強制適用 |
| 影響対象 | 全リソース対象ポリシーを持つ全企業 | OIDC基本スコープのみ要求するアプリ利用企業 |
| ロールアウト方式 | – | 数週間かけて段階的に展開 |
Microsoft Entra ID P2を全社員に配布し、Entra ID Protection側のリスクポリシーで高リスクのサインインに多要素認証やパスワード変更を要求している。そんな数千人規模の企業でID基盤を預かる情報システム部門[…]
Custom Controls利用企業が直面する移行作業
Custom Controlsは、Duoなどサードパーティの多要素認証製品と条件付きアクセスを連携させるために広く使われてきた機能だ。廃止後はExternal MFAという標準ベースの仕組みへ移行する必要があり、MC1422061は推奨アクションを5項目挙げている[4]。先頭の3つは次のとおりで、残る2つは「認証フローの検証と移行完了の確認」「Custom Controls参照の全削除」だ。第一に、Custom Controlsを使用している条件付きアクセスポリシーを洗い出す。第二に、サードパーティの多要素認証プロバイダーを外部認証方式として構成する。第三に、該当ポリシーの許可コントロールを標準の「多要素認証を要求する」に置き換える。
Custom Controlsを使っていない企業には影響がないが、サードパーティMFA製品を条件付きアクセス経由で利用している企業は、2026年9月の新規作成・変更停止という節目までに移行を完了させる必要がある。
数千人規模でEntra ID（旧Azure AD）とオンプレADを併用し、年次の内部監査があるような日本企業のID基盤担当者は、SMSや音声通話によるMFA（多要素認証）を、まだ主要な認証手段として使い続けている場合が多い。Microso[…]
日本企業の条件付きアクセス設計は「除外リストの積み上げ」になっていないか
日本企業の条件付きアクセス運用は、既存システムとの互換性を優先し、例外対応として除外設定を積み重ねる形で発展してきたケースが多い。新規導入時に厳格なポリシーを設計しても、レガシーシステムや取引先システムとの連携で不具合が出るたびに除外を追加し、結果として「なぜこの除外があるのか」を説明できる担当者が異動でいなくなっている、という状態は珍しくない。今回の変更は、こうした除外リストの中身を棚卸しする良い契機になる。
海外企業では、条件付きアクセスポリシーの変更管理をIDガバナンス基盤やチケット管理システムと連動させ、除外設定の追加理由を記録として残す運用が比較的定着している。日本企業では、除外設定がExcelの手順書や担当者の記憶に依存していることが多く、監査時に理由を再現できないリスクがある。
| 観点 | 海外企業で進みやすいこと | 日本企業で起きやすいこと |
|---|---|---|
| 除外設定の記録 | チケット管理システムに追加理由を記録 | 手順書や担当者の記憶に依存 |
| 定期見直し | 半期ごとに除外リストを棚卸し | 監査直前にまとめて確認 |
| Custom Controls利用状況 | セキュリティ部門が一元把握 | 導入時の担当者以外は把握していないことも |
ID基盤担当者の次の一手は、「すべてのリソース」を対象とするポリシーの除外リストを棚卸しし、それぞれの除外理由を記録に残すことだ。決裁側にとっての判断材料は、Custom Controls利用有無を確認したうえで、移行作業が必要な場合の対応工数をいつ予算化するかという計画立案になる。
まとめ
条件付きアクセスの除外設定は、もはや「設定しておけば安全」という万能の安全弁ではなくなった。ただし逃げ道が塞がれたわけではない。告知とLearnはどちらも、ベースラインスコープの設定でこの変更をオプトアウトするか、ポリシー単位で強制の挙動をカスタマイズして従来動作を保持できると明示している[1][3]。まず影響範囲を調べ、必要ならカスタマイズで一時退避してから移行するのが現実的な順序だ。限定スコープのみを要求するサインインでは、除外があっても強制適用される場面が生まれている。同時にCustom Controlsの廃止も進み、サードパーティMFA連携を組んでいる企業には移行作業が発生する。IT部門担当者の次の一手は既存ポリシーの除外リスト棚卸しとCustom Controls利用状況の確認、決裁側の判断材料は移行工数の予算化タイミングだ。「除外しているから安心」という前提を、今一度見直したい。
よくある質問（FAQ）
Q. 自社の条件付きアクセスポリシーが影響を受けるか、どう確認すればよいか？
A. サインインログの conditionalAccessAudiences を見るのが確実だ。Microsoft GraphならauditLogs/signIns を conditionalAccessAudiences で絞り込んで、基本スコープのみを要求しているアプリケーションを特定できる[3]。そのうえでEntra管理センターで「すべてのリソース」を対象とし、かつリソース除外を設定しているポリシーを一覧化する。
Q. Custom Controlsを使っているかどうかはどこで確認できるか？
A. Entra管理センターの条件付きアクセスポリシー一覧で、許可コントロールに「カスタム制御」が設定されているポリシーを検索すれば特定できる。
Q. 移行を後回しにするとどうなるか？
A. 2026年9月以降はCustom Controlsの新規作成・変更ができなくなり、2027年5月には完全に機能しなくなる。サードパーティMFA連携が突然使えなくなる前に、計画的な移行が必要だ。
出典
[1] https://mc.merill.net/message/MC1400649[2] https://blog.admindroid.com/conditional-access-change-for-improved-enforcement-of-policies-with-resource-exclusions/
[3] https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-enforcement-resource-exclusions
[4] https://mc.merill.net/message/MC1422061
[5] https://learn.microsoft.com/en-us/entra/identity/conditional-access/how-to-migrate-custom-controls-external-mfa
