はじめに
Entra ID（旧Azure AD）の条件付きアクセス（Conditional Access）は、設定自体は難しくありません。問題は「どのポリシーを、誰に、どの順番で適用するか」という設計判断です。
外資系ITコンサルとしてModern Workplace案件を複数担当してきた経験から、現場で詰まりやすいポイントと判断軸をまとめます。
前提：条件付きアクセスはポリシーの「積み重ね」
条件付きアクセスは複数のポリシーが同時に評価されます。あるユーザーが複数のポリシーに該当する場合、最も制限が厳しいポリシーが適用されます（OR評価ではなくAND評価）。
この前提を理解していないと、「なぜかMFAが求められる」「なぜかブロックされる」という問い合わせが発生したときに原因の切り分けができません。
落とし穴1：緊急アクセスアカウントを除外し忘れる
条件付きアクセスの設定を誤ると、全管理者がサインインできなくなります。これは実際に起きる事故です。
必ず最初にやること：
# 緊急アクセスアカウントをポリシーの除外に追加する
# Azure Portal → Entra ID → 条件付きアクセス → ポリシー → 除外 → ユーザー
緊急アクセスアカウント（Break Glass Account）は以下の要件で作成します。
- MFAを要求しないアカウント（認証手段が制限された環境でもサインイン可能にする）
- Entra ID P1/P2ライセンスを割り当てない
- グローバル管理者ロールを付与
- 強力なランダムパスワードを設定し、物理的に保管
- 使用時にアラートが上がるように監査ログを監視
【2025年2月以降の注意点】
各種管理センターおよびAzure PortalへのMFA強制化が実施されたため、「MFAを要求しない」という設計だけでは条件付きアクセスの設定ミス時に完全ロックアウトのリスクが残ります。現在のベストプラクティスは FIDO2セキュリティキー（2本以上・異なる場所に物理保管）を認証手段として設定することです。セキュリティキー＋PIN（またはキーの種類によっては生体認証）で認証できるため、パスワードの物理保管も不要になります。
すべての条件付きアクセスポリシーからこのアカウントを除外すること。
落とし穴2：レポート専用モードを使わずに本番適用する
ポリシーを作成してすぐに「有効」にするのは危険です。必ずレポート専用モードで一定期間動作を確認してから有効化してください。
ポリシーの状態：
- オフ（評価されない）
- レポート専用（評価されるがアクセス制御はしない）
- オン（実際にアクセス制御が行われる）
レポート専用モードでの確認期間の目安は最低1週間です。サインインログを見て、想定外のユーザーやアプリケーションが引っかかっていないかを確認します。
# サインインログで条件付きアクセスの評価結果を確認
Connect-MgGraph -Scopes "AuditLog.Read.All"
$logs = Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'reportOnlySuccess'" -Top 100
$logs | Select-Object UserDisplayName, AppDisplayName, ConditionalAccessStatus |
Format-Table -AutoSize
落とし穴3：named locationの管理が属人化する
条件付きアクセスで「社内IPアドレスからのアクセスは除外する」という設定をよく使います。このときに使うのがNamed Location（名前付きの場所）です。
Named Locationを管理する際によくある問題は、「誰がどのIPを登録したかわからない」「古いIPが残り続けている」という属人化です。
管理のポイント：
- Named Locationに登録したIPアドレスはコメントで用途を記載する（Entra IDのUI上にメモ欄はないため、命名規則で管理する）
- 例：
Office-Tokyo-Main、VPN-Endpoint-Osaka - 四半期ごとにレビューして不要なエントリーを削除する
- PowerShellでエクスポートして台帳管理する
Connect-MgGraph -Scopes "Policy.Read.All"
$locations = Get-MgIdentityConditionalAccessNamedLocation
$locations | ForEach-Object {
[PSCustomObject]@{
DisplayName = $_.DisplayName
Id = $_.Id
CreatedDateTime = $_.CreatedDateTime
ModifiedDateTime = $_.ModifiedDateTime
}
} | Export-Csv -Path "named_locations.csv" -Encoding UTF8 -NoTypeInformation
落とし穴4：ゲストユーザーへのポリシー適用を考慮していない
デフォルトでは条件付きアクセスのポリシーは「すべてのユーザー」に適用されます。この「すべてのユーザー」にはゲスト（外部）ユーザーも含まれます。
社内ユーザー向けに設計したMFAポリシーが外部ユーザーに適用されると、「Teamsの会議に招待した取引先が参加できない」という問い合わせが発生します。
設計判断のポイント：
| 対象 | 推奨設定 |
|---|---|
| 社内ユーザー | 全MFAポリシーを適用 |
| ゲストユーザー | 専用ポリシーで分離管理 |
| サービスプリンシパル | ワークロードID条件付きアクセスで別管理 |
ゲストユーザー専用ポリシーを作る際は、「ユーザーとグループ」の条件で「ゲストまたは外部ユーザー」を明示的に選択します。
設計判断の優先順位
現場で条件付きアクセスを設計する際の判断順序をまとめます。
Step 1: まず緊急アクセスアカウントを作成・除外設定
Step 2: MicrosoftのSecure Score推奨ポリシーを確認
Entra管理センターの「セキュリティスコア」から推奨ポリシーのテンプレートを使うことで、設計の抜け漏れを防げます。
Step 3: レポート専用モードで1週間以上テスト
Step 4: 影響範囲の小さいグループから段階的に有効化
全ユーザーに一括適用せず、ITチームや先行ユーザーグループから展開します。
Step 5: サインインログの定期レビューを運用に組み込む
まとめ
条件付きアクセスの設計でよくある失敗は、「動作確認が不十分なまま全社展開した」「緊急アクセスアカウントの除外を忘れた」「ゲストユーザーへの影響を考慮しなかった」の3つに集約されます。
設定そのものよりも「誰に・いつ・どの順番で適用するか」という判断プロセスが重要です。
Entra IDの設計判断軸については しがないblog でも継続的に発信しています。条件付きアクセス設計の実務的なポイントについてはこちらの記事も参照してください。