要点（先に結論）
法人向けに正しく契約されたMicrosoft 365 Copilotは、入力したプロンプトや応答を基盤モデルの学習に使わず、データをテナントの外に出さない。だから企業が「顧客情報をAIに入れるな」と禁ずる本当の理由は”漏洩”ではなく、(1) データが自社テナントに残るという「所在」の問題、(2) 顧客と顧客の間に壁を立てる情報バリアの発想、(3) 生成物が社外へ拡散するリスク——この三つである。さらに多くの「禁止」は技術的な必然ではなく、本来はMicrosoft Purviewのようなプラットフォーム統制で建てるべき壁を、ライセンスや設計が追いつかないままプロンプトの指示文で代用した結果にすぎない。
社内にCopilotのような生成AIが導入されたのに、いざ使おうとすると「顧客名を書くな」「案件の要件を入れるな」「機密が混じるなら出力させるな」と縛られる——そんな経験をした人は多いはずだ。提案書を要約させたくても、肝心の中身を打ち込めない。便利なはずのツールが、現場では一番使いたい場面で手錠をかけられている。この不便さは、たいてい「AIに入れたら漏れるから」で説明される。だが、その理解は半分が誤解だ。理由はもっと構造的なところにある。
「入れたら漏れる・学習される」は、半分は誤解
結論から言えば、適切に契約された法人向けCopilotでは、入力が外部に漏れることも、AIの学習に使われることもない。エンタープライズデータ保護（EDP）や商用データ保護と呼ばれる仕組みが効いているからだ。Microsoftの公開ドキュメントによれば、入力したプロンプトも生成された応答も、Microsoft Graph経由で参照したデータも、基盤モデルの学習には使われない。データは組織のテナント境界の内側で処理されて外部に保存されず、テナント間は論理的に分離され、Microsoft 365 Copilotでは人の目による不正利用監視（コンテンツレビュー）もオプトアウトされている。
つまり「顧客名を入れたらMicrosoftに筒抜けになる」「入力がAIの賢さの肥やしにされる」という類の心配は、適切に構成された法人環境ではほぼ起きない。だとすれば、禁止の根拠を「漏れるから」だけに求めるのは筋が悪い。漏れないのに、なぜ禁ずるのか。理由は三つの層に分かれている。
本当の理由①：データが「誰のテナントに残るか」
ひとつ目の理由は、論点が「Microsoftから安全か」ではなく「データが誰のテナントに残るか」だからだ。EDPが保証するのは前者まで。だが顧客データを入力した瞬間、その情報は入力した会社（たとえば受託側のベンダー）自身のテナントの中に在ることになる。監査や電子情報開示のためにログとして保存され、それを管理するのは自社の管理者であって、データの本来の持ち主である顧客ではない。
受託開発やコンサルのように他社のデータを預かる立場では、ここが契約上の核心になる。問われているのは「Microsoftに漏れるか」ではなく、「顧客の機密情報が、契約で許された範囲を超えて第三者（自社）のクラウドに常駐していいのか」だ。EDPはこの問いには一切答えていない。守る主語が違うのである。
本当の理由②：顧客と顧客の間の「壁」
二つ目の理由は、競合する顧客同士の情報を混ぜないための「壁」である。IT業界には昔から、複数の顧客を同時に担当するとき、チーム間に情報の壁を立てる慣行がある。A社の情報がB社の担当に流れないよう、アクセスも保管も分離する——いわゆる倫理の壁（Chinese wall）だ。
全社共通の生成AIは、この観点では厄介な存在になる。全チームが同じひとつのツールに合流する「共有地」だからだ。共有地にはチームごとの仕切りがない。だから「庭の中で仕切る」のではなく「共有地そのものを顧客データフリーに保つ」方針が選ばれ、結果として一律の「顧客情報を入れるな」になる。壁の置き場所が、人と人の間（従来）から、ツールという共有面の入口（AI時代）へ移ったとも言える。
しかも生成AIは、ただの保管庫ではなく、複数の文脈を混ぜて新しい成果物を合成して吐き出す。漏洩面は従来のアクセス制御より一段広い。壁が重く感じられるのは、ツールが「生成器」だからだ。
本当の理由③：出力が独り歩きする
三つ目の理由は、生成された成果物が独り歩きすることだ。入力がテナント内で安全でも、出力はそこに留まらない。顧客名入りのきれいな要約は、メールに貼られ、資料に流れ込み、共有ドライブに置かれ、やがて社外にも出ていく。入口で固有名詞を抜いておけば、境界の外へ動いていく成果物に顧客情報が乗らない。入力制限は、実は出力の拡散対策でもある。
なぜ「プロンプトで禁止」という大雑把な形になるのか
理由がこれほど明確なら、なぜ統制は「プロンプトに禁止事項を書き込む」「機密が含まれたら処理を止めさせる」といった、ユーザーに負担を強いる粗い形をとるのか。答えは、統制を本来あるべき層に置けていないからだ。
この種の制御は、AIに指示文で頼むものではなく、プラットフォームの層に作るものだ。Microsoftには Purview というデータガバナンスの統合基盤があり、秘密度ラベル（データに機密区分を貼り、暗号化を付随させる）、DLP（機密パターンの入力・送信を仕組みで止める）、情報バリア（顧客チーム同士をセグメントで遮断する、まさに倫理の壁のデジタル版）といった機能が揃っている。Microsoft 365 Copilotはユーザーのアクセス権限を尊重し、秘密度ラベルを継承して動くため、ここで壁を設計すれば、ツール自身が壁を守ってくれる。
それでも現場が「指示文での禁止」に頼ってしまうのには、二つの現実がある。ひとつは、ネイティブの統制が最新のAI機能のすべてを覆いきれていないこと。Microsoft自身、Teamsのチャネルエージェントでは情報バリアがサポートされず、バリアを越えて情報が返りうると注意喚起している。もうひとつは、Purviewの高度な機能の多くが上位ライセンス帯に置かれていること。たとえば情報バリアや、クライアント／サービス側での自動の秘密度ラベル付けは、E5やE5 Complianceといった上位ライセンス（または相当のアドオン）を前提にしており、E3どまりの組織では使えない機能が少なくない。壁を建てる「資材」を、組織が持っていないことがあるのだ。
つまり「プロンプトでの禁止」は、しばしば技術的な必然ではなく、本来プラットフォームに建てるべき統制を、ライセンスや構築が追いつかないまま、ユーザーの行動規範という「当て木」で代用した結果なのだ。当て木は、言い回しを変えれば抜けられる程度の強度しかなく、その割に摩擦だけは最大になる。
結論：禁止は「怠慢」でも「過剰」でもなく、未完成な統制の影
現場のあの不便さは、ガバナンス意識の低さでも、理解不足の過剰防衛でもない（少なくとも、そうとは限らない）。多くの場合それは、プラットフォームにまだ建てられていない壁の「影」が、ルールという形で現場に落ちているだけだ。
そう捉えると、打ち手も変わる。利用者として禁止ルールと戦うより、問うべきは二つ。第一に、その作業は本来どこでやるべきか——顧客データを使うAI作業なら、自社の共有環境ではなく顧客自身の環境（顧客のテナント）に置くのが、契約的にも技術的にも一番きれいに収まる。第二に、統制は指示文ではなく、プラットフォーム層（ラベル・DLP・情報バリア）に寄せられているか。
「AIに顧客情報を入れるな」という一見不合理なルールの裏には、データの所在と顧客間の壁という、生成AI以前から続くまっとうな論理がある。そして禁止の粗さは、その論理をツールにまだ実装しきれていないことの裏返しだ。不便の正体が分かれば、抗議する先も、設計し直す先も見えてくる。
よくある質問（FAQ）
Q. Microsoft 365 Copilotに入力した内容は、AIの学習に使われますか？ A. 法人向けに正しく契約された環境では使われません。Microsoftの公開ドキュメントによれば、プロンプト・応答・Microsoft Graph経由で参照したデータは、基盤モデルの学習には用いられません。
Q. では、顧客情報をCopilotに入れても社外に漏れないのですか？ A. Microsoftの外に出るかという意味ではテナント境界の内側に留まります。ただし入力した情報は「自社のテナント」に残り、自社の管理者の管理下に置かれます。受託で他社データを預かる立場では、漏洩よりも「顧客データを自社クラウドに常駐させてよいか」という契約・データ所在の問題が核心になります。
Q. 情報バリアとは何ですか？ A. Microsoft Purviewの機能で、特定のグループ間の双方向のやりとりを制限・遮断する仕組みです。競合する顧客チーム同士を分離する「倫理の壁（Chinese wall）」のデジタル版にあたります。
Q. なぜ仕組みで防がず、プロンプトで禁止するだけなのですか？ A. 本来は秘密度ラベル・DLP・情報バリアといったプラットフォーム統制で防ぐべきですが、これらは最新のAI機能の一部を覆いきれていなかったり、E5などの上位ライセンスを前提とするため、組織が導入しきれていない場合があります。その不足を、プロンプトの指示文で暫定的に代用しているのが実態です。
Q. 結局、顧客データでAIを活用したいときはどうすべきですか？ A. 顧客データを使うAI作業は、自社の共有環境ではなく顧客自身の環境（顧客のテナント）で行うのが、契約面でも技術面でも整合的です。あわせて、統制を指示文ではなくプラットフォーム層に寄せることが望ましい方向です。
出典
- Microsoft 365 Copilot のエンタープライズ データ保護（EDP）｜Microsoft Learn
- Microsoft 365 Copilot のデータ、プライバシー、セキュリティ｜Microsoft Learn
- 情報バリア（Microsoft Purview）｜Microsoft Learn
- Teams での Microsoft 365 Copilot とチャネル エージェントの管理に関する考慮事項｜Microsoft Learn
本記事は一般的な業界構造と上記の公開情報に基づく解説であり、特定の企業の内部方針を記述したものではない。
