Microsoft が 2026年4月7日に公開したブログの結論は明快です。エンタープライズ AI エージェントを安全に動かすには、エージェントに ID を付けるだけでは足りません。各ツール実行の直前に、業務ポリシー、データ境界、承認閾値まで含めて可否を判断する「ランタイム認可」を、共通のコントロールプレーンとして置く必要があります。ブログでは、この役割を担う共有の Authorization Fabric を、Microsoft Entra で保護されたエンドポイントとして実装する考え方が示されました。 (TECHCOMMUNITY.MICROSOFT.COM)
背景にあるのは、AI エージェントが単に回答するだけでなく、API を呼び、ツールを実行し、他エージェントや業務システムと連携しながら自律的に処理を進めるようになったことです。Microsoft の Cloud Adoption Framework でも、こうしたエージェント群を組織全体で可視化し、同一ポリシーで統制する中央コントロールプレーンが必要だと整理されています。この記事では、Microsoft の発信を踏まえて、AI エージェントのセキュリティ ガバナンスで何を設計し、どこで失敗しやすいのかを実務目線で解説します。 (Microsoft Learn)
Microsoft が示した AI エージェントのランタイム認可の要点
今回の内容は、単なる新機能紹介というより、Copilot Studio や AI Foundry / Semantic Kernel など複数の実装方式に共通する reference architecture の提案として読むのが適切です。Microsoft は、Entra Agent Identity が「そのエージェントは誰か」を管理する一方で、実行時には共有の Authorization Fabric が「その行為を今この条件で実行してよいか」を判定する構成を示しています。判断結果は ALLOW / DENY / REQUIRE_APPROVAL / MASK の4系統で、ここが実質的な運用上のコントロールプレーンになります。 (TECHCOMMUNITY.MICROSOFT.COM)
まず整理したい「認証」「認可」「承認」の違い
| 用語 | この記事での意味 |
|---|---|
| 認証 | エージェントが誰かを確認する層です。Microsoft Entra Agent ID は、AI エージェント向けの専用 ID とセキュリティ フレームワークを提供します。 (Microsoft Learn) |
| 認可 | ツールや API の実行を許可するかを runtime で判定する層です。Microsoft のブログでは、RBAC・ABAC・承認ポリシーをまとめて評価する仕組みとして Authorization Fabric が提示されています。 (TECHCOMMUNITY.MICROSOFT.COM) |
| 承認 | 高リスク操作に人のレビューを挟む段階です。decision は REQUIRE_APPROVAL として返せます。 (TECHCOMMUNITY.MICROSOFT.COM) |
ここを混同すると設計が崩れます。認証だけ整えても、購買金額の上限、越境データの扱い、機密情報のマスキング、危険操作の人手承認といった「業務上の妥当性」は担保できません。Microsoft のブログが強調しているのも、まさにこの差です。 (TECHCOMMUNITY.MICROSOFT.COM)
なぜ AI エージェントのランタイム認可が中核コントロールプレーンになるのか
ID だけでは業務上の可否を判断できない
Microsoft は、OAuth や API 権限が答えられるのは「その API を呼べるか」までであり、「その操作を業務ポリシーやコンプライアンス条件の下で実行すべきか」までは判断しないと指摘しています。マルチエージェント環境では、同じバックエンドに対して複数のエージェントが委任権限で並列に触るため、自律実行のスプロールが起きやすく、ID だけでは統制が追いつきません。 (TECHCOMMUNITY.MICROSOFT.COM)
実行時にしか分からない条件が増えている
Zero Trust の観点でも、エージェントは「質問に答える UI」ではなく、ツールを呼び出すソフトウェア主体として扱う必要があります。Microsoft のガイダンスでは、実行時に未信頼コンテンツや API と相互作用する場面こそ安全機構が必要であり、高リスク操作には決定論的な human-in-the-loop、最小権限、ツール呼び出しのガードレールが必要だとされています。 (Microsoft Learn)
ポリシーを中央化しないと運用が破綻する
ポリシーを各エージェントの中に個別実装すると、変更のたびに再配布が必要になり、監査も統一できません。Microsoft のブログは、ポリシーを Cosmos DB などの中央ストアに外出しし、バージョン管理やロールバックを可能にすることで、ポリシー変更を全エージェントへ一貫適用できる構成を推奨しています。 (TECHCOMMUNITY.MICROSOFT.COM)
Authorization Fabric の構成と実務上の意味
Authorization Fabric は、実行前ゲートとしての PEP（Policy Enforcement Point）と、判断エンジンとしての PDP（Policy Decision Point）を組み合わせたものです。各エージェントはツールや業務 API を直接叩く前にこの Fabric を呼び、RBAC、ABAC、承認ポリシーを評価したうえで ALLOW / DENY / REQUIRE_APPROVAL / MASK を受け取ります。Microsoft は、エージェントが事前判定なしに業務ツールを直接呼ばないこと、そして ID・意図・実行を別々に強制することを重要な信頼境界として挙げています。 (TECHCOMMUNITY.MICROSOFT.COM)
実装例として示されたのは、Azure Functions もしくは App Service 上に /authorize エンドポイントを用意し、Microsoft Entra の built-in authentication で保護する形です。さらに本番寄りの構成では、IP 制限や Private Endpoint、APIM によるレート制御・リクエスト正規化・集中ログを重ねるのが推奨されています。 (TECHCOMMUNITY.MICROSOFT.COM)
見落としやすいのは、ツール実行への抜け道を作らないことです。ブログは、Copilot Studio の別トピックや別分岐から認可チェックを迂回して実行できてはいけないと明記しています。つまり、認可は「呼んだほうがよい機能」ではなく、「通らないと実行不能」な設計で置くべきです。 (TECHCOMMUNITY.MICROSOFT.COM)
安全な評価順序
評価順序も固定したほうが安全です。Microsoft の例では、まず tenant isolation と data residency を hard deny し、その次に classification に応じて deny または mask を決め、続いて RBAC の entitlement、金額やリスクの閾値、最後に step-up approval を挿入する流れになっています。この順序にしておくと、本来は越境アクセスや機密度違反で止めるべき操作が、承認ワークフロー経由で「救済」される事故を防げます。 (TECHCOMMUNITY.MICROSOFT.COM)
1分で分かる具体例
たとえば、財務エージェントに 70,000 の発注書作成を依頼するケースでは、ユーザーにもエージェントにも ERP API を呼ぶ権限があっても、それだけでは不十分です。Microsoft の例では、この場面で runtime policy が REQUIRE_APPROVAL を返し、承認完了後にだけ実行が進みます。これが「API にアクセスできること」と「業務として実行してよいこと」の違いです。類似の考え方は、地域外データへのアクセスを DENY にする、PII を含む応答だけ MASK にする、といった運用にもそのまま広げられます。 (TECHCOMMUNITY.MICROSOFT.COM)
Copilot Studio / Foundry / Entra / Purview での実装イメージ
この考え方は 1 つの製品だけで完結するものではありません。Microsoft の現行ドキュメントを実務向けに読むと、ID は Entra、データ統制は Purview、挙動監視は Entra ログや Azure Monitor、必要に応じて Defender を組み合わせ、ランタイム認可そのものは共通エンドポイントとして切り出すのが現実的です。 (Microsoft Learn)
Microsoft Entra Agent ID
Microsoft Entra Agent ID は、AI エージェント向けの専用 ID とセキュリティ フレームワークです。agent identity、blueprint、条件付きアクセス、Identity Protection、ライフサイクル管理、監査ログまでを一元化でき、OAuth 2.0、MCP、A2A といった標準プロトコルも前提にしています。一方で Microsoft は、agent identity に多くの高権限ロールを付与できないよう制限しており、AI エージェントを単なる汎用アプリ登録として扱わず、専用フレームワークで管理することを推奨しています。なお、2026年4月時点の Entra Agent ID 関連ドキュメントには preview の注意が付いています。 (Microsoft Learn)
Copilot Studio
Copilot Studio では、Entra Agent ID の自動作成機能が preview として案内されており、新しいエージェントに対して環境レベルで agent identity を自動付与できます。ブログの実装案でも、Copilot Studio からは HTTP Request ノード、または Agent Flow（Power Automate）経由で Authorization Fabric を呼ぶ構成が推奨されています。ただし、既知の問題として、現時点では custom engine agent が中心で、agent ID は Copilot Studio のコネクタやツール認証そのものにはまだ使われていない点に注意が必要です。 (Microsoft Learn)
Microsoft Foundry
Microsoft Foundry は agent identity を自動プロビジョニングし、ツール呼び出し時には downstream service 向けの scoped token を発行します。実務で特に重要なのは、未公開エージェントは project 共有 ID を使う一方、公開すると distinct agent identity に切り替わることです。公開後に権限エラーが出る典型は、古い shared identity にだけ RBAC を付けたまま、新しい agentIdentityId に再割り当てしていないケースです。また、audience は MCP サーバーの URL ではなく、Azure Storage や Graph など下流サービスの resource identifier に合わせないと認証に失敗します。 (Microsoft Learn)
Microsoft Purview と監査
データ統制側では Microsoft Purview が重要です。Purview は、AI アプリやエージェントのランタイム データに対するリアルタイム分析、監査、Communication Compliance、ライフサイクル管理、DLP を提供し、Agent Framework では prompts / responses をミドルウェアで取り込んでポリシー適用する構成も示されています。加えて、ブログが挙げる最低限の監査項目――agentId、userUPN、action、resource、decision、reason、policyIds、approval outcome、correlationId――を残しておくと、後から「なぜこの自律操作が実行されたのか」を説明しやすくなります。 (Microsoft Learn)
導入前に決めるべき6つの項目
導入を始めるなら、いきなり全社展開するより、まずは高リスクだが範囲が限定しやすい 1 操作で PoC を作るのが現実的です。次の 6 項目が決まっていない状態では、ランタイム認可を入れても形だけで終わりやすくなります。
- 台帳と責任者を先に決める。
全エージェントを inventory 化し、用途、所有者、スポンサー、アクセス範囲を管理します。小規模なら手作業でもよいですが、規模が出るなら Entra Agent ID や agent registry を正本にしたほうが shadow AI を防ぎやすくなります。 (Microsoft Learn) - ID 設計を trust boundary で分ける。
同じ runtime・同じ team・同じ secrets を共有する群なら 1 blueprint 配下で複数 agent identity にし、別 platform や別 team で trust boundary が変わるなら blueprint を分けます。各 agent instance に固有 ID を持たせることも重要です。 (Microsoft Learn) - 権限は default deny から始める。
自律エージェントは client credentials、ユーザー代理実行は OBO を使い分け、広い app permission を安易に渡しません。条件付きアクセスもユーザー用ポリシーの流用ではなく、agent 専用ポリシーで組みます。 (Microsoft Learn) - 共有の
/authorizeを作り、必ずそこを通す。
Functions / App Service の Entra 保護、または同等の構成で認可 API を作り、すべてのツール実行前に呼び出します。ポリシーは中央ストアに置き、version、effectiveFrom、priority を持たせるとロールバックしやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM) - データ境界と承認条件を明文化する。
tenant、region、data sensitivity、amount、operation type などを属性として定義し、DENY / MASK / REQUIRE_APPROVAL の条件を先に決めます。Purview の DLP やデータ ガバナンスもこの段階で接続しておくと、後からの追加実装が減ります。 (TECHCOMMUNITY.MICROSOFT.COM) - ログ・レビュー・停止手段を持つ。
サインイン ログと監査ログを監視し、異常なトークン要求や権限変更にアラートを出し、6〜12 か月ごとの access review を回します。blueprint 単位の無効化を kill-switch にできる設計も有効です。 (Microsoft Learn)
失敗しやすいポイント
- 「agent identity があるから安全」と考えること。
ID は誰かを示すだけで、業務上の実行可否までは決めません。ランタイム認可がなければ、API 権限のあるエージェントが不適切なタイミングで正しく「実行できてしまう」状態が残ります。 (TECHCOMMUNITY.MICROSOFT.COM) - ユーザー向けの MFA 条件付きアクセスをそのまま agent に当てること。
Microsoft も、agents は対話型制御を満たせないため、agent 専用ポリシーを作るよう勧めています。 (Microsoft Learn) - Copilot Studio の agent ID が、すぐにコネクタ認証まで守ってくれると誤解すること。
2026年4月時点の既知の問題では、そこはまだ制約があります。 (Microsoft Learn) - Foundry で公開後の新しい ID に RBAC を付け忘れること。
shared identity では動いていたのに本番だけ失敗する典型原因です。 (Microsoft Learn) - decision の理由と correlationId を残さないこと。
障害調査や監査で「なぜ動いたか」を説明できず、結局は運用が人手判断に戻ります。 (TECHCOMMUNITY.MICROSOFT.COM) - エージェント台帳を作らず、チームごとに野良運用すること。
Microsoft も untracked deployment を shadow risk と見なし、単一 inventory を求めています。 (Microsoft Learn)
まとめ
Microsoft が 2026年4月7日に示したメッセージを一言でまとめるなら、AI エージェントのセキュリティ ガバナンスは「ID 管理」から「実行時判断の統制」へ重心が移った、ということです。Entra Agent ID で主体を識別し、Authorization Fabric で実行可否を決め、Purview や監査ログでデータと挙動を追跡する。この3層を切り分けて考えると、AI エージェントの導入はかなり設計しやすくなります。 (TECHCOMMUNITY.MICROSOFT.COM)
最初の一歩としては、購買申請、顧客情報参照、管理者操作のような「失敗コストが高い 1 操作」を選び、その操作だけを /authorize で止める PoC を作るのが効果的です。そこで decision、approval、audit の流れが回れば、全社展開で必要な論点が一気に見えるようになります。
コメント