Copilot と保持ポリシー: すべての M365 管理者が知っておくべきこと

By Mirko Peters · 2026-03-17 · Updated 2026-03-24

Microsoft 365 Copilot: 保持ポリシー。Copilot とTeams のチャットおよび Copilot のやり取りに適用される Microsoft 365 の保持ポリシーについて解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft 365 の管理者であれば、コンプライアンス上のリスクがこれまでになく高まっていることはご存じでしょう。Microsoft Copilot やその他の AI 搭載ツールが M365 に組み込まれた今、保持ポリシーの管理は単なるチェックボックスの確認作業ではありません。組織を安全に保ち、コンプライアンスを遵守し、監査に備えるための中核となる作業です。

Copilot は、ドキュメントやメールだけを対象にしているわけではありません。データとの関わり方が従来とは異なるため、データのライフサイクル、ガバナンス、法的リスクに固有の課題をもたらします。何が変わったのでしょうか。大きく変わりました。Exchange や SharePoint で有効だった従来の保持コントロールも、Copilot がやり取りデータをどのように保存、再利用、削除するかに対応できるよう進化させる必要があります。これを無視すると、法的リスク、データ漏えい、規制違反にさらされるおそれがあります。

管理者は、データ保護や コンプライアンス監査のためだけでなく、シャドーデータや気づかないうちに生じるポリシーの穴といった厄介な問題を避けるためにも、Copilot の保持ポリシーを整合させる必要があります。Copilot ガバナンスの効果的な戦略と安全な技術的な実施は、強固な契約、アクセス制御、組み込みの自動コンプライアンスとともに、AI を安全に展開する助けになります。Copilot における保持が何によって異なるのか、そしてなぜそれを偶然に任せてはいけないのかを、ここで詳しく見ていきましょう。

1. 保持は、モデルの提案に影響することがあります: コードやプロンプト履歴をどこに、どれくらいの期間保持するかによって、Copilot が使用する文脈が変わり、同じプロンプトでも提案内容が変わることがあります。
2. エンタープライズの保持期間は想定より長いことがあります: Copilot に関連する組織のログやテレメトリは、一時的なデバッグのための期間だけでなく、コンプライアンス上の理由から数か月から数年にわたって保持される場合があります。
3. 個人データと組織データの分離は絶対ではありません: Copilot が個人データと組織データを分離している場合でも、保持システムやバックアップによってデータが重複して存在し、ポリシーによる制御が必要になることがあります。
4. 保持ポリシーは法的証拠開示に影響します: 保持ポリシーでデータが残されている場合、Copilot が保持するデータ(コードの断片、プロンプト、チャット履歴など)は、訴訟や監査で開示対象になる可能性があります。
5. 短い保持期間は、モデルの「学習」の可視性を低下させます: 削除までの期間が短すぎると、Copilot が特定の推奨を行った理由を監査しにくくなり、デバッグや安全性の調査が複雑になります。
6. 保持設定が攻撃の経路になることがあります: 保持設定が不適切(長すぎる、またはアクセスしやすすぎる)だと、Copilot が目にした、またはログに記録した可能性のある独自のコード、シークレット、個人情報(PII)が露出するリスクが高まります。
7. 保持は微調整(ファインチューニング)やテレメトリと相互に影響します: テレメトリや微調整のパイプラインのために保持されたデータは、ポリシーで明示的に除外しない限り、今後のモデルの動作に影響を与える可能性があります。
8. Copilot の機能によって保持ルールは異なります: コードの補完、チャットの記録、フィードバック、テレメトリは、多くの場合それぞれ別の保持スケジュールと法的な扱いに従います。
9. 保持ポリシーの選択は、ユーザーの信頼と採用に影響します: 透明性が高く制限的な保持は、機密性の高いプロジェクトで開発者が Copilot を使おうとする意欲を大きく高めます。一方、緩い保持は組織での採用を妨げます。

Microsoft Copilot における保持ポリシーの理解

保持ポリシーは、これまでも Microsoft 365 におけるコンプライアンスの基盤でしたが、Copilot はその前提を揺るがします。単に保管されているだけの従来のファイルとは異なり、Copilot はユーザーのプロンプトと AI が生成した応答ごとに、新たなやり取りデータを生成、処理、保存します。データはもはや作成されて忘れ去られるものではなく、ワークフローの能動的な一部となり、新しいデータの経路を絶えず流れ続けています。

では、何が問題なのでしょうか。Copilot はデータとの関わり方が従来の枠組みを壊すものです。メールやドキュメントに対する管理者主導のコントロールが必要なのはもちろんのこと、ユーザーのチャット履歴、AI が生成したテキスト、Copilot がまとめ上げた文脈についても必要になります。通常の保持期間のタイマーもここに適用されますが、特に生成 AI が関わる場合は、そのタイマーがいつ、どのように開始されるのかを正確に把握しておく必要があります。

これだけ変化が多いと、すべてを対象にした単一の保持ポリシーを設定するだけでは不十分です。今後は、Copilot のクロスプラットフォームな性質、扱うデータの種類、そして時期の複雑さを考慮した戦略が必要です。保持はいつ開始するのか、削除はいつ強制するのか。これを Microsoft 365 ガバナンスの新しいレイヤーと捉え、継続的な注意と計画的な構成を行ってください。

以下のセクションでは、Copilot の保持ポリシーの具体的な姿、その基本原則、そしてライフサイクル管理が開始から終了までどのように機能するかを説明します。ポリシーのギャップを先回りして把握し、見落としを防ぎ、AI を活用した環境が実際に必要なレベルで安全かつコンプライアンスに適合していることを確実にするためのガイドです。

Copilot データ保持ポリシーの基本概念

1. Copilot の保持ポリシーの定義: 保持ポリシーは、Copilot がユーザーのプロンプト、AI が生成した出力、およびやり取りのメタデータを保持する期間を定めます。コンプライアンス、セキュリティ、または組織のポリシー上の理由から、データが必要以上に長く保持されないようにするためのものです。
2. 対象となる Copilot データの種類: 一般的なデータの種類には、ユーザーのクエリ、Copilot が生成した AI の応答、処理のために収集された基礎となるコンテキスト、そして場合によっては要約または参照されたドキュメントの内容が含まれます。保持はチャットログだけでなく、これらすべてに適用されます。
3. 保持ポリシーはいつ開始するのか: 保持の期間は通常、作成時点から開始します。つまり、Copilot とのやり取りが発生した時点、または関連する非表示のメールボックスフォルダーやアプリケーションのデータリポジトリにデータが保存された時点です。このタイミングは、削除のスケジュールを設定するうえで重要です。
4. 保持ポリシーのタイミングに関する原則: Copilot の保持期間は、Exchange、SharePoint、Teams など統合先の Microsoft 365 サービスの保持期間に準じます。ただし、Copilot 固有のアーティファクトには、重複や混乱を避けるために、独自の明示的なタイミングルールが必要になる場合があります。
5. ポリシーの適用と上書き: 保持ポリシーは、保持のみ、削除のみ、または保持してから削除、のいずれかに設定できます。Copilot のデータもこれに従う必要がありますが、管理者は法的ホールドやコンプライアンス上の要件に対して上書きを適用できます。多くの場合、Purview または関連するコントロールを通じて行います。
6. 実例: 組織が財務関連のメールに対して 7 年間の法的ホールドを設けているとします。それらのメールに基づいて Copilot が生成した要約や推奨事項も、同じ保持の対象となります。Copilot が複数のワークロードのデータを扱う場合、抜け漏れを防ぐためにワークロード間の整合性が不可欠です。
7. Microsoft 365 ガバナンス全体との統合: Copilot の保持ポリシーは単独で機能するものではなく、SharePoint、OneDrive、Exchange の設定と連携して動作します。設定が食い違うとコンプライアンス上のリスクが生じるため、Copilot の機能が進化するにつれて、ポリシーを定期的に見直し、テストすることが必要です。

Copilot のデータ ライフサイクル管理プロセス

1. プロンプトの取得: ライフサイクルは、ユーザーが Copilot とやり取りした時点から始まります。クエリの入力、ドキュメントの生成、要約の依頼などがこれに該当します。その入力と、Copilot が取り込んだコンテンツはすべて、関連するワークロード(Exchange や SharePoint など)内のレコードとして取得されます。
2. データの保存: 取得後、やり取りのデータは保存されます。多くの場合、ユーザーまたはワークロードに紐づいた非表示のメールボックスフォルダーや暗号化されたデータベースに保存されます。保存場所によって保持ポリシーの適用方法や確認方法が変わるため、この点は重要です。
3. 保持期間: 保存されたら、Copilot のデータは定められた保持期間が満了するまで保持されます。これは Purview で設定でき、コンテンツの種類ごとに期間を指定できます。この期間中、データは調査や監査の対象として検索可能である一方、早期の削除からは保護されます。
4. 継続的な管理と監視: 管理者は、コンプライアンス ダッシュボード、監査ログ、および保持期限が近づいていることを知らせるタイマー ジョブを通じてライフサイクルの状態を監視できます。法的ホールドや手動による上書きが必要な場合に、対応する時間を確保できます。
5. 完全削除: 保持期間が満了し、上書きやホールドが存在しない場合、Exchange や SharePoint のタイマー ジョブなどのバックグラウンド ジョブが、Copilot のデータを完全削除の対象としてマークします。この削除は元に戻せないため、データ最小化とプライバシー コンプライアンスの維持に役立ちます。
6. ライフサイクルの可視化: Copilot のデータを、ポリシーによって制御される「川」になぞらえて考えてみてください。プロンプトの取得時に流れ込み、ストレージの島で一時的に留まり、保持期間中はそこにとどまり、最後に削除の滝へと流れ落ちます。各ステップはコンプライアンスの観点から制御されています。
7. ライフサイクルへの介入: 管理者は、重要なポイントでライフサイクルを傍受したり一時停止したりできます。具体的には、保留を適用する、ポリシーの設定ミスを修正する、コンプライアンス追跡用のレポートを生成する、といった方法があります。これにより柔軟性と確実性の両方が得られ、規制の厳しい業界では特に重要です。Microsoft 365 のガバナンスの幅広い視点については、こちらの議論もご覧ください。

Copilot のデータ ストレージとセキュリティのプラクティスの解説

データを持っていることと、それを安全に適切に管理することは別の問題です。Microsoft Copilot を環境に導入するとき、それは優秀な AI アシスタントを導入するだけではありません。これまで扱ったことがないかもしれない新しいデータ、新しいストレージの場所、新しいセキュリティ上の検討事項も同時に持ち込むことになります。

Copilot のデータは、見落とされやすい場所に存在します。たとえば、非表示のメールボックス フォルダー、アプリケーションに組み込まれたストレージ、ユーザーやワークロードに紐づいて暗号化されたデータベースなどです。データの所在地（データが地理的にどこに保存されるか）は単なる技術的な詳細ではなく、米国の法律から GDPR に至るまで、コンプライアンスへの適合性を左右する可能性があります。

セキュリティについては、Microsoft のアプローチは基本的な暗号化にとどまりません。アクセス制御、従業員によるアクセスの制限、機密データの秘密度ラベルによる厳格な保護など、複数の層で対策が組み込まれています。既定では、Copilot のコンテンツをサードパーティと共有することは認められていません。ただし、特に新しい統合ポイントが展開されるにつれて、これがどのように監査され、適用されているかは正確に把握しておく必要があります。

以降のセクションでは、Copilot のデータが物理的にどこに保存されるのか、Microsoft がどのようにデータを厳重に保護しているのか、そして従業員によるアクセス、外部共有、情報漏えいの防止について何を知っておくべきかを解説します。Copilot のアーキテクチャは従来の Exchange や SharePoint のワークロードとは異なるため、これらの違いを理解することは任意ではなく、今日のリスクとコンプライアンスを管理するすべての管理者にとって不可欠です。

Copilot のデータ ストレージの場所と地理的な考慮事項

Copilot のデータがどこに行き着くかは、後から考えればよいものではなく、コンプライアンスと規制上のリスクに対処するうえで中心的な問題です。Microsoft Copilot は、多くの場合ユーザーが直接アクセスできないように「非表示」となっている、ユーザーまたはワークロードごとのリポジトリに対話データの大部分を保存します。たとえば、Copilot が Outlook や Teams と連携する場合、対話ログと生成された出力は、通常、Exchange Online の非表示フォルダーか、ユーザー アカウントに紐づくアプリケーション固有のデータベースに保存されます。

ここではデータの所在地が重要になります。Microsoft のドキュメントによると、Copilot のデータは、元となる M365 ワークロードと同じリージョンのデータセンターに保存されます。つまり、組織の Exchange データが米国のデータセンターにあれば、Exchange に関連する Copilot のデータも同様に米国にあります。ある最近の Gartner のレポートでは、特に米国の患者情報や金融情報などの機密情報を扱う場合、企業の 67% が 2024 年における AI のコンプライアンス上の主要な懸念事項としてデータの所在地を挙げたとされています。

米国内のみのデータ所在地要件を厳格に定めている組織では、Copilot サービスについて Microsoft のジオフェンシングの約束に頼ることができる事例が見られます。ただし、意図しないリージョン間のデータ漏えいを避けるために、SharePoint、OneDrive、Teams のワークロードのデータ所在地設定は、管理者が二重に確認すべきです。Copilot の物理的な保存方法は、従来の SharePoint/OneDrive のリポジトリとは異なる場合があります。アプリケーション固有のデータはより細分化されている可能性があり、これはデータの最小化には役立つ一方で、eDiscovery を複雑にするおそれがあります。

専門家は、Microsoft のリージョン別ストレージに関する約束を毎年見直すことを推奨しています。アーキテクチャは新機能や規制の変更によって変わりうるためです。結局のところ、Copilot のデータ ストレージはテナントの設定に沿うように設計されていますが、管理者の役割は例外を検証し、監視することです。特に、国境を越えるチームや規制の厳しい業界と連携する場合はなおさらです。

機密データの保護と従業員のアクセス制御

1. Copilot コンテンツの秘密度ラベル: Microsoft は、Purview の秘密度ラベルを Copilot が生成したコンテンツと参照されたコンテンツにも拡張しています。ユーザーのプロンプトや Copilot の回答が機密データに関わる場合、秘密度ラベルによって実行できる操作が制限されます。承認されたスタッフを除き、転送、コピー、さらには読み取りアクセスもブロックされます。
2. Microsoft社内のアクセス制限: Microsoftのバックエンドエンジニアやデータセンターのスタッフは、テナントのCopilotデータへの常時アクセス権を持っていません。緊急時のアクセスは厳格な「ブレークグラス」手順に従い、監査されたうえで明示的に承認される必要があります。これにより、内部からの情報漏えいのリスクを低減します。
3. ロールベースのアクセス制御 (RBAC) と Entra ID: 管理者は、Entra ID と RBAC を使用して、組織内で誰がCopilotデータにアクセスできるかを細かく調整できます。対象はエンドユーザーのデータだけではなく、管理者の監査証跡や eDiscovery のエクスポートにも及びます。入社、役割変更、退社のタイミングでアクセスを確実に制限できます。
4. Copilotデータの暗号化: 保存時と転送時のCopilotデータはすべて、エンタープライズグレードのアルゴリズムで暗号化されます。仮に不正な第三者がコンテンツを傍受しようとしても、数学的に解読できない状態になっています。
5. 自動監査とアラート: Microsoftは、ユーザー、管理者、自動化されたプロセスのいずれによるものであっても、Copilotデータへのすべてのアクセスを記録します。そのため、調査の際に根拠として提示できる監査証跡を確保できます。きめ細かなデータセキュリティと自動化のベストプラクティスについては、Dataverse のセキュリティ戦略をご覧ください。
6. 不正な開示の防止: Copilotが生成した機密性の高い出力が誤って公開されないよう、ポリシーに基づく制限、DLP ルール、通常とは異なるアクセスパターンに対するアラートなどの制御が用意されています。機密データが仮想的な扉の外へ持ち出されることを防ぎます。

サードパーティとの共有およびアプリケーションデータの取り扱いの管理

• サードパーティとの共有はデフォルトで無効: 既定では、Copilotデータは Microsoft 365 の外部の第三者やアプリに提供されません。このポリシーにより、ユーザーのプロンプトと応答は社内にとどまり、情報漏えいのリスクを抑えられます。
• 厳格なアプリデータの取り扱い: Copilotのアプリデータは、明確なアプリケーションの境界を設けたうえで、関連する M365 サービス内にとどまります。そのため、Teams のボット、API 呼び出し、コネクタを経由して意図せず公開されることはありません。
• 外部からのアクセス要求の監査: 拡張された監査機能を使うと、許可されていない、またはリスクの高いサードパーティとの共有の試みを監視し、フラグを付けられます。SharePoint や OneDrive の高度な制御について説明した内容と同様です。詳しくはこちらをご覧ください。
• 管理者による制限: 管理者には、共有をさらに制限するためのツールがあります。新しいポリシーの発行、リスクの高いコネクタの無効化、Copilotワークロードの共有監査ログの定期的な確認などが可能です。

Copilotデータに関するコンプライアンスと規制要件

Microsoft Copilot の時代に完全なコンプライアンスを実現するには、従来のポリシーがそのまま対応できると想定するだけでは不十分です。AI やユーザーが生成したコンテンツに関する規制要件は、特に米国の公共部門、医療機関、金融機関において、今後さらに厳しくなる一方です。Copilotは新たな種類のデータをもたらすため、ポリシーの適用と監査の両方を見直す必要があります。

このセクションでは、GDPR、HIPAA などの規制基準の全体像を解説し、Copilot がどこに位置づけられ、何が変わるのかを示します。Copilot の制御を、全社的な法的保留、プライバシー保護、監査要件とどのように整合させるかも明確になります。重要なのは、ポリシーを用意することだけではありません。すべての段階で確実に実行し、監査人や規制当局に対してその実施を証明できることが求められます。

また、Purview と Defender for Cloud のようなツールが、コンプライアンスの監視と継続的なレポートをどのように一元化できるかについても取り上げます。監査が来てから慌てて対応することがないようにするためです。保持とコンプライアンスのドリフトに関するよくある落とし穴を深く知りたい場合は、Microsoft 365 のコンプライアンスドリフトに関するこのエピソードをご覧ください。目から鱗が落ちる内容です。

続きを読んで、Copilot に関係する主要な規制、Microsoft が各規制に対応するコントロールをどのようにマッピングしているか、そして法務部門や規制当局から連絡が来た際に、組織を守るために eDiscovery と監査のワークフローを強化する方法をご確認ください。

米国のコンプライアンスと国際的な規制基準への対応

• GDPR への準拠: Copilot は、EU 居住者のデータを適法に処理し、目的を明確に限定して保存し、要求に応じて削除またはエクスポートできるようにする必要があります。GDPR への準拠には、データの所在地と同意が重要です。
• 医療データに対する HIPAA の保護措置: 米国の医療機関の場合、保護対象保健情報 (PHI) を含む Copilot のやり取りは、HIPAA のセキュリティおよびプライバシー規則に従う必要があります。データの送信は暗号化され、PHI を安全に保つためにアクセス制御が適用されます。
• 米国固有のコンプライアンス管理: 連邦、州、地方の各機関では、Copilot が FedRAMP、CJIS、その他の米国固有のコンプライアンス フレームワークをサポートしている必要があります。データは国内に保存され、監査証跡とインシデント報告の要件は、Microsoft のネイティブ コントロールで満たされます。
• 国境をまたぐ複数リージョンの構成: 多国籍組織では、Copilot によって EU、米国、APAC のリージョン間でポリシーの不整合が意図せず生じないようにする必要があります。データの所在地やアクセスの競合を防ぐには、テナント構成とポリシーの見直しが重要です。
• 規制への整合に関するベスト プラクティス: Purview DLP、自動ラベル付け、RBAC、監査レポートを組み合わせて使用し、Copilot と Exchange や SharePoint などのワークロードの間にあるギャップを埋めます。この統合的なアプローチは、包括的なコンプライアンスを実現するうえで不可欠です。継続的な監視と自動修復については、Defender for Cloud によるコンプライアンス管理をご覧ください。
• ポリシーの文書化と証拠の収集: 監査に備えて、Copilot のポリシーの設計、適用、インシデント対応に関する文書を完全な形で保管してください。ポリシーは事前にテストし、グローバルの事業単位全体で責任の所在を明確に対応付けておくことが大切です。

Copilot の eDiscovery と監査機能を有効にする

• eDiscovery の統合: Copilot で生成されたコンテンツ、プロンプト、応答はコンプライアンス eDiscovery 用にインデックス化されます。これにより、法務、人事、セキュリティの各チームは、メールやチャットと同様に、ユーザーのやり取り全体を検索できます。
• リーガル ホールドのワークフロー: リーガル ホールドが設定されると、そのホールドの対象となる Copilot のデータにフラグが付けられ、他の保持設定に関係なく保存されます。コンテンツは、ホールドが解除されるまで削除されないため、法的リスクを軽減できます。
• Purview の監査証跡の管理: Copilot のやり取りはすべて監査ログで追跡でき、ユーザーの操作、管理者による変更、バックグラウンドで実行される保持と削除のジョブを記録できます。Purview Premium を利用しているチームには、保持期間の延長と詳細な追跡機能が用意されています。高度な監査の進め方に関心がある場合は、Purview Audit の詳細解説をご覧ください。
• 規制当局に対する説明可能なレポート: eDiscovery と監査ツールを使うと、法務担当者やコンプライアンス管理者が、タイムスタンプ付きで改ざんが検知できるレポートを作成できます。規制当局や裁判所からの要求に自信をもって応えるうえで欠かせない機能です。
• 予防的なコンプライアンス監視: 自動アラートと継続的なポリシーチェックにより、ポリシーからの逸脱が業務上の問題になる前に検知できます。SIEM/SOAR ツールと連携すると、フォレンジックへの備えとリアルタイムのリスク検出をさらに強化できます。
• データのライフサイクル監査の可視化: ダッシュボードとログを使うと、管理者はプロンプトから削除まで、Copilot データのライフサイクルをたどれます。保持のトリガー、ホールド、削除スケジュールを一目で確認できます。

Copilot におけるデータの削除とユーザーのオフボーディング

Copilot でデータの削除とユーザーのオフボーディングを行うには、しっかりしたワークフローを整えることが欠かせません。データは自動的には削除されず、退職したユーザーのコンテンツは容易に残ってしまいます。適切に扱わなければ、コンプライアンス上の時限爆弾や法的リスクになりかねません。Copilot も Microsoft 365 の他の機能と同様に、保持期限が来たら情報を消去し、法務部門の判断で必要な場合は保持するための、ポリシーに基づいたツールをいくつか備えています。

重要なのは、Copilot における削除の仕組みを理解することです。単にごみ箱を空にする話にとどまりません。保持の上書き、タイマー ジョブ、コンテンツのパスの見直しはすべて、コンテンツが例外なくクリーンアップされるようにするための役割を担います。ポリシーのタイミングも戦略的な検討事項になります。Copilot の成果物はいつから保持期間のカウントが始まるのか、また通常より早く削除する必要がある場合や、通常より長く保持する必要がある場合はどうすればよいのか、という点です。

オフボーディングでは、社員の退職に合わせて細部まで確実に対応する必要があります。具体的には、アクセス権の取り消し、ポリシーに沿したデータの保持または削除、そして各段階でのコンプライアンス確認です。メールボックスや非表示フォルダーを一つ見落としただけでも、監査で問題になったり、訴訟の際にさらに深刻な事態を招いたりする可能性があります。

削除ポリシー、例外設定、そして主要な Copilot のシナリオに合わせたワークフローの構成方法を順を追って解説します。また、組織を適切かつ法令に沿った状態に保ち、今後に備えるためのオフボーディングのベストプラクティスのチェックリストもご紹介します。

データ削除と保持の例外設定の構成方法

1. Copilot データの格納場所を特定する: 削除を構成する前に、Copilot のデータがどこに存在するかを把握します。非表示のメールボックスフォルダー、Teams のチャット、アプリケーションのデータベース、SharePoint と連携したファイルなどが対象です。Purview とコンプライアンスダッシュボードを使い、データの格納場所に漏れがないことを確認してください。
2. 削除専用ポリシーを設定する: 保持が不要なシナリオでは、Purview または PowerShell で削除専用ポリシーを構成します。たとえば、規制対象のデータを含まない Copilot のプロンプトを 30 日後に削除するなど、明確なトリガーと期間を定義してください。
3. 保持してから削除する制御を適用する: 規制の厳しい業界では、保持と削除を組み合わせます。必須の保持期間を設定したうえで、Copilot のデータを完全に消去する具体的な条件を明記します。保持期間が終了したときに自動的に削除を開始するタイマージョブが有効になっていることも確認してください。
4. 保持の例外設定を活用する: 法務やコンプライアンスの要件が変わった場合は、データコンテナーまたはユーザー単位でポリシーの例外を適用します。例外では、法的ホールドを使って削除を一時停止したり、特定のレコードの保持期間を延長したりできます。例外は監査ログに記録されるため、説明責任を果たす根拠になります。
5. 削除ワークフローを監視する: アクティビティログとタイマージョブのレポートを使い、Copilot のデータがいつ削除予定になっているかを追跡し、実際に削除が行われているかを検証します。レビュージョブの実行やスポット監査によってポリシーをテストし、コンプライアンスが机上の空論にならないようにしてください。
6. 固有の Copilot シナリオに合わせたカスタマイズ: 複数のワークロードと連携する Copilot 機能では、保持のギャップや競合を避けるため、関連するすべてのプラットフォーム(Exchange、Teams、SharePoint)でポリシーの整合性を確保してください。これはプラットフォームをまたぐガバナンスの重要なステップです。
7. 実例: 退職するマネージャーの Copilot のプロンプトが、機密性の高い人事関連文書を参照していたとします。まずデータの格納場所を確認し、必要な法的ホールドを適用したうえで、プロンプトを削除スケジュールに登録します。「保持してから削除」ポリシーを使ってプロセスを完結させ、組織を保護します。

ユーザーのオフボーディングと Copilot データの保持戦略

• 退職者向けのポリシーによるデータ保持: 退職した社員のアカウントに紐づく Copilot のデータに保持(または削除)ポリシーを適用し、退職者のメールボックス(非表示フォルダーを含む)に適切なフラグが付いていることを確認します。
• アクセス権の自動取り消し: オフボーディング中は Entra ID または PowerShell を使って、Copilot のワークロードへのアクセスを無効化し、削除します。これにより、誤操作や悪意のある情報漏えいの経路を確実に閉じられます。
• オフボーディング作業の監査と文書化: ポリシーの適用、データ削除、アクセス権の削除に関する詳細なログを残し、規制当局の審査に備えてプロセスを説明できるようにします。ゲストアカウントや退職者アカウントの保護のヒントについては、M365 ゲストアカウントの取り扱いに関するこちらのガイドをご覧ください。
• 法的に防御可能な記録管理: 訴訟やデータ主体のアクセス要求が発生した場合に備えて、オフボーディングのすべての手順を監査、検証、再現でき、コンプライアンスの証拠として提示できる状態にしてください。

Copilot のデータ処理と AI トレーニングでの利用

多くの管理者が気にしている疑問があります。「Enter」を押した後、Copilot のデータはどこへ行くのか。そして、それは Microsoft の AI モデルの学習に使われているのか、という点です。Copilot の技術的なデータ処理の仕組みを理解することは、コンプライアンスだけでなく、プライバシーとユーザーの信頼のためにも不可欠です。データは処理されて捨てられるだけではありません。ログファイルや非表示フォルダーに移動することもあります。さらに、適切な保護措置が講じられていない場合、ポリシーによっては将来の AI トレーニングの対象になる可能性もあります。

Microsoft は、Copilot が学習して改善できるようにすることと、ユーザーデータが誤用されたり、意図せず組織外の機械学習に利用されたりしないようにすることの間で、慎重なバランスを取っています。データの機密性、発生元、ユーザーの同意設定に応じて、追加の審査が行われる堅牢な仕組みが整えられています。

次の2つのセクションでは、Copilot がユーザー入力を取り込んでから安全に保存されるまでをどのように扱うかを解説します。あわせて、Copilot のデータの大半がデフォルトで AI 学習のプールに入らないようにするために Microsoft が適用している具体的なポリシーを示します。管理者は、責任ある AI のガードレール、オプトアウトの仕組み、そして対象の組み込みと除外のプロセスが実際の導入でどのような意味を持つのかも把握できます。

規制当局は年々、AI の透明性とモデル学習データの管理に注目を強めています。こうしたデータの流れを理解することは、単なる技術的な知識にとどまりません。プライバシーに関する問い合わせや監査が来たときに、AI の運用体制を守るうえで欠かせない要素です。

Copilot のデータ処理に関する技術的な詳細

Copilot は、入力されたテキストを取り込み、接続されたワークロードから関連するコンテキストを取得し、安全なサーバーで結果を生成することで、ユーザーのプロンプトを処理します。ユーザーのプロンプトと生成された応答は構造化されたレコードとして記録され、対象の Microsoft 365 ワークロードに応じて、非表示のメールボックス フォルダーや専用のデータベースに保存されることがよくあります。データは、不正アクセスを防ぐために、保存時と転送時の両方で暗号化されます。

保持のロジックはデータ処理パイプラインに組み込まれています。プロンプトと応答が作成されると、タイマー ジョブまたはポリシー エンジンが、組織の保持ポリシーに従って削除されるまで、そのやり取りをどれだけの期間保存するかを決定します。また、コンプライアンスの境界が尊重されるよう、Copilot 自体は承認された環境の外でデータを処理または保存しません。

AI 学習データとデータ使用制限に関するポリシー

1. AI モデル学習からのデフォルトの除外： デフォルトでは、Microsoft 365 の Copilot は、組織のユーザーデータ（プロンプト、応答、コンテキスト）を、パブリックまたは共有の AI モデルの学習に使用しません。これにより、機密性の高いビジネス情報や個人情報が、テナント外での AI モデルの改善に再利用されることを防ぎます。
2. 明示的な同意がある場合にのみ AI 学習に使用： 特別なプログラムや管理者による例外設定の場合に限り、特定の Copilot データが AI の改善の対象になることがあります。ただし、その前に、ユーザーまたは組織による明示的な同意が必要です。オプトイン バナーとポリシー設定により、このプロセスは透明性が確保され、監査可能になります。
3. 責任ある AI のガードレール： 機密としてフラグが付けられたデータ、または機密性の高いラベルが付与されたデータは、個々のユーザー設定にかかわらず、学習プールから自動的に除外されます。Microsoft は、ポリシー ロジック、技術的な制御、コンプライアンス監査を組み合わせて、これを徹底しています。
4. データ使用に関する監査と監督： 管理者は、ユーザーまたはワークロードごとに、AI 学習への組み込みログとオプトアウトの状態を確認できます。レポートは、必要に応じて、機密性の高い Copilot のやり取りが組織の境界を一度も出ていないことを、コンプライアンス担当者が証明するのに役立ちます。責任ある AI を実際の視点から見るには、AI リスク管理におけるガバナンス ボードの役割もご覧ください。
5. 動的なポリシーの調整： 秘密度ラベル、リスク分析、ライフサイクルのトリガーにより、特定の Copilot データを AI 学習の対象とするかどうかを自動的に調整できます。ユーザーの役割が変わったり、データが再分類されたりした場合でも、保持ポリシーと AI の組み込みポリシーをその場で適応させ、変化する環境でコンプライアンスを維持できます。
6. サードパーティ モデル学習からの除外： Copilot のデータは、ChatGPT Enterprise や外部の Microsoft Foundry モデルなどのサードパーティの AI プラットフォームと共有されることはありません。ただし、非常に明示的な契約上のオプトインが与えられ、記録されている場合は例外です。ほとんどの組織では、デフォルトの状態で、Copilot のデータが Microsoft の安全なクラウドの外に出ることはありません。
7. 継続的なポリシーの監視： ガバナンス ボードとコントロール プレーンのポリシーは、責任ある利用を監視し、徹底するために欠かせません。安全な AI ガバナンスに関するこのガイドで詳しく取り上げているとおり、重要なのは技術的な構成だけではありません。継続的なレビュー、運用プレーンと管理プレーンの分離、そして AI リスクの事前軽減も同じくらい重要です。

よくある質問：Microsoft 365 Copilot と保持ポリシー

Microsoft 365 Copilot と保持ポリシーの関係は何ですか?

Microsoft 365 Copilot は Microsoft 365 サービス内にあるコンテンツを利用するため、Microsoft Purview で構成した保持ポリシーと保持ラベルは、Copilot がアクセスできるコンテンツにも引き続き適用されます。Copilot に関する保持とは、基になるアイテム(メール、SharePoint ファイル、Teams チャット、Copilot のやり取りなど)が、引き続き保持および削除のルールの対象になることを意味します。保持ポリシーは Microsoft Purview ポータルで構成して適用し、コンプライアンス要件を満たすとともに、望ましくないデータ損失を防ぎます。

Copilot の保持ポリシーは、Teams チャットと Copilot のやり取りにどのように影響しますか?

Teams の保持ポリシーでは、Teams チャット、チャネル、会議の録画を対象にできます。Teams の Copilot が操作内容を生成または保存する場合、そのコンテンツには Teams 向けの同じ保持ポリシーが適用されます。ポリシーを「保持して削除」に設定している場合、Copilot 関連のコンテンツは保持期間中は保存され、保持期間の終了時に削除されます。これにより、コンプライアンスを確保しつつ、過剰な保持を減らせます。

Copilot のデータに対する保持ポリシーは、どのように作成して構成しますか?

保持ポリシーを作成するには、Microsoft Purview ポータルにアクセスし、Microsoft 365 Copilot のデータが存在する場所(Exchange、SharePoint、OneDrive、Teams)を対象に保持ポリシーを作成して構成します。保持の対象範囲には静的なポリシーのスコープを使用するか、特定の Microsoft 365 グループやメールボックスを含めます。ポリシーのアクション(保持のみ、または保持して削除)を構成し、保持期間を設定したうえで、準備が整ったらポリシーを発行します。手順の詳細は Microsoft Learn の保持に関するドキュメントを参照してください。

ポリシーを適用してから、保持が有効になるまでどのくらいかかりますか?

保持は保持ポリシーが発行された時点で機能しますが、実際の適用には時間がかかる場合があります。ポリシーがすべての場所で完全に適用されるまでに、最大 24 時間以上かかることがあります。保持期間は、ポリシーの構成によって、通常はアイテムの作成時または変更時に開始されます。そのため、保持期間をいつ開始するのか、またテナント内で複数の保持設定(ラベルとポリシー)がどのように相互作用するのかを理解しておくことが重要です。

同じ Copilot のコンテンツに複数の保持ポリシーやラベルが適用されている場合はどうなりますか?

複数の保持ポリシーが適用される場合、Microsoft 365 の保持ロジックは、コンテンツを最も長く保持する、最も制限の厳しい設定を選択します。コンテンツに保持ラベルが適用され、同じアイテムに保持ポリシーも適用されている場合は、より長く保持する、または削除を防ぐポリシーが通常優先されます。Copilot のコンテンツに対して望ましい結果が得られるよう、Microsoft Purview ポータルでポリシーの競合を確認できます。単一の保持ポリシーを使うか、複数の保持シナリオを使うかを計画するには、Microsoft 365 の保持ポリシーについてのドキュメントも参照してください。

Copilot は、保持の一時停止やリーガルホールドの対象となっているコンテンツにアクセスできますか?

はい、ユーザーにそのコンテンツへのアクセス許可がある場合、Copilot は生成や要約のためにコンテンツにアクセスできます。一方、保持の一時停止やリーガルホールドは削除を防ぎ、コンテンツを現在の場所に保持します。ホールドは保持ポリシーとは別の仕組みで、Microsoft 365 のセキュリティとコンプライアンスの管理機能の一部です。コンテンツが保持またはリーガルホールドの対象になっている場合は、コンプライアンス要件を満たすために引き続き利用可能な状態が保たれ、保持による削除アクションでは削除されません。

保持ポリシーとデータ損失防止 (DLP) は、Copilot に対してどのように連携しますか?

保持ポリシーは、コンプライアンスのルールに基づいてコンテンツを保持または削除することに重点を置きます。一方、データ損失防止とデータ損失の制御は、機密データの漏えいを防ぎます。Copilot と AI アプリでは、Microsoft 365 Copilot のデータに対する保持ポリシーと DLP ポリシーを組み合わせて、データ損失のリスクを減らします。具体的には、Teams チャットと Copilot のやり取りに対する DLP ルールを構成し、共有を制限して、Copilot の利用状況を監視します。また、Copilot Studio とガバナンスの制御を使用して、Copilot が取り込める内容を制限し、コンプライアンス要件が確実に適用されるようにします。

管理者は、Copilot の保持について学び、ポリシーの構成を確認するにはどこを参照すればよいですか?

管理者は、Microsoft Learn と Microsoft Purview ポータルで、保持ポリシー、保持と削除、保持ポリシーの場所ごとの詳細について確認する必要があります。Purview ポータルでは、保持ポリシーの作成、保持ポリシーが正しく構成されているかの確認、保持の対象となるアイテムの表示、ポリシーの展開状況の監視を行えます。Copilot に特化した情報については、Microsoft 365 Copilot のデータの取り扱い方法と、Copilot 向けの保持ポリシーが既存のコンプライアンス ワークフローとどのように統合されるかを理解するために、Microsoft 365 の Copilot および Copilot Studio のドキュメントを参照してください。