Microsoft Entra Agent IDの今回の更新で重要なのは、AIエージェントを単なるアプリやボットではなく、責任者、固有ID、アクセス権、利用期限を持つ業務主体として管理する仕組みが具体化されたことです。
結論から言えば、これは緊急適用が必要なセキュリティパッチではありません。ただし、AIエージェントがMicrosoft Graphのアプリケーション権限、Microsoft Entraのロール、Microsoft 365上のデータへアクセスしている組織は、早めに対応すべきガバナンス強化です。
優先して行うべきことは、次の3点です。
- 各AIエージェントに固有のIDとスポンサーを割り当てる
- 権限を期限付きのアクセスパッケージで付与する
- スポンサーの異動・退職時に、Lifecycle Workflowsで責任を引き継ぐ
Microsoftが2026年7月7日に公開した公式情報では、Microsoft Entra Agent IDによってAIエージェントにも説明責任のあるID、アクセスガバナンス、ライフサイクル自動化を持たせる方針が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra Agent IDの今回の発表で何が変わるのか
Microsoft Entra Agent IDは、AIエージェント向けに設計されたIDおよびセキュリティの基盤です。
従来のサービスプリンシパルやマネージドIDによる認証だけでなく、AIエージェントに固有のIDを与え、誰が責任を持つのか、どの権限を持つのか、いつ利用を終了するのかまで一貫して管理します。
今回の「Microsoft Entra Agent ID brings accountable identities, access governance, and lifecycle automation to AI agents」という説明は、次の3つに整理できます。
| 要素 | 何を実現するか | 管理者が確認すること |
|---|---|---|
| Accountable identities | 各エージェントに固有IDと人間のスポンサーを関連付ける | 責任者不在のエージェントがないか |
| Access governance | 承認、期限、更新を伴うアクセスパッケージで権限を管理する | 無期限の権限や過剰な権限がないか |
| Lifecycle automation | スポンサーの異動・退職に合わせて責任の移管や通知を自動化する | 人事異動後も放置されるエージェントがないか |
ポイントは、AIエージェントを「誰かが作ったアプリ」として管理するのではなく、従業員や外部委託者に近いガバナンス対象として扱うことです。
一方で、人間とまったく同じIDとして扱うわけではありません。エージェント固有のオブジェクト、スポンサー、ブループリント、オプションのエージェントユーザーアカウントを組み合わせ、AIエージェント特有の自律実行や大量展開に対応します。(Microsoft Learn)
対応が必要かを判断する基準
Microsoft Entra Agent IDを利用していない組織まで、直ちに設定変更を行う必要はありません。ただし、名称が「AIエージェント」でなくても、バックグラウンドで自律的に処理を行うアプリやCopilot、ワークフローが存在する場合は確認が必要です。
| 優先度 | 該当する状況 | 推奨する対応 |
|---|---|---|
| 高 | 本番環境のエージェントがMicrosoft Graphのアプリケーション権限を持つ | 直ちにID、スポンサー、権限、ログを棚卸しする |
| 高 | エージェントにEntraロールや重要グループのメンバーシップを付与している | アクセスパッケージと承認期限へ移行する |
| 高 | 責任者が分からないエージェントや共有資格情報がある | スポンサーを設定し、共有IDを廃止する |
| 高 | エージェントユーザーアカウントを使用している | エージェントIDとは別に条件付きアクセスを確認する |
| 中 | 検証環境でAgent IDやCopilot Studio、Azure AI Foundryを試している | 本番展開前に管理基準とライセンスを確認する |
| 中 | 数か月以内に複数部門へAIエージェントを展開する | ブループリント単位のポリシーを先に設計する |
| 低 | AIエージェントを利用しておらず、導入予定もない | 緊急対応は不要。ただし導入時の申請ルールを決めておく |
特に優先度が高いのは、エージェントがユーザーの代理ではなく、アプリケーション権限によって自律的に動作するケースです。人間の操作を待たずにメール、ファイル、ユーザー情報、業務データへアクセスできるため、責任者と停止方法を明確にしておく必要があります。
Microsoft Entra Agent IDが管理する保護対象
4種類のIDオブジェクトを理解する
Microsoft Entra Agent IDでは、主に次のオブジェクトを使用します。
| オブジェクト | 役割 | 管理上の注意点 |
|---|---|---|
| Agent identity blueprint | 同じ種類のエージェントを作成するためのテンプレート | 条件付きアクセスやガバナンス設定を共通化できる |
| Agent identity blueprint principal | ブループリントを利用してエージェントIDを作成するプリンシパル | 不正利用されると多数のIDを作成される可能性がある |
| Agent identity | 個々のAIエージェントに割り当てる固有ID | スポンサー、権限、アクティビティーを個別に追跡する |
| Agent user | 必要に応じて作成するユーザー型のアカウント | Agent identityとは別のプリンシパルとしてポリシーを設定する |
Agent identity blueprintは、エージェントの種類ごとに設定を共通化するための基盤です。たとえば、「社内FAQエージェント」「請求書処理エージェント」「人事問い合わせエージェント」など、用途ごとにブループリントを分けられます。
ブループリントへ設定したポリシーを、既存および将来作成されるエージェントへ適用できるため、大量展開時に個別設定がばらつく問題を抑えられます。(Microsoft Learn)
ブループリントプリンシパルは強い権限を持つ
Agent identity blueprint principalには、配下のエージェントIDを作成するための権限が自動的に付与されます。
この作成権限は個別に取り消せないため、エージェントIDの追加を止めたい場合は、ブループリントプリンシパル自体を無効化または削除する必要があります。管理者は、不要になったブループリントプリンシパルを有効なまま放置しないことが重要です。(Microsoft Learn)
Microsoft以外のAIエージェントも対象にできる
Microsoft Entra Agent IDは、Microsoft製のAIエージェントだけに限定された仕組みではありません。
Azure AI Foundry、Copilot Studio、Microsoft Teams向けエージェント、Azure App Service、Azure Functionsなどに加え、Microsoft以外のエージェントも、Entra Auth SDKのサイドカーやワークロードIDフェデレーションを利用して統合できます。
したがって、「外部製品だからEntra Agent IDとは無関係」とは限りません。外部製のAIエージェントがMicrosoft 365や社内APIへアクセスしている場合も、認証方式とID管理方法を確認する必要があります。(Microsoft Learn)
Agent IDだけでは保護できない範囲もある
Microsoft Entra Agent IDが主に保護するのは、ID、認証、アクセス権、ライフサイクルです。
次の問題を単独で解決する機能ではありません。
- プロンプトインジェクションによる不正な指示
- AIモデルが生成する回答内容の正確性
- 機密データの分類や持ち出し防止
- エージェントが外部ツールへ送信する入力内容
- SharePointや業務システム内で行われた個別操作の完全な追跡
そのため、Entraの監査ログだけでなく、Microsoft Graph、SharePoint、Teams、Azure、業務アプリなど、アクセス先の監査ログも合わせて確認する運用が必要です。
管理者が設定すべき項目
Owner、Sponsor、Managerの役割を分ける
Microsoft Entra Agent IDでは、技術的な管理者と業務上の責任者を分離できます。
| 役割 | 主な責任 | 必須か |
|---|---|---|
| Owner | 設定、構成、資格情報などの技術管理 | 任意 |
| Sponsor | 利用目的、存続、アクセス権、更新、停止に関する業務上の説明責任 | 原則必須 |
| Manager | 組織階層に基づく管理や、配下のエージェントに対するアクセス申請 | 任意 |
Sponsorは、単にエージェントを作成した担当者を設定すればよいわけではありません。
適切なのは、そのエージェントの利用継続や停止を判断できる業務責任者です。たとえば、経理処理エージェントなら経理部門の責任者、採用支援エージェントなら人事部門の責任者をスポンサーにします。
技術担当者だけをスポンサーにすると、エージェントが何の業務に必要なのか、権限を更新してよいのかを判断できない場合があります。Microsoftの設計でも、Ownerは技術管理、Sponsorは業務上の説明責任を担う役割として分けられています。(Microsoft Learn)
実務では、次の運用が安全です。
- スポンサーは個人だけでなく、組織変更に耐えられる管理方法を検討する
- 主担当者以外の共同スポンサーまたは代替連絡先を設定する
- スポンサーが権限更新を判断できる情報を申請時に記録する
- OwnerとSponsorを同一人物に固定しない
- 四半期または半年ごとにスポンサー不在のエージェントを確認する
最小権限の管理ロールを割り当てる
2026年7月時点の公式ドキュメントでは、主な作成操作に必要なロールは次のように整理されています。
| 操作 | 使用できる主な管理ロール |
|---|---|
| Agent identity blueprintの作成 | Agent ID Developer、Agent ID Administrator |
| Agent identityの作成 | Agent ID Developer、Agent ID Administrator、AI Administrator |
| Agent userの作成 | Agent ID Administrator、User Administrator |
すべての担当者へGlobal Administratorを付与する必要はありません。開発担当者にはAgent ID Developer、全体管理者にはAgent ID Administratorなど、職務に応じた最小権限を使用します。(Microsoft Learn)
アクセスパッケージで権限を期限付きにする
Microsoft Entra ID GovernanceのEntitlement Managementでは、AIエージェント向けにアクセスパッケージを作成できます。
アクセスパッケージには、次のような権限をまとめられます。
- セキュリティグループのメンバーシップ
- アプリケーションのOAuth API権限
- Microsoft Graphのアプリケーション権限
- Microsoft Entraのディレクトリロール
これにより、エージェントへ個別に永続的な権限を付与するのではなく、申請、承認、利用期限、更新を伴う形で管理できます。(Microsoft Learn)
アクセスパッケージ設定の基本手順
- Microsoft Entra管理センターで「ID Governance」を開く
- 「Entitlement management」からカタログとアクセスパッケージを作成する
- エージェントに必要なグループ、API権限、ロールだけを追加する
- 割り当てポリシーで、エージェントIDを申請対象にする
- スポンサーやリソース所有者による承認を設定する
- 有効期限と延長時の再承認を設定する
- 期限切れ後に権限が実際に削除されるかテストする
割り当てポリシーでは、対象としてFor users, service principals, and agent identities in your directoryを選び、必要に応じてAll agentsを指定できます。
ただし、All agentsは「すべてのエージェントに自動で権限を付与する」という意味ではありません。アクセスを申請できる対象範囲を示します。承認者、期限、申請理由を別途設定することが重要です。
スポンサーやOwnerは、My Accessから自分が担当するエージェントを選び、代理でアクセスパッケージを申請できます。管理者による直接割り当てや、エージェントからのプログラムによる申請もサポートされます。(Microsoft Learn)
権限期限の運用例
すべてのエージェントへ一律の期限を設定する必要はありません。リスクに応じて期限を分けます。
| 権限の種類 | 期限の例 | 更新時の確認 |
|---|---|---|
| 検証環境の読み取り権限 | 30日 | 検証継続の必要性 |
| 一般業務データへのアクセス | 90日 | 利用実績とスポンサー承認 |
| Microsoft Graphの高権限 | 30～90日 | 権限範囲と監査ログ |
| Entraロール | 必要最小期間 | 管理者と業務責任者の再承認 |
これは推奨運用の例です。実際の期限は、エージェントの自律性、アクセスするデータの機密性、停止時の業務影響を基に決めます。
Lifecycle Workflowsでスポンサーの異動・退職に対応する
AIエージェントの権限を期限付きにしても、スポンサーが退職したままでは更新判断ができません。
Lifecycle Workflowsでは、スポンサーの異動や退職に伴って次の処理を自動化できます。
- スポンサー変更をManagerへ通知する
- 共同スポンサーへスポンサー変更を通知する
- エージェントのスポンサーシップをManagerへ移管する
これらは主にMoverおよびLeaver向けのタスクです。Microsoft Entra管理センターの「ID Governance」から「Lifecycle workflows」を開き、ワークフローへスポンサー関連タスクを追加します。(Microsoft Learn)
自動移管を正しく動作させるには、Microsoft Entra ID上のManager属性が正確であることが前提です。退職処理の自動化を始める前に、次を確認します。
- スポンサーにManagerが設定されているか
- Managerが無効なユーザーになっていないか
- 部門長や兼務者の組織情報が最新か
- 共同スポンサーへの通知先が有効か
- Managerが新しいスポンサーとして適切か
Manager属性が欠けている組織では、自動移管だけに依存せず、例外リストや管理者への通知を用意する必要があります。
条件付きアクセスはプリンシパルごとに確認する
アクセスパッケージと条件付きアクセスは、目的が異なります。
- アクセスパッケージは「何へアクセスできるか」を管理する
- 条件付きアクセスは「どの条件ならアクセスを許可するか」を管理する
Microsoft Entra Agent IDでは、エージェントのリスクやコンテキストを基に条件付きアクセスを適用できます。また、ブループリント単位で設定し、同じ種類のエージェントへ共通ポリシーを適用する方法もあります。(Microsoft Learn)
注意したいのは、Agent identityとAgent userが別のプリンシパルであることです。
Agent identityを対象にしたポリシーは、オプションで作成したAgent userへ自動的に適用されるとは限りません。両方を使用する場合は、それぞれのサインイン方式とポリシー対象を確認します。(Microsoft Learn)
条件付きアクセスは、次の順番で導入すると安全です。
- 対象となるブループリントとエージェントIDを限定する
- レポート専用モードで影響を確認する
- ユーザー代理実行と自律実行を別々にテストする
- 高リスクのエージェントをブロックするポリシーを検証する
- 正常な処理を妨げないことを確認してから適用する
監査ログとリスク検知への影響
エージェントの作成経路を監査できる
Microsoft Entra Agent IDで作成されたIDは、Microsoft Entraの監査ログへ記録されます。
管理者ポータル、Microsoft Graph API、PowerShell、CLI、製品統合、ブループリントプリンシパルなど、どの経路から作成されたかを確認できます。大量のエージェントIDが短時間に作成された場合や、想定外の作成経路が使われた場合の検知に役立ちます。(Microsoft Learn)
監査では、少なくとも次の操作を追跡対象にします。
- Agent identity blueprintの作成、変更、削除
- Blueprint principalの作成、無効化、削除
- Agent identityの作成、無効化、削除
- SponsorおよびOwnerの変更
- Agent userの作成
- アクセスパッケージの割り当て、延長、失効
- 条件付きアクセスポリシーの変更
- 高権限グループやEntraロールへの追加
Risky Agentsでエージェント固有のリスクを確認する
Microsoft Entra ID Protectionには、Agent IDを持つAIエージェントのリスクを確認するRisky Agentsレポートがあります。
公式ドキュメントでは、次のようなリスク検知が案内されています。
- 侵害済みとして確認されたエージェント
- 作成直後の悪意あるアクティビティー
- Microsoft Entraディレクトリの偵察
- 失敗したアクセス試行
- Microsoft Entra Threat Intelligenceによる検知
- サインインの急増
- 不審な資格情報の使用
- 通常とは異なるリソースへのアクセス
Risky Agentsでは、侵害済みとして確認、問題なしとして確認、リスクの無視、エージェントの無効化といった対応が可能です。検知結果は、診断設定を使用してLog Analytics、ストレージアカウント、イベントハブ、SIEMへ転送できます。(Microsoft Learn)
リスク検知は即時とは限らない
2026年7月時点の公式ドキュメントでは、エージェント向けリスク検知はオフライン検知とされています。
つまり、異常な動作が発生した直後に必ずRisky Agentsへ表示されるとは限りません。検知結果だけに依存せず、条件付きアクセス、アクセス先の監査ログ、SIEMのアラートを組み合わせる必要があります。
また、エージェントのリスク検知情報は最大90日保持されます。長期的な調査や監査が必要な組織は、診断設定による外部保存を検討します。(Microsoft Learn)
On-Behalf-Ofではユーザー側にリスクが記録される
ユーザーの代理としてエージェントが処理するOn-Behalf-Ofフローでは、リスクのある動作がエージェントではなく、代理元のユーザーへ関連付けられる場合があります。
そのため、Risky Agentsだけを確認すると、ユーザー代理型エージェントの異常を見落とす可能性があります。
監視対象は次のように分けます。
| 実行方式 | 主に確認する対象 |
|---|---|
| エージェント自身のアプリケーション権限で自律実行 | Agent identity、Risky Agents、ワークロードサインイン |
| ユーザーの代理で実行 | ユーザーのサインインリスク、対象エージェント、委任権限 |
| Agent userとして実行 | Agent userのサインイン、Agent identityとの関連 |
| 外部APIや業務システムを操作 | アクセス先システムの監査ログ |
Microsoft Entraのログだけで、エージェントが業務システム内で行ったすべての操作内容を再現できるとは限りません。インシデント調査では、エージェントID、スポンサー、サインイン、APIアクセス、リソース側の操作ログを時系列で突き合わせます。(Microsoft Learn)
管理者が優先すべき対応
最初の1週間で行うこと
まず、新しいポリシーを作成する前に、既存のAIエージェントを棚卸しします。
最低限、次の情報を一覧化します。
- エージェント名と用途
- Agent identityとブループリント
- Blueprint principal
- Agent userの有無
- SponsorとOwner
- 利用部門
- Microsoft Graphの権限
- グループメンバーシップ
- Microsoft Entraロール
- 自律実行かユーザー代理実行か
- 本番、検証、開発の区分
- 最終利用日時
- 停止手順
スポンサーが未設定、用途が不明、最終利用日時が確認できないエージェントは、優先的な調査対象にします。
2週間以内に行うこと
棚卸し後は、特に機密性の高いリソースからアクセスパッケージへ移行します。
最初から全エージェントを対象にするより、次のような高リスクのエージェントを1つ選び、設定と失効のテストを行う方法が現実的です。
- Microsoft Graphのアプリケーション権限を持つ
- ユーザー、グループ、メール、ファイルを変更できる
- 夜間や無人で定期実行される
- 複数部門のデータへアクセスする
- 外部サービスとデータを送受信する
アクセスパッケージを作成したら、付与だけでなく、期限切れ時の権限削除まで確認します。失効後もキャッシュや既存のセッションでアクセスできる場合があるため、トークン更新後の動作もテストします。
30日以内に行うこと
アクセス権の整理後、次の運用を追加します。
- スポンサーの異動・退職に対応するLifecycle Workflows
- Agent identityとAgent userを分けた条件付きアクセス
- Risky Agentsの定期確認
- 監査ログとリスク検知のSIEM転送
- 不要なBlueprint principalの無効化
- インシデント時の停止手順
- 権限更新時の再承認ルール
- 新しいエージェントを作成する際の申請手続き
条件付きアクセスは、いきなり全体へ強制せず、レポート専用モードと限定対象で影響を確認します。
インシデント対応手順も事前に決めておく
AIエージェントに不審な動作が見つかった場合、担当者を探している間にも自律処理が続く可能性があります。
あらかじめ、次の対応手順を文書化します。
- 対象のAgent identity、Agent user、Blueprint principalを特定する
- エージェントを無効化し、新しいトークン発行を止める
- アクセスパッケージの割り当てを削除または失効させる
- Microsoft Graph権限、グループ、Entraロールを確認する
- SponsorとOwnerへ連絡する
- Entraのサインイン、監査、リスク検知を調査する
- SharePoint、Teams、Exchange、Azure、業務アプリのログを確認する
- ブループリント配下の他エージェントへ影響がないか調べる
- 原因と影響範囲を確認してから再有効化を判断する
個別のエージェントだけでなく、同じブループリントから作成されたエージェント全体を停止または制限できる点も重要です。共通設定や作成元が侵害された場合は、エージェント単位ではなくブループリント単位で対応します。(Microsoft Learn)
導入時に失敗しやすいポイント
Sponsorを技術担当者だけにする
技術担当者は設定方法を理解していても、エージェントを継続すべきか判断できるとは限りません。
Sponsorには業務上の責任者を設定し、技術担当者はOwnerとして管理する方法が適切です。
Agent identityだけに条件付きアクセスを設定する
Agent userを併用している場合、Agent identityだけを対象にした条件付きアクセスでは十分でない可能性があります。
両者は別のプリンシパルとして扱い、サインインログとポリシー適用結果を個別に確認します。
アクセスパッケージを作っただけで安心する
アクセスパッケージに期限や承認者を設定しなければ、永続的な直接付与と大きく変わりません。
承認、期限、延長時の再承認、失効テストまでを一つの設定として扱います。
All agentsへ広すぎる申請権限を与える
All agentsを選択すると、多数のエージェントが申請対象になります。
機密性の高いアクセスパッケージでは、対象ブループリント、承認者、申請理由、期限を絞り込みます。
Manager属性を確認せず自動移管を有効にする
スポンサーのManagerが未設定の場合、想定どおりに責任を引き継げない可能性があります。
Lifecycle Workflowsを設定する前に、対象となるスポンサーの組織情報を検査します。
Risky Agentsをリアルタイム監視だと考える
エージェント向けリスク検知は、2026年7月時点ではオフライン処理を含みます。
緊急停止が必要なインシデントは、Risky Agentsへの表示を待たず、他のログやアラートを基に対応します。
Entraログだけですべての操作を追跡できると考える
Entraログは、ID、認証、権限、サインインの調査に有効です。一方で、エージェントがアクセス先で行った業務操作は、各サービス側のログ確認が必要です。
調査時に共通のエージェントIDでログを関連付けられるよう、アクセス先でも主体を記録できる構成にします。
プレビュー状態とライセンスを確認する
Microsoft Entra Agent IDの基盤自体と、エージェント向けIDガバナンスの各機能は、提供状態が同一ではありません。
2026年7月時点では、エージェント向けIDガバナンスにはプレビューとして案内されている機能が含まれています。画面、ライセンス条件、設定項目、制限事項が変更される可能性があるため、本番展開前に最新の公式ドキュメントを確認する必要があります。(Microsoft Learn)
公式ドキュメントでは、主に次のライセンス構成が案内されています。
| 機能 | 確認すべき主なライセンス |
|---|---|
| Agent IDの基本プラットフォーム | Microsoft Entraテナントでの利用可否 |
| エージェント向けID Governance | Microsoft 365 E7、またはMicrosoft Agent 365と必要なEntraライセンス |
| Lifecycle Workflows | Microsoft 365 E7、またはMicrosoft Agent 365とMicrosoft Entra ID P1など |
| リスクベースの保護 | Microsoft Entra ID P2とAgent 365の要件 |
| ネットワーク制御 | Microsoft Entra Internet Access |
一部のAgent 365ライセンス要件は段階的に適用されるものとして案内されています。契約中のMicrosoft 365プランだけで判断せず、対象ユーザー、管理者、エージェントごとのライセンス要件を確認します。(Microsoft Learn)
まず1つの高リスクエージェントから管理を始める
Microsoft Entra Agent IDの今回の強化は、AIエージェントに対して「誰が責任を持つのか」「どの権限をいつまで与えるのか」「担当者が退職したらどうするのか」を明確にするものです。
管理者が最初に行うべき対応は、全機能を一度に有効化することではありません。
まず、本番環境で強い権限を持つAIエージェントを1つ選び、次の流れを通して動作を確認します。
- 固有のAgent identityを確認する
- 業務上のSponsorを割り当てる
- 権限を期限付きアクセスパッケージへ移行する
- スポンサー退職時の移管をテストする
- 条件付きアクセスをレポート専用モードで評価する
- 監査ログとRisky AgentsをSIEMへ連携する
- エージェントを停止し、権限が失効するところまで試験する
この一連の運用をテンプレート化したうえで、ブループリント単位に他のAIエージェントへ展開すると、設定のばらつきと管理負荷を抑えられます。
コメント