エージェントの導入は進む一方で、認証と権限管理が追いつかない——Microsoft Copilot Studioを使う企業が直面する課題に、IAM（Identity and Access Management、IDとアクセスを一元管理する仕組み）ベンダーのAembitが踏み込みました。
本記事では、2026年6月16日にIdentiverse 2026で発表されたCopilot Studio連携の内容と、エージェントAIのアクセス制御をどう設計するかを整理します。
この記事でわかること
- AembitのCopilot Studio連携が解くセキュリティ上のギャップ
- Blended Identity（ユーザーとエージェントを結び付けた複合ID）の仕組み
- 短命クレデンシャルと監査ログがもたらす運用上の変化
- 既存のOAuth認証との違いと導入の前提
Copilot Studio連携が発表された背景
Aembitは2026年6月16日、米ネバダ州ラスベガスで開催中のIdentiverse 2026において、Microsoft Copilot Studioのエージェントを自社IAMプラットフォームで保護できると発表しました。連携は既存のAembit顧客向けに提供開始されており、会場ブース220でライブデモも行われています。
Copilot Studioは、社内データや外部API、基幹システムへMCP（Model Context Protocol、AIエージェントがツールやデータに標準的な手順で接続するためのプロトコル）サーバー経由でつなぐカスタムAIエージェントを構築・展開するプラットフォームです。Microsoft 365に組み込まれたCopilotとは別製品で、外部MCPサーバーへの接続はCopilot Studio側の機能に限られます。
MicrosoftはCopilot Studioでのエージェント構築のハードルを下げ、業務部門でもエージェントを量産しやすくしました。一方、エージェントが機密データや基幹システムへアクセスする際の認証設計は、セキュリティチームの手を離れやすい構造です。Aembit共同創業者兼CEOのDavid Goldschlag氏は、エージェントに検証済みIDを持たせ、恒久的なクレデンシャルを持たせず、セキュリティチームが中央で管理できるアクセスポリシーで動かす枠組みが欠けていたと指摘しています。
Aembitが入る位置とBlended Identity
AembitのIAMプラットフォームは、Copilot Studioのエージェントとエージェントが接続する企業リソースの間に置かれます。人間向けのIDプロバイダーから得たユーザー文脈と、エージェント固有のID・アクセス要件を組み合わせ、ユーザーとは別のBlended Identity（複合ID）をエージェントに付与します。
エージェントが実行時にクレデンシャルを必要とするとき、AembitはエージェントID、要求先リソース、リクエスト条件をアクセスポリシーと照合します。承認された場合のみ、タスクに必要な範囲に絞った短命クレデンシャルを発行し、作業完了後は恒久的なアクセス権を残しません。アクセス判断はコンプライアンスレビューやインシデント調査に足る文脈付きで記録されます。
Aembit共同創業者兼CTOのKevin Sapp氏は、Copilot Studioを展開する組織から「他のインフラと同じアクセスモデルでエージェントを管理したい」という要望があったと述べています。エージェントの構築方法や接続先システムを変えずに、この統制を適用できる点が連携の訴求点です。
静的クレデンシャルでは足りない理由
Copilot Studioの標準的な接続方法には、OAuth 2.0によるユーザー委任認証やAPIキーがあります。OAuthはエージェントを動かす入口としては機能しますが、Aembitはエージェントが決定論的なワークロードではない点を問題視しています。実行時にどのツールを呼び、どのリソースへ到達するかがリクエストごとに変わるため、1本の静的クレデンシャルに期待どおりの範囲を割り当てるのは難しくなります。
範囲を広く取れば過剰な権限が残り、狭く取ればタスク失敗が増えます。複数エージェントが同じサービスアカウントを共有すれば、監査ログ上の帰属も曖昧になります。Microsoft社内のMCPガバナンス事例でも、トークンは短命・タスク単位のスコープに絞り、不要なフィールドはツールへ渡さない方針が示されています（参考）。Aembitはこの課題を、エージェント専用の中央ポリシー管理とMCP Identity Gateway（MCP経由の接続を認証・ポリシー適用・トークン交換で仲介するゲートウェイ）で補う立場です。
連携で得られる4つの制御
公式ブログが挙げる実運用面の変化は次のとおりです。
- 恒久的アクセスの排除 — エージェントは常時有効なクレデンシャルを保持せず、タスクごとに発行・失効する
- 最小権限の強制 — そのインタラクションに必要な範囲だけを付与し、将来の可能性まで先取りして広げない
- 監査証跡 — クレデンシャル発行、アクセスイベント、ポリシー判断を文脈付きで記録し、コンプライアンス質問に答えやすくする
- 中央ポリシー — Copilot Studioエージェントのルールを、Claudeなど他プラットフォームのエージェントと同じ管理面で扱える
Aembitは2025年10月にAgentic AI向けIAMを発表し、Blended IdentityとMCP Identity Gatewayを中核に据えてきました。今回のCopilot Studio対応は、その機能をMicrosoftのエージェント基盤へ広げたものです。同社はClaude展開の支援実績も公表しており、時価総額3000億ドル規模の投資会社がアナリスト・経営層向けAIアシスタントを財務データやメール、カレンダー、機密情報へ接続した事例を挙げています。
導入前に確認すべき点
連携はAembitのWorkload IAMプラットフォームを既に利用する顧客が対象です。Copilot Studio単体の設定だけでは有効化されず、Aembit側のポリシー設計とデプロイが前提になります。
Identiverseに参加しない組織向けに、AembitはAgentic AI Deployment Checklist（エージェント展開前のセキュリティ確認用インタラクティブチェックリスト）も公開しています。Copilot StudioのほかClaude、ChatGPT、Gemini、カスタムLLMエージェントも対象で、プラットフォームを問わず共通するアクセス課題を洗い出す用途を想定しています。
Microsoft側ではAgent 365がエージェント向けのEntra IDやMCPサーバー統制のコントロールプレーンとして位置づけられています。Aembitはその上に、ワークロードIAMの観点からエージェントと下流リソースの間に入る第三者レイヤーとして機能します。既存のEntra IDやPower Platformデータポリシーと役割分担を整理したうえで、どこまでをAembitに任せるかを決める必要があります。
エージェントIAMが標準装備になる段階へ
Copilot Studioはエージェント作成を簡単にしました。簡単さの裏では、MCP経由の接続が増え、静的なサービスアカウントやAPIキーに依存した設計の限界が表面化しています。Identiverse 2026での発表は、IDコミュニティが人間とワークロード向けに築いた統制の延長として、AIエージェントを扱うべきだというメッセージでもあります。
AembitのCopilot Studio連携は、短命クレデンシャル・Blended Identity・実行時ポリシー適用という三点セットで、エージェントのアクセスを「作ったあとに後追いで締める」状態から「最初から統制下に置く」方向へ寄せる試みです。エージェント導入を進めるセキュリティ担当者は、OAuth委任だけで十分か、エージェント固有のIDと監査が必要かを、この連携を手がかりに設計を見直すタイミングです。