Microsoft Agent 365とは？機能・3本柱・料金を徹底解説

Microsoft Agent 365は、組織内のあらゆるAIエージェントを統合管理するコントロールプレーンとして、2026年5月1日に商用環境向けに一般提供（GA）されました。
Microsoft製・サードパーティ・オープンソースを問わず、Observe（観測）・Govern（統制）・Secure（防御）の3本柱で、Entra Agent IDによる識別から脅威検知までを一気通貫で扱えます。

本記事では、Copilot Studio・Agent Frameworkとの役割の違い、3本柱の中身、対応するエージェントと実行環境（Multi-cloud Registry sync・OpenClaw等のローカルAIエージェント検出・Windows 365 for Agents）、SDK・CLI・Work IQ MCP・Tools Gatewayといった開発者向け基盤、per-user $15/月とMicrosoft 365 E7バンドル $99/月の新しい料金構造、GA時点でpreview継続中の機能までを最新情報で整理します。

✅Microsoft 365 Copilotの最新エージェント機能「Copilot Cowork」については、以下の記事をご覧ください。
Copilot Coworkとは？機能や料金、Claude Coworkとの違いを解説

Microsoft Agent 365とは？

Microsoft Agent 365は、組織内のあらゆるAIエージェントを管理・統制・活用するための統合コントロールプレーンです。
2025年11月のMicrosoft Ignite 2025で初めて発表され、Frontierプレビューでの先行提供期間を経て、2026年5月1日に商用環境向けへGA（一般提供）されました。

Microsoft製（Copilot StudioやMicrosoft Foundryで構築したもの）だけでなく、サードパーティ製・オープンソース製のエージェントも管理対象にできます。IDの付与・アクセス制御・行動の可視化・脅威検知を一気通貫で扱える点が、単なるエージェント実行基盤やSDKと根本的に異なります。

各エージェントにはMicrosoft Entra IDの技術を応用したEntra Agent IDが付与され、人間の社員と同じようにエージェントのライフサイクル全体を統制できます。GAアナウンス時点で、Microsoft社内では既に50万を超えるエージェントがAgent 365管理下で稼働しており、Customer Zeroとしての実証規模も整っています。

---

Microsoft Agent 365とCopilot Studio・Agent Frameworkとの違い

Agent 365を理解するうえで最初に押さえるべきは、Copilot StudioやMicrosoft Agent Frameworkとは役割が根本的に異なる点です。3製品はいずれも「エージェント」に関わる名前を持ちますが、担当する領域が違います。

ここでは混同しやすい3製品の役割を整理し、そのうえでAgent 365が「どう違うのか」を立ち位置として明確にします。

Agent 365・Copilot Studio・Agent Frameworkの役割比較

Agent 365、Copilot Studio、Agent Frameworkはいずれも「エージェント」に関わる製品ですが、担当領域が異なります。以下の表で3製品の違いを整理します。

製品	役割	対象ユーザー	主な機能
Copilot Studio	エージェントの構築（ローコード）	業務部門・市民開発者	テンプレート、ビジュアルフロー、Power Platformコネクタ
Agent Framework	エージェントの構築（プロコード）	プロ開発者	Semantic Kernel・LangChain連携、マルチチャネル対応
Agent 365	エージェントの管理・統制	IT管理者・セキュリティ担当者	Registry、Access Control、Agent Map、Defender / Purview連携

読み解くと、Copilot StudioとAgent Frameworkは「エージェントを作る」ための道具で、業務部門寄りか開発者寄りかでローコード／プロコードに分かれます。Agent 365は「作られたエージェントを組織として安全に運用する」ためのレイヤーで、対象ユーザーがIT・セキュリティ部門に変わります。

「構築は問わず、管理を一元化する」という立ち位置

3製品の役割が分かれていることの実務的な意味は、Agent 365 SDKがエージェント自体を作成・ホストしない点に集約されます。Agent 365は、すでに構築済みのエージェントに対して、Entra Agent IDの付与・ガバナンスポリシーの適用・MCPアクセスの統制・通知の連携といったエンタープライズ機能を後付けで追加する役割を担います。

この設計により、組織は次のような分業が可能になります。

• 業務部門はCopilot Studioで素早くエージェントを試作する
• 開発者はAgent Frameworkでプロ仕様のエージェントを作り込む
• IT・セキュリティ部門はAgent 365で構築されたエージェントすべてを一元的に管理する

Microsoft環境内のエージェント構築をプロコード／ローコードで分担し、構築されたエージェントすべての管理面をAgent 365が一元化する分業構成だと捉えると、3製品の使い分けが見通しやすくなります。「構築は問わず、管理を一元化する」というのが、Agent 365をCopilot StudioやAgent Frameworkと混同しないための一番の補助線です。

---

Microsoft Agent 365の主な機能（Observe・Govern・Secure）

公式概要ドキュメントでは、Agent 365の提供価値を**Observe（観測）・Govern（統制）・Secure（防御）**の3本柱で整理しています。プレビュー時に説明されていたRegistry・Access Control・Visualization・Securityといった個別機能は、GAに合わせてこのフレームの中に再配置されました。

3本柱は「迎え入れる→働かせる→守る」というエージェントのライフサイクル順に対応しており、IT管理者・セキュリティ担当者・経営層がそれぞれの役割でエージェントを掌握できる設計です。

Observe（観測）

Observeは、組織内に存在するすべてのAIエージェントをリアルタイムに把握するための層です。中核となるのはMicrosoft Entraを基盤にしたAgent Registryで、ここを起点にAgent Mapとアクティビティメトリクスが層全体を構成します。

Agent Registry（中央台帳）

組織全体のエージェントを一覧化し、所有者・状態・依存関係を可視化する中核機能です。Agent IDを持つエージェントだけでなく、管理者が手動で登録したエージェントや、Defender / Intuneが検出したシャドウエージェントまでを単一台帳に集約します。

未承認エージェントが見つかれば、IT管理者は即座に**隔離（Quarantine）**して組織リソースへのアクセスを遮断できます。

Agent Map（接続マップ）

どのエージェントがどの社員・どのデータ・どのMCPサーバーと接続しているかを視覚的に表示するダッシュボードです。経営層・セキュリティ担当者向けの俯瞰図として活用され、依存関係の把握とリスクの早期検知に直結します。

アクティビティメトリクス

利用セッション数・採用率・健全性指標をリアルタイムで追跡します。経営層がエージェント投資のROIを定量的に判断する材料になり、IT管理者にとっては利用低迷エージェントの整理判断軸になります。

シャドウAIが社内で増えている組織がまず手をつけるべきは、派手な脅威検知ではなくObserveでの全数把握です。何台動いているかわからない状態のままでは、後段のガバナンス設計が空回りします。

Govern（統制）

Governは、把握したエージェントを「誰が・何のために・いつまで使うか」の観点でコントロールする層です。各エージェントにはEntra Agent IDが付与され、IDを起点にアクセス権・ライフサイクル・コンプライアンスポリシーを統合的に管理します。

Access Control（アクセス制御）

最小特権の原則に基づき、エージェントが扱えるリソースを限定します。リスクベースの条件付きアクセスポリシーを設定すれば、侵害兆候のあるエージェントを動的に制限することも可能です。

エージェントタイプ別の権限管理

エージェントは「どのアイデンティティで動くか」によって、Microsoft 365エコシステム内では大きく3つのモードに分かれます。それぞれ権限設計と提供状況が異なります。

• delegated access（OBO / On-Behalf-Of）
  社員の代理として動作し、紐付くユーザーが持つ権限の範囲内でしか動かない。最小特権の徹底が効きやすく、GA時点でper-userライセンスにそのまま含まれる
  
  

• own access（behind the scenes）
  エージェント自身のIDで、バックグラウンド処理として自律的に動くモード。GAでper-userライセンスにカバーされる
  
  

• own access（team workflows）
  エージェント自身のIDで、チームのワークフロー内に人と並んで参加する協働モード。GA時点ではpublic preview扱いで、本番SLAが付かない

これらに加えて、エージェントが独自credentialで自身を認証するAgent identity authenticationは引き続き Frontier program 経由の先行アクセスです。提供状況とライセンスの整理は料金セクションで詳述します。

Lifecycle・Identity Governance

アクセスパッケージ・スポンサー承認ワークフロー・自動ライフサイクル管理が一通り揃っており、エージェントのオンボーディングから廃棄までを一貫した手続きで運用できます。eDiscoveryやCommunication Complianceもエージェント対象に拡張されています。

Agent Blueprint（IT承認テンプレート）

Agent Blueprintは、Microsoft Entra Agent Blueprintに基づくIT承認済みのエージェントテンプレートです。エージェントの機能・必要なMCPアクセス権・セキュリティ制約・監査要件・DLPなどのガバナンスポリシーがひとまとめに定義されています。

ブループリントがテナント内で有効化されると、そこから作成されたすべてのエージェントインスタンスが同じルールを継承します。メール・カレンダー・Teams・SharePointなど、エージェントが接触するすべてのMicrosoft 365ワークロードに一貫したガバナンスを適用できるため、シャドウエージェントの発生を構造的に抑止できます。

Policy Templates（ポリシーテンプレート）

Entra・Purview・Defender・SharePointの統制ポリシーをまとめた標準テンプレートが提供されます。組織のガバナンス基準を「再利用可能な型」として配布できるため、部門ごとにブループリントを作るときの土台になります。

Copilot StudioやAgent Frameworkで作ったエージェントを本番運用するなら、Govern層の整備が事実上の前提条件です。Access ControlとIdentity Governanceの両輪で、暴走と権限の野放しを同時に抑える設計が現実的です。

Secure（防御）

Secureは、稼働中のエージェントを内外の脅威から守るための層で、Microsoftのセキュリティスタック全体（Defender / Purview / Entra）を横断的に活用します。

Microsoft Defenderとの連携

Microsoft Defenderは、エージェントの挙動を常時監視して脅威を検知・対応します。

• 集中監視
  すべてのエージェント活動を統一的に追跡し、Defenderポータルで一元管理する
  
  

• 即時の脅威検知
  Defender・Entra SSE・Purviewを含むセキュリティスタック全体と連携し、プロンプトインジェクション攻撃・データ流出兆候・異常な大量アクセスを検知してアラートを発する
  
  

• Advanced Hunting
  セキュリティアナリストがログをクエリし、疑わしいパターンを能動的に探し出せる。MCPサーバーへのツールコール単位でトレースログを検査できる

Defender for AIで提供されるAgent Security Posture Management（preview継続中）は、Foundry・Copilot Studioで構築したエージェントの設定不備や危険な組み合わせを早期に検出する用途で位置づけられています。

Microsoft Purviewとの連携

Microsoft Purviewはデータ保護とコンプライアンスを担当し、エージェントが扱う「データ」に焦点を当て情報漏洩を未然に防ぎます。

• 機密ラベルの適用
  機密ラベル（Sensitivity Label）が付与されたファイルへのエージェントのアクセスや持ち出しを可視化・制御する。ただし、エージェントに共有されたコンテンツは機密ラベルや権限設定に関係なく他ユーザー向けの応答に要約・利用される可能性がある旨が公式ドキュメントで注意喚起されている
  
  

• 監査ログ
  エージェントの会話やアクションはすべて記録され、「いつ・誰と・何を」話したかを追跡（トレーサビリティ）できる
  
  

• DSPM AI Observability
  GA時点で拡張されたデータセキュリティ態勢管理機能。エージェントの入出力・グラウンディングデータの両方をDLP対象として保護する

エージェントとの共有コンテンツの取り扱いには上記の注意点があるため、組織のデータ分類ポリシーと併せた運用設計が重要です。

Identity Protection for Agents

エージェントIDの侵害兆候（異常なサインイン挙動、認証情報の漏えいシグナル等）を検知し、条件付きアクセスやステップアップ認証を発動します。エージェント自身が「攻撃者の踏み台」にならない設計が、人間ユーザーと同じ思想で実装されています。

SASE / Network Controls

Microsoft Entra Suiteのネットワーク統制をエージェントにも適用する仕組みです。脅威インテリジェンスフィルタリング・プロンプトインジェクション保護・カテゴリベースのトラフィック制御が、エージェントの送信先にも作用します。

Secure層の真価は、各機能の単発性能ではなくMicrosoftスタック内での連動にあります。サードパーティSIEMとの併用を想定する組織は、Purview監査ログのエクスポートやDefenderアラートのSplunk / Sentinel統合可否を要件定義の段階で押さえておくのが現実的です。

---

Microsoft Agent 365が対応するエージェントと実行環境

Agent 365が管理対象にできるエージェントは、Microsoft製のものに限りません。GAに合わせて管理対象スコープがMicrosoft環境の外側まで広がり、サードパーティ製のエージェントや、AWS / Google Cloudで稼働するエージェント、Windows端末にローカルインストールされたAIツールまでが視野に入りました。

ここでは、Agent 365が「どんなエージェントを」「どこで動いていても」管理できるのかを、エージェントの種類別と実行環境別に整理します。

Microsoft製・パートナー製・カスタムエージェントの管理範囲

Agent 365が管理対象にできるエージェントは、大きく3つに分類できます。

• Microsoft製エージェント
  Copilot Studio（ローコード）やMicrosoft Agent Framework（プロコード）、Microsoft Foundry上のエージェント等、Microsoft純正の構築基盤で作られたエージェント。Agent IDの付与とガバナンスがネイティブに統合される
  
  

• パートナー製エージェント
  業界リーダー企業がAgent 365への参画を表明しており、各領域に特化した「専門家エージェント」を統一されたセキュリティ基準のもとで採用できる。GA発表時点では Adobe・Cognition・Databricks・Genspark・Glean・Kasisto・Manus・NVIDIA・n8n・ServiceNow・Workday・Zendesk・Zensai・Egnyte が公式パートナーとして掲載されている。Kore.ai・Celonisはエージェントファクトリ（構築基盤）パートナーとして位置づけられている
  
  

• カスタムエージェント（自社開発）
  OpenAI Agents SDK、Claude Code SDK、LangChain、Semantic Kernelなど、Microsoft純正以外のフレームワークで自社開発したエージェント。Agent 365 SDKを通じてEntra Agent IDやMCPアクセスを後付けで適用できる

パートナー製・カスタム製のエージェントもAgent IDの付与対象になるため、自社開発のエージェントと同じガバナンスフレームワーク内で管理できます。導入企業からすれば、SaaSベンダーごとに監査・ID連携を個別実装する必要がなくなる点が大きな価値です。

マルチクラウド対応（Amazon Bedrock・Google Gemini Enterprise Agent Platform）

Agent 365のRegistryは、GAアナウンスと同時にAmazon BedrockおよびGoogle Gemini Enterprise Agent Platform（旧 Google Vertex AI）で稼働しているエージェントの取り込みsyncに対応しました（public preview）。

具体的には、以下のような統合が可能になっています。

• クロスクラウド観測
  Amazon BedrockのエージェントメタデータをAgent 365 Registryに同期し、Microsoft環境のエージェントと並べて可視化する
  
  

• Gemini Enterprise Agent Platformとの統合
  Google Gemini Enterprise Agent Platform上のエージェントもRegistry経由で観測対象化する
  
  

• コンテキスト情報の取り込み
  他クラウド上のエージェントについて「どのアイデンティティが紐付いているか」「何にアクセスしているか」といったメタデータを取り込み、Microsoft環境のエージェントと同じビューで把握できる

現時点ではRegistry層での観測・メタデータ同期が中心で、Entra Agent IDと他クラウドのIDシステムを完全に統合した認証・監査までは段階的な拡張の見通しです。AWS / GCP上のエージェントに対するDefenderの脅威検知やPurviewのDLP適用も同様に順次。マルチクラウド環境の組織では、まず観測の統合から着手し、検知・防御の統合は次フェーズで判断するのが現実的です。

ローカルAIエージェント検出（OpenClaw／拡張予定：GitHub Copilot CLI・Claude Code）

GA時のもう一つの重要な拡張は、Microsoft Defender + Microsoft Intuneによるローカル端末のAIエージェント検出です。

公式GAアナウンスでは、検出対応の現状と今後の拡張予定が次のように整理されています。

• 現在対応：OpenClaw（旧Clawdbot）
  ローカル端末で動作するオープンソースのエージェントランタイム。Frontierプログラム経由で利用できる検出対象として明示されている
  
  

• 拡張予定：GitHub Copilot CLI ／ Claude Code など
  公式は「OpenClawから始め、GitHub Copilot CLIやClaude Codeのような広く使われているエージェントへの対応をsoon（近日中）に拡張する」と表現しており、現時点では正式な検出対応に入っていない

Intuneが端末上の対象ツールを検出し、Agent 365 Registryに「シャドウエージェント候補」として登録します。さらに、ネットワークレベルでの統制をMicrosoft Entra Suite経由で適用できるため、ローカルAI起点の情報持ち出しに対するガバナンスが実装可能になりました。

社員が個人的にローカルAIツールを使い始めている組織にとって、これは「禁止か放任か」の二択を超える選択肢になります。Registry登録とポリシー適用という第三の道がAgent 365 GAで整備されつつあり、対象ツールの拡張も見据えた計画が立てやすくなっています。

Windows 365 for Agents（preview・米国のみ）

GA時点でWindows 365 for Agentsもpublic previewとして発表されました。これは、Cloud PC（Windows 365）の仮想Windows環境内でエージェントを実行し、ローカル端末や本番ネットワークから隔離された状態でエージェントタスクを走らせる仕組みです。公式アナウンスでは現時点で米国リージョンのみのpublic previewと明記されています。

開発・テスト・PoCを安全に進めたい場合や、特定の業務オペレーション（外部ファイルの解析、未知のWebスクレイピング等）をサンドボックス化したい場合に有効です。Tools Gatewayと組み合わせれば、リスクの高いツール呼び出しを仮想環境内に閉じ込める設計も可能になります。

日本リージョンでの利用や全世界展開のスケジュールは公式に明示されていないため、グローバル展開を前提とした組織は、ロードマップの動向を追いつつPoCに先行採用する判断が現実的です。

---

Microsoft Agent 365の開発者向け機能

Agent 365は管理者やセキュリティ担当者だけのものではありません。開発者にとっても、既存のAIエージェントをエンタープライズグレードに引き上げるための基盤となります。

Agent 365 SDK

Agent 365 SDKは、任意のエージェントSDKやプラットフォームで構築されたエージェントに、エンタープライズグレードの機能を後付けで追加するためのソフトウェア開発キットです。

SDKが提供する主な機能は以下のとおりです。

• Entra Agent Identity
  面倒な認証処理をAgent 365に任せ、メールボックスなどのユーザーリソースを持つセキュアなID管理を実現する
  
  

• 通知機能
  Teams、Outlook、Wordコメント、メールからの通知を受信・応答し、人間の参加者と同じようにMicrosoft 365アプリ内で動作する
  
  

• 可観測性（Observability）
  Open Telemetryベースで、エージェントの対話・推論イベント・ツール使用を監査可能な形で記録する
  
  

• MCPサーバーへのアクセス
  管理者の制御下で、Microsoft 365ワークロード（メール、カレンダー、SharePoint、Teamsなど）にアクセスするためのガバナンス付きMCPサーバーを呼び出せる

SDKはPython・JavaScript・.NETの3言語に対応しており、それぞれのパッケージマネージャ（PyPI、npm、NuGet）で公開されています（SDKがエージェント自体を作成・ホストしない位置づけは、冒頭の「Copilot Studio・Agent Frameworkとの違い」で詳説）。

Agent 365 CLI

Agent 365 CLIは、エージェント開発のライフサイクル全体を自動化するコマンドラインツールです。

CLIで実行できる主な操作を以下に示します。

• Agent Blueprintと関連リソースの作成
• 標準MCPサーバーやカスタムMCPサーバーの管理、権限設定
• エージェントコードのAzureへのデプロイ
• エージェントアプリケーションパッケージのMicrosoft管理センターへの公開
• 不要になったブループリント・ID・Azureリソースのクリーンアップ

SDKとCLIを組み合わせることで、エージェントの設計からデプロイ、運用管理までを一貫したワークフローで実行できます。

Work IQ MCPサーバー

Agent 365では、MCP（Model Context Protocol）に準拠したWork IQ MCPサーバーが標準で提供されています。これはエージェントがMicrosoft 365のデータやツールに安全にアクセスするための仕組みで、Data・Context（Memory）・Skills and Tools（Inference）といった3層で構成されるWork IQインテリジェンスレイヤーを支える実装でもあります（公式ページ内でも文脈により表記が揺れるため、ここでは併記しています）。

2026年5月時点で提供されている主なMCPサーバーは以下のとおりです。

MCPサーバー	主な機能
Work IQ Copilot	Microsoft 365 Copilotとのチャット、ファイルによるグラウンディング
Work IQ User	ユーザープロファイル、マネージャー・直属の部下の取得
Work IQ Mail	メールの作成・更新・削除、返信、セマンティック検索
Work IQ Calendar	イベントの作成・一覧・更新・削除、承諾・辞退、競合解決
Work IQ Teams	チャットの作成・更新、メンバー追加、メッセージ投稿、チャネル操作
Work IQ Word	ドキュメントの作成・読み取り、コメントの追加・返信
Work IQ Excel	スプレッドシートの読み取り・書き込み
Work IQ Knowledge	ナレッジベースへのアクセス
Dataverse / Dynamics 365	CRUD操作とドメイン固有のアクション
SharePoint / OneDrive	ファイル・フォルダー操作、メタデータ取得、共有
SharePoint Lists	リストアイテムの操作
Sales	営業関連データへのアクセス

IT管理者はMicrosoft 365管理センターで各MCPサーバーの有効化・ブロックを組織レベルで制御できます。MCPサーバーがブロックされると、すべてのユーザーとエージェントに対して即座にアクセスが遮断されます。

さらに、開発者はMCP Management Serverを使ってカスタムMCPサーバーを構築することも可能です。1,500以上のコネクタ（ServiceNow、JIRAなど）、Microsoft Graph API、REST APIなどを活用して、業務特化型のツールをエージェントに提供できます。ただし、カスタムMCPサーバーの公開（publish）はテナント管理者に限定されています。

Agent 365 Tools Gateway（preview）

Tools Gatewayは、エージェントが実行時に呼び出すMCPツールをランタイムで検査・遮断するゲートウェイレイヤーです。2026年4月にpublic preview入りし、GA時点でも引き続きpreview段階です。

主に提供される機能は次のとおりです。

• ペイロード検査
  ツール呼び出しの引数・戻り値をスキャンし、機密データや危険な操作を検出する
  
  

• レート制限
  特定エージェント・特定ツールに対する呼び出し頻度を制限し、暴走時の被害を局所化する
  
  

• ポリシー強制
  Defender・Purviewのポリシーをツールコール時点で適用し、宣言的なガバナンスをコードに反映する

Tools Gatewayはまだpreview段階ですが、own access型エージェント（特に team workflows参加や Agent identity authentication による完全自律）を本番投入する前提では事実上必須の防護層になる位置づけです。SLAが求められる本番運用では、Tools GatewayのGA時期を待つか、当面はSDK内のObservability機能で代替するかの判断が必要です。

---

Microsoft Agent 365の活用事例

Agent 365で管理されたエージェントは、実際の業務現場でどのように動くのでしょうか。

ここでは、Microsoft社内の大規模運用（Customer Zero）、テンプレートとして提供されているSales Development Agent、そしてGA発表時に公開されたパートナー統合事例を順に取り上げます。

Microsoft社内での運用事例（Customer Zero）

Microsoftは自社を「Customer Zero」（最初の顧客）として、Agent 365をGA前から全社展開してきました。

Microsoft InsideTrackの報告によると、その規模は以下のとおりです。

• 50万以上のエージェントが社内で稼働中
• 過去28日間で毎日6万5,000件以上のレスポンスを生成
• 主要な用途はリサーチ、コーディング支援、営業インテリジェンス、カスタマートリアージ、HR自己サービス

Microsoft Digital（社内IT部門）がこの大規模運用から得た知見は、製品チームへのフィードバックとしてMicrosoft 365管理センターのコントロール機能に直接反映されています。

さらに、Agent 365のRegistryにはプレビュー期から数千万のエージェントが登録され、数万社の顧客がGA前段階で採用していました。GA時点でこの規模を管理している実績は、Agent 365のスケーラビリティを実証するものと言えます。

Sales Development Agent（営業開発エージェント）

Sales Development Agentは、Teams内で動作する営業アウトリーチ支援エージェントで、Microsoft純正テンプレートとして提供されています。現時点ではpreview機能で、Microsoft 365のTargeted releaseプログラムにオプトインした顧客が利用できます。

営業プロセスの自動化フローは以下のとおりです。

1. リストの精査
   担当者がCSVで見込み客リストをアップロードすると、エージェントがデータを検証する。会社名の欠落やメールアドレスの無効性といった不備があれば指摘する
   
   

2. メール作成
   検証されたリストに基づき、顧客ごとにパーソナライズされた営業メールの下書きを自動作成する。製品知識や過去の成功事例を参照し、最適な文面を生成する
   
   

3. フォローアップ
   返信がない顧客への追撃メールや、返信があった場合の一次対応、CRMへの活動記録を自動化する

このエージェントは単なる自動化ツールではなく、人間と協働する「同僚」として設計されています。

Human-in-the-loopの設計原則

Agent 365のエージェントが完全に勝手に行動するわけではありません。「プレイブック」と呼ばれるルールに従い、重要な判断は人間に委ねる安全設計がなされています。

• ドラフト承認
  作成したメールは勝手に送信せず、必ず人間に「ドラフト」として提示し、承認を得てから送信する
  
  

• ガイドライン遵守
  「競合他社を批判しない」「価格交渉は人間にエスカレーションする」といった自然言語のルールを厳守する
  
  

• ロールプレイ
  実際の顧客に送る前に、Teamsチャットでエージェントと練習を行い、挙動をテストできる

Agent 365のエージェントは「暴走しないAI」として設計されており、人間とAIが信頼関係を持って協働できる環境を提供します。

パートナーエージェントの統合事例

GA発表時には、パートナー製エージェントがAgent 365の管理対象として組み込まれた具体例が公開されています。

• Zensai - Human Success Agent
  人事・学習領域に特化したエージェント。従業員データをリアルタイム化し、研修推奨や離職リスク検知を業務の流れの中で実行する
  
  

• Genspark × Microsoft 戦略パートナーシップ
  Genspark製エージェントをWord・Excel・PowerPoint・Agent 365に直接埋め込む構成。Microsoft環境内のドキュメント業務に特化したインテリジェントワークフローを提供する
  
  

• Kasisto - KAIgentic for Banking
  金融機関向けに、コンプライアンスを満たした銀行AIエージェントをAgent 365管理下で展開。規制業界での統制と業務効率化を両立する

共通しているのは、Agent 365の管理基盤上で動かすことで、IT・セキュリティ部門が新たなパートナーごとに監査・ID連携を作り直さずに済む点です。SaaS型のエージェントを次々に増やしても、ガバナンスは1本化された状態を維持できます。

---

Microsoft Agent 365の料金とライセンス

Agent 365の料金体系はGAに合わせて大きく整理され、プレビュー期の「per-agent-instance」モデルから「per-user」モデルへ刷新されました。

スタンドアロンプラン（per-user $15/月）

GA時点でのスタンドアロン価格は以下のとおりです。

項目	内容
価格	$15 / ユーザー / 月（年契約）
ライセンス単位	エージェントを管理するユーザー、またはエージェントを業務に使うユーザー
含まれる範囲	OBO（On-Behalf-Of）エージェントは束ねてカバー（追加課金なし）
カバー対象モード	delegated access（OBO）と own access（behind the scenes）はGAでper-userに包含。own access（team workflows）はpublic preview扱い、独自credentialによる Agent identity authentication は Frontier program（後述）

※ 2026年5月時点。最新はMicrosoft Agent 365公式ページで確認推奨。

ポイントは、1ユーザーがOBOエージェントを何個動かしてもライセンスは1本で済む設計に変わったことです。プレビュー期はエージェントインスタンス数で課金されていたため、複数エージェントを試す際の予算が読みにくいという問題がありましたが、GAではユーザー数ベースで予算化できます。

ライセンス上、Agent 365を有効化するためのMicrosoft 365側の必須前提条件はありません。ただし公式ドキュメントでは、Entra P1 / P2 / Entra Suite と Purview Data Loss Prevention の併用が推奨されています。これらが揃っていないとAgent 365のSecure層の効果を十分に引き出せないため、実用上は併用前提で予算を組むのが現実的です。

Microsoft 365 E7との関係

2026年5月1日には、新しいライセンスティアであるMicrosoft 365 E7も同時にGAされました。E7は、Agent 365に加えてMicrosoft 365 E5・Microsoft 365 Copilot・Microsoft Entra Suiteをまとめた「エージェントファースト」のバンドルです。

項目	内容
E7価格	$99 / ユーザー / 月
E7（No Teams）	$90.45 / ユーザー / 月
含まれるもの	Microsoft 365 E5 + Microsoft 365 Copilot + Agent 365 + Microsoft Entra Suite
個別合計（参考）	E5 $60 + Copilot $30 + Agent 365 $15 + Entra Suite $12 ＝ $117

※ E5は2026年7月以降$60 / ユーザー / 月に改定予定。E7は$99で据え置き。

スタンドアロンでAgent 365のみ追加する場合、既にE5 + Copilot + Entra Suiteを契約している組織なら大きな差は出ません。一方、これら全体を新規導入する組織やEntra Suiteを含めた高度なセキュリティを必要とする組織では、E7バンドルが約15%程度のコスト圧縮になります。

判断軸を整理すると、E7が有利になりやすいのは「Copilot＋Entra Suite＋Agent 365をフルセットで使う」ケースで、それ以外（既存ライセンスを維持したい、Copilotだけ既導入で他は段階導入したい等）はスタンドアロン$15 / 月の追加が現実的です。

自律型エージェントの提供状況（delegated access／own access／Frontier）

公式GAアナウンスでは、エージェントが「どのアイデンティティで動くか」によって提供状況が分かれています。Agent 365のライセンスでカバーされる範囲を判断するには、自社のエージェントがどのモードで動くかを先に整理する必要があります。

動作モード	提供状況	概要
delegated access（OBO / On-Behalf-Of）	GA	ユーザーの代理として、紐付くユーザーの権限範囲で動作。per-user $15/月のスタンドアロンまたはE7に含まれる
own access（behind the scenes）	GA	エージェント自身のIDで、バックグラウンド処理として自律的に動く形態。Agent 365のper-userライセンスでカバーされる
own access（team workflows）	Public Preview	エージェント自身のIDで、チームのワークフロー内に人と並んで参加する協働型。GA時点ではpreview段階
Agent identity authentication（独自credentialでの認証・実行）	Frontier program	エージェントが独自の認証情報で自身を認証して自律的に動く形態。Frontier プログラム参加組織での先行アクセス

GA時点で per-user モデルでカバーされるのは、表の上2つ（delegated accessと own access の behind the scenes）です。team workflowsに参加するown accessはpublic preview扱いで、本番SLAが付きません。さらに、エージェントが独自credentialで自身を認証して動かすAgent identity authenticationは、引き続き Frontier program 経由の先行アクセスです（公式 Microsoft Learn ではAgent identity authenticationとして整理されています）。

team workflows型を本格採用したい場合や Agent identity authentication による完全自律を使いたい場合は、自社シナリオの提供状況を必ず公式GAアナウンスで確認したうえで、preview期間中はリスクを抑えた範囲で検証する設計が安全です。

---

Microsoft Agent 365の始め方と導入時の注意点

GAされたことで、Agent 365の利用開始は商用環境向けに大きく簡素化されました。一方で、GA時点でもpreview継続中の機能・テンプレート固有の制限が複数あり、本番設計時には押さえる必要があります。

管理センターでの有効化手順

GA以降は、商用テナント（Commercial customers）の管理者がMicrosoft 365管理センターから即座にAgent 365を有効化できます。Frontierプレビュー申請はもはや必須ではありません。

代表的な有効化手順は以下のとおりです。

1. サインイン
   グローバル管理者としてMicrosoft 365管理センターにアクセスする
   
   

2. Agent 365メニューを開く
   GA以降、左ペインに「Agents」メニューが標準表示される。ここでエージェントの登録・展開・権限管理を行う
   
   

3. ライセンス割り当て
   Agent 365スタンドアロン または Microsoft 365 E7 のライセンスを、エージェントを管理・利用するユーザーに割り当てる
   
   

4. 権限・MCPサーバーの設定
   エージェントがアクセスできるリソース（MCPサーバー、Graph APIなど）の権限を承認し、利用ユーザーを割り当てる

変更がテナント全体に反映されるまで最大1時間程度かかる場合がある点は、プレビュー期と同様です。本番ロールアウトでは、まず一部部門に限定して有効化し、Registry・Agent Mapで挙動を確認してから全社展開する段階的アプローチが安全です。

GA時点でpreview継続中の機能

GAされたコア機能とは別に、いくつかの機能は引き続きpublic previewです。本番運用設計の際は、preview段階の機能を「将来正式機能になる前提で計画に含める」のか「現時点ではPoC範囲に留める」のかを明確に分ける必要があります。

機能領域	現状	本番運用上の扱い
Agent 365 Tools Gateway	preview	ランタイム保護として要注目だが本番SLAなし。重要エージェントは併行のSDK Observabilityで補完
Foundry / Copilot Studio agentsのSecurity Posture Management	preview	Defender for AIで個別検出は可能。本番運用時は手動レビューを併用
Multi-cloud Registry sync（AWS Bedrock / Google Cloud）	preview	観測の統合は可能。検知・防御の統合は段階拡張待ち
Windows 365 for Agents	preview（米国のみ）	サンドボックス用途で先行採用可。基幹業務での常用や日本リージョン展開はGA・拡張待ち
own access（team workflows）型エージェント	public preview	チームワークフロー参加型は本番SLAなし。本格採用前にpreview期間中の検証が必要
Agent identity authentication（独自credential認証）	Frontier program	独自認証で動く完全自律型は引き続きFrontier program経由の先行アクセス

本番運用を計画する場合、これらのpreview機能をクリティカルパスに置かない設計が安全です。

Sales Development Agent（テンプレート）の主な制限

Microsoft純正テンプレートのSales Development Agent自体はpreview機能として提供されており、Microsoft 365のTargeted releaseプログラムにオプトインした顧客が利用できます。テンプレート固有の制限が複数あるため、本番導入を検討する場合は事前に整理しておく必要があります。

制限項目	内容
チャット対応	エージェント作成者との1対1 Teamsチャットのみ対応。他のユーザーはチャットできない
通信チャネル	メールとTeamsチャットのみ。Teamsチャネル、ドキュメントコメント、会議は未対応
メールスレッド	エージェントが開始したスレッドへの返信のみ対応。外部から送られたメールは無視される
名前・メールアドレス変更	デプロイ後もエージェントの名前とメールアドレスはMicrosoft 365管理センターで変更可能
データ取り込み	SharePoint・OneDrive・Webリンクに対応。再帰的クロールやメディアファイルは未対応
分析機能	ビジュアルレポートダッシュボードなし。進捗はTeamsチャットで通知
メール送信時間	週末や祝日を含め、全時間帯でメールが送信される
実行制御	一度起動すると停止操作まで自律的に処理を続ける。途中ステップ単位の停止／再開は提供されていない
検証チャネル	デプロイ前の動作検証はエージェント作成者との1対1 Teamsチャットに限定される
パイロット移行	テスト段階からパイロット段階への自動移行はなく、IT管理者が明示的に切り替える必要がある

本番導入を検討する場合は、最新の制限事項を公式ドキュメントで確認することを推奨します。営業領域のエージェント活用が中心テーマなら、Sales Development Agentをそのまま使うのではなく、自社ドメインのプロセスに合わせてCopilot StudioやMicrosoft Agent Frameworkで構築し、Agent 365管理下に置く設計のほうが実用度が高いでしょう。

---

エージェントのガバナンスを実運用に落とし込むなら

Agent 365でAIエージェントの可視化・権限管理の枠組みは見えた。次の課題は、その管理体制のもとで実際のAgent群を稼働させ、業務成果を出すことです。

ここで効いてくるのが、AI総合研究所が提供するAI Agent Hubです。Agent 365のガバナンス設計と同じ思想で構築・管理・実行を一気通貫に整え、「管理するだけ」から「動かして成果を出す」段階へ進められる位置づけのエンタープライズAI基盤です。

• Agent 365のガバナンス設計をそのまま業務Agentに適用
  Registry・Access Control・監査証跡の仕組みを、業務Agentの本番運用にそのまま活用。構築から管理まで一貫したガバナンスを実現します。
  
  
• Teams上でAgent群が業務を自動実行
  管理基盤で可視化・統制されたAgentが、経費精算・承認ワークフロー・データ参照をTeamsチャットから自動実行。投資対効果を業務成果で可視化します。
  
  
• 使い慣れたMicrosoft環境をそのまま活用
  Teamsなど既存のMicrosoftツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
  
  
• データは100%自社テナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、設計から運用まで伴走支援します。まずは無料の資料で、自社の業務にどう活用できるかご確認ください。

---

まとめ

Microsoft Agent 365は、AIエージェントを「信頼できるデジタル社員」として迎え入れ、組織の戦力にするための統合コントロールプレーンとして、2026年5月1日に商用GAしました。

Copilot StudioやAgent Frameworkが「エージェントを作る」ためのツールであるのに対し、Agent 365は「作られたエージェントを安全に運用する」ためのレイヤーで、3つのコア能力（Observe・Govern・Secure）を中心に役割が分かれています。Multi-cloud Registry sync・Windows 365 for Agents・ローカルAIエージェント検出といったGA時の拡張により、管理対象スコープはMicrosoft環境を超えてマルチクラウド・ローカル端末まで広がりました。

料金モデルはper-user $15 / 月（delegated access＝OBOエージェントとown access〔behind the scenes〕を包含）に整理され、フルバンドルのMicrosoft 365 E7は$99 / 月です。一方で、own access（team workflows）や Agent identity authentication による完全自律、Tools Gateway、Foundry / Copilot Studio agentsのSecurity Posture Managementなど、preview継続中の領域も多く残っています。

これからAgent 365を導入する組織にとっての現実的な進め方は、まずObserve層のRegistry・Agent Mapで自社のエージェント実態を全数把握すること、次にGovern層のAccess Control・Identity Governance・Agent Blueprintでガバナンスポリシーを型として整備すること、その上でSecure層の機能でMicrosoftスタックとの連動を活かすことです。preview機能はクリティカルパスに置かず、team workflowsへの参加や Agent identity authentication による完全自律を本番運用したいケースでは、Frontier programやpublic preview期間中の先行検証を経てから商用シナリオに移すロードマップが安全と言えます。