Microsoft Entra Conditional Access optimization agentは、条件付きアクセスの「抜け」「重複」「例外の増えすぎ」を継続的に見つけ、Microsoft Security Copilotを使って改善提案を出すエージェントです。結論から言うと、管理者はすぐに本番適用するのではなく、ライセンス、SCU課金、権限、エージェントID、レポート専用ポリシー、ブレークグラスアカウントの除外を確認したうえで、小さく検証してから展開すべき機能です。
2026年5月14日に更新されたMicrosoft EntraのSecurity Copilot公式情報では、Microsoft EntraでSecurity Copilotを利用する体験として、スタンドアロン、管理センター埋め込み、専用エージェント、自然言語プロンプトが整理されています。その中でConditional Access optimization agentは、条件付きアクセスを一度作って終わりにせず、ユーザー、アプリケーション、エージェントIDの保護状態を継続的に見直すための実務向け機能と考えると分かりやすいです。(Microsoft Learn)
Microsoft Entra Conditional Access optimization agentとは
Microsoft Entra Conditional Access optimization agentは、Microsoft Entraの条件付きアクセスを分析し、保護されていないユーザー、アプリケーション、エージェントIDを見つけて、新しいポリシーの作成や既存ポリシーの更新を提案する機能です。MFA要求、デバイスベースの制御、レガシ認証のブロック、デバイスコードフローのブロック、類似ポリシーの統合などを評価対象にします。(Microsoft Learn)
重要なのは、エージェントが勝手に本番ポリシーを変更するわけではない点です。Microsoftの公式情報では、管理者が提案を明示的に承認しない限り既存ポリシーは変更されず、エージェントが提案する新しいポリシーはレポート専用モードで作成されると説明されています。(Microsoft Learn)
つまり、このエージェントは「自動で条件付きアクセスを任せるツール」ではなく、管理者が判断するための継続的な監査・提案エンジンです。特に、条件付きアクセスのポリシー数が増え、例外グループや対象アプリが複雑化している環境では、手作業の棚卸しを補助する役割が大きくなります。
2026年5月時点で押さえるべき主な変更点
今回の公式情報で管理者が特に見るべきポイントは、単なるポリシー提案にとどまらず、組織固有のルール、エージェントID、パスキー導入、段階的ロールアウト、可視化まで含めて運用機能が広がっている点です。
| 変更点・強化点 | 管理者が確認すべきこと |
|---|---|
| ユーザー、アプリケーション、エージェントIDの保護状態を評価 | 人間のユーザーだけでなく、非人間IDやアプリの条件付きアクセス対象漏れを確認する |
| MFA、デバイス制御、レガシ認証、デバイスコードフローを評価 | 既存ポリシーの対象外ユーザー、例外グループ、旧式認証の利用状況を棚卸しする |
| 詳細なMFAギャップ分析 | 過去24時間だけでなく、テナント全体のMFA対象漏れを見る運用を検討する |
| エージェントIDへの対応 | 以前のユーザーコンテキスト実行から、Microsoft Entra Agent IDへ移行できるか確認する |
| ナレッジソースとカスタム指示 | 命名規則、ブレークグラス除外、管理者用ポリシーなど社内標準を反映させる |
| 段階的ロールアウト | レポート専用ポリシーを一気にオンにせず、低影響グループから展開する |
| パスキー導入キャンペーン | 特権管理者など高リスクユーザーからフィッシング耐性の高い認証を展開する |
| Teams通知・ServiceNow連携 | 提案を見落とさない通知設計と、変更管理フローとの接続を検討する |
ServiceNow統合、ファイルアップロード、アクティビティベースの実行など一部機能はプレビューとして扱われています。プレビュー機能は仕様変更の可能性があるため、本番運用に組み込む場合は「正式リリース済みの機能」と同じ前提で運用ルールを固定しないことが重要です。(Microsoft Learn)
影響範囲は管理者だけでなく、開発者・アプリ担当者にも及ぶ
Conditional Access optimization agentの影響は、Microsoft Entra管理者だけに閉じません。条件付きアクセスはサインイン、アプリ利用、デバイス状態、認証方式に関わるため、開発者や業務アプリ担当者も確認が必要です。
| 関係者 | 影響を受ける可能性がある領域 | 確認ポイント |
|---|---|---|
| Entra管理者 | 条件付きアクセスポリシー、例外、レポート専用設定 | 提案を誰が承認するか、どの順番で展開するかを決める |
| セキュリティ担当者 | MFA、リスクベース制御、レガシ認証、ゼロトラスト指標 | セキュリティ向上と業務影響のバランスを評価する |
| 開発者・アプリ担当者 | アプリのサインイン、デバイスコードフロー、Graph権限 | アプリが新しい条件付きアクセスで止まらないか検証する |
| ヘルプデスク | MFA要求、端末準拠、パスキー登録、証明書選択プロンプト | 問い合わせ増加を見込み、案内文とエスカレーション先を準備する |
| 変更管理担当者 | ServiceNow連携、承認フロー、監査証跡 | 提案をそのまま適用せず、変更管理プロセスに載せる |
開発者が特に注意したいのは、デバイスコードフローやレガシ認証のブロックです。社内ツール、CLI、古い業務アプリ、検証用アプリが旧式の認証フローに依存している場合、条件付きアクセスの強化によってサインインできなくなる可能性があります。エージェントの提案を適用する前に、サインインログで対象アプリと認証方式を確認しておくべきです。
利用前に確認すべき前提条件
Conditional Access optimization agentを使うには、少なくともMicrosoft Entra ID P1ライセンス、利用可能なSecurity Compute Unit、適切なMicrosoft Entraロールが必要です。Security Administratorは初回アクティブ化に必要で、Security ReaderとGlobal Readerは閲覧のみ、Conditional Access AdministratorとSecurity Administratorは提案へのアクションが可能とされています。デバイスベースの制御を扱う場合はIntuneライセンスも関係します。(Microsoft Learn)
また、Security Copilotは少なくとも1つのSCUがテナントにプロビジョニングされている必要があり、エージェントをオフにしてもSCUの月額課金は止まらないと説明されています。検証だけのつもりでも、課金と容量の管理者を巻き込んでから有効化するのが安全です。(Microsoft Learn)
有効化前チェックリスト
| 確認項目 | 判断基準 |
|---|---|
| ライセンス | Microsoft Entra ID P1以上があるか。リスクベース提案を使うならP2が必要な場面がある |
| SCU | Security CopilotのSCUが用意されているか。課金責任者が把握しているか |
| ロール | 初回有効化、閲覧、承認、変更を誰が担当するか分離できているか |
| ブレークグラスアカウント | 条件付きアクセスやパスキーキャンペーンから除外する設計になっているか |
| 既存ポリシー | レポート専用、オン、オフ、例外グループ、対象アプリを棚卸し済みか |
| Intune連携 | デバイス準拠やアプリ保護ポリシーを提案に使う場合、Intune側の状態を確認したか |
| 開発・業務アプリ | レガシ認証、デバイスコードフロー、Graph権限の利用状況を確認したか |
| 通知先 | Teams通知を受ける管理者またはグループを決めているか |
| 変更管理 | 提案の承認、却下、スヌーズ、メモの運用ルールを決めているか |
エージェントの動作を理解する
エージェントは実行時に、まずテナント内の条件付きアクセスポリシーをスキャンし、ポリシーギャップや統合できるポリシーを確認します。過去の提案も参照し、同じポリシーを再提案しないようにします。初期スキャン手順ではSCUを消費せず、未提案のギャップや統合候補を見つけた後のエージェントアクションでSCUを使用します。(Microsoft Learn)
標準のスキャンでは、過去24時間の新しいユーザー、アプリケーション、エージェントIDが条件付きアクセスポリシーで保護されているかを確認します。一方、詳細なMFAギャップ分析では、テナント内の有効な条件付きアクセスポリシー全体を評価し、MFAポリシーの対象外ユーザーを特定します。(Microsoft Learn)
実務では、次のように使い分けると効果的です。
| 使いどころ | 向いている確認 |
|---|---|
| 日次の自動実行 | 新規ユーザー、新規アプリ、新規エージェントIDの保護漏れ確認 |
| 手動実行 | ポリシー変更後、アプリ追加後、監査前のスポットチェック |
| 詳細なMFAギャップ分析 | 長年の例外、グループ設計ミス、重複ポリシー間の抜けの確認 |
| ポリシー統合提案 | 条件や制御が似ているポリシーを減らし、運用負荷を下げる |
管理者が最初に確認すべき設定
Conditional Access optimization agentの設定は、Microsoft Entra管理センターのエージェント画面または条件付きアクセスのポリシー概要側から確認できます。設定では、実行トリガー、通知、スコープ、カスタム指示、Intune統合、アクセス許可などを扱います。(Microsoft Learn)
実行トリガー
エージェントは24時間ごとの自動実行に加え、手動実行もできます。さらに、アクティビティベースの実行を有効にすると、有効な条件付きアクセスポリシーの変更、ポリシー状態のオンへの変更、オン状態の新規ポリシー作成などを契機に実行されます。アクティビティベース実行はプレビューで、過剰な実行を避けるためのクールダウンも用意されています。(Microsoft Learn)
ポリシーを頻繁に変更するテナントでは、自動実行だけに頼ると確認タイミングが遅れることがあります。一方で、変更のたびにエージェント提案が増えると運用が混乱します。まずは手動実行と24時間実行で様子を見て、変更管理の流れが固まってからアクティビティベース実行を検討すると安全です。
レポート専用ポリシーの作成許可
既定では、エージェントがレポート専用モードで新しいポリシーを作成できない設定になっている場合があります。この設定を有効にすると、エージェントはレポート専用ポリシーを作成できますが、有効化前に管理者の承認と影響確認が必要です。(Microsoft Learn)
本番環境では、最初から自動作成を許可するより、まず提案内容だけを確認し、社内の条件付きアクセス命名規則や承認フローに合うかを見るのが現実的です。運用に慣れてから、レポート専用作成を許可するとよいでしょう。
Teams通知
Teams通知を使うと、新しい提案が出たときに管理者へ通知できます。ただし、現時点では一方向の通信で、Teams上で返信して提案を処理することはできません。提案に対応するにはMicrosoft Entra管理センターを開く必要があります。通知先には人数やオブジェクト数の制限もあります。(Microsoft Learn)
通知先は「全管理者」ではなく、条件付きアクセスをレビューする少人数のグループに絞るのが実務的です。通知が多すぎると、重要な提案が埋もれます。
カスタム指示とナレッジソース
カスタム指示では、特定のユーザー、グループ、ロールを含める・除外する、特定ポリシーに例外を適用する、といった組織固有のルールをエージェントに伝えられます。たとえば、ゲストユーザーをエージェントの考慮対象から外す、特定グループをMFAポリシーから除外する、といった指示が可能です。(Microsoft Learn)
ナレッジベース機能では、条件付きアクセスの標準を記述したWordまたはPDF文書をアップロードし、命名規則、ユーザーペルソナ、ブレークグラスアカウントの扱いなどを提案に反映できます。ただしプレビュー期間中は、テナントごとに1つのドキュメント、WordまたはPDF、最大5MBなどの制限があります。既存の提案へはさかのぼって反映されません。(Microsoft Learn)
エージェントIDへの移行で見るべきポイント
既存環境で特に重要なのが、Microsoft Entra Agent IDです。公式情報では、条件付きアクセス最適化エージェントが特定ユーザーのIDではなく独自のエージェントIDで実行できるようになり、新規インストールでは既定でエージェントIDが使われると説明されています。既存インストールもユーザーコンテキストからエージェントIDへ切り替えられますが、以前のユーザーコンテキストには戻せません。(Microsoft Learn)
Microsoft Ignite 2025より前にPIMでロール有効化が必要なアカウントを使ってエージェントを有効化していた場合、実行時に必要な権限がなく「Fail」と表示される可能性があります。この場合は、Microsoft Entra Agent IDを使うよう移行することで解決できるとされています。(Microsoft Learn)
移行前に確認すること
エージェントIDへ切り替える前に、次の点を確認してください。
- エージェントを作成・管理する担当者にSecurity Administratorロールがあるか
- エージェントIDへ切り替えた後、既存のレポートや推奨事項に影響がないことを関係者へ説明したか
- 監査ログで、エージェントによる変更と人間の管理者による承認を追跡できるか
- 以前のユーザーコンテキストへ戻せない点を変更管理に記録したか
エージェントIDには、AuditLog.Read.All、Policy.Read.All、Policy.Create.ConditionalAccessRO、User.Read.Allなどのアクセス許可が自動的に割り当てられます。開発者やセキュリティ担当者は、エージェントID自体も監査対象の非人間IDとして扱うべきです。(Microsoft Learn)
提案を適用する前に見るべきレビュー項目
エージェントの提案は、内容によって「新しいレポート専用ポリシーの作成」「既存ポリシーの変更」「重複ポリシーの統合」「ポリシーアクティビティの急増・低下のレビュー」などに分かれます。管理者は、提案のロジック、影響範囲、ポリシー詳細を確認したうえで判断する必要があります。(Microsoft Learn)
| レビュー項目 | 見るべき内容 |
|---|---|
| 提案の理由 | なぜギャップと判断されたのか。対象外ユーザー、対象外アプリ、例外グループの根拠は明確か |
| ポリシー影響 | どのサインイン、ユーザー、アプリに影響するか。業務停止につながるアプリはないか |
| JSON差分 | 既存ポリシーのどの条件、対象、制御が変わるか |
| 除外設定 | ブレークグラスアカウント、緊急アクセス、検証用アカウントが適切に扱われているか |
| ロールアウト方法 | レポート専用、段階的ロールアウト、限定グループ検証の順番になっているか |
| 監査証跡 | 誰が提案を確認し、誰が承認したかを後から追えるか |
提案画面では、ポリシー変更の確認、ポリシーの有効化、レビュー済みとしてマーク、14日間通知を一時停止、エージェントの完全なアクティビティ表示、メモ追加などの操作ができます。提案を「今すぐ適用しない」場合でも、レビュー済みやスヌーズ、メモを使って判断理由を残すと、後日の監査で説明しやすくなります。(Microsoft Learn)
段階的ロールアウトで本番影響を抑える
条件付きアクセスの変更で最も避けたいのは、意図しないロックアウトです。段階的ロールアウト機能は、レポート専用ポリシーを低影響グループから段階的に展開し、影響を監視しながら進めるための機能です。管理者はグループ、ロールアウト速度、展開判断を制御できます。(Microsoft Learn)
段階的ロールアウトでは、すべてのユーザーに適用されるレポート専用ポリシーが対象になります。計画には5つのフェーズがあり、エージェントは既存ポリシーで使われているグループやサインインデータを見て、影響の低いグループから高いグループへ進める計画を提案します。テナントには少なくとも5つの定義済みグループが必要です。(Microsoft Learn)
展開時の実務ポイント
最初のフェーズに含めるべきなのは、IT部門全体ではなく、復旧手順を理解している少人数の検証グループです。たとえば、条件付きアクセス管理者、セキュリティ運用担当、ヘルプデスクの代表者、主要業務アプリの担当者を含めると、問題発生時に原因を切り分けやすくなります。
段階的ロールアウト中は、各フェーズでサインイン失敗、MFA要求の増加、デバイス準拠エラー、業務アプリへのアクセス失敗を確認します。公式情報では、任意のフェーズで10%を超えるサインインが新しいポリシーによってブロックされた場合、ロールアウトは一時停止されると説明されています。また、成功率が90%を下回ると停止し、有効なポリシーがレポート専用モードへ戻されるとされています。(Microsoft Learn)
パスキー導入キャンペーンは特権管理者から始める
Conditional Access optimization agentは、パスキー導入キャンペーンの展開もサポートします。パブリックプレビューでは、ユーザーとデバイスの準備状況を評価し、展開計画を生成し、必要な手順をユーザーに案内し、準備ができたら条件付きアクセスポリシーを適用する流れが説明されています。(Microsoft Learn)
パスキーキャンペーンを使うには、パスキーを認証方法ポリシーで有効化している必要があり、キャンペーン管理にはSecurity Administratorが必要です。Conditional Access Administratorだけでは、パスキーキャンペーンを管理する十分な権限がないとされています。(Microsoft Learn)
実務では、全社員へ一斉展開するより、特権管理者、経営層、財務・人事などフィッシング被害の影響が大きいユーザーから始めるのが現実的です。キャンペーンでは、デバイス更新が必要なユーザー、パスキー登録が必要なユーザー、適用準備ができているユーザーを分けて確認できます。ブレークグラス用または緊急アクセス用の管理者アカウントは、キャンペーンから除外することが推奨されています。(Microsoft Learn)
IntuneとGlobal Secure Accessを使う環境での注意点
Intuneを使っている組織では、エージェントがデバイスコンプライアンスやアプリ保護ポリシーを監視し、条件付きアクセスでの適用漏れを提案できます。Intuneの提案を生成するには、エージェントがGlobal AdministratorまたはConditional Access Administratorに加えてGlobal Readerとして実行されている必要があり、Conditional Access Administratorだけでは不十分とされています。(Microsoft Learn)
Global Secure Accessを使う環境では、Microsoft Entra Internet AccessとMicrosoft Entra Private Accessがエージェントと統合され、承認されたGlobal Secure Access経由で企業リソースへアクセスする条件付きアクセスの提案を行えます。サインインログを見て、準拠した接続かどうかを確認できます。(Microsoft Learn)
注意したいのは、デバイス準拠を要求するレポート専用ポリシーでも、macOS、iOS、Androidのユーザーにデバイス証明書の選択が求められる場合がある点です。公式情報では、エンドユーザーのサインイン時プロンプトを避けるには、デバイスコンプライアンスチェックを行うレポート専用ポリシーからMac、iOS、Androidを除外する方法が示されています。(Microsoft Learn)
失敗しやすいポイントと回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 提案をすぐ本番適用する | 管理者や業務ユーザーがロックアウトされる | レポート専用、限定グループ、段階的ロールアウトの順に進める |
| ブレークグラスを除外しない | 障害時に復旧用アカウントへアクセスできない | すべての新規・変更ポリシーで除外を確認する |
| SCU課金を確認しない | 検証後もコストが残る | 有効化前にSecurity Copilotの容量と課金責任者を確認する |
| PIM前提の古い有効化状態を放置する | エージェント実行がFailになる | Microsoft Entra Agent IDへ移行する |
| カスタム指示を曖昧に書く | 不要な対象追加や例外漏れが起きる | グループ名だけでなく、可能ならオブジェクトIDも確認する |
| レガシ認証利用アプリを確認しない | 古い業務アプリやツールが使えなくなる | サインインログで認証方式と対象アプリを確認する |
| 通知先を増やしすぎる | 誰も提案を処理しない | レビュー責任者を少人数に絞り、メモで判断を残す |
| プレビュー機能を固定運用に組み込む | 仕様変更で運用が崩れる | プレビューは検証・補助扱いにし、変更可能性を明記する |
特に「レポート専用だから安全」と考えるのは危険です。レポート専用でもユーザーにプロンプトが出るケースがあるため、デバイス準拠や証明書に関わるポリシーは、検証端末と実ユーザーの両方でサインイン挙動を確認してください。
開発者・アプリ担当者が確認すべき項目
開発者や業務アプリ担当者は、条件付きアクセスの提案を「ID管理部門だけの変更」と捉えないほうがよいです。アプリへのアクセス条件が変わると、認証フロー、API利用、サポート問い合わせに影響します。
確認すべきログと設定
- Microsoft Entraサインインログで、対象アプリの失敗イベントを確認する
- レガシ認証、デバイスコードフロー、証明書ベース認証の利用有無を確認する
- Microsoft Graph権限を持つアプリやエージェントIDの過剰権限を棚卸しする
- 条件付きアクセスの対象にしたくない検証アプリや一時アプリを整理する
- 本番適用前に、管理対象端末、非管理端末、モバイル、外部ネットワークからのサインインを試す
エージェントIDの最小特権アクセス提案では、未使用または過剰なMicrosoft Graphアクセス許可を持つエージェントIDを識別し、未使用権限の削除や広すぎる権限の置き換えを推奨します。この領域はアプリ登録やGraph API利用に直結するため、開発チームとID管理チームの共同レビューが必要です。(Microsoft Learn)
運用に組み込むためのおすすめ手順
Microsoft Entra Conditional Access optimization agentを安全に使い始めるなら、次の順番がおすすめです。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 事前棚卸し | 既存の条件付きアクセスポリシー、例外、対象アプリを確認 | ポリシー一覧と例外理由が分かる状態 |
| 権限設計 | Security Administrator、Conditional Access Administrator、閲覧者を分ける | 誰が承認できるか明確 |
| エージェントID確認 | 新規はエージェントID、既存は移行可否を確認 | ユーザーコンテキスト依存を減らす |
| ナレッジ整備 | 命名規則、ブレークグラス、管理者ポリシーを文書化 | カスタム指示やナレッジベースに使える |
| 初回実行 | 手動実行し、提案だけ確認 | すぐに本番適用しない |
| 影響確認 | ポリシー影響、JSON差分、サインインログを確認 | 業務停止リスクを説明できる |
| 小規模展開 | 検証グループまたは段階的ロールアウトを使う | ヘルプデスク影響を測定 |
| 本番展開 | フェーズごとに進め、問題があればロールバック | 監査ログと変更記録が残る |
| 継続運用 | Teams通知、メモ、スヌーズ、月次レビューを運用化 | 提案が放置されない |
導入初期は、提案数を減らすよりも「なぜ提案されたか」を理解することを優先してください。条件付きアクセスの問題は、単一ポリシーの誤りではなく、複数ポリシー、例外、グループ、アプリ追加の積み重ねで起きることが多いためです。
監査と可視化で見るべき指標
Conditional Access optimization agentには、エージェントの概要やInsightsダッシュボードが用意されています。過去30日間に検出された保護されていないユーザー、アプリ、保護されたサインイン、使用されたSCUなどを確認できます。Insightsダッシュボードでは、提案適用によって対象範囲が改善されたオブジェクトや、まだ対象範囲がないオブジェクトを確認できます。(Microsoft Learn)
監査ログでは、Microsoft Entraリソースに対するエージェントの変更が記録されます。エージェントによって作成または変更された条件付きアクセスポリシーは、条件付きアクセスの最適化エージェントでタグ付けされると説明されています。監査時には、エージェントの提案、管理者の承認、ポリシー変更、サインイン影響をセットで追跡しましょう。(Microsoft Learn)
まず取るべき対応
Microsoft Entra Conditional Access optimization agentは、条件付きアクセスを継続的に改善するための強力な機能です。ただし、AIエージェントの提案であっても、最終判断は管理者が行う必要があります。特に本番環境では、SCU課金、権限、エージェントID、ブレークグラス除外、レポート専用ポリシー、段階的ロールアウトを確認してから進めてください。
最初の一歩としては、既存の条件付きアクセスポリシーを棚卸しし、ブレークグラスアカウントと主要業務アプリを明確にしたうえで、エージェントを手動実行して提案を確認するのが安全です。その後、影響の小さい検証グループでレポート専用ポリシーを確認し、問題がなければ段階的ロールアウトやパスキー導入キャンペーンへ広げていくと、セキュリティ強化と業務影響の抑制を両立しやすくなります。
コメント