Agents for Microsoft 365 Copilotは、Microsoft 365 Copilotを「汎用AIアシスタント」から、業務ごとのAIエージェントへ拡張するための仕組みです。今回の公式情報で重要なのは、エージェントの作り方が大きく 宣言型エージェント と カスタムエンジンエージェント に整理され、管理者はMicrosoft 365管理センターでアクセス、共有、承認、展開、ブロックなどをより明確に管理する必要がある点です。
特に確認すべきなのは、「誰がエージェントを使えるか」「どの種類のエージェントを許可するか」「外部サービスやAPIに接続するエージェントをどう審査するか」です。Microsoft 365 Copilotを全社展開している組織では、利用者の利便性だけでなく、データアクセス、権限、ライセンス、運用責任者の整理まで含めて見直す必要があります。Microsoft Learnの該当情報は、ページ上では2026年5月18日最終更新として公開されています。(Microsoft Learn)
Agents for Microsoft 365 Copilotで何が変わるのか
Agents for Microsoft 365 Copilotの本質は、Copilotを業務単位に特化させることです。Microsoft 365 CopilotはCopilot Chat、Outlook、Teams、WordなどのMicrosoft 365アプリで、Microsoft Graphを通じた組織データを活用する生産性向上ツールです。そこにエージェントを追加すると、特定の部門、業務プロセス、外部データ、API操作に合わせたAIアシスタントを構成できます。(Microsoft Learn)
たとえば、標準のCopilotでは「会議内容を要約して」と依頼できます。一方、エージェントを使えば「営業案件の進捗をCRMから確認し、関連するTeams会話と過去提案書を踏まえて次回アクションを整理する」といった、業務フローに近い処理を設計できます。
今回の更新で押さえるべきポイントは次の3つです。
| 観点 | 変更・整理されたポイント | 実務上の意味 |
|---|---|---|
| エージェントの種類 | 宣言型エージェントとカスタムエンジンエージェントの使い分けが明確化 | まず低リスクな宣言型で始めるか、独自モデル・高度なワークフローまで作るかを判断しやすくなる |
| 管理方法 | Microsoft 365管理センター、Copilot Control System、Agent Registryでの管理が重要に | 利用者が勝手に広げる前に、承認・公開・ブロック・所有者管理を設計する必要がある |
| 開発・展開 | Agent Builder、Copilot Studio、Microsoft 365 Agents Toolkitなど複数の作成手段を前提に整理 | 作成ツールごとに管理場所、承認フロー、配布方法、権限確認が変わる |
つまり、Agents for Microsoft 365 Copilotは単なる新機能ではなく、Copilot活用を「個人利用」から「組織管理されたAI業務基盤」へ広げるための要素と考えるべきです。
エージェントは何をするものか
Microsoftの公式説明では、エージェントは特定領域に合わせたAIアシスタントとして、組織の知識や自動化を使い、情報取得、要約、メール送信、レコード更新などを実行できるものとされています。(Microsoft Learn)
エージェントの構成要素は、大きく次の2つです。
| 構成要素 | 内容 | 例 |
|---|---|---|
| Knowledge | 回答に使う知識、指示、データソース | SharePointの手順書、Teamsメッセージ、OneDrive上の資料、Copilotコネクタ経由の外部データ |
| Actions | 業務処理を実行するアクション、トリガー、ワークフロー | チケット作成、CRM更新、承認依頼、メール送信、外部API呼び出し |
ここで注意したいのは、エージェントは「便利なチャットボット」では終わらないという点です。外部APIや業務システムと接続すれば、実際にデータを更新したり、処理を開始したりできます。そのため、展開前には「回答だけを許可するのか」「操作も許可するのか」を明確に分けて設計する必要があります。
宣言型エージェントとカスタムエンジンエージェントの違い
Agents for Microsoft 365 Copilotで最初に判断すべきなのは、どちらの方式で作るかです。公式情報では、Copilotのオーケストレーターやモデルを使う 宣言型エージェント と、独自のオーケストレーションやモデルを持ち込む カスタムエンジンエージェント の2つが説明されています。(Microsoft Learn)
| 比較項目 | 宣言型エージェント | カスタムエンジンエージェント |
|---|---|---|
| 向いている用途 | Microsoft 365内の業務に特化した比較的シンプルな支援 | 複雑な業務ロジック、複数システム連携、独自モデル利用 |
| 利用する基盤 | Copilotのオーケストレーター、基盤モデル、AIインフラ | 独自のオーケストレーション、モデル、ホスティングを組み合わせ可能 |
| ホスティング | 追加ホスティング不要 | Azureなど外部ホスティングが必要になる場合がある |
| 開発手段 | Agent Builder、Copilot Studio、Visual Studio Code、Microsoft 365 Agents Toolkitなど | Copilot Studio、Visual Studio、Visual Studio Code、Agents Toolkit、.NET、Python、JavaScript、Semantic Kernel、LangChainなど |
| 対応チャネル | Microsoft 365 Copilot、Teams、Word、Excel、Outlookなど | Microsoft 365アプリに加え、外部Webサイトや社内ポータルなどにも展開可能 |
| 自律的・能動的な処理 | 基本的にユーザー起点 | ユーザー操作なしのトリガーやプロアクティブな動作を設計可能 |
| セキュリティ・コンプライアンス | Microsoft 365のセキュリティ、コンプライアンス、Responsible AI要件を継承 | 独自にセキュリティ、コンプライアンス、Responsible AI対応を確保する必要がある |
実務では、まず宣言型エージェントから検討するのが現実的です。Microsoft 365内のデータを使い、TeamsやSharePoint、Outlookで利用する業務支援であれば、開発・管理・展開の負担を抑えられます。
一方、次のような要件がある場合は、カスタムエンジンエージェントを検討します。
- 複数の外部システムをまたいだ複雑な承認フローがある
- 独自の業界特化モデルやマルチモーダルモデルを使いたい
- Teams会議やチャネルで複数ユーザーが同じエージェントを使う
- Microsoft 365外の社内ポータルや顧客向けWebサイトでも使いたい
- ユーザーが依頼しなくても、条件に応じて処理を開始したい
たとえば、社内FAQや文書検索の補助なら宣言型エージェントで十分な場合が多いでしょう。与信審査、在庫引当、インシデント対応の自動エスカレーションのように、明確な業務ルールと複数システム連携が必要な場合は、カスタムエンジンエージェントの方が適しています。
利用者への影響：Copilotが業務別に使いやすくなる
利用者にとっての最大の変化は、Copilotを業務ごとに呼び出せるようになることです。Microsoft 365 Copilot内のAgent Storeからエージェントを見つけたり、管理者が展開したエージェントをTeams、Outlook、Word、Excelなどで利用したりできます。Microsoft 365管理センターでは、組織が許可したエージェントのみを利用者がアクセスできるように管理できます。(Microsoft Learn)
利用者側で起こりやすい変化は次の通りです。
| 利用シーン | これまで | エージェント利用後 |
|---|---|---|
| 社内ナレッジ検索 | SharePointやTeamsを個別に検索 | 部門専用エージェントに質問し、関連資料を前提に回答 |
| 文書作成 | Copilotに都度、背景や条件を説明 | 用途別エージェントが書式、トーン、参照先を踏まえて支援 |
| 問い合わせ対応 | 担当者が手順書とチケットを確認 | ヘルプデスク用エージェントが手順確認や起票を支援 |
| 営業支援 | CRM、メール、会議メモを別々に確認 | 営業用エージェントが案件状況と次のアクションを整理 |
ただし、利用者が期待しすぎると失敗します。エージェントは万能ではありません。アクセス権のないデータは参照できず、管理者が許可していないアクションは実行できません。また、利用者のライセンスやエージェントに設定された機能によって、利用可否や動作が変わる場合があります。Agent Builderで共有されたエージェントについても、利用者が必要なMicrosoft 365 Copilotライセンスを持たない場合、エラーになる可能性があると説明されています。(Microsoft Learn)
管理者がまず確認すべき設定
管理者は、Agents for Microsoft 365 Copilotを「使えるようにする」だけでなく、「安全に広げる」ことを優先すべきです。公式情報では、Microsoft 365管理センターでエージェントの有効化、無効化、割り当て、ブロック、削除などを管理できるとされています。また、この機能はMicrosoft 365 Copilotライセンスのあるテナントでは既定で有効です。(Microsoft Learn)
ユーザーアクセスを確認する
Microsoft 365管理センターのAgent settingsでは、組織内で誰がエージェントにアクセスし、インストールできるかを制御できます。設定は「すべてのユーザー」「ユーザーなし」「特定のユーザーまたはグループ」から選択できます。(Microsoft Learn)
本番環境では、最初から全社開放するよりも、次のように段階的に展開するのが安全です。
| フェーズ | 推奨設定 | 目的 |
|---|---|---|
| 検証 | 特定のユーザーまたはグループ | IT部門、セキュリティ部門、業務部門代表で動作確認 |
| パイロット | 部門単位のグループ | 実業務での有効性、誤回答、権限問題を確認 |
| 本番展開 | 全社または対象部門 | 利用ルールとサポート体制を整えたうえで展開 |
失敗しやすいのは、ライセンスやアクセス権を確認せずに全社展開するケースです。利用者によって見えるデータが異なるため、「同じ質問なのに回答が違う」といった問い合わせが発生します。これはAIの不具合ではなく、Microsoft 365上の権限設計やデータ配置が影響している可能性があります。
許可するエージェント種別を整理する
Agent settingsでは、ユーザーがエージェントカタログから表示・インストールできるエージェント種別も管理できます。公式情報では、Microsoftが作成したエージェント、組織内で作成したエージェント、外部パブリッシャーが作成したエージェントを許可対象として選択できるとされています。(Microsoft Learn)
判断基準は次の通りです。
| 種別 | 許可判断のポイント |
|---|---|
| Microsoft製エージェント | 既定で利用しやすいが、業務上不要なものは表示・展開方針を確認する |
| 組織内作成エージェント | 業務適合性は高いが、作成者、データソース、アクション権限の審査が必要 |
| 外部パブリッシャー製エージェント | 利便性が高い一方、データ処理条件、契約、プライバシー確認が必須 |
特に外部パブリッシャー製エージェントは慎重に扱うべきです。公式情報でも、Microsoft以外のサービスで処理されるデータはMicrosoftの契約対象ではないため、パブリッシャーの条件やデータ処理、プライバシー実務を確認する必要があるとされています。(Microsoft Learn)
共有設定を確認する
エージェントは作成者が他のユーザーに共有できます。Agent Builderで作成されたエージェントについては、管理者が組織レベルで共有できるユーザーを制御できます。設定は、すべてのユーザー、特定のユーザーまたはグループ、共有不可のいずれかです。(Microsoft Learn)
ここで重要なのは、共有設定の変更が既存共有に必ずしも自動適用されるわけではない点です。公式情報では、管理者コントロールの変更は新しい共有操作に適用され、既存の共有済みエージェントは手動で更新しない限りアクセス可能なままと説明されています。(Microsoft Learn)
そのため、共有ポリシーを変更する場合は、既存の共有済みエージェントを棚卸しする必要があります。設定変更だけで安心せず、「すでに誰に共有されているか」まで確認してください。
Agent Registryと承認フローで見るべきポイント
Microsoft 365管理センターでは、Agent Registryを通じてエージェントを管理できます。利用者や開発者が組織向けにエージェントを公開しようとした場合、管理者はRequestsで申請内容を確認し、公開または却下できます。管理者は説明、所有者、データ、ツール、機能、データソース、カスタムアクションなどを確認したうえで判断できます。(Microsoft Learn)
承認時に確認すべき項目は次の通りです。
| 確認項目 | 見るべき内容 | 危険な例 |
|---|---|---|
| 所有者 | 退職・異動時に引き継げる担当者か | 個人任せで部門責任者が不明 |
| データソース | SharePoint、OneDrive、Teams、外部データの範囲 | 全社共有サイトを安易に参照 |
| アクション | メール送信、チケット作成、CRM更新などの実行内容 | ユーザー確認なしに外部APIへ更新 |
| 権限 | 要求されるMicrosoft Graph権限や管理者同意 | 業務に不要な広範囲権限 |
| 対象ユーザー | 全社、部門、テストグループのどれか | 検証なしで全社公開 |
| ポリシーテンプレート | セキュリティ・保護ポリシーの適用状況 | 既定値のまま高リスク業務に展開 |
承認フローでは、公開対象ユーザーの選択、必要に応じたプリインストール対象の選択、ポリシーテンプレートの適用、権限確認、管理者同意が行われます。既存エージェントの更新申請では、管理者が承認するまで以前のバージョンが利用可能なままとされています。(Microsoft Learn)
これは移行時にも重要です。業務部門が新バージョンを公開したつもりでも、管理者承認が完了していなければ利用者には旧版が残ります。リリース日を決める場合は、開発完了日ではなく、管理者承認と展開完了まで含めた日程を組むべきです。
開発者が確認すべき設計・移行の注意点
開発者は、エージェントを作る前に「どの作成方法を使うか」を決める必要があります。Agents for Microsoft 365 Copilotでは、Agent Builder、Microsoft Copilot Studio、Microsoft 365 Agents Toolkit、SharePointベースのエージェント、Copilot connectorsなど、複数の作成・連携方法があります。管理場所や承認方法も作成方法によって異なります。(Microsoft Learn)
既存チャットボットを移行する場合
既存の社内チャットボットやFAQボットをAgents for Microsoft 365 Copilotに移行する場合、単純な置き換えではなく、次の観点で再設計します。
| 観点 | 確認内容 |
|---|---|
| データソース | 既存ナレッジをSharePoint、OneDrive、コネクタ、外部APIのどこに置くか |
| 認証・権限 | ユーザー本人の権限で参照するのか、アプリ権限で処理するのか |
| アクション | 回答だけでよいか、業務システムへの登録・更新まで行うか |
| チャネル | Copilot Chat、Teams、Outlook、Word、Excel、外部Webのどこで使うか |
| 管理者承認 | Agent RegistryやRequestsで承認が必要か |
| ログ・監査 | 誰が何を実行したかを追えるか |
| 失敗時対応 | APIエラー、権限不足、誤回答時のエスカレーション先があるか |
既存ボットが外部LLMや独自APIに依存している場合は、カスタムエンジンエージェントを検討する余地があります。一方、Microsoft 365内の文書検索や定型業務支援が中心なら、宣言型エージェントに移すことで運用負荷を下げられる可能性があります。
ZIPパッケージでの展開に注意する
カスタムエージェントはZIPパッケージとしてMicrosoft 365管理センターにアップロードし、管理対象にできます。公式情報では、ZIPにはマニフェスト、構成ファイル、アイコン、ブランド要素、埋め込みナレッジファイルなどが含まれると説明されています。管理センターでは、Agents > All agents > Add agentからアップロードし、対象ユーザー、プリインストール対象、ポリシー、権限を確認して展開します。(Microsoft Learn)
展開前には、次のミスを避けてください。
| 失敗例 | 対策 |
|---|---|
| 開発用アイコンや説明文のまま公開する | エージェント名、説明、アイコン、対象業務を本番向けに確認 |
| テスト用APIエンドポイントが残っている | マニフェストと構成ファイルを本番用に差し替える |
| 全社対象で一括展開する | まず「Just me」や単一テストグループで検証 |
| 権限要求を読み飛ばす | Review permissionsで業務に必要な最小権限か確認 |
| 所有者が個人のまま | 部門または運用チームで引き継げる体制にする |
エージェントの評価とAPI管理も視野に入れる
2026年の開発者向け更新では、エージェント評価用のフレームワークやCLI、Package Management APIの更新、Agent Registration APIのプレビューなども案内されています。Agent Registration APIは、Microsoft 365環境内でエージェント登録をプログラムから作成、取得、更新、削除するためのAPIとして説明されています。(Microsoft Learn)
大規模運用では、管理画面で1件ずつ確認するだけでは追いつきません。多数の部門がエージェントを作成する組織では、将来的にAPIを使った棚卸し、所有者確認、登録情報更新、ブロック状況の確認を検討するとよいでしょう。
展開時に管理者が行うべき実務手順
Agents for Microsoft 365 Copilotの展開では、技術検証よりも運用設計が重要です。次の順番で進めると、失敗を減らせます。
| 手順 | 実施内容 | 完了の目安 |
|---|---|---|
| 現状把握 | Microsoft 365 Copilotの利用者、ライセンス、主要アプリ、データ配置を確認 | 対象部門と対象ユーザーが決まっている |
| アクセス設定 | Agents > Settings > User accessで利用対象を設定 | テストグループから開始している |
| 種別制御 | Microsoft製、組織内作成、外部パブリッシャーの許可方針を決定 | 外部エージェントの審査基準がある |
| 共有制御 | Agent Builderなどの共有可能範囲を設定 | 組織全体共有を誰に許可するか決まっている |
| 棚卸し | Agents > All agentsで既存エージェント、所有者、可用性を確認 | 所有者不明のエージェントがない |
| 申請審査 | Requestsでデータ、ツール、権限、対象ユーザーを確認 | 承認・却下の基準が文書化されている |
| パイロット展開 | 特定ユーザーまたはグループに展開 | 問い合わせ、誤回答、権限不足を記録している |
| 本番展開 | 部門または全社へ段階展開 | サポート窓口と更新ルールが決まっている |
| 継続管理 | ブロック、削除、所有者変更、更新承認を定期運用 | 月次または四半期で棚卸ししている |
この表の中で特に重要なのは、棚卸しと所有者管理です。Microsoft 365管理センターでは、エージェントのインストール、アンインストール、ブロック、削除、所有者再割り当てなどのライフサイクル操作ができます。Agent Builderで作成したエージェントの削除は元に戻せず、反映に最大24時間かかる場合があると説明されています。(Microsoft Learn)
セキュリティとデータ保護で注意すべきポイント
Agents for Microsoft 365 Copilotは、組織データを活用できる点が強みです。しかし、それは同時にリスクにもなります。特に次の3点は、展開前に必ず確認してください。
権限の過剰付与を避ける
エージェントが参照できる情報は、基本的に設定されたデータソースやユーザー権限に依存します。とはいえ、外部APIやMicrosoft Graph権限を組み合わせると、意図せず広い範囲のデータにアクセスできる設計になる可能性があります。
承認時には「便利そうだから許可する」ではなく、「この業務にこの権限が本当に必要か」で判断します。特に、メール送信、ファイルアクセス、ユーザー情報取得、外部システム更新の権限は慎重に確認してください。
外部サービスへのデータ送信を確認する
外部パブリッシャー製エージェントや外部API連携を含むエージェントでは、データがMicrosoft以外のサービスで処理される可能性があります。この場合、Microsoftの契約や商用データ保護の範囲とは別に、外部提供元の利用条件、データ保持、ログ、再学習利用、国外移転などを確認する必要があります。公式情報でも、非Microsoftサービスで処理されるデータについては、提供元の条件やプライバシー実務を確認するよう注意されています。(Microsoft Learn)
SharePointナレッジの共有範囲を誤解しない
Agent Builderで作成したエージェントを共有する場合、SharePoint上のファイルやフォルダーを知識ソースとして使うことがあります。公式情報では、エージェントはエンドユーザーの情報アクセス権や秘密度ラベルを尊重し、ユーザーがアクセスできないナレッジソースの内容は回答に含めないと説明されています。(Microsoft Learn)
ただし、エージェントを共有したからといって、SharePointサイト全体へのアクセスが自動付与されるわけではありません。逆に、エージェントの共有を解除しても、既に共有されたファイルやフォルダーの権限が自動的に消えるとは限りません。エージェントの権限とSharePointの権限は、分けて管理してください。
どの方式を選ぶべきか：実務での判断基準
Agents for Microsoft 365 Copilotの導入で迷ったら、次の基準で判断すると整理しやすくなります。
| 要件 | 推奨方式 |
|---|---|
| 社内FAQ、手順書検索、文書作成支援 | 宣言型エージェント |
| TeamsやSharePoint中心の業務支援 | 宣言型エージェント |
| 低コードで素早く試したい | Agent BuilderまたはCopilot Studio |
| 部門専用のナレッジと簡単なアクションを組み合わせたい | 宣言型エージェント |
| 複数の外部システムをまたいだ業務処理 | カスタムエンジンエージェント |
| 独自モデル、業界特化モデル、複雑な判断ロジックが必要 | カスタムエンジンエージェント |
| Microsoft 365外のWebアプリや社内ポータルでも使いたい | カスタムエンジンエージェント |
| ユーザー操作なしで条件に応じて処理したい | カスタムエンジンエージェント |
最初から高度なエージェントを作ろうとすると、設計、権限、ホスティング、監査、運用の負担が増えます。多くの組織では、まず宣言型エージェントで「特定部門の業務をどこまで改善できるか」を検証し、その後にカスタムエンジンエージェントへ広げる方が現実的です。
導入時によくある失敗と対策
Agents for Microsoft 365 Copilotは便利な一方、準備不足のまま展開すると混乱します。よくある失敗は次の通りです。
| 失敗 | 原因 | 対策 |
|---|---|---|
| 利用者がエージェントを見つけられない | 対象ユーザー、インストール、ピン留め、チャネル設定が不十分 | 展開対象と表示場所を事前に確認し、必要に応じてピン留めする |
| 同じ質問でも回答が違う | ユーザーごとの権限やデータアクセスが違う | SharePoint、Teams、OneDriveの権限を棚卸しする |
| 外部エージェントの利用が広がりすぎる | 許可するエージェント種別や共有設定が広すぎる | 外部パブリッシャー製は審査制にする |
| 更新したのに反映されない | 管理者承認待ち、または利用者側への反映待ち | RequestsのPending updateを確認する |
| 所有者不明のエージェントが増える | 作成者の異動・退職時の引き継ぎがない | 定期的にownerless agentを確認し、所有者を再割り当てする |
| 削除後に問い合わせが増える | 削除の影響範囲を周知していない | 削除前に対象ユーザー、代替手段、反映時間を通知する |
特に所有者不明のエージェントは、セキュリティ面でも運用面でもリスクです。Agent settingsでは、Agent Builderで作成された所有者不明エージェントを、Microsoft Entra IDの階層に基づいて前所有者のマネージャーへ一括再割り当てするルールも説明されています。(Microsoft Learn)
まず管理者と開発者がやるべきこと
Agents for Microsoft 365 Copilotを安全に活用するには、いきなり全社展開するのではなく、管理設定、作成方式、承認フローを先に固めることが重要です。
管理者は、Microsoft 365管理センターで次の項目を確認してください。
- Agents > Settings > User accessで、誰がエージェントを利用できるか
- 許可するエージェント種別が業務方針に合っているか
- Agent Builderの共有範囲が広すぎないか
- Agents > All agentsで、既存エージェント、所有者、可用性を棚卸しできているか
- Requestsで、公開・更新・有効化の申請を審査する体制があるか
- 外部パブリッシャーや外部API連携の審査基準があるか
開発者は、次の順番で設計してください。
- 業務要件を「回答支援」「検索支援」「アクション実行」に分ける
- 宣言型エージェントで足りるか、カスタムエンジンエージェントが必要か判断する
- データソース、アクション、権限、対象チャネルを明文化する
- テストグループで利用ログ、誤回答、権限不足を確認する
- 管理者承認、更新申請、所有者変更、削除時の運用を決める
Agents for Microsoft 365 Copilotは、Copilotを現場業務に近づける強力な仕組みです。ただし、価値を出すには「作ること」よりも「管理して広げること」が重要です。まずは影響の小さい部門業務から宣言型エージェントを試し、アクセス権、データソース、承認フロー、サポート体制を整えたうえで、より高度なカスタムエンジンエージェントへ段階的に拡張していくのが現実的な進め方です。
コメント