AIエージェントにメールボックスや予定表、Teams、グループ経由の権限を持たせるため、「AIエージェント用ユーザーアカウント」を利用するケースが増えています。しかし、通常のユーザー向け条件付きアクセスポリシーを作成しただけでは、これらのアカウントが保護対象に含まれないことがあります。
結論から言うと、2026年7月にパブリックプレビューとして拡張されたMicrosoft Entra条件付きアクセスでは、割り当て先として「すべてのエージェントユーザー」または「選択したエージェントユーザー」を明示的に指定できます。さらに、個別アカウントやカスタムセキュリティ属性による対象・除外、エージェントリスク、実行環境、デバイスプラットフォーム、端末フィルター、準拠デバイス、準拠ネットワークを組み合わせた制御が可能です。(Microsoft Learn)
実務では、未承認エージェントのブロック、リスクの高いエージェントのブロック、エンドポイント上で動くエージェントへの準拠端末・準拠ネットワーク要求を、目的別のポリシーに分けて作成します。最初から有効化せず、レポート専用モードで影響を確認することが重要です。
Entra条件付きアクセスのAIエージェント制御がプレビューで拡張
今回の拡張対象は、AIエージェントが利用する「エージェントのユーザーアカウント」です。
Microsoft Entra Agent IDでは、AIエージェント本体を表す「エージェントID」と、ユーザーオブジェクトを必要とするサービスにアクセスするための「エージェントのユーザーアカウント」が別々に管理されます。エージェントのユーザーアカウントは任意で作成され、親となるエージェントIDと1対1で関連付けられます。(Microsoft Learn)
エージェントのユーザーアカウントは、一般ユーザーに似たユーザーオブジェクトですが、人間が利用する通常のアカウントとは異なります。パスワードやパスキーを持たず、親のエージェントIDを通じて認証されるため、通常ユーザーと同じMFA要件をそのまま適用する設計には向きません。(Microsoft Learn)
エージェントIDとエージェントユーザーの違い
| アクセス方式 | トークンの主体 | 条件付きアクセスの対象 | 主に利用できる条件・制御 |
|---|---|---|---|
| ユーザーの代理で動作するエージェント | サインインした人間のユーザー | ユーザーまたはグループ | 通常のユーザー向け条件付きアクセス |
| エージェントIDで動作する自律型エージェント | エージェントID | すべて、個別、またはブループリント単位のエージェントID | エージェントリスク。アクセス制御は原則ブロック |
| エージェントのユーザーアカウントで動作 | エージェントのユーザーアカウント | すべて、個別、または属性で選択したエージェントユーザー | エージェントリスク、実行環境、端末、OS、ネットワーク |
エージェントIDを対象にしたポリシーは、対応するエージェントのユーザーアカウントには適用されません。また、エージェントIDブループリントを対象にしても、その配下のエージェントユーザーまでは保護されません。(Microsoft Learn)
最も間違えやすい点は、「すべてのユーザー」を対象にした既存ポリシーに、エージェントのユーザーアカウントが自動的には含まれないことです。
AIエージェント用ユーザーアカウントを保護するには、ポリシーの割り当てで「エージェント」を選び、英語UIでいう「All agent users (Preview)」または「Select agent users (Preview)」を明示的に指定する必要があります。(Microsoft Learn)
設定前に確認すべきライセンスと前提条件
現時点でMicrosoftが案内している主な要件は次のとおりです。プレビュー期間中は、ライセンス要件やポータル上の名称が変更される可能性があります。(Microsoft Learn)
| 確認項目 | 要件・注意点 |
|---|---|
| 提供状況 | パブリックプレビュー |
| Entraライセンス | Microsoft Entra ID P1またはP2 |
| Agentライセンス | Microsoft Agent 365ライセンスが必要と案内されている。ライセンスの強制適用は今後予定 |
| 管理者ロール | 条件付きアクセス管理者 |
| エージェントリスク | Microsoft Entra ID Protectionのリスク情報を利用 |
| カスタムセキュリティ属性 | 属性の作成・割り当て・参照に、それぞれ専用ロールが必要 |
| 準拠端末 | Microsoft Entraに登録され、Intuneなどで準拠状態を提供できる端末 |
| 準拠ネットワーク | Global Secure AccessクライアントとMicrosoft Entra Internet Accessが必要 |
| 保護対象リソース | Microsoft Entra IDで保護され、テナントにサービスプリンシパルが存在するリソース |
カスタムセキュリティ属性を扱う場合は、条件付きアクセス管理者だけでは権限が不足することがあります。
- 属性を定義するには「Attribute Definition Administrator」
- 属性値を割り当てるには「Attribute Assignment Administrator」
- ポリシーから属性値を参照するには「Attribute Assignment Reader」または「Attribute Assignment Administrator」
グローバル管理者であっても、カスタムセキュリティ属性を自動的に読み取り、定義、割り当てできるわけではありません。(Microsoft Learn)
また、条件付きアクセスが制御できるのは、Microsoft Entra IDがアクセストークンを発行するアクセスです。AIエージェントがAPIキーを使って外部サービスへ直接接続する場合、その通信は条件付きアクセスの評価経路を通りません。(Microsoft Learn)
AIエージェント向けポリシーは目的別に分ける
複数の条件を一つのポリシーに詰め込むより、制御目的ごとにポリシーを分ける方が、レポートの確認や障害時の切り戻しが容易です。
実務では、次のような構成が分かりやすいでしょう。
| ポリシー名の例 | 目的 | 主な設定 |
|---|---|---|
| CA-AI-01-Deny-Unapproved | 未承認エージェントの拒否 | カスタムセキュリティ属性＋ブロック |
| CA-AI-02-Block-Risky | 危険なエージェントの拒否 | Agent riskがMediumまたはHighならブロック |
| CA-AI-03-Compliant-Device | 管理端末からの実行に限定 | エンドポイント実行＋準拠デバイス要求 |
| CA-AI-04-Compliant-Network | 許可ネットワーク経由に限定 | エンドポイント実行＋準拠ネットワーク要求 |
| CA-AI-05-Platform-Restriction | 許可していないOSを拒否 | エンドポイント実行＋デバイスプラットフォーム＋ブロック |
ポリシー名には、対象、目的、状態を含めておくと管理しやすくなります。検証中は末尾に「REPORT」や「PILOT」を付ける方法も有効です。
Entra条件付きアクセスポリシーを作成する基本手順
どの制御を設定する場合でも、ポリシー作成の入口はほぼ共通です。
- 条件付きアクセス管理者としてMicrosoft Entra管理センターにサインインします。
- ［Entra ID］から［条件付きアクセス］を開きます。
- ［ポリシー］を選択します。
- ［新しいポリシー］を選択します。
- 用途が分かるポリシー名を入力します。
- ［割り当て］で［ユーザー、エージェント（プレビュー）、またはワークロードID］を開きます。
- ポリシーの適用対象として［エージェント］を選択します。
- 「すべてのエージェントユーザー」または「選択したエージェントユーザー」を指定します。
- ［ターゲットリソース］で保護するリソースを指定します。
- 必要な条件とアクセス制御を設定します。
- ポリシーの状態を［レポート専用］にします。
- ［作成］を選択します。
英語UIでは、対象指定に次の選択肢が表示されます。
- All agent identities
- All agent users (Preview)
- Select agent identities
- Select agent users (Preview)
AIエージェント用ユーザーアカウントを対象にする場合は、必ず「All agent users」または「Select agent users」を選びます。(Microsoft Learn)
ターゲットリソースの選び方
ターゲットリソースでは、AIエージェントがアクセスするMicrosoft Graph、SharePoint、MCPサーバー、OpenAPIベースのツール、独自APIなどを選択します。
独自のMCPサーバーやAPIを保護する場合、そのリソースをMicrosoft Entra IDにアプリケーション登録し、APIのアクセス許可を公開しておく必要があります。条件付きアクセスの対象にするリソースには、テナント内のエンタープライズアプリケーション、つまりサービスプリンシパルが必要です。(Microsoft Learn)
リスクベースのブロックでは「すべてのリソース」を対象にする設計が適しています。一方、準拠端末やネットワーク制御を初めて導入するときは、影響範囲を確認するため、重要度の低い検証用リソースから始める方が安全です。
個別のエージェントユーザーを対象・除外する方法
少数のAIエージェントだけを管理する段階では、個別選択が最も簡単です。
［割り当て］で「Select agent users (Preview)」を選び、ポリシーを適用するエージェントのユーザーアカウントを指定します。除外設定が表示される場合は、検証用アカウントや移行中のアカウントを一時的に除外できます。(Microsoft Learn)
ただし、エージェント数が増えると、オブジェクトを一つずつ選択する運用は破綻しやすくなります。運用開始時から、承認状態や利用環境をカスタムセキュリティ属性で管理しておくと、ポリシーの対象を自動化できます。
カスタムセキュリティ属性で対象を自動分類する方法
カスタムセキュリティ属性は、エージェントユーザーに独自の分類情報を付与し、その値を条件付きアクセスの対象指定に利用する機能です。
例えば、次のような属性を用意します。
| 属性セット | 属性名 | 値の例 | 用途 |
|---|---|---|---|
| AgentGovernance | ApprovalStatus | Pending、Approved、Suspended | 利用承認状態 |
| AgentGovernance | Environment | Development、Test、Production | 実行環境 |
| AgentGovernance | DataSensitivity | Low、Internal、Confidential | 取り扱う情報の機密度 |
| AgentGovernance | Department | HR、Finance、IT | 所管部門 |
値の表記揺れを防ぐため、自由入力よりも定義済みの値から選択する方式が適しています。
カスタムセキュリティ属性を作成する
- Microsoft Entra管理センターで［Entra ID］を開きます。
- ［カスタムセキュリティ属性］を選択します。
- ［属性セットの追加］から、例えば「AgentGovernance」を作成します。
- 「ApprovalStatus」などの属性を追加します。
- データ型は条件付きアクセスで扱いやすい文字列型を選択します。
- Approved、Pending、Suspendedなどの定義済み値を登録します。
エージェントユーザーへ属性値を割り当てる
エージェントのユーザーアカウントはユーザーオブジェクトとして管理されるため、ユーザー管理画面から属性値を割り当てられます。
- ［Entra ID］から［ユーザー］を開きます。
- ［すべてのユーザー］を選択します。
- 対象のエージェントユーザーを開きます。
- ［カスタムセキュリティ属性］を選択します。
- ［割り当ての追加］を選択します。
- 属性セット、属性名、値を指定します。
- ［保存］を選択します。(Microsoft Learn)
未承認エージェントをブロックする設定例
「承認済みのエージェントだけを許可する」設計では、許可リスト方式が有効です。
- ［割り当て］で［エージェント］を選択します。
- ［含める］で［すべてのエージェントユーザー］を選択します。
- ［除外］で、カスタムセキュリティ属性を基準にしたエージェントユーザーの選択を有効にします。
- 「ApprovalStatus」が「Approved」のエージェントユーザーを除外します。
- ターゲットリソースを指定します。
- ［アクセス制御］で［アクセスのブロック］を選択します。
- ［レポート専用］で作成します。
この構成では、Approvedに分類されたエージェントだけがブロックポリシーから除外されます。属性が未設定の新規エージェントはブロック対象になるため、「登録しただけでアクセス可能になる」状態を防げます。
属性ベースでエージェントを分類すると、新しく作成されたエージェントにも、属性値に応じて自動的に同じルールを適用できます。(Microsoft Learn)
グループではなくカスタムセキュリティ属性を使う理由
エージェントのユーザーアカウント自体はMicrosoft Entraグループに追加できます。しかし、プレビュー時点では、グループメンバーシップを使ってエージェントのユーザーアカウントを条件付きアクセスポリシーの対象または除外対象にする構成はサポートされていません。(Microsoft Learn)
したがって、条件付きアクセスの適用範囲を管理する場合は、次のいずれかを使用します。
- すべてのエージェントユーザー
- 個別に選択したエージェントユーザー
- カスタムセキュリティ属性で分類したエージェントユーザー
エージェントリスクが高いアカウントをブロックする方法
「Agent risk」は、Microsoft Entra ID ProtectionがAIエージェントの挙動を分析し、侵害されている可能性をLow、Medium、Highなどのリスクレベルとして条件付きアクセスに渡す機能です。
Microsoftの構成例では、エージェントのユーザーアカウントについて、MediumまたはHighのリスクを検出した場合にアクセスをブロックします。(Microsoft Learn)
リスクベースポリシーの設定手順
- 新しい条件付きアクセスポリシーを作成します。
- ［割り当て］で［エージェント］を選択します。
- ［すべてのエージェントユーザー（プレビュー）］を含めます。
- ［ターゲットリソース］で［すべてのリソース］を選択します。
- ［条件］から［エージェントリスク（プレビュー）］を開きます。
- ［構成］を［はい］にします。
- リスクレベルとして［中］と［高］を選択します。
- ［アクセス制御］から［許可］を開きます。
- ［アクセスのブロック］を選択します。
- ポリシーを［レポート専用］で作成します。
運用初期はHighだけをブロックし、検出状況を確認してからMediumへ広げる方法もあります。ただし、Microsoftのエージェントユーザー向け構成例はMediumとHighのブロックです。
エージェントリスクだけに依存しない
現行のMicrosoft文書では、エージェントリスク検出はオフライン検出とされています。そのため、不審な動作が発生した瞬間に、必ず即座にリスクレベルが更新されるとは限りません。(Microsoft Learn)
リスクベースのポリシーに加えて、次の静的な制御も併用してください。
- 未承認エージェントを属性でブロックする
- アクセスできるリソースを必要最小限にする
- エンドポイント実行時は準拠端末を要求する
- 許可ネットワーク以外からのアクセスを拒否する
- エージェントの権限とスポンサーを定期的に確認する
また、エージェントが人間のユーザーの代理として動作するOBOフローでは、危険な動作がエージェントではなく人間のユーザー側のリスクとして扱われる場合があります。このアクセスには、通常ユーザー向けのユーザーリスク、サインインリスク、MFAポリシーも必要です。(Microsoft Learn)
AIエージェントに準拠端末を要求する方法
デスクトップ操作型のAIエージェントは、Windows 365 Cloud PC for Agentsなどの管理対象エンドポイント上で動作できます。この場合、Intuneのコンプライアンス状態を条件付きアクセスに渡し、準拠端末からのアクセスだけを許可できます。(Microsoft Learn)
準拠端末ポリシーの設定手順
- 新しい条件付きアクセスポリシーを作成します。
- ［割り当て］で［すべてのエージェントユーザー］または対象のエージェントユーザーを選択します。
- 保護するターゲットリソースを選択します。
- ［条件］から［エージェント実行環境（プレビュー）］を開きます。
- ［構成］を［はい］にします。
- ［エンドポイントから開始されたエージェントユーザーセッション］を含めます。
- ［アクセス制御］から［許可］を開きます。
- ［アクセス権の付与］を選択します。
- ［デバイスは準拠としてマーク済みである必要があります］を選択します。
- ［レポート専用］で作成します。
Microsoftの現行文書では、エージェントシナリオにおけるIntune登録と端末準拠の主な対象として、Windows 365 Cloud PC for Agentsが案内されています。(Microsoft Learn)
Agent execution environmentsを必ず組み合わせる
すべてのAIエージェントが端末上で動作するわけではありません。Copilot Studioなどのクラウドホスト型エージェントには、評価可能なデバイス情報が存在しない場合があります。
この状態で、すべてのエージェントユーザーに準拠デバイスを要求すると、クラウド上で動作するエージェントは要件を満たす手段がなく、意図せずブロックされます。
「Agent execution environments」を使って、ポリシーをエンドポイントから開始されたセッションだけに限定すれば、デバイス情報を持たないクラウドネイティブなエージェントは評価対象から除外されます。(Microsoft Learn)
デバイスプラットフォームでOSを制限する方法
エージェントのユーザーアカウントには、デバイスプラットフォーム条件も利用できます。エンドポイントで実行されるエージェントを、Windowsなどの許可したOSに限定する用途で使用します。(Microsoft Learn)
Windows以外をブロックする構成例
- ［割り当て］で対象のエージェントユーザーを選択します。
- ［エージェント実行環境］でエンドポイントから開始されたセッションを選択します。
- ［デバイスプラットフォーム］を有効にします。
- 許可しないプラットフォームをポリシーの対象にします。
- ［アクセスのブロック］を選択します。
- ［レポート専用］で検証します。
注意したいのは、デバイスプラットフォーム条件は「ポリシーを適用する範囲」を決める条件だという点です。
例えば、Windowsだけを条件に指定して準拠端末を要求しても、そのポリシーだけではmacOSやLinuxをブロックできません。macOSやLinuxはポリシーの適用範囲外になるだけです。許可したOS以外を拒否したい場合は、非許可プラットフォームを対象としたブロックポリシーを別に作成します。
また、デバイスプラットフォームはユーザーエージェント文字列など、端末側から提供される情報を利用して判定します。Microsoftも、この情報は変更可能であり、検証済みの強い信頼情報ではないと説明しています。プラットフォーム条件だけで端末を信頼せず、Intuneの準拠デバイス条件やブロック制御と組み合わせてください。(Microsoft Learn)
端末フィルターで許可デバイスを絞り込む方法
「Filter for devices」を使うと、デバイス属性を基準にして、特定端末をポリシーの対象または除外対象にできます。
設定画面では、次のいずれかを選択します。
- 条件に一致するデバイスをポリシーに含める
- 条件に一致するデバイスをポリシーから除外する
ルールビルダーまたはルール構文を使い、デバイスID、所有形態、信頼タイプなどの属性に基づいて対象を絞り込みます。エージェントユーザーに対する端末フィルターは、デバイス情報を提供できるエンドポイント上のセッションにだけ適用できます。(Microsoft Learn)
例えば、専用のWindows 365 Cloud PCだけをエージェント実行環境として認める場合は、許可端末を識別できる属性でフィルターを作成し、それ以外の端末をブロックするポリシーを用意します。
AIエージェントに準拠ネットワークを要求する方法
Global Secure Accessクライアントをエージェントの実行端末へ導入すると、条件付きアクセスは端末から提供されるネットワークシグナルを使って、準拠ネットワーク経由かどうかを評価できます。
この制御にはMicrosoft Entra Internet Accessが必要です。(Microsoft Learn)
準拠ネットワークポリシーの設定手順
- 新しい条件付きアクセスポリシーを作成します。
- ［割り当て］で［すべてのエージェントユーザー］または対象アカウントを選択します。
- ターゲットリソースを選択します。
- ［エージェント実行環境］を有効にします。
- ［エンドポイントから開始されたエージェントユーザーセッション］を選択します。
- ［アクセス制御］から［アクセス権の付与］を選択します。
- ［準拠ネットワークを要求する］を選択します。
- ［レポート専用］で作成します。
Microsoftが示している推奨構成でも、準拠ネットワークの要求と「Agent execution environments」を組み合わせ、エンドポイント上のセッションだけを対象にしています。(Microsoft Learn)
ネットワーク条件では、テナントの構成に応じて「任意の場所」や「すべての準拠ネットワークの場所」を選択できます。Global Secure Accessクライアントがないクラウド実行型エージェントはネットワークシグナルを提供できないため、端末条件と同様に実行環境によるスコープ設定が欠かせません。(Microsoft Learn)
レポート専用モードで確認すべき項目
プレビュー機能を本番テナントへ導入するときは、少なくとも次の順序で検証します。
- 検証用エージェントユーザーだけを対象にする
- ポリシーをレポート専用で作成する
- 実際に対象リソースへのアクセスを発生させる
- サインインログで適用対象になったポリシーを確認する
- デバイス、プラットフォーム、ネットワーク、リスク情報を確認する
- 想定外のブロック候補がないことを確認する
- 対象を段階的に拡大する
- 最後にポリシーを有効化する
エージェント関連のサインインは、Microsoft Entra管理センターの［監視と正常性］にあるサインインログで確認できます。「Agent type」を「Agent ID user」にしたり、「Is Agent」を「Yes」にしたりすると、AIエージェントに関連するログを絞り込めます。(Microsoft Learn)
条件付きアクセスのWhat Ifツールも、どのポリシーが適用されるかを事前に確認するために利用できます。ただし、実際の端末状態やネットワークシグナルを含む評価では、What Ifの結果だけに頼らず、実サインインログも確認してください。(Microsoft Learn)
設定時によくある失敗
| 失敗例 | 問題点 | 修正方法 |
|---|---|---|
| 「すべてのユーザー」ポリシーだけを作成する | エージェントユーザーが含まれない | 割り当てでエージェントユーザーを明示する |
| エージェントID向けポリシーだけを作成する | 対応するユーザーアカウントには適用されない | エージェントIDとエージェントユーザーに別ポリシーを作る |
| ブループリントを対象にすればユーザーアカウントも守られると考える | ブループリントの対象はエージェントIDのみ | エージェントユーザーを別途対象にする |
| グループを使って対象・除外する | プレビュー時点ではサポートされない | 個別選択またはカスタムセキュリティ属性を使う |
| すべてのエージェントに準拠端末を要求する | デバイス情報を持たないクラウド型エージェントがブロックされる | Agent execution environmentsでエンドポイントに限定する |
| OS条件だけで端末を信頼する | プラットフォーム情報は強い検証情報ではない | 準拠デバイスや端末フィルターを併用する |
| APIキーによるアクセスも保護できると考える | Entraのトークン発行を通らない | Entra認証へ移行するか、API側の認証・ネットワーク制御を追加する |
| 作成直後にポリシーを有効化する | 想定外のアクセス停止が起きる | レポート専用から段階的に展開する |
これらの制約は、エージェントID、エージェントユーザー、通常ユーザーを別の主体として扱うことで理解しやすくなります。(Microsoft Learn)
まず実施すべき導入手順
Entra条件付きアクセスをAIエージェント用ユーザーアカウントへ適用する場合は、次の順序で進めると安全です。
- テナント内のエージェントIDとエージェントユーザーを一覧化する
- 各エージェントの用途、所有者、スポンサー、利用リソースを確認する
- ApprovalStatusやEnvironmentなどのカスタムセキュリティ属性を定義する
- 未承認エージェントをブロックするポリシーをレポート専用で作成する
- MediumまたはHighのエージェントリスクをブロックする
- エンドポイント型エージェントに準拠端末を要求する
- 必要に応じて準拠ネットワークとプラットフォーム制限を追加する
- サインインログで影響を確認し、段階的に有効化する
特に重要なのは、「すべてのユーザー」や「すべてのエージェントID」に既存ポリシーを設定しただけで、AIエージェント用ユーザーアカウントも保護できていると判断しないことです。
エージェントユーザーを明示的に対象へ含め、カスタムセキュリティ属性による分類、Agent risk、Agent execution environments、準拠端末、準拠ネットワークを目的別に組み合わせることで、AIエージェントの自律性を維持しながら、アクセス範囲を現実的に制御できます。
コメント