Microsoft Entra の Conditional Access Templates は、条件付きアクセスの推奨ポリシーをゼロから作らず、Microsoft の推奨構成に沿ったテンプレートから作成できる機能です。2026年7月2日に更新された公式情報では、従来の管理者保護やリモートワーク向けテンプレートに加え、AI Agents 向けのテンプレートもカテゴリとして整理されており、グローバル環境で Entra ID を運用する管理者は確認しておきたい内容です。(Microsoft Learn)
今回のポイントは、「テンプレートをそのまま有効化する」のではなく、レポート専用モードで影響を確認し、除外アカウントや対象範囲を調整してから本番適用することです。特に、全ユーザー向け MFA、管理者向け MFA、レガシー認証ブロック、AI エージェント ID の制御は、設定ミスがサインイン障害や業務停止につながるため、段階的な導入が欠かせません。
Microsoft Entra の Conditional Access Templates とは
Conditional Access Templates は、Microsoft Entra ID の条件付きアクセス ポリシーを作成するための事前構成済みテンプレートです。条件付きアクセスは、「誰が」「どこから」「どのデバイスで」「どのアプリに」アクセスするかといったシグナルをもとに、MFA 要求、アクセスブロック、準拠デバイス要求などを適用する仕組みです。(Microsoft Learn)
通常、条件付きアクセスをゼロから設計する場合、対象ユーザー、対象アプリ、デバイス条件、場所、リスク、許可条件、セッション制御を個別に組み合わせる必要があります。設定の自由度が高い一方で、初心者や少人数の管理チームにとっては、どのポリシーから始めるべきか判断しにくいのが実情です。
Conditional Access Templates を使うと、Microsoft が推奨する代表的なセキュリティポリシーを土台にできます。たとえば、管理者に MFA を必須化する、レガシー認証をブロックする、リスクの高いサインインに追加制御をかける、といったよく使われる設定をテンプレートから作成できます。公式情報では、これらのテンプレートは「Microsoft recommendations」に沿って環境を保護するための便利な方法として説明されています。(Microsoft Learn)
2026年7月2日更新で確認すべきポイント
2026年7月2日更新の公式ページで特に注目したいのは、テンプレートカテゴリの整理と、作成後の検証・カスタマイズに関する注意点です。テンプレートは単なるサンプルではなく、実際の条件付きアクセス ポリシーとして作成できます。ただし、作成した時点で組織に完全に合うとは限りません。
主な確認ポイントは次のとおりです。
| 確認項目 | 管理者が見るべき内容 | 実務上の注意点 |
|---|---|---|
| テンプレートカテゴリ | Secure foundation、Zero Trust、Remote work、Protect administrator、Emerging threats、AI Agents | 自社の優先課題に合うカテゴリから選ぶ |
| 初期状態 | 既定ではレポート専用モードで作成される | すぐに有効化せず、サインインログで影響を確認する |
| 除外対象 | テンプレートから作成したユーザー対象ポリシーでは、作成者のみが除外される | 緊急用管理者アカウントなどは作成後に明示的に除外する |
| JSON エクスポート | テンプレートの JSON 定義を出力できる | Git 管理、レビュー、複数テナント展開に使いやすい |
| 移行確認 | クラシック条件付きアクセス ポリシーはすでに制御適用を停止 | 古いポリシーが残っていないか What If ツールなどで確認する |
公式情報では、テンプレートから作成したポリシーは既定でレポート専用モードになり、テストと監視を行ってから有効化することが推奨されています。また、テンプレートから作成されたユーザー対象ポリシーは、作成者のみが除外されるため、ほかの除外アカウントが必要な場合は作成後に編集する必要があります。(Microsoft Learn)
テンプレートカテゴリ別の使いどころ
Conditional Access Templates は、複数のカテゴリに分かれています。大切なのは、カテゴリ名だけで選ぶのではなく、自社のリスクと運用体制に合わせて優先順位を決めることです。
Secure foundation：まず入れるべき基本対策
Secure foundation は、多くの組織で土台として検討すべき基本ポリシー群です。公式情報では、これらのポリシーをすべての組織におけるベースとして推奨し、グループとして展開することが示されています。(Microsoft Learn)
代表的なテンプレートには、次のようなものがあります。
| テンプレート例 | 目的 | 優先度の目安 |
|---|---|---|
| Require multifactor authentication for admins | 管理者アカウントに MFA を要求 | 最優先 |
| Securing security info registration | セキュリティ情報登録を保護 | 最優先 |
| Block legacy authentication | レガシー認証をブロック | 最優先 |
| Require multifactor authentication for all users | 全ユーザーに MFA を要求 | 高 |
| Require multifactor authentication for Azure management | Azure 管理操作に MFA を要求 | 高 |
最初に検討すべきは、管理者アカウントの MFA とレガシー認証ブロックです。管理者アカウントが侵害されると、ユーザー作成、アプリ登録、メール転送、セキュリティ設定変更など、被害が広がりやすくなります。一方、レガシー認証は MFA などの近代的な認証制御を回避する攻撃経路になりやすいため、まだ利用しているクライアントや業務アプリがないかを確認したうえでブロックを進めるべきです。
Zero Trust：継続的な検証を前提にする
Zero Trust カテゴリは、「一度ログインできたら安全」と考えるのではなく、アクセスのたびに条件を評価する考え方に近い構成です。条件付きアクセス自体も、Microsoft の Zero Trust policy engine として位置付けられており、ユーザー、グループ、場所、デバイス、アプリ、リスクなど複数のシグナルを使ってアクセス判断を行います。(Microsoft Learn)
Zero Trust カテゴリでは、MFA、ゲストアクセス、リスクベースの制御、非対応デバイスの制御、永続的なブラウザーセッションの制限などが候補になります。特にグローバル展開している企業では、拠点ごとの IP アドレス、国・地域、業務時間、委託先やゲストユーザーのアクセスパターンが異なるため、テンプレートをそのまま全社適用するのは危険です。
たとえば、次のように段階分けすると失敗しにくくなります。
| フェーズ | 対象 | 推奨アクション |
|---|---|---|
| 検証 | IT 部門、少数のパイロットユーザー | レポート専用モードでサインイン影響を確認 |
| 初期展開 | 管理者、高リスク部門、クラウド管理者 | MFA と管理ポータル保護を優先 |
| 全社展開 | 全ユーザー、全主要アプリ | 例外条件を整理してから有効化 |
| 継続改善 | ゲスト、外部委託、AI エージェント | ログを見ながら条件を細かく調整 |
Remote work：社外アクセスと端末管理を整理する
Remote work カテゴリは、リモートワーカーを保護するためのポリシー群です。公式ページでは、MFA、ゲストアクセス、リスクベース制御、準拠デバイス、承認済みクライアントアプリ、管理外デバイス向けの制限などが挙げられています。(Microsoft Learn)
リモートワーク環境では、ユーザーの場所や端末状態が一定ではありません。会社支給 PC、個人端末、スマートフォン、海外出張先、委託先ネットワークなどが混在します。そのため、「社外アクセスは全部ブロック」のような単純な設計では業務が止まりやすくなります。
実務では、次の観点で整理すると設計しやすくなります。
| 利用シーン | 推奨される考え方 | 注意点 |
|---|---|---|
| 会社支給 PC から Microsoft 365 を利用 | 準拠デバイスまたはハイブリッド参加デバイスを要求 | Intune 管理状態を先に確認 |
| 個人スマホから Teams や Outlook を利用 | アプリ保護ポリシーや承認済みアプリを検討 | BYOD ルールを明文化する |
| 海外出張からのアクセス | MFA とサインインリスクを組み合わせる | 国・地域ブロックだけに頼らない |
| 外部委託先・ゲストユーザー | ゲスト向け MFA やアプリ単位制御を検討 | 一律ブロックでは共同作業に支障が出る |
Protect administrator：特権アカウントを別扱いにする
Protect administrator カテゴリは、侵害された場合の影響が特に大きい高権限管理者を保護するためのテンプレートです。公式情報でも、このカテゴリは環境内の高権限管理者向けであり、侵害時に大きな被害につながる可能性があるアカウントを対象とすると説明されています。(Microsoft Learn)
管理者向けポリシーでは、一般ユーザーより厳しい制御を設定するのが基本です。たとえば、管理ポータルへのアクセス時だけフィッシング耐性のある MFA を要求する、Azure 管理操作には追加の MFA を要求する、準拠済みデバイスからのみ管理操作を許可する、といった設計が考えられます。
ただし、管理者を厳しくしすぎると、障害対応時にログインできなくなるリスクがあります。そのため、必ず緊急アクセス用の break-glass アカウントを用意し、通常の条件付きアクセス ポリシーから除外しておく必要があります。公式情報でも、ロックアウトを防ぐため、緊急アクセスまたは break-glass アカウントを条件付きアクセス ポリシーから除外することが推奨されています。(Microsoft Learn)
Emerging threats：新しい攻撃パターンへの対応
Emerging threats カテゴリでは、環境侵害への対策として新しい保護方法を提供するポリシーが扱われます。公式ページでは、管理者にフィッシング耐性のある多要素認証を要求するテンプレートが示されています。(Microsoft Learn)
フィッシング耐性のある MFA は、従来の SMS や単純なプッシュ通知よりも強い認証手段を使う設計です。特に、グローバル管理者、条件付きアクセス管理者、特権ロール管理者、セキュリティ管理者などには、通常の MFA より強い認証を要求する価値があります。
導入時に注意したいのは、利用者側の準備です。セキュリティキーや証明書ベース認証などを使う場合、デバイス配布、紛失時の復旧手順、代替認証方法を事前に整えておかないと、導入初日に問い合わせが集中します。
AI Agents：エージェント ID もアクセス制御の対象にする
2026年7月2日更新のページで目を引くのが、AI Agents カテゴリです。公式情報では、このカテゴリは環境内のエージェントを制御する方法を提供するものとして整理され、Block high-risk agent identities、Configure policy for autonomous agent access、Configure policy for on-behalf-of agent access が挙げられています。(Microsoft Learn)
これは、AI エージェントや自律的なワークロードが組織データにアクセスする場面が増えていることを前提にした重要な変化です。人間のユーザーだけでなく、エージェント ID やエージェントによる代理アクセスも、条件付きアクセスの設計対象として考える必要があります。
たとえば、次のようなケースでは AI Agents 関連のテンプレート確認が重要です。
| ケース | 確認すべきこと |
|---|---|
| Microsoft 365 Copilot や業務 AI エージェントを使っている | どのエージェントが、どのデータやアプリにアクセスできるか |
| 自律実行型のエージェントを試験導入している | 高リスクなエージェント ID をブロックできるか |
| ユーザー代理で操作するエージェントを使う | on-behalf-of アクセスの条件を定義できるか |
| 複数地域・複数部門で AI 活用が進んでいる | エージェント単位のアクセス棚卸しを行っているか |
AI Agents テンプレートは、単に新しいカテゴリが増えたという話ではありません。今後の Entra ID 運用では、「ユーザーのサインイン」だけでなく、「AI エージェントがどの権限で動くか」も条件付きアクセスの管理対象に入ってくる、という実務上のサインとして捉えるべきです。
影響範囲：誰が対応すべきか
今回の更新で直接確認すべきなのは、Microsoft Entra ID の条件付きアクセスを運用している管理者です。特に次のような組織では、テンプレートの見直し優先度が高くなります。
| 対象組織・担当者 | 影響 |
|---|---|
| Microsoft 365 を全社利用している組織 | 全ユーザー MFA、レガシー認証ブロック、管理ポータル保護の見直しが必要 |
| Azure を利用している組織 | Azure 管理操作に対する MFA や管理者保護を確認すべき |
| グローバル拠点を持つ企業 | 国・地域、拠点、委託先、ゲストアクセスの条件整理が必要 |
| Intune を利用している組織 | 準拠デバイス要求やアプリ保護ポリシーとの整合性確認が必要 |
| Microsoft Purview や Insider Risk を利用している組織 | インサイダーリスクに基づくアクセスブロックの検討対象になる |
| AI エージェントを導入・検証している組織 | エージェント ID と代理アクセスの制御確認が必要 |
ライセンス面では、条件付きアクセスの利用には Microsoft Entra ID P1 が必要です。リスクベースの条件付きアクセスには Microsoft Entra ID Protection が関係し、これは Microsoft Entra ID P2 の機能として説明されています。また、Intune、Purview、Workload ID などと連携する機能では、それぞれ適切なライセンスが必要になります。(Microsoft Learn)
つまり、テンプレート一覧に表示されるからといって、すべての機能を現在の契約で利用できるとは限りません。導入前に、Microsoft Entra ID P1/P2、Microsoft 365 Business Premium、Intune、Purview などの契約状況を確認しておくべきです。
設定変更で管理者がやるべき手順
Conditional Access Templates を使う場合は、いきなり有効化するのではなく、次の順序で進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 現在の条件付きアクセス ポリシーを棚卸しする | 既存ポリシーとの重複や競合を確認 |
| 2 | 優先するテンプレートを選ぶ | 管理者 MFA、レガシー認証ブロック、セキュリティ情報登録保護を優先 |
| 3 | テンプレートからポリシーを作成する | 既定ではレポート専用モードで作成されることを確認 |
| 4 | 除外アカウントを追加する | break-glass アカウント、サービスアカウント、移行中ユーザーなど |
| 5 | サインインログで影響を確認する | ブロック予定、MFA 要求予定、対象外ユーザーを確認 |
| 6 | 対象範囲を段階的に広げる | IT 部門、パイロット部門、全社の順に展開 |
| 7 | 本番有効化する | レポート専用から On に切り替える |
| 8 | 運用後に定期レビューする | 異常な除外、古い例外、未保護アプリを確認 |
テンプレートは Microsoft Entra 管理センターの「Entra ID > Conditional Access > Create new policy from templates」から確認できます。公式情報では、Show more を選ぶことで各カテゴリ内のすべてのポリシーテンプレートを表示できると説明されています。(Microsoft Learn)
また、テンプレートごとにポリシー設定の概要確認、組織要件に合わせた編集、JSON 定義のエクスポートができます。JSON 定義は編集後、条件付きアクセス ポリシー画面の Upload policy file からインポートできるため、複数テナントへの展開や構成レビューにも使いやすい仕組みです。(Microsoft Learn)
レポート専用モードで見るべきログ
条件付きアクセスの変更で最も避けたいのは、正当なユーザーが業務アプリにアクセスできなくなることです。そのため、テンプレートから作成したポリシーは、まずレポート専用モードで検証します。
レポート専用モードでは、ポリシーはサインイン時に評価されますが、実際には強制されません。評価結果はサインインログの Conditional Access タブや Report-only タブに記録されます。(Microsoft Learn)
確認すべきログの見方は次のとおりです。
| ログ結果 | 意味 | 管理者の判断 |
|---|---|---|
| Report-only: Success | 条件を満たしており、ポリシー適用後も問題が少ない | 有効化候補 |
| Report-only: Failure | 条件に一致するが、要求を満たせず失敗する可能性がある | 対象や条件を見直す |
| Report-only: User action required | MFA などユーザー操作が必要になる | ユーザー周知や登録状況確認が必要 |
| Report-only: Not applied | 条件に一致せず適用されない | 想定どおり対象外か確認 |
特に注意すべきなのは、準拠デバイスを要求するポリシーです。公式情報では、レポート専用モードであっても、macOS、iOS、Android 端末でデバイス証明書の選択を求めるプロンプトが出る場合があると警告されています。デバイス準拠チェックを行うレポート専用ポリシーでは、必要に応じて Mac、iOS、Android のデバイスプラットフォームを除外することが推奨されています。(Microsoft Learn)
除外アカウントの設計で失敗しないコツ
条件付きアクセスの失敗で多いのが、「安全にしようとして管理者自身が締め出される」ケースです。テンプレートから作成したポリシーでは、作成者だけが除外されるため、緊急用アカウントや特殊な運用アカウントは別途除外しなければなりません。(Microsoft Learn)
除外を検討すべき代表例は次のとおりです。
| 除外候補 | 理由 | 注意点 |
|---|---|---|
| break-glass アカウント | 条件付きアクセス設定ミス時の復旧用 | 強力なパスワード、監視、利用ルールを必ず設定 |
| サービスアカウント | バックエンド処理や連携で使われる場合がある | 可能ならマネージド ID へ移行 |
| Microsoft Entra Connect 関連アカウント | 同期処理に影響する可能性がある | 対話型サインインの有無を確認 |
| 検証中のパイロットユーザー | 段階展開のため | 除外を放置しない |
公式情報では、サービスアカウントやサービスプリンシパルについても注意が示されています。サービスプリンシパルによる呼び出しは、ユーザーを対象にした条件付きアクセス ポリシーではブロックされません。ワークロード ID 向けの条件付きアクセスを使う、またはスクリプトやコード内のサービスアカウントをマネージド ID に置き換えることが推奨されています。(Microsoft Learn)
クラシック条件付きアクセス ポリシーの移行状況を確認する
今回の公式ページで、移行期限として新たな日付が示されたわけではありません。ただし、クラシック条件付きアクセス ポリシーに関する重要な記述があります。公式情報では、クラシック条件付きアクセス ポリシーは非推奨であり、2024年7月10日以降は制御の適用を停止していると説明されています。(Microsoft Learn)
そのため、2026年時点で確認すべきことは、「これから移行する期限があるか」ではなく、すでに効かなくなっている古いポリシーが残っていないかです。
確認手順は次のようになります。
| 手順 | 内容 |
|---|---|
| 1 | Microsoft Entra 管理センターに Conditional Access Administrator 以上の権限でサインイン |
| 2 | Entra ID > Conditional Access > Classic policies を確認 |
| 3 | 残っているクラシックポリシーの設定を記録 |
| 4 | テンプレートまたはカスタムポリシーで現行の条件付きアクセス ポリシーとして再作成 |
| 5 | レポート専用モードで検証 |
| 6 | 問題がなければクラシックポリシーを無効化 |
注意点として、クラシックポリシーは一度無効化すると再有効化できません。公式情報でも、無効化前に設定内容を文書化するよう警告されています。(Microsoft Learn)
また、What If ツールを使うと、環境内にクラシックポリシーが残っているかどうかを確認できます。(Microsoft Learn)
グローバル企業で特に確認すべきポイント
グローバル環境では、単一拠点の中小規模テナントよりも条件付きアクセスの影響が複雑になります。国・地域、時差、ネットワーク、ゲストユーザー、外部委託、複数の ID 運用ルールが絡むためです。
特に次の観点は、テンプレート適用前に整理しておくべきです。
国・地域ベースのブロックは慎重に使う
特定の国や地域からのアクセスをブロックする設定は分かりやすい反面、出張、海外拠点、委託先、VPN 経由のアクセスに影響します。場所条件は強力ですが、ビジネス要件を無視して設定すると、正当な業務を止める原因になります。
最初はブロックではなく、MFA 要求やセッション制御と組み合わせて様子を見る方が安全です。
管理者ロールを持つユーザーを棚卸しする
Conditional Access Administrator は条件付きアクセス機能を管理できる特権ロールです。Microsoft の組み込みロール一覧でも、このロールは Microsoft Entra Conditional Access 設定を管理できる権限として説明されています。(Microsoft Learn)
条件付きアクセスを強化する前に、グローバル管理者、条件付きアクセス管理者、セキュリティ管理者、特権ロール管理者などを棚卸しし、不要な権限を削除しておきましょう。強いポリシーを作っても、特権ロールが過剰に付与されていれば、侵害時の影響範囲は大きくなります。
ゲストユーザーと外部委託先を分けて考える
ゲストユーザーを一律で全社員と同じ扱いにすると、共同作業が止まることがあります。一方で、何も制御しないと SharePoint、Teams、業務アプリへのアクセスが広がりすぎます。
外部ユーザーには、少なくとも MFA 要求、対象アプリの限定、セッション期限、管理外デバイスでの制限を組み合わせて検討するのが現実的です。
AI エージェントのアクセスを棚卸しする
AI Agents カテゴリが用意されたことで、今後は人間のアカウントだけでなく、エージェント ID の管理も重要になります。AI エージェントがユーザー代理でアクセスするのか、自律的にアクセスするのか、高リスクと判断された場合にブロックできるのかを確認しましょう。
特に、複数部門で個別に AI ツールやエージェントを検証している企業では、誰がどの権限でエージェントを登録し、どのデータにアクセスできるのかが見えにくくなります。Conditional Access Templates の確認とあわせて、エージェント ID の棚卸しを進めるべきです。
よくある失敗と回避策
Conditional Access Templates は便利ですが、テンプレートだから安全に自動運用できるわけではありません。よくある失敗を事前に把握しておくと、導入時のトラブルを減らせます。
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| 管理者がログインできなくなる | break-glass アカウントを除外していない | 緊急アクセス用アカウントを事前に設計 |
| 全ユーザー MFA で問い合わせが急増 | MFA 登録状況を確認せず有効化 | レポート専用モードと段階展開を使う |
| レガシー認証ブロックで業務アプリが止まる | 古いメールクライアントや連携アプリが残っている | サインインログでレガシー認証利用を確認 |
| 準拠デバイス要求で BYOD が使えない | Intune 登録やアプリ保護方針と整合していない | 対象アプリと端末種別を分けて設計 |
| 例外ユーザーが増え続ける | 一時除外を放置している | 例外には期限と理由を記録 |
| AI エージェントの権限が不明 | 人間のユーザーだけを棚卸ししている | エージェント ID と代理アクセスも確認 |
テンプレート導入で重要なのは、「推奨テンプレートを入れること」ではなく、「自社の実態に合う形で安全に有効化すること」です。テンプレートは出発点であり、最終設定ではありません。
まず実施すべきチェックリスト
Microsoft Entra の Conditional Access Templates を確認する管理者は、次の順で進めるとよいでしょう。
| 優先度 | チェック項目 | 完了の目安 |
|---|---|---|
| 高 | 既存の条件付きアクセス ポリシーを棚卸しする | 重複・競合・未使用ポリシーが把握できている |
| 高 | break-glass アカウントを確認する | 条件付きアクセスから除外され、監視されている |
| 高 | 管理者 MFA テンプレートを検証する | 管理者サインインへの影響がログで確認済み |
| 高 | レガシー認証利用を確認する | ブロックしても業務影響がない、または代替策がある |
| 中 | 全ユーザー MFA を段階展開する | パイロット部門で問題がない |
| 中 | リモートワーク向けポリシーを見直す | BYOD、ゲスト、海外拠点の扱いが整理されている |
| 中 | クラシックポリシーの残存を確認する | 現行ポリシーへ移行済み |
| 中 | AI Agents カテゴリを確認する | エージェント ID とアクセス経路を把握している |
| 低 | JSON 定義をエクスポートして管理する | レビューや再展開に使える形で保管されている |
まとめ：テンプレートは「最短導入」ではなく「安全な標準化」のために使う
Microsoft Entra の Conditional Access Templates は、条件付きアクセスを効率よく始めるための強力な機能です。2026年7月2日更新の公式情報では、基本的なセキュリティ対策、Zero Trust、リモートワーク、管理者保護、新しい脅威、AI Agents まで、幅広いカテゴリが整理されています。(Microsoft Learn)
管理者が次に取るべき行動は明確です。まず、既存ポリシーとクラシックポリシーの棚卸しを行い、管理者 MFA、レガシー認証ブロック、セキュリティ情報登録保護から優先的にテンプレートを確認します。そのうえで、レポート専用モードで影響を見て、除外アカウントを正しく設定し、段階的に有効化します。
特にグローバル環境では、国・地域、ゲスト、端末管理、AI エージェントの扱いまで含めて設計する必要があります。テンプレートを「そのままオンにする機能」と考えるのではなく、Microsoft 推奨に沿った標準ポリシーを安全に作るための土台として活用しましょう。
コメント