Microsoft 365 Copilotで外部データを活用したい組織にとって、Federated Copilot connectorsのGAは重要な変更です。結論から言うと、外部システムのデータをMicrosoft 365に取り込んでインデックス化する方法だけでなく、元データを外部システムに置いたまま、Copilotが必要なタイミングでリアルタイムに参照する方法が本格的な選択肢になります。Microsoft Learnでは、Federated connectors overviewが2026年6月3日に更新され、MCPを使ったリアルタイム取得、ユーザー権限ベースのアクセス、管理センターでの統制が整理されています。(Microsoft Learn)
この記事では、Microsoft 365 CopilotのFederated Copilot connectorsで何が変わるのか、従来のSynced connectorsとの違い、管理者が確認すべき設定、開発者・パートナーが注意すべきMCPや認証のポイント、移行・展開時に失敗しやすい点を実務目線で整理します。
Microsoft 365 CopilotのAI/Copilot更新で何が変わるのか
Federated Copilot connectorsのGAで変わる最大のポイントは、Copilotに外部データを見せる方法が「取り込んで検索対象にする」だけではなくなったことです。
従来のCopilot connectorsでは、外部データをMicrosoft Graph側に同期し、Microsoft 365内で検索・Copilot回答に使えるようにする考え方が中心でした。これに対してFederated connectorsは、Model Context Protocol、つまりMCPを使い、外部データをMicrosoft 365にインデックス化せず、必要なときにリアルタイムで取得します。(Microsoft Learn)
実務上の意味は大きく、次のようなデータをCopilotに接続しやすくなります。
- 更新頻度が高く、インデックス化すると鮮度が落ちやすいデータ
- 金融、市場、営業、サポート、プロジェクト管理など、今の状態が重要なデータ
- Microsoft 365側にコピーや保存をしたくない外部サービス上のデータ
- ユーザーごとの権限で見える範囲が大きく変わるSaaSデータ
たとえば、営業担当者がCopilot Chatで「今週動きがあったHubSpot上の重要顧客を整理して」と聞く場合、Federated connectorsでは、ユーザー本人の認証と権限に基づいて外部サービスから情報を取得できます。これにより、古い同期データではなく、より現在の業務状況に近い情報をCopilotの回答に使いやすくなります。
Federated Copilot connectorsとは
Federated Copilot connectorsは、Microsoft 365 Copilotから外部データソースへリアルタイムに問い合わせるためのコネクタです。Microsoftの公式説明では、MCPを使ってデータを取得し、外部データをMicrosoft 365にインデックス化せず、管理者がMicrosoft 365管理センターで管理・統制できる仕組みとされています。(Microsoft Learn)
重要なのは、「Copilotが何でも自由に外部データを読めるようになる」という話ではないことです。Federated connectorsは、ユーザーのIDと権限を使ってアクセスし、元システム側で許可されている範囲のデータだけを取得します。また、Microsoft LearnではFederated connectorsは読み取り専用で、Microsoft Purviewで監査可能と説明されています。(Microsoft Learn)
GAで利用シーンが広がる対象
公式のリリースノートでは、Federated Copilot connectorsが一般提供され、Microsoft 365 Copilotをサポートされるサードパーティデータソースに安全に接続し、MCPでリアルタイムに情報を取得できるようになったと説明されています。対象のCopilot体験として、Microsoft 365 Chat、Researcher、ExcelのAgent Modeが挙げられています。(Microsoft Learn)
Microsoft LearnのFederated connectors overviewでは、サポートされる体験として以下が示されています。(Microsoft Learn)
| 利用場所 | 期待できる使い方 |
|---|---|
| Microsoft 365 Copilot Chat | 外部SaaSの情報を含めた質問、要約、調査 |
| Copilot in Excel / Agent Mode in Excel | 外部データを踏まえた分析や表作成の補助 |
| Researcher agent | 複数ソースを使った調査、比較、深掘り |
ただし、利用できる範囲や表示名はテナント、リリースリング、ライセンス、Microsoft側の更新により変わる可能性があります。展開前には、必ず自社テナントのMicrosoft 365管理センターで実際の表示を確認してください。
Synced connectorsとの違い
Federated connectorsを理解するには、従来型のSynced connectorsとの違いを押さえるのが近道です。
| 比較項目 | Synced connectors | Federated connectors |
|---|---|---|
| データの扱い | 外部データをMicrosoft 365側にインデックス化 | 外部データを元システムに置いたままリアルタイム取得 |
| 向いている用途 | 社内Wiki、文書管理、ナレッジベースなど横断検索したい情報 | 最新状態が重要なSaaS、動的データ、外部に置いたまま使いたい情報 |
| アクセス単位 | 組織レベルの接続が中心 | ユーザーレベルの認証・権限が中心 |
| 管理方法 | 管理者が接続、スキーマ、クロール、権限マッピングを設計 | 管理者が有効化・無効化・段階展開を制御し、ユーザーが必要に応じて認証 |
| データ鮮度 | クロール頻度に依存 | 問い合わせ時点のデータを取得しやすい |
| カスタム開発 | Microsoft Graph connectors APIなどでカスタム同期コネクタを構築可能 | MCPサーバーを使ったカスタムFederated connectorを構成 |
Synced connectorsが不要になるわけではありません。むしろ、両者は使い分けるものです。Microsoftの概要ページでも、外部データをインデックス化するSynced connectorsと、リアルタイムに接続するFederated connectorsの2種類が整理されています。(Microsoft Learn)
たとえば、社内規程、製品マニュアル、FAQ、過去の議事録のように「全文検索性」と「横断検索」が重要な情報はSynced connectorsが向いています。一方、CRMの案件状況、カレンダー、顧客対応履歴、マーケットデータのように「今の状態」が重要な情報はFederated connectorsのほうが実務に合いやすい場面があります。
組織への影響範囲
Federated Copilot connectorsのGAは、単なる新機能追加ではなく、外部データ公開のガバナンス設計に影響します。
管理者への影響
管理者は、Microsoft 365管理センターのCopilot > Connectorsから、利用可能なFederated connectorsを確認し、有効化、無効化、段階的な展開を管理できます。Microsoftのリリースノートでも、管理者がMicrosoft-published federated connectorsを管理センターから確認・レビュー・有効化・無効化・管理できることが示されています。(Microsoft Learn)
特に注意したいのは、Microsoft-published federated connectorsの扱いです。公式ドキュメントでは、Microsoft-publishedのFederated connectorsは、管理者が無効化しない限りテナントで既定で有効になると説明されています。また、管理者はMicrosoft Entra IDグループを使って段階的な展開を設定できます。(Microsoft Learn)
つまり、管理者が確認しないままにしておくと、意図しない外部サービス連携がユーザー側に見える可能性があります。セキュリティやコンプライアンス要件が厳しい組織では、まず全体の既定動作を確認し、必要に応じて無効化や限定展開を行うべきです。
利用者への影響
利用者にとっては、Copilotから外部サービスの情報を使いやすくなるのがメリットです。
たとえば、次のような使い方が想定できます。
- ResearcherでNotionやHubSpotなどの情報を含めて調査する
- Copilot Chatで外部SaaS上の顧客情報や業務データを要約する
- Excelで外部データを踏まえて分析の下書きを作る
- Google CalendarやGoogle Contactsなど、Microsoft 365外の情報を業務文脈に含める
ただし、ユーザーは必要に応じて自分の資格情報で外部データソースに認証します。管理者が有効化しただけで、すべての外部データが自動的にCopilotへ流れ込むわけではありません。公式ドキュメントでも、ユーザーはプロンプト時に接続を求められ、自分の権限でアクセスすると説明されています。(Microsoft Learn)
セキュリティ・コンプライアンス部門への影響
セキュリティ部門が見るべきポイントは、「データがMicrosoft 365に保存されるか」だけではありません。Federated connectorsではデータをMicrosoft 365にコピー・インデックス化しないと説明されていますが、Copilotの回答生成に外部データが使われる以上、監査、利用ポリシー、外部サービス側の契約条件、ユーザー教育は必要です。(Microsoft Learn)
確認すべき観点は次の通りです。
| 観点 | 確認すること |
|---|---|
| 権限 | 外部サービス側で過剰な閲覧権限が付与されていないか |
| 認証 | OAuth 2.0やMicrosoft Entra SSOの設定が適切か |
| 監査 | Microsoft Purviewや外部SaaS側の監査ログで利用状況を追えるか |
| 契約 | 外部サービスの利用規約、データ処理条件、保存場所を確認したか |
| ユーザー教育 | Copilot回答の根拠確認、機密情報の取り扱いルールを周知したか |
管理者が確認すべき設定
Federated Copilot connectorsの展開では、まず「何を有効にするか」よりも「何を不用意に有効化しないか」を決めることが重要です。
テナント全体のトグルを確認する
Microsoftは、既定のFederated connectorsを組織全体で有効化・無効化するテナントワイドのトグルを提供しています。PowerShellで一括管理でき、将来Microsoftが追加する既定コネクタにも設定が適用されます。(Microsoft Learn)
公式ドキュメントでは、Connector.Cmdモジュールのバージョン2.1以降と、Global AdministratorまたはAI Administrator権限が前提とされています。設定にはSet-FederatedConnectorToggleコマンドレットを使います。(Microsoft Learn)
実務では、次の順番で確認すると安全です。
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 1 | Microsoft 365管理センターでCopilot > Connectorsを確認 | MCP/Federated系のコネクタが表示されているか |
| 2 | テナント全体の既定動作を確認 | Microsoft-published connectorsを既定で許可する方針か |
| 3 | 必要に応じて一括無効化 | 先に止めてから、承認済みのものだけ開けるか |
| 4 | Entra IDグループで段階展開 | 情シス、セキュリティ、業務代表者で先行検証するか |
| 5 | 利用ログとユーザーのフィードバックを確認 | 業務効果とリスクを見て全社展開を判断するか |
特に、規制業種や顧客データを扱う部門では、「既定で有効」のまま全社公開するより、先にテナント全体で無効化し、必要なコネクタだけ段階的に有効化する運用が現実的です。
7日間の管理者レビュー期間を活用する
Microsoft-published federated connectorが管理センターに初めて表示された場合、ユーザーに公開される前に管理者だけが確認できる7日間のレビュー期間があります。この期間中に、管理者はコネクタを確認し、組織要件に合わなければ無効化し、段階的な展開を設定できます。(Microsoft Learn)
ここでやるべきことは、単に「有効・無効」を選ぶことではありません。次の観点でレビューしてください。
- その外部サービスを業務で正式利用しているか
- 対象ユーザーが明確か
- 外部サービス側の権限設計が最新か
- 機密情報や個人情報をCopilotで扱う可能性があるか
- 利用規程や社内ガイドラインに反しないか
- Copilotの回答に使われたとき、出典確認ができるか
7日間は短いため、Microsoft 365管理者だけで判断しようとすると遅れます。事前に、セキュリティ、法務、情報管理、業務部門の確認ルートを決めておくと展開がスムーズです。
段階的な展開を前提にする
Federated connectorsは、Microsoft Entra IDグループを使ったステージングができます。公式ドキュメントでも、管理者はStaged Rollout列のAdd stagingから特定のEntra IDグループに利用範囲を限定できると説明されています。(Microsoft Learn)
おすすめの展開順は次の通りです。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | IT管理者、セキュリティ担当 | 設定、認証、監査、表示範囲を確認 |
| 業務パイロット | 営業、財務、サポートなど一部部門 | 実務で回答品質と業務効果を確認 |
| 制限付き展開 | 対象業務の主要ユーザー | 利用ルールを整えながら利用拡大 |
| 全社または部門展開 | 承認済み部門 | サポート体制と教育を含めて展開 |
いきなり全社公開すると、「便利だが管理できないコネクタ」になりやすくなります。Copilot関連機能は利用者の期待値が高いため、先にルールと問い合わせ先を用意してから広げることが重要です。
開発者・パートナーが確認すべきMCP対応
Federated connectorsは、開発者にとっても重要な変更です。自社独自システムや業務アプリをCopilotに接続したい場合、MCPサーバーを用意し、読み取り専用のツールを公開する設計が必要になります。
Microsoft Learnでは、カスタムFederated connectorはMCPサーバーから始まり、search、fetch、queryのような読み取り専用ツールを公開することが前提として説明されています。認証にはMicrosoft Entra SSOまたはOAuth 2.0を利用できます。(Microsoft Learn)
カスタムFederated connectorで準備するもの
開発側で確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| MCPサーバー | Copilotから到達できるエンドポイントを用意する |
| 読み取り専用ツール | 検索、取得、問い合わせなど、書き込みを伴わない操作に限定する |
| 認証方式 | Microsoft Entra SSOかOAuth 2.0かを決める |
| 権限判定 | ユーザー単位で閲覧可能なデータだけを返す |
| レスポンス設計 | Copilotが根拠として扱いやすいタイトル、URL、要約、更新日時などを返す |
| エラー処理 | 権限不足、タイムアウト、外部API制限時の応答を明確にする |
| 監査 | 誰が、いつ、どのデータに問い合わせたかを追跡できるようにする |
パートナーがギャラリー掲載を目指す場合
MicrosoftのConnectors GalleryにFederated connectorを掲載したいパートナーは、リモートMCPサーバーをMicrosoftへ提出し、審査を受ける必要があります。Microsoftの提出ガイドでは、セキュリティとプライバシー、ツールメタデータ、OAuth 2.0、ドキュメント品質などが要件として示されています。また、Microsoftは検索と取得を行うツールのみを有効化し、各ツールにreadOnlyHint注釈が必要と説明しています。(Microsoft Learn)
提出時には、MCP server URL、表示名、短い説明、同義語、ロゴ、OAuth資格情報、ツール一覧、ドキュメント、テスト資格情報、サンプルプロンプトなどの準備が必要です。(Microsoft Learn)
開発者が失敗しやすいのは、MCPサーバーを作ること自体よりも、Copilotが使いやすい粒度で情報を返せていないケースです。たとえば、検索結果にタイトルやURLがない、更新日時がない、権限エラーが曖昧、1回の応答が大きすぎる、といった実装は利用者体験を悪化させます。
移行・展開時の判断基準
Federated connectorsのGA後も、すべての外部データをFederated connectorsに寄せる必要はありません。次の基準で判断すると、設計を誤りにくくなります。
| データの種類 | 推奨しやすい方式 | 理由 |
|---|---|---|
| 社内Wiki、FAQ、規程、マニュアル | Synced connectors | 検索性と横断的な発見が重要 |
| CRMの案件状況、サポートチケット、カレンダー | Federated connectors | 最新状態とユーザー権限が重要 |
| 監査上Microsoft 365へコピーしたくない外部データ | Federated connectors | データを元システムに残したまま利用できる |
| 大量文書を全文検索したいデータ | Synced connectors | インデックス化による検索体験が向いている |
| 外部APIでリアルタイム照会する業務データ | Federated connectors | API経由のライブ取得と相性がよい |
判断に迷う場合は、次の質問に答えると整理できます。
- そのデータは「最新であること」が最重要か
- Microsoft 365側にコピー・インデックス化してよいか
- ユーザーごとの外部サービス権限を厳密に反映したいか
- 全文検索したいのか、業務文脈で問い合わせたいのか
- 外部サービス側のAPI性能や利用制限に耐えられるか
たとえば、社内の就業規則PDFを検索したいならSynced connectorsが向いています。一方で、「今週の顧客接点」「最新の商談ステータス」「今日の外部カレンダー予定」をCopilotに聞きたいなら、Federated connectorsのほうが適しています。
展開前に見落としやすい注意点
外部サービス側の権限整理を先に行う
Federated connectorsはユーザーの権限を尊重しますが、外部サービス側の権限が広すぎれば、Copilotでも広い範囲の情報を参照できる可能性があります。Copilot連携を始める前に、外部SaaS側の共有設定、グループ、ロール、退職者アカウント、ゲストユーザーを見直してください。
特に、過去に「全員閲覧可」で作られたデータベースやナレッジベースは要注意です。人間が画面から探す運用では問題が表面化しなかった権限不備も、Copilotで自然言語検索できるようになると見つかりやすくなります。
「インデックスされない＝リスクがない」ではない
Federated connectorsは外部データをMicrosoft 365にインデックス化しない点が特徴です。しかし、Copilotの回答に外部データが使われる以上、情報の取り扱いルールは必要です。
たとえば、Copilotが外部CRMの情報を要約し、その要約をユーザーがメールやTeamsに貼り付ければ、そこから別の情報管理リスクが生まれます。機能の安全性だけでなく、利用者の運用まで含めて考える必要があります。
API制限や応答速度を確認する
Federated connectorsはリアルタイム取得が強みですが、裏側の外部APIが遅い、レート制限が厳しい、検索品質が低い場合、Copilotの回答体験も悪化します。
パイロット展開では、単に接続できるかではなく、次の観点を確認してください。
- よく使う質問で適切な結果が返るか
- 応答が業務利用に耐える速度か
- 権限不足時に分かりやすいエラーになるか
- 外部APIの制限に達した場合の挙動はどうなるか
- 参照元リンクを利用者が確認できるか
利用者に「何を聞くと役立つか」を示す
Copilot機能は、有効化しただけでは定着しません。利用者には、業務別のサンプルプロンプトを用意すると効果的です。
営業部門なら、次のような例が考えられます。
今週更新された重要商談を優先度順に整理して。根拠となる外部サービスの項目も示して。サポート部門なら、次のようなプロンプトが使えます。
直近30日で増えている問い合わせテーマを外部チケット情報から要約して。対応が遅れているものを分けて。財務・分析部門なら、次のような使い方が考えられます。
接続済みの外部データを使って、今月の変動要因をExcelで分析するための観点を整理して。こうした例を用意しておくと、利用者が「とりあえず何か聞いてみる」状態から、実務に直結する使い方へ移行しやすくなります。
管理者向けチェックリスト
展開前には、最低限次のチェックを行ってください。
| チェック項目 | 確認状況 |
|---|---|
| Microsoft 365管理センターでFederated connectorsの表示を確認した | 未確認の場合はCopilot > Connectorsを確認 |
| テナント全体で既定有効にするか、一括無効化するかを決めた | セキュリティ部門と合意する |
| 7日間の管理者レビュー期間の運用担当を決めた | 新規コネクタ追加時の確認漏れを防ぐ |
| Entra IDグループで段階展開する対象を決めた | まず検証グループから始める |
| 外部サービス側の権限を棚卸しした | 過剰共有を先に修正する |
| 監査ログと問い合わせ対応の流れを決めた | 利用開始後の運用に備える |
| 利用者向けガイドとサンプルプロンプトを用意した | 定着率と安全性を高める |
開発者向けチェックリスト
カスタムFederated connectorやパートナー連携を検討する開発者は、次の点を確認してください。
| チェック項目 | 実装上の注意 |
|---|---|
| MCPサーバーは公開可能なHTTPSエンドポイントで提供できるか | 社内専用の場合は到達性と認証を設計する |
| ツールは読み取り専用か | 書き込みや更新処理を混ぜない |
| ユーザー単位の権限判定ができるか | 管理者権限でまとめて返す設計は避ける |
| Microsoft Entra SSOまたはOAuth 2.0を選定したか | 利用者の認証体験も確認する |
| 検索結果にタイトル、URL、更新日時、概要を含められるか | Copilotの回答根拠として使いやすくする |
| エラー応答を設計したか | 権限不足、未接続、タイムアウトを区別する |
| 監査・ログを残せるか | セキュリティレビューに耐える設計にする |
まず何から始めるべきか
Federated Copilot connectorsのGAに対して、最初にやるべきことは新しいコネクタを片っ端から有効化することではありません。
まず、Microsoft 365管理センターで自社テナントに表示されているFederated connectorsを確認します。次に、テナント全体の既定動作を確認し、セキュリティ要件が厳しい場合は一括無効化または限定展開を検討します。そのうえで、業務効果が高く、権限管理が整理されている外部サービスからパイロット展開するのが現実的です。
Federated connectorsは、Microsoft 365 Copilotを「Microsoft 365内の情報を探すAI」から、「外部SaaSを含む業務データにアクセスするAI」へ広げるための実用的な仕組みです。一方で、外部データをCopilotに接続するほど、権限、監査、契約、ユーザー教育の重要性も増します。
今後の展開では、次の3点を優先してください。
- 管理センターで表示・既定状態・レビュー期間を確認する
- 外部サービス側の権限と監査を整えてから段階展開する
- Synced connectorsとFederated connectorsをデータ特性で使い分ける
この順番で進めれば、Microsoft 365 Copilotの外部データ活用を急ぎすぎず、安全性と実用性のバランスを取りながら広げられます。
コメント