Entra IDの条件付きアクセスとは、サインインのたびに「誰が・どこから・どの端末で・何にアクセスするか」を評価し、MFA要求やブロックなどの制御を自動で適用するMicrosoft Entra ID（旧Azure AD）の機能です。パスワードが漏れても、MFAなし・未登録端末・想定外の国からのサインインを止められるため、Microsoft 365を使う中小企業が最初に整えるべきID保護の土台になります。
Entra ID P1相当のライセンス（Microsoft 365 Business PremiumやE3に含まれます）を前提に、最初に入れるべき5つのポリシーを、締め出し事故を起こさない順序で設定します。管理センターのメニュー名は執筆時点のもので、Microsoftは改名を頻繁に行うため英語名も併記します。
この記事でわかること
- Entra ID Free / P1 / P2の違いと、条件付きアクセスに必要なライセンス
- 「シグナル → 条件 → 制御」の評価モデルと、レポート専用モードが実際に何を評価しているか
- 緊急アクセス用アカウントとMFA登録という、ポリシー作成前に済ませる2つの前提
- 全ユーザーMFA・レガシー認証ブロック・管理者保護・準拠デバイス・場所制限の具体的な設定値
- サインインログとPowerShellでの確認方法、AADSTSエラーの読み方
Entra IDとは：Azure ADからの名称変更とFree / P1 / P2の違い
Microsoft Entra IDは、Microsoft 365やAzureのサインインを担うクラウドのID基盤で、2023年にAzure Active Directory（Azure AD）から名称が変わりました。テナントや設定はそのままで、名前と管理ポータル（Microsoft Entra管理センター）が変わっただけです。オンプレミスのActive Directoryとは別物で、両者はEntra Connect（旧Azure AD Connect）でつなぎます。
条件付きアクセスはP1以上の機能です。Freeのテナントでは代わりに「セキュリティの既定値群（Security defaults）」という固定ルール（全員MFA、レガシー認証ブロックなど）しか使えず、両者は排他です。条件付きアクセスポリシーを作るには、先にセキュリティの既定値群をオフにする必要があります。
| プラン | 条件付きアクセス | 主な追加機能 | 含まれる代表的なライセンス（執筆時点） |
|---|---|---|---|
| Entra ID Free | 不可（セキュリティの既定値群のみ） | 基本的なユーザー・グループ管理 | Microsoft 365 Business Basic / Standard |
| Entra ID P1 | 可 | グループベースのライセンス割り当て、動的グループ、SSPRのオンプレ書き戻し | Microsoft 365 Business Premium、E3、EMS E3 |
| Entra ID P2 | 可（リスクベース条件を追加） | Identity Protection、Privileged Identity Management、アクセスレビュー | Microsoft 365 E5、EMS E5 |
ライセンスはユーザー単位で、ポリシーの対象になるユーザー全員にP1が必要です。Business Standardだけの環境なら、条件付きアクセスの前にライセンスの見直しが先になります。
条件付きアクセスの仕組み：シグナル → 条件 → 制御
条件付きアクセスは、認証が成功した「後」にトークンを発行するかどうかを決める仕組みです。パスワードやMFAの検証を通過した時点で、Entra IDはそのサインインのシグナル（ユーザー、グループ、アプリ、IPアドレス、デバイス状態、クライアントアプリの種類、P2ならリスクスコア）を集め、有効なポリシーすべてと照合します。一致したポリシーの制御は「すべて」適用され、1つでもブロックがあればブロックが勝ちます。ポリシーに優先順位はなく、上書きもできません。
ポリシーは「割り当て（ユーザー・ターゲットリソース・条件）」で対象を絞り、「許可」で「ブロック」または「MFAを要求」「準拠デバイスを要求」などを選び、「セッション」でサインイン頻度や永続ブラウザーセッションを制御する3層構造です。状態は「オン」「オフ」「レポート専用」の3つで、レポート専用はサインインごとにポリシーを実際に評価し、「もしオンだったら成功／失敗／ユーザー操作が必要／適用外」のどれになるかをサインインログに記録します。制御は適用されないのでMFA未登録の人も通過しますが、「このポリシーをオンにしたら誰が止まるか」が本番の実トラフィックで分かります。
レポート専用でも例外があります。「デバイスは準拠としてマーク済みである必要があります」や「Entraハイブリッド参加済みデバイスが必要」を含むポリシーをレポート専用にすると、評価のためにデバイス状態を確認する必要があるため、macOS・iOS・Androidのユーザーにデバイス証明書の選択プロンプトが表示されることがあります。モバイルが多い環境では事前に周知するか、対象をWindowsに限定して検証してください。
前提：MFA登録と緊急アクセス用アカウント
P1環境では「MFAを要求」ポリシーに当たった未登録ユーザーがその場で登録画面に誘導されるため、準備なしにオンにすると朝いちばんに全社が同時に登録画面を見ることになります。先にMFAの全社導入手順に沿って登録キャンペーンを行い、Entra管理センターの「保護 → 認証方法 → ユーザー登録の詳細（User registration details）」で登録率を確認してから進めてください。登録画面自体も、ユーザー操作「セキュリティ情報の登録」を対象に社内IPまたは準拠デバイスからのみ許可するポリシーで守れます。
もう1つの前提が緊急アクセス用アカウント（break-glassアカウント）です。設定ミスで全管理者が締め出されたときや、MFA基盤やスマホが使えないときに唯一ログインできる入口になります。
- クラウド専用アカウントを2つ作る。ドメインは
*.onmicrosoft.com（カスタムドメインのフェデレーション障害の影響を受けないため） - グローバル管理者ロールを恒久的に割り当て、特定の個人のスマホや電話番号に紐づけない
- パスワードは長いランダム文字列を分割保管するか、FIDO2セキュリティキーを金庫に保管する
- すべての条件付きアクセスポリシーの「除外」に入れる
- このアカウントのサインインを検知したら通知する（Log Analyticsのアラート、または週次のサインインログ確認）
除外しているからこそパスワードだけで入れる最強のアカウントになるので、保管と監視は厳格にし、四半期に1回は実際にサインインできることを試して記録します。
ポリシー1：全ユーザーにMFAを必須にする
Entra管理センターの「保護（Protection） → 条件付きアクセス → ポリシー → 新しいポリシー」から作成します。「テンプレート」にも同等のものがありますが、除外設定を自分で入れるため手動作成をおすすめします。
| 設定項目 | 値 | 理由 |
|---|---|---|
| 名前 | CA001-AllUsers-RequireMFA | 番号・対象・制御を名前に入れるとサインインログで一目で分かる |
| ユーザー（含める） | すべてのユーザー | グループ指定だと入社時の付け忘れが起きる |
| ユーザー（除外） | 緊急アクセス用アカウント2つ、サービスアカウント用グループ | 締め出し防止。サービスアカウントは別途保護する |
| ターゲットリソース | すべてのリソース（旧「すべてのクラウドアプリ」） | アプリ単位の指定は漏れが出る |
| 許可 | アクセス権の付与 → 多要素認証を要求する | 認証強度は管理者ポリシーから先に使う |
| 状態 | レポート専用 → 検証後にオン | 誰がMFA未登録かをログで把握してから有効化 |
「多要素認証を要求する」は認証方法ポリシーで許可した方法（SMS、Authenticator、FIDO2など）のどれでも通るため、SMSと音声通話を段階的に無効化する計画もセットで持ってください。複合機のスキャン送信などMFAに対応できないサービスアカウントは除外グループに入れることになりますが、パスワードだけで守られる状態になるので、レガシー認証ブロックの対象からは外さず、「場所」条件で送信元IPを社内に限定する別ポリシーを作ります。
ポリシー2：レガシー認証をブロックする
レガシー認証とは、IMAP・POP・SMTP AUTH・Exchange ActiveSync・古いOffice（2010以前）などが使う基本認証（ユーザー名とパスワードをそのまま送る方式）です。この方式はMFAの検証を挟む仕組みを持たないため、ポリシー1を入れてもレガシー認証で入られればパスワードだけで突破されます。Exchange Onlineでは基本認証が段階的に無効化されてきましたが、テナントの設定や例外で残っているケースがあり、条件付きアクセス側でも明示的に閉じておくのが確実です。
設定は、ユーザー「すべてのユーザー」（緊急アカウントを除外）、ターゲットリソース「すべてのリソース」、条件 → クライアントアプリ →「構成済み: はい」で「Exchange ActiveSyncクライアント」と「その他のクライアント」だけにチェック（「ブラウザー」「モバイルアプリとデスクトップクライアント」は外す）、許可は「アクセスをブロックする」です。
オンにする前に、サインインログを「クライアントアプリ」でフィルタし、直近30日間にIMAP、POP、Authenticated SMTP、Exchange ActiveSyncでサインインしているアカウントを洗い出してください。複合機のスキャン送信や古いスマホのメール設定が引っかかります。複合機はSMTP AUTH以外の送信方法（コネクタ経由の直接送信など）に切り替えるか、専用アカウントを除外して送信元IPで制限します。
ポリシー3：管理者ロールを保護する
ポリシー1で全員にMFAを求めていても、管理者には別ポリシーを作る価値があります。ポリシー1を一時的にオフにした間も管理者だけは守られること、そして管理者にはより強い認証方法を要求できることが理由です。ユーザーの指定で「ディレクトリロール」を選び、グローバル管理者、特権ロール管理者、セキュリティ管理者、条件付きアクセス管理者、Exchange管理者、SharePoint管理者、ユーザー管理者、認証管理者、特権認証管理者、アプリケーション管理者、Intune管理者、ヘルプデスク管理者、パスワード管理者、課金管理者あたりを対象にします。
許可には「認証強度が必要」→「フィッシング耐性MFA」を推奨します。Authenticatorの番号一致プッシュは中間者型フィッシングを防げませんが、FIDO2セキュリティキーやWindows Hello for Businessは認証が発生したドメインと鍵が紐づくため、偽サイトでは認証自体が成立しません。ただし管理者全員にキーが行き渡る前に入れると全員が締め出されるので、揃うまでは「多要素認証を要求する」で始めます。Microsoft自身もEntra管理センターやAzureポータルへのサインインにMFAを必須化する取り組みを進めており（執筆時点）、管理者MFAは前提条件と考えてください。
あわせて、日常業務用と管理者用でアカウントを分け（管理者は別UPN、ライセンスなし、メールボックスなし）、セッション制御「サインインの頻度」を4〜8時間にしておくと、フィッシングメールが管理者権限に直結する経路を切れます。
ポリシー4：準拠デバイスを要求する
「準拠デバイス」とは、Intuneに登録され、コンプライアンスポリシー（BitLocker有効、OSバージョン、Defender有効など）を満たしていると評価された端末です。このポリシーを入れると、パスワードとMFAの両方が盗まれても会社が管理していない端末からはアクセスできなくなります。前提としてIntuneが必要なので、まだの場合はIntuneでのWindows端末管理の始め方を先に進めてください。
設定は、ユーザーはまずパイロットグループ、ターゲットリソースは「すべてのリソース」、条件 → デバイスプラットフォームで「Windows」だけを含め、許可は「デバイスは準拠としてマーク済みである必要があります」です。オンプレADに参加した端末をEntra Connectで同期している環境なら、「Microsoft Entraハイブリッド参加済みデバイスが必要」を「いずれか1つ」で並べて選択します。
Intuneには「コンプライアンスポリシーが割り当てられていないデバイスを『準拠』とマークする」という既定の動作があります（Intune管理センターの「デバイス → コンプライアンス → コンプライアンスポリシーの設定」）。既定値が「準拠」のままだと、登録しただけでポリシーを1つも満たしていない端末が「準拠」と判定され、このポリシーを素通りします。準拠デバイスを要求する前に「非準拠」へ変更してください。
私物スマホでメールだけ見たい要望が多い会社では、端末登録を強いるより、iOS/Androidを対象に「アプリの保護ポリシーが必要」（Outlookアプリ内のデータをIntuneのアプリ保護ポリシーで守る）を選ぶほうが定着します。
ポリシー5：場所によるアクセス制限
「保護 → 条件付きアクセス → ネームドロケーション」で、「国の場所」として「Japan」を含む許可国のリストを作ります。判定方法は「IPアドレス（GeoIP）」で、「不明な国/地域を含める」はオフのままにします。ポリシーは、ユーザー「すべてのユーザー」（緊急アカウントと海外出張者グループを除外）、条件 → 場所 →「含める: 任意の場所」「除外: 許可国のネームドロケーション」、許可「アクセスをブロックする」です。
この制御の実態は「攻撃者の手間を増やすフィルタ」です。GeoIPの誤判定はありますし、国内のVPN出口を使う攻撃者は通過します。それでも海外IPからの自動化されたパスワードスプレー攻撃をログの段階で減らせる効果は大きく、サインインログが読みやすくなる副次効果もあります。海外出張が日常的な会社では、国のリストを広げるより、出張者グループを期間限定で除外に入れる運用のほうが安全です。
逆に「社内IPを信頼できる場所にしてMFAを免除する」構成は推奨しません。オフィスのネットワークに侵入された時点でMFAが無効化される設計になるためで、オフィスでのプロンプトが多い不満は準拠デバイスとサインイン頻度の調整で解決するほうが筋が良いです。
レポート専用モードでの検証と本番展開の手順
- 5つのポリシーをすべて「レポート専用」で作成し、緊急アカウントの除外を各ポリシーで目視確認する
- 1〜2週間、サインインログの「レポート専用」タブで「失敗」「ユーザー操作が必要」になった件数と対象ユーザーを集計する
- 診断設定でサインインログをLog Analyticsに送っている場合は、「ID → 監視と正常性 → ワークブック → 条件付きアクセスの分析情報とレポート」で傾向を見る
- ポリシー1と2を情シスのパイロットグループに対して「オン」にし、数日運用する
- 全ユーザーに対してオンにする。順番は「2（レガシー認証ブロック）→ 1（MFA）→ 3（管理者）→ 5（場所）→ 4（準拠デバイス）」。準拠デバイスはIntune登録率が95%を超えてから
- 切り替えは平日の午前中、ヘルプデスクが対応できる時間帯に行い、ロールバック手順（ポリシーをオフに戻す）を担当者2名が把握しておく
「What If」ツール（ポリシー一覧の上部）では、特定のユーザー・アプリ・IP・デバイス状態の組み合わせでどのポリシーが適用されるかを、サインインせずに確認できます。緊急アカウントに何も適用されないことを展開前にここで確認します。
確認方法：サインインログとPowerShell
個々のサインインの判定は、Entra管理センターの「ID → 監視と正常性 → サインインログ」で該当行を開き、「条件付きアクセス」タブで見ます。ポリシーごとに「成功」「失敗」「適用外」と要求された制御が表示され、「レポート専用」タブには評価結果が同じ形式で並びます。フィルタ「条件付きアクセス: 失敗」でブロックされたサインインだけを抽出できます。
ポリシーの一覧と状態は、Microsoft Graph PowerShellで取得しておくと変更履歴の証跡になります。以下は読み取り専用のスコープで実行できます。
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Install-Module Microsoft.Graph.Reports -Scope CurrentUser
Connect-MgGraph -Scopes "Policy.Read.All","AuditLog.Read.All"
# ポリシー名と状態（enabled / disabled / enabledForReportingButNotEnforced）
Get-MgIdentityConditionalAccessPolicy |
Select-Object DisplayName, State, ModifiedDateTime |
Sort-Object DisplayName | Format-Table -AutoSize
# 緊急アクセス用アカウントの直近サインイン（使われていないことの確認）
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '[email protected]'" -Top 5 |
Select-Object CreatedDateTime, IpAddress, AppDisplayName, @{n='Result';e={$_.Status.ErrorCode}}Stateの値は、オンがenabled、レポート専用がenabledForReportingButNotEnforcedです。月次でこの出力を保存しておくと、誰かがポリシーをオフにしたまま戻し忘れた事故に気づけます。
つまずきポイント：エラーコードと対処
AADSTS53003: Access has been blocked by Conditional Access policies
ブロック制御に当たったときの標準メッセージです。サインインログで該当行の「条件付きアクセス」タブを開き、失敗しているポリシー名を確認します。準拠デバイスポリシーなら端末のIntune登録状態、場所ポリシーならIPアドレスと判定された国を見れば原因が分かります。テザリング中のスマホが海外IPと判定されるケースも実際にあります。
AADSTS50076 / AADSTS50079: MFAが要求されたが完了できない
50076はMFAが必要なのに対話的に応答できないクライアント（スクリプトからの認証、古いアプリ）で出ます。50079はMFA未登録のユーザーが登録を求められている状態です。前者はサービスアカウントの認証方式を証明書やマネージドIDなどの非対話型に変えるか、除外グループに入れて別の制御で守ります。後者が大量に出るなら、ポリシー1をオンにするのが早すぎたサインです。
新しいポリシーが作れず、セキュリティの既定値群の無効化を求められる
「ID → 概要 → プロパティ → セキュリティの既定値群の管理」でオフにできますが、オフにした瞬間から条件付きアクセスをオンにするまでの間はMFAが強制されない空白期間になります。ポリシー1と2をレポート専用で作り終え、除外設定を確認してから、既定値群オフとポリシーオンを同じ作業時間内に行ってください。
Outlookデスクトップやスマホのメールが「パスワードが違う」と繰り返す
レガシー認証ブロック後の典型症状です。iPhoneの標準メールアプリで古い方式でExchangeアカウントを追加していた場合や、Outlook 2013以前の環境で発生します。アカウントを一度削除して再追加すると先進認証で再構成されます。サインインログでは「クライアントアプリ」がIMAPやExchange ActiveSyncとして記録されるので、申告がなくても特定できます。
よくある質問
Entra IDとAzure ADは何が違いますか？
同じサービスの新旧の名前です。2023年にAzure Active DirectoryからMicrosoft Entra IDに改名され、ライセンス名もAzure AD Premium P1/P2からEntra ID P1/P2になりました。テナントIDや設定、PowerShellの互換性に影響はなく、古いドキュメントでAzure ADと書かれていても読み替えて問題ありません。
条件付きアクセスに必要なライセンスは？
対象ユーザーごとにEntra ID P1以上が必要で、Microsoft 365 Business Premium、E3、E5、EMS E3/E5に含まれます。サインインリスクやユーザーリスクを条件に使うにはP2（E5など）が必要です。Business BasicやStandardのみならFree相当なので、セキュリティの既定値群で全員MFAとレガシー認証ブロックだけは有効にしてください。
締め出されないための対策は？
緊急アクセス用アカウントを2つ作ってすべてのポリシーから除外し、四半期ごとにサインインテストをすることが第一です。次に、新規ポリシーは必ずレポート専用で1〜2週間ログを見てからオンにし、What Ifツールで緊急アカウントと自分のアカウントを事前確認します。それでも締め出されたら、緊急アカウントでサインインして該当ポリシーをオフにするのが復旧手順です。
まとめ
5つのポリシーのうち、効果が大きく副作用が小さいのはレガシー認証ブロックと全ユーザーMFAで、この2つだけでもパスワードスプレー攻撃の大半は無力化できます。準拠デバイス要求はIntuneの登録率が上がってから、場所制限は出張者の除外運用を決めてから入れると、ヘルプデスクへの問い合わせを抑えられます。どのポリシーも、レポート専用での実トラフィック検証と緊急アカウントの除外確認を省かないでください。
次に読む
- 多要素認証（MFA）を全社導入する手順：ポリシー1の前提となる登録キャンペーンとパスキー移行
- Intuneで始めるWindows端末管理：準拠デバイス要求に必要なコンプライアンスポリシーの作り方
- ゼロトラストとは？最初の90日で取り組む実践ステップ：条件付きアクセスをID・端末・アクセス制御の全体像に位置づける