2026年4月16日時点で、Microsoft Entra Agent ID / Agent 365 を検討している企業が最初に押さえるべき結論は明確です。AIエージェントの一覧管理と運用の中心は Agent 365 に寄せられ、Microsoft Entra は Agent ID によるID・アクセス制御の基盤として残る、という役割分担に変わります。
この変更は、単なる管理画面の移動ではありません。エージェントの棚卸し、所有者管理、権限設計、監査、Microsoft Graph API連携の作り方に影響します。特に Identity architects や AI governance teams は、「どのエージェントが存在するか」だけでなく、「誰が責任を持ち、何にアクセスでき、いつ止められるか」まで設計する必要があります。
Microsoftは、2026年5月1日に Entra admin center 内の Agent registry と Agent collections のブレードを廃止し、Agent 365をエージェントの統合レジストリおよびコントロールプレーンにすると案内しています。一方で、Microsoft Entra Agent ID は引き続きエージェントIDの基盤として機能します。既存の registry Graph API は将来的に廃止され、Agent 365 ベースの新APIに置き換えられる予定です。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Entra Agent ID / Agent 365の変更点を一言で整理する
今回の変更を一言で言えば、「エージェントを見る場所」は Agent 365、「エージェントをIDとして制御する場所」は Microsoft Entra Agent ID という整理です。
これまでは、エージェントの可視化やレジストリ関連の情報が Microsoft Entra 側にも存在していました。しかし今後は、全社的な agent inventory は Agent 365 に集約されます。Microsoft Entra admin center は、Agent IDを持つエージェントのID管理、条件付きアクセス、IDガバナンス、セキュリティシグナルの確認に集中する位置付けです。(Microsoft Learn)
| 項目 | これからの主な場所 | 実務上の意味 |
|---|---|---|
| 全社のエージェント一覧 | Agent 365 / Microsoft 365 admin center | Microsoft製・非Microsoft製を含めた棚卸しの起点にする |
| Agent IDの管理 | Microsoft Entra Agent ID | エージェントの認証、アクセス制御、所有者、スポンサー管理を扱う |
| 条件付きアクセス・IDガバナンス | Microsoft Entra | 人間ユーザーやワークロードIDと同じ発想で制御を拡張する |
| 運用・監視・可視化 | Agent 365 | エージェントの活動、リスク、データ接続、利用状況を管理する |
| Registry Graph API | 今後変更予定 | 既存API連携は再登録・移行を前提に棚卸しする |
ポイントは、Agent 365がEntraを置き換えるわけではないことです。Agent 365はエージェント管理のコントロールプレーン、Entra Agent IDはIDとアクセス制御の基盤です。この2つを分けて理解しないと、管理責任やAPI設計を誤りやすくなります。
なぜAgent 365への集約が重要なのか
AIエージェントは、チャットボットのように質問に答えるだけの存在ではありません。社内文書を検索し、チケットを作成し、メールやTeams、SharePoint、業務アプリと連携し、ときにはユーザーの代わりに操作を実行します。
この段階になると、問題は「便利かどうか」ではなく、次のようなガバナンスになります。
- そのエージェントは誰が作成したのか
- 本番利用を許可されたエージェントなのか
- 顧客情報、財務情報、人事情報にアクセスできるのか
- 退職者や異動者が作ったエージェントは残っていないか
- 事故が起きたとき、どのID・どの操作として追跡できるか
- 外部製ツールや部門独自のエージェントを把握できているか
Microsoft Agent 365は、組織内のAIエージェントを管理・ガバナンスするためのコントロールプレーンとして位置付けられています。Microsoft 365チャネルで公開され、Entra Agent IDに登録されたエージェントはAgent 365のインベントリに表示され、Microsoft外で構築されたエージェントには追加手順が必要とされています。(Microsoft)
つまり、Identity architects と AI governance teams が最初に作るべきものは、個別エージェントの利用ルールではなく、エージェントを発見し、分類し、責任者を割り当て、権限を見直す運用モデルです。
2026年5月1日までに確認すべきこと
Microsoftの案内では、2026年5月1日に Entra admin center の Agent registry と Agent collections ブレードが廃止されます。管理者側で必須の移行作業はないとされていますが、実務上は「何もしなくてよい」と受け取るべきではありません。(TECHCOMMUNITY.MICROSOFT.COM)
特に影響を受けやすいのは、次のような組織です。
| 対象 | 確認すべきポイント |
|---|---|
| Entra admin centerでエージェント一覧を見ていた管理者 | 今後の確認場所を Microsoft 365 admin center の Agent 365 側に変更する |
| 既存のRegistry Graph APIを使っている開発チーム | API廃止と新APIへの置き換えに備えて、連携箇所を洗い出す |
| 非Microsoft製エージェントを登録している組織 | 再登録が必要になる可能性を前提に、登録情報と所有者を整理する |
| 監査・リスク管理チーム | エージェントのログ、責任者、アクセス権限、停止手順を運用台帳に反映する |
| グローバル企業 | 国・リージョン、テナント、管理ロールごとの差異を確認する |
「UIが変わるだけ」と考えると、後からAPI連携や監査証跡で詰まります。いまのうちに、エージェント管理の運用手順書やRACIをAgent 365前提に更新しておくのが安全です。
Agent inventoryは「一覧」ではなく「統制の起点」として作る
Agent inventoryは、単なるエージェント名の一覧では不十分です。AIエージェントは、人間ユーザー、アプリ、データ、外部APIをまたいで動くため、最低でも次の情報を持つ必要があります。
| 管理項目 | 記録例 | なぜ必要か |
|---|---|---|
| エージェント名 | Sales Proposal Agent | 人が識別できる名称 |
| 作成元 | Copilot Studio、Azure AI Foundry、外部ベンダーなど | 自動登録か手動登録かを判断する |
| 所有者 | 開発責任者、運用責任者 | 障害・変更・棚卸し時の連絡先 |
| スポンサー | 業務部門責任者 | 業務上の利用責任を明確にする |
| Agent ID | Entra Agent IDの有無 | 条件付きアクセスや監査に使う |
| アクセス先 | SharePoint、Exchange、CRM、社内APIなど | 権限レビューとリスク評価に使う |
| 操作種別 | 読み取りのみ、作成、更新、削除、承認など | 危険度を判定する |
| データ分類 | 公開、社内、機密、個人情報など | PurviewやDLP設計と接続する |
| 本番ステータス | 検証中、本番、停止、隔離 | シャドーエージェント対策に使う |
| 最終レビュー日 | 2026-04-16 | 棚卸し漏れを防ぐ |
Microsoft Entra Agent Registryのドキュメントでは、エージェント登録において Agent Instance と Agent Card Manifest の2つの情報が重要とされています。Agent Instanceは実行・管理に関する運用情報、Agent Card Manifestは機能やスキルなど発見・協調に関するメタデータです。(Microsoft Learn)
この考え方は、Agent 365移行後も実務上有効です。エージェントを「名前だけ」で管理するのではなく、実行実体、ID、責任者、能力、アクセス範囲を分けて記録することが重要です。
Governance設計では「人と同じ」ではなく「人より厳しく」見る
Microsoft Entra Agent IDは、AIエージェントに対してID管理、アクセス保護、ガバナンス、コンプライアンスを適用するための仕組みです。エージェントは非人間IDでありながら、人間の代わりに操作できるため、ユーザーIDよりも放置リスクが高くなります。(Microsoft Learn)
実務では、エージェントを次の4段階で分類すると判断しやすくなります。
| リスク階層 | 例 | 必要な統制 |
|---|---|---|
| 低 | 公開情報を要約するだけのエージェント | 所有者登録、利用目的の明記 |
| 中 | 社内文書を検索・要約するエージェント | Agent ID、アクセス範囲の制限、ログ確認 |
| 高 | 顧客情報や契約情報にアクセスするエージェント | スポンサー承認、条件付きアクセス、定期レビュー、DLP連携 |
| 重大 | データ更新、承認、外部送信、管理操作を行うエージェント | 人間による承認ステップ、最小権限、監査ログ保全、停止手順の明文化 |
AI governance teamsが失敗しやすいのは、エージェントを「作成者単位」で管理してしまうことです。作成者が異動・退職しても、エージェントは残り続ける可能性があります。管理単位は作成者ではなく、業務目的、データ分類、アクセス権限、責任者に置くべきです。
Identity architectsが見直すべき設計ポイント
Identity architectsは、Agent 365への集約を「管理ポータル変更」としてではなく、IDアーキテクチャの拡張として扱う必要があります。
Agent IDの所有者とスポンサーを必ず設計する
Microsoft GraphのAgent ID API概要では、agent identity、agent identity blueprint、agent identity blueprint principal が主要な構成要素として説明されています。また、所有者やスポンサーのメタデータを使って、エージェントの行動、アクセス権限、セキュリティ姿勢に対する責任を明確にする考え方が示されています。(Microsoft Learn)
実務では、次のように分けると運用しやすくなります。
| 役割 | 担当例 | 責任 |
|---|---|---|
| Owner | 開発チーム、プラットフォームチーム | 技術的な構成、変更、障害対応 |
| Sponsor | 業務部門長、プロセス責任者 | 業務上の必要性、利用継続判断 |
| Identity admin | Entra管理者 | Agent ID、条件付きアクセス、権限設計 |
| Security/GRC | セキュリティ、監査、法務 | ログ、リスク、規制対応、レビュー基準 |
重要なのは、Ownerだけで本番利用を完結させないことです。エージェントが業務データにアクセスするなら、業務上の責任者であるSponsorを置くべきです。
条件付きアクセスは「人間ユーザーの延長」では足りない
エージェントに条件付きアクセスを適用する場合、人間ユーザーと同じポリシーをコピーするだけでは不十分です。エージェントは常時稼働し、バックグラウンドでAPIを呼び出し、ユーザーの操作タイミングとは異なる動きをします。
設計時は、少なくとも次を分けて考えます。
- 対話型エージェントか、自律型エージェントか
- ユーザーの代理で動くのか、エージェント自身の権限で動くのか
- アクセス先はMicrosoft Graphか、社内APIか、SaaSか
- 高リスクデータへのアクセス時に追加制御が必要か
- リスク検知時に停止・隔離・通知のどれを行うか
Microsoft Entra Agent IDでは、エージェントに対する条件付きアクセス、リスク検知、監査ログなどの適用が説明されています。今後の設計では「ユーザー」「アプリ」「ワークロードID」に加えて、「エージェントID」をID境界として扱う必要があります。(Microsoft Learn)
Graph API変更への備え方
今回の更新で最も注意すべき点の一つが、Microsoft Graph APIです。Microsoftは、既存の registry Graph API を廃止し、Agent 365により提供される新しいAPIへ置き換える予定だとしています。また、現在のAPIで登録されたエージェントは再登録が必要になると案内されています。ただし、廃止日や新APIの詳細は今後通知される扱いです。(TECHCOMMUNITY.MICROSOFT.COM)
現時点でやるべきことは、新APIを推測して実装することではありません。まず、既存APIへの依存を可視化することです。
| 確認項目 | 実施内容 |
|---|---|
| API呼び出し箇所 | /agentRegistry、agentInstances、agentCollections、agentCardManifests への依存を洗い出す |
| 登録データ | agent instance、agent card manifest、owner、sourceAgentId、URL、権限をエクスポートする |
| 認可 | AgentInstance.ReadWrite.All などの権限を確認する |
| 実装方式 | API呼び出しをアプリ内に直書きせず、ラッパー層に分離する |
| 移行計画 | 新API公開後に、開発テナントで再登録と差分比較を行う |
| 監視 | Microsoft Learn、Microsoft Entra release notes、Message centerを確認する |
Microsoft Graph betaのAgent Registry関連APIには、/beta/agentRegistry/agentInstances などのエンドポイントがあり、Microsoft Graph beta APIは変更される可能性があり、本番アプリでの利用はサポートされないと明記されています。(Microsoft Learn)
そのため、Graph APIを使ってエージェント管理を自動化している場合は、次の設計が重要です。
アプリ本体
↓
自社のAgent Registry連携ラッパー
↓
Microsoft Graph / Agent 365 APIこの形にしておけば、新しいAgent 365 APIが公開されたときも、アプリ本体を大きく修正せずに済みます。
API移行で失敗しやすいポイント
Graph API変更に備える際、よくある失敗は次の3つです。
Microsoft側のIDを唯一の社内キーにしてしまう
外部APIのIDだけを社内マスターキーにすると、再登録時にIDが変わった場合、履歴や承認記録と結び付かなくなる可能性があります。社内側では、エージェントごとに独自の管理IDを持ち、Microsoft側のIDは属性として保持する設計が安全です。
Agent Card Manifestを軽視する
Agent Card Manifestは、エージェントの能力やスキルを説明する発見用メタデータです。これが不十分だと、どのエージェントが何をできるのか判断しにくくなります。特にAgent-to-Agent連携を見据える場合、メタデータの品質がガバナンス品質に直結します。
プレビュー制限を本番前提で設計する
Microsoft Entra Agent IDには、プレビュー段階の既知の制限があります。たとえば、Graph APIの一部関係クエリではAgent IDだけをフィルターできないため、odata.type を使ったクライアント側フィルタリングが回避策として示されています。また、エージェントのユーザーアカウントが孤立する可能性なども説明されています。(Microsoft Learn)
プレビュー機能を扱う場合は、動いた実装をそのまま標準化せず、制限事項を運用手順に明記しておくべきです。
Agent 365時代の実務チェックリスト
Agent 365への移行をきっかけに、次の順番で準備すると無理がありません。
| 優先度 | やること | 完了の判断基準 |
|---|---|---|
| 高 | 既存エージェントの棚卸し | 所有者、スポンサー、アクセス先、Agent ID有無が一覧化されている |
| 高 | 管理場所の整理 | Agent 365とEntra Agent IDの役割分担を運用手順に反映している |
| 高 | Graph API依存の確認 | 既存registry Graph APIを使うアプリ・スクリプトが一覧化されている |
| 中 | ロール設計 | AI Administrator、AI Reader、Agent ID Administratorなどの権限分離方針がある |
| 中 | リスク分類 | 読み取り、更新、外部送信、管理操作などでリスク階層を分けている |
| 中 | レビュー運用 | 四半期または半期ごとのアクセスレビュー手順がある |
| 低 | 自動化 | 新API公開後に差し替えやすいラッパー層を用意している |
Agent 365の完全なインベントリは Microsoft 365 admin center の Agents > All agents から確認する流れが示されています。一方、Entra admin centerではMicrosoft Entra Agent IDを持つエージェントのID管理に焦点が当たります。(Microsoft Learn)
グローバル企業で注意すべき点
グローバル企業では、単一テナントだけでなく、複数テナント、地域別管理、国別クラウド、委託先運用が絡みます。Agent 365 / Entra Agent IDの導入では、次を確認してください。
- 各リージョンのテナントでAgent 365が利用可能か
- Microsoft 365 admin centerへの管理権限を誰に付与するか
- 国・地域ごとのデータ分類とDLP方針に差がないか
- 海外拠点が独自に作ったエージェントを本社が把握できるか
- API利用がGlobal service以外で利用できるか
- 監査ログの保管期間と保管場所が規制要件を満たすか
Microsoft Graph betaの一部Agent Registry APIでは、利用可能なクラウドがGlobal serviceに限られ、US GovernmentやChina operated by 21Vianetでは未対応と示されているものがあります。グローバル展開では、機能の有無をテナントごとに確認することが重要です。(Microsoft Learn)
まず取るべき次のアクション
Microsoft Entra Agent ID / Agent 365の今回の変更は、AIエージェント管理を本格運用へ進めるサインです。最初にやるべきことは、新機能を試すことではありません。まず、現在のエージェントを棚卸しし、誰が責任を持ち、どのデータにアクセスし、どのAPI連携に依存しているかを明らかにすることです。
短期的には、2026年5月1日の管理画面変更に備えて、Agent 365側のインベントリ確認手順と管理ロールを整理します。中期的には、既存registry Graph APIを使う自動化を洗い出し、新しいAgent 365 APIへ差し替えやすい構造にしておきます。長期的には、AIエージェントを「便利なツール」ではなく「統制対象の非人間ID」として扱い、IDガバナンス、条件付きアクセス、監査、データ保護を一体で設計することが重要です。
Agent governanceで失敗しない組織は、エージェントの数を増やす前に、エージェントを止める方法、見つける方法、責任者を特定する方法を決めています。Agent 365へのシフトは、その運用を始めるためのちょうどよいタイミングです。
コメント