結論は、除外をゼロにすることではなく、緊急用アカウントと一時的な業務例外を区分し、すべての除外に責任者、期限、代替コントロール、見直し記録を持たせることです。
なぜ除外が増え続けるのか
条件付きアクセスは、ユーザー、場所、デバイス、リスク、対象リソースなどの条件と、MFAや準拠デバイス要求などの制御を組み合わせます。影響範囲を確認せず一括適用すると業務停止につながるため、障害対応のたびに除外が追加されがちです。
問題は除外そのものではありません。ポリシー間の依存関係、除外理由、終了条件が分からない状態です。後任者は削除判断ができず、対象外の利用者だけが古い認証条件のまま残ります。
公式情報で確認できること
Microsoftは、条件付きアクセスポリシーを段階的に展開し、テンプレートで作成したポリシーを既定でReport-onlyとして、利用状況をテスト・監視してから有効化する方法を示しています。また、誤設定によるロックアウトを避けるため、緊急用アカウントをブロック・制限するポリシーから除外することを推奨しています。
現場で起きる典型的なずれ
除外で復旧しても、影響したポリシーは確定していません。
利用者の申告時刻と実際のサインイン時刻がずれ、別の試行を見ていることがあります。対象アプリ名だけでなく、クライアント種別、Correlation ID、サインインログの条件付きアクセス欄を一件ずつ確認します。暫定除外には、解除条件、期限、承認者、代替コントロールをその場で記録します。
二種類の除外を混ぜない
緊急用アカウント
通常の管理者が利用できない緊急時にテナントを復旧するためのアカウントです。Microsoftは二つ以上を用意し、通常時は使用せず、監視・定期検証することを示しています。業務上の一時例外と同じ台帳で扱うと、目的と管理方法が曖昧になります。
業務例外
未対応端末、旧式アプリ、委託先、移行期間などを理由とする例外です。期限、対象、代替策、改善計画が必要です。恒久除外に見えても、定期的に必要性を再確認します。
解決までの進め方
- 全ポリシーを一覧化する対象、条件、制御、除外、状態、作成者、変更日を同じ形式で整理します。
- 除外を分類する緊急用、サービス用途、業務例外、移行中、誤設定回避に分けます。
- 依存関係を確認する複数ポリシーの組み合わせ、認証方法、端末管理、対象アプリへの影響を確認します。
- Report-onlyとパイロットを使う影響をログで確認し、限定グループから段階的に有効化します。
- 例外に終了条件を付ける期限、承認者、代替コントロール、再確認日、削除担当を記録します。
- 緊急時を訓練する緊急用アカウントの利用可否、保管、監視、利用後レビューを定期確認します。
支援で整備する主な成果物
条件付きアクセス設計表、ポリシー依存関係図、除外・例外台帳、緊急用アカウント運用手順、Report-only評価記録、段階展開・ロールバック計画、定期レビュー様式。
相談が必要な状態
- 除外ユーザーやグループの理由を一覧にできない
- Report-onlyの評価基準が決まっていない
- ポリシー名から目的や対象が分からない
- 緊急用アカウントを最後に試験した日が不明
- 変更時の承認記録とロールバック手順がない
確認した公式情報
Microsoft Learn：Plan a Conditional Access deployment
ページ更新日：2026年6月1日。確認日：2026年9月3日。
Microsoft Learn：Manage emergency access accounts in Microsoft Entra ID
ページ更新日：2026年6月5日。確認日：2026年9月3日。
適用結果はテナント、ライセンス、対象アプリ、認証方法、端末状態により異なります。個別環境ではサインインログ等による確認が必要です。