はじめに
Microsoft Ignite 2025 にて、Agent 365 の紹介がありました。以下の Learn を読むと、各 AI エージェント (以降エージェント) に固有の Microsoft Entra エージェント ID を付与し、ID、ライフサイクル、アクセス管理を実現するサービスのようです。
こちらを踏まえ、私なりに、Agent 365 や Copilot Studio で作成するエージェントのセキュリティ、ガバナンスについて考えてみたいと思います。
本記事の前提
私は、仕事で主に Power Platform の市民開発者育成支援を行っています。また、最近は、Microsoft 365 Copilot、Copilot Studio、AI Builder 等に関する相談、展開支援、作成支援、ハッカソンイベント講師なども行っています。
また、前職 (日本 MS) では、Power Platform はもちろん、Exchange Online、Microsoft 365 のセキュリティコンプライアンス周り、また、Entra ID の認証認可周りについても少なからず関わっていました。
そのため、Power Platform、Copilot Studio 寄りの見解となりますが、私なりに情報を整理してみたいと思います。
もちろん、完全な主観です。
なぜ Agent 365 が重要なのか
今後、エージェントは急速に増加し、自律的に動作して人の代わりに業務を実行するようになり、その数・役割・影響範囲はいずれも拡大していくと予想されます。つまり、エージェントは単なる拡張チャットボットや Power Platform の成果物ではなく、自律的に行動する主体へと変化していくと考えられます。
この変化に伴い、従来の「人が操作することを前提としたセキュリティモデル」では捉えきれない、後述するような新たな懸念が顕在化してきます。
そのため、これらの懸念に対しては、早期の段階から対策を講じていくことが重要です。
マイクロソフトはこれまで、ユーザーアカウントやアプリケーション（サービス プリンシパル）に対し、
Entra ID、Defender、Purview を中心とした管理・防御・制御・監査の仕組みを提供してきました。
Agent 365 は、こうした実績あるエンタープライズ向けセキュリティ基盤を前提に、エージェントを「ID を持つ主体」として管理するための仕組みとして発表されたものだと理解しています。
Entra ID、Defender、Purview はすでに多くの企業で採用されており、信頼性と実績のある管理・統制基盤です。
これらをベースにエージェントを統合的に管理できる点は、マイクロソフトの大きな強みであると考えます。
アイデンティティ、権限の懸念
人に対しては、ユーザーアカウントとして Entra ID で管理され、MFA が適用され、条件付きアクセスも課せられることで、なりすましやアカウント乗っ取りへの対策が行われています。また、ユーザーが実行できる操作は、付与された権限の範囲に明確に制限されています。
一方、人の代わりにエージェントが動作する場合、そのエージェントが「どの主体として、どの権限で動作しているのか」が分かりにくくなるという課題があります。
例えば、以下のような違いがあります。
・特定ユーザーの権限を委任して動作しているのか
・ユーザーとは独立したアプリケーション（サービスプリンシパル）として動作しているのか
この違いは、権限設計や監査の観点で非常に重要です。
また、エージェントは利便性を重視するあまりオーバーパーミッションになりやすく、指示ミスや解釈の違いによって、意図せずファイル削除などの破壊的操作を行うリスクもあります。
そのため、権限設計だけでなく、実行内容を監査・追跡できる仕組みが不可欠です。
データ漏えい・情報統制の懸念
Copilot Studio で作成するエージェントは、Microsoft 365 系サービスだけでなく、サードパーティの MCP サーバーとも接続可能です。
さらに、Copilot Studio で作成したエージェント同士の連携に加え、サードパーティ製エージェントとの連携も可能となっています。
これらは「内から外」への連携だけでなく、サードパーティのエージェントから Microsoft のクラウドサービスの MCP サーバーを利用する、いわば「外から内」への経路としても利用されるようになると考えられます。
例えば、Microsoft 365 系の MCP サーバー利用時は、ユーザーアカウントによる認証、つまり委任されたアクセス許可が用いられる認識です。この挙動は Microsoft Graph 利用時と同様であり、Entra ID におけるアプリ登録や権限同意の仕組みに基づいて制御されます。そのため、管理者同意を必須としている環境では、従来と同等のセキュリティレベルは維持される認識です。
また、Microsoft 365 系 MCP サーバーを利用するエージェントについても、Entra ID 上で管理対象として扱われる仕組みが必要になるという認識です。
このような構成が一般化すると、エージェント間連携を通じて、意図せず組織内の情報が外部へ流出するリスクが高まります。
そのため、
・エージェントがどのサービスと連携しているのか
・どのエージェント同士が接続しているのか
を可視化し、適切に制御・監視できる仕組みが求められます。
アプリケーション、Power Apps/Power Automate のセキュリティガバナンス
以下は、アプリケーションおよび Power Apps / Power Automate におけるセキュリティガバナンスに関する簡単な整理です。
まず、Microsoft Graph を利用するアプリケーションは、Entra ID を基盤として認証・認可が行われ、アイデンティティや権限が一元的に管理・制御されています。この仕組みを踏まえると、エージェントについても同様に「ID を持つ主体」として Entra ID により管理・制御される設計になると考えられます。
また、Copilot Studio で作成されるエージェントは、Power Apps や Power Automate と同様に、各種コネクタを介して外部サービスや Microsoft 365 サービスと連携します。そのため、Power Platform の環境設定や DLP ポリシーによる制御が適用されることが前提となります。加えて、Copilot Studio 独自の機能についても、既存のガバナンスと整合した形で、追加の設定により管理・制御できる仕組みが求められるという認識です。
アプリケーションのセキュリティガバナンス (アイデンティティ、権限観点)
IT 管理者であればご存じのとおり、独自に作成したアプリケーションが、ユーザーの代わりに Microsoft 365 のリソースを操作する仕組みは、かなり以前から提供されています。
これらは Microsoft Graph を利用し、Entra ID によって管理されます。
具体的には、このようなアプリケーションを構築する際、あらかじめ Entra ID にアプリケーションを登録し、必要なアクセス許可を定義する必要があります。
その後、ユーザーがアプリケーションを利用する際（サードパーティ製アプリの場合は、利用者側テナントにサービスプリンシパルが作成される）、以下のような アクセス許可への同意画面が表示されます。
※Graph explorer 利用時に同意すると Entra ID にエンタープライズアプリケーションとして登録される
多くの組織では、Entra ID の設定により、ユーザーが無条件にアプリケーションへ同意することを許可していないケースが一般的です。
そのため、出どころが不明なアプリケーションに対して、ユーザーが意図せず同意してしまい、組織外から Microsoft 365 のリソースが操作されるといった事態は現実的には起こりにくい設計になっています。
このように、アプリケーションがユーザーの代わりに Microsoft 365 のリソースを操作する場合でも、その主体は Entra ID 上のアプリケーション（サービスプリンシパル）として明確に管理されます。
結果として、ユーザーアカウントと同様に、以下のような観点で制御・監視することが可能です。
・付与されている権限の可視化と最小化
・管理者同意による統制
・サインインログや監査ログによる追跡
この仕組みにより、「誰が」「どの権限で」「何を操作しているのか」を明確にした上で、Microsoft 365 のリソース操作を許可することができます。
Power Apps、Power Automate のセキュリティガバナンス (情報漏洩観点)
Power Apps、Power Automate は、Microsoft 内外の様々なサービスとコネクタを介して連携するアプリ、自動化フローを作成できます。また、マイクロソフトのサービスのため、上記アプリ登録、ユーザー同意等は暗黙的に許可されているため、基本組織内の誰でもアプリや自動化フローを作成できます。
この際の懸念としては、サードパーティのサービスと連携して意図せず社内情報が漏洩しないかです。こちらは、Power Platform の DLP ポリシーで制御できます。
Power Apps や Power Automate で市民開発をするにあたって、他にもセキュリティガバナンスの観点で実施することは色々ありますが、本記事のメイントピックではないため割愛いたします。
Agent 365 の対象者
個人的には、本仕組みは IT 管理者向け、特に Entra ID、Defender、Purview などのセキュリティ・ガバナンス系サービスを担当している方向けの領域だと認識しています。
もちろん、Agent Builder や Copilot Studio を利用してエージェントを作成する方がこの仕組みを理解しておくことに越したことはありません。ただし、正直なところ、Agent Builder でエージェントを作成するエンドユーザーの方や Power Platform 市民開発者にとって、難易度がかなり高い内容だと思います。
そのため、今後、人の代わりに業務を担うエージェントの数がさらに増えていく中において、Agent 365 や DLP ポリシーといったサービス・機能を基盤として、セキュリティガバナンスの強化や社内ルールの整備が進むことが前提になると考えています。
その上で、利用者にはこれまで以上に以下のようなことが求められるようになると考えます。
・定められたルールを順守すること
・既定で利用が許可されていない機能や連携を使用する場合には、適切な申請・承認プロセスを経ること
Agent Builder で作成するエージェントに対しての管理について
個人的には、現時点で Agent Builder で作成できるエージェントは、主にチャット型のシンプルな構成だと認識しています。具体的には、カスタムプロンプトを埋め込むだけのエージェントや、カスタムプロンプトに加えて公開 Web サイトや Microsoft 365 のナレッジを指定するエージェントを作成することができます。
一方で、これらは 自律的に動作するエージェントではなく、ツール呼び出しやサードパーティサービスとの連携も行えないため、機能面は限定的です。
もちろん、今後機能が拡張され、Copilot Studio のようにマルチエージェント構成や MCP への対応などが進めば状況は変わると思います。しかし、現状においては、Agent 365 で厳密に管理する必要性はそれほど高くないと感じています。実際のところ、これらをすべて管理対象とすると、管理負荷が増大すると考えまます。
※利活用状況の把握という観点では、組織内で作成されているエージェントの数や作成者を把握できること自体には価値があるとは考えています
Copilot Studio で作成するエージェントに対しての管理について
Copilot Studio で作成されるエージェントは、少なからず Agent 365 の管理対象になると考えられます。
一方で、すべての Copilot Studio で作成されたエージェントを、必ずしも Agent 365 で厳密に管理する必要があるとは限らない、というのが個人的な見解です。
その理由は、作成されるエージェントの性質によっては、チャットボットの拡張や Power Automate の延長線上にとどまり、自律的に行動する主体とまでは言えないケースも十分に存在するためです。
例えば、
・チャット型で Agent Builder と大きく変わらないシンプルな構成のエージェント
・コネクタを介して他サービスと連携するものの、処理の主導権が明確に人側にあるエージェント
といったケースについては、Power Apps や Power Automate と同様に、Power Platform の既存の管理・ガバナンス機能による制御を基本とするという考え方で問題ない認識です。
ただし、Copilot Studio は進化のスピードが非常に速い点も踏まえる必要があります。
そのため、現時点の Copilot Studio で何ができるのかを整理し、それぞれについて、どのような懸念が考えられるのか、現状どのような制御が可能なのかを整理してみたいと思います。
ナレッジ
これまで何度もブログ記事書いてきましたが、Copilot Studio では様々なナレッジを追加できます。こちらはあくまでエージェントが回答を生成するために利用するものであり、かつナレッジソースは DLP ポリシーで制御できます。
ツール
個人的にこちらが一番機能が豊富で、セキュリティの観点でも気にする点が多くあります。まず、コネクタに関しては同様に DLP ポリシーで制御されます。
また、MCP サーバーも DLP ポリシーで制御できそうです。
※若干 DLP ポリシー側に存在しないものも Copilot Studio 上存在するように見えますが
また、一覧にはない MCP サーバーも追加できるようです。こちらは DLP ポリシーのカスタムコネクタでブロックされるのか分かりませんが、もしされない場合、早めに制御できる機能が欲しいところです。
コンピュータ操作も強力な機能です。要は、人の代わりにブラウザー、PC 操作を代わりにやってくれます。RPA と違い、あくまで指示文ベースで動くため、柔軟性が高いです (逆に RPA ベースで精度高く動くのであれば、そのままの方がいいと個人的に思います)。
こちらも情報漏洩につながるリスクがあり、現状は環境の設定で制御できそうです。もう少し細かいレベルで制御できるようになることを期待しています。
エージェントフロー
Copilot Studio では、エージェントフローを作成して他のサービスと連携もできます。こちらは、従来は Power Automate のフローでしたが、エージェントフローということで Copilot Studio 内に取り込まれました。こちらは、コネクタベースで動作するため、DLP ポリシーの制御対象内という認識です。
マルチエージェント
Copilot Studio で作成したエージェント同士、また、外部のエージェントとも接続できます。こちらも注意が必要です。まず、接続可能なエージェントを制御できる機能は欲しいところです。今後、逆に外部のエージェントから Copilot Studioで作成したエージェントを呼べるようになる場合は、接続元を制御できる機能が欲しいところですし、接続元は Entra ID で管理されるようになる認識です。
公開
Copilot Studio で作成したエージェントについて、様々な場所に展開できます。こちらは Power Virtual Agents 時代から大きくは変わっておらず、以前から、DLP ポリシーで展開先は制御可能です。
例えば、以下のように、Teams/Microsoft 365 Copilot、SharePoint、Web サイト (認証なしは許可されていない) に対してのみ展開可能にする感じです。
※本来、Direct Line chnnels は許可しなくてもいいはずですが、少し前に検証した際、こちらブロックすると、Copilot Studio 作成画面で公開ができず、Teams/Microsoft 365 Copilot に展開できなかったです
トリガー
トリガーを設定すると、Power Automate のフローのように、チャットせずとも自動でエージェントが動作します。上記の通り、エージェントは、Power Automate のフロー以上に人の代わりにいろいろなことができます。こちらも、現状 Power Automate のコネクタベースのため、DLP ポリシーで制御できます。
具体的には、トリガーの種類のコネクタを制御する、自律型エージェント自体の作成を制御することができます。後者は以下のコネクタを制御することで可能です。
まとめ
今回は、Agent 365 および Copilot Studio のエージェントに対するセキュリティガバナンスについて、個人的な考えを整理してみました。
今後、エージェントは爆発的に増加し、人の代わりにさまざまなサービスを操作しながら、結果的に 人に代わって自律的に業務を担う存在になっていくことが想定されます。そのような将来を見据えると、セキュリティガバナンスの観点では多くの懸念点が存在します。そこで、Agent 365 の重要性に加え、Copilot Studio で作成されるエージェントに対する現状のセキュリティガバナンスについても整理してみました。
これらの対策の中核となるのは、エージェントを「ID を持つ主体」として管理するための仕組みであり、信頼性と実績のある管理・統制基盤である Entra ID を中心に管理する設計が採用されたものと理解しています。
併せて、Defender や Purview、Power Platform DLP などの機能も含め、エージェントに対するセキュリティガバナンスは今後ますます重要になると考えています。エージェントの急速な進化・拡大と並行して、これらの統制・管理機能による運用も継続的に強化していく必要があるでしょう。
あくまで個人的な整理ではありますが、何かの参考になれば幸いです。