Microsoft が、Microsoft 365 Copilot の Declarative Agents において MCP（Model Context Protocol）サポートの一般提供（GA）を発表した。これにより開発者は、外部の SaaS や基幹業務（LoB）システムを Copilot チャットに直接統合できるようになり、エンタープライズのワークフロー自動化が大きく前進する。

MCPとDeclarative Agentsの組み合わせが実現すること

MCP は、AI モデルが外部システムとやり取りするための標準プロトコルとして急速に普及している。これまで Copilot の Declarative Agents に外部機能を追加するには、REST API プラグインを手動で定義する必要があり、スキーマ記述や認証設定など、相当量のボイラープレート作業が伴っていた。

MCP 対応 GA によって、この状況が一変する。MCP サーバーが公開しているツール一覧を Agents Toolkit が自動的に読み込み、必要なプラグイン定義（ai-plugin.json）やエージェント設定（declarativeAgent.json）を自動生成してくれるようになった。開発者は「何をつなぐか」だけに集中すればよく、「どうつなぐか」のコードをほぼ書かずに済む。

VS Code Agents ToolkitでのMCPエージェント構築手順

Microsoft 365 Agents Toolkit（VS Code 拡張）を使った構築フローは次のとおりだ。

エージェントのスキャフォールド VS Code で「Create a new Declarative Agent」を選択。プロジェクト構造とマニフェストファイルが自動生成される。

MCP アクションの追加 「Add Action → Start with an MCP server」から MCP サーバーの URL（https://<your-server>/mcp）を入力するだけで、ツール一覧が自動取得され、プラグインスペックが生成される。

ツールの選択 MCP サーバーが多数のツールを公開している場合、セキュリティや用途に応じて使用するツールのサブセットを選択できる。

認証設定 現時点では SSO（シングルサインオン）と静的 OAuth 2.0 をデフォルトでサポート。Toolkit がウィザード形式でガイドしてくれるため、認証フローの実装コードを自前で書く必要はない。

生成・確認・テスト 設定完了後、Toolkit が manifest.json・ai-plugin.json・declarativeAgent.json を更新し、サイドロード用のビルドも完成する。VS Code から「Provision and Start debugging」をワンクリックすれば、Microsoft 365 Copilot アプリ上でローカルテストできる。

生成された Adaptive Card によるレスポンス表示や、ツールチェイニングの設定も可能で、より高度なエージェントへの拡張余地も用意されている。

配布・展開の選択肢

完成したエージェントは2つの方法で展開できる。

  • Copilot ストア経由: Partner Center でパッケージを申請し、審査通過後にストアで公開。
  • 組織内デプロイ: IT 管理者がテナント全体または特定グループに展開。管理インターフェースは REST API エージェントと同様で、既存の管理フローを流用できる。

日本のエンタープライズ現場への影響

この GA は、Copilot ライセンスをすでに展開している国内企業にとって特に意味が大きい。これまで「Copilot は社内データには強いが、外部サービスとの連携が弱い」という声が多かった。MCP 対応によって、たとえば以下のような連携が現実的なコストで実装できるようになる。

  • 社内の Copilot チャットから Salesforce・ServiceNow・SAP などの SaaS を直接操作
  • 基幹系の RESTful API を MCP サーバーとしてラップし、Copilot から自然言語で呼び出し
  • カスタム MCP サーバーを Azure 上に立て、社内専用エージェントとして全社展開

特に注目したいのが IT 管理者側の管理容易性だ。MCP ベースのエージェントも既存の Copilot エージェント管理と同一の UI で制御できるため、セキュリティポリシーやアクセス制御を組織の標準に沿って適用しやすい。REST API プラグインと運用コストを変えずにより強力なエージェントを展開できる点は、管理負荷を気にする日本の大手企業にとって導入ハードルを下げる要素になるだろう。

開発側としては、すでに社内・外部向けに MCP サーバーを構築している場合、そのサーバーを Copilot エージェントのバックエンドとして再利用できる。MCP 投資を Copilot の文脈でも活かせるのは、技術資産の観点から合理的な選択だ。

筆者の見解

MCP 対応の GA は、Declarative Agents の実用性を大きく引き上げる一手として評価したい。Copilot の価値は「M365 の文脈を理解している」点にあるが、それだけでは業務の全体像をカバーできない。外部システムとの接続性が整って初めて「社員が業務を完結させる場所」としての Copilot が成立する。

そういう意味で、今回の GA は Copilot が本来目指すべき方向への正しい一歩だ。標準プロトコルである MCP を採用し、ツールキットで開発体験を整えたことで「つなぎにくいから使わない」という摩擦が減る。

ただ、本当の問いはここからだと思う。MCP サーバーを「誰が」「どのように」整備するか。エンタープライズのシステムをMCPサーバーとして公開するには、SaaS ベンダー側の対応と、社内システムへのラッパー実装が必要になる。Toolkit が Copilot 側の手間を省いてくれても、MCPサーバー側のエコシステムが育たないと絵に描いた餅になりかねない。

Microsoft には、主要な SaaS パートナーとの連携を積極的に推進し、「つなぐものがすでにある」状態を早期に作ってほしい。Copilot が持つ M365 統合の強みと、MCP による外部接続性が噛み合ったとき、初めてエンタープライズでの本格活用が見えてくる。その潜在力は本物だと思っているからこそ、期待は高い。

出典: この記事は Build declarative agents for Microsoft 365 Copilot with MCP の内容をもとに、筆者の見解を加えて独自に執筆したものです。