Microsoft Agent 365とは？開発基盤によって異なる管理・セキュリティ機能を比較

2026年11月9日時点

1. はじめに

Microsoft Agent 365は、企業内のAIエージェントを一元的に可視化・管理・保護するためのプラットフォームです。

Microsoft 365 Copilot Agent Builder、Copilot Studio、Microsoft Foundryなどで作成したエージェントに加えて、サードパーティ製の開発基盤で構築されたエージェントも管理対象にできます。

ただし、すべてのエージェントに対して、Agent 365の全機能を同じように適用できるわけではありません。

利用できる機能は、開発基盤、連携方式、エージェントの実装、利用するデータや実行環境によって異なります。

本記事では、Agent 365の主要機能と、開発基盤ごとの対応状況について整理します。

2. Agent 365の主要機能

Agent 365の機能は、大きく3つに分類できます。

分類	主な機能
Observe（可視化）	エージェント一覧、利用状況、実行履歴、ツール呼び出しの監視
Govern（ガバナンス）	エージェント登録、ID管理、公開・利用制御、ライフサイクル管理
Secure（セキュリティ）	DLP、機密情報の保護、脅威検出、実行時のセキュリティ対策

これらの機能は、Microsoft 365管理センターに加え、以下のセキュリティ製品と連携して実現されます。

Microsoft Entra：エージェントのID管理とアクセス制御
Microsoft Purview：データ分類、DLP、監査、情報保護
Microsoft Defender：脅威検出、セキュリティ状態の把握、実行時保護

3. AIエージェントの主な開発・実行基盤

AIエージェントを構築・実行するためのプラットフォームには、Microsoft製品だけでも複数の選択肢があります。

開発・実行基盤	特徴
Microsoft 365 Copilot Agent Builder	Microsoft 365 Copilotから簡単にエージェントを作成
Microsoft Copilot Studio	ローコードで業務エージェントを開発・公開
Microsoft Foundry Agent Service	AIモデルや独自ロジックを利用したエージェントを開発・実行
サードパーティ製基盤	Google Vertex AI、Amazon Bedrockなどでエージェントを開発・実行

Microsoft製の開発基盤には、Agent 365との標準的な連携機能が用意されています。

サードパーティ製の開発基盤についても、Registry SyncやAgent 365 SDKなどを利用することで、Agent 365の管理対象に含めることができます。

ただし、連携方式や対応機能は開発基盤ごとに異なります。

4. 開発基盤ごとのAgent 365対応状況

ここでは、Agent 365の主要機能について、開発基盤ごとの差を比較します。

対応状況の見方

表記	意味
◎ 標準対応	個別のSDK実装なしで対応。管理側の設定は必要な場合がある
○ 設定により対応	管理設定・ポリシー・権限設定などが必要
△ 条件付き対応	開発方式、追加実装、データ経路などによって対応範囲が異なる
— 未確認	対象の組み合わせで対応を確認できない

※ これらは本記事独自の分類であり、Microsoft公式の対応区分ではありません。

Agent 365機能比較表

Agent 365機能	Copilot Studio	Agent Builder	Foundry Prompt	Foundry Hosted	独自開発・外部PF
エージェント登録・可視化	◎	◎	◎	◎	○〜△
実行テレメトリの収集	◎	◎	◎	○〜△	△
EntraによるID管理	◎	◎	○	○	△
公開承認・公開制御	○	○	△	△	△
利用ブロック	◎	◎	△	△	△
Purview DLP	○	○〜△	○〜△	○〜△	△
Defender脅威検出	○	○〜△	○〜△	○〜△	△
Defender実行時保護	○〜△	○〜△	△	△	△

注意事項

この表は各機能の利用可能性を概括したものであり、すべての製品組み合わせについて対応を保証するものではありません。
◎であっても、ライセンス、テナント設定、管理者による有効化などが必要になる場合があります。
公開承認・公開制御は、Agent 365単独で実現するものとは限らず、各開発基盤や公開先の機能との組み合わせで判断する必要があります。
Foundryや外部PFでは、ホスト方式、利用経路、SDK連携方法によって対応状況が変わります。
PurviewやDefenderの保護機能は、保護対象のデータや通信経路によって適用可否が異なります。

また、上表のEntra ID管理は、エージェントIDやアクセス制御との連携可能性を示しています。すべてのエージェントに同一種類のIDが自動発行されることを意味しません。

5. 特に重要な3つの違い

① エージェントの利用ブロック範囲が異なる

Agent 365では、Microsoft 365管理センターからエージェントをブロックできます。

しかし、ブロックの適用範囲は開発基盤によって異なります。

例えば、Copilot Studioで作成したエージェントをブロックすると、Microsoft Copilot、Teams、Outlookなど、対応するホスト製品での利用を制限できます。

一方、Foundryで作成したエージェントを同じ方法でブロックした場合、その効果はMicrosoft Copilot Chatでの利用に限定されます。

FoundryのAPIを直接呼び出すなど、別の経路からの実行まで自動的に禁止されるわけではありません。

なお、対応するFoundryエージェントについては、Microsoft 365管理センターからAzure側の実行基盤を開始・停止できる場合もあります。これは利用ブロックとは別の操作です。

つまり、Agent 365からブロックできることと、エージェントのすべての実行を停止できることは別です。

② 実行状況を監視できる範囲が異なる

Copilot Studioでは、エージェントの呼び出しやツール実行に関するテレメトリの標準連携が用意されています。

Foundry Prompt Agentも、標準のアクティビティデータ連携に対応しています。

Foundry Hosted Agentについては、利用するホスティングライブラリによって対応が異なります。

例えば、Foundryの対応ホスティングライブラリを利用している場合、Agent 365のデータ収集が有効であれば、テレメトリを自動送信できます。

一方、それ以外の構成では、Agent 365 SDKなどによる追加実装・設定が必要です。

サードパーティ製・独自開発のエージェントでも、Microsoft OpenTelemetryなどによる計測が必要になる場合があります。

したがって、Agent 365に登録されていても、実行内容まで監視できるとは限りません。

③ Purview・Defenderの保護範囲が異なる

Microsoft Purviewは、Copilot StudioやFoundryなどの対応するAIインタラクションに対して、データ分類、機密ラベル、DLP、監査などの機能を提供します。

ただし、開発基盤やデータの送受信経路によって、適用できる保護機能は変わります。

Microsoft Defenderについても同様です。

対応するエージェントに対して脅威検出や実行時保護を提供しますが、すべてのエージェント、すべての通信経路に同じ保護が適用されるわけではありません。

特に独自開発エージェントでは、Agent 365 SDKを導入しても、自動的にすべてのデータや処理が保護対象になるわけではありません。

6. Agent 365との連携方式

Agent 365では、Microsoft製・サードパーティ製を問わず、主に3種類の連携方式が用意されています。

連携方式	主な対象	特徴	SDK実装
Built-in integration（標準連携）	Copilot Studio、Foundry、対応する外部PFなど	開発基盤に組み込まれた機能でAgent 365と連携	不要
Registry Sync（レジストリ同期）	Google Vertex AI、Amazon Bedrockなど	エージェントの登録情報を同期	不要
Agent 365 SDK	独自開発・サードパーティ製エージェントなど	コードにSDKを組み込んで連携	必要

① Built-in integration（標準連携）

エージェントの開発基盤に、Agent 365との連携機能があらかじめ用意されている方式です。

例えば、Copilot Studioでエージェントを作成すると、Agent 365と標準的に連携できます。

開発者がAgent 365 SDKを個別に組み込む必要はありません。
管理者が必要な設定を行うことで、Agent 365から管理できます。

Microsoft Foundryも標準連携に対応していますが、作成するエージェントの種類や利用機能によって追加設定が必要になる場合があります。

また、標準連携に対応しているサードパーティ製エージェントも対象となります。

ポイント：開発基盤側に連携機能が組み込まれているため、エージェントごとに連携用プログラムを開発する必要がありません。

ただし、標準連携であっても、Agent 365のすべての管理・セキュリティ機能が利用できるとは限りません。

② Registry Sync（レジストリ同期）

サードパーティ製の開発基盤から、エージェントの登録情報をAgent 365に同期する方式です。

例えば、Google Vertex AIやAmazon Bedrockなど、対応する開発基盤に登録されているエージェント情報をAgent 365に取り込みます。

主に次の用途で利用します。

企業内に存在するエージェントの把握
エージェントの一覧管理
登録情報に基づくガバナンス

ポイント：既存のエージェントをAgent 365から可視化するための連携方式です。

ただし、Registry Syncは主に登録情報の同期を目的とするものであり、実行監視や外部PF側の実行停止など、すべての制御機能が自動的に利用可能になるわけではありません。

③ Agent 365 SDK

開発者が、エージェントのプログラムにAgent 365 SDKを組み込む方式です。

主に、独自開発したエージェントや、標準連携だけでは必要な機能を実現できない場合に利用します。

例えば、LangChain、CrewAI、Microsoft Agent Frameworkなどを使って開発したエージェントに、Agent 365との連携処理を実装します。

SDKを利用することで、次のような機能と連携できます。

Agent IDを利用したID連携
Agent 365の管理されたツールとの連携
通知機能
エージェントの実行監視に必要な連携

なお、実行監視にはMicrosoft OpenTelemetryを使用します。

ポイント：標準連携やRegistry Syncで対応できない機能を、コードから実装するための方式です。

ただし、Agent 365 SDKの導入が、すべてのガバナンス・セキュリティ機能への対応を保証するわけではありません。

連携方式の選び方

基本的には、次の順序で検討します。

Built-in integration：開発基盤の標準連携で必要な機能を利用できるか確認する。
Registry Sync：標準連携がない場合、対応する外部PFから登録情報を同期できるか確認する。
Agent 365 SDK：追加のID連携、ツール連携、通知などが必要な場合にSDKによる実装を検討する。

これらは必ずしも排他的な方式ではありません。

例えば、標準連携に対応した開発基盤でも、一部の機能をSDKで追加実装する場合があります。

7. 補足：Microsoft FoundryのPrompt AgentとHosted Agentの違い

Microsoft Foundryには、代表的なエージェントの実装方式として、Prompt AgentとHosted Agentがあります。

両者は、エージェントの開発方法や実行方式が異なります。

Prompt Agent（プロンプトエージェント）

プロンプト、AIモデル、ツールなどを設定して構築するエージェントです。

FoundryポータルやSDKから作成
Microsoftが実行環境を管理
独自の実行コードをホストする必要がない
比較的簡単に構築できる

Hosted Agent（ホスト型エージェント）

Pythonなどで独自のコードを実装し、Foundry上で実行するエージェントです。

Microsoft Agent Frameworkなどを利用して開発
独自ロジックや複雑な処理を実装可能
コンテナーとしてFoundryにデプロイ
マルチエージェントなど高度な構成に対応

両者の比較

項目	Prompt Agent	Hosted Agent
開発方式	設定中心	コード中心
開発難易度	比較的低い	比較的高い
ロジックの自由度	標準機能・ツール中心	高い
実行環境	Foundryが管理	Foundryがコンテナーを管理
Agent 365への登録	標準対応	標準対応
Agent 365の実行監視	標準連携	ホスティング方式により標準連携または追加実装