Microsoft 365 Copilot プラグインの最新情報でまず押さえるべき結論は、プラグインは「Copilot本体に単体で追加する拡張機能」ではなく、宣言型エージェントのアクションとして、MCPサーバーやREST APIを自然言語から呼び出す仕組みだという点です。ユーザーはCopilotに質問するだけで外部システムの情報取得やデータ更新を依頼できますが、管理者はエージェント単位での公開・割り当て・ブロック、開発者はマニフェスト、認証、確認プロンプト、MCP対応を正しく設計する必要があります。Microsoft Learnの「Plugins for Microsoft 365 Copilot」では、プラグインが宣言型エージェント内のアクションとしてのみサポートされ、MCPサーバーまたはREST APIを通じて照会・作成・更新・削除を実行できることが明記されています。(Microsoft Learn)
この記事では、2026年5月13日前後に更新されたMicrosoft Learnの公式情報をもとに、Microsoft 365 Copilot プラグインで何が変わるのか、利用者・管理者・開発者にどのような影響があるのか、移行や展開でどこを確認すべきかを実務目線で整理します。
Microsoft 365 CopilotのAI/Copilot更新で何が変わるのか
今回のポイントは、Microsoft 365 Copilotの拡張が「会話で答える」だけでなく、外部システムに対して実際のアクションを実行する方向に進んでいることです。
たとえば、社内の予算管理システムやチケット管理システムをMCPサーバーまたはREST APIとして公開し、宣言型エージェントにプラグインとして接続すると、ユーザーは次のような操作を自然言語で依頼できます。
| 利用シーン | ユーザーの依頼例 | プラグイン側で起きる処理 |
|---|---|---|
| 社内データの照会 | 「大阪支社の今月の予算残高を教えて」 | APIまたはMCPツールで予算データを取得 |
| チケット管理 | 「この障害チケットを対応中に変更して」 | 外部システムのチケット状態を更新 |
| 営業支援 | 「A社の直近商談を要約して」 | CRM APIから情報を取得してCopilotが要約 |
| 経費・購買 | 「この出張費をプロジェクト予算に計上して」 | 金額・説明・対象予算をAPIに送信 |
Microsoft Learnでは、プラグインを使うことで、ユーザーが宣言型エージェントに対してMCPサーバーやREST APIの情報照会だけでなく、データやオブジェクトの作成・更新・削除を依頼できると説明されています。つまり、Microsoft 365 Copilot プラグインは「回答の拡張」ではなく、業務システムをCopilotから操作するための実行レイヤーとして考えるべきです。(Microsoft Learn)
ただし重要なのは、プラグインがMicrosoft 365 Copilotに直接有効化されるわけではない点です。公式情報では、プラグインは宣言型エージェント内のアクションとしてのみサポートされるとされています。既存の「Copilotにプラグインをそのまま追加する」イメージで設計している場合は、宣言型エージェントを中心に構成を見直す必要があります。(Microsoft Learn)
変更点の要点はMCP対応・確認プロンプト・管理統制
Microsoft 365 Copilot プラグイン関連の更新で、管理者と開発者が特に確認すべき変更点は次のとおりです。
| 変更点 | 内容 | 実務上の影響 |
|---|---|---|
| MCPサーバー対応 | プラグインマニフェストスキーマ2.4でRemoteMCPServerが追加 | REST APIだけでなくMCPサーバーをCopilotのアクションとして扱える |
| 宣言型エージェント前提 | プラグインは宣言型エージェントのactionsとして利用 | 既存APIをそのまま公開するのではなく、エージェント設計が必要 |
| 確認プロンプトの整理 | 初回接続時や副作用のある操作でユーザー確認が入る | 誤更新・誤送信を防ぐ設計が必須 |
| 応答表示の拡張 | Adaptive Cardテンプレートで応答を構造化できる | 一覧、詳細、操作結果を見やすく表示できる |
| 管理者統制 | Microsoft 365管理センターでエージェントを公開・展開・ブロック可能 | 全社展開前に権限、対象ユーザー、データアクセスの確認が必要 |
| URL処理の注意 | アクション応答内のURLはクリック可能になる場合があるが、動作はランタイム制御 | 本番必須機能として「必ずリンク化される」前提にしない |
プラグインマニフェストスキーマ2.4では、MCPサーバー対応としてRemoteMCPServerがランタイム種別に追加され、MCPサーバーへの接続情報を記述するMCPサーバースペックオブジェクトが導入されています。また、static_templateで外部ファイル参照が可能になり、OpenAPI GETアクションの確認動作に関する扱いも更新されています。(Microsoft Learn)
利用者への影響：便利になる一方で「確認」と「権限」が増える
利用者から見ると、Microsoft 365 Copilot プラグインは「社内システムを横断して操作できる窓口」になります。たとえば、TeamsやMicrosoft 365 Copilot内で、CRM、在庫管理、申請ワークフロー、チケット管理の操作を自然言語で依頼できるようになります。
一方で、すべての操作が無条件に実行されるわけではありません。Microsoft 365 CopilotがMCPまたはAPIプラグインを初めて使用する場合、ユーザーに接続を許可するか取り消すかの確認が表示されます。接続後、HTTP GETのようなデータ取得操作は通常追加確認なしで実行されますが、データ変更を伴う操作では送信データが表示され、ユーザーが許可または拒否を選ぶ仕組みです。(Microsoft Learn)
利用者向けに周知すべきポイントは次の3つです。
| 周知ポイント | 説明 |
|---|---|
| 確認画面は無視しない | 「許可」を押すと外部システムにデータが送られる場合がある |
| 操作対象を明確に入力する | 「この件を更新して」より「チケットINC-123を対応中に変更して」の方が誤操作を防げる |
| 使えない場合は権限を確認する | エージェントやプラグインは管理者の許可、ユーザー割り当て、外部API側の認証に依存する |
特に、経費処理、発注、承認、ステータス変更、データ削除のような操作では、Copilotの回答だけでなく「どのシステムに、どのデータを送るのか」を確認する習慣が重要です。
管理者が確認すべき設定と展開上の注意点
管理者にとって、Microsoft 365 Copilot プラグインは「便利な追加機能」ではなく、外部システムへのアクセス経路を持つエージェントとして管理する必要があります。
Microsoft 365管理センターでは、Copilot用エージェントの有効化、無効化、割り当て、ブロック、削除を管理できます。利用者は、管理者が許可し、かつ自分にインストールまたは割り当てられたエージェントだけを利用できます。(Microsoft Learn)
管理者が最初に確認する項目
| 確認項目 | 判断基準 | 放置した場合のリスク |
|---|---|---|
| 管理ロール | AI Admin、Global Admin、Global Readerなど必要最小限の権限で運用する | 過剰権限アカウントによる設定ミスや監査上の問題 |
| エージェント一覧 | 利用可能、展開済み、ブロック済みの状態を確認する | 不要なエージェントが利用され続ける |
| データアクセス | どのデータソース、API、カスタムアクションを呼び出すか確認する | 機密データの過剰共有や外部送信 |
| 対象ユーザー | 全社展開ではなく、部門・職種・検証グループ単位で割り当てる | 意図しない利用者が業務データを操作できる |
| 共有・公開設定 | 作成者が共有したエージェントを管理者承認フローに乗せる | 野良エージェントの拡散 |
| ブロック・削除 | 不要、危険、未検証のエージェントをブロックまたは削除する | 廃止済みAPIや古い権限設定の残存 |
Microsoftの管理者向けガイドでは、Copilot Control System内でエージェントポリシー、インベントリ、割り当て、展開を管理でき、エージェントのアクセス、共有、公開に関する設定が含まれると説明されています。また、最小権限のロール利用が推奨されています。(Microsoft Learn)
展開時は「全社公開」より段階展開を優先する
Microsoft 365 Copilot プラグインを含むエージェントは、まず限定ユーザーに展開し、実際のプロンプト、確認画面、APIログ、権限エラーを確認してから対象範囲を広げるのが安全です。
おすすめの展開順序は次のとおりです。
| 段階 | 実施内容 | 確認すること |
|---|---|---|
| 検証 | 管理者・開発者・業務責任者のみで試す | API呼び出し、認証、確認プロンプト、応答品質 |
| 小規模パイロット | 対象部門の数名に割り当てる | 実務プロンプトで誤操作が起きないか |
| 部門展開 | 業務フローに組み込む | 操作ログ、問い合わせ、権限不足の発生状況 |
| 全社展開 | 利用ルールとヘルプデスク対応を整えて展開 | 不要なエージェントのブロック、定期レビュー |
Microsoft 365管理センターのCopilot Control Systemでは、カスタムエージェントのアップロード、エージェントインベントリの確認、ユーザーまたはグループへの展開、権限と機能のレビューができます。展開時には「全組織」ではなく、まず特定ユーザーまたはグループに割り当てる判断が重要です。(Microsoft Learn)
開発者が確認すべきマニフェストと移行ポイント
開発者は、Microsoft 365 Copilot プラグインを単独のAPI定義としてではなく、Microsoft 365アプリパッケージ、宣言型エージェントマニフェスト、プラグインマニフェストの関係で設計する必要があります。
Microsoft Learnでは、エージェントはMicrosoft 365のアプリとして扱われ、アプリパッケージはmanifest.json、アイコン、宣言型エージェント定義、APIプラグイン定義などを含むZIPファイルとして説明されています。APIプラグイン定義は宣言型エージェント定義のactionsから参照されます。(Microsoft Learn)
基本構成は「アプリ → エージェント → アクション → プラグイン」
実装時の構造は、次のように考えると整理しやすくなります。
| 階層 | 主なファイル・設定 | 役割 |
|---|---|---|
| Microsoft 365アプリ | manifest.json | アプリ全体の名前、説明、アイコン、copilotAgentsを定義 |
| 宣言型エージェント | declarativeAgent.jsonなど | Copilotへの指示、知識、会話例、アクションを定義 |
| アクション | actions配列 | 使用するプラグインを参照 |
| プラグイン | plugin.jsonなど | MCPサーバーまたはREST APIの機能、認証、関数、応答表示を定義 |
| API/MCPサーバー | OpenAPI定義またはMCP tools/list相当 | 実際にデータ取得・更新を行う外部システム |
宣言型エージェントマニフェストのactionsは、プラグインマニフェストファイルへの参照またはインライン定義として指定できます。公式スキーマでは、actions配列は1件以上10件以下とされています。(Microsoft Learn)
{
"actions": [
{
"id": "budgetPlugin",
"file": "plugin.json"
}
]
}MCPサーバーを使う場合はRemoteMCPServerを確認する
MCPサーバーを利用する場合、プラグインマニフェストのruntimesでRemoteMCPServerを指定します。MCPサーバースペックには、MCPサーバーのURLと、ツール定義を外部ファイルまたはインラインで指定するmcp_tool_descriptionが必要です。(Microsoft Learn)
{
"runtimes": [
{
"type": "RemoteMCPServer",
"auth": {
"type": "OAuthPluginVault",
"reference_id": "your-reference-id"
},
"spec": {
"url": "https://mcp.example.com/",
"mcp_tool_description": {
"file": "mcp-tools.json"
}
}
}
]
}ここで注意したいのは、MCPサーバーのURLはMicrosoft 365 Copilotから到達できる必要があることです。ローカル開発でlocalhostにサーバーを立てているだけではCopilotから呼び出せません。公式ドキュメントでは、デバッグ時にdevtunnelなどのリバースプロキシを使い、Microsoft 365 CopilotからアクセスできるURLを用意する方法が説明されています。(Microsoft Learn)
本番環境では、開発トンネルをそのまま使うのではなく、認証、監査ログ、レート制限、障害監視を備えたHTTPSエンドポイントとしてMCPサーバーまたはAPIを公開する必要があります。
確認プロンプトは「邪魔な画面」ではなく安全設計の一部
Microsoft 365 Copilot プラグインでは、確認プロンプトの設計が非常に重要です。理由は、Copilotが自然言語から外部システムの操作を実行できるためです。
MCPプラグインでは、MCPサーバーのtools/list応答でreadOnlyHintをtrueに設定することで、特定のツールが読み取り専用であることを示せます。REST APIプラグインでは、OpenAPIドキュメントにx-openai-isConsequentialを追加し、初回接続後に特定操作で確認を求めるかを制御できます。副作用を伴う操作は、ユーザーが意図せず外部システムを変更しないようtrueにするのが原則です。(Microsoft Learn)
| 操作 | 推奨設定 | 理由 |
|---|---|---|
| データ検索・一覧取得 | 読み取り専用として明示 | 毎回確認を出すと使い勝手が悪くなる |
| チケット更新 | 確認を有効化 | 状態変更は業務記録に影響する |
| 申請作成 | 確認を有効化 | 外部システムに新しいデータが作成される |
| 削除・取消 | 確認を必須扱いにする | 取り消し不能な操作になりやすい |
| 金額・契約・購買関連 | 確認を必須扱いにする | 財務・承認フローへの影響が大きい |
確認テキストも重要です。単に「この操作を許可しますか？」ではなく、「予算Aに500ドルの経費を登録します」のように、何が起きるかをユーザーが理解できる文面にします。公式情報では、プラグインマニフェストのFunction capabilitiesオブジェクト内のConfirmationオブジェクトでbodyを設定し、確認文をカスタマイズできると説明されています。(Microsoft Learn)
応答表示とURL処理で失敗しやすいポイント
Microsoft 365 Copilot プラグインでは、外部APIやMCPサーバーから返ったデータをCopilotが会話形式で返します。さらに、Adaptive Cardテンプレートを使うことで、結果を一覧、カード、詳細表示のように構造化できます。(Microsoft Learn)
ただし、実装で失敗しやすい点があります。
| 失敗しやすいポイント | 具体例 | 対策 |
|---|---|---|
| API応答が大きすぎる | 100件の明細をそのまま返す | 必要な件数・項目に絞る |
| 関数が多すぎる | 1つのプラグインに20個以上の関数を詰め込む | 用途別に分割する |
| 説明文が曖昧 | 「データを処理します」だけ | いつ使う機能か、入力条件、戻り値を明記する |
| URLリンクに依存する | 応答内URLが常にクリック可能だと想定する | リンク化されない場合の案内文も用意する |
| 確認文が抽象的 | 「送信しますか？」だけ | 送信先、対象、操作内容を明示する |
公式ドキュメントでは、アクション応答に含まれるURLはMicrosoft 365 Copilotチャットでクリック可能なリンクとしてレンダリングされる可能性があるものの、この動作はCopilotランタイムやセキュリティ、信頼、ポリシー規則に左右され、時間とともに変わる可能性があると説明されています。本番の重要機能を「URLが必ずクリック可能になる」前提で設計しないことが大切です。(Microsoft Learn)
プラグイン数と関数数は増やしすぎない
Microsoft 365 Copilot プラグインは、作れば作るほど便利になるわけではありません。むしろ、関数やプラグインが多すぎると、Copilotが適切なアクションを選びにくくなります。
公式情報では、宣言型エージェントに最大5つのプラグインが含まれる場合は常にプロンプトに挿入され、5つを超える場合はセマンティックマッチングが使われると説明されています。また、プラグインに含められる関数数に明示的な上限はないものの、10を超える関数が含まれると応答品質が低下する可能性があります。大きな入力・出力はトークンウィンドウで切り捨てられる可能性もあります。(Microsoft Learn)
実務では、次の基準で分割すると失敗しにくくなります。
| 分割基準 | 良い例 | 悪い例 |
|---|---|---|
| 業務領域で分ける | 経費エージェント、在庫エージェント、障害対応エージェント | 全社システム操作エージェント |
| 操作権限で分ける | 照会専用エージェント、更新可能エージェント | 読み取りと削除を同じエージェントに混在 |
| リスクで分ける | 低リスクの検索、高リスクの申請・更新を分離 | すべて同じ確認ルールで処理 |
| ユーザー部門で分ける | 経理向け、営業向け、情シス向け | 全員に同じアクションを割り当て |
特に、削除、承認、金額変更、外部送信のような高リスク操作は、読み取り専用アクションと同じプラグインに詰め込まない方が、管理者レビューや利用者教育がしやすくなります。
移行時に確認すべきポイント
既存のAPIプラグイン、Teamsアプリ、Copilot向け拡張をMicrosoft 365 Copilot プラグインとして整理する場合は、次の観点で移行計画を立てます。
| 既存の状態 | 移行・確認ポイント |
|---|---|
| REST APIだけがある | OpenAPI定義、認証方式、operationId、確認プロンプトを整備する |
| MCPサーバーがある | RemoteMCPServer、MCPツール定義、Copilotから到達可能なURLを確認する |
| 旧スキーマのプラグインがある | v2.4で必要な変更点、未知のプロパティ、static_templateの扱いを確認する |
| 社内で作成者が個別共有している | 管理者承認、エージェントインベントリ、対象ユーザー割り当てに移す |
| 本番APIに直接つないでいる | 検証環境、監査ログ、ロールバック手順、レート制限を追加する |
| 多機能すぎるプラグインがある | 業務単位・権限単位で分割し、説明文と関数数を見直す |
プラグインマニフェストスキーマ2.4では、認識されないプロパティはドキュメント全体を無効にする必要があるとされています。既存マニフェストを移行する場合は、古いプロパティ、非推奨項目、誤った大文字小文字、不要な独自拡張を残さないように検証しましょう。(Microsoft Learn)
また、認証情報をマニフェストに直接埋め込まないことも重要です。ランタイム認証オブジェクトではOAuthPluginVaultやApiKeyPluginVaultとreference_idを使う仕組みがあり、シークレット値をプラグインマニフェストに保存しないための設計が示されています。(Microsoft Learn)
管理者・開発者向け展開前チェックリスト
公開前には、次のチェックリストを使うと抜け漏れを防ぎやすくなります。
| 対象 | チェック項目 |
|---|---|
| 管理者 | エージェントの作成者、発行元、対象ユーザー、ホスト製品を確認したか |
| 管理者 | 全社展開ではなく、特定ユーザーまたはグループから開始したか |
| 管理者 | 不要なエージェントをブロックまたは削除できる運用にしているか |
| 管理者 | エージェントが呼び出すデータソース、API、カスタムアクションを確認したか |
| 開発者 | プラグインが宣言型エージェントのactionsから参照されているか |
| 開発者 | MCPサーバーまたはAPIがCopilotから到達可能なHTTPSエンドポイントになっているか |
| 開発者 | 読み取り専用操作と副作用のある操作を明確に分けたか |
| 開発者 | readOnlyHint、x-openai-isConsequential、確認テキストを適切に設定したか |
| 開発者 | 応答が大きすぎず、必要な項目だけを返す設計になっているか |
| 開発者 | Adaptive CardやURL表示に依存しすぎていないか |
| 利用部門 | 誤操作時の取り消し手順、問い合わせ先、業務ルールを用意したか |
このチェックリストで特に重要なのは、「便利かどうか」より先に「誰が、どの外部システムに、どの操作を実行できるのか」を明確にすることです。Microsoft 365 Copilot プラグインは自然言語で使えるため、UI上のボタンよりも操作意図が曖昧になりやすい場面があります。だからこそ、確認プロンプト、権限、ログ、展開範囲をセットで設計する必要があります。
まず取るべき次のアクション
Microsoft 365 Copilot プラグインを導入・移行するなら、最初にやるべきことは3つです。
| 立場 | 次にやること |
|---|---|
| 管理者 | Microsoft 365管理センターでエージェント一覧、共有・公開設定、対象ユーザー割り当てを確認する |
| 開発者 | 既存APIまたはMCPサーバーを、宣言型エージェントのアクションとして設計し直す |
| 業務部門 | どの操作をCopilotに任せてよいか、読み取り・更新・削除で業務ルールを分ける |
Microsoft 365 Copilot プラグインは、うまく設計すれば社内システムの操作を大きく効率化できます。一方で、外部APIやMCPサーバーを自然言語から実行できるため、管理者のガバナンスと開発者の安全設計が欠かせません。まずは読み取り専用の小さなユースケースから始め、確認プロンプト、権限、ログ、展開範囲を検証してから、更新系・申請系のアクションへ広げるのが現実的です。
コメント