Copilotの情報漏洩リスクと対策 設定と体制の両面から防ぐ

前回はCopilot導入前の権限設計と過剰共有の洗い出し手順を扱いました。今回はその上に構築すべきCopilotの情報漏洩リスクと対策を、設定と体制の両面から整理します。Copilotは既存のM365権限に依存するため、技術的な設定だけでは漏洩を防げません。必要なのは「どこで情報が意図せず露出するか」を因果で把握し、設定・監視・対応を構造化する仕組みです。

Copilotで起こる情報漏洩リスクの3つの構造

Copilotの情報漏洩は次の3つの経路で発生する可能性があります。いずれも技術設定のみでは防ぎにくく、体制と運用ルールの整備が前提となります。

• 権限設計の不備による露出: SharePointやTeamsで本来アクセスできないはずの文書に、Copilotを通じて間接的にアクセスできてしまうケース。Copilotはユーザーが持つ既存の権限範囲内でのみ情報を参照しますが、過剰に付与された閲覧権限や、削除し忘れたゲストアカウントが漏洩経路になる可能性があります
• プロンプト経由の意図しない共有: ユーザーが機密情報を含むプロンプトをCopilot Chatに入力し、そのやり取りが共有チャネルやループコンポーネントに残る形で他者に見える状態になるケース。会話履歴がチーム全体に公開設定されていると、個人が意図しない情報拡散が起こる場合があります
• 要約・引用機能による意図しない露出: Copilotが会議録音を要約する際、発言の一部が文脈を欠いた形で抽出され、本来見せるべきでない相手に共有されるケース。要約結果がデフォルトで会議参加者全員に配信される設定だと、機密性の高い議論の断片が漏れる可能性があります

これらは「Copilotの脆弱性」ではなく、M365の権限モデルと共有設計が可視化された結果です。Copilotは既存の権限構造を前提に動作するため、導入前に権限を整理しないまま展開すると、潜在していた過剰共有が顕在化する場合があります。

情報漏洩対策の全体像:設定・監査・対応の3層構造

Copilotの情報漏洩を防ぐには、事前設定・継続監査・事後対応を一体で設計します。設定だけで止まると、運用開始後の変化や例外に対応できません。

第1層:事前設定で防ぐ範囲

• 感度ラベルとDLPポリシーの適用: 機密文書に感度ラベル(Confidential等)を付与し、Copilotがその文書を参照した場合に自動で要約生成を制限するDLP(Data Loss Prevention)ルールを設定します。ラベルは文書作成時に自動付与する条件付きルールと組み合わせると、人手の漏れを減らせます
• ゲスト・外部ユーザーの権限スコープ制限: Azure AD B2Bで招待したゲストに対し、Copilot利用を許可するかどうかをテナント全体ポリシーで制御します。許可する場合も、特定のTeamsチャネルやSharePointサイト内に閲覧範囲を限定し、全社ファイルを検索できない状態にします
• Copilotプラグイン・拡張機能の制限: サードパーティ製Copilotプラグインがテナント外にデータを送信するリスクを防ぐため、管理センターで許可するプラグインをホワイトリスト制にします。未承認プラグインは自動ブロックされる設定を推奨します

Microsoft 365 Copilot 導入とオンボード ガイド(IT管理者向け)では、テナント設定とDLPポリシーの推奨構成が示されています。これを土台に自社の情報分類と照らし合わせて設定します。

第2層:継続監査で検知する仕組み

設定後も権限は日々変化します。新規プロジェクトでのゲスト追加、組織変更に伴う部署間アクセス付与など、意図しない権限拡大を早期に検知する監査が必要です。

• アクセスログの定期レビュー: Microsoft Purview監査ログから「Copilotが参照した文書」と「その文書にアクセスしたユーザー」を定期的に抽出し、想定外の組み合わせ(例:人事部員が経理の予算書にアクセス)がないか確認します。自動アラートを設定すると工数を削減できます
• 感度ラベル付与率のモニタリング: 全社文書のうち感度ラベルが付いていない割合を定期的に計測し、ラベル付与率が低下したら原因を調査します。ラベルのない文書はDLPで保護されないため、漏洩リスクが高い状態です
• 外部共有レポートの定期確認: SharePoint管理センターの「外部共有レポート」から、ゲストに共有されているファイル一覧を定期的に抽出し、業務上の必要性がないものは共有解除します

監査の頻度は組織のリスク許容度で決めます。金融・医療など高リスク業種ではより頻繁な確認が推奨される場合があります。

第3層:インシデント発生時の対応フロー

設定と監査をすり抜けて漏洩が発生した場合、初動の遅れが被害を拡大させる可能性があります。事前に対応フローを定めておくことで、判断の遅延を防ぎます。

1. 迅速な初動: 異常なアクセスログや社員からの報告を受けた時点で、該当ユーザーのCopilotアクセスを一時停止し、関連文書の共有リンクを無効化します。この段階では原因調査より拡散防止を優先します
2. 影響範囲確定: 監査ログから「誰が」「どの文書を」「いつ」Copilot経由で参照したかを特定し、情報が外部に転送されたかを確認します。メール送信ログとの突合が必要です
3. 再発防止策実施: 漏洩原因が権限設定なら該当サイトの権限を見直し、プロンプト誤用ならガイドラインを更新して全社通知します。対策完了まで該当部署のCopilot利用を制限する判断も検討します

対応フローは法務・情報セキュリティ部門と事前に合意し、責任者の連絡先と判断基準を文書化しておきます。夜間・休日の連絡体制も明記すると初動が早まります。

プロンプト誤用を防ぐ利用者教育の設計

技術的な設定を整えても、利用者がプロンプトに機密情報を直接入力すれば漏洩リスクは残ります。教育は「禁止事項を伝える」だけでなく、安全な使い方の具体例を示す構造にします。

教育すべき3つのポイント

• プロンプトに書いてはいけない情報の種類: 個人名・顧客名・金額・契約条件など、文書から引用する形でCopilotに質問させ、プロンプト自体に機密情報を書かない習慣を作ります。「この契約書の金額を教えて」ではなく「開いている契約書の重要ポイントを要約して」と指示する方が安全です
• 共有範囲の確認方法: Copilot Chatの会話履歴がどこに保存されるか(個人のOneDrive/チーム共有/パブリックチャネル)を意識させます。機密性の高い質問は個人チャットで行い、結果を選択的にチームに共有する手順を標準化します
• 要約結果の確認と編集: Copilotが生成した会議要約やメール下書きをそのまま送信せず、必ず内容を確認して不要な情報を削除する習慣を徹底します。自動生成された文章には、元文書の機密情報が意図せず含まれる可能性があります

教育は導入時の一度きりではなく、定期的に「実際に起きたヒヤリハット事例」を共有する形で継続します。抽象的な注意喚起より、具体的な失敗例から学ぶ方が定着率が高まる場合があります。

外部規制と社内ポリシーの整合

情報漏洩対策は自社の判断だけでなく、外部規制や業界ガイドラインとの整合も求められます。特に個人情報や医療情報を扱う組織では、Copilotの利用自体が規制対象になる場合があります。

個人情報保護委員会やデジタル庁では生成AIの利活用に関する情報が公開されており、Copilotが個人データを参照する場合の利用目的の特定や安全管理措置の水準が論点になります。これらを参照しつつ、自社の情報分類とCopilotの利用範囲を照らし合わせ、許可する用途と禁止する用途を明文化します。

社内ポリシーは「全面禁止」か「全面許可」の二択ではなく、情報の機密レベルごとに利用可否を分ける設計が現実的です。例えば「社外秘以上の文書はCopilot検索対象から除外」「契約書の要約は法務部のみ許可」といった段階的な制御を行います。

よくある設定ミスと修正手順

Copilot導入後に漏洩リスクが高まる可能性がある設定ミスと、その修正方法を示します。

ミス1:全社員にSharePointサイトの閲覧権限が付与されている

部門別サイトのはずが「全社員」グループに閲覧権限が残っていると、Copilotは全社員にそのサイトの情報を提示します。修正は次の手順で行います。

1. SharePoint管理センターから全サイトの権限一覧をエクスポート
2. 「全社員」「All Users」グループが含まれるサイトを抽出
3. 各サイト所有者に連絡し、本来必要な部門・プロジェクトメンバーのみに権限を絞る
4. 権限変更後、Copilotで検索して対象外の社員が情報を取得できないことを確認

ミス2:感度ラベルが付いていない機密文書が存在する

ラベルのない文書はDLPポリシーの対象外となり、Copilotが自由に参照します。修正手順は次の通りです。

1. Purview コンプライアンスポータルで「ラベルのない文書」を検索
2. ファイル名・作成者から機密性を判断し、該当するラベルを一括付与
3. 今後はファイル作成時に自動ラベル付与ルールを適用(例:特定フォルダ内の文書は自動で「社外秘」ラベル)

ミス3:ゲストユーザーの権限が削除されずに残っている

プロジェクト終了後もゲストアカウントが残ると、Copilot経由で過去の資料にアクセスされるリスクがあります。修正手順は次の通りです。

1. Azure ADの「外部ID」から全ゲストユーザーを一覧表示
2. 最終サインイン日が一定期間以上前のアカウントを抽出
3. 招待元の部門に利用継続の必要性を確認し、不要なアカウントは削除
4. 残すアカウントも、アクセス可能なサイトを最小限に絞る

情報漏洩対策の効果を測る指標

対策が機能しているかを評価するには、次のような指標を定期的に計測します。数値目標を設定することで、改善の優先順位が明確になります。

• 感度ラベル付与率: 全社文書のうちラベルが付いている割合
• 権限レビュー完了率: 定期的に実施する権限見直しの対象サイトのうち、レビューが完了した割合
• 異常アクセス検知から対応完了までの時間: インシデント発生時、検知から初動対応完了までの時間
• ゲストアカウントの平均滞留日数: ゲストが招待されてから削除されるまでの平均日数

これらの指標は定期レポートにまとめ、経営層とIT部門で共有します。数値が悪化した場合は原因を分析し、設定や運用ルールを見直します。

まとめ:設定・監査・対応を一体で設計する

Copilotの情報漏洩対策は、導入前の一度きりの設定では完結しません。権限設計・感度ラベル・DLPポリシーによる事前防御、アクセスログ監査による継続検知、インシデント対応フローによる事後対応を一体で構築することで、リスクを構造的に管理できます。教育と監査を組み合わせ、設定のすり抜けを早期に発見する仕組みが、漏洩を防ぐ最後の砦になります。では、これらの対策を実務で確実に実行するには、管理者がどのような設定項目を日常的にチェックすべきでしょうか。次回はその具体的なチェックリストを扱います。

よくある質問

Copilotで情報漏洩が起きやすい原因は何ですか

SharePointやTeamsの権限が過剰に付与されたまま放置されている状態が代表的な原因です。Copilotは既存の権限範囲内で情報を参照するため、本来アクセスできないはずの社員に閲覧権限が残っていると、Copilot経由でその情報が見えてしまう可能性があります。プロジェクト終了後に権限を削除し忘れる、全社員グループに一律で権限を付与するといった運用が漏洩の起点になる場合があります。導入前に権限の棚卸しと最小権限の原則に基づく再設計が推奨されます。

Copilotのプロンプト履歴は誰が見られる状態になりますか

Copilot Chatの会話履歴は実行したユーザー本人のみがアクセスできるのが原則ですが、チーム共有チャネルやループコンポーネント内でCopilotを使った場合、その会話内容はチャネルメンバー全員に公開されます。また管理者は監査ログからプロンプト内容を確認できます。機密性の高い質問は個人のCopilot Chatで行い、結果を選択的に共有する運用を推奨します。会話履歴の保存場所と公開範囲を利用者が理解していないと、意図しない情報露出が起こる場合があります。

感度ラベルを付けた文書はCopilotで検索できなくなりますか

感度ラベル自体は検索を禁止しません。ラベルに紐付けたDLP(Data Loss Prevention)ポリシーで「このラベルが付いた文書はCopilotの要約生成を制限する」「特定の部署以外は検索結果に表示しない」といった制御を行います。例えば「極秘」ラベルが付いた文書に対し、経営層以外のCopilot検索結果から除外するルールを設定できます。ラベル付与とDLPポリシーは必ずセットで設計し、ラベルだけ付けてポリシーを設定しない状態では保護効果がありません。

外部ゲストにCopilotを使わせても安全ですか

ゲストのCopilot利用はアクセス範囲を明確に制限した上でのみ許可することが推奨されます。ゲストは招待されたTeamsチャネルやSharePointサイト内でCopilotを使えますが、そのサイトに機密文書が混在していると、Copilot経由で参照される可能性があります。対策としてゲスト専用のサイトを分離し、そこに共有してよい資料のみを配置する、ゲストアカウントにCopilot利用権限を付与しないテナント設定を選択するといった構造が有効です。業務上の必要性を都度評価し、不要になったゲストは速やかに削除します。

Copilotの情報漏洩対策で最初にやるべきことは何ですか

最初に行うべきはSharePointとTeamsの全サイト・チャネルの権限一覧を可視化することです。管理センターから権限レポートをエクスポートし、誰がどのサイトにアクセスできるかを一覧表にします。その上で「全社員」「All Users」といった広範なグループに権限が付与されているサイトを特定し、本来必要なメンバーのみに絞ります。この権限整理を行わずにCopilotを展開すると、既存の過剰共有がCopilot経由で顕在化し、漏洩リスクが高まる可能性があります。技術的な設定より先に、権限構造の可視化と再設計が対策の起点です。