条件付きアクセスの設定方法｜最初に作るポリシーと、締め出されない作り方

条件付きアクセスを任されて最初のポリシーを作ろうとすると、「すべてのユーザー」や「すべてのリソース」を選んだところで「自分自身をロックアウトしないでください。」と警告が出ます。それでも対象外には、テンプレートでは作る人（現在のユーザー）が入り、手で作ると空のままで、緊急用アカウントは入りません。対象外を誤ると、管理者も含めて誰も入れなくなることがあります。

この記事では、条件付きアクセスに要るライセンスと既定値群の扱い、ポリシーの欄が決めること、最初にテンプレートから作る数本とその順番、締め出されないための4つの決まり、入れなくなったときの戻し方を、今の画面に沿って順に書きます。

Microsoft 365 の導入を支援している当社が、公式の説明と、当社の検証用の環境の画面をもとに書いています。

始める前に確かめる3つ

プランに Entra ID P1 が含まれているか

条件付きアクセスを使うには Microsoft Entra ID P1 のライセンスが要り、P1 は Microsoft 365 Business Premium に含まれています（Microsoft Entra のライセンス）。ほかのプランで使うときは、P1 を足すか Business Premium に上げるかを先に決めます。Business Standard との違いはBusiness Standard と Business Premium の違いの記事で比べています。

危険なサインインや危険度の高いユーザーに反応させる、リスクを使うポリシーは、Entra ID P2 の機能（Microsoft Entra ID 保護）が要ります。Business Premium だけでは P2 は含まれません。英語版の Learn のライセンスのページは、P2 が Business Premium 向けの「Microsoft Defender Suite」と「Microsoft Defender and Purview Suites」にも含まれると書いています（Microsoft Entra licensing）。日本語版はこの箇所の訳が崩れていて読み取りにくいことがあるため、英語版を見てください。画面の［条件］の欄には、Learn の説明にあるサインインのリスク・ユーザーのリスクの項目は出ていませんでした（出ない理由は確かめていません）。

セキュリティの既定値群をどうするか

条件付きアクセスとセキュリティの既定値群は組み合わせて使えません（条件付きアクセスの展開を計画する）。既定値群がオンのまま［新しいポリシー］を開くと、画面の下に「組織のセキュリティ構成を管理しようとしているようです。条件付きアクセス ポリシーを有効にする前に、まずセキュリティの既定値群を無効にする必要があります。」と出ていました。

既定値群を置き換える条件付きアクセスのポリシーを使うなら、既定値群を無効にし、無効にした後は直ちにポリシーを有効にします（セキュリティの既定値群）。無効にしてからオンにするまでの間は守りが空きます。ポリシーを先に用意しておき、切り替えの日に間を空けずに進める順番は、多要素認証の記事の「締め出されない切り替えの順番」に書きました。

どこで、だれが作るか

ポリシーは Entra 管理センターの［Entra ID］>［条件付きアクセス］で作ります。Intune 管理センターにも条件付きアクセスの画面がありますが、中身は Entra ID のものと同じなので、切り替える必要はありません（Intune と条件付きアクセス）。Intune が加えるのは、端末が会社の決まりを満たしているか（準拠）などの情報を、条件付きアクセスの判断に使えるようにすることです。

作れるのは、グローバル管理者・条件付きアクセス管理者・セキュリティ管理者のどれかのロールを持つ人です。［ポリシー］を開いた直後はボタンが灰色で、当社が見たときは、押すと「ポリシーを作成するには、グローバル管理者、条件付きアクセス管理者、またはセキュリティ管理者のいずれかのロールが必要です。」と出ました。ページを読み込み直すと押せるようになりました。

作る前に、今どのアプリに条件付きアクセスが当たっていないかを見ておけます。［概要］の［カバレッジ］タブには、過去7日間に条件付きアクセスが当たっていないアプリが、当たっていない人の割合とともに並びます。

この記事に関連するサービス

M365・Google Workspace の移行と設定の相談移行と設定を、1件から相談できます。詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →Google Workspace 導入・移行支援Gmail移行から権限設計・Gemini活用まで詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Notion 導入支援議事録・ナレッジ・タスクを一箇所にまとめる詳しく見る →

ポリシーは「誰が・何に・どんな時に → どうするか」の1文

条件付きアクセスのポリシーは、「割り当て」と「アクセス制御」でできた if-then の文です（条件付きアクセス ポリシーの構築）。割り当てが「誰が・何に・どんな時に」、アクセス制御が「どうするか」です。最低限、名前、ポリシーを当てるユーザー、ターゲット リソース、許可かブロックのどちらか、の4つがあれば1本のポリシーになります。

1本のポリシーの中の割り当ては「かつ」で結ばれます。たとえば［ユーザー］で営業部のグループを、［条件］でスマートフォンを選べば、「営業部の人が、スマートフォンから入るとき」だけに当たります。1つのサインインに複数のポリシーが当たったときは、当たったポリシーをすべて満たす必要があります。決めなかった条件は、その条件では絞らないという意味です。たとえば［クライアント アプリ］を決めなければ、すべての種類のクライアント アプリに当たります。

［ユーザー］には［対象］と［対象外］のタブがあり、両方に入った人は対象外が優先されます（条件付きアクセス ポリシーのユーザーとグループ）。対象外に人を入れると、その人はそのポリシーでは守られません。［対象］で「すべてのユーザー」を選ぶと、ゲストを含むディレクトリの全員が対象になり、画面には次の警告が出ました。

［ターゲット リソース］で「すべてのリソース」を選んだときも、「このポリシーは Azure portal に影響します。続行する前に、自分または他のユーザーがポータルに戻れることをご確認ください。」と警告が出ます。画面では、この選択肢に「以前の ‘すべてのクラウド アプリ’」と添えてあり、Learn の古い説明の「クラウド アプリ」と同じものです。同じ管理センターでも、What If の入力欄やテンプレートの［レビューと作成］には「クラウド アプリ」の言い方が残っていました。

ターゲット リソースに選べるのは、アプリだけではありません。セキュリティ情報の登録のような利用者の操作や、認証コンテキストも対象にできます（ターゲット リソース）。この操作は、画面では「ユーザー操作」、Learn の手順では「ユーザー アクション」と書かれています。画面では、［ターゲット リソース］の「このポリシーが適用される対象を選択する」で「リソース (以前のクラウド アプリ)」「ユーザー操作」「認証コンテキスト」を切り替えます。「ユーザー操作」を選ぶと、「セキュリティ情報の登録」と「デバイスの登録または参加」が出ました。

［許可］では、「アクセスのブロック」か「アクセス権の付与」を選び、付与なら求めるものにチェックを入れます。複数にチェックを入れたときは、すべてを求めるか、どれか1つでよいかを選びます。初めの値は「選択したコントロールすべてが必要」でした。ブロックは強力なので、使い方を知ってから使います。最初の数本でブロックを使うのは、レガシ認証のブロックだけです。

［ネットワーク］の画面には、「’場所’ 条件が移行されます。場所は ‘ネットワーク’ 割り当てになり」で始まる案内が出ていました。同じ作成画面の［条件］の中にも「場所」が残っていました。Learn で「場所」と書かれている条件は、この2か所のどちらかで探します。会社の IP アドレスや国で分ける作り方は、この記事では扱いません。IP の範囲や国の指定（ネームド ロケーション）と、出張する人の扱いは、条件付きアクセスで社外・海外からのサインインを制限する記事に書いています。

ポリシーの名前は、開かずに中身が分かるように付けます。たとえば、番号、対象のアプリ、どうするか、誰に、いつ、を名前に入れます。番号は、会話でポリシーを指すときに役立ちます。なお、ポリシーは1つのテナントに240個までです。

最初に作るポリシーは、テンプレートから

最初の数本は、欄を1つずつ埋めるより、テンプレートから作るほうが確かです。［新しいポリシーをテンプレートから］を開くと、カテゴリごとにテンプレートが並びます。Microsoft は、基盤のカテゴリのテンプレートを、どの組織にもベースとして勧め、まとめて展開するよう案内しています（条件付きアクセス テンプレート）。どの順で作るかは、下に当社の案として並べています。

画面と Learn ではカテゴリの呼び方が違います。画面の「安全な基盤」「リモート ワーク」「新しい脅威」は、Learn では「セキュリティで保護された基盤」「リモート作業」「新たな脅威」です。Learn にある「AI エージェント」のカテゴリは、画面には出ていませんでした。テンプレートの名前も、画面の「セキュリティ情報登録の保護」は Learn では「セキュリティ情報登録のセキュリティ確保」です。

作る順番は、公式の展開計画とテンプレートの「安全な基盤」をもとに、当社が次のように並べてみました。多要素認証の抜け道になる古い方式を先にふさぎ、管理者から全員へ広げる案です。

展開計画も、まず基本の制御を整えて多要素認証の適用に備え、次にすべてのユーザーとゲストに多要素認証を求め、その後に高度な保護へ進む、という段階です（条件付きアクセスの展開を計画する）。最初の段階（展開計画の目安では第1〜2週）には、レガシ認証のブロックと多要素認証の登録のページを守るポリシーに加えて、管理者にフィッシングに強い方法を求めるポリシーが入っています。管理者がパスキーなどをすでに登録しているなら、2番目はテンプレートの「フィッシングに強い多要素認証を管理者に要求する」で作ります。レガシ認証のブロックを先に置くのは、IMAP・POP3・SMTP のような古い方式は多要素認証に対応せず、全員に多要素認証を求めても、その道が開いたままになるからです。止まる機器やソフトの洗い出し方（「止まりうるもの」の表）と、4番目の全員の多要素認証の細かい作り方は、多要素認証（MFA）を全員に有効にする記事に書いています。

何に当てるか・どんな時に当てるかは、テンプレートごとに違います。ポリシーごとの手順では、レガシ認証のブロックは、すべてのリソースを対象に［条件］の［クライアント アプリ］で Exchange ActiveSync クライアントとその他のクライアントに絞ってブロックします。Azure 管理の多要素認証は、リソースの選択で「Windows Azure Service Management API」だけを選びます。セキュリティ情報登録の保護は、アプリではなくユーザー操作の「セキュリティ情報の登録」に当て、信頼できる場所を外します。画面で「セキュリティ情報登録の保護」の［レビューと作成］を開くと、［クラウド アプリまたは操作］はユーザー操作の「セキュリティ情報の登録」、［場所］は「すべての場所」を含めて「すべての信頼できる場所」を除外する形で、Learn の手順と同じでした。違ったのは除外で、「すべてのゲストと外部ユーザー」と「現在のユーザー」に加えて、［除外されたロール］に「グローバル管理者」が入っていました（Learn の手順のページには、この除外はありません）。作ったら、除外が自社の決め方に合うかを見直します。また、Azure 管理のテンプレートの対象のアプリは、画面では「Microsoft Azure 管理」と出ました。手で同じものを作るときは、上の欄の表をそのまま写さず、ポリシーごとの手順に合わせます。

端末の準拠を求めるポリシーは、端末を Intune に登録して準拠の状態が出てから作ります。Business Premium での順番はBusiness Premium の最初の設定の記事で、端末の登録はIntune の記事で書いています。なお、準拠を求めるポリシーをレポート専用にしているときでも、macOS・iOS・Android の利用者に端末の証明書を選ぶ画面が出ることがあります。避けるには、レポート専用の間はそのポリシーからこの3つのプラットフォームを外します。

テンプレートから作ると、作った人が対象外に入る

テンプレートを選んで［レビューと作成］を開くと、作られるポリシーの中身が出ます。「管理者に多要素認証を要求する」では、ポリシーの状態の初めの値が「レポート専用」、除外されたユーザーが「現在のユーザー」、対象はグローバル管理者・セキュリティ管理者などの管理者のロールでした（［作成］は押していません）。

ユーザーを対象とするテンプレートでは、ポリシーを作っている人だけが除外される作りで、ほかのアカウントを除外するなら、作った後にポリシーを直します。当社が［レビューと作成］を開いた4つ（「管理者に多要素認証を要求する」「レガシ認証をブロックする」「Azure 管理に多要素認証を要求する」「セキュリティ情報登録の保護」）でも、どれも除外されたユーザーに「現在のユーザー」が入り、緊急用アカウントは入っていませんでした（「セキュリティ情報登録の保護」には、上に書いたほかの除外もありました）。「すべてのユーザーに多要素認証を要求する」は説明を見ただけで、［レビューと作成］は開いていません。作ったら各ポリシーを開き、対象外の「現在のユーザー」を、次の節の緊急用アカウントのグループに入れ替えます。一方、［新しいポリシー］の作成画面の［対象外］には、何も入っていませんでした（保存する前の画面で見ました）。手で作るときは、対象外を自分で決めます。

テンプレートの下には「JSON ファイルのダウンロード」もあり、中身を JSON で保存しておけます。リスクを使うテンプレート（危険なサインインに多要素認証を求める、など）は Entra ID P2 が要るため、上の順番には入れていません。

締め出されないために守る4つの決まり

条件付きアクセスでいちばん避けたいのは、ポリシーを誤って、管理者を含めて誰も入れなくなることです。それを防ぐために、どのポリシーにも当てる決まりを4つにまとめました。前の節のテンプレートの「現在のユーザー」の入れ替えは、1つ目に含めています。

緊急用アカウントのグループを対象外にする

緊急用アカウント（Learn では緊急アクセス アカウント、ブレークグラス アカウント）は、ポリシーの誤りで管理者が入れなくなったときに戻るためのアカウントです。2つ以上作り、ふだんの管理者とは違う強い認証方法を使うことが勧められています（緊急アクセス用管理者アカウントを管理する）。ポリシーからは、人を1人ずつ外すのではなく、緊急用アカウントだけを入れた専用のセキュリティ グループを作り、そのグループを外します。グループにしておけば、緊急用アカウントを足したり替えたりしても、各ポリシーの対象外を1本ずつ直さずに済みます。作り方の細部は多要素認証の記事に書いています。

緊急用アカウントのほかに、Microsoft Entra Connect の同期アカウントのようなサービス アカウントもポリシーから外します（すべてのユーザーに多要素認証を要求する手順 など）。レポート専用のポリシーはサインインを止めないため、緊急用アカウントを外さなくてもよいとされています。ただ、後でオンにするときに外し忘れないよう、作った時点で外しておきます。Learn は、緊急用アカウントで入れることを少なくとも90日ごとに確かめるよう勧めています。

「すべてのユーザー」と「すべてのリソース」に、止める条件を重ねない

すべてのユーザー・すべてのリソースを対象にしたポリシーで、次の組み合わせは、トラブルシューティングのページで「使用しないでください」とされています（条件付きアクセスのサインインの問題のトラブルシューティング）。

端末の準拠を求めるポリシーは全員に当てたくなりますが、端末を登録していない管理者は、ポリシーを直すために入り直すこともできなくなります。全員に広げる前に、まず数人のグループで試します。実際の利用者に広げる前に、管理者ではないテスト用のユーザーや試験的なグループで動きを確かめておきます。

レポート専用で少なくとも1週間見る

ポリシーの有効化を「レポート専用」にしたポリシーは、サインインのたびに評価だけされ、ブロックも多要素認証の要求も起きません。結果は、サインイン ログの各サインインの［条件付きアクセス］タブと［レポート専用］タブに残ります（レポート専用モード）。Learn は、適用する前に少なくとも1週間、各ポリシーをレポート専用で動かすよう勧めています。結果が「レポートのみ: ユーザー アクションが必要」の人は、オンにすると多要素認証などを求められる人です（この表示名の「ユーザー アクション」は、許可の条件を満たすのに利用者の操作が要る、という意味で、上に書いたターゲット リソースのユーザー操作とは別のものです）。ただし Learn のレポート専用モードのページは、ユーザー操作（Learn ではユーザー アクション）を対象にしたポリシーを、レポート専用の評価から除いています。セキュリティ情報登録の保護はこれに当たり、1週間見ても記録が出ないことがあります（当社では確かめていません）。記録が無いことを、当たる人がいないと受け取らないでください。Learn のセキュリティ情報登録の保護の手順のほうは、適用を始める前にレポート専用でテストするよう書いていて、2つのページの書き方はそろっていません。結果の読み方の細部は、ここでは扱いません。既定値群がオンの間にこの記録が残るかは、当社では確かめていません。記録が出ないときの進め方は、多要素認証の記事に書いています。

［新しいポリシー］の［ポリシーの有効化］でも、テンプレートの［レビューと作成］の［ポリシーの状態］でも、初めの値は「レポート専用」でした。Learn の手順には「レポートのみ」と書かれた箇所もありますが、同じものです。

オンにする前に What If で試し、オンの直後に緊急用アカウントで確かめる

What If は、特定の人が特定の条件でサインインしたときに、どのポリシーが当たり、どれが当たらないかを試す道具です。［ポリシー］の上の［What If］から開きます（画面の幅が狭いと［…］の中に入っていました）。入力が必須なのは、ID、ターゲット リソース、デバイス プラットフォーム、クライアント アプリの4つです（What If ツール）。画面では、ID は［ID の種類の選択］で［ユーザー］を選び、ターゲット リソースは［ターゲットの種類の選択］が「クラウド アプリ」になっていました。IP アドレスや国も入れられます。

評価に入るのは「オン」か「レポート専用」のポリシーだけで、当たらなかったポリシーには、満たさなかった最初の条件が理由として出ます。また、What If はサービスどうしの依存関係までは試しません。たとえば Teams を選んで試しても、Teams が裏で使う Exchange Online に当たるポリシーは結果に入りません。経営者、経理、管理者など、止まると仕事が止まる人のサインインを一通り試してからオンにし、オンにした直後に、別のブラウザーで緊急用アカウントで入れるかを確かめます。社員には、いつから何が変わるか、困ったら誰に連絡するかを先に知らせておきます。

「入れない」と言われたとき、締め出されたとき

オンにした後に困るのは、社員の一部が入れない場合と、管理者も含めて入れない場合の2つです。戻し方が違います。

社員から「入れない」と言われたら、Entra 管理センターの［サインイン ログ］でその人のサインインを開き、［条件付きアクセス］タブを見ます。止めたポリシーがそこに出ます。エラー コードは止まった理由ごとに違い、ブロックで止まったときは 53003（条件付きアクセスによりブロックされています）、端末が準拠していないときは 53000（デバイスが準拠していない）のように分かれます（Learn のトラブルシューティングのページの「条件付きアクセスの一般的なエラー コード」）。急ぐなら、そのポリシーを「オフ」にすれば、次のサインインから当たらなくなります。人を対象外に足すこともできますが、信頼できる人に限って慎重に使い、できるだけ早く元に戻します。機種変更や紛失で認証できない人は、対象外ではなく多要素認証のリセットと再登録で戻します。

管理者も入れなくなったときは、まず、ほかの管理者が入れるかを確かめます。入れる管理者がいれば、そのポリシーを無効にできます。緊急用アカウントを対象外にしてあれば、それで入って直します。組織の中の誰もポリシーを直せない場合は、Microsoft にサポート リクエストを出します。Microsoft のトラブルシューティングのページでは、Microsoft が確認したうえで、アクセスを妨げているポリシーを更新するとされています。誤って消したポリシーは、Learn によれば30日以内なら復元できます。画面の左のメニューにも［削除されたポリシー］がありますが、戻す操作は当社では試していません。

次にやること

まず、緊急用アカウントを2つ作り、それだけを入れたグループを用意してください。次に［新しいポリシーをテンプレートから］の「安全な基盤」から、レガシ認証のブロックと管理者の多要素認証を作り、対象外をそのグループに入れ替えて、レポート専用のまま1週間見ます。既定値群がオンのままの会社は、多要素認証の記事の切り替えの順番に沿って進めてください。導入の全体の中でいつ設定するかはMicrosoft 365 導入の手順の記事で書いています。

ポリシーの並べ方や、オンにする日の段取りから一緒に決めたい場合は、Microsoft 365 の導入支援でお手伝いしています。

この記事の確かめ方

公式の説明は、2026年10月29日に Microsoft Learn で確かめました（Entra ID P2 が含まれるプランは、日本語版の訳が崩れていたため英語版で確かめています）。締め出されないために守る4つの決まりは、Learn の展開計画とトラブルシューティングのページをもとに当社がまとめたものです。画面は、当社の検証用の環境（Business Premium）で2026年10月29日に開いたものです。ポリシーは作っておらず、テンプレートは［レビューと作成］で中身を見るところまでで、［作成］は押していません。写真のユーザー数の列は伏せています。

画面の名前は Learn と違うところがあります。たとえば Azure 管理の対象は、テンプレートの［レビューと作成］では「Microsoft Azure 管理」、Learn の手順では「Windows Azure Service Management API」でした。Entra 管理センターの画面は更新が続いているため、設定の前に各ページの最新を確かめてください。