両者を同一視するのはやめましょう: M365 の保持ポリシーとレコード管理

By Mirko Peters · 2026-08-11

Microsoft 365 のコンプライアンスという、時にわかりにくい領域を掘り下げる記事へようこそ。広範なコンプライアンスルールを設定して、データは完全に安全で、ロックされ、法的にも保護されていると思い込んだことがあるなら、決して珍しいことではありません…

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

Microsoft 365 のコンプライアンスという、時にわかりにくい領域を掘り下げる記事へようこそ。広範なコンプライアンスルールを設定して、データは完全に安全で、ロックされ、法的にも保護されていると思い込んだことがあるなら、決して珍しいことではありません。しかし、Microsoft Purview が組織のデジタルフットプリントをどう扱うかを思い込みで判断すると、大きなコンプライアンス上の死角が生まれたり、最悪の場合は意図しないデータ損失につながったりします。この記事では、Microsoft 365 の保持ポリシーとレコード管理の本質的な違いを整理し、これらの仕組みが互いにどう作用するかについて実証済みの考え方を示したうえで、テナントを保護するための実践的な設計図を紹介します。

この記事は、ポッドキャストで取り上げた内容を大きく掘り下げたものです。現場の実例や技術的な知見を含む会話全体を聞きたい場合は、Microsoft 365 Retention Policies vs Records Management のエピソードをぜひお聴きください。

エピソードの概要

多くのテナントは、保持とレコード管理を互いに入れ替え可能なスイッチのように扱っています。しかし、データが突然消えたり、法的な保存期間を過ぎても残り続けたりして初めて問題に気づくのです。本エピソードでは、M365 のコンプライアンス機能が Exchange、SharePoint、OneDrive、Teams の間でどのように作用するのかを解説します。ポリシーが競合したときにどちらが優先されるのか、そして監査や eDiscovery に耐えられるエンドツーエンドのプログラムをどう設計するかを取り上げます。

対象読者

• 防御可能な保持の責任を負うコンプライアンス担当者および法務チーム
• Purview のポリシーとラベルを運用する M365 管理者またはレコード管理者
• 監査や DSAR に備えるセキュリティ／ガバナンスのリーダー
• レガシーな共有フォルダーを Microsoft 365 へ移行するプロジェクトオーナー

重要なポイント

• スイッチではなくシステムとして考える：保持ポリシー、自動適用ラベル、レコード、ホールドは互いに重なり合うため、ひとつのシステムとして設計してください。
• 優先順位が重要：より限定された適用範囲（アイテム単位のラベルやレコード）は、通常、広範な場所のポリシーを上書きします。ただし、ワークロードごとに動作は異なります。
• 保持 ≠ 変更不可：ポリシーはどれだけの期間保持するかを制御し、レコードは何を変更できるか（変更不可性と処分）を制御します。
• 隠れた競合：レガシーなポリシー、サイトポリシー、自動適用ラベルは、気づかないうちにお互いを上書きし、早期削除や無期限の保持を引き起こすことがあります。
• 監査か、ドリフトか：定期的な見直しを行わないと、ポリシーは堆積物のように積み重なり、死角や検出の失敗につながります。

テナントがよく陥る間違い

• 7 年の保持ポリシーがあれば編集や削除が防げると考えること（防げません。レコードとして宣言する必要があります）。
• 優先順位のマッピングをせずに、ワークロードごとに異なる保持期間を設定すること（例：Exchange 5 年、SharePoint 7 年、Teams 3 年）。
• .All-sites ポリシーと自動適用ラベルを多用すること → 結果が予測できなくなります。
• 誰が、なぜ、どこにルールを作成したかを文書化しないと、意図の追跡(証跡)ができなくなります。

考え方のモデル: どれが優先されるのか

1. 訴訟ホールド / eDiscovery ホールド（最も強力で、コンテンツを保全します）。
2. アイテム単位のレコード（宣言済みレコードまたは規制上のレコード）。編集や削除をロックし、処分を制御します。
3. アイテム単位の保持ラベル（期間と動作が定義されたもの）。
4. 場所ごとの保持ポリシー（サイト、メールボックス、OneDrive、Teams）。
5. ポリシーなし（ストレージの所有者の動作がそのまま適用されます）。

注意：ワークロードのエンジンは異なります（例：Teams のチャットと SharePoint のドキュメント）。必ずご自身のテナントでテストしてください。

設計図: ビジネス要件を M365 の制御にマッピングする

1. データを分類する
   • 規制対象、契約上の対象、業務上の対象、一時的なもの、に分類します。各分類について所有者と正式な記録システムを定義します。
2. 保存場所を棚卸しする
   • メールボックス、Teams（チャットやチャネル）、SharePoint のサイトやライブラリ、OneDrive を確認します。移行の状況やレガシーなホールドも記録します。
3. 保持とレコードのルールを定義する
   • 各分類について、保持期間、イベントや作成の開始時点、レコード宣言の必要性、処分の見直し、ホールドを定めます。
4. 制御手段を選ぶ
   • 影響度や規制上のリスクが高い項目（契約書、患者記録や財務記録など）にはレコードを使用します。
   • 不変性が不要な場合に、アイテム単位で管理するための保持ラベル。
   • 影響範囲が広くリスクの低い基本設定のための場所ポリシー。
5. 優先順位と例外の整理
   • 複数の制御が存在する場合にどれが適用されるかを文書化します。サンドボックスサイト、テスト用メールボックス、テストチームでパイロットを実施します。
6. 安全な範囲での自動化
   • 自動適用ラベル(機密情報の種類、キーワード、トレーニング可能な分類子)を使用し、ユーザーの負担を軽減します。
7. 廃棄ワークフロー
   • レコードの廃棄には、レビュー、破棄証明、監査証跡を必須とします。
8. 展開とトレーニング
   • サイト所有者とチャネル モデレーターに保持とレコードの違いを説明し、簡単な判断ツリーを公開します。
9. 意図の文書化
   • ポリシーやラベルごとに、所有者、適用範囲、目的、法的根拠、開始イベント、終了アクション、レビュー頻度を記録します。

運用上のガードレール

• 変更管理: 新しいポリシーやラベルごとに PRD を作成し、優先順位への影響についてはピアレビューを実施します。
• 命名規則: [LOB]-[DataClass]-[Years]-[Action]-[Scope](例: FIN-Invoices-7y-Record-SP)
• 範囲を限定したパイロット: テナント全体に展開する前に、シナリオごとにメールボックス、サイト、チーム単位で実施します。
• 例外パス: 迅速な法的保留プロセスをすべてに優先させつつ、保持ロジックを壊さないようにします。
• ユーザー UX: 既定のビューにラベルとレコードの列を表示し、所有者が競合を確認できるように教育します。

監査と将来への備え

• 四半期ごとのポリシー正常性チェック
  • 孤立したラベル、重複する適用範囲、一度も適用されていない自動ラベルルール、期限切れのテスト ポリシーを確認します。
• 机上演習
  • 人事案件、GDPR/CCPA の DSAR、訴訟ホールドをシミュレーションします。取得までの時間と完全性を評価します。
• テレメトリのダッシュボードへの集約
  • ラベル付きと未ラベルの割合、レコードとして扱われるアイテム数、廃棄保留中のアイテム数、ホールド件数、ポリシーの競合を追跡します。
• ロードマップの監視
  • Purview の更新後に再評価し、Teams や SharePoint のエンジンの動作が変わった場合はパイロットを再実施します。

よくある落とし穴と対処法

• 「無期限」の保持だがユーザーが削除・編集できる: レコードではありません。→ レコードを宣言するか、より厳格な不変性のために規制レコードを使用します。
• Teams のチャットが検出で見つからない: Teams の保持と Exchange/SharePoint のマッピングが一致していません。→ チャットとチャネルのポリシーを揃え、エクスポートをテストします。
• SharePoint では早期に削除され、メールは長期保持される: 期間が不均一です。→ 期間を統一するか、必要に応じてアイテム単位のラベルを強化します。
• 自動適用ラベルがサイトポリシーを予期せず上書きする: 優先順位の予想外の動作です。→ 自動適用の範囲を絞るか、対象ライブラリではレコードのみにします。

クイックスタート(最初の 2 週間)

1. 棚卸しとヒートマップ: リスクの高い上位 20 のサイト、チーム、メールボックスを把握し、現在のラベル、ポリシー、ホールドを記録します。
2. 重要なレコードシリーズを 1 つ選びます(例: 署名済み契約書)。ラベルをレコードとして設計し、廃棄レビューを伴う管理されたライブラリでパイロットを実施します。
3. 1 つのプロジェクトチームでチャットとドキュメントの保持を整合させます: Teams、SharePoint、Exchange の期間が意図する結果と一致していることを確認します。
4. 監査ダッシュボードを作成します: ラベル付きの割合、レコード数、廃棄保留中のアイテム、検出された競合を表示します。
5. テストユーザーでDSAR の机上演習を実施します。ギャップを記録し、拡大する前に修正します。

よくある質問

• 保持ポリシーは削除を防ぎますか? それだけでは防ぎません。アイテムがホールド中またはレコードとして宣言されていない限り、ユーザーは削除できます。
• 複数のポリシーが適用される場合、どれが優先されますか? 一般的には、ホールド > レコード > アイテム ラベル > 場所ポリシーの順です(ワークロードごとに確認してください)。
• すべてにレコードが必要ですか? いいえ。リスクの高い規制対象のシリーズに限定し、それ以外はラベルやポリシーを使用します。
• 自動適用でトレーニングを置き換えられますか? 役立ちますが、所有者はラベル、レコード、例外について理解する必要があります。

まとめ

Microsoft 365 内でコンプライアンス制御を構成することは、「設定して放置する」作業ではありません。保持ポリシーとレコード管理を同一のツールとして扱う考え方から脱却することで、高額な訴訟上の死角、意図しないデータの消去、煩雑なコンプライアンス監査から組織を守ることができます。ビジネス要件を慎重にマッピングし、優先順位の順序を尊重し、テナント全体に展開する前に必ずサンドボックス環境で構成をテストしてください。

これらの戦略をさらに深く理解し、専門家による解説を聞いて、テナントのデータを適切に保護する方法を学ぶには、関連するポッドキャストのエピソードをぜひご覧ください: Microsoft 365 Retention Policies vs Records Management。