条件付きアクセスのポリシープランとは｜共有条件で除外漏れとポリシーの乱立を防ぐ

Microsoft Entra の条件付きアクセスに、関連するポリシーを1つの「プラン」にまとめ、対象者や緊急用アカウントの除外を1か所で管理できる仕組み（プレビュー）が加わりました。

ポリシープランは、共通の対象と除外をプランに1回だけ書き、場面ごとの違いだけを「ルール」に書く仕組みです。使うのに必要なのは条件付きアクセスと同じライセンスと条件付きアクセス管理者のロールで、既存のポリシーはそのまま動きます。ただし、既存のポリシーとプランのルールは両方とも評価され、優先順位はありません。

同じ内容をプランに作り直しただけでは、古いポリシーの除外漏れはそのまま残ります。また、プレビューの間は、場所を条件にしたプランの判定がすぐには見直されないという注意書きもあります。

この記事では、Microsoft Learn の公開情報をもとに、ポリシープランの仕組み、共有条件とルールの組み合わさり方、作り方と段階的な有効化、プレビュー期間に気をつけることを解説します。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

条件付きアクセスのポリシープランとは

ポリシープランは、関連する複数の「ルール」を、共通の対象と条件（共有条件）の下にまとめる仕組みです。Learn は、準拠デバイスの要求や、AIエージェントの活動の保護のように、1つのセキュリティ上の目的ごとにプランを作る使い方を示しています。

従来の条件付きアクセスは、1本のポリシーの中に、対象者・対象のアプリ・条件・制御をすべて書く形でした。同じ対象者や同じ除外を持つポリシーが何本あっても、それぞれに同じ設定を書く必要があります。プランでは、共通の部分をプランに1回だけ書き、ルールには場面ごとに違う部分だけを書きます。

項目	従来のポリシー	ポリシープランとルール
対象の指定	ポリシーごとに指定し、ポリシーをまたいで同じ指定を繰り返す	共有条件としてプランに1回だけ書き、すべてのルールが引き継ぐ。ルールごとにも指定できる
変更の手間	ポリシーを1本ずつ直す	プランの共有条件を1回直せば、すべてのルールに反映される
テンプレート	1つのテンプレートから1本のポリシーを作る	複数のテンプレートを1つのプランにまとめるか、テンプレートごとにプランを作る

プランは、Microsoft Entra 管理センターの「Entra ID」→「条件付きアクセス」→「Policy plans (Preview)」から作ります。ライセンスは条件付きアクセスと同じで、Microsoft Entra ID P1 または Microsoft 365 Business Premium です。プランの作成・変更・削除には、条件付きアクセス管理者のロールが必要です。

既存のポリシーは作り直す必要があるのか

作り直す必要はありません。Learn は、プランは既存の条件付きアクセスへの「追加」であって置き換えではなく、既存のポリシーは変更なしでこれまでどおり動くと明記しています。

既存のポリシーとプランのルールは、両方とも効く

サインインのとき、条件付きアクセスは既存のポリシーとプランのルールの両方を評価します。該当するポリシーとルールのすべてを満たさなければアクセスは許可されず、両者の間に優先順位や相互の作用はありません。それぞれが独立に積み上がります。

このため、既存のポリシーと同じ内容のルールをプランに作っただけでは、同じ制御が二重にかかるだけです。たとえば、プランの共有条件に緊急用アカウントの除外を入れても、除外の漏れた古いポリシーが有効なまま残っていれば、緊急用アカウントはそちらで締め出されます。

既存のポリシーをプランへ移すときの順番

既存のポリシーをプランへ移すなら、古いポリシーを止めるところまでが作業です。弊社は、次の順番で進めることをお勧めしています。

1. 移す先のルールを、レポート専用の状態で作る
2. サインインログで、古いポリシーと同じ判定になっているかを確かめる
3. ルールをオンにしたら、対応する古いポリシーをオフにする
4. 古いポリシーはすぐに削除せず、しばらくオフのまま残して戻せるようにしておく

なお、ポリシープランはプレビューの機能です。管理者への多要素認証のような要となる制御をすぐに載せ替える必要はありません。新しく作る目的のポリシーからプランで作り始め、既存のポリシーは一般提供を待って移す進め方も選べます。

プランを構成する3つの要素

Learn によると、プランは次の3つでできています。プランには、少なくとも1つのルールが必要です。

• プランの詳細：名前、説明、任意のタグ、所有者（個人またはグループ）
• 共有条件：すべてのルールに当てはまる対象と除外、条件（任意）
• ルール：場面ごとの対象と条件に加え、許可の制御とセッションの制御

プランの詳細は、チームがそのプランの目的と責任者、変更したときの影響の範囲を把握するための情報です。実行時の判定には影響しません。所有者の欄も記録のためのもので、所有者に指定しても編集の権限は与えられません。プランを作った人は、自動で所有者に入ります。

共有条件に書けるもの

共有条件には、従来のポリシーで指定してきた対象と条件のほとんどを書けます。Learn が挙げているのは次のとおりです。

• 対象のID（ユーザー、エージェント、ワークロードID）の指定と除外
• アプリなどのリソース、ユーザーの操作、認証コンテキスト
• リスクのレベル、デバイスのプラットフォーム、ネットワークの場所、クライアントアプリの種類

共有条件とルールの組み合わさり方

Learn は、共有条件とルールの条件は「足し算」で組み合わさると説明しています。押さえておく決まりは次の3つです。

• プランの対象は、すべてのルールに引き継がれる：プランがグループAを対象にしていれば、どのルールもグループAが前提になる。ルールでこの対象を狭めることはできないが、ルール独自の除外は足せる
• 除外は積み上がり、プランの除外は外せない：プランで緊急用のグループAとBを除外し、ルールでグループCを除外すると、実際の除外はA・B・Cになる。プランの除外を、ルールが上書きしたり外したりすることはできない
• プランの対象に、IDの種類を混ぜられない：ユーザーを対象にしたプランは、プランの段階でエージェントを対象にできない。種類をまたぐなら、IDの指定はプランに書かず、ルールに任せる

2つ目の決まりは、除外漏れを防ぐための設計です。緊急用アカウントのように、どのルールからも必ず外したいものはプランに書いておけば、ルールを足すたびに除外を書き忘れる心配がなくなります。裏を返すと、プランに書いた除外は全ルールに効くので、一部のルールだけで外したい人をプランに入れてはいけません。

「すべてのユーザー」と「すべてのリソース」はルールの側で選ぶ

「すべてのユーザー（All users）」と「すべてのリソース（All resources）」は、プランの共有条件では選べず、ルールの側でだけ選べます。全社員を対象にするプランを作るなら、ユーザーの指定はルールに書くことになります。

その場合も、共有条件には除外だけを書いておけば、緊急用アカウントの除外はすべてのルールに行き渡ります。Learn の手順も、共有条件には「すべてのルールに当てはまるものだけ」を入れ、場面ごとに変わるものはルールに書くよう求めています。

プランが効く4つの場面

Learn は、プランを使う理由として次の4つの場面を挙げています。

OSごとに分けたポリシーをまとめる

Windows・macOS・iOS・Android で求める設定が違うと、OSごとに別のポリシーを作ることになります。それらのポリシーは、同じ対象者と同じ緊急用アカウントの除外を繰り返し持っています。プランにすれば、共通の対象者と除外はプランに1回だけ書き、ルールにはOSごとの違いだけを書けます。

緊急用アカウントとサービスアカウントの除外漏れを防ぐ

緊急用アカウント、信頼できるサービスアカウント、特権用の端末は、多くのポリシーの除外リストに登場します。Learn は、除外の漏れが意図しない締め出しのよくある原因だと書いています。プランの除外はルールから外せないので、ルールを足すときの書き忘れが起きません。

なお、サービスプリンシパルからの呼び出しは、ユーザーを対象にしたポリシーでは止まりません。サービスプリンシパルを対象にするには、ワークロードID向けの条件付きアクセスを使います。

Global Secure Access のネットワーク単位のルールを管理する

Global Secure Access を導入した組織では、同じ利用者と同じアプリを対象にした、ネットワークの範囲ごとのルールが数百本に及ぶことがあります。プランなら、共通の対象はプランに1回だけ書き、各ルールは自分が受け持つネットワークの範囲だけを書けばよくなります。

AIエージェントの活動に、同じ制御をかける

エージェントのIDは、自分の権限で動く場合と、ユーザーの代わりにユーザーの権限で動く場合があります。プランでは「エージェントのリスクが高い」という共有条件を1つ置き、エージェントのユーザーと、自律的に動くエージェントを別々のルールで守れます。エージェントのIDと権限の考え方は、AIエージェントに「権限」をどう与え、統制するかで解説しています。

作り方と段階的な有効化

プランは、組み込みのテンプレートから作る方法と、一から作る方法があります。どちらも、作る前にプランの目的を1つに決めておくことが前提です。Learn は、目的の例として、特定の場所で働く社員の保護、エージェントの活動の保護、準拠デバイスの要求を挙げています。

テンプレートから作る

テンプレートには、よくある場面向けの共有条件とルールがあらかじめ入っており、エージェントの活動を守るためのものも含まれます。プランと共有条件、ルールが1回の流れで作られます。

1. 「Policy plans (Preview)」で「Create policy from template」を選ぶ
2. 使うテンプレートを1つ以上選んで「Create plan」を選ぶ
3. 共有条件にあらかじめ入っている対象を確かめ、「Create policy plan」を選ぶ
4. 「Edit plan」から、共有条件の除外に緊急用アカウントとサービスアカウントを加える
5. ルールの内容を確かめ、状態を「オフ」から「レポート専用」に変える
6. 影響を確かめてから、状態を「オン」にする

テンプレートから作ったルールは、組織への意図しない影響を避けるため、すべて「オフ」の状態で作られます。作っただけでは何も効かないので、レポート専用を経てオンにするところまでを1つの作業として計画します。

一から作る

テンプレートに合う場面がないときや、共有条件とルールを最初から自分で決めたいときは、一から作ります。

1. 「Create policy」を選び、プランの名前と、必要なら説明・タグ・所有者を入れる
2. 共有条件に、すべてのルールに共通の対象・除外・条件を入れる（任意）
3. 最初のルールを作る。状態は「レポート専用」にし、ルール固有の対象と条件、許可とセッションの制御を設定する
4. 場面ごとにルールを足していく

レポート専用の結果は、ルールごとに確かめる

サインインのとき、各ルールは共有条件と組み合わせた対象で、単独のポリシーと同じように独立して判定されます。サインインログにもルールごとに1件ずつ記録されるので、レポート専用の結果はルール単位で確かめられます。Learn は、組み込みの影響の指標か、サインインログで影響を確かめてから、ルールをオンにするよう案内しています。

プレビュー期間に気をつけること

場所を条件にしたプランは、判定の見直しがすぐには行われない

Learn は、プレビューの間、ユーザーを対象にして場所を条件にしたプランでは、有効期間1時間のアクセストークンが発行され、IPアドレスによる即時の確認は行われないと注記しています。継続的アクセス評価に対応したアプリで、場所の条件をトークンの期限を待たずに評価し直す動きが、プランでは効かないということです。

許可していない場所からの利用を止めることが要となる制御は、当面は既存のポリシーで持ち続けるのが安全です。プランで場所を扱うのは、この注記が外れてからにすることを弊社はお勧めしています。

プレビューの利用条件で提供される

ポリシープランは、Microsoft Azure プレビューの追加使用条件のもとで提供されており、一般提供の機能のすべてを備えていない場合があります。一般提供までに画面や仕様が変わることも想定し、プランで作ったルールの内容は、手順書や設定の一覧として控えておきます。

弊社の支援

弊社は、Microsoft 365 と Microsoft Entra ID の導入から、条件付きアクセスの設計・段階的な展開までを支援しています。条件付きアクセスは、設定を誤ると社員や管理者がサインインできなくなる領域です。そのため、緊急用アカウントの用意と除外、レポート専用での確認、切り戻しの手順を、ポリシーの中身と同じ重さで扱っています。

ポリシープランについても、既存のポリシーの棚卸しから、どれをプランにまとめ、どれを既存のまま残すかの判断、移行の順番までをご一緒に整理します。ゼロトラストの全体像は、ゼロトラストとはもあわせてご覧ください。

よくあるご質問

こちらをクリックして「よくある質問」を表示

ポリシープランを使うのに、追加のライセンスは必要ですか？

条件付きアクセスと同じで、Microsoft Entra ID P1 または Microsoft 365 Business Premium があれば使えます。ただし、サインインのリスクやユーザーのリスクを条件にする場合は Microsoft Entra ID P2 が、サービスプリンシパルを対象にする場合は Microsoft Entra Workload ID のライセンスが必要です。

既存の条件付きアクセスのポリシーは、そのまま動きますか？

そのまま動きます。プランは既存のポリシーへの追加で、変更は要りません。ただし、既存のポリシーとプランのルールは両方とも評価され、該当するすべてを満たさないとアクセスは許可されません。同じ内容をプランに作ったら、古いポリシーをオフにするところまで行います。

プランで設定した除外を、特定のルールだけで外せますか？

外せません。プランの除外はすべてのルールに効き、ルールから上書きしたり外したりはできません。一部のルールだけで除外したい人は、プランではなく、そのルールの除外に入れます。ルールの側で足した除外は、プランの除外に積み上がります。

プランの所有者に指定すれば、その人がプランを編集できますか？

編集はできません。所有者の欄は、誰がそのプランに責任を持つかを記録するためのもので、権限は与えません。プランの作成・変更・削除には、条件付きアクセス管理者のロールが必要です。

ユーザーとAIエージェントを、1つのプランで扱えますか？

扱えます。ただし、プランの共有条件ではIDの種類を混ぜられないため、IDの指定はプランに書かず、ルールに任せます。たとえば、1つ目のルールでユーザーを、2つ目のルールでエージェントを対象にします。

テンプレートから作ったルールは、すぐに有効になりますか？

有効になりません。テンプレートから作ったルールは、意図しない影響を避けるため、すべて「オフ」の状態で作られます。状態を「レポート専用」に変えてサインインログで影響を確かめ、問題がなければ「オン」にします。

条件付きアクセスは、ポリシーが増えるほど、除外の漏れや重複に気づきにくくなります。現在のポリシーの一覧や運用の悩みをお聞かせいただければ、棚卸しからポリシープランの使いどころ、段階的な展開の手順まで、ご提案します。お問い合わせよりお気軽にご相談ください。

関連サービス・関連コラム

• セキュリティ強化支援（ゼロトラスト）｜Microsoft 365・Azureでゼロトラストを実現
• Microsoft 365導入支援｜EntraID・Purview活用・セキュリティ強化
• ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ
• AIエージェントに「権限」をどう与え、統制するか｜Entra Agent IDとCopilot Studioの権限モデル
• Purviewの保護ポリシーにEntra ID条件付きアクセス＋MDCAを組み合わせたファイルの持ち出し制御

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。