Microsoft Purview Data Lifecycle Managementとは？保持と削除を設計する

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。2026年9月時点のMicrosoft LearnとMicrosoft Purviewサービス説明を確認し、保持・削除、E3/E5/Purview Suiteの境界、AIロケーションの課金注意を整理しています。

検証ステータス：📘 Microsoft公式情報確認済み・実機未確認

Microsoft Purview Data Lifecycle Management（DLM）は、Microsoft 365上の情報を「何を、なぜ、いつまで残し、最後にどうするか」というライフサイクルで管理する仕組みです。Exchange、SharePoint、OneDrive、Teamsなどに保持ポリシーや保持ラベルを適用し、利用者がファイルを削除しても保持要件を満たせるようにします。

最初に覚える4語

保持は「バックアップ」とは違います。バックアップは復旧のためのコピー、Retentionはコンプライアンス上の保持・削除ルールです。

E3 / E5 / Purview Suiteの考え方

Microsoft 365 E3でも、基本的な保持ポリシーや保持ラベルの作成・公開などCore Purviewの機能を利用できます。一方、イベントを起点にした保持、Disposition review、record / regulatory record、Adaptive policy scope、自動適用など高度なInformation Protection and Governance / Records Management領域は、Microsoft 365 E5、Microsoft Purview Suite、または対応する追加ライセンスが必要になる機能があります。

したがって「E3ならDLM不可」「E5ならPurviewの全機能が無条件で使える」という二択ではありません。使う機能と、その機能から利益を受けるユーザー単位で最新のPurview service descriptionを確認するのが安全です。

Microsoft 365 E7は2026年5月1日に一般提供され、E5を包含する上位SKUです。図鑑ではE3/E5を主軸にしますが、現在の製品選定ではE7も存在する点に注意してください。

Records Managementとの違い

flowchart LR
    A[Microsoft 365 data] --> B[Data Lifecycle Management]
    B --> C[保持ポリシー]
    B --> D[保持ラベル]
    D --> E[Records Management]
    E --> F[Record / Regulatory record]
    E --> G[File plan]
    E --> H[Disposition review]

DLMは日常データを含む情報全体の保持・削除を広く扱います。Records Managementは、法務・規制・業務上の正式な記録に対し、レコード宣言、File plan、Disposition reviewなど、より厳格な統制を追加する領域です。

保持と削除が競合したら

Purviewでは複数の保持設定が同じコンテンツへ作用することがあります。そのため「ユーザーが削除した＝すぐ消える」とは限りません。Microsoftのretention principlesに従い、保持が必要な期間はコンテンツを保護し、保持義務を満たした後に削除ルールを評価します。

sequenceDiagram
    participant U as 利用者
    participant M as Microsoft 365
    participant P as Purview Retention
    U->>M: 文書を削除
    M->>P: 適用中の保持設定を確認
    alt 保持期間中
      P-->>M: 保持を優先
      M-->>U: 通常画面からは削除済みに見える場合あり
    else 保持義務なし/終了
      P-->>M: 削除条件を評価
    end

まず試す前に「削除しない設計」を紙で作る

最初から本番ポリシーを作らず、対象と根拠を書き出します。

対象       : 検証用SharePointサイト
データ種別 : 一般文書
保持期間   : 1年（設計例。実際は規程・法務要件から決める）
期間後     : まずは削除せずレビュー
根拠       : 社内検証
所有者     : 検証担当

ここを見る

「対象」「期間」「期間後の動作」「根拠」「責任者」を第三者へ説明できれば設計段階の成功です。

1か所変えてみる

対象をSharePointからOneDriveへ変えた場合を考えます。個人領域では退職・アカウント削除などのライフサイクルも関係するため、同じ保持要件をそのままコピーしてよいとは限らないことが分かります。

一般利用者・事務職・情シスでは見る場所が違う

• 一般利用者：削除操作と組織の保持義務は別物だと理解する。

• 事務職・文書管理担当：保存年限をツールから決めず、法令・契約・社内規程から根拠を整理する。

• 情シス / コンプライアンス管理者：対象ロケーション、スコープ、ライセンス、競合する保持設定、監査と変更管理を確認する。

Copilot / AIロケーションは課金モデルも確認する

Microsoftの現行Records Management/DLM関連資料では、Microsoft Copilot experiences、Enterprise AI apps、Other AI appsを含む保持ポリシーの作成にpay-as-you-go billingの設定が必要になるシナリオがあります。Microsoft 365 Copilot interactions自体には、その説明上の保持処理料金はありません。

AI関連データまで保持対象へ広げる場合は、従来のE3/E5だけで判断せず、対象ロケーションとPurviewの課金モデルを導入時点で確認してください。

管理者が確認する点

• Exchange / SharePoint / OneDrive / Teamsなど対象場所

• 保持ポリシーと保持ラベルの使い分け

• Static / Adaptive scopeのどちらを使うか

• E3/E5/Purview Suite/対応Add-onの機能別ライセンス

• 削除と保持が競合した場合のretention principles

• AIロケーションを含む場合のpay-as-you-go条件

• Preservation Lockなど後戻りしにくい設定を安易に使わないこと

• テスト対象を本番全体へ広げないこと

Microsoft公式情報

• Data lifecycle and records management overview

• Learn about retention policies and retention labels

• Get started with records management

• Microsoft Purview service description

• E3 / E5 / E7 feature overview

Data Lifecycle Managementは設定画面から始めるより、「何を、なぜ、いつまで残し、最後にどうするか」を業務側と決めてから実装する方が安全です。