その社内規則、Copilotを禁止していますか？｜「外部AIへの機微情報投入禁止」とEDPの読み合わせ方ARTICLE

ARTICLEM365 Copilot導入

M365 Copilot導入2026.08.31

「当社の規則では、外部AIへの機密情報の入力が禁止されています。だからCopilotは使えません」

Microsoft 365 Copilot の導入検討で、実際に最も多く出会う"壁"がこれです。生成AIブームの初期に急いで作られた社内規則には、「外部AIサービスへの機微情報・顧客情報の投入を禁止する」といった条項が入っていることが多く、この文言が Copilot まで一律に止めてしまっています。

しかし、この結論は多くの場合、規程の文言と Copilot の仕組みを突き合わせないまま出されています。本記事では、規程の禁止条項が本当に恐れているものを分解し、Microsoft 365 Copilot のエンタープライズデータ保護（EDP: Enterprise Data Protection）の保護範囲と対応づけて、利用可否を整理する実務手順を解説します。

なお本記事は一般的な整理の枠組みを示すものであり、最終的な判断は自社の規程の文言・契約条件・法務確認に基づいて行ってください。

よくある膠着 ―「禁止されているので使えない」の内訳

この膠着には典型的な構図があります。

  • 規則を作った時点で想定していたのは、個人アカウントで使う無償のチャットAI（入力内容が事業者側に渡り、学習に使われ得るもの）
  • その後に登場した Copilot のようなテナント内で完結する企業向けAIは、想定に入っていない
  • 規則の文言は「外部AI」「機微情報の投入」と広く書かれているため、読みようによっては Copilot も該当してしまう
  • 誰も判断の責任を取りたくないため、「グレーなら禁止」で止まる

つまり問題は「Copilotが危険かどうか」ではなく、規程の文言が新しい実態に追いついていないことにあります。であれば、やるべきは文言と実態の読み合わせです。

Step 1：禁止条項を分解する ― その規則は何を恐れているか

「外部AIへの機微情報投入禁止」という条項が守ろうとしているものを分解すると、懸念は次の4つに集約されます。

  1. 第三者への流出 ―― 入力したデータがAI事業者や他社に渡ってしまうのではないか
  2. 学習への利用 ―― 入力内容がAIモデルの学習に使われ、他社への回答に混ざって出てくるのではないか
  3. アクセス統制の喪失 ―― 社内で権限管理していた情報が、AIを経由して権限のない人に見えてしまうのではないか
  4. 追跡不能 ―― 誰が何を入力したか分からず、事故時に調査・説明ができないのではないか

自社の規程を読むときは、条文をこの4つの懸念に翻訳してください。「外部AI」という言葉自体が問題なのではなく、この4つが起きる形態のAI利用が問題なのだ、と整理できれば、判断基準が明確になります。

Step 2：EDPの保護範囲を確認する

Microsoft 365 Copilot（および M365 アカウントでサインインした Copilot Chat）には、エンタープライズデータ保護（EDP）が適用されます。ポイントは5つです。

  • 契約境界内での処理 ―― プロンプト（入力）と応答は自社のMicrosoft 365テナントの契約条件の下で扱われ、SharePointのファイルやExchangeのメールと同じ契約的保護を受けます
  • 暗号化 ―― データは保存時・転送時ともに暗号化されます
  • テナント間の分離 ―― 自社のデータが他社のテナントと混ざることはありません
  • 基盤モデルの学習に使われない ―― プロンプトと応答が、基盤となるAIモデルの学習に利用されることはありません
  • 権限の継承 ―― Copilotはユーザー本人が閲覧権限を持つデータしか参照・出力しません。また利用は監査ログに記録され、Microsoft Purview による追跡・eDiscoveryの対象にできます

Step 3：懸念と保護範囲を対応づける

Step 1 の4つの懸念に、Step 2 の保護範囲を当てはめます。

  1. 第三者への流出 → プロンプト・応答はテナントの契約境界内に留まります。無償チャットAIへの「貼り付け」とは、データの置かれる場所が契約上まったく異なります
  2. 学習への利用 → EDPの下では基盤モデルの学習に使われません
  3. アクセス統制の喪失 → 既存のアクセス権限がそのまま継承されます。閲覧権限のないデータをAIが引用することは構造的に起きません
  4. 追跡不能 → 監査ログとPurviewで、誰がいつ何に使ったかを追跡できます

この対応づけができると、次の整理が可能になります。

当社規程が禁止する「外部AIへの機微情報の投入」とは、入力データが契約的保護の外に出て、第三者提供・学習利用され得る形態を指す。エンタープライズデータ保護が適用された Microsoft 365 Copilot の利用は、データが自社テナントの契約境界内で処理されるため、この「外部への投入」には該当しないと整理する。

「Copilotは規則違反ではない」と主張するのではなく、規則が守ろうとしているものをCopilotの仕組みが満たしていることを示す——これが通る説明の型です。

Step 4：ただし、この整理には条件がある

ここまでの整理は、Microsoftが担保する層の話です。見落としてはいけないのは、EDPが守ってくれない領域が自社側に残ることです。

最大の論点は「権限の継承」の裏返しです。Copilotはユーザーが開ける情報をすべて探しに行くため、SharePointの共有設定がずさんなら、そのずさんさがそのままAIの回答に反映されます。「全社共有」に置かれたままの人事資料や役員会議事録は、権限上は"全員が閲覧可能"であり、Copilotは正しくそれを引用します。これはEDPの欠陥ではなく、自社の権限設計の問題です。

つまり Step 3 の整理が実務として成立するのは、次の整備が伴っているときです。

  • SharePoint/OneDrive のアクセス権の棚卸しと過剰共有の是正
  • Microsoft Purview による秘密度ラベル等の機密区分の設計
  • 利用ガイドラインの策定と利用者教育
  • 監査ログを実際に見る運用の設計

「Microsoftが守る層」と「自社が設計する層」の二層構造で捉え、後者の整備計画とセットで提示することが、法務・経営の納得を得る条件になります。

Step 5：法務・経営への説明ドキュメントを作る

社内説明用のドキュメントは、次の構成をおすすめします。A4で2〜3枚に収まります。

  1. 規程の該当条文の引用と、条文が防ごうとしている4つの懸念への分解
  2. 懸念とEDPの保護範囲の対応表（懸念ごとに、何によって担保されるかを1行ずつ）
  3. 自社側で整備する事項と時期（権限棚卸し・ラベル設計・ガイドライン・教育）
  4. 利用範囲の段階設計 ―― まず機微情報を含まない業務（議事録要約・文書ドラフト・メール下書きなど）から開始し、整備の進捗に応じて範囲を広げる。拡大の判断は都度、会社として行う
  5. 規程改定の提案（次項）

この「段階設計」が重要です。整理がついても、初日から機微情報を扱う業務に使う必要はありません。非機微業務で開始 → 整備 → 段階拡大という順序を示すことで、承認のハードルは大きく下がります。

Step 6：規程の改定 ― グレーを残さない

読み合わせで運用を始められても、規程の文言がそのままでは、判断が属人的なままです。最後に規程自体を改定し、明文化します。盛り込むべきは次の観点です。

  • 「外部AI」の定義を、データの取り扱い条件（契約的保護の有無、学習利用の有無、テナント内処理か否か）で定義し直す
  • 会社が承認したAIサービスのリスト管理方式にする（サービス名を条文に直書きしない。改定が追いつかなくなります）
  • 個人アカウントでの業務利用の禁止を明記する
  • 機微情報の利用可否は秘密度ラベル等の機密区分と紐づけて規定する
  • 新しいAIサービスを使いたい場合の申請・審査フローを定める

なお、MicrosoftのサービスやEDPの仕様は変化し続けます。整理した内容は「作成時点の仕様に基づく」ことを明記し、年1回以上の見直しをルール化しておくことをおすすめします。

まとめ

  • 「規則で禁止されているのでCopilotは使えない」の多くは、規程の文言が実態に追いついていないだけです
  • 禁止条項を4つの懸念（流出・学習利用・統制喪失・追跡不能）に分解し、EDPの保護範囲と対応づければ、「外部への投入には当たらない」という整理が可能です
  • ただしこの整理は、自社側の整備（権限・ラベル・ガイドライン）が伴って初めて成立します
  • 最後は規程を改定し、グレーゾーンを残さないことが重要です

Copilot導入の全体像は第1回：非IT企業のMicrosoft 365 Copilot導入ロードマップで解説しています。

K.S.Rogers では、規程とEDPの読み合わせ整理、経営・法務向け説明資料の作成、SharePoint・Purviewの整備からガイドライン策定までを一貫して支援しています。「規則の壁」で止まっている方は、ぜひ一度ご相談ください。

← 記事一覧へ戻る