Microsoft Agent 365 とは？サードパーティエージェント観点で見る機能概要
はじめに
生成 AI エージェントの活用が進むにつれて、企業内ではさまざまなエージェントが利用されるようになっています。
たとえば、以下のようなケースです。
- Microsoft Copilot Studio で作成した業務エージェント
- Microsoft 365 Copilot の Agent Builder で作成したエージェント
- Azure AI Foundry で構築したエージェント
- Amazon Bedrock、Google Vertex AI、n8n、ServiceNow、Dify、自社開発基盤など、Microsoft 以外の環境で構築したエージェント
ここで企業として重要になるのは、単に「エージェントを作れるか」ではなく、以下のような観点です。
- どのエージェントが社内で使われているのか
- 誰が所有しているのか
- どのデータや API にアクセスできるのか
- セキュリティリスクはないか
- 利用状況や監査ログを確認できるか
- 不要・危険なエージェントを管理者が制御できるか
このような課題に対して、Microsoft が提供するエージェント管理のコントロールプレーンが Microsoft Agent 365 です。
本記事では、Cloud Solution Architect の視点から、特に サードパーティエージェントを Agent 365 でどのように可視化・統制・保護できるのか という観点で整理します。
※ 本記事は 2026 年 6 月時点の Microsoft 公開情報を基にした個人の見解です。製品仕様や提供状況は変更される可能性があります。
Microsoft Agent 365 の位置づけ
Microsoft Agent 365 は、企業内で増加する AI エージェントを一元的に管理するための仕組みです。
ポイントは、Agent 365 が「エージェントの実行基盤そのもの」ではなく、エージェントを企業利用に耐えられる形で管理する control plane であるという点です。
大きく見ると、Agent 365 は以下の 3 つの観点を提供します。
| 領域 | 概要 |
|---|---|
| Observe | エージェントの可視化、利用状況、所有者、リスク、状態の把握 |
| Govern | ライフサイクル管理、公開範囲、アクセス制御、ポリシー適用 |
| Secure | ID、認証、条件付きアクセス、リスク検知、監査、保護 |
Microsoft 製のエージェントだけでなく、Microsoft 以外の環境で構築されたエージェントも管理対象に取り込める点が重要です。
なぜサードパーティエージェント管理が重要なのか
実際の企業環境では、すべてのエージェントが Microsoft 製品だけで作られるとは限りません。
部門や開発チームごとに、以下のようなツールや基盤が使われることがあります。
- Amazon Bedrock
- Google Vertex AI
- n8n
- ServiceNow
- Dify
- LangChain / Semantic Kernel などのフレームワーク
- 自社開発の AI エージェント基盤
- SaaS ベンダーが提供するエージェント
このような環境では、IT 管理者やセキュリティ部門から見ると、次のような課題が発生します。
- エージェントの存在を把握できない
- 所有者や責任者が分からない
- どの API や社内データにアクセスしているか分からない
- 認証情報がコードや設定ファイルに埋め込まれている
- 退職者が作成したエージェントが残り続ける
- 過剰な権限を持つエージェントを検出しにくい
- 監査やコンプライアンス対応が難しい
いわゆる「シャドウ AI」や「野良エージェント」の問題です。
Agent 365 は、このようなエージェントを企業の統制下に置くための仕組みとして位置づけられます。
サードパーティエージェントを Agent 365 に接続する主な方法
サードパーティエージェントを Agent 365 の管理対象にする方法は、主に以下の 3 つの観点で整理できます。
1. Agent Registry に登録して可視化する
まず重要なのが、エージェントを Agent Registry に登録し、管理者が一覧で確認できるようにすることです。
Agent Registry では、組織内で利用可能なエージェントを確認できます。
管理者は、たとえば以下のような情報を確認できます。
- エージェント名
- 状態
- チャネル
- 作成日
- 更新日
- 発行元
- 発行元タイプ
- 所有者
- 説明
- プラットフォーム
- 指示内容
- リスク情報
これにより、「どのエージェントが存在するのか」「誰が管理しているのか」「どこで利用されているのか」を把握しやすくなります。
特にサードパーティエージェントの場合、まずは Registry に取り込むことで、管理対象として見える状態にすることが第一歩になります。
2. Registry sync で外部プラットフォームのエージェントを同期する
Agent 365 では、外部プラットフォーム上で作成されたエージェントを Agent Registry に同期する仕組みとして Registry sync が提供されています。
イメージとしては、以下のような流れです。
外部エージェント基盤
例: Amazon Bedrock / Google Vertex AI など
↓
Registry sync
↓
Microsoft 365 admin center の Agent Registry
↓
管理者による可視化・管理・ガバナンス
管理者は Microsoft 365 admin center から外部プラットフォームとの接続を作成し、同期状態やエラー、最終同期状況などを確認できます。
これにより、Microsoft 以外の環境で作成されたエージェントも、企業全体のエージェント台帳に取り込むことができます。
ただし、ここで注意したいのは、Registry sync は基本的に 可視化・管理対象化のための同期 であり、外部基盤上のエージェント本体を Agent 365 に移行するものではないという点です。
つまり、外部基盤で動いているエージェントは引き続き外部基盤上で稼働し、Agent 365 はそれを管理プレーンとして把握・統制する役割を担います。
3. Agent 365 SDK で既存エージェントを拡張する
サードパーティエージェントや自社開発エージェントを、より深く Agent 365 と統合したい場合は、Agent 365 SDK の利用が選択肢になります。
Agent 365 SDK を使うことで、既存のエージェントに対して以下のようなエンタープライズ向け機能を組み込むことができます。
- エージェント ID
- 認証
- 可観測性
- 通知
- セキュリティ
- Microsoft 365 データへの統制されたアクセス
- Agent 365 tools / MCP サーバーとの連携
たとえば、自社開発の Python / TypeScript ベースのエージェントや、外部フレームワークで構築したエージェントに対して、Agent 365 の ID やログ、ポリシー、ツール連携を追加していくイメージです。
ここでのポイントは、Agent 365 SDK は「エージェントを Microsoft 製に作り直す」ためのものではなく、既存エージェントを企業統制に対応させるための拡張手段であるという点です。
Microsoft Entra Agent ID によるサードパーティエージェントの認証
サードパーティエージェントを企業環境で利用する際に、特に重要なのが ID と認証です。
従来のアプリケーションでは、クライアントシークレットや証明書を使って API にアクセスするケースが多くありました。しかし、AI エージェントでは以下のような課題が出てきます。
- エージェントごとの ID をどう管理するか
- エージェントが持つ権限をどう最小化するか
- 誰の代理でアクセスしているのかをどう確認するか
- 認証情報をコードに埋め込まないようにするにはどうするか
- エージェントの利用を監査できるか
この領域を担うのが Microsoft Entra Agent ID です。
Microsoft Entra Agent ID は、AI エージェント向けの ID とセキュリティの仕組みです。Microsoft 製のエージェントだけでなく、サードパーティエージェントにも Agent ID を付与し、認証・認可・監査・ガバナンスの対象にできます。
サードパーティエージェントの認証パターン
Microsoft Entra Agent ID では、サードパーティエージェント向けに主に以下の統合パターンが示されています。
パターン 1: Microsoft Entra Auth SDK の sidecar パターン
1 つ目は、Microsoft Entra Auth SDK を sidecar として動かすパターン です。
この構成では、エージェント本体とは別に sidecar コンテナを配置し、エージェントは sidecar に対してトークンを要求します。
Agent Container
↓ token request
Microsoft Entra Auth SDK Sidecar
↓ token acquisition
Microsoft Entra Agent ID
↓ access token
Microsoft Graph / Azure / Custom API
この方式のメリットは、エージェント本体が直接シークレットや証明書を扱わなくてよい点です。
向いているケースは以下です。
- Docker / Kubernetes 上で動くエージェント
- AWS Bedrock など外部環境で動くエージェント
- ローカル開発環境で認証をテストしたい場合
- コンテナ基盤をすでに利用している組織
一方で、sidecar コンテナを追加で管理する必要があるため、実行基盤側の設計や運用も考慮する必要があります。
パターン 2: Workload Identity Federation
2 つ目は、Workload Identity Federation を使うパターンです。
この方式では、AWS STS や GCP Workload Identity など、外部クラウド側のワークロード ID を Microsoft Entra とフェデレーションし、Microsoft Entra のトークンに交換します。
Third-party platform
例: AWS STS / GCP Workload Identity
↓
OIDC / federated credential
↓
Microsoft Entra Agent ID
↓
Access token
↓
Microsoft Graph / Azure / Custom API
この方式のメリットは、sidecar を配置せず、既存のクラウド ID 基盤を活用できる点です。
向いているケースは以下です。
- AWS / GCP 側のワークロード ID をすでに利用している
- コンテナを追加できない、または追加したくない
- 外部 ID プロバイダーとのフェデレーション設計が可能
- シークレットレスな認証を実現したい
特にマルチクラウド環境では、このパターンが重要になります。
Agent 365 でできることをサードパーティ観点で整理する
サードパーティエージェント観点で、Agent 365 の機能を整理すると以下のようになります。
| 観点 | Agent 365 / Entra Agent ID での考え方 |
|---|---|
| 可視化 | Agent Registry に登録・同期し、管理者が一覧で把握 |
| 所有者管理 | Owner / Sponsor などの責任者情報を管理 |
| ライフサイクル | 登録、公開、ブロック、削除、棚卸しを管理 |
| 認証 | Entra Agent ID によりエージェント ID を付与 |
| 認可 | 必要な API 権限やスコープを最小権限で構成 |
| 条件付きアクセス | ID ベースでアクセス条件を制御 |
| 監査 | サインインログや監査ログでエージェントの活動を追跡 |
| リスク検知 | 過剰権限、所有者なし、シャドウエージェントなどを検出 |
| 公開制御 | Agent Store や Microsoft 365 admin center で公開・ピン留めを管理 |
| 外部連携 | SDK、Registry sync、federation、MCP などで統合 |
Agent Store との関係
Agent 365 とあわせて理解しておきたいのが Agent Store です。
Agent Store は、Microsoft 365 Copilot の中でユーザーがエージェントを発見・利用するための場所です。
Agent Store には、以下のようなエージェントを含めることができます。
- Microsoft が提供するエージェント
- 信頼されたパートナーが提供するエージェント
- 自社で作成したエージェント
- 外部プラットフォームから持ち込んだエージェント
- Agent 365 SDK で統合されたエージェント
つまり、管理者・開発者の視点では Agent 365 / Agent Registry で統制し、ユーザーの視点では Agent Store から必要なエージェントを見つけて利用する、という関係になります。
誤解しやすいポイント
最後に、サードパーティエージェント観点で誤解しやすいポイントを整理します。
誤解 1: Agent 365 に登録すれば、外部エージェント本体も Microsoft 側に移る？
移りません。
Agent 365 は管理・統制・可視化のためのコントロールプレーンです。外部基盤で稼働しているエージェント本体は、基本的にその外部基盤上で稼働し続けます。
誤解 2: Agent 365 側で削除すれば、外部基盤のエージェント本体やデータも自動削除される？
通常はそう考えない方が安全です。
Agent 365 側の削除やブロックは、Microsoft 365 側での可視性、利用制御、管理状態に関わる操作です。外部基盤上のエージェント本体、ログ、データ、認証情報、外部 API 権限まで自動的に削除されるかは、外部基盤側の仕様や連携実装に依存します。
サードパーティエージェントを完全に廃止する場合は、少なくとも以下を分けて考える必要があります。
- Agent 365 / Agent Registry 側の登録削除またはブロック
- Microsoft Entra Agent ID の無効化・削除
- Microsoft Graph や API 権限の取り消し
- 外部基盤側のエージェント本体の停止・削除
- 外部基盤側のログ・データ・シークレットの処理
誤解 3: サードパーティエージェントはすべて同じレベルで統制できる？
これも注意が必要です。
Agent 365 の統制レベルは、対象エージェントがどのように統合されているかによって変わります。
たとえば、単に Registry に同期されているだけのエージェントと、Agent 365 SDK や Entra Agent ID を組み込んだエージェントでは、適用できる制御や取得できる情報の粒度が異なります。
したがって、設計時には以下のように整理するとよいです。
| 統合レベル | できることのイメージ |
|---|---|
| Registry 登録のみ | 存在の可視化、所有者・メタデータ管理 |
| Registry sync | 外部基盤からの継続的な可視化・棚卸し |
| Entra Agent ID 統合 | ID ベースの認証・認可・監査 |
| Agent 365 SDK 統合 | より深い可観測性、通知、ツール連携、統制 |
| MCP / Agent tools 連携 | Microsoft 365 や業務システムへの統制されたツールアクセス |
まとめ
Microsoft Agent 365 は、AI エージェント時代における企業向けの管理・統制基盤です。
特にサードパーティエージェント観点では、以下の点が重要です。
- Agent 365 は Microsoft 製エージェントだけでなく、外部基盤のエージェントも管理対象にできる
- Agent Registry により、組織内のエージェントを一覧化・可視化できる
- Registry sync により、外部プラットフォーム上のエージェントを取り込める
- Agent 365 SDK により、既存エージェントにエンタープライズ向け機能を追加できる
- Microsoft Entra Agent ID により、サードパーティエージェントにも ID、認証、認可、監査の仕組みを適用できる
- sidecar や Workload Identity Federation により、シークレットレスな認証設計が可能になる
- Agent 365 は外部エージェントの実行基盤ではなく、可視化・統制・保護のための control plane として理解するとよい
今後、企業内ではエージェントの数が急速に増えていくと考えられます。
そのときに重要になるのは、「どのツールでエージェントを作るか」だけではありません。
それ以上に重要なのは、作られたエージェントをどのように発見し、管理し、保護し、監査し、企業のガバナンスに乗せていくかです。
その観点で、Microsoft Agent 365 と Microsoft Entra Agent ID は、サードパーティエージェントを含む企業全体のエージェント管理において、重要な役割を担うサービスだと考えています。
参考情報
- Microsoft Learn: Overview of Microsoft Agent 365
- Microsoft Learn: Connect existing agents to Microsoft Agent 365
- Microsoft Learn: Registry sync in the Microsoft 365 agent registry
- Microsoft Learn: Integrate third-party agents with Microsoft Entra Agent ID
- Microsoft Learn: What is Microsoft Entra Agent ID?
- Microsoft Learn: Manage agent registry in Microsoft 365 admin center
- Microsoft Learn: Agent Store in Microsoft 365 Copilot