Microsoft Agent 365のライセンス移行で管理者が最初に押さえるべき点は、2026年7月1日以降、Microsoft Copilot StudioとMicrosoft FoundryのAIエージェント向け一部セキュリティ機能が、Microsoft Agent 365ライセンス前提に切り替わることです。対象テナントで準備が不十分な場合、エージェントそのものが直ちに削除されるという話ではありませんが、Defender上の可視化、脅威検出、リアルタイム保護、Advanced Huntingの運用に影響が出ます。Microsoft 365管理者は、ライセンス数の見積もりだけでなく、Defender設定、ハンティングクエリ、アラート連携、サードパーティエージェントの同期方法まで確認しておく必要があります。(Microsoft Learn)
Microsoft Agent 365のライセンス移行で何が変わるのか
Microsoft Agent 365は、組織内のAIエージェントを監視、管理、保護するためのコントロールプレーンです。Microsoft Learnでは、エージェントの利用状況や健全性を一元的に確認する「Observe」、ライフサイクル管理やアクセス制御を行う「Govern」、Entra、Purview、Defenderと連携して保護する「Secure」が主要な役割として説明されています。(Microsoft Learn)
今回のポイントは、Agent 365そのものの一般提供ではなく、既存のDefender系ライセンスで利用できていた一部のAIエージェント保護・可視化機能が、2026年7月1日からAgent 365対象ライセンスへ移ることです。Microsoftの公式情報では、Microsoft Copilot StudioエージェントとMicrosoft Foundryエージェント向けのAI agent security capabilitiesが、既存のDefender for Cloud AppsまたはDefender for Cloudではカバーされなくなると説明されています。(Microsoft Learn)
| 確認項目 | 7月1日以降の変更点 | 管理者が見るべきポイント |
|---|---|---|
| Copilot Studioエージェント | Discovery、posture、脅威検出、リアルタイム保護、Advanced Hunting調査にAgent 365ライセンスが必要 | Defender for Cloud Appsで見ていたエージェント監視・ブロック運用が残るか確認 |
| Microsoft Foundryエージェント | クラウドホスト型エージェントの検出、セキュリティ態勢、脅威保護にAgent 365ライセンスが必要 | Defender for CloudのCSPMやDefender for AI Services依存の運用を棚卸し |
| Advanced Hunting | AIエージェントのインベントリテーブルが新しいAgent 365側のスキーマへ移行 | 旧テーブル参照のKQL、カスタム検出、外部スクリプトを点検 |
| リアルタイム保護 | 既存のAgent 365リアルタイム保護ルールのうちBlock設定は、7月1日にそのままではブロック継続しない | 新しいPolicies画面でブロックルールを再定義 |
| サードパーティクラウドエージェント | Defender for Cloudコネクタ経由では検出されなくなる | Agent 365 registry syncへの移行を検討 |
| AzureポータルのFoundry表示 | Foundry agent dataがData and AI dashboardやCloud Security Explorerに表示されなくなる | SOCやクラウド管理チームの確認画面を変更 |
この変更で特に影響を受けるのは、Copilot StudioやFoundryでエージェントを試験導入しているだけの企業よりも、すでにDefenderで検出・アラート・調査・ブロックまで運用している企業です。ライセンスを「後で考える費用項目」と扱うと、7月1日以降に検知ルールやダッシュボードが空振りする可能性があります。
影響を受ける組織とユーザー
Microsoft Agent 365のライセンスは、エージェント単位ではなくユーザー単位です。公式FAQでは、Agent 365はMicrosoft 365 E7に含まれる場合でも、スタンドアロンで購入する場合でもユーザー単位でライセンスされ、エージェント自体には個別ライセンスは不要と説明されています。ライセンスの考え方は、エージェントを利用するユーザー、所有者、スポンサー、管理者など、エージェントに関係するユーザーにひも付きます。(Microsoft)
確認対象になるユーザー
以下のユーザーは、Agent 365ライセンス要否の確認対象に入れるべきです。
- Copilot Studioエージェントを利用するユーザー
- Foundryエージェントを利用、作成、管理するユーザー
- エージェントの所有者、スポンサー、業務部門側の管理者
- Microsoft 365 Copilot上でエージェントを利用するユーザー
- Defender、Purview、Entra、Intuneでエージェントの監視・制御を担当する管理者
- SOC、CSIRT、監査、コンプライアンス部門の担当者
よくある失敗は、「エージェントを作った開発者だけにライセンスを割り当てればよい」と考えることです。実際には、エージェントを使って業務上の利益を得るユーザー、運用責任を持つ所有者やスポンサーも確認対象になります。MicrosoftのFAQでも、Agent 365管理対象エージェントとやり取りする、管理する、スポンサーになるユーザーには広めのカバレッジを推奨しています。(Microsoft)
Microsoft 365 E5は「前提」だが「含まれる」とは限らない
ここは誤解しやすい部分です。2026年6月のPartner Center announcementでは、新しいAgent 365購入について、Enterprise customersはMicrosoft 365 E5、Frontline WorkerユーザーはMicrosoft Defender and Purview F5 level、SMB customersはMicrosoft 365 Business Premiumが前提になると案内されています。一方で、Microsoft 365 E7にはMicrosoft 365 E5、Agent 365、Microsoft 365 Copilot、Microsoft Entra Suiteが含まれると説明されています。(Microsoft Learn)
つまり、E5はAgent 365機能を十分に使うための土台になり得ますが、E5だけでAgent 365の有償機能がすべて含まれると考えるのは危険です。E3 + Copilot、E5、E7、Agent 365スタンドアロンのどれを採用しているかで、確認すべきライセンス経路が変わります。
| 現在の構成例 | 判断のポイント |
|---|---|
| Microsoft 365 E7 | Agent 365を含む構成として確認しやすい。対象ユーザー範囲と実際の割り当てを確認する |
| Microsoft 365 E5 + Agent 365スタンドアロン | E5を前提に、Agent 365を必要ユーザーへ追加する構成。最小割り当てにしすぎない |
| Microsoft 365 E5のみ | Agent 365の対象機能が使えるとは限らない。7月1日以降のDefender上のAIエージェント機能を確認 |
| Microsoft 365 E3 + Copilot | Agent 365の前提条件を満たさない可能性がある。E5/E7または該当アドオンの検討が必要 |
| Business Premium | SMB向け前提には入るが、追加のDefender/Purview関連要件や機能差を確認する |
7月1日前にMicrosoft 365管理者が確認すべき設定
Agent 365対象ライセンスがテナントにあるか確認する
最初に確認すべきなのは、テナントがAgent 365対象ライセンスを持っているかです。Microsoftの移行手順では、対象ライセンスがないテナントは2026年7月1日の切り替え時点でエージェントセキュリティ機能を失うと説明されています。未導入の場合は、Agent 365の管理者主導トライアルも選択肢として案内されています。(Microsoft Learn)
実務では、次の順で進めると混乱しにくくなります。
| 手順 | 確認内容 | 成果物 |
|---|---|---|
| ライセンス棚卸し | E3、E5、E7、Copilot、Agent 365スタンドアロンの保有状況を確認 | ユーザー別ライセンス一覧 |
| 利用者棚卸し | Copilot Studio、Foundry、Microsoft 365 Copilot上のエージェント利用者を確認 | 対象ユーザー候補リスト |
| 所有者棚卸し | エージェントの所有者、スポンサー、管理者を確認 | ライセンス割り当て候補 |
| 費用試算 | 必要ユーザー数を最小・標準・広めの3パターンで試算 | 予算申請資料 |
| 割り当て検証 | 少数ユーザーでAgent 365機能の表示・ログ・検出を確認 | 移行判定メモ |
ライセンス数を見積もるときは、現在の利用者だけでなく「7月以降に本番展開する予定のエージェント」も含めてください。Copilot StudioのPoC段階では数人でも、本番化後に営業部門やサポート部門へ展開すると、一気に対象ユーザーが増えます。
DefenderのSecurity for AI Agents設定を確認する
7月1日以降、Security for AI関連機能はDefender設定の単一トグルに統合されます。Microsoftの移行手順では、Security for AI Agents toggleがオフの場合、Security for AI機能が無効になると説明されています。(Microsoft Learn)
確認先は次の流れです。
- Microsoft Defenderポータルを開く
- Settingsを開く
- Security for AIまたはSecurity for AI agentsの設定を確認
- Security for AI Agentsがオンになっているか確認
- Agent 365との接続状態を確認
- Copilot Studio連携やローカルAIエージェント保護を使っている場合は、関連設定も確認
リアルタイム保護を有効にする手順として、Defenderの公式ドキュメントでは、System > Settings > Security for AI agentsを開き、Security for AI agentsをオンにし、AI real-time protection & investigationでAgent 365が接続されていることを確認する流れが示されています。(Microsoft Learn)
Advanced HuntingのKQLをAgentsInfoへ移行する
SOCやセキュリティ管理者にとって重要なのが、Advanced Huntingのテーブル移行です。Microsoftは2026年6月更新のスキーマ変更で、AIAgentsInfoテーブルがAgentsInfoテーブルへ移行中であり、Agent 365 customers should use AgentsInfo table todayと案内しています。AIAgentsInfoは2026年7月1日までアクセス可能とされています。(Microsoft Learn)
まずは、以下を検索してください。
- Defender内の保存済みKQL
- カスタム検出ルール
- Microsoft SentinelのWorkbook
- Logic AppsやPower Automateから呼び出すクエリ
- GitHubや社内Wikiに保存しているKQL
- API経由で実行するスクリプト
- SOC運用手順書に貼り付けている調査クエリ
Microsoftのスキーマ変更ページでは、Defender XDR内に保存されたクエリやカスタム検出ルールは自動更新される一方、API経由で実行するクエリやDefender XDR外に保存しているクエリは手動更新が必要と説明されています。列名も変わるため、単にテーブル名を置換するだけでは不十分です。(Microsoft Learn)
エージェント一覧を確認する基本形は、次のようにAgentsInfoを使います。
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where LifecycleStatus != "Deleted"このクエリでは、同じエージェントの複数スナップショットから最新状態を取り出せます。Microsoftのドキュメントでも、AgentsInfoはエージェントのID、プラットフォーム、権限、公開状態、ライフサイクル状態、所有者、接続ツール、MCPサーバー、ガードレールなどの情報を持つテーブルとして説明されています。(Microsoft Learn)
既存のBlockルールを新しいPoliciesで再定義する
最も運用事故につながりやすいのが、リアルタイム保護のBlockルールです。Microsoftは、既存のAgent 365 rulesでBlockに設定されているテナントについて、2026年7月1日にブロックが停止すると説明しています。ブロックを再開するには、7月1日から利用可能になるSettings > Security for AI > Policiesでルールを定義し直す必要があります。(Microsoft Learn)
確認すべきなのは、ルールの有無だけではありません。以下まで確認してください。
| 確認項目 | 見落としやすいポイント |
|---|---|
| 既存のBlockルール | AuditとBlockのどちらで運用しているかを一覧化する |
| 対象エージェント | Copilot Studio、Foundry、外部連携エージェントで対象が分かれていないか確認 |
| 対象ツール | メール送信、外部API、ファイル操作、MCPサーバー呼び出しなど高リスク操作を確認 |
| 例外設定 | 役員、開発者、テスト環境だけに許可している例外がないか確認 |
| 通知先 | Block時の通知がSOC、Teams、チケットシステムに届くか確認 |
| 再定義後のテスト | 実際に危険操作を模擬して、ブロックとアラートが動くか確認 |
「以前からBlockにしていたから大丈夫」と考えるのが一番危険です。7月1日以降に新しいPoliciesへ移していなければ、管理者が意図したブロックが効かない可能性があります。
アラート連携とワークフローを移行する
Microsoftの移行手順では、リアルタイム保護ルールのアラートはBehaviorInfoテーブルへ移り、脅威検出アラートはAgent 365 observability logsへ移ると説明されています。(Microsoft Learn)
これにより、次のような運用に影響が出ます。
- DefenderのアラートをMicrosoft Sentinelへ送っている
- アラートをTeamsチャネルへ通知している
- ServiceNowやJiraなどへチケットを自動起票している
- KQL結果をもとに自動封じ込めを行っている
- 監査用に月次レポートを出している
- SOCが旧テーブル名を前提に手順書を作っている
BehaviorInfoは、Defender for Cloud AppsやUEBA由来のbehavior情報を扱うAdvanced Huntingテーブルです。プレビュー扱いであり、GCCでは利用できないと説明されているため、政府系クラウドや特殊環境では自社テナントでの表示可否を必ず確認してください。(Microsoft Learn)
サードパーティクラウドエージェントはRegistry Syncへ移す
Amazon Bedrock、Google Vertex AI、Salesforce Agentforce、Databricks Genieなど、Microsoft外のAIプラットフォームでエージェントを運用している場合も注意が必要です。Microsoftの移行情報では、サードパーティクラウドエージェントはDefender for Cloud connectors経由では検出されなくなり、Agent 365 registry syncを使うよう案内されています。(Microsoft Learn)
Registry syncはプレビュー機能で、外部AI agent環境をAgent 365 agent registryへ同期し、一元的な可視化とガバナンスを行う機能です。対応プラットフォームとして、Amazon Bedrock、Google Vertex AI、Salesforce Agentforce、Databricks Genieが記載されています。(Microsoft Learn)
移行時は、単に接続を作るだけでは不十分です。次の点を確認してください。
| 項目 | 確認内容 |
|---|---|
| 認証情報 | AWSアクセスキー、Google Cloudサービスアカウント、Salesforce OAuth、Databricksサービスプリンシパルなどの保管場所 |
| 権限範囲 | 同期に必要な最小権限になっているか |
| リージョン | エージェントが配置されているリージョンを正しく指定しているか |
| 自動インポート | 取り込み対象を広げすぎて不要なエージェントまで登録しないか |
| 同期失敗時の監視 | last sync status、errors、total synced agentsを運用で見る担当者を決めているか |
| プレビュー前提 | 本番監査に使う場合、プレビュー機能の扱いを社内で確認しているか |
開発者とエージェント所有者が確認すべきこと
エージェントが観測データを出しているか確認する
Microsoft DefenderのAIエージェント検出は、Agent 365のobservability dataを前提にします。公式情報では、Copilot Studioで作成されたエージェントは既定でobservability dataをMicrosoft 365へ送信し、その他のプラットフォームで作成されたAIエージェントはAgent 365 SDKを使ってobservabilityを有効化する流れが示されています。(Microsoft Learn)
開発者は、以下を確認してください。
- エージェントがAgent 365に登録されているか
- 所有者、スポンサー、管理者が正しく設定されているか
- エージェントのツール呼び出しがログとして確認できるか
- 外部API、MCPサーバー、データソース接続が棚卸しされているか
- 本番と検証環境でエージェントIDや接続先が混在していないか
- 削除済み、未公開、停止中のエージェントが残っていないか
特に、MCPサーバーや外部APIを呼び出すエージェントは、通常のチャットボットよりリスクが高くなります。ユーザーの質問に答えるだけでなく、実際にファイルを読む、メールを送る、社内システムへ書き込むといった動作をする場合は、権限、ログ、ブロックルールをセットで確認してください。
所有者不明のエージェントを残さない
Agent 365のライセンス判断では、エージェントの所有者、スポンサー、管理者が重要になります。所有者が退職者、共有アカウント、開発用アカウントのままだと、ライセンス割り当てだけでなく、インシデント時の責任分界も曖昧になります。
実務では、次のように分類すると整理しやすくなります。
| 分類 | 例 | 対応 |
|---|---|---|
| 業務本番エージェント | 問い合わせ対応、営業支援、経費処理 | 所有部門、責任者、運用SLAを明確化 |
| 検証中エージェント | PoC、ハッカソン、技術検証 | 期限を決め、不要なら削除または無効化 |
| 個人作成エージェント | 個人の業務効率化用 | 共有範囲とデータアクセスを確認 |
| 外部連携エージェント | SaaS、Bedrock、Vertex AI、Agentforceなど | Registry Syncと認証情報管理を確認 |
| 所有者不明 | 作成者退職、部署異動、旧プロジェクト | 再割り当て、停止、削除の判断を実施 |
7月1日の移行は、ライセンスだけの話ではありません。エージェントの棚卸しを行う絶好のタイミングです。使われていないエージェント、誰も責任を持っていないエージェント、権限が過大なエージェントを整理すれば、ライセンス費用とセキュリティリスクを同時に下げられます。
予算計画で見落としやすいポイント
「エージェント数」ではなく「関係するユーザー数」で見る
Agent 365では、blueprints、agents、agent instancesは個別のライセンス単位ではありません。公式FAQでは、これらは別々にライセンスされず、1人のライセンスユーザーが複数のblueprints、agents、agent instancesを作成、管理、利用できると説明されています。(Microsoft)
そのため、予算計画では「エージェントが30個あるから30ライセンス」ではなく、次のように見積もります。
- エージェントを利用するユーザー数
- エージェントを管理するIT・開発者数
- エージェントのスポンサーや業務責任者数
- Microsoft 365 Copilot経由でエージェントを使うユーザー数
- 7月以降に展開予定の部門ユーザー数
小規模なPoCなら少数ライセンスで足りることもありますが、全社展開では利用部門を含めた設計が必要です。特に、ヘルプデスク、営業、経理、人事などの横断部門でエージェントを使う場合、対象ユーザーが想定以上に広がりやすくなります。
Work IQ APIの従量課金と混同しない
同じ時期にWork IQ APIの一般提供やCopilot Creditsによる従量課金の話も出ているため、Agent 365のライセンス移行と混同しやすくなっています。Partner Centerの6月発表では、Work IQ APIはCopilot Creditsを使う消費ベース課金であり、独立したWork IQ APIサブスクリプション、SKU、ユーザー単位ライセンスはないと説明されています。(Microsoft Learn)
つまり、予算表では少なくとも次を分けて管理してください。
| 予算項目 | 主な対象 | 見積もり軸 |
|---|---|---|
| Agent 365ライセンス | エージェントの可視化、保護、ガバナンス | 関係するユーザー数 |
| Microsoft 365 E7 | E5、Copilot、Agent 365、Entra Suiteをまとめる構成 | 対象ユーザー数 |
| Work IQ API | Microsoft 365データやコンテキストを使うカスタムエージェント | Copilot Creditsの消費量 |
| Windows 365 for Agents | エージェントの実行環境が必要な場合 | 利用時間やVM単位 |
ライセンス費用だけを見ていると、従量課金や運用監視コストが抜けます。逆に、従量課金だけを警戒していると、7月1日に必要なAgent 365ライセンス対応が漏れます。
よくある誤解と正しい判断
Microsoft 365 CopilotがあればAgent 365は不要？
不要とは言えません。公式FAQでは、Microsoft 365 Copilotはエンドユーザー向けのAI機能であり、Copilot以外のエージェントを管理、ガバナンス、保護するにはAgent 365が必要と説明されています。Copilotは「AIで何ができるか」、Agent 365は「AIに何を許可するか」を扱うものと考えると分かりやすいです。(Microsoft)
E5ユーザーなら7月1日の影響はない？
E5は重要な前提になり得ますが、Agent 365そのものがE5に含まれると判断するのは危険です。Enterprise customersの新規Agent 365購入ではMicrosoft 365 E5が前提になる一方、Microsoft 365 E7にはAgent 365が含まれると案内されています。現在の契約、購入チャネル、更新時期、対象ユーザーによって判断が変わるため、Microsoft 365管理センターの実ライセンス割り当てで確認してください。(Microsoft Learn)
7月1日にエージェントが全部止まる？
今回の公式情報で明確に説明されているのは、エージェントセキュリティ機能、可視化、調査、保護機能のライセンス要件変更です。エージェントの実行そのもの、Copilot StudioやFoundry側のビルド機能、各アプリの利用条件は別途確認が必要です。管理者は「エージェントが動くか」だけでなく、「見えるか、検知できるか、止められるか」を分けて確認してください。
Defenderの画面が残っていれば大丈夫？
画面が見えることと、必要なログ、アラート、ブロックが動いていることは別です。Microsoftの移行情報では、対象ライセンスがあるテナントではDefenderポータルのAI Agents inventoryやSecurity for AI settingsなどが残る一方、対象ライセンスがないテナントでは必要ライセンスに関する案内に置き換わると説明されています。(Microsoft Learn)
7月1日以降は、実際に以下を確認する必要があります。
- AI Agents inventoryに対象エージェントが表示されるか
AgentsInfoで最新のエージェント状態が取得できるか- リアルタイム保護のBlockが効くか
- 期待したアラートが発生するか
- SOCの通知先にアラートが届くか
- Sentinelや外部SIEMのダッシュボードが更新されるか
移行作業の進め方
7月1日までの作業は、ライセンス担当、Microsoft 365管理者、セキュリティ担当、開発者を分けずに進めると漏れます。短期間で対応するなら、次の順序が現実的です。
| 期限 | 作業 | 完了条件 |
|---|---|---|
| 6月中 | Agent 365対象ライセンスと前提ライセンスを確認 | 対象ユーザー候補と不足ライセンスが分かっている |
| 6月中 | Copilot Studio、Foundry、外部エージェントを棚卸し | 所有者、利用者、プラットフォーム、重要度が一覧化されている |
| 6月中 | Advanced Huntingクエリを移行 | AIAgentsInfo依存の外部クエリがAgentsInfo対応済み |
| 6月中 | Blockルールを棚卸し | 7月1日に再定義すべきルールが一覧化されている |
| 7月1日 | Security for AI AgentsとPoliciesを確認 | トグル、接続、Blockルール、アラートが動作確認済み |
| 7月以降 | アラート、レポート、監査証跡を検証 | SOC、監査、管理部門が新しい表示・ログで運用できる |
| 7月以降 | 不要エージェントを整理 | 所有者不明、未使用、過大権限のエージェントが削減されている |
この移行で最も重要なのは、ライセンスを買うかどうかだけで判断しないことです。Microsoft Agent 365は、エージェントの台帳、可視化、保護、ガバナンスをまとめる役割を持つため、設定や運用が追いついていなければライセンスを割り当てても効果が出ません。
まずは、Microsoft 365管理センターとDefenderポータルでエージェントの一覧を出し、誰が使い、誰が管理し、どの検出・ブロック・監査に依存しているかを確認してください。そのうえで、必要ユーザーへのAgent 365ライセンス割り当て、AgentsInfoへのKQL移行、Security for AI Agents設定、Blockルール再定義、Registry Sync移行を順番に進めるのが、7月1日のライセンス移行で失敗しない進め方です。
コメント