結論から言うと、2026年4月16日時点で Microsoft Entra Conditional Access を運用している組織は、「All resources を対象にしつつ、一部リソースを除外しているポリシー」を優先的に見直すべきです。Microsoft は、Baseline scopes のみを要求するサインインにも Conditional Access の保護を適用する改善を進めており、これまで MFA や準拠デバイス要求を受けなかったアプリで、突然チャレンジが発生する可能性があります。(Microsoft Learn)
この変更は単なる仕様差分ではありません。Identity 管理者にとっては「なぜ急に MFA が出るのか」「除外したはずのアプリがブロックされるのはなぜか」という問い合わせ対応に直結し、ゼロトラスト設計者にとっては、例外をどこまで許容するかを再設計するタイミングになります。
この記事では、Microsoft Entra Conditional Access の適用強化が何を意味するのか、影響を受ける条件、例外設計の見直し方、そしてトラブル発生時の確認手順まで、管理者がすぐ動ける形で整理します。
Microsoft Entra Conditional Access の適用強化で何が変わるのか
今回のポイントは、All resources ポリシーにリソース除外がある場合の適用ロジックです。
Microsoft Entra Conditional Access では、ポリシーの対象リソースとして All resources、個別アプリ、Microsoft 365、Windows Azure Service Management API などを指定できます。All resources は広範囲を保護できる一方、業務上の理由で一部アプリを除外しているテナントも少なくありません。(Microsoft Learn)
従来は、All resources ポリシーにリソース除外がある場合、openid、profile、User.Read などの一部の低権限スコープが自動的に Conditional Access の適用対象外になるケースがありました。変更後は、これらのスコープがディレクトリアクセスとして評価され、Windows Azure Active Directory、つまり Microsoft Entra ID ディレクトリへのアクセスとして Conditional Access の判定対象になります。(Microsoft Learn)
| 観点 | 従来の挙動 | 変更後の挙動 | 管理上の意味 |
|---|---|---|---|
| All resources ポリシーに除外がない | All resources として適用 | 大きな変更なし | 基本方針として維持しやすい |
| All resources ポリシーにリソース除外がある | 一部の低権限スコープが自動的に適用対象外になることがあった | Baseline scopes もディレクトリアクセスとして評価される | 以前は通っていたサインインで MFA やデバイス準拠要求が出る可能性がある |
アプリが Mail.Read や Files.Read など追加スコープを要求する | 対象リソースに応じて Conditional Access が評価される | 挙動は基本的に変わらない | 影響調査では「Baseline scopes のみ」のアプリを優先する |
重要なのは、「除外したアプリだから常に対象外」とは考えられないことです。Conditional Access はクライアントアプリそのものではなく、要求されるリソースやスコープを見て評価されます。Microsoft Learn でも、Conditional Access は基本的にクライアントではなくリソースに適用されると説明されています。(Microsoft Learn)
Baseline scopes とは何か
今回の変更で注目すべき Baseline scopes は、ユーザーの基本情報やディレクトリ情報を取得するためによく使われるスコープです。Microsoft は、OIDC スコープとベースラインのディレクトリスコープを Baseline scopes として整理しています。(Microsoft Learn)
| 分類 | 主なスコープ | 使われやすい場面 |
|---|---|---|
| OIDC スコープ | openid、profile、email、offline_access | サインイン、ID トークン取得、基本プロフィール表示 |
| ディレクトリ系スコープ | User.Read、User.Read.All、User.ReadBasic.All | ユーザー情報の取得、アカウント表示 |
| 人・グループ関連スコープ | People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden | 組織内ユーザー検索、グループメンバー確認、連絡先候補表示 |
たとえば、Azure CLI が User.Read のみを要求する、Visual Studio Code デスクトップクライアントが openid と profile を要求する、といったサインインでは、変更後に MFA などの Conditional Access チャレンジが発生する可能性があります。Microsoft の例でも、こうしたクライアントが変更後に MFA を求められるケースが示されています。(Microsoft Learn)
影響を受けるテナントの条件
すべての Microsoft Entra Conditional Access 環境が同じ影響を受けるわけではありません。Microsoft は、次の条件をすべて満たす場合に影響を受けると説明しています。(Microsoft Learn)
| 確認項目 | 該当する場合の見方 |
|---|---|
| All resources を対象にした Conditional Access ポリシーがある | まず対象ポリシーとして棚卸しする |
| そのポリシーに 1 つ以上のリソース除外がある | 影響調査の最優先対象にする |
| ユーザーが Baseline scopes のみを要求するアプリでサインインしている | MFA、準拠デバイス、アプリ保護ポリシーなどの追加要求が発生する可能性がある |
逆に、All resources ポリシーにリソース除外がない場合、この変更の直接的な影響は受けにくいとされています。また、アプリが Baseline scopes 以外のスコープ、たとえば Mail.Read などを要求している場合は、すでに該当リソースに対して Conditional Access が評価されているため、今回の変更による挙動差は基本的にありません。(Microsoft Learn)
なぜ管理者のトラブルシューティング需要が急増するのか
この変更で厄介なのは、ユーザーから見ると「昨日まで使えていたアプリで急に MFA が出る」「除外していたはずのアプリでブロックされた」と見える点です。
実際には、Conditional Access がより一貫して評価されるようになる変更ですが、運用現場では次のような問い合わせになりがちです。
| ユーザーやアプリ担当者の訴え | 管理者が見るべき観点 |
|---|---|
| Azure CLI で急に MFA が必要になった | 要求スコープが User.Read のみか、All resources ポリシーの除外が関係しているか |
| VS Code のサインインで追加認証が出る | OIDC スコープのみの要求が Windows Azure Active Directory として評価されていないか |
| 除外した業務アプリなのに Conditional Access が効いている | 除外対象はアプリ本体か、ディレクトリスコープか、依存リソースか |
| サイレント認証が失敗する | アプリが Conditional Access チャレンジを処理できる実装になっているか |
Microsoft の開発者向けガイダンスでは、アプリが Conditional Access チャレンジを受けた場合、interaction_required や claims チャレンジを処理し、必要に応じて対話的なトークン取得へ切り替える必要があると説明されています。サイレント認証だけを前提にしたアプリでは、今回の変更をきっかけにエラーが表面化する可能性があります。(Microsoft Learn)
まず確認すべき Conditional Access ポリシー
最初に見るべきなのは、すべてのポリシーではありません。優先順位を付けるなら、次の順番が実務的です。
| 優先度 | 確認対象 | 理由 |
|---|---|---|
| 高 | All resources を対象にし、リソース除外があるポリシー | 今回の変更の中心 |
| 高 | MFA、準拠デバイス、アプリ保護ポリシー、ブロックを含むポリシー | ユーザー影響が大きい |
| 中 | 開発者ツール、CLI、管理ツールに関係するサインイン | Baseline scopes のみを要求するケースがあり、問い合わせが発生しやすい |
| 中 | 除外対象の業務アプリや ISV アプリ | アプリが Conditional Access チャレンジを処理できない場合がある |
| 低 | All resources に除外がない標準 MFA ポリシー | 今回の変更による直接影響は小さい |
Microsoft は、全ユーザー・全リソースを対象にした MFA ベースラインポリシーを推奨しており、MFA ポリシー作成時にはアプリ除外なしの構成例も提示しています。ただし、緊急アクセス用の break-glass アカウントなど、ロックアウト防止のために除外すべきアカウントもあります。(Microsoft Learn)
つまり、理想は「All resources を保護しつつ、例外を最小化する」ことです。例外をゼロにできない場合でも、除外理由、所有者、有効期限、代替コントロールを明文化する必要があります。
影響調査の進め方
Microsoft は、影響を受けるアプリケーションの確認方法として、PowerShell、Usage and Insights、サインインログを挙げています。また、Baseline scope settings を使って変更後の挙動をプレビューし、サインインログで影響を確認できると説明しています。(Microsoft Learn)
実務では、次の流れで進めると混乱を抑えられます。
| 手順 | 作業内容 | 判断ポイント |
|---|---|---|
| 1 | All resources かつリソース除外ありのポリシーを抽出する | 影響範囲の起点を決める |
| 2 | 除外されているリソースを一覧化する | 「誰が、なぜ、いつまで」除外したか確認する |
| 3 | Baseline scopes のみを要求するアプリを洗い出す | VS Code、Azure CLI、独自アプリ、ISV アプリを重点確認する |
| 4 | サインインログで Conditional Access の適用結果を確認する | Resource、Audience、Policy result を見る |
| 5 | 例外を維持、縮小、廃止、アプリ修正のどれにするか決める | セキュリティリスクと業務影響を比較する |
| 6 | ヘルプデスク向けの説明文を用意する | 「なぜ MFA が出るようになったか」を短く説明できる状態にする |
ここで重要なのは、いきなり本番ポリシーを緩めないことです。ユーザー影響が出ると、現場では「とりあえず除外しよう」という判断になりがちですが、それではゼロトラストの前提が崩れます。まずはサインインログで、どのアプリがどのリソースを要求し、どの Conditional Access ポリシーに該当したのかを確認します。
例外設計は「アプリ単位」から「リスク単位」へ見直す
今回の変更後、例外設計で避けたいのは、アプリ名だけを見て広く除外する運用です。
Conditional Access は、ユーザー、グループ、デバイス状態、場所、クライアントアプリ、対象リソース、リスク、認証強度などを組み合わせて判断します。アプリを丸ごと除外すると、本来保護すべきディレクトリ情報や依存リソースへのアクセスまで緩くなる可能性があります。
例外を設計する場合は、次の観点で判断します。
| 判断軸 | 確認すること | 望ましい対応 |
|---|---|---|
| 業務必要性 | その例外がないと業務が止まるか | 代替手段があるなら例外を廃止する |
| 影響範囲 | 全社か、特定部門か、特定アプリか | 対象ユーザーやグループを最小化する |
| 期間 | 恒久的な例外か、一時的な移行措置か | 期限を設定し、定期レビューする |
| 代替コントロール | MFA 以外に準拠デバイス、場所制限、認証強度を使えるか | 例外ではなく別条件で保護する |
| アプリ実装 | Conditional Access チャレンジを処理できるか | 開発元または ISV に修正可否を確認する |
| 監査性 | 誰が承認し、いつ見直すか | 変更履歴と承認記録を残す |
特に ISV アプリや社内開発アプリでは、基本的なユーザー情報を取るだけの目的で User.Read や People.Read を使っている場合があります。Microsoft は、テナント所有または ISV 所有の Confidential client が Baseline directory scopes のみを要求している場合、OIDC スコープで足りるかを評価することを推奨しています。(Microsoft Learn)
レガシー挙動を維持すべきケースと避けるべきケース
Microsoft は、新しい適用モデルに合わせることを推奨しつつ、特定の理由がある場合には Baseline scope settings によってレガシー挙動を維持する方法も案内しています。ただし、これはテナントレベルの設定であり、安易に使うべきではありません。(Microsoft Learn)
| シナリオ | 推奨判断 | 注意点 |
|---|---|---|
| アプリが準拠デバイス要求に対応できず、業務上どうしても非管理デバイスから利用が必要 | 一時的な例外として検討 | 対象ユーザー、期間、監視条件を限定する |
| Intune SDK 非対応のクライアントでアプリ保護ポリシーを満たせない | アプリ更新または代替クライアントを優先 | 例外の恒久化を避ける |
| ブロックポリシーから特定クライアントを除外する必要がある | セキュリティ承認を前提に限定運用 | ブロック回避の抜け道になりやすい |
| 開発者向け CLI やツールで MFA が頻発する | 認証方法、デバイス準拠、開発者グループの設計を見直す | 全開発者ツールを丸ごと除外しない |
| アプリが Conditional Access チャレンジを処理できない | アプリ修正を原則とする | 一時除外する場合は期限を必ず設定する |
レガシー挙動の維持は、障害回避策としては有効な場面があります。しかし、ゼロトラスト設計の観点では、例外を増やすほど「すべてのアクセスを検証する」という原則から離れます。短期的には業務継続を優先しても、中期的にはアプリ修正やポリシー分割で例外を減らす計画が必要です。
トラブル発生時の確認手順
ユーザーから「急にサインインできない」「MFA が出るようになった」と連絡が来た場合は、ポリシーを変更する前にサインインログを確認します。Microsoft は、Conditional Access 関連の予期しないサインイン結果を調べる際、エラーメッセージと Microsoft Entra のサインインログを確認するよう案内しています。(Microsoft Learn)
| 手順 | 確認内容 |
|---|---|
| 1 | ユーザー名、発生時刻、アプリ名、端末、ネットワーク環境を確認する |
| 2 | Microsoft Entra 管理センターで Sign-in logs を開く |
| 3 | ユーザー、日時、Conditional Access、Resource で絞り込む |
| 4 | 該当イベントの Conditional Access タブを確認する |
| 5 | 適用されたポリシー名、成功・失敗、要求されたリソースを確認する |
| 6 | Audience reporting で、ユーザーが実際に要求した複数リソースを確認する |
| 7 | 必要に応じて What If tool や Sign-in diagnostic を使う |
サインインログでは、ユーザーが意識しているアプリ名だけでなく、実際に要求されたリソースを見ることが重要です。たとえば、Microsoft Teams へのサインインでも、裏側では Teams、Outlook、SharePoint など複数リソースにアクセスする場合があります。Microsoft Learn では、このような依存関係の確認に Audience reporting を使えると説明されています。(Microsoft Learn)
代表的な Conditional Access 関連のエラーコードも押さえておくと、ヘルプデスクとの連携が速くなります。(Microsoft Learn)
| エラーコード | 意味 | 初動対応 |
|---|---|---|
| AADSTS53000 | DeviceNotCompliant | デバイス準拠状態、Intune 登録、対象プラットフォームを確認 |
| AADSTS53001 | DeviceNotDomainJoined | ハイブリッド参加、Microsoft Entra 参加状態を確認 |
| AADSTS53002 | ApplicationUsedIsNotAnApprovedApp | 承認済みクライアントアプリの条件を確認 |
| AADSTS53003 | BlockedByConditionalAccess | ブロックポリシー、対象ユーザー、対象リソースを確認 |
| AADSTS53009 | Intune 保護ポリシーの適用が必要 | アプリ保護ポリシー対応状況を確認 |
ポリシー設計で避けたい失敗
今回の変更を受けて、Identity 管理者やゼロトラスト設計者が避けるべき失敗は明確です。
All resources に広すぎるブロック条件を入れる
All resources、All users、Block access のような組み合わせは、設定を誤ると組織全体のアクセスを止める危険があります。Microsoft のトラブルシューティング文書でも、すべてのユーザー・すべてのリソースを対象にしたブロックや、準拠デバイス要求などは慎重に扱うべき構成として説明されています。(Microsoft Learn)
アプリ除外を恒久的な逃げ道にする
例外は、障害対応や移行期間には必要です。しかし、例外リストが増え続けると、どこまで保護されているのか管理者自身も把握できなくなります。
例外を作る場合は、最低限、次の情報を記録します。
| 記録項目 | 例 |
|---|---|
| 例外対象 | アプリ名、アプリ ID、対象ユーザーグループ |
| 理由 | アプリが Conditional Access チャレンジを処理できない |
| 承認者 | セキュリティ責任者、業務オーナー |
| 期限 | 2026年6月末まで |
| 代替対策 | 特定国からのアクセス制限、監査ログ監視、利用者限定 |
| 見直し条件 | アプリ更新完了、ISV 対応完了、代替手段導入 |
Microsoft 365 の依存関係を見落とす
Microsoft 365 系サービスは互いに依存しています。Exchange、SharePoint、Teams を個別に扱うと、ユーザー体験とポリシー適用結果が一致しないことがあります。Microsoft Learn でも、Microsoft 365 サービスの依存関係による問題を避けるため、Microsoft 365 アプリグループを使う考え方が示されています。(Microsoft Learn)
開発者ツールを特別扱いしすぎる
Azure CLI、Visual Studio Code、PowerShell などは、管理者や開発者にとって不可欠です。しかし、「開発者が困るから除外」ではなく、フィッシング耐性の高い認証、準拠デバイス、Privileged Identity Management、管理者ロールの分離などと組み合わせて設計すべきです。
開発者ツールは権限の強い操作につながりやすいため、一般ユーザー向けアプリよりも例外を厳しく扱うほうが安全です。
これからの推奨設計
今回の Conditional Access の適用強化を前提にすると、推奨される設計は次のようになります。
| 設計領域 | 推奨方針 |
|---|---|
| ベースライン保護 | All resources を対象にした MFA または認証強度要求を基本にする |
| 例外 | アプリ単位で広く除外せず、ユーザー、期間、条件を限定する |
| 高リスク操作 | 管理ポータル、PIM、重要 SaaS にはより強い認証を要求する |
| 開発者・管理者ツール | 除外ではなく、準拠デバイスや認証強度で制御する |
| 独自アプリ | Conditional Access チャレンジを処理できるよう実装を確認する |
| ISV アプリ | OIDC スコープ利用可否、CA 対応状況、ロードマップを確認する |
| 監視 | Sign-in logs、Audience reporting、Usage and Insights を定期確認する |
最も実践しやすい進め方は、まず「All resources + 除外あり」のポリシーを棚卸しし、次に Baseline scopes のみを要求するアプリを洗い出すことです。そのうえで、例外を残すもの、縮小するもの、アプリ修正で解消するものに分類します。
管理者が今すぐ取るべきアクション
Microsoft Entra Conditional Access の今回の変更は、セキュリティを強化する方向の更新です。一方で、既存運用に例外が多いテナントほど、ユーザー影響や問い合わせが出やすくなります。
まず実施すべきことは、次の 3 つです。
| アクション | 目的 |
|---|---|
| All resources かつリソース除外ありのポリシーを棚卸しする | 影響を受ける可能性のある設計を特定する |
| Baseline scopes のみを要求するアプリを確認する | 急な MFA、準拠デバイス要求、サイレント認証失敗を予測する |
| 例外ごとに所有者、期限、代替対策を決める | 例外をセキュリティ上の負債として放置しない |
この変更を「トラブル対応の火消し」で終わらせるのはもったいないです。むしろ、例外が増えすぎた Conditional Access 設計を整理し、ゼロトラストの原則に近づける好機です。まずはポリシー棚卸しとサインインログ確認から始め、必要な例外だけを短期的に残しながら、最終的にはアプリ修正とポリシー分割で安全な構成へ寄せていきましょう。
コメント