Microsoft 365 管理センターのエージェント設定（Agent settings in Microsoft 365 admin center）は、AIエージェントを「使えるようにする」ためだけの画面ではありません。社内で増える Copilot エージェントやカスタム エージェントを、誰が使えるか、どの種類を許可するか、どの範囲で共有できるか、所有者不在のエージェントをどう扱うかまで管理するためのガバナンス機能です。
2026年5月15日時点の公式情報を前提にすると、管理者が最初に確認すべきポイントは User access、Allowed agent types、Sharing、Agent management rules、Agent templates の5つです。特に、User access の既定値が「すべてのユーザー」である点、外部発行元のエージェントではデータ処理条件の確認が必要な点、共有制御の対象が Microsoft 365 Copilot Agent Builder で作成されたエージェントに限定される点は、展開前に必ず押さえておきたいところです。(Microsoft Learn)
Agent settings in Microsoft 365 admin centerとは
Agent settings in Microsoft 365 admin center は、Microsoft 365 管理センター内で AI エージェントを一元管理するための設定ページです。Microsoft Learn の説明では、組織全体の AI エージェントに対して、セキュリティ、コンプライアンス、ガバナンス標準を適用しながら、業務利用の柔軟性を保つための機能とされています。(Microsoft Learn)
従来のアプリ管理では「アプリを許可するか」「ユーザーに割り当てるか」が中心でした。しかし AI エージェントでは、エージェントが業務データを参照したり、ユーザーの代わりに処理を進めたり、他のサービスと連携したりする可能性があります。そのため、単なるオン・オフではなく、次のような観点で管理する必要があります。
| 設定項目 | 管理できること | 実務上の意味 |
|---|---|---|
| Agent management rules | エージェントに対する一括アクション | 大量のエージェントを個別確認せず、ルールで管理しやすくする |
| Allowed agent types | 利用できるエージェントの種類 | Microsoft製、社内作成、外部発行元のどれを許可するか決める |
| Agent templates | 定義済みのセキュリティポリシー適用 | 新しいエージェントの設定品質をそろえる |
| Sharing | エージェント共有の許可範囲 | 社内で誰が広く共有できるかを制御する |
| User access | エージェントへのアクセス対象 | 全社展開、停止、特定ユーザー・グループ限定を切り替える |
重要なのは、これらの設定を別々に見るのではなく、社内のAIエージェント運用ルールとして組み合わせて設計することです。たとえば「外部発行元のエージェントは原則不可」「社内作成エージェントは開発部門と業務オーナーの承認後に限定公開」「全社利用する Microsoft エージェントはテンプレートを適用して展開」といった形です。
Microsoft 365のAI/Copilot更新で何が変わるのか
今回のポイントは、Microsoft 365 管理センターが AI エージェントの運用管理により深く関わるようになったことです。Microsoft Agent 365 は、組織内で増えるエージェントを監視、管理、保護するための機能として位置付けられており、2026年5月1日時点で商用セグメント向けに一般提供されています。利用には少なくとも1人の対象ライセンス付与が必要で、Entra や Purview Data Loss Prevention と組み合わせることで効果を高められるとされています。(Microsoft Learn)
つまり、管理者に求められる作業は「Copilotを使わせるかどうか」から、「AIエージェントが増えても統制できる状態を作ること」に変わってきています。
利用者にとっての変更点
利用者から見ると、エージェント カタログで見えるエージェント、インストールできるエージェント、実際に使えるエージェントが管理者設定によって変わります。
たとえば、管理者が外部発行元のエージェントを許可しない場合、その種類のエージェントはユーザーのエージェント ストアに表示されません。一方、Microsoft製エージェントは設定が無効でも表示されることがありますが、その場合はユーザーがインストールできません。(Microsoft Learn)
利用者向けには、次のような案内を準備しておくと混乱を防げます。
| 利用者の疑問 | 管理者側で用意すべき説明 |
|---|---|
| 前に見えたエージェントが表示されない | 許可された種類や対象ユーザーが変更された可能性がある |
| インストールできないエージェントがある | 管理者が許可していない、または対象グループ外の可能性がある |
| 共有したのに相手が使えない | 共有設定とユーザーアクセス設定の両方に制限がある可能性がある |
| 外部サービス連携のエージェントを使いたい | データ処理条件や社内ポリシー確認が必要になる場合がある |
管理者にとっての変更点
管理者にとって大きいのは、AIエージェントの管理が「個別対応」から「ルールとポリシーによる一括管理」に寄っていくことです。
Agent management rules では、条件に合うエージェントを特定し、実行前に影響を受けるエージェントを確認し、対象エージェントへ一括でガバナンス アクションを適用できます。現在サポートされているシナリオには、Microsoft エージェントのインストールと、Microsoft 365 Copilot Agent Builder で作成された所有者なしエージェントを前所有者のマネージャーへ再割り当てする操作があります。(Microsoft Learn)
これは、人事異動や退職が多い組織ほど重要です。エージェントの作成者が退職した後も、エージェントだけが残り続けると、問い合わせ先、改修責任、停止判断、データ管理責任が曖昧になります。所有者不在のエージェントを放置しない仕組みを作ることが、AIエージェント運用の基本になります。
開発者にとっての変更点
社内でカスタム エージェントを作る開発者は、作って終わりではなく、Microsoft 365 管理センターでの発行、表示確認、アクセス制御、所有者管理まで考える必要があります。
Microsoft Learn では、A365 CLI の a365 publish コマンドを使ってエージェントをパッケージ化し、Microsoft 365 管理センターにアップロードする流れが説明されています。発行には Microsoft 365 テナントとグローバル管理者ロールが必要で、a365 publish により manifest.json の更新、manifest.zip の作成、管理センターへのアップロード手順の出力が行われます。(Microsoft Learn)
開発部門だけで完結させず、管理者・セキュリティ担当・業務オーナーを含めた公開フローを決めておくことが重要です。
管理者が最初に確認すべき5つの設定
User access：まず「誰が使えるか」を決める
User access は、組織内のメンバーがエージェントにアクセスし、インストールする方法を制御する設定です。Microsoft 365 管理センターで、エージェント > 設定 > ユーザー アクセス から管理します。選択肢は「すべてのユーザー」「ユーザーなし」「特定のユーザー/グループ」の3つです。(Microsoft Learn)
| 選択肢 | 向いている状況 | 注意点 |
|---|---|---|
| すべてのユーザー | 全社利用が決まっている、教育とルールが整っている | 既定値のため、意図せず広く使われないか確認が必要 |
| ユーザーなし | 一時停止、導入前の検証、緊急時の遮断 | 業務影響が大きいため事前周知が必要 |
| 特定のユーザー/グループ | パイロット導入、部門別展開、高リスク機能の限定公開 | Entra ID のグループ設計が雑だと運用が複雑になる |
初期導入では、いきなり「すべてのユーザー」にするより、特定のユーザー/グループから始めるのが安全です。たとえば、情報システム部門、業務部門の代表者、セキュリティ担当を含むパイロットグループを作り、利用ログ、問い合わせ内容、誤操作、データ取り扱い上の懸念を確認してから段階的に広げます。
また、User access は既存のアプリ ポリシーやユーザー割り当ての影響も受けます。ユーザーアクセスで許可されていても、別のアプリ制御やライセンス条件によって利用できないケースがあります。問い合わせ対応では、User access だけでなく、ライセンス、アプリ ポリシー、グループ所属をセットで確認しましょう。
Allowed agent types：許可するエージェントの種類を分ける
Allowed agent types では、ユーザーがエージェント カタログから表示・インストールできるエージェントの種類を制御します。選択肢は、Microsoft によって構築されたアプリとエージェント、組織によって構築されたアプリとエージェント、外部発行元によって構築されたアプリとエージェントです。(Microsoft Learn)
実務では、次のように段階を分けて考えると判断しやすくなります。
| 導入段階 | 推奨される考え方 | 理由 |
|---|---|---|
| 検証開始 | Microsoft製と社内作成エージェントを中心に確認 | 利用範囲と責任者を把握しやすい |
| パイロット | 外部発行元は必要なものだけ個別審査 | データ処理条件やサポート責任を確認するため |
| 全社展開 | 許可基準、禁止基準、申請フローを明文化 | 部門ごとの独自判断によるリスクを避ける |
| 運用定着 | 定期棚卸しと例外レビューを実施 | 不要なエージェントや古い設定を残さないため |
特に外部発行元のエージェントは、便利そうに見えても、社内データの取り扱い、保存先、利用規約、サポート範囲、監査対応の確認が必要です。Microsoft Learn でも、Microsoft 以外のサービスで処理されるデータは Microsoft 契約の対象ではなく、発行元の条件やデータ処理・プライバシーの取り扱いを確認するよう注意喚起されています。(Microsoft Learn)
Sharing：共有範囲を「広げすぎない」設計にする
Sharing では、組織内で誰がエージェントを共有できるか、どのように共有できるかを定義します。選択肢は「すべてのユーザー」「ユーザーなし」「特定のユーザー」です。(Microsoft Learn)
ここで誤解しやすいのが、「ユーザーなし」を選べば共有が完全に止まるわけではない点です。公式情報では、組織レベルの共有は無効になりますが、ユーザーは引き続き特定の個人と直接共有できると説明されています。また、この共有制御の対象は Microsoft 365 Copilot Agent Builder で構築されたエージェントに限られます。(Microsoft Learn)
そのため、機密性の高い業務で使うエージェントについては、Sharing だけに頼らず、User access、Allowed agent types、データ損失防止、内部規程を組み合わせて管理する必要があります。
おすすめは、広範な共有を許可するユーザーを限定することです。たとえば、次のような基準を設けます。
| 共有権限を与える対象 | 判断基準 |
|---|---|
| 業務部門のエージェント管理者 | 部門内の利用目的とデータ範囲を説明できる |
| IT管理者 | アクセス制御、公開停止、問い合わせ対応を行える |
| セキュリティ担当 | 外部連携や機密情報の扱いを評価できる |
| 一般ユーザー | 原則として広範な共有は不可、必要時は申請制にする |
Agent management rules：所有者不在と一括展開に備える
Agent management rules は、AIエージェントに対して一括管理アクションを適用するための機能です。現時点での代表的な用途は、Microsoft エージェントの一括インストールと、所有者なしエージェントの再割り当てです。(Microsoft Learn)
特に確認すべきなのは、所有者なしエージェントの扱いです。Microsoft 365 Copilot Agent Builder で作成されたエージェントについて、元の作成者が退職などで有効な所有者ではなくなった場合、Microsoft Entra ID の階層に基づいて前所有者のマネージャーへ所有権を一括再割り当てできます。(Microsoft Learn)
ただし、この仕組みを有効に使うには、Entra ID 側のマネージャー情報が正しく管理されている必要があります。人事異動や兼務が多い組織では、次の点を事前に確認しましょう。
| 確認項目 | なぜ重要か |
|---|---|
| Entra ID の manager 属性 | 所有者再割り当て先の判断に使われる |
| 退職者・異動者のアカウント処理 | 所有者不在エージェントを早く検出するため |
| 業務オーナーと技術オーナーの分離 | 部門責任と保守責任を明確にするため |
| 再割り当て後の通知ルール | 新しい所有者が責任を認識するため |
Agent templates：新規エージェントの品質をそろえる
Agent templates は、新しい AI エージェントに対して定義済みのセキュリティポリシーを含むテンプレートを適用するための考え方です。公式情報では、エージェントのガバナンスとセキュリティを強化する目的で説明されています。(Microsoft Learn)
社内でエージェント作成が広がると、部門ごとに設定品質がばらつきます。ある部門では外部共有を厳しく制限しているのに、別の部門では広く共有できる状態になっている、といった状況は避けるべきです。
テンプレート設計では、少なくとも次の分類を作っておくと運用しやすくなります。
| テンプレート例 | 想定用途 | 設定の考え方 |
|---|---|---|
| 全社標準 | 一般的な社内FAQ、規程検索 | 低リスクデータ中心、利用範囲は広め |
| 部門限定 | 営業、経理、人事などの部門業務 | 部門グループ限定、共有範囲を制限 |
| 機密業務 | 契約、個人情報、財務情報を扱う業務 | 最小権限、外部連携制限、監査重視 |
| 開発・検証 | 開発中のカスタム エージェント | 少人数、期限付き、公開前レビュー必須 |
影響範囲：管理者・開発者・利用者が見るべきポイント
Agent settings の影響は、Microsoft 365 管理者だけに留まりません。エージェントを使う利用者、作る開発者、審査するセキュリティ担当、問い合わせを受けるヘルプデスクまで関係します。
| 立場 | 主な影響 | 確認すべきこと |
|---|---|---|
| Microsoft 365 管理者 | 利用者、共有、種類、所有者管理を担う | User access、Allowed agent types、Sharing の初期値 |
| セキュリティ担当 | 外部発行元、データ処理、DLP、監査を確認する | 外部サービスの規約、機密情報の扱い、ログ確認 |
| 開発者 | カスタム エージェントの公開と更新に関わる | manifest.zip、発行手順、所有者、バージョン管理 |
| 業務部門 | エージェントの利用目的と効果を説明する | どの業務で使うか、誰が責任者か、停止時の代替手段 |
| ヘルプデスク | 表示されない、使えない、共有できない問い合わせを受ける | グループ所属、ライセンス、アクセス設定、アプリ ポリシー |
この表で重要なのは、責任分担です。AIエージェントは業務に近い存在なので、情報システム部門だけで利用可否を判断すると、現場の利便性を損ねる可能性があります。一方、現場だけで判断すると、データ管理や監査対応が不十分になります。IT・セキュリティ・業務部門の共同運用を前提に設計しましょう。
カスタム エージェント展開時の実務手順
社内で作成したエージェントを Microsoft 365 管理センターに展開する場合は、開発と管理の境界を明確にする必要があります。開発者がローカルで動作確認して終わりではなく、管理センター上での表示、アクセス制御、所有者、問い合わせ窓口まで整える必要があります。
展開前のチェック
公開前に、次の項目を確認します。
| チェック項目 | 確認内容 |
|---|---|
| 利用目的 | どの業務課題を解決するエージェントか |
| データ範囲 | 個人情報、契約情報、財務情報、顧客情報を扱うか |
| 所有者 | 業務オーナーと技術オーナーが明確か |
| 利用対象 | 全社、部門、特定グループのどれか |
| 外部連携 | Microsoft 以外のサービスへデータを送るか |
| 停止基準 | 誤回答、情報漏えい懸念、コスト超過時に誰が止めるか |
| 更新手順 | バージョンアップ時の再審査が必要か |
発行とアップロードの流れ
開発者向けドキュメントでは、a365 publish によりマニフェストを更新し、manifest.zip を作成し、Microsoft 365 管理センターへのアップロード手順を出力する流れが示されています。アップロードは Microsoft 365 管理センターの エージェント > すべてのエージェント からカスタム エージェントをアップロードする形です。(Microsoft Learn)
実務上は、次の順序で進めると安全です。
| 手順 | 作業 | 担当 |
|---|---|---|
| 1 | エージェントの目的、データ範囲、所有者を申請する | 業務部門・開発者 |
| 2 | ローカル環境で動作確認する | 開発者 |
| 3 | a365 publish でパッケージを作成する | 開発者 |
| 4 | manifest.zip と設定内容をレビューする | 管理者・セキュリティ担当 |
| 5 | Microsoft 365 管理センターへアップロードする | 管理者 |
| 6 | 対象ユーザーまたはグループに限定公開する | 管理者 |
| 7 | 表示、利用、共有、ログ、問い合わせを確認する | 管理者・業務部門 |
アップロード後、エージェントが管理センターや Teams に表示されるまで5〜10分程度かかる場合があると説明されています。すぐに表示されなくても、まずは少し時間を置き、マニフェスト、権限、対象グループ、ライセンスを順番に確認しましょう。(Microsoft Learn)
エージェント インスタンス管理で見るべきこと
エージェントを有効化すると、リクエスタがインスタンスを作成できる場合があります。Microsoft 365 管理センターでは、エージェント レジストリ、エージェント詳細、インスタンス タブを通じて、インスタンスの一覧、設定、セキュリティとコンプライアンスの状態、ライセンス適用などを確認できます。(Microsoft Learn)
管理者が特に押さえるべき操作は、ブロックと削除です。
| 操作 | 使う場面 | 注意点 |
|---|---|---|
| ブロック | 不審な動作、誤設定、調査中の一時停止 | インスタンスと実行中のアクションが停止する |
| ブロック解除 | 調査後に問題がないと判断した場合 | 再開前に所有者と利用者へ周知する |
| 削除 | 不要になった、廃止された、誤って作成された場合 | 所有者通知、ライセンス削除・再割り当てが必要 |
インスタンス削除では、30日後にインスタンス アカウントとデータが完全に削除され、監査ログは保持されると説明されています。削除は取り消しにくい運用判断になるため、削除前に業務影響、データ保全、所有者通知、代替手段を確認してください。(Microsoft Learn)
外部・マルチクラウドのエージェント管理で注意すること
Microsoft Agent 365 では、Microsoft 365内だけでなく、外部のAIエージェント環境も含めた可視化・管理の方向性が示されています。Microsoft のセキュリティブログでは、エージェントがアプリ、エンドポイント、クラウドに広がり、リスク管理チームの可視性や制御の外で増える「agent sprawl」に触れています。Agent 365 は、Microsoft AIで作られたエージェントやエコシステム パートナーのエージェントを含め、監視、ガバナンス、保護を行うコントロール プレーンとして説明されています。(Microsoft)
また、Microsoft 365 エージェント レジストリのレジストリ同期はプレビュー機能として提供され、Amazon Bedrock と Google Vertex AI からの同期をサポートしています。ただし、プレビュー機能は運用環境での使用を想定しておらず、機能が制限される可能性があると明記されています。(Microsoft Learn)
この点から、外部プラットフォーム連携を検討する場合は、次のように段階を分けるのが現実的です。
| 段階 | 実施内容 | 注意点 |
|---|---|---|
| 棚卸し | どのクラウド、どの部門でエージェントが使われているか確認 | シャドーAIを前提に調査する |
| 可視化 | レジストリや管理ツールで一覧化する | プレビュー機能は本番前提にしない |
| 権限確認 | 外部環境のAPI権限、アクセスキー、サービスアカウントを確認 | 過剰権限を避ける |
| ガバナンス設計 | 停止、削除、所有者変更、監査のルールを作る | Microsoft 365側だけで完結しない場合がある |
| 本番判断 | SLA、サポート、契約、ログ保全を確認する | プレビューと一般提供の違いを明確にする |
移行・展開で失敗しやすいポイント
Agent settings の展開で失敗しやすいのは、技術設定そのものよりも、運用設計の不足です。特に次のポイントは事前に潰しておきましょう。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 既定値のまま全社に広げる | 想定外のユーザーがエージェントを利用する | 初期は特定グループでパイロットする |
| 外部発行元を無条件に許可する | データ処理条件や責任範囲が曖昧になる | 発行元の規約、プライバシー、社内ポリシーを確認する |
| 「共有なし」を完全ブロックと誤解する | 直接共有が残り、情報管理の抜け道になる | User access やグループ制御と組み合わせる |
| 所有者不在を放置する | 問い合わせ先、停止判断、改修責任が不明になる | Entra ID のマネージャー情報と所有者ルールを整備する |
| 開発者に恒久的な高権限を渡す | 権限過多や監査上の問題が起きる | 発行作業は管理者承認フローで実施する |
古い manifest.zip を使う | アップロード失敗や表示不整合が起きる | 公開直前に a365 publish を再実行する |
| ライセンスやロールを確認しない | 設定画面が見えない、ユーザーが使えない | ライセンス、管理ロール、対象グループを確認する |
| 問い合わせ窓口を決めない | 利用者が問題発生時に止められない | 業務オーナーとIT窓口を明記する |
おすすめの展開プラン
Agent settings は、全社一括で切り替えるよりも、段階的に進めるほうが安全です。特に、AIエージェントは業務データと結びつきやすいため、最初から利便性だけを優先すると、後から統制を戻すのが難しくなります。
| フェーズ | 目的 | 実施内容 |
|---|---|---|
| 現状把握 | 既存エージェントと利用希望を把握する | エージェント レジストリ、部門ヒアリング、外部利用状況の確認 |
| パイロット | 少人数で設定と問い合わせを検証する | User access を特定グループに限定する |
| 基準作成 | 許可・禁止・申請の基準を明文化する | Allowed agent types、Sharing、外部発行元審査を決める |
| テンプレート化 | 設定品質をそろえる | 業務別テンプレート、所有者ルール、停止基準を作る |
| 段階展開 | 部門単位で利用を広げる | 教育、FAQ、ヘルプデスク対応を並行する |
| 定期レビュー | 不要・危険・所有者不在を減らす | 月次または四半期で棚卸しする |
最初のパイロットでは、便利さの評価だけでなく、次の項目を必ず記録してください。
| 記録する項目 | 判断に使う場面 |
|---|---|
| よく使われたエージェント | 全社展開候補の選定 |
| 使われなかったエージェント | 不要な公開を避ける |
| 誤回答や誤操作の内容 | 利用ガイドや制限の改善 |
| 共有に関する問い合わせ | Sharing 設計の見直し |
| 外部サービス連携の要望 | 審査基準の整備 |
| データ取り扱い上の懸念 | Purview、DLP、内部規程との連携 |
よくある疑問
Agent settingsを設定すれば、すべてのアプリ権限を一括で管理できますか
いいえ。Agent settings は AIエージェントの利用、種類、共有、アクセスなどを管理する重要な設定ですが、既存のアプリ ポリシー、ユーザー割り当て、ライセンス、Entra ID のグループ設計も影響します。User access で許可していても、別のポリシーやライセンス条件で利用できない場合があります。
外部発行元のエージェントはすべて禁止すべきですか
必ずしもすべて禁止する必要はありません。ただし、外部発行元のエージェントでは、データ処理、保存、利用規約、サポート、監査対応の確認が欠かせません。特に顧客情報、個人情報、契約情報、財務情報を扱う業務では、許可前にセキュリティ担当と法務・コンプライアンス担当の確認を入れるべきです。
Microsoft製エージェントを無効にするとユーザーから見えなくなりますか
Microsoft製エージェントは、設定が無効でもユーザーに表示される場合があります。ただし、その場合ユーザーはインストールできません。利用者から「表示されるのに使えない」と問い合わせが来る可能性があるため、社内FAQに説明を入れておくとよいでしょう。(Microsoft Learn)
Sharingを「ユーザーなし」にすれば共有は完全に止まりますか
完全な共有停止と考えるのは危険です。公式情報では、組織レベルの共有は無効になりますが、ユーザーは特定の個人と直接共有できると説明されています。また、Sharing の制御対象は Microsoft 365 Copilot Agent Builder で構築されたエージェントに限られます。(Microsoft Learn)
開発者が作ったエージェントはすぐ全社公開してよいですか
推奨されません。まずは限定グループで検証し、データ範囲、応答品質、所有者、問い合わせ先、停止基準を確認してください。公開後に問題が出た場合、利用者が増えているほど停止や修正の影響が大きくなります。
まずやるべきこと
Microsoft 365 管理センターの Agent settings は、AIエージェント時代の管理者にとって重要な設定領域です。最初にやるべきことは、すべての機能を有効化することではありません。誰に、どの種類のエージェントを、どの範囲で、どの責任体制のもとで使わせるかを決めることです。
まずは次の順序で確認してください。
| 優先度 | 作業 |
|---|---|
| 高 | User access を確認し、意図せず全社利用になっていないか見る |
| 高 | Allowed agent types で外部発行元の扱いを決める |
| 高 | Sharing の対象と制限を確認する |
| 中 | 所有者なしエージェントの検出・再割り当て方針を決める |
| 中 | カスタム エージェントの公開フローを作る |
| 中 | Agent templates で業務別の標準設定を準備する |
| 低ではない | 利用者向けFAQ、問い合わせ窓口、停止基準を整備する |
AIエージェントは、導入すればすぐ効果が出る一方で、増えすぎると管理が追いつかなくなります。Agent settings を使う目的は、利用を止めることではなく、安全に広げることです。まずは小さなパイロットから始め、設定、責任者、共有ルール、外部サービス審査を整えてから、部門単位・全社単位へ展開していきましょう。
コメント