条件付きアクセス基本ポリシー：最初に作る6本

要点： 小規模なテナントは、まず6本の条件付きアクセスポリシーから始めます。管理者のMFA、全ユーザーのMFA、レガシー認証のブロック、セキュリティ情報の登録の保護、Azure管理のMFA、ゲストのMFAです。6本すべてで緊急用アクセスアカウントを除外し、作成時はレポート専用（Report-only）にして、結果を読んでから1本ずつOnに切り替えます。ただし登録のポリシーはレポート専用では試せないため、グループを決めて先行導入します。以下はCA001〜CA006の番号順で、本番化の順番は「まずレポート専用でテストする」の末尾に別に示します。必要なのはMicrosoft Entra ID P1で、MicrosoftはMicrosoft 365 Business Premiumのお客様も利用できると説明しています。

この記事は、ライセンスはあるものの条件付きアクセスの基本セットをまだ作っていない、小〜中規模のMicrosoft 365テナントの管理者向けです。ポリシーごとに、対象、条件、許可コントロール、除外を示し、そのあとレポート専用で安全に本番へ切り替える手順を説明します。手順は2026年10月28日にMicrosoft Learnで確認しました。

作り始める前に

緊急用アクセスアカウントを2つ作る。 Microsoftの推奨は、onmicrosoft.comドメインのクラウド専用アカウントで、Global Administratorロールを常時割り当て、サインインにはパスキー（FIDO2）を使う構成です。2つをEmergencyAccessというグループに入れます。
セキュリティの既定値をどうするか決める。 セキュリティの既定値と条件付きアクセスは置き換えの関係です。ポリシーに頼る前に、セキュリティの既定値を無効にします（Entra ID > Overview > Properties > Manage security defaults > Disabled）。
Microsoft管理のポリシーを確認する。 Entra ID > Conditional Access > Policies で、Created by 列がMicrosoftの行は、Microsoftがレポート専用で作成したものです。そのままにすると、Microsoftが導入から30日以上後に有効にします。理由がなければ、同じルールの複製を作らないでください。「Multifactor authentication for all users」や「Block legacy authentication」のようなMicrosoft管理のポリシーが、すでにCA003やCA001に相当している場合があります。その場合は新規に重複して作らず、それらの状態と除外を編集してください。
命名ルールを決める。 たとえばCA001〜CA006に短い説明を付けます。
ロールを確認する。 ポリシーの作成には、少なくともConditional Access Administratorが必要です。ライセンス：Microsoft Entra ID P1またはMicrosoft 365 Business Premium。リスクベースのポリシーにはEntra ID P2が必要です。

以下の操作はすべて、Microsoft Entra管理センター（entra.microsoft.com）の Entra ID > Conditional Access > Policies > New policy で行います。Entra ID > Conditional Access > Create new policy from templates から始めることもできます。Microsoftのテンプレートはレポート専用で作成され、ユーザーを対象にするテンプレートで除外されるのは作成者だけです。作成後にポリシーを開き、緊急用アクセスのグループを追加してください。

6本のポリシー

各ポリシーは、ユーザー、ターゲットリソース、条件、許可コントロール、除外の順に書いています。

CA001：レガシー認証をブロックする

ユーザー： All users。
ターゲットリソース： All resources (formerly 'All cloud apps')。
条件： Client apps > Configure = Yes。Exchange ActiveSync clients と Other clients だけにチェックを入れます。
許可： Block access。
除外： EmergencyAccessグループ。引き続きレガシープロトコルが必要なアカウントは、期限を決めた一時的な例外として追加します。
有効にする前に： 誰が使っているかを調べます。Entra ID > Monitoring & health > Sign-in logs を開き、Client App列を追加して、レガシープロトコルで絞り込みます。対話型サインインと User sign-ins (non-interactive) の両方のタブで確認します。

CA002：管理者にMFAを要求する

ユーザー： Include > Directory roles。Microsoftの一覧は、Global Administrator、Application Administrator、Authentication Administrator、Billing Administrator、Cloud Application Administrator、Conditional Access Administrator、Exchange Administrator、Helpdesk Administrator、Password Administrator、Privileged Authentication Administrator、Privileged Role Administrator、Security Administrator、SharePoint Administrator、User Administratorです。
ターゲットリソース： All resources。
条件： なし。
許可： Grant access > Require multifactor authentication。Microsoftは、管理者の準備ができたら、認証強度（authentication strength）でフィッシング耐性のあるMFAを要求することも検討するよう勧めています。
除外： EmergencyAccessグループ。
注意： このポリシーが対象にするのは組み込みロールだけです。管理単位のスコープのロールとカスタムロールには適用されません。

CA003：全ユーザーにMFAを要求する

ユーザー： All users。
ターゲットリソース： All resources (formerly 'All cloud apps')。アプリの除外はしません。Microsoftはこれを基本にするよう推奨しています。
条件： なし。信頼できるネットワークの例外（Network > Include Any network or location > Exclude All trusted networks and locations）を加える場合は、ポリシーを弱めるため、必ず記録に残します。
許可： Grant access > Require authentication strength > Multifactor authentication。
除外： EmergencyAccessグループ。Entra ConnectまたはCloud Syncを使う場合は、ディレクトリロール Directory Synchronization Accounts も除外します。ゲストを除外するのは、CA006で別にカバーする場合だけです。

CA004：セキュリティ情報の登録を保護する

ユーザー： All users。All guest and external users（Temporary Accessパスはゲストでは使えません）とEmergencyAccessグループを除外します。
ターゲットリソース： User actions > Register security information。
条件： Locations > Configure = Yes。Any locationを含め、All trusted locationsを除外します。
許可： Grant access > Require authentication strength。組み込みまたはカスタムの強度を選びます。
除外： 上記のとおり。
注意： 統合登録（combined registration）を有効にしておく必要があります。新入社員にはTemporary Accessパスを発行し、登録時のMFA要件を満たせるようにします。Microsoftのページによると、2026年7月6日以降、Register security informationを対象にしたポリシーは、Windows Hello for BusinessやmacOS Platform SSOの資格情報を登録するときにも適用されます。

CA005：Azure管理にMFAを要求する

ユーザー： All users。
ターゲットリソース： Select resources > Windows Azure Service Management API。Azureポータル、Microsoft Entra管理センター、Azure PowerShell、Azure CLIが対象です。
条件： なし。
許可： Grant access > Require multifactor authentication。
除外： EmergencyAccessグループ。
注意： MicrosoftはAzureのサインインにも自らMFAを強制しており、緊急用アカウントも含まれると説明しています。それでも、自社のルールを見える形でテストできるように、このポリシーは残しておきます。

CA006：ゲストと外部ユーザーにMFAを要求する

ユーザー： Include > Select users and groups > Guest or external users。使っているゲストの種類を選びます。
ターゲットリソース： All resources、またはゲストが必要とするアプリ。
条件： なし。
許可： Grant access > Require authentication strength > Multifactor authentication。先にクロステナントアクセス設定の受信MFA信頼を確認してください。
除外： EmergencyAccessグループ。
注意： Microsoftによると、認証強度が現在適用できるのは、Microsoft Entra IDで認証するゲストです。メールのワンタイムパスコード、SAML/WS-Fed、Googleフェデレーション、個人のMicrosoftアカウントのゲストには、Require multifactor authentication の許可コントロールを使います。

まずレポート専用でテストする

各ポリシーの作成時に、Enable policy を Report-only にして Create を選びます。
少なくとも平日1週間分のサインインを集めます。月末や週次のジョブも出てくるようにするためです。CA001は長いほど安心です。「1週間」は筆者の目安で、Microsoftの数字ではありません。
ポリシーを開いて Policy impact（Security Reader以上のロール）を見ます。24時間、7日、1か月の対話型サインインへの影響が分かります。
Entra ID > Monitoring & health > Sign-in logs を開き、サインインを1件選んで、Report-only タブでポリシーごとの結果（Success、Failure、User action required）を確認します。
Entra ID P1とサインインログを受け取るLog Analyticsワークスペースがあれば、Conditional Access Insights and Reportingブックで多数のサインインをまとめて比較できます。
抜けを埋めます。除外の追加、複合機のモダン認証への移行、遅れているユーザーのMFA方法の登録です。
Enable policy を Report-only から On に、1本ずつ、間に1〜2日あけて切り替えます。ポリシーをOnにしたあとサインインに失敗する場合は、緊急用アクセスアカウントでサインインし、そのポリシーをReport-onlyまたはOffに戻します。

Microsoftのレポート専用のページによると、User actionsのスコープに含まれる項目は、レポート専用モードでは評価できません。CA004がこれに当たるため、レポート専用の結果に頼らず、パイロットグループに割り当ててから対象を広げてください。

多くの小規模テナントで使いやすい本番化の順番は、CA002（管理者）、CA005、CA001（レガシー認証の洗い出し後）、CA003、CA006、最後にCA004です。

よくある失敗

緊急用アクセスアカウントがない、または除外していない。 誤ったポリシー1つで、自分も含めて全員が締め出されることがあります。四半期ごとにこのアカウントを試します。
除外が多すぎる。 「情シスチーム」や「役員」という除外が抜け道になります。除外は緊急用アカウントと、どうしても避けられないサービスアカウントだけにします。
テンプレートの除外を直さない。 テンプレートが除外するのは、ポリシーを作成した本人だけです。
レポート専用の結果を読まずにオンにする。 サインインログを見れば、ブロックされていたはずの対象が分かります。
サービスアカウントと同期アカウントを忘れる。 Entra ConnectやCloud Syncのアカウントには、Directory Synchronization Accountsの除外が必要です。スクリプトに使うユーザーアカウントは、マネージドIDやワークロードIDに置き換えます。
従来型のポリシーを放置する。 従来型の条件付きアクセスポリシーは2024年7月10日に適用を停止しました。最新のポリシーとして作り直し（Entra ID > Conditional Access > Classic policies）、古いものを無効にします。

効いているかの確認

サインインログで最近のサインインの Conditional Access タブを開き、各ポリシーの結果が期待どおりSuccessまたはNot appliedになっているか確認します。
Conditional AccessのWhat Ifツールで、テストユーザー、アプリ、クライアントの種類を指定し、どのポリシーが適用されるか確認します。
テストユーザーでプライベートウィンドウからサインインし、MFAの確認が出ることを確かめます。
テスト用メールボックスからレガシープロトコルで接続し、ブロックされることを確認します。
緊急用アカウントでサインインして今も使えることを確認し、日付を記録します。
Conditional AccessのOverviewタブとCoverageタブで、ポリシーのカバーがないアプリを確認します。

すでに条件付きアクセスポリシーがあるテナントは、どう監査しますか？

上の6本は、まだ何もないテナントのためのものです。実際に見るテナントの多くはそうではありません。2〜3年前に誰かが一式を作り、プロジェクトのために数本が足され、それ以来、一覧を通して読んだ人がいない、という状態です。既存のポリシー群を監査するのは、ゼロから作るのとは別の作業です。問うべきは「どのポリシーがあるべきか」ではなく、「いまあるポリシーは、担当者が思っているとおりに働いているか」です。Microsoft Entra管理センターの Entra ID > Conditional Access > Policies でポリシーを1本ずつ開き、別のタブにサインインログ（Entra ID > Monitoring & health > Sign-in logs を Conditional Access で絞り込み）を開いたまま、下の一覧に沿って確認します。ポリシー名、状態、見つかったことを書き留めてください。その記録がそのまま報告書の下書きになります。

既存の条件付きアクセスで確認する10項目

レポート専用のまま止まっているポリシー。 State 列を見ます。何か月もレポート専用のままのポリシーは何も強制しておらず、作った本人も忘れていることが多いです。良い状態：すべてのポリシーが理由のある On か理由のある Off で、テスト期間を過ぎて Report-only のものが1本もない。
膨らんだ除外グループ。 各ポリシーの Users > Exclude を開き、グループそのものも開きます。2024年に2人だった EmergencyAccess グループが、今日は9人になっていることがあります。良い状態：除外は緊急用アクセスアカウント2つと、記録のあるサービスアカウントに限られ、それぞれに担当者と見直し日がある。
オフィスの実態と合わなくなった名前付きの場所。 Entra ID > Conditional Access > Named locations で、信頼済みIP範囲を各オフィスがいま実際に使っている回線と照らし合わせます。前の回線事業者の範囲や、閉鎖したオフィスの範囲は、今日そのアドレスを持っている誰かにとっての信頼済みの場所です。良い状態：すべての範囲が現在のオフィスか VPN の出口に対応し、一覧に最終確認日がある。
レガシー認証のブロックがない。 CA001 に相当するポリシーが存在し On であることを確認し、サインインログを Client app の Exchange ActiveSync と Other clients で絞り込んで、まだ通っているものがないか見ます。良い状態：ブロックが On で、直近30日のレガシープロトコルのサインインがゼロか、すべて説明がつく。
サインイン頻度や持続的ブラウザーセッションの制御がない。 ユーザー向けポリシーの Session 制御を確認します。これがないと、共用端末や管理外の端末のトークンが長期間有効なままになります。良い状態：管理外デバイスにサインイン頻度が設定され、デバイスがコンプライアンスポリシーを満たしていない、またはハイブリッド参加していない場合は持続的ブラウザーセッションが無効。
緊急用アカウントを除外していない All users ポリシー。 All users を対象にしながら EmergencyAccess グループを除外していないポリシーは、誤った変更1つで全員を締め出します。良い状態：All users のポリシーはすべてこのグループだけを除外し、緊急用アカウントは定期的にテストされている。
廃止済みの機種を参照するデバイスフィルター。 Conditions > Filter for devices を開いてルールを読みます。会社がもう使っていない機種、OSバージョン、命名プレフィックスを前提に書かれたフィルターは、何にも一致しないまま黙っており、本来かけるはずだった制御がかかっていないことが多いです。良い状態：コンプライアンス状態や信頼の種類など、いまも維持されている属性でフィルターが書かれている。
重複した Microsoft 管理のポリシー。 Created by 列が Microsoft の行は、CA001 や CA003 と重複していることがあります。同じルールで除外だけが違うポリシーが2本あると、結果は誰にも予測できません。良い状態：1つのルールにポリシーは1本で、Microsoft 管理のものは採用して編集するか、意図して無効にしている。
サービスアカウントを除外した管理者MFAポリシー。 CA002 に相当するポリシーを開き、除外を読みます。管理者ロールを持ちながらMFAのないサービスアカウントは、漏れたパスワード1つからテナント全体の乗っ取りに至る最も多い経路です。良い状態：特権ロールを持つ人もサービスアカウントも除外されておらず、自動化はマネージドIDかワークロードIDで動いている。
ゲストを対象にしたポリシーがない。 Guest or external users を対象にしたポリシーがあるか確認します。2つ前のプロジェクトで終わった取引先のゲストが、今日も Teams と SharePoint に席を持っています。良い状態：CA006 に相当するポリシーが On で、テナント間アクセス設定が見直され、古いゲストが定期的に削除されている。

どの項目も、あとで別の人が確認できなければ役に立ちません。ポリシー一式を JSON でエクスポートし（各ポリシーの Download JSON、または Graph API）、代表的なユーザーの条件付きアクセス結果が分かる日付付きのサインインログのサンプルを保存し、誰がいつ除外グループを見直したかを記録します。この3点を見直し日とともに保管したものが、保険会社、監査人、取引先から「アクセスはどう制御されているか」と聞かれたときに証拠として使えるように設計された資料です。ポリシー一覧のスクリーンショット1枚ではそうなりません。

この一覧は、当社の一回限りの Microsoft 365 セキュリティ監査の ID セクションの大部分を占めます。監査ではテナント内のすべてのポリシー、除外グループ、名前付きの場所を確認し、結果を CIS Microsoft 365 Benchmark に照らして記録します。関連記事のMFA ギャップレポートは、ID のもう半分、つまりどのユーザーが実際にMFAを登録し、どの方法を使っているかを扱います。

FAQ

条件付きアクセス（Conditional Access）とは何ですか？

Microsoft Entraの機能で、「もしこうなら、こうする」という形でアクセスを判断します。ユーザーがMicrosoft 365のようなリソースにアクセスするなら、MFAなどの要件を満たす必要があります。Microsoftはポリシーを、第1要素の認証が完了してから適用します。

Microsoft Entraとは何ですか？

Microsoftが、IDとアクセスに関する製品群につけているブランドです。Microsoft Entra ID（旧Azure Active Directory）は、Microsoft 365のユーザーを保持するディレクトリです。条件付きアクセスは、Microsoft Entra管理センターの Entra ID > Conditional Access で設定します。

Azureではどの認証が使われますか？

サインインにはMicrosoft Entra IDが使われます。条件付きアクセスでは、組み込みの認証強度（Multifactor authentication、Passwordless MFA、Phishing-resistant MFA）を要求できます。

Azure Policyと条件付きアクセスは同じものですか？

違います。Azure PolicyはAzureリソースのための別のガバナンスサービスで、条件付きアクセスはIDのシグナルに基づいてアプリやリソースへのサインインを制御します。MicrosoftはAzure PolicyでMFAのないAzureリクエストを監査または拒否することもできると述べていますが、別の仕組みです。