Microsoft 365のAgent Registryは、組織内のAIエージェントを「見つける」「管理する」「監査する」ための中心的な画面です。特に2026年5月上旬の公式情報では、Microsoft 365管理センター上のAgent 365を軸に、エージェントの一覧管理、所有者不在の検出、リスク確認、ピン留め、カスタムエージェントの展開、Microsoft Graph API連携まで整理されています。管理者が最初にやるべきことは、Microsoft 365管理センターで Agents > All agents > Registry を開き、エージェントの棚卸しとリスク確認を始めることです。(Microsoft Learn)
これまで部門ごとにCopilot Studio、Agent Builder、SharePoint、Microsoft Foundryなどで作られたエージェントは、管理者から見えにくくなりがちでした。Agent Registryを使うと、Microsoft製、外部パートナー製、組織内で公開されたLOBエージェント、個人が共有したエージェントを同じ画面で把握できます。AI/Copilot活用を広げる企業ほど、利用促進だけでなく、アクセス権、データソース、所有者、リスク、廃止判断まで含めた運用設計が必要です。
Microsoft 365のAgent Registryで何が変わるのか
Agent Registryの大きな変更点は、AIエージェント管理の入口がMicrosoft 365管理センター側に集約されることです。Microsoftの公式情報では、Agent 365がエージェントの統合レジストリおよびコントロールプレーンになり、Microsoft Entraは引き続きエージェントIDや条件付きアクセス、IDガバナンスなどの基盤を担う位置付けとされています。(Microsoft Learn)
つまり、運用上は次のように考えると分かりやすいです。
| 管理したいこと | 主に使う場所 | 確認する内容 |
|---|---|---|
| 組織内の全エージェントを棚卸ししたい | Microsoft 365管理センター / Agent 365 | エージェント一覧、所有者、公開元、チャネル、リスク |
| エージェントのIDやアクセス制御を管理したい | Microsoft Entra | エージェントID、条件付きアクセス、IDガバナンス |
| エージェントの利用可否や展開を管理したい | Microsoft 365管理センター | 発行範囲、インストール範囲、ブロック、ピン留め |
| セキュリティやコンプライアンスリスクを確認したい | Microsoft 365管理センター、Defender、Purview、Entra | 高重大度リスク、保護状況、アラート、調査リンク |
従来のアプリ管理と同じ感覚で「作ったら終わり」にすると、AIエージェントは急速に増えます。人事FAQ、営業支援、社内規程検索、顧客対応補助など、部門ごとの便利なエージェントが増える一方で、所有者不在、古いナレッジ、過剰な権限、外部サービスへのデータ連携が放置されるリスクも高まります。Agent Registryは、この“エージェントの散らばり”を管理対象として見える化するための機能です。
Agent Registryで確認できるエージェントの種類
Agent Registryでは、組織で利用可能なエージェントが大きく4種類に整理されます。公式情報では、Microsoftエージェント、外部パートナー構築エージェント、組織によって発行されたカスタムエージェント、作成者が共有したエージェントが対象として説明されています。(Microsoft Learn)
| 種類 | 具体例 | 管理上の注意点 |
|---|---|---|
| Microsoftエージェント | Microsoftが提供・管理するエージェント | 既定で表示・ピン留めされるものがあるため、ユーザー影響を確認する |
| 外部パートナー構築エージェント | 外部ベンダーが公開する業務支援エージェント | データ処理条件、認証、利用規約、社内ポリシーとの整合性を確認する |
| 組織によって発行されたエージェント | 社内開発の営業支援、社内FAQ、業務申請支援 | 所有者、更新責任、利用部門、アクセス範囲を明確にする |
| 作成者が共有したエージェント | 個人や部門が作成して共有したエージェント | 退職・異動時に所有者不在になりやすく、定期棚卸しが必要 |
特に注意したいのは「作成者が共有したエージェント」です。個人が作った便利なエージェントは導入スピードが速い反面、退職や異動で管理責任が曖昧になりやすい領域です。Agent Registryでは所有者がいないエージェント数を確認でき、該当エージェントをフィルターしてブロックや削除などの対応につなげられます。(Microsoft Learn)
管理者が最初に確認すべき画面と項目
Microsoft 365管理センターでは、Agents > All agents > Registry からAgent Registryを表示できます。まずは、全エージェントを一覧で確認し、フィルターとエクスポートを使って棚卸しするのが現実的です。(Microsoft Learn)
最初の棚卸しで見るべき項目
| 確認項目 | 見る理由 | 判断の目安 |
|---|---|---|
| Publisher Type | Microsoft製、外部製、社内製、共有エージェントを分類するため | 外部製と共有エージェントは優先的に確認 |
| Channel | Copilot、Teams、Outlook、Microsoft 365 apps、SharePointなどの利用面を把握するため | 利用者が多いチャネルほど影響範囲が大きい |
| Owner | 管理責任者を確認するため | 所有者不在は放置せず、再割り当て・ブロック・削除を判断 |
| Data source | 埋め込みナレッジや微調整モデルの有無を確認するため | 機密ファイルや外部データ参照がある場合は厳格に確認 |
| Status | 利用可能、ブロック、展開状況を確認するため | 使われていないもの、古いものは整理候補 |
| Risks | 高重大度リスクの有無を確認するため | リスクありは調査・軽減策・ブロック判断を優先 |
エージェント数が多いテナントでは、最初から一つずつ詳細確認すると時間がかかります。まずはCSVエクスポートで全体像を把握し、外部パートナー製、所有者不在、リスクあり、広範囲に展開済みのエージェントから優先順位を付けると効率的です。エクスポートには名前、状態、チャネル、作成日、最終更新、発行元、所有者、説明、プラットフォーム、指示などが含まれますが、エクスポート処理が1分に達すると、その時点までのデータのみが含まれる点には注意が必要です。(Microsoft Learn)
所有者不在のエージェントは最優先で確認する
Agent Registryで特に重要なのが、所有者がいないエージェントの確認です。共有エージェントは、作成者が組織から削除されると所有者不在になる可能性があります。Microsoft 365管理センターでは、所有者不在エージェントの合計数、ワンクリックフィルター、ユーザー削除を反映する更新により、該当エージェントを見つけやすくなっています。(Microsoft Learn)
所有者不在のエージェントを見つけたら、次の基準で判断します。
| 状況 | 推奨アクション |
|---|---|
| 現在も業務で使われている | 新しい所有者を割り当て、説明・ナレッジ・権限を再確認する |
| 利用実態が不明 | 一時的にブロックし、利用部門に確認する |
| 古い情報や退職者の個人管理に依存している | 削除または再構築を検討する |
| 機密情報や外部連携を含む | セキュリティ部門と確認し、必要に応じて即時ブロックする |
所有者不在を放置すると、誰もナレッジを更新しないままユーザーが回答を信じてしまう可能性があります。AIエージェントは「動いているから安全」ではありません。問い合わせ件数が少なくても、権限やデータソースが強いエージェントはリスクが高くなります。
リスク列でセキュリティ対応の優先順位を決める
Agent Registryの「Risks」列は、Microsoft Entra、Microsoft Defender、Microsoft PurviewなどのMicrosoftセキュリティプラットフォーム全体で検出された高重大度リスクを集約して表示します。リスク数を選ぶと、エージェント詳細のSecurityタブに移動し、必要に応じてブロックなどの軽減策を検討できます。(Microsoft Learn)
ただし、リスク列の見方には注意があります。公式情報では、リスク列に表示されるのは各プラットフォームでフラグ付けされた高重大度リスクであり、ゼロだからといって低・中程度のリスクまで存在しないことを意味するわけではありません。また、Microsoft 365管理センターのリスク数は、各セキュリティポータルの表示と比べて最大1時間の遅延が発生する可能性があります。(Microsoft Learn)
実務では、次のように運用すると判断ミスを減らせます。
| 表示 | 解釈 | 管理者の対応 |
|---|---|---|
| リスクあり | 高重大度リスクが検出されている | Securityタブと各セキュリティポータルで詳細確認 |
| リスクゼロ | 現時点で高重大度リスクは表示されていない | 低・中リスク、権限、外部連携は別途確認 |
| リスク数が急に増えた | 検出条件、利用状況、データアクセスの変化が疑われる | 一時ブロックや利用範囲縮小を検討 |
| 管理センターとポータルの数が違う | 反映遅延の可能性がある | 最大1時間程度の差を考慮して再確認 |
エージェントの公開・展開・ピン留めは分けて考える
Agent Registryでは、エージェントを公開するだけでなく、ユーザーに事前インストールしたり、Microsoft 365 Copilot上でピン留めしたりできます。ここで混同しやすいのが、公開、展開、ピン留めの違いです。
| 操作 | 何が変わるか | 使う場面 |
|---|---|---|
| Published to | ユーザーがエージェントを見つけてインストールできる範囲を決める | 部門単位で利用を許可したい |
| Installed to | 指定ユーザーにエージェントを事前インストールする | 必須業務ツールとして使わせたい |
| Pin for users | CopilotなどのUI上で目立つ位置に表示する | 重要なエージェントを探しやすくしたい |
| Block | ユーザーがインストール・利用できないようにする | リスクや不備があるエージェントを止めたい |
エージェントの詳細画面では、Install、Uninstall、Block、Update in store、Pin for usersなどの操作ができます。Blockを実行すると、組織メンバーはそのエージェントをインストール・利用できなくなり、すでにインストール済みの場合も削除されます。(Microsoft Learn)
ピン留めにも制約があります。管理者がピン留めできるのは、すでに一部または全ユーザーに展開されたエージェントのみです。ブロックされているエージェントは、ピン留め前にブロック解除が必要です。また、管理者によるピン留め後、エンドユーザー側に表示されるまで最大6時間かかる場合があります。(Microsoft Learn)
ピン留め運用で失敗しやすいポイント
管理者ピン留めは便利ですが、使いすぎると逆にユーザー体験を悪化させます。公式情報では、管理者はMicrosoft 365管理センターで最大3つのエージェントをピン留めでき、優先順位を上下に並べ替えられます。(Microsoft Learn)
ピン留め対象は、次のように絞るのがおすすめです。
| ピン留めに向いているエージェント | 理由 |
|---|---|
| 全社FAQ、ITヘルプ、セキュリティ問い合わせ | 多くのユーザーが共通して使う |
| 人事・経費・申請などの定型業務支援 | 問い合わせ削減や手続き短縮に直結する |
| 部門別の営業支援、製品ナレッジ | 特定グループに限定すれば業務効果が高い |
逆に、検証中のエージェント、利用対象が曖昧なエージェント、所有者や更新頻度が決まっていないエージェントは、ピン留めしない方が安全です。
管理者が確認すべきAgent settings
Agent Registryだけでなく、Agents > Settings も重要です。Agent settingsでは、エージェント管理ルール、許可するエージェントタイプ、セキュリティテンプレート、共有、ユーザーアクセスなどを設定できます。(Microsoft Learn)
| 設定 | 何を制御するか | 実務での使い方 |
|---|---|---|
| Agent management rules | エージェントへの一括管理アクション | 所有者不在エージェントの再割り当てなどを効率化 |
| Allowed agent types | ユーザーが表示・インストールできるエージェント種別 | 外部発行元を制限し、社内製やMicrosoft製を優先 |
| Security templates | 新規エージェントに適用するポリシーや保護 | 部門ごとの標準ガードレールを作る |
| Sharing | 誰がエージェントを組織内共有できるか | 全員共有を避け、特定グループに限定 |
| User access | 誰がエージェントにアクセスできるか | 段階展開やパイロット検証に使う |
外部パブリッシャー製のエージェントを許可する場合は、特に慎重に判断する必要があります。公式情報でも、Microsoft以外のサービスで処理されるデータはMicrosoftの契約対象ではないため、発行元のデータ処理条件やプライバシー慣行、社内ポリシーを確認するよう注意されています。(Microsoft Learn)
カスタムエージェントを展開する前の確認事項
Agent Registryでは、カスタムエージェントをZIPパケットファイルとしてアップロードできます。ZIPにはマニフェスト、構成ファイル、アイコン、ブランド情報、埋め込みナレッジファイルなどが含まれます。エージェントZIPは、Copilot StudioまたはCopilot内のAgent Builderからダウンロードできます。(Microsoft Learn)
展開前には、次の順序で確認すると安全です。
| 手順 | 確認内容 | 注意点 |
|---|---|---|
| ZIPの検証 | マニフェスト、名前、アイコン、ホスト製品 | 表示名だけで用途が分かるようにする |
| 発行範囲の設定 | インストール可能なユーザー・グループ | 最初から全社公開しない |
| デプロイ範囲の設定 | 事前インストールする対象 | テストグループから開始する |
| ポリシー適用 | 既存テンプレート、カスタムポリシー、既定ポリシー | ポリシーや保護が有効か別途確認する |
| アクセス許可確認 | エージェントが扱うデータと操作 | 書き込み・送信・外部連携は重点確認 |
| 展開完了 | Finish deployment | 展開後にRegistryで状態を確認する |
公式情報では、テスト目的で「自分のみ」または単一のテストグループなど、少数の対象を選択できると説明されています。実務でも、全社展開前に、想定質問、誤回答、機密データ参照、不要な権限、利用ログの確認を行うべきです。(Microsoft Learn)
Data & ToolsとPermissionsは必ず確認する
エージェントの詳細画面では、Data & Toolsタブから、そのエージェントが何を読めるのか、どのナレッジソースを使うのか、どのツールやアクションを実行できるのかを確認できます。たとえば、組織ファイル、メール、予定表、SharePointサイト、Graph connectors、MCPサーバー、カスタムアクションなどが確認対象になります。(Microsoft Learn)
特に重要なのは、「何を読めるか」よりも「何ができるか」です。社内規程を読むだけのFAQエージェントと、メール送信や外部API更新ができるエージェントでは、リスクがまったく違います。Tools欄に外部サービス連携や書き込み系アクションがある場合は、利用部門だけでなく、セキュリティ・法務・データ管理担当を交えて確認した方が安全です。
また、Data & Toolsタブは読み取り専用で、表示されるメタデータはエージェントプラットフォームから報告される内容です。データソースやツール自体を変更するには、Copilot StudioやFoundryなどの作成元プラットフォーム側で設定を更新する必要があります。(Microsoft Learn)
開発者が注意すべきAPIと移行ポイント
開発者や運用自動化担当者は、Microsoft Graph APIの変更にも注意が必要です。Microsoftの公式情報では、2026年5月以降、Microsoft GraphのAgent Registry APIsは、Microsoft Agent 365ベースのAgent Registry APIsに置き換えられる予定と説明されています。既存のAPI連携を使っている場合は、新しいAgent 365ベースのAPIへの移行計画を立てる必要があります。(Microsoft Learn)
新しいPackage Management APIでは、Microsoft 365全体のアプリとエージェントの一覧取得、詳細メタデータ取得、ブロック、ブロック解除、所有権の再割り当てなどが可能です。ただし、Package Management APIへのアクセスにはMicrosoft Agent 365ライセンスが必要とされています。(Microsoft Learn)
API利用時の注意点は次の通りです。
| 項目 | 注意点 |
|---|---|
/beta API | 変更される可能性があり、実稼働アプリケーションでの利用はサポートされない |
| 権限 | 一覧取得ではCopilotPackages.Read.Allなど、用途に応じた最小権限を検討する |
| フィルター | supportedHosts、elementTypes、lastModifiedDateTimeなどで絞り込み可能 |
| ライセンス | Package Management APIにはMicrosoft Agent 365ライセンスが必要 |
| 移行 | 既存のAgent Registry API利用箇所を洗い出し、新APIへの切り替えを計画する |
また、Microsoft Entra側で作成したエージェントIDブループリントがAgent 365 Registryに表示されない場合は、Agent 365 Registryへの登録が必要になる場合があります。公式情報では、すべてのエージェントIDブループリントを確実に登録するために、Agent 365 Registryへの登録手順を参照するよう案内されています。(Microsoft Learn)
影響範囲：管理者、開発者、利用者で見るべき点が違う
Agent Registryの影響は、Microsoft 365管理者だけに限られません。AIエージェントを作る開発者、利用する現場部門、セキュリティ担当、ID管理者がそれぞれ関わります。
| 対象者 | 影響 | 取るべき行動 |
|---|---|---|
| Microsoft 365管理者 | 全エージェントの可視化・展開・ブロック・ピン留めを担う | Registryで棚卸しし、設定と運用ルールを整備 |
| セキュリティ担当 | リスク、データ保護、Purview/Defender/Entra連携を確認する | Risks列とSecurityタブ、各ポータルのアラートを確認 |
| ID管理者 | エージェントID、条件付きアクセス、IDガバナンスを扱う | Microsoft EntraとAgent 365の役割分担を整理 |
| 開発者 | カスタムエージェントの公開、API移行、権限設計が必要 | ZIP、マニフェスト、データソース、Graph API移行を確認 |
| 現場利用者 | CopilotやTeamsなどで利用できるエージェントが変わる | ピン留め・利用範囲・利用ルールを理解する |
| 部門責任者 | 部門エージェントの所有者・更新責任を持つ | 所有者、ナレッジ更新頻度、廃止基準を決める |
特に現場部門に対しては、「AIエージェントを自由に作れる」だけでなく、「共有したら管理対象になる」「所有者は継続的に責任を持つ」「外部サービスにデータが渡る可能性がある場合は確認が必要」と説明しておくことが大切です。
展開前に決めておきたい運用ルール
Agent Registryを有効に使うには、画面を確認するだけでなく、社内の運用ルールを決める必要があります。最低限、次の項目は文書化しておきましょう。
| ルール | 決める内容 |
|---|---|
| 命名規則 | 部門名、用途、環境、本番・検証の区別を入れる |
| 所有者 | 個人だけでなく、部門または管理グループも明確にする |
| 公開範囲 | 全社、部門、テストグループの判断基準を決める |
| データ利用 | SharePoint、OneDrive、メール、外部URL、外部APIの扱いを決める |
| レビュー周期 | 月次または四半期ごとに所有者・利用状況・リスクを確認する |
| 廃止基準 | 一定期間使われない、所有者不在、更新停止、リスク増加時の対応を決める |
| 外部エージェント | 事前審査、発行元確認、データ処理条件の確認手順を決める |
小規模な組織でも、最初から完璧なAIガバナンス規程を作る必要はありません。まずは「誰が作ったか」「誰が使うか」「何のデータに触れるか」「問題が起きたら誰が止めるか」の4点を最低限のチェック項目にすると、運用を始めやすくなります。
よくある失敗と回避策
全社展開を急ぎすぎる
便利そうなエージェントをいきなり全社公開すると、想定外の質問、誤回答、不要なデータ参照、サポート問い合わせ増加が起きやすくなります。まずはテストグループに展開し、利用ログ、回答品質、権限、ユーザーの反応を確認してから範囲を広げましょう。
所有者を個人任せにする
個人作成のエージェントはスピード感がありますが、退職・異動・休職で管理が止まりやすくなります。部門単位の責任者、代替所有者、レビュー期限を決めておくと、所有者不在リスクを減らせます。
リスクゼロを安全と誤解する
Agent RegistryのRisks列がゼロでも、高重大度リスクが表示されていないだけの場合があります。低・中リスク、外部サービス利用、過剰な権限、古いナレッジは別途確認が必要です。(Microsoft Learn)
ピン留めを告知代わりに使う
ピン留めはユーザーの目に入りやすくする機能ですが、告知や教育の代わりにはなりません。特に、どの業務で使うのか、どの情報は入力してはいけないのか、回答をどう確認するのかを説明しないと、誤用につながります。
SharePoint Embeddedコンテナーを削除する
Agent Builderでファイルをアップロードしたエージェントでは、ファイルがSharePoint Embeddedコンテナーに保存される場合があります。公式情報では、これらのコンテナーを削除すると、関連するエージェントの機能が壊れる可能性があるため削除しないよう注意されています。(Microsoft Learn)
まず実施すべきチェックリスト
Agent Registry対応を始めるなら、次の順序で進めると実務に落とし込みやすくなります。
| 優先度 | 作業 | 完了の目安 |
|---|---|---|
| 高 | Agents > All agents > Registryで全エージェントを確認 | エージェント数、種類、所有者、リスクを把握できている |
| 高 | 所有者不在エージェントを抽出 | 再割り当て、ブロック、削除の判断が済んでいる |
| 高 | 外部パートナー製エージェントを確認 | 発行元、データ処理、利用範囲を確認済み |
| 高 | Risks列とSecurityタブを確認 | 高重大度リスクへの対応方針が決まっている |
| 中 | CSVエクスポートで棚卸し台帳を作成 | 定期レビューに使える一覧がある |
| 中 | Agent settingsを確認 | 許可タイプ、共有、ユーザーアクセスが社内方針と合っている |
| 中 | ピン留めエージェントを整理 | 本当に必要な最大3件に絞っている |
| 中 | カスタムエージェント展開手順を標準化 | テスト、承認、展開、レビューの流れがある |
| 低 | Graph API連携の棚卸し | 旧API利用箇所と移行計画が分かっている |
まとめ：Agent RegistryはAIエージェント時代の管理台帳になる
Microsoft 365のAgent Registryは、単なる一覧画面ではありません。組織内に増えるAIエージェントを、所有者、公開元、チャネル、データソース、権限、リスク、展開状態の観点で管理するための台帳です。
まずはMicrosoft 365管理センターでAgent Registryを開き、全エージェントの棚卸しを行いましょう。次に、所有者不在、外部パートナー製、リスクあり、全社展開済みのエージェントを優先して確認します。そのうえで、Agent settings、公開・展開・ピン留め、Data & Tools、Permissions、API移行を順番に整備すれば、CopilotやAIエージェントの活用を止めずに、安全な運用へ近づけられます。
コメント