Microsoft Entra 条件付きアクセスの「ポリシープラン」解説（プレビュー）
Microsoft Entra の条件付きアクセスに、関連する制御を「目的」単位で束ねる新しいオブジェクト「ポリシープラン（Policy plans）」がパブリックプレビューで追加された。対象ユーザーや緊急アクセス用アカウントの除外をプランに1回だけ定義し、個別の制御は「ルール」として継承させる仕組みである。
本記事は Microsoft Mechanics の解説動画「New Conditional Access policy plans in Microsoft Entra」の内容に、Microsoft Learn の公式ドキュメント（2026年10月26日更新版）と検証記事の情報を加えて整理したものである。要点は次の3つ。
- 既存ポリシーの置き換えではなく追加：既存ポリシーとプランのルールは並行して評価され、該当するものすべてを満たしたときだけアクセスが許可される。
- 継承は一方向：プランで設定した対象と除外はルール側で狭めたり外したりできない。緊急アクセス用アカウントの除外漏れを構造的に防げる。
- 移行ウィザードは複製を作る：元のポリシーは残り、生成されたルールは「オフ」で始まる。切り替えは「ルールをオン → 元ポリシーをオフ」の順で行う。
従来の条件付きアクセスの課題
従来の条件付きアクセスは、ポリシーが1本ずつ独立したフラットな一覧で管理される。運用が進むと次の問題が表面化する。
- ポリシーの乱立：Windows・macOS・iOS・Android などプラットフォームごとに設定が異なれば、同じユーザー対象を持つポリシーが複数本できる。共通の対象を変更するときは、全ポリシーを個別に編集する必要がある。
- 除外設定の重複：緊急アクセス用（ブレークグラス）アカウントやサービスアカウントの除外を、各ポリシーに繰り返し設定する。除外の入れ忘れは、意図しないロックアウトの典型的な原因になる。
- 関係性と所有者が見えない：どのポリシーが同じ目的に属し、誰が責任を持つかは命名規則で表現するしかなかった。変更時の影響範囲の把握が難しい。
- 上限への接近：条件付きアクセスには状態を問わず1テナントあたり240ポリシーという上限がある。Global Secure Access を導入すると、同じユーザーとアプリを対象にネットワーク範囲ごとのルールが数百本必要になることがあり、ポリシー数はさらに膨らみやすい。
ポリシープランは、この「共通部分の重複」をプラン側に寄せて一元管理するための仕組みである。
ポリシープランの構成
ポリシープランは「プラン詳細」「共有条件」「ルール」の3つで構成される。実際にアクセスを制御するのはルールであり、プランはその共通部分を担う。
共有条件に置いた対象と除外は2つのルールにそのまま届き、各ルールは許可コントロールだけを持つ。
| 構成要素 | 保持する内容 | 実行時の役割 |
|---|---|---|
| プラン詳細 | 名前、説明、タグ、所有者（個人またはグループ） | なし。所有者は責任の所在を示すだけで、編集権限は付与しない |
| 共有条件（任意） | 対象IDの包含・除外、アプリ・ユーザー操作・認証コンテキスト、リスクレベル、デバイスプラットフォーム、ネットワークの場所、クライアントアプリの種類 | 全ルールに継承される |
| ルール（1つ以上必須） | シナリオ固有の割り当て・条件、許可コントロール、セッションコントロール、状態（オフ／レポートのみ／オン） | それぞれ独立したポリシーとして評価される |
ルールは「プランの共有条件を継承する通常の条件付きアクセスポリシー」と捉えると正確である。許可コントロールとセッションコントロールはルールにしか存在しない。
動画のデモでは、本社ユーザー向けのプランを次のように組んでいる。
- プラン詳細：名前・説明・タグ「HQ」・所有者
- 共有条件：本社ユーザーグループを包含、ブレークグラス用グループを除外
- ルール1：フィッシング耐性のある多要素認証（MFA）を要求（レポートのみモードで開始）
- ルール2：「準拠済み」と判定されたデバイスを要求
2つのルールとも、対象グループと除外はプランから自動で引き継ぐため、ルールごとに再設定しない。
共有条件とルールの継承規則
共有条件とルールの条件は加算的に組み合わされ、ルールがプランの設定を打ち消すことはできない。具体的な規則は次のとおり。
- 対象は継承され、狭められない：プランがグループAを対象にすると、全ルールがグループAを対象にする。ルールは独自の除外を追加できるが、対象をプランより狭めることはできない。継承した項目はルール編集画面でロックされる。
- 除外は積み上がる：プランがグループA・Bを除外し、ルールがグループCを除外すると、そのルールの実効的な除外はA・B・Cになる。プランで設定した除外をルールが削除することはできない。
- IDの種類は混在させない：プランレベルでユーザーとワークロードID（またはエージェント）を同時に対象にできない。両方を扱う場合は、プランではIDを指定せず、ルールごとに指定する。
プランレベルとルールレベルで設定できる項目の違いは次のとおり。
| 項目 | プラン（共有条件） | ルール |
|---|---|---|
| 「すべてのユーザー」 | 指定不可 | 指定可 |
| 「すべてのリソース」 | 指定不可 | 指定可 |
| 特定グループ・ユーザーの包含／除外 | 可 | 可（プランの対象は狭められない。除外は追加できる） |
| リスクレベル、デバイスプラットフォーム、場所、クライアントアプリ | 可 | 可 |
| 許可コントロール・セッションコントロール | 不可 | 可 |
多くの組織のベースラインポリシーは「すべてのユーザー」「すべてのリソース」を対象にしている。その場合、プランで共有できるのは実質的に「除外リスト」と「条件」だけになる。このときも、ブレークグラス用アカウントの除外をプランに置くことには十分な効果がある。
評価の仕組みと既存ポリシーとの関係
サインイン時、条件付きアクセスは各ルールの条件にプランの共有条件を結合して完全な対象範囲を作り、ルールを単体ポリシーと同じ方法で個別に評価する。サインインログにもルールごとに独立したエントリとして記録される。
既存ポリシーとプランのルールの間に優先順位や相互作用はない。両者は並行して評価され、該当するポリシーとルールをすべて満たした場合にのみアクセスが許可される。つまりプランは「制御の整理方法」を変えるものであり、「制御の適用方法」は変えない。既存ポリシーは変更なしでそのまま動作し続ける。
| 観点 | 従来のポリシー | ポリシープランとルール |
|---|---|---|
| 対象範囲の定義 | ポリシーごとに定義し、複数ポリシーで重複する | プランで1回定義して全ルールに継承、またはルールごとに定義 |
| 変更管理 | ポリシーを個別に更新 | 共有条件を1箇所変えれば全ルールに反映 |
| テンプレート | 1テンプレート＝1ポリシー | 複数テンプレートを1プランにまとめられる |
| 評価 | ポリシー単位 | ルール単位（共有条件を結合した状態で） |
エージェント保護への適用
動画では、ペルソナ単位だけでなく「エージェントのアクセス保護」というセキュリティ目標単位のプランも示されている。AI エージェントのIDには、自身の権限で動く自律型と、ユーザーの権限で代理して動く型がある。プランの共有条件に「エージェントリスク高」を置き、エージェントユーザー用と自律型エージェント用のブロックルールを分けて置くと、同じリスク条件を2本のポリシーに重複させずに済む。この構成はテンプレートからも作成できる。
作成手順
作成・変更・削除には「条件付きアクセス管理者」ロールが必要である。ライセンス要件について、公式ドキュメントは通常の条件付きアクセスの要件（Microsoft Entra ID P1 以上。リスクベースの条件は P2）を参照している。AdminDroid の解説記事によると、エージェントを対象にする場合は Microsoft Agent 365 または Microsoft 365 E7 のライセンスも必要になる。作成前にプランのセキュリティ目標を決め、「全シナリオに共通するものだけを共有条件に、差分はルールに」という分け方を先に整理しておく。
テンプレートから作成する
- Microsoft Entra 管理センターで Entra ID > 条件付きアクセス > Policy plans (Preview) を開く。
- Create policy from template を選び、1つ以上のテンプレートを選択して Create plan を実行する。
- 名前と事前入力された共有条件を確認してプランを作成する。テンプレートから生成されたルールはすべて「オフ」で始まる。
- Edit plan から、緊急アクセス用アカウントとサービスアカウントを共有条件の除外に追加する。
- 各ルールを確認し、状態を「レポートのみ」に変更する。サインインログで影響を確認したあと「オン」にする。
カスタムで作成する
- 同じ画面で Create policy を選び、名前・説明・タグ・所有者を入力する。作成者は自動的に所有者になる。
- 共有条件を設定する。対象IDの包含・除外、対象リソース、リスクレベル・デバイスプラットフォーム・場所・クライアントアプリの種類を必要な分だけ指定する。
- Continue で最初のルールを作成する。状態は「レポートのみ」を選び、ルール固有の対象・条件と、許可コントロール・セッションコントロールを設定する。全リソースを守る場合はここで「すべてのリソース」を選ぶ。
- シナリオの数だけルールを追加する。影響確認後に各ルールを「オン」にする。
ブレークグラス用アカウントとサービスアカウントの除外は、ルールではなく必ず共有条件に置く。プランで設定した除外は全ルールに強制されるため、後からルールを追加しても除外漏れが起きない。
既存ポリシーの移行と切り替え
移行ウィザードは既存ポリシーを「複製」してプランとルールに変換する。元のポリシーは変更されず、生成されたルールは「オフ」で作られるため、移行操作そのものが本番のアクセス制御を変えることはない。
グループ化の単位
どのポリシーを1つのプランにまとめるかは管理者が決める。ポータルは候補を提案しない。目安は次の3つ。
- 保護対象のリソースが同じポリシー
- 同じペルソナ（対象ユーザー）に異なる制御をかけているポリシー
- 場所やリスクレベルなど同じ条件を持つポリシー
動画では、支社ごとに作られた複数のポリシーを1つのプランに統合する例が示されている。ただし対象ユーザーが似ていても、「国単位のブロック」と「高リスクサインインのブロック」のように目的が異なるポリシーは分けておく。
移行の手順
- Entra ID > 条件付きアクセス > ポリシー を開き、「Migrate to Conditional Access Policy plans (Preview)」バナーの Get started を選ぶ。
- まとめるポリシーを選択し、Merge policies into a plan を実行する。
- プラン名を入力する。空欄のままだとすべて「Migrated policy plan」という同名になるため、必ず命名する。
- 共有条件とルールの内容を確認し、Create policy plan で作成する。
ウィザードが共通化する範囲
ウィザードは、選択した全ポリシーで完全に一致する設定だけを共有条件に移す。LazyAdmin による実機検証（Admin365.Blog でも紹介）では、ユーザー割り当てが共有条件に移るのは「割り当て全体が一致し、かつ包含が『すべてのユーザー』でない」場合に限られていた。
このため「すべてのユーザー」を対象にしたポリシーを移行すると、ブレークグラス用アカウントの除外も各ルールに残ったままになる。移行後に Edit plan から除外をプランの共有条件へ手動で追加する。ルールはプランの除外を継承するため、ルール側の除外を個別に消す必要はない。
検証と切り替えの順序
移行直後は元のポリシーが引き続き適用され、ルールは「オフ」の状態にある。切り替えは次の順で行う。
- ルールを「レポートのみ」にする（Edit all rules で一括変更できる）。
- 監視と正常性 > サインインログ で対象ユーザーのサインインを開き、「レポートのみ」タブで各ルールの結果と元ポリシーの結果を比較する。
- 結果が一致したら、ルールを「オン」にする。
- 元のポリシーを「オフ」にする。
- サインインログを再確認し、検証期間を経てから元のポリシーを削除する。
手順3と4は順序を入れ替えない。ルールを先にオンにすれば一時的に同じ制御が二重にかかるだけで実害はないが、逆にするとどちらも効いていない空白時間が生まれる。また、移行後のルールと元ポリシーは別オブジェクトである。検証期間中に元ポリシーを変更すると両者の内容がずれるため、変更を凍結しておく。
プレビュー時点の注意点
本機能はパブリックプレビューであり、Azure プレビューの追加使用条件が適用される。本番のポリシーを再編する前に、次の4点を確認する。
1. 場所条件を使うルールは即時のIPチェックが効かない
プレビュー期間中、ユーザーを対象に場所条件を含むプランでは、有効期間1時間のアクセストークンが発行され、継続的アクセス評価（CAE）による即時のIP強制チェックが行われない。ユーザーが許可された場所を離れても、最大1時間は制御が反映されない。場所ベースの即時適用を前提にした設計では、該当する制御を従来ポリシーに残す。
2. 既存のバックアップにプランが含まれない
プランのルールは、条件付きアクセスポリシー用の Microsoft Graph PowerShell コマンドレット（beta 版を含む）に表示されない。既存のバックアップスクリプトやツールはプランを取得できない（LazyAdmin・Admin365.Blog の検証による。公式ドキュメントには記載がない）。
3. プランは未文書化の beta エンドポイントで取得する
プランは専用の Graph エンドポイント /beta/identity/conditionalAccess/plans で扱われ、Policy.Read.All 権限で読み取れる。公式には未文書化のため、一般提供開始時にプロパティ名が変わる可能性がある。
# プラン一覧と各プランのルール数を取得し、JSON で保存する
Connect-MgGraph -Scopes "Policy.Read.All"
$uri = "https://graph.microsoft.com/beta/identity/conditionalAccess/plans"
$res = Invoke-MgGraphRequest -Method GET -Uri $uri
$res.value | ForEach-Object { "{0}: rules={1}" -f $_.displayName, $_.rules.Count }
$res | ConvertTo-Json -Depth 20 | Out-File "ca-plans-$(Get-Date -Format yyyyMMdd).json"バックアップ時は次の点に注意する。
- ルールの許可・セッションコントロールは、ポリシーのように最上位ではなく
controls配下に格納される。 - ルールには継承した共有条件が含まれない。ユーザーが空に見えるルールもあるため、プランとルールは必ず一体で保存する。
4. ポリシー上限との関係は未確認
条件付きアクセスには1テナント240ポリシーの上限があるが、プランのルールがこの上限にどう数えられるかは、現時点の公式ドキュメントに記載がない。上限回避を目的に導入する場合は、事前に自テナントで確認する。
導入の進め方
ポリシープランは既存ポリシーと並行稼働できるため、小さく始めて段階的に広げる。
- 棚卸し：既存ポリシーを一覧化し、リソース・ペルソナ・共通条件のいずれでまとめられるかを分類する。
- 小さく移行：数本のポリシーから始める。テナント全体を一度に移行しない。
- 除外をプランに寄せる：移行後、ブレークグラス用アカウントとサービスアカウントの除外を共有条件に追加する。
- レポートのみで検証：サインインログで元ポリシーと結果を突き合わせてからオンにする。
- 運用資料を更新：バックアップ手順に plans エンドポイントを加え、一般提供開始時にスクリプトを再確認する。
関連記事
AIエージェントの権限を実行環境側で制限する仕組みは、次の記事で解説しています。
NVIDIA OpenShell入門：AIエージェントを隔離して動かすランタイムの仕組み
GitHubのAzure移行と基盤刷新は、次の記事で解説しています。
GitHubのアーキテクチャ刷新とAzure移行を解説｜AIエージェントで書き込み5倍、Git基盤を保存と計算に分ける
計算結果を検証する暗号技術は、次の記事で解説しています。
参考資料
- New Conditional Access policy plans in Microsoft Entra（Microsoft Mechanics）
- What are Microsoft Entra Conditional Access policy plans? (preview)（Microsoft Learn）
- Create a Microsoft Entra Conditional Access policy plan (preview)（Microsoft Learn）
- Plan a Conditional Access deployment（Microsoft Learn）
- Entra Conditional Access Policy Plans Explained（Admin365.Blog、2026年10月30日）
- Migrate Conditional Access Policies to Policy Plans（LazyAdmin）
- Conditional Access Policy Plans in Microsoft Entra ID（AdminDroid）