Copilot導入で情報漏えいを起こす会社の共通点は「LLM」ではなく“オーバーシェア”

Microsoft Purview（秘密度ラベル／DLP）×Entra（権限）×Copilotコネクタで、情シスが「止めずに守る」実装手順

※本記事は一般的な情報提供を目的としており、個別案件の法的助言・紛争対応・代理交渉等を行うものではありません。個別事情に応じた判断が必要な場合は、内容により弁護士等の専門家と連携して検討してください。

1. “Copilotが漏らす”のではなく「あなたの権限設計が漏らす」

まず、情シスが社内・取引先から聞かれる定番2問に、Microsoft公式の前提で答えを揃えます。

Q1：入力したプロンプトや社内データが、基礎モデルの学習に使われませんか？

Microsoft Learnでは、Microsoft Graph経由でアクセスされるプロンプト・応答・データは、基礎LLMのトレーニングには使用されないと明記されています。

Q2：Copilotは、社内の何でも見えるんですか？

Microsoft Learnでは、Copilotは各ユーザーが少なくとも“閲覧権限”を持つ組織データのみを表示し、SharePoint等の権限モデルを適切に設計することが重要（外部ユーザーに付与する権限も含む）と整理されています。

結論：Copilot導入で事故る組織の本質は、**「AIが強い」ではなく“共有が雑”**です。

2. まず情シスがやるべきは「Copilot Chatを“緑の盾”の世界に揃える」

2026年の現場で一番危険なのは、ユーザーが「職場アカウントで守られたチャット」と「個人向け/未保護のチャット」を混同することです。

Microsoft Learnでは、Microsoft 365 Copilot Chatはプロンプトと応答に対してエンタープライズ データ保護（EDP）を提供し、追加料金なしで利用でき、UI上の“緑のシールド”で適用が示されると説明しています。

さらに、Copilot Chatではプロンプトと応答がログに記録され、監査／電子情報開示のためにExchangeに保存される、と整理されています。

情シス目線の要点はこれです。

• 「緑の盾＝EDP」 を利用者に教育（ここが揃わないと、ルールが空中分解）

• 監査・eDiscoveryの観点では、**残るログの“取り扱い（保持・閲覧権限・提出手順）”**まで運用設計が必要

3. Copilot時代の“4層防御”──権限→ラベル→DLP→コネクタ

第1層：権限（Entra/SharePoint/Teams）＝Copilotの“検索範囲”そのもの

Copilotは権限の上に乗ります。だから最初にやるのは、AIの設定ではなく過剰共有の棚卸しです。

山崎行政書士事務所のブログでも、M365導入初期は「現状の使われ方をざっくり把握→A4一枚の暫定ルール→3ヶ月かけて“ルールと設定をすり合わせ”」という進め方が現場向きだと整理しています。

情シスの現場タスクに翻訳すると：

• SharePoint：**“全社公開（意図せずEveryone系が入っている）”**を潰す

• Teams：共有チャネル／ゲストで外部に見える範囲を把握（Copilotの前に、まず共同作業の境界を確定）

• 「共有は善」ではなく、**“共有の根拠（なぜ見せるのか）”**を持たせる

第2層：秘密度ラベル（分類と保護）＝“人間の判断”を仕組みにする

Microsoft Purviewの秘密度ラベルは、データを分類・保護しつつ、共同作業の生産性を損なわない目的で設計されており、ラベルにより暗号化や透かし等の保護設定も適用できます。

重要なのは「ラベルを作る」よりも、Copilot時代はラベルが“AIのガードレール条件”として再利用できることです。

第3層：Copilot用DLP＝「そのデータをAIの回答生成に使わせない」

ここが“刺さる”ポイントです。Microsoft Learnでは、Purview DLPで Microsoft 365 Copilot と Copilot Chat の“ポリシーの場所”を使い、秘密度ラベル条件でファイルやメールをCopilotの処理対象から除外できる、と説明しています。

しかも実務でありがたいのが次の仕様です。

• Word/Excel/PowerPointで Microsoft 365 Copilot / Copilot Chat / Copilot に適用

• 事前構築済みエージェントにも保護が拡張

• ただし OutlookのCopilotでは未サポート（ここが落とし穴）

• ブロックされたアイテムは引用文献に表示され得るが、内容は回答に使われない／Copilotがアクセスしない 

情シスの設計指針はこうなります。

• 「極秘」ラベルの文書は Copilot回答生成に使わせない（＝“AIから見えない”を実現）

• その代わり、引用文献に出る可能性まで踏まえて、ファイル名・保存場所・サイト設計も整える（“ファイル名が機密”は普通にあるので、命名規約も統制対象）

第4層：Copilotコネクタ／外部データ＝“新しい過剰共有”の地雷

意外と盲点なのが、Copilotコネクタです。Microsoft Learnでは、Copilotコネクタは外部データソースのコンテンツをMicrosoft 365 SearchとCopilotにインデックス化し、セットアップ時のアクセス許可が組織の意図した可視性モデルを反映していることが重要と説明しています。

そして痛い事実がもう1つ：

• 作成後のアクセス許可編集はサポートされず、誤構成を直すには 削除→再作成が確実 

ここ、情シスの運用設計に直撃します。

• コネクタ導入は「便利機能」ではなく、権限設計の一発勝負

• “Everyoneに見える”設定事故は、Copilot時代だと影響範囲が跳ね上がる

• 変更管理（チケット・承認・ロールバック）を前提にして導入すべき

4. 「監査で説明できるAI」へ：Purviewの“AI管理フロントドア”を使う

Microsoft Learnでは、Microsoft Purviewで Microsoft 365 Copilot / Copilot Chat のデータセキュリティ＆コンプライアンスを管理する推奨手順が整理されており、AI用DSPMを“フロントドア”として、監査の有効化確認、過剰共有の評価と防止、データ保護・アクティビティ検出などを進める流れが示されています。

つまり、情シスの現場は「設定した」ではなく、

• 過剰共有がどれだけ減ったか

• どのラベルをどう守っているか

• DLPがCopilotにどう効いているか

• 監査でどこを見せれば証明できるか

までを“クリック手順化”して初めて強くなります。

山崎行政書士事務所では、監査で詰まりやすいポイントを「証跡ナビ（画面パス付き）」としてクリック手順化する考え方を提示しています。

5. 情シス向け：Copilot導入前チェックリスト

A. 利用者が迷わないか（運用事故の芽）

• □ Copilot Chatの**緑の盾（EDP）**を利用者が理解している

• □ プロンプト／応答が監査・eDiscoveryに残る前提で、閲覧・提出の運用がある

B. 過剰共有を潰せているか（根本原因）

• □ Copilotは閲覧権限の範囲で見える、と説明できる（＝権限棚卸しがある）

C. “AIに使わせないデータ”を決めたか（ラベル×DLP）

• □ 秘密度ラベルの体系があり、暗号化・マーキング等の方針がある

• □ Copilot/Copilot ChatのDLP（場所）で、ラベル条件で処理除外している

• □ OutlookのCopilotはこの機能が未サポートである点を織り込んでいる

D. “新しい地雷”を踏まないか（コネクタ）

• □ Copilotコネクタのアクセス許可が意図通りであることを確認している

• □ 誤設定時に「削除→再作成」が必要な点まで、変更管理に入れている

6. ルールは“文章だけ”でも“設定だけ”でも失敗する

山崎行政書士事務所のスタンスとして一貫しているのが、**「ルールと設定を3ヶ月で“すり合わせ”していく」**という現場目線です。

Copilot時代の社内ルール（行政書士の業務範囲で支援できる領域）も、次のように“設定と矛盾しない文章”に落とすと実務で回ります。

• 何をプロンプトに入れてよい／だめか（例：顧客名・未公開条件の扱い）

• AI生成物の扱い（社外資料に使う前の確認・承認）

• 例外運用（役員・委託先・緊急時）を、台帳で期限管理

• 取引先のセキュリティチェックシートに「説明できる」形へ整形

（AIのガバナンスと技術実装をセットで前に進める、という方向性も事務所ブログで整理されています。）