【Microsoft Copilot】外部接続は「検索だけ」とは限らない――MCPコネクタの権限・承認・公開範囲を整理する

執筆している2026年11月4日時点の情報です。Cowork は更新が速い機能のため、最新情報は必ず公開情報（本記事末尾の参考リンク）もあわせてご確認ください。

1. 「接続を許可する」の前に、何ができる接続かを確認する

「外部の業務システムをCopilotにつなげて、情報を検索したい」

導入の目的が検索であれば、管理者も利用者も、読み取り専用の接続を想像しがちです。

しかし、Microsoft CopilotのFederated connector（フェデレーション型コネクタ）は、情報を取得するだけの仕組みとは限りません。コネクタが対応するツールを提供している場合、接続先のデータを作成・更新・削除できます。

たとえば、チケットを検索する接続に、コメントを追加するツールや、レコードを更新するツールも含まれている可能性があります。

重要なのは、コネクタの名前ではなく、次の3点を分けて確認することです。

確認すること	判断する内容
接続先での権限	誰の権限で、どのデータを参照・変更できるか
コネクタの利用対象	組織内の誰に、その接続を使わせるか
ツールの実行承認	更新や削除を、どの単位・期間で許可するか

この記事では、Copilot ChatやCoworkから外部システムを利用する管理者・開発者に向けて、この3つを整理します。

新機能の提供開始を知らせる記事ではなく、現行の公式資料に基づく管理・運用の解説です。

出典：Federated connectors overview

2. MCPは接続の仕組みであり、「読み取り専用」の意味ではない

**MCP（Model Context Protocol）**は、AIアプリケーションと外部のデータや機能をつなぐためのプロトコルです。

ここでいうツールとは、検索、レコード取得、コメント追加など、接続先が呼び出し可能な機能として公開する操作を指します。

Federated connectorでは、MCPを通じて必要なタイミングで外部システムへアクセスします。

方式	情報の扱い
同期型コネクタ	外部データをMicrosoft Graphへ索引化する
Federated connector	外部データを索引化せず、その都度取得する

索引化とは、検索しやすくするためのインデックスを作ることです。Federated connectorでは、元の外部システムが引き続きデータの管理元になります。

ただし、「Microsoft 365へ索引化しない」ことと、「外部へ情報を送らない」ことは別です。

公式資料には、書き込み操作を行う際、処理に必要な情報をコネクタへ送信すると記載されています。たとえばコメントを追加するなら、その本文は接続先へ渡されます。

「データを元の場所に置いたまま利用できる」という特徴だけで、情報の流れや第三者サービスの利用条件の確認を省略しないようにしましょう。

出典：Federated connectors overview — Dynamic tooling / Write, update, and delete actions

3. 接続先の権限：Copilotが使うのは利用者本人の権限

公式資料では、Federated connectorは利用者本人のIDと権限で外部システムへアクセスすると説明されています。

接続時には、利用者が自分の資格情報で認証します。Copilotが参照・変更できる範囲は、接続先でその利用者に許可されている範囲です。

たとえば、次のように考えます。

接続先での利用者の権限	Copilot経由の操作を考える際の前提
チケットの閲覧のみ	更新ツールがあっても、更新権限が新たに付与されるわけではない
閲覧とコメント追加	対応ツールがあれば、コメント追加も利用対象になり得る
広範囲の更新・削除	広い権限を前提とした操作が可能になり得るため、特に慎重な確認が必要

これは、権限を守る仕組みであって、既存の権限が適切かを判断してくれる仕組みではありません。

人が画面から操作するときには普段使わない権限でも、そのアカウントに付与されていれば、管理上の確認対象になります。

導入前には、接続先の権限も見直しましょう。筆者なら、日常利用者に管理者権限を付けたまま試すのではなく、実際の業務に必要な権限を持つテスト利用者を用意します。

出典：Federated connectors overview — Security and compliance

4. 公開範囲：「誰に接続を見せるか」と「何を見せるか」は別

この記事でいう「公開範囲」は、インターネットへの一般公開ではなく、組織内でコネクタを利用できるユーザーの範囲です。

コネクタを使えるようにすることは、接続先の全データを全員へ共有することではありません。一方、接続先の権限が適切でも、コネクタを誰に展開するかは別途管理する必要があります。

公式資料では、主に次の設定が説明されています。

設定	役割
Agent and plugin access	Microsoft製、組織製、外部発行元製といった発行元の種類ごとに、一括で利用可否を設定する
User access	エージェントやプラグイン、コネクタを利用できるユーザーの上限範囲を設定する
Enable / Disable	個別のコネクタを有効化・無効化する
Staged rollout	個別のコネクタを利用できるユーザーやグループを指定する

User accessが、利用者の上限になる

たとえば、次の設定を考えます。

• User access：検証グループのみ
• 個別コネクタのStaged rollout：Everyone

この場合でも、User accessの対象外の利用者には、そのコネクタを利用させられません。

個別コネクタの対象設定は、User accessで決めた範囲を狭められますが、広げられません。

「個別の画面にEveryoneと表示されているから、全社員が使える」とは限らない点が重要です。

発行元の一括設定には、個別の例外がある

Agent and plugin accessで発行元の種類をオフにすると、その種類の既存コネクタはStaged rolloutがNo usersとなり、将来追加される同種のコネクタも利用対象外になります。

ただし、管理者が個別のコネクタを選んで利用可能にすることはできます。公式資料では、個別設定が発行元の一括設定より優先され、User accessは常に適用されると説明されています。

そのため、利用可否を確認するときは、一括設定だけでなく、個別コネクタの状態と対象範囲も確認します。

なお、公式概要にある利用者への表示条件には、Microsoft 365 Copilotライセンスも含まれています。Copilot Chat自体を使えることと、その外部接続を使えることを同一視しないようにしましょう。

出典：Manage federated connector availability

5. 操作の承認：「毎回確認される」とは限らない

書き込み・更新・削除を行うツールは、初期状態では利用者の明示的な承認が必要です。

利用者は確認画面を展開し、実行する操作のパラメーターを確認できます。

ただし、選べるのは「今回だけ許可」だけではありません。

選択肢	公式資料で説明されている動作
Allow once	今回実行する。次回そのツールを使う際は再度確認する
Allow for conversation	今回実行し、現在の会話の残りではそのツールの確認を省略する
Always allow	今回実行し、設定変更または発行元によるツール変更まで、そのツールの確認を省略する
Cancel	操作を拒否する。接続先のデータは変更されない

Allow for conversationとAlways allowは、コネクタ全体ではなく個々のツールに適用されます。

たとえばコメント追加ツールをAlways allowにしても、それだけで別の削除ツールまで許可したことにはなりません。

反対に、同じコメント追加ツールを継続して許可すると、後続の操作では毎回の確認が省略されます。「更新前には必ず確認画面が出るから安心」という利用者説明は不正確です。

また、読み取りツールは、この書き込み操作の確認を必要としません。読み取りで機密情報を扱う場合も、確認画面ではなく、接続先の権限やコネクタの利用対象設定を適切に設計する必要があります。

出典：Federated connectors overview — Confirm an action

継続許可を見直す場所

公式資料では、Copilotの Settings → Sources → 対象コネクタ から、ツールの承認設定を確認・変更する方法が案内されています。

Write/Delete toolsを展開すると、個々のツールの状態を確認できます。Always allowにした設定を、Needs approvalへ戻すこともできます。

また、発行元が新しい書き込みツールを追加したり、既存ツールを変更したりした場合、そのツールは既定でNeeds approvalになります。

導入時だけでなく、接続先の機能変更や利用者の担当業務変更に合わせて見直す運用にしましょう。

出典：Federated connectors overview — Manage tool permissions

6. 同じ接続でも、利用する機能によって操作範囲が異なる

公式概要では、Federated connectorの利用先としてCopilot Chat、Cowork、エージェント、Officeアプリ内のCopilot、Researcherなどが案内されています。

ただし、Researcherでは作成・更新・削除をサポートせず、読み取り専用と明記されています。

つまり、「Researcherでは検索しかできなかった」という経験だけを根拠に、同じ接続がCopilot ChatやCoworkでも読み取り専用だとは判断できません。

確認すべきなのは、次の組み合わせです。

利用するCopilotの機能 × コネクタが提供するツール × 接続先の利用者権限

コネクタ単位の説明だけでなく、「どの画面・機能から使うのか」まで含めて利用者へ案内しましょう。

出典：Federated connectors overview — Supported Copilot experiences

7. 接続を有効化する前に、ツールを確認する

公式概要には、管理センターのコネクタ詳細画面でツール一覧を確認する説明があります。

ただし、この節にはComing soonと付いています。すべてのコネクタ・テナントで、今すぐ管理センターから同じ一覧を確認できるとは説明できません。

管理センターで確認できない場合については、公式資料に次の経路が案内されています。

Copilot Chat → Settings → Sources → 対象コネクタ → Write/Delete toolsを展開

確認する際は、ツール名だけでなく、何を入力し、どのデータを作成・変更・削除するかを読みます。

なお、表示されるツール一覧は、接続時に使用したアカウントの権限に依存します。ある利用者に見える一覧が、組織内の全利用者の操作能力を表すとは限りません。

管理上の機能確認と、一般利用者の権限で行う動作確認を分けて考えることが大切です。

出典：Federated connectors overview — View a connector’s tools in the admin center

8. 実務例：チケット管理システムを小さく展開する

ここからは、筆者が提案する仮想の導入例です。特定製品での検証結果や、実際に存在するツール名を示すものではありません。

あるチケット管理用コネクタに、次の3種類のツールがあるとします。

仮想のツール	目的	導入前の確認
チケット検索	状況の把握	他部門や機密案件を参照できないか
コメント追加	対応内容の記録	本文、対象チケット、コメントの閲覧者が適切か
チケット削除	不要データの削除	業務上必要か、利用者に削除権限が必要か

最初の目的が状況把握だけなら、筆者は次のように進めます。

1. 接続先の権限を整理する
   検証利用者には、目的に必要な権限だけを付与します。

2. 利用対象を限定する
   User accessと個別コネクタのStaged rolloutを確認し、少人数で始めます。

3. 読み取りと書き込みを分けて試す
   テスト用データで参照範囲を確認し、書き込みが必要な場合だけ、変更先と承認動作を確認します。

4. 利用者向けの説明を用意する
   確認画面で見る項目と、継続許可を選んだ場合の意味を伝えます。

5. 確認結果を踏まえて対象を広げる
   利用可否だけでなく、接続先の権限と実際の操作結果も確認します。

「この接続では更新しないでください」とプロンプトに書くことは、利用上の指示にはなります。しかし、接続先の権限を制限したことにはなりません。

技術的に許可する操作の範囲と、AIに伝える作業方針は分けて設計します。

9. 導入前・運用中のチェックリスト

確認項目	確認する内容
提供元と利用条件	発行元、プライバシー条件、第三者サービスの契約を確認したか
操作の種類	読み取りだけか、作成・更新・削除も含まれるか
利用する機能	Copilot Chat、Cowork、Researcherなどの違いを確認したか
本人の権限	接続先で不要に広い権限を持っていないか
利用者の範囲	User accessと個別コネクタのStaged rolloutを確認したか
将来の追加	発行元の一括設定が、将来追加されるコネクタへどう適用されるか確認したか
操作承認	Allow once、会話中の許可、Always allowの違いを説明したか
データの送信	操作の引数や本文として、外部へ渡す情報を確認したか
継続的な見直し	ツール追加、権限変更、担当変更に合わせて確認する担当者を決めたか

管理資料では、設定変更がMicrosoft 365の各機能へ反映されるまで最大10分かかる場合があると案内されています。

変更直後の表示だけで判断せず、管理センターを更新し、テスト利用者のCopilot ChatのSourcesでも確認する流れが示されています。

出典：Manage federated connector availability — Verify the changes

10. まとめ

MCPを使うFederated connectorは、外部情報をその都度取得するだけでなく、提供されるツールによっては外部システムを操作できます。

導入時は、次の3つを別々に確認しましょう。

誰の権限で動くか。誰に接続を使わせるか。どの操作を継続して許可するか。

特に覚えておきたいのは、次の点です。

• 索引化しないことは、外部へのデータ送信がないことを意味しません。
• 接続先の権限が守られていても、その権限自体が広すぎる場合があります。
• 書き込みツールには継続許可があるため、毎回の確認を前提にできません。
• Researcherの読み取り専用という制限を、ほかの利用先へ一般化できません。

検索の便利さだけでなく、操作できる範囲と、承認の有効範囲まで含めて接続を管理する。それが、外部システムとCopilotを組み合わせる際の出発点になります。

参考リンク

以下のMicrosoft公式資料は、2026年11月4日に本文を確認しています。

• Federated connectors overview — Microsoft 365 Copilot connectors
  MCPによる取得、対応する利用先、利用者権限、書き込み操作、承認設定、管理センターのツール表示に関する説明。
• Manage federated connector availability — Microsoft 365 Copilot connectors
  発行元ごとの設定、User access、個別コネクタの設定、反映後の確認方法。

着想・関連解説

• Oracle Autonomous DatabaseのデータをMicrosoft 365 Copilot Coworkから参照する ― Select AI AgentとMCPの連携／ymaejima
  外部データとCoworkを接続する実務テーマの着想となった第三者の検証記事です。本記事は、そのOracle構成や認証方法の動作を検証したものでも、Microsoftの公式対応として保証するものでもありません。

本記事について

本記事は、公開情報をもとに内容を整理し、できるだけ分かりやすく解説することを目的として作成しています。記載内容は個人の見解であり、所属組織の公式見解を示すものではありません。少しでもお役に立てればうれしいです。

ご質問・追記要望は本ページのコメント欄までお寄せください。