Copilotの社内データ接続はどこまで許可するか AIコネクタ権限管理の棚卸し
Copilotに社内データをつなぐ前に、見せる範囲を一枚に整理できると判断はかなり楽になります。
学習の有無だけでなく、権限と停止方法まで見えているかを一緒に確認しませんか。
Copilotの社内データ接続は、便利そうに見えるほど判断が難しくなります。営業資料、Teamsの会話、SharePointの古いフォルダ、外部SaaSのチケット情報までつながると、「何を見せてよいのか」を説明できる会社だけが安全に広げられるからです。
最初に押さえたいのは、「AIに学習されるか」と「社員の権限で見えてしまうか」は別問題だという点です。学習利用の話だけで安心すると、既存の共有権限が広すぎる問題を見落とします。
この記事では、Microsoft 365 Copilotを前提に、社内データ接続、AIコネクタ権限管理、生成AI SaaS管理を一枚の棚卸し台帳へ落とし込む順番で整理します。まず見るのは、AIの性能ではなく接続の説明責任です。
Copilotの社内データ接続で最初に分けること
Microsoft 365 Copilotは、Microsoft Graphを通じてメール、チャット、予定表、文書などの文脈を扱います。Microsoft公式情報では、Copilotは既存のMicrosoft 365サービスの権限モデルを使い、ユーザーが少なくとも閲覧権限を持つデータだけを表示対象にすると説明されています。
出典: Microsoft Learn「Data, Privacy, and Security for Microsoft 365 Copilot」(英語)
同じ公式ページでは、プロンプト、応答、Microsoft Graph経由でアクセスしたデータは、基盤LLMの学習には使われないとも説明されています。ここだけ見ると安心材料ですが、実務上の焦点は別です。
Copilotは権限を無視して全社データを読むわけではありません。しかし、SharePointやTeamsの権限が以前から広すぎれば、その広すぎる権限のまま回答の文脈に使われます。つまり危ないのはCopilotそのものより、古い共有設定が放置されたまま接続されることです。
要点判断は「学習」より「見える範囲」から始める
Copilotに社内データを接続する前に見るべきなのは、学習利用の有無だけではありません。社員がすでに見られるデータの範囲が広すぎないかを先に確認します。
この論点は、生成AIを社内データに学習させない設定を考えるときにも同じです。学習オフや履歴設定を確認したうえで、最後は権限、共有リンク、データオーナーへ戻ってくると考えると迷いにくくなります。
学習の論点（製品仕様）
プロンプト・応答・Graph経由データは基盤LLMの学習に使われない（Microsoft公式）
学習利用や履歴の設定で確認できる
ここだけ見ると安心しやすい
見える範囲の論点（自社の権限）
既存のSharePoint・Teams権限が広すぎると、その範囲が回答の文脈に使われる
危ないのはCopilotより、古い共有設定の放置
権限・共有リンク・データオーナーの棚卸しが要る
接続先は3層に分けて見る
Copilotの社内データ接続を一つの箱で考えると、議論が混ざります。まずはMicrosoft 365内部データ、外部コネクタ、エージェントとWeb検索の3層に分けてください。
| 層 | 対象 | 確認点 |
|---|---|---|
| 内部データ | SharePoint、OneDrive、Teams、Exchange | 既存権限、共有リンク、所有者 |
| 外部コネクタ | CRM、チケット、ナレッジ、業務DB | 接続方式、ACL、同意、対象者 |
| 追加機能 | エージェント、Web検索、アクション | 承認、割当、ログ、停止方法 |
Microsoft Learnでは、Copilot connectorsの方式として、外部データをMicrosoft Graphへ同期してインデックス化する方式と、MCPを使ってリアルタイムに取得するフェデレーテッド方式が説明されています。同じ「コネクタ」でも、データ移動の有無が違うため、台帳では分けて扱う必要があります。
出典: Microsoft Learn「Microsoft 365 Copilot connectors overview」(英語)
メモ同期型は「どこに取り込むか」、フェデレーテッド型は「誰の権限でリアルタイム取得するか」を確認します。どちらも安全性の見方が違うため、同じ承認フローにまとめない方が扱いやすくなります。
Microsoft 365のデータ活用全体を整理したい場合は、社内文書をAIで横断検索する仕組みも参考になります。横断検索の便利さを考えるほど、どのデータを横断させるかの線引きが必要になるからです。
許可・試験許可・停止の基準
接続可否は、全社で一括許可するものではありません。現実的には、許可、試験許可、停止の3分類で見ます。基準はシンプルで、目的、データ分類、対象者、監査、停止方法を説明できるかです。
| 判定 | 条件 | 進め方 |
|---|---|---|
| 許可 | 目的、対象、監査、停止方法が明確 | 部門単位で開始し月次確認 |
| 試験許可 | 価値はあるが権限確認が一部未了 | 期間、部署、データ範囲を限定 |
| 停止 | 所有者不明、全社共有、監査不能 | 権限整理後に再判定 |
試験許可は、甘い許可ではありません。むしろ本番許可に進める前の安全確認です。対象グループ、対象データ、期間、レビュー日を決め、回答の出典リンクと予期しない参照を見ます。
注意「便利そうだから全社許可」は避ける
Copilotの社内データ接続は、許可範囲が広いほど効果も出やすくなります。ただし、説明できない接続を広げるほど、後から止めるのが難しくなります。
AIエージェントに実行を任せる場面でも、同じ考え方が使えます。AIエージェントの承認フローでは、閲覧、提案、実行を分けて考える方法を整理しています。
棚卸し台帳に入れる項目
最初に作るべきものは、立派な規程ではなく接続台帳です。ExcelやGoogleスプレッドシートで構いません。誰が見ても「何を、誰に、どの方式で許可したか」が分かる状態を作ります。
| 項目 | 書く内容 | 見落とし時の問題 |
|---|---|---|
| 接続名 | コネクタ名、エージェント名 | 有効な接続を説明できない |
| データソース | SharePoint、CRM、外部Wiki | 重要情報が混ざる |
| 方式 | 内部、同期型、フェデレーテッド型 | データ移動を説明できない |
| 対象者 | 部署、グループ、個人 | 全社に広がる |
| 承認者 | データオーナー、情シス | 責任者不明になる |
| 監査 | Purview、管理ログ、月次レビュー | 事故後に追えない |
| 停止方法 | 割当解除、無効化、権限変更 | 問題時に止められない |
この台帳は、情報システム部門だけの資料にしない方が実用的です。データオーナー、現場責任者、管理者が同じ表を見ることで、業務価値と情報リスクを同じ場所で話せます。
推奨最初の台帳は7列で十分
完璧な管理台帳を最初から作る必要はありません。まずは接続名、データソース、方式、対象者、承認者、監査、停止方法の7列から始めると、会議で確認しやすくなります。
AIツール全体の停止漏れや退職時の棚卸しまで広げるなら、AIツールの権限棚卸しで紹介した台帳の考え方もそのまま使えます。Copilotだけを特別扱いせず、生成AI SaaS管理の一部として置く方が運用は続きます。
SharePointとTeamsの既存権限を先に見る
Copilot接続前の確認で最も手戻りが大きいのは、SharePointとTeamsの既存権限です。古いプロジェクトサイト、所有者不明のチーム、全社共有リンク、外部共有リンクが残っていると、Copilot以前から見えていた範囲がそのまま問題になります。
MicrosoftはSharePoint Advanced Managementを、過共有やコンテンツライフサイクル、最小権限、アクセスレビューなどの管理に使える仕組みとして案内しています。使える契約や設定がある場合は、手作業の前にレポートで危険な場所を絞ると早く進みます。
一方で、Restricted SharePoint Searchは使い方を間違えやすい機能です。Microsoft公式は、これをCopilotや検索の範囲を一時的に絞る短期的な解決策として説明し、セキュリティ境界ではないとも明記しています。
出典: Microsoft Learn「Restricted SharePoint Search」(英語)
警告検索範囲の制限を権限整理の代わりにしない
Restricted SharePoint Searchで一時的に範囲を絞っても、SharePointの権限そのものが整うわけではありません。短期策を恒久対策に見せないことが大切です。
実務では、まず高リスクなサイトだけでも見ます。所有者不明、外部共有、Everyoneや全社グループ、古い共有リンク、機密ラベル未設定の場所を洗い出し、Copilot接続の前に閉じるものを閉じる。この順番なら、導入を止めずに安全性を上げられます。
エージェント、Web検索、監査ログの確認
社内データ接続の棚卸しでは、コネクタだけでなくエージェントも見ます。Microsoft 365 admin centerでは、エージェントの有効化、無効化、割当、ブロック、削除などを管理できると説明されています。「誰が追加できるか」「誰に割り当てたか」を台帳に戻してください。
出典: Microsoft Learn「Manage agents for Microsoft 365 Copilot in Integrated apps」(英語)
Web検索についても同様です。Microsoft公式では、Web検索は任意機能であり、管理者設定とユーザー側のトグルで制御されると説明されています。Bingへ送られるのは通常、プロンプト全体ではなく生成された検索クエリですが、文脈によって扱いが変わるため、会社としてWeb検索を許可する業務を決めておく方が安全でしょう。
さらに、Microsoft PurviewではCopilotのプロンプトや応答を監査、eDiscovery、保持ポリシーなどの対象にできるとされています。ここで見るべきは、社員を監視することではありません。想定外のデータ参照や危険な使い方を早めに見つけることです。
確認ログは責めるためでなく止めるために見る
利用ログの目的を「社員の監視」にすると、現場は隠れて使い始めます。危険な接続、想定外の出典、権限の広がりを見つけ、必要なら接続を止める条件を先に決めておきます。
外部アプリ連携の権限設計は、ChatGPTなど他のAIツールでも同じ課題です。ChatGPT接続アプリ権限の社内ルールもあわせて見ると、Copilotだけでなく生成AI SaaS管理全体の見直しにつながります。
初月に見る運用チェック
接続を許可したら、最初の1ヶ月は広げる時期ではなく観察する時期です。現場に使わせながら、回答の出典、見えて困る情報、使われていない接続、止めるべき接続を見ます。
初月チェック4つだけ見る
1. 出典リンク
回答がどの文書や外部データを根拠にしたか。
2. 予期しない参照
見えてほしくない部署資料や古い共有フォルダが出ていないか。
3. 使われ方
本来の業務目的から外れていないか。
4. 停止判断
次回レビューまでに止める接続、狭める接続、広げる接続を決める。
この確認をしないまま席数や接続先だけ増やすと、Copilotが使われない問題と、見せすぎる問題が同時に起きます。定着の進め方はCopilotが使われない会社の共通点でも整理していますが、使われる状態を作るには安全に使える範囲が先に必要です。
結論として、Copilotの社内データ接続は「許可するかしないか」ではなく、どのデータを、誰に、どの方式で、いつ止められる形で許可するかの問題です。まずは接続台帳を1枚作り、説明できない接続を止めるところから始めてください。
FAQ
QCopilotは社内データを学習しますか？
AMicrosoft公式では、Copilotのプロンプト、応答、Microsoft Graph経由でアクセスしたデータは基盤LLMの学習には使われないと説明されています。ただし、既存権限で見えるデータは回答の文脈に使われるため、権限の棚卸しは別に必要です。
QCopilotの社内データ接続は全部止めるべきですか？
A全部止める必要はありません。目的、データ分類、対象者、監査方法、停止方法を説明できる接続から、部署や期間を絞って許可するのが現実的です。
QGraph connectorsとMCPの違いは何ですか？
AGraph connectorsの同期型は外部データをMicrosoft Graphへ取り込みます。MCPを使うフェデレーテッド型は、外部APIからリアルタイムに取得する方式です。台帳ではデータ移動の有無を分けて記録します。
QRestricted SharePoint Searchを使えば十分ですか？
A十分とは言えません。MicrosoftはRestricted SharePoint Searchを短期的な解決策であり、セキュリティ境界ではないと説明しています。過共有の棚卸しや権限整理と組み合わせて使います。
Q中小企業では何から始めるべきですか？
Aまず接続台帳を1枚作ります。接続名、データソース、接続方式、対象ユーザー、承認者、監査方法、停止方法の7列だけでも、許可範囲を説明しやすくなります。
Q運用開始後はどのログを見ればよいですか？
A回答の出典、予期しないデータ参照、エージェント追加、Web検索の利用、停止や割当解除の履歴を見ます。目的は社員を責めることではなく、危険な接続を早く止めることです。
