企業のAIエージェント導入が加速するなか、ひとつの問いが浮上している。「動いているエージェントを、誰が、どう管理するのか？」だ。
Microsoftの調査によれば、Fortune 500企業の80%がすでにAIエージェントを運用しているという。だが、エージェントが増えるほど、セキュリティリスクも膨らむ。誰がどのデータにアクセスしているのか。暴走したエージェントを即座に止められるのか。こうした課題に対する回答として、Microsoftが2026年3月のRSAC 2026で発表したのが「Microsoft Agent 365」だ。
この記事では、Agent 365の仕組み・料金・導入方法を、Q&A形式で整理する。
そもそもMicrosoft Agent 365とは何か
ひとことで言えば、AIエージェント専用のコントロールプレーンだ。
これまでMicrosoft Entraは人間やデバイスのIDを管理してきた。Agent 365は、その管理対象を「AIエージェント」にまで拡張する。組織内で稼働するすべてのAIエージェントを、1つのダッシュボードで把握・監視・統制できる基盤になる。
Microsoft製のエージェントだけでなく、オープンソースやサードパーティ製のエージェントも管理対象に含む点がポイントだ。つまり、LangChainやCrewAIで構築した独自エージェントも、Agent 365のガバナンス下に置ける設計になっている。
GA（一般提供）は2026年5月1日。現在はプレビュー段階だ。
何が新しいのか——従来のID管理との違い
正直、「それってEntraの拡張じゃないの？」と思った人もいるだろう。確かに基盤技術はEntraだ。だが、AIエージェント特有の要件に対応するために、いくつかの重要な新機能が追加されている。
| 機能 | 従来のEntra ID | Agent 365（Entra Agent ID含む） |
|---|---|---|
| 管理対象 | 人間ユーザー、デバイス、サービスプリンシパル | 上記＋AIエージェント（固有IDを付与） |
| アクセス制御 | ロールベース（RBAC） | RBAC＋エージェントの行動パターンに基づく条件付きアクセス |
| 可視性 | ユーザーのサインインログ | エージェントの全操作ログ＋Security Dashboard for AI |
| データ保護 | DLP（データ損失防止） | DLP＋Purviewによるプロンプト内PII自動ブロック |
| 脅威検知 | ITDR（ID脅威検知と対応） | ITDR＋Shadow AIの自動検出 |
要するに、「人間と同じようにエージェントにもIDを発行し、同じゼロトラストポリシーを適用する」という発想だ。これがMicrosoftの言う「Zero Trust for AI」の核心になる。
具体的にどんな機能があるのか
Agent 365の主要コンポーネントは大きく4つに分かれる。
1. Entra Agent ID — エージェントに身分証明書を与える
すべてのAIエージェントにユニークなIDを発行し、Conditional Access（条件付きアクセス）を適用する。これにより、「このエージェントは営業データにはアクセスできるが、人事データには触れない」というきめ細かい制御が可能になる。
# Microsoft Graph APIでエージェントIDの登録（Python SDK例）
# 動作環境: Python 3.10+, azure-identity>=1.15, msgraph-sdk>=1.5
from azure.identity import ClientSecretCredential
from msgraph import GraphServiceClient
credential = ClientSecretCredential(
tenant_id="YOUR_TENANT_ID",
client_id="YOUR_CLIENT_ID",
client_secret="YOUR_CLIENT_SECRET"
)
graph_client = GraphServiceClient(credential)
# エージェントIDの作成（プレビューAPI）
agent_identity = {
"displayName": "CS-Support-Agent-v2",
"agentType": "autonomous",
"description": "カスタマーサポート用AIエージェント",
"owner": "security-team@contoso.com"
}
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 正式なSDKサポートはGA後（2026年5月以降）に提供予定
2. Security Dashboard for AI — 全エージェントを一覧で監視
CISOやセキュリティチーム向けの統合ダッシュボード。組織内のAIエージェントの稼働状況、アクセスパターン、リスクスコアを一画面で確認できる。2026年3月時点ですでに一般提供されている。
3. Purview連携 — プロンプトの中身まで保護
Microsoft PurviewがAIエージェントのプロンプト処理に組み込まれ、クレジットカード番号やマイナンバーなどの個人情報（PII）がプロンプトに含まれていた場合に自動ブロックする。エージェントが意図せず機密情報を外部APIに送信するリスクを、入口で食い止める設計だ。
4. Shadow AI Detection — 野良エージェントを発見する
IT部門の管理外で動いているAIエージェント（いわゆるシャドーAI）を、ネットワーク層で自動検出する。Entra Internet Accessとの連携で、2026年3月31日から一般提供が開始される。
よくある誤解を整理する
誤解1：「Microsoft製エージェントしか管理できない」
これは違う。Agent 365はプラットフォームに依存しない設計を謳っている。OpenAI Agents SDK、LangChain、CrewAIなどで構築したエージェントも、Entra Agent IDに登録すれば管理対象になる。ただし、現時点ではMicrosoft製エージェント（Copilot Studio、Azure AI Agent Service）との統合が最も深い。サードパーティとの統合はGA後に段階的に拡充される見込みだ。
誤解2：「大企業だけが必要な話」
そうとも言えない。McKinseyの最新調査では、すでに23%の企業が少なくとも1つのビジネス機能でエージェント型AIを本格展開しており、39%が実験を開始している。エージェントが5〜10体を超えると、手動での管理は現実的でなくなる。スタートアップでも、本番環境にエージェントを複数投入しているなら無関係ではない。
誤解3：「既存のSIEMやIDaaSで十分」
従来のSIEMはログ集約と相関分析に強いが、AIエージェント固有の脅威（プロンプトインジェクション、データ過剰共有、エージェント間の不正通信）には対応していない。Agent 365は、こうしたAI特有の脅威モデルに最適化されている点が差別化要因だ。
料金体系——スタンドアロンとE7バンドルの2択
| プラン | 月額（ユーザーあたり） | 含まれるもの |
|---|---|---|
| Agent 365スタンドアロン | $15 | Agent 365のみ |
| Microsoft 365 E7 Frontier Suite | $99 | M365 E5＋Copilot with Work IQ＋Agent 365＋Entra Suite |
E7は個別購入比で約15%のコスト削減になるとMicrosoftは説明している。すでにM365 E5を契約している組織であれば、Agent 365のスタンドアロン追加（$15/ユーザー/月）が現実的な選択肢だろう。
料金情報の最終確認: 2026-03-23
開発者が知っておくべき実装のポイント
Agent 365を導入する際に、開発者として最低限押さえておきたい設定がある。
# Conditional Accessポリシーの設定例（Azure CLI）
# 動作環境: Azure CLI 2.60+, jq
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 1. エージェント用のセキュリティグループを作成
az ad group create
--display-name "AI-Agents-Production"
--description "本番環境で稼働するAIエージェントのグループ"
--mail-nickname "ai-agents-prod"
# 2. エージェントIDをグループに追加
az ad group member add
--group "AI-Agents-Production"
--member-id "<agent-object-id>"
# 3. Conditional Accessでアクセス制御
# - 営業データ（SharePoint）へのアクセスを許可
# - 人事データ（HR System）へのアクセスをブロック
# - 1時間ごとにトークンを再検証（セッションリスク評価）
# エージェントの行動ログを取得する例（Microsoft Graph API）
# 動作環境: Python 3.10+, requests>=2.31
import requests
import os
token = os.environ["GRAPH_ACCESS_TOKEN"]
headers = {"Authorization": f"Bearer {token}"}
# エージェントの操作ログを直近24時間分取得
response = requests.get(
"https://graph.microsoft.com/v1.0/security/agentActivities",
headers=headers,
params={
"$filter": "createdDateTime ge 2026-03-22T00:00:00Z",
"$top": 50,
"$orderby": "createdDateTime desc"
}
)
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# agentActivities APIはGA後に正式提供。プレビュー中はbeta エンドポイントを使用
activities = response.json().get("value", [])
for act in activities:
print(f"Agent: {act['agentDisplayName']} | Action: {act['actionType']} | Risk: {act['riskLevel']}")
まだ分からないことも多い
筆者も判断がつかない点がいくつかある。正直に書いておく。
- サードパーティ統合の実際の完成度 — GA時点（5月1日）で、非Microsoft製エージェントの管理がどこまで実用レベルかは未知数。「登録できる」と「実用的に管理できる」は別の話だ
- Shadow AI Detectionの精度 — ネットワーク層での検出は、VPN経由やローカル実行のエージェントを捕捉できるのか
- スケーラビリティ — 1,000体以上のエージェントを運用する大規模環境でのパフォーマンスは、実データ待ち
- マルチクラウド対応 — AWS・GCPで稼働するエージェントをどこまで管理できるかは、公式ドキュメントでも詳細が限られている
これらは5月のGA以降、実環境のフィードバックで明らかになるだろう。
結局どうすればいいのか——3つの準備
1. エージェント台帳を今すぐ作る
自社で稼働しているAIエージェントの棚卸しを始めよう。名前、用途、アクセスするデータ、責任者を一覧にするだけで、Agent 365導入時のスムーズな移行につながる。
2. Entra IDの棚卸し
既存のEntra ID環境を確認し、サービスプリンシパルやマネージドIDの整理を進めておく。Agent 365はEntraの上に構築されるため、基盤の健全性が前提になる。
3. 5月1日のGAに備えてプレビューを試す
Agent 365の公式ページからプレビュー申請が可能だ。検証環境で先行して触っておけば、GA後の本番展開がスムーズになる。
参考・出典
- Secure agentic AI end-to-end — Microsoft Security Blog（参照日: 2026-03-23）
- Microsoft Agent 365 公式ページ — Microsoft（参照日: 2026-03-23）
- Introducing the First Frontier Suite Built on Intelligence & Trust — Microsoft Blog（参照日: 2026-03-23）
- Microsoft outlines agentic AI security strategy — SiliconANGLE（参照日: 2026-03-23）
- 10% Of Enterprise Functions Use AI Agents, McKinsey Finds — Forbes（参照日: 2026-03-23）
あわせて読みたい:
- AIエージェントにIDは必要か？Okta新製品が示すセキュリティの新常識 — Agent 365と比較しながら読むと理解が深まる
- DASFとは？AIエージェント35のリスクを定義した安全基盤 — セキュリティフレームワークの別の視点
AIエージェントの導入戦略やセキュリティ設計について、より詳しい相談はお問い合わせフォームからお気軽にどうぞ。
この記事はAIgent Lab編集部がお届けしました。
