条件付きアクセス ポリシーが適用されない: Microsoft Entra の問題を診断して修正する方法

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

条件付きアクセス ポリシーが適用されない問題を防ぐには、明確なビジネスシナリオ、検証済みのセキュリティとデータの境界、そして責任の所在が明確な運用体制が必要です。まず目的とする結果を定義し、代表的なユーザーでポリシーの構成と効果をテストします。そのうえで判断とサポートの手順を文書化し、要件や Microsoft 365 の機能が変わるたびにアプローチを定期的に見直してください。

Automatically translated with AI from the original post. Read the English original

条件付きアクセス ポリシーが適用されない問題を防ぐには、明確なビジネスシナリオ、検証済みのセキュリティとデータの境界、そして責任の所在が明確な運用体制が必要です。まず目的とする結果を定義し、代表的なユーザーを使ってポリシーの構成と効果をテストします。そのうえで判断とサポートの手順を文書化し、要件や Microsoft 365 の機能の変化に合わせて、アプローチを定期的に見直してください。

条件付きアクセス ポリシーが適用されない: 実践チェックリスト

• シナリオ、責任者、判断基準を定義します。
• アクセス許可、ポリシー、セキュリティ、ユーザーへの影響を検証します。
• パイロットでテストし、サポートと見直しの判断を文書化します。

最新のガイダンスについては Microsoft Learn を参照してください。

最終レビュー: 2026 年 7 月

条件付きアクセスは、Microsoft Entra (旧 Azure AD) における ID 保護の中核です。しかし、ログに「NotApplied」というステータスが表示されている場合、アクセス制御が役割を果たしていないことを意味し、組織が不適切な相手に対して無防備になっている可能性があります。この問題は、コンプライアンス監査、インシデント対応、または管理されていないユーザーの行動によって欠陥が明らかになるまで、静かに潜んでいることが少なくありません。

厄介なのは、条件付きアクセス ポリシーが適用されない理由が1つだけということがほとんどない点です。設定の見落とし、サービス プリンシパルがすり抜けているケース、あるいはポリシーの乱立によって状況が分かりにくくなっていることもあります。条件付きアクセスが機能しないと、トラブルシューティングはすぐに難しくなります。そのため、Microsoft Entra がポリシーをどのように評価し、どのような場合にスキップするのかを理解することが重要です。それにより、目に見えないギャップを修正し、ユーザーの困りごとを解消し、セキュリティ チームの不安を和らげることができます。

このガイドでは、ポリシーが適用されなかった理由を診断する明確な手順を示し、よくある落とし穴を避ける方法を解説します。そして、意図したとおりに、過不足なく機能する条件付きアクセス ポリシーを構築するための出発点となります。

Azure における条件付きアクセス評価の仕組みと、ポリシーが「NotApplied」と表示される理由

Microsoft Entra の条件付きアクセスは、ルールを適用すれば結果が得られる単純な仕組みに見えるかもしれません。しかし実際には、内部の処理はすぐに複雑になります。「NotApplied」の問題を修正する前に、誰かがサインインを試みた瞬間に Entra がすべてのポリシーをどのように処理するのかを理解しておく必要があります。管理センターで確認した内容だけで、ポリシーが適用されるかどうかが決まるわけではありません。

ポリシーが「NotApplied」とマークされている場合、Entra はそのサインインをポリシーに照らして評価したものの、ルールが現在の状況に当てはまらないと判断したことを意味します。ユーザー、デバイス、アプリ、またはサインインのコンテキストがポリシーの対象範囲と一致しなかったのかもしれません。あるいは、優先度の高い別のルールが先に適用され、必要な結果をすでに満たしていた可能性もあります。

重要なのは、評価の順序と、重複が生じた場合に Entra がどのポリシーを優先するかという点です。さらに、ポリシーの除外、サービス プリンシパルのフロー、名前付きの場所に関する特殊な挙動、そして特定の Microsoft 365 サービスに固有の動作も関係します。多くのポリシーは、時には分かりにくい理由でスキップされ、「NotApplied」というタグだけが異常を示す唯一の手掛かりになります。

これらの理由を深く掘り下げず、「NotApplied」の意味を正しく理解しないままでいると、セキュリティに穴が生じたり、正当なユーザーのサインインで問題が起きたりするおそれがあります。そこで役立つのがサインイン ログです。適用されたポリシー、スキップされたポリシー、無視されたポリシーを区別し、実際に何が起きているのかを正確に把握できます。条件付きアクセスとリスクについてさらに詳しく知りたい場合は、ポリシーの乱立とガバナンスを扱ったこちらのポッドキャスト エピソードをご覧ください。大規模な組織向けに、実績のある戦略が紹介されています。

Microsoft Entra のサインイン ログを使ってポリシー適用の欠落を特定する方法

Microsoft Entra のサインイン ログは、条件付きアクセスの謎を解明するための主要な調査ツールです。各ログ エントリには、そのサインインで評価されたポリシーの詳細が記録されており、「Applied」「NotApplied」「Failure」「Success」といった明確なステータスを確認できます。「NotApplied」は Entra がポリシーを無視したという意味ではなく、条件を満たさなかったか、別のポリシーが優先されたことを意味します。

サインインログで「条件付きアクセス」タブを確認してください。ここでは、ユーザー、デバイス、アプリケーションのコンテキストを突き合わせて、ポリシーが適用されなかった理由を特定できます。サービス プリンシパルのサインインやアプリ専用フローといった痕跡に注意してください。これらは多くの場合「NotApplied」として表示されます。条件付きアクセスは非対話型のトークンを処理しないためです。ログの読み方を理解することは、設定の抜け漏れを見つけ、設定ミスを排除するうえで欠かせません。ベースライン ポリシーと信頼に関する問題の追跡については、条件付きアクセスの信頼の欠落に関するこちらのガイドをご覧ください。

ポリシーの適用を妨げる、よくある条件付きアクセスの設定ミス

正直に言えば、条件付きアクセスは小さなミスが大きなセキュリティ上の問題につながりやすいツールです。「NotApplied」の状態になる最大の原因は、単純に設定ミスです。除外設定の誤り、緩すぎるリスクしきい値、見落とされたレガシー プロトコルなどにより、きちんと施錠したつもりでもセキュリティの扉が開いたままになることがあります。

スコープと条件の不一致は、特に場所の設定やリスクのあるサインインのロジックで頻繁に発生します。想定外の場所にいるユーザーや、古い認証方式を使用しているアプリケーションがあると、事前には分かりにくい形でポリシーの適用が崩れます。さらに、アクセス制御の仕様にも注意が必要です。「すべて必要」を「いずれか必要」と取り違えるといった誤解によって、意図したルールがすり抜けてしまうことは容易に起こります。

さらに、レガシー認証は条件付きアクセスと MFA の裏口のような存在です。多くの組織がこの抜け穴を忘れがちで、コンプライアンス監査で指摘されて初めて気付くことも少なくありません。優れた管理者は、自分の作業を二重に確認し、Microsoft 365 の拡大に伴って現れる新たな抜け穴に常に目を配っています。わずかな構成のずれが、Microsoft 自身のコンプライアンス結果にさえ影響しうることを知りたい方は、このMicrosoft 365 のコンプライアンス ドリフトに関するポッドキャストが参考になります。

条件付きアクセス ポリシーにおける場所とリスク条件の落とし穴

• 名前付きの場所の設定ミス: 名前付きの場所に誤った IP 範囲が含まれていたり、信頼できるアドレスが抜けていたり、国の指定が不完全だったりすると、一部のサインインが警告なしにポリシーをすり抜けることがあります。
• 不適切なリスク レベル: リスクのあるユーザーやリスクのあるサインインのしきい値を高く（または低く）設定しすぎると、本当のリスクが見逃されたり、誤検知によって正当なユーザーがブロックされたりする可能性があります。
• 場所の指定漏れや範囲の過剰: 必要なすべての IP 範囲やクラウド アプリを含め忘れたり、古い「信頼済み」の地域を残したままにしたりすると、適用にばらつきが生じます。
• デバイス状態の死角: デバイスのコンプライアンスやハイブリッド Azure AD 参加を考慮していないと、管理されていないエンドポイントからのサインインが対象外になります。

これらの誤りを避けるには、こちらの Azure ガバナンス ガイドで説明されているように、定期的な監査と明確なガバナンスが大きな差を生みます。

条件付きアクセスの失敗を引き起こすアクセス制御と許可ルール

1. 競合する許可制御（「すべて必要」と「いずれか必要」）: MFA、準拠デバイス、承認済みアプリなど、すべての許可制御を必須とするようにポリシーを設定すると、1 つの要件でも満たされないだけで「NotApplied」になったり、意図しない拒否が発生したりします。
2. わかりにくいブロック アクセスのロジック: ポリシー内で「許可」と「ブロック」の両方の制御を誤って有効にすると、互いに打ち消し合い、予測できない適用結果になります（ブロック条件が発動しなければ「NotApplied」になることもあります）。
3. 重複または除外されたユーザー グループ: 優先度の高いポリシーに広範なグループを含めると、より対象を絞ったポリシーを上書きしてしまいます。その結果、後者の条件が一度も評価されず、「NotApplied」と表示されることがあります。
4. クラウド アプリの誤った対象設定: 誤ったクラウド アプリにポリシーを適用したり、重要なアプリを 1 つでも漏らしたりすると、意図した制限が単に発動しなくなります。

隙間を生むレガシー認証と MFA のバイパス

• レガシー プロトコル: POP、IMAP、SMTP といった旧来のプロトコルは条件付きアクセスと MFA を回避し、Exchange Online などの従来型エンドポイントを経由して防御をすり抜けます。
• 管理されていないアプリの登録: 条件付きアクセスが適用される前に登録されたアプリ(またはクライアント資格情報フローを使用するアプリ)は、最新のポリシーチェックの対象外となり、攻撃者や気づかないユーザーが、確認なしでリソースにアクセスできてしまいます。
• サービス アカウントに対する MFA の除外: レガシー システムや共有メールボックスに対する包括的な除外設定は、中核となる保護機能を無効にし、攻撃者が狙う死角を生み出します。
• アプリ間の抜け穴: クライアント アプリ間の統合に不備があると、本来 MFA が求められるはずの場面でも MFA プロンプトが省略されてしまうことがあります。これらのゼロトラストのギャップを埋める方法の詳細については、こちらの Microsoft 365/Dynamics 365 のゼロトラストガイドをご覧ください。

Microsoft 365 アプリ、B2B、デバイス プラットフォームにおける条件付きアクセスのトラブルシューティング

条件付きアクセスの適用は、最も弱い箇所によって決まります。Microsoft 365 には独自のサービス上の特性があり、B2B のゲスト/パートナーのサインインは通常とは異なる動作をします。また、デバイスへのポリシー適用も、必ずしも想定どおりとは限りません。こうした細かな違いは、適切に設計されたポリシーであっても予期しない影響を及ぼし、「NotApplied」の痕跡を残す原因になります。

特に、パートナー プロジェクトの終了後に忘れ去られたゲスト アカウントは典型的な例です。その信頼境界とライフサイクルは社内ユーザーとは異なるため、ポリシーが適用されなかったり、適用されても影響が弱かったりすることがあります。Exchange Online や SharePoint などの Microsoft 365 サービス固有の動作も、アプリのアクセス許可からセッションのタイムアウトまで、さらなる複雑さを加えます。

また、デバイス側の要素も重要です。ユーザーのエンドポイントがどのように参加、登録、管理されているか(ハイブリッド Azure AD 参加、Intune のコンプライアンス、モバイル デバイス プラットフォームなど)によって、どのポリシーが適用され、どのポリシーがスキップされるかが決まります。環境をまたいだ条件付きアクセスの適用状況を正確に把握したい場合は、環境ごとのチェックリストを作成し、ギャップをリアルタイムで発見できるようにしておきましょう。深夜のサポート対応につながる前に問題を見つけられます。ゲスト ユーザーやTeams のガバナンスに関するガバナンス上の落とし穴については、ゲスト アカウントのリスク対策と、Teams ガバナンスの改善もあわせてご覧ください。変化し続けるリスクをより広い視点で捉えられます。

条件付きアクセスに影響する Microsoft 365 サービスの特性

条件付きアクセスに関して、すべての Microsoft 365 ワークロードが同じルールに従うわけではありません。Exchange Online、SharePoint、Teams には、それぞれ固有の API、エンドポイント、セッション管理のロジックがあります。特に従来のエンドポイントや OAuth で同意済みのアプリが関係する場合、一部のプロトコルやモバイル アプリからのアクセスは、必ずしも最新の CA 設定に従うとは限りません。

たとえば、Exchange Online PowerShell を使用する場合や、レガシー フローで SharePoint Online にアクセスする場合など、アプリが別の認証方式を使用していると、ポリシーが「NotApplied」と表示されることがあります。これは同意フィッシングやトークン窃取による攻撃経路を開く可能性があるため、ワークロードごとに的を絞った是正措置が必要です。こうしたサービス レベルの攻撃ベクトルと保護策の詳細については、Microsoft 365 の攻撃チェーンに対する是正策をご覧ください。

B2B コラボレーションとゲスト ユーザーに対する条件付きアクセス

• B2B の信頼境界: ゲスト ユーザーの所属組織には独自のセキュリティ ルールがあり、お客様の CA が必ずしもそれを上書きできるとは限りません。そのため、ポリシーが適用されるかどうかは一定しない場合があります。
• 招待とサインイン フローの違い: 条件付きアクセスが適用されるのは招待時ではなくサインイン時です。ゲストがサインインしなければ、ポリシーは実行されません。
• 監視とアラート: アラートを設定し、Entra のログを確認して、ゲストによるサインインの異常を監視しましょう。外部共有や放置されたゲスト アクセスがコンプライアンス上のリスクにつながらないようにするためです。
• レビューと有効期限: 定期的なアクセス レビューと期間を限定した招待を行うことで、環境を整理し、攻撃対象領域を減らせます。より効果的に運用するには、包括的な監査プロセスを継続的に組み立てることが重要です。その具体的な方法については、外部共有の管理に関する実践ガイドをご覧ください。

条件付きアクセスにおける Windows およびデバイスのコンプライアンスの課題

• デバイス プラットフォームの除外: Windows、iOS、Android を対象とするポリシーは、デバイスが認識されない場合やコンプライアンスの範囲外にある場合、ユーザーがまったく対象にならないことがあります。
• ハイブリッド Azure AD 結合の落とし穴: ハイブリッドかどうかに関わらず、適切に参加していないデバイスは条件付きアクセスのデバイス チェックを通過できず、ポリシーの適用がブロックされます。
• Intune 連携のギャップ: Intune ベースのコンプライアンス ポリシーは登録に時間がかかる場合があり、その間はポリシーの適用に一貫性がないように見える時期が生じることがあります。
• 非準拠または未検証のデバイス: 脱獄済み、古い、または管理されていないデバイスからのサインインは、通常はデバイスを条件とするポリシーを発動しません。コンプライアンスと脅威保護の統合に関する詳しい情報は、こちらの Microsoft 365 Defender と Purview の概要をご覧ください。

条件付きアクセスが予測不能になる原因となるポリシーの乱立と重複への対処

大規模な環境では、条件付きアクセス ポリシーが際限なく増えがちです。完璧な保護を求めるあまり、重複や競合するルールが大量に生まれ、どのポリシーが適用されるのかを誰も予測できなくなることがあります。ポリシーが多すぎると複雑さが増し、見落としの範囲が生まれ、トラブルシューティングも困難になります。

ポリシーの乱立とは、善意の管理者が「もう一つだけ」とポリシーを積み重ねていく状態を指し、特にグループへの含めや例外に頼っている場合や、テスト用のポリシーの削除を忘れた場合に、見えない適用の死角を生み出します。さらに、サービスの依存関係が状況を悪化させます。あるクラウド アプリへの変更や新しい統合が、以前は確実に機能していたポリシーの連鎖を崩すことがあるのです。

賢明な対策は、定期的なポリシーの監査と整理です。基本となる包括的なポリシーに焦点を当て、期限付きの例外は最小限に抑えましょう。すべてのポリシーには明確な目的と文書化された結果があり、実用的なレポートと組み合わされていることを確認してください。また、環境を「設定したら放置」と決め込まないことも重要です。条件付きアクセスにおける信頼のギャップの監視やシャドー IT への対処については、こちらの CA の信頼問題に関するプレイブックとシャドー IT の是正に関するガイドをご覧ください。

サービスの依存関係を管理し、ポリシーの乱立を防ぐ

• 現在のポリシーの監査: 有効なすべての CA ポリシーを定期的に棚卸しして文書化し、不要な重複や古くなったルールがないか確認します。
• 相互接続されたサービスのマッピング: Azure、Microsoft 365、サードパーティ製アプリにまたがる CA の依存関係を特定し、新しい統合によって生じる適用のギャップを見つけます。
• 統合と整理: 類似のポリシーをまとめ、古いものや未使用のものは廃止します。広範で十分に文書化されたルールを基本とし、対象を絞った例外を設けるようにします。
• AI/自動化のリスクを確認する: バックグラウンドのプロセスを忘れないでください。AI エージェントや自動化には、シャドー IT のリスクを防ぐために独自の範囲指定された制御が必要です。詳しくはAI エージェントによるシャドー IT の脅威をご覧ください。

「すべての結果を選択」と レポートを使って、ポリシーの影響を安全にテストする

1. まずレポート専用モードを有効にする: 展開する前に、正当なユーザーをブロックすることなくポリシーの影響をシミュレートするため、レポート専用モードを使用します。組み込みのレポート ダッシュボードを使って影響を分析します。
2. 「すべての結果を選択」は慎重に使用する: 予期しない結果や計画外の除外を完全展開の前に発見するため、安全なテスト環境ですべての適用アクションを試してください。
3. 影響を受けるユーザーとアプリを文書化する: 変更によって影響を受けるすべてのユーザー、グループ、アプリの記録を残し、関係者と連携できるようにするとともに、問題が起きた場合に方針を修正できるようにします。
4. ユーザーとシステムからのフィードバックを集める: ユーザーには問題をすぐに報告するよう促し、ポリシーによるロックアウトがないかシステムのエラー ログを確認します。
5. インシデント対応では監査ログを活用する: Microsoft Purview 監査とテナントのログを使用して、ユーザーのアクティビティを追跡し、ポリシーの結果を検証します。監査のガイダンスについては、このPurview 監査の詳しい解説をご覧ください。

ロックアウトされた場合や、条件付きアクセス ポリシーが適用されない場合の対処法

すべての条件付きアクセス管理者が一度は悪夢を見たことがあるはずです。新しいポリシーを展開した途端、自分やチーム全体がテナントから締め出されたり、効果があると思っていたポリシーがまったく機能しなかったりします。エスカレーションの電話が次々にかかってきて、事業を止めないためにはしっかりとした復旧戦略が必要だと気づくことになります。

良いニュースがあります。再構築を損なうことなく、すばやくアクセスを取り戻すための手順があります。緊急時に備えて「ブレークグラス」アカウントを用意し、ロールバックや除外の手法を準備しておき、必要に応じてMicrosoftサポートやセキュリティチームにエスカレーションしてください。

ただし、復旧だけで終わらせてはいけません。根本原因に対処しなければ、次にポリシーを調整したときに同じ問題が再び起こります。そのため、サービスを復旧させるスイッチを切り替えることと同じくらい、事後レビュー、関係者への報告、継続的なテスト、そして学んだ内容の文書化が重要です。管理ツールの所有権が分散するとガバナンスが機能しなくなる理由については、こちらのガバナンスの失敗に関する詳細解説をご覧ください。

条件付きアクセスが機能しないときの段階的な復旧手順

1. ブレークグラスアカウントを使用する: 条件付きアクセスポリシーが適用されていない、グローバル管理者権限を持つ緊急用アカウントを少なくとも1つ用意してください。このアカウントでサインインすれば、いつでもアクセスを回復できます。
2. 一時的な除外ポリシーを適用する:締め出されている場合は、影響を受けているアカウントまたはグループに対して除外ポリシーを作成するか有効化してください。これにより通常のアクセスを回復し、根本的な問題を修正できます。
3. 管理者による例外承認をエスカレーションする: 一次対応の手順で解決しない場合は、Microsoftサポートまたはセキュリティチームに連絡し、直接の対応やテナントのロック解除を依頼してください。
4. 最近のポリシー変更をロールバックする: 新しく作成した、または最近変更した条件付きアクセスルールを、最後に正常に動作していた構成に戻し、サインインログで修正が有効になったことを確認してください。

適用されていない問題を特定した後の次のステップと、ポリシーの有効性レビュー

• 学んだ教訓を文書化する: 何が問題だったのか、どの対策が修正に有効だったのか、今後どこに制御や監査が必要かを正確に記録してください。
• レポートのみモードでテストする: ポリシーを再度有効にする前に、Entraのレポートのみモードを使用して、新たな障害を引き起こすことなく問題を検出できることを確認してください。
• フィードバックを収集して反映する: 影響を受けたユーザーやシステムログからフィードバックを求め、その知見を使って残りのギャップを埋めてください。
• 関係者に報告する: 影響を受けるすべてのチーム、IT管理部門、外部パートナー、ユーザーに対して、インシデント、解決策、長期的な再発防止計画を共有してください。
• 定期的なガバナンスを継続する: 条件付きアクセスポリシーの定期的なレビュー、レポート作成、更新をスケジュールに組み込んでください。ガバナンスの幻想に関するポッドキャストが指摘するとおり、ガバナンスは一度設定して終わりのチェックボックス作業ではなく、継続的な取り組みだからです。

🎧 あわせて聴きたいエピソード

• Microsoft Entra の ID ガバナンス

  アクセスとライフサイクルの制御を学べます。

• Microsoft Purview – わかりやすい解説

  保護とコンプライアンスの全体像を解説します。

• Microsoft 365 ガバナンス運用モデル

  持続可能な所有権と意思決定について理解を深められます。