2026年6月2日に公開または更新された公式情報を踏まえると、Microsoft Purview Records Managementの要点は、Microsoft 365上の文書やメールを「業務・法務・規制上の記録」として扱い、保持、変更制御、廃棄レビュー、削除証跡まで一貫して管理することです。単に「ファイルを消さない」機能ではなく、どの情報をレコード化し、誰が変更でき、いつ廃棄判断を行うかを設計するための仕組みです。
特に管理者が最初に確認すべきなのは、保持ラベル、ファイル計画、レコードと規制レコードの違い、廃棄レビュー、イベントベース保持、移行時の検証方法です。Microsoft Purviewの公式情報では、Records Managementは法務・規制・ビジネスクリティカルなレコードを管理し、不要になったアイテムの定期的な廃棄効率を高めるソリューションとして説明されています。(Microsoft Learn)
Microsoft Purview Records Managementで何が変わるのか
Microsoft Purview Records Managementの重要な変化は、文書やメールの管理を「保存場所単位」から「アイテム単位のライフサイクル管理」へ寄せる点にあります。
従来の運用では、「契約書フォルダーは7年保存」「退職者メールボックスは削除しない」といった場所や人に依存したルールになりがちでした。Records Managementでは、保持ラベルを使って文書やメールそのものに保持・削除・レコード宣言のルールを持たせます。保持ラベルは文書やメールなどのアイテム単位で保持・削除を制御し、Microsoft 365データのレコード管理でも使われます。(Microsoft Learn)
| 変更点 | 実務への影響 | 管理者が確認すべきこと |
|---|---|---|
| 保持ラベルで文書・メールをレコード化する | SharePoint、OneDrive、Exchangeの重要アイテムを個別に保護しやすくなる | 通常の保持ラベル、レコード、規制レコードを使い分ける |
| ファイル計画でラベルを一覧管理する | 保持期間、根拠、部門、廃棄方法を管理しやすくなる | 既存の文書管理台帳や保存年限表と対応付ける |
| イベント発生時から保持期間を開始できる | 退職、契約終了、製品終了などを起点にできる | イベント種別、資産ID、検索条件を設計する |
| 廃棄レビューを組み込める | 保存期間満了後に自動削除せず、人の判断を挟める | レビュアー、権限、監査ログ、通知文を確認する |
| Graph APIでラベルやイベントを扱える | 人事・契約管理・業務システムと連携しやすくなる | 自動化範囲、権限、テスト環境を決める |
AI/Copilot活用が進む組織ほど、元データとなる文書やメールの保持ルールは重要になります。CopilotやAIアプリの保持は文書・メールのレコード管理とは別の論点も含みますが、Microsoft PurviewではCopilot experiences、Enterprise AI apps、Other AI appsを含む保持ポリシーを作成する場合に従量課金設定が必要とされています。(Microsoft Learn)
Records Managementは「バックアップ」ではなく「証跡を残す情報統制」
Microsoft Purview Records Managementを、バックアップやアーカイブ製品の代替として理解すると失敗します。バックアップは障害復旧が主目的ですが、Records Managementは「その情報をなぜ保持し、いつ削除し、誰が判断したか」を説明できる状態にすることが目的です。
公式情報では、Records Managementの主な機能として、アイテムをレコードとしてラベル付けすること、ファイル計画で保持要件を管理すること、保持ラベルで保持・削除設定を行うこと、イベントベース保持を使うこと、廃棄レビューと削除証跡を扱うことが挙げられています。(Microsoft Learn)
Records Managementが向いている対象
Records Managementが特に効果を発揮するのは、次のような「後から説明責任が問われる情報」です。
| 対象例 | レコード管理が必要になる理由 | 設定例 |
|---|---|---|
| 契約書、注文書、請求関連文書 | 契約終了後も一定期間の保存が必要になる | 契約終了イベントから7年保持し、満了時に廃棄レビュー |
| 人事記録、退職者関連文書 | 退職日を起点に保存年限が決まることがある | 退職イベントをトリガーに保持期間を開始 |
| 監査資料、稟議資料、承認メール | 改ざん防止と証跡が重要 | レコードとして宣言し、削除や変更を制限 |
| 規制対象の業務記録 | 管理者でも削除・変更できない統制が必要な場合がある | 規制レコードを慎重に適用 |
一方で、全ファイルを無差別にレコード化する運用は避けるべきです。共同編集が必要な作業中ファイルまでレコード化すると、編集制限や削除制限によって業務が止まる可能性があります。
通常の保持ラベル、レコード、規制レコードの違い
Microsoft Purview Records Managementで最も重要なのは、保持ラベルの種類を正しく選ぶことです。特に「レコード」と「規制レコード」は名前が似ていますが、運用上の重さが大きく異なります。
| 種類 | 主な用途 | 変更・削除の制限 | 判断基準 |
|---|---|---|---|
| 通常の保持ラベル | 一般的な保存年限管理 | 保持・削除設定はあるが、レコード宣言はしない | 期限管理は必要だが、厳格な改ざん防止までは不要 |
| レコード | 業務・法務上の重要記録 | コンテンツ編集や削除が制限される | 監査や証跡が必要な重要文書・メール |
| 規制レコード | 非常に厳格な規制対応 | 適用後はグローバル管理者でもラベルを削除できない | 法令・規制・社内統制上、解除不能に近い制御が必要 |
公式の比較では、標準の保持ラベル、ロックされたレコード、ロック解除されたレコード、規制レコードごとに、編集、削除、移動、ラベル変更、ラベル削除などの許可・ブロックが整理されています。また、ExchangeアイテムではSharePointやOneDriveのようなレコードのロック解除・再ロックを前提にした動作ではなく、レコード化されたExchangeアイテムはロックされたレコード相当として扱われます。(Microsoft Learn)
規制レコードは「念のため」で使わない
規制レコードは強力ですが、取り扱いを誤ると後戻りが難しくなります。Microsoftの公式情報では、規制レコードはコンテンツに適用された後、グローバル管理者であってもラベルを削除できず、保持期間も短縮できず延長のみ可能と説明されています。また、規制レコード用の保持ラベルは自動ラベル付けポリシーではサポートされず、保持ラベルポリシーで適用する必要があります。(Microsoft Learn)
規制レコードの選択肢は既定では表示されません。利用するには、Security & Compliance PowerShellで次のコマンドを実行して表示を有効化します。これは監査対象の操作として記録されます。(Microsoft Learn)
Set-RegulatoryComplianceUI -Enabled $true実務では、規制レコードを有効化する前に、法務、監査、情報システム、業務部門で「どの文書を対象にするか」「誤適用時にどう対応するか」「誰が最終承認するか」を決めておくべきです。
管理者が最初に確認すべき設定
Microsoft Purview Records Managementを展開する前に、管理者は少なくとも次の設定を確認します。
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| ライセンスと課金 | Records Management機能、Copilot/AIアプリ保持ポリシーの要件 | E3/E5やアドオン要件を確認せず設計する |
| 権限 | Records Management管理者、閲覧専用、廃棄レビュー権限 | グローバル管理者だけで運用する |
| ファイル計画 | 保持期間、廃棄方法、根拠、部門、カテゴリ | ラベル名を場当たり的に作る |
| 保持ラベルポリシー | 公開対象、静的スコープ、適応型スコープ | SharePoint対象なのに管理単位を誤用する |
| 自動適用 | 機密情報、キーワード、検索可能プロパティ、分類器 | 既存ラベルが置き換わると誤解する |
| 廃棄レビュー | レビュアー、監査ログ、通知、承認期限 | レビュアーが内容を見られない |
| 展開タイミング | ラベル反映までの時間、Exchangeメールボックス容量 | 即時反映されないことを障害扱いする |
権限は最小権限で設計する
Records Managementの管理者には、Microsoft Purviewポータルでの適切な権限が必要です。Microsoftはグローバル管理者を最小限にすることを推奨しており、レコード管理担当者にはRecords Management admin role groupを使うことが推奨されています。この権限は、レコード宣言や廃棄管理の設定に必要なものであり、設定担当者がコンテンツ本文へアクセスする必要はありません。(Microsoft Learn)
廃棄レビューについても注意が必要です。DispositionページにアクセスするにはDisposition Managementロールが必要で、既定ではグローバル管理者にこのロールは付与されません。内容プレビューを見せる場合は、Content Explorer Content Viewerロールも検討が必要です。(Microsoft Learn)
管理単位は便利だがSharePoint向けポリシーでは注意する
Microsoft Purview Records Managementは、Microsoft Entra IDで構成された管理単位に対応しています。これにより、部門や地域ごとに管理者の範囲を分けられます。ただし、SharePointサイトに適用したい保持ラベルポリシーで管理単位を選択すると、SharePointサイトの場所を選択できなくなるため注意が必要です。(Microsoft Learn)
また、現時点では保持ラベルとイベントは管理単位をサポートしていません。CopilotおよびAIアプリの保持ポリシーも管理単位をサポートしておらず、管理単位を選んだポリシーでは非アクティブメールボックスもサポートされません。(Microsoft Learn)
ファイル計画で保持ラベルを管理する
Records Managementでは、ファイル計画を使って保持ラベルを体系的に管理できます。ファイル計画では、保持ラベルの一括作成、既存ラベル情報のエクスポート、ラベル設定の一覧確認、追加のファイル計画記述子の管理ができます。(Microsoft Learn)
ファイル計画に含めるべき項目は、単なる保存年限だけではありません。少なくとも次の情報を整理しておくと、監査や部門レビューに耐えやすくなります。
| 項目 | 例 | 実務上の意味 |
|---|---|---|
| ラベル名 | Contract-7Years-AfterEnd | 後から変更しにくいため命名規則が重要 |
| 対象部門 | 法務、経理、人事 | 管理責任者を明確にする |
| 保存起点 | 作成日、最終更新日、ラベル適用日、イベント日 | 保持期間の開始日を誤らない |
| 保持期間 | 7年、10年、無期限 | 法務・規制・業務要件と対応付ける |
| 期間満了後の処理 | 自動削除、廃棄レビュー、何もしない | 削除リスクと運用負荷を調整する |
| 根拠 | 社内規程、契約義務、規制要件 | 監査時に説明できるようにする |
保持ラベル名は保存後に変更できないため、命名規則を決めてから作成する必要があります。また、一部の設定はラベル作成後に変更できず、レコードとしてマークするオプションも後から自由に変えられるものではありません。(Microsoft Learn)
保持ラベルの公開と自動適用で確認すべきこと
保持ラベルは、作成しただけではユーザーが使えません。組織内のユーザーが文書やメールへ適用できるようにするには、保持ラベルポリシーで公開します。公式情報では、保持ラベルを利用可能にする流れは「保持ラベルを作成する」「保持ラベルポリシーで公開する」の2段階と説明されています。(Microsoft Learn)
公開後すぐに反映されるとは限りません。SharePointやOneDriveでは通常1日以内に表示されることがありますが、最大7日を見込む必要があります。Exchangeでも保持ラベルがユーザーに表示されるまで最大7日かかる場合があり、Exchangeではメールボックスに少なくとも10MBのデータが必要です。(Microsoft Learn)
自動適用は便利だが、既存ラベルを置き換えない
自動適用ポリシーを使うと、機密情報、キーワード、検索可能プロパティ、トレーニング可能な分類器などに基づいて保持ラベルを適用できます。ユーザーにすべての分類ルールを教育しなくても、Microsoft 365側で条件に一致するアイテムをラベル付けできる点が利点です。(Microsoft Learn)
ただし、自動適用ポリシーは既存の保持ラベルを置き換えません。既に保持ラベルが付いているコンテンツに対して、別の自動適用ポリシーで上書きされると考えると、移行や再分類で誤算が生じます。公式情報でも、自動適用ポリシーは既存ラベルを置き換えないため、再ラベル付けには既存ラベルの手動削除が必要とされています。(Microsoft Learn)
イベントベース保持は「退職日」「契約終了日」に強い
イベントベース保持は、作成日や最終更新日ではなく、特定のイベントが起きた日を保持期間の起点にできます。たとえば、退職者関連文書は「文書作成日から7年」ではなく「退職日から7年」としたいケースがあります。契約書も、作成日ではなく契約終了日を起点にしたいことが少なくありません。
イベントベース保持では、保持ラベルの保持設定としてイベントを使い、イベント発生時にRecords ManagementのEventsからイベントを作成します。イベントに関連付ける対象は、キーワード、検索クエリ、SharePointやOneDriveの資産IDなどで絞り込みます。イベント作成後、対象コンテンツへの同期には最大7日かかる場合があります。(Microsoft Learn)
| シナリオ | イベント例 | 条件設計の例 |
|---|---|---|
| 退職者文書 | 退職日 | ComplianceAssetID:<社員ID> |
| 契約管理 | 契約終了日 | 契約番号、取引先ID、契約種別 |
| 製品関連文書 | 製品ライフサイクル終了日 | 製品コード、プロジェクトコード |
| 監査資料 | 監査完了日 | 監査ID、年度、部門コード |
イベントベース保持では、資産IDや管理プロパティの整備が成否を分けます。ファイル名やフォルダー名だけに頼ると、移動や改名で対象判定が不安定になります。SharePoint列や業務システムのIDと対応させ、検索条件を検証してから本番化することが重要です。
廃棄レビューは「消してよいか」を人が判断する仕組み
保存期間が満了したコンテンツを自動削除するだけでは、訴訟、監査、歴史的価値、業務上の再利用価値を見落とす可能性があります。廃棄レビューを使うと、保持期間の終了時にレビュアーが確認し、削除、保持延長、別対応を判断できます。
Microsoft PurviewのDispositionページでは、Records Managementから廃棄レビューを管理し、保持期間の終わりに自動削除されたレコードのメタデータを確認できます。廃棄レビューがトリガーされると、指定されたレビュアーに通知メールが送信され、レビュアーはPurviewポータルのDispositionページから対象を確認して処理します。(Microsoft Learn)
廃棄レビューには段階的な承認も設定できます。レビュアーは最大10人の個別ユーザーまたはメール有効セキュリティグループを指定でき、最大5段階まで構成できます。Microsoft 365グループはこのレビュアー指定ではサポートされません。(Microsoft Learn)
自動承認は便利だが慎重に使う
廃棄レビューでは、7日から365日の範囲で自動承認期間を設定できます。指定期間内にレビュアーが手動対応しない場合、次のレビュー段階へ進むか、最終段階では完全削除されます。既にレビュー待ちのアイテムがある状態で自動承認を有効化すると、指定日数を超過しているアイテムが自動承認される可能性があるため、既存キューを確認してから設定するべきです。(Microsoft Learn)
移行時の注意点：ファイルサイズやハッシュだけでは不十分な場合がある
既存のファイルサーバー、文書管理システム、アーカイブからSharePointやOneDriveへレコードを移行する場合、「移行後にファイルが改ざんされていないこと」を検証したい場面があります。
Microsoftの公式情報では、SharePointにアップロードされるとファイルのメタデータが自動更新されるため、ファイルサイズや通常のファイルハッシュだけでは検証として不十分な場合があるとされています。その代わりに、vti_writevalidationtokenプロパティの値を使い、元ファイルのQuickXorHashをBase64エンコードした値と比較する方法が説明されています。(Microsoft Learn)
移行プロジェクトでは、次の順序で進めると失敗を減らせます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前棚卸し | 既存の保存年限表、文書分類、メール保存ルールを収集 | 部門ごとのローカルルールを洗い出す |
| ラベル設計 | 保持期間、保持起点、廃棄方法、レコード種別を決定 | 規制レコードを乱用しない |
| テスト移行 | 少量の文書でSharePoint/OneDriveへ移行 | メタデータ、ラベル、検索条件を確認 |
| 検証 | vti_writevalidationtokenなどで整合性を確認 | 監査・法務が求める証跡を満たすか |
| 本番展開 | 段階的に対象部門へ展開 | 反映遅延とユーザー問い合わせを想定 |
| 定期レビュー | ファイル計画をCSV出力し、部門と確認 | 期限切れラベルや不要ラベルを整理 |
開発者が確認すべきAPI連携ポイント
Records Managementは管理画面だけでなく、Microsoft Graph APIによる自動化にも対応しています。開発者や管理者は、保持ラベルの管理、イベントベース保持のトリガー、ファイル計画記述子の管理などをAPIで扱えます。Microsoft GraphのRecords Management APIは、法的義務やコンプライアンス規制に対応するための保持・削除管理を支援し、定期的な廃棄を効率化するものと説明されています。(Microsoft Learn)
実務で有効な連携例は次のとおりです。
| 連携元 | 自動化できること | 注意点 |
|---|---|---|
| 人事システム | 退職イベントを作成し、退職者文書の保持期間を開始 | 社員IDと資産IDの対応が必須 |
| 契約管理システム | 契約終了日をイベントとして登録 | 契約番号の表記ゆれを防ぐ |
| 文書管理ワークフロー | 承認完了後に保持ラベルを適用 | 作業中ファイルへの誤適用を避ける |
| 監査・証跡システム | ラベル情報やイベント情報を収集 | API権限と監査ログの保管方針を確認 |
Graph APIでは、退職、契約終了、会計年度終了などのイベントを契機に保持期間を開始するシナリオが示されています。たとえば退職時に社員IDをイベントクエリとして登録し、そのIDに紐づく保持ラベル付き文書の保持期間を開始できます。(Microsoft Learn)
展開時に失敗しやすいポイント
Microsoft Purview Records Managementの導入でよくある失敗は、機能の有効化よりも運用設計の不足です。
すべてをレコード化して業務を止める
レコード化すると編集や削除が制限されます。特に共同編集中のファイル、ドラフト文書、日常的に更新される台帳に強い制限をかけると、現場の作業が止まります。まずは「最終版」「承認済み」「契約締結済み」など、状態が明確な文書から対象にするのが現実的です。
規制レコードを通常レコードの延長で使う
規制レコードは解除不能に近い強力な制御です。グローバル管理者でもラベルを削除できないため、テスト環境や限定スコープで十分に検証してから使う必要があります。(Microsoft Learn)
反映遅延を考慮しない
保持ラベルの公開、イベント同期、廃棄設定変更などは即時反映されないことがあります。SharePoint、OneDrive、Exchangeへのラベル反映やイベント同期には最大7日を見込むべき場面があります。(Microsoft Learn)
エンドユーザー向け説明を用意しない
保持ポリシーは裏側で動くことが多い一方、保持ラベルはMicrosoft 365アプリ上に表示されます。Microsoft公式情報でも、保持ラベルにはUI上の存在感があるため、本番展開前にユーザーとヘルプデスク向けのガイダンスを用意することが推奨されています。(Microsoft Learn)
導入判断の実務基準
Records Managementを導入すべきか迷う場合は、次の基準で判断します。
| 質問 | Yesなら検討すべき設定 |
|---|---|
| 法務・監査・規制上、削除してはいけない文書やメールがあるか | レコード保持ラベル |
| 保存期間満了後に人の確認を挟みたいか | 廃棄レビュー |
| 退職日、契約終了日、製品終了日を起点にしたいか | イベントベース保持 |
| 文書分類や保存年限が部門ごとにバラバラか | ファイル計画 |
| 既存の保存年限表をMicrosoft 365へ移行したいか | CSVインポートとラベル設計 |
| 人事・契約管理システムと連携したいか | Microsoft Graph API |
最初から全社一括展開を狙うより、法務文書、人事記録、契約書、監査資料など、対象と責任者が明確な領域から始めるほうが成功しやすくなります。
管理者が次に行うべきチェックリスト
Microsoft Purview Records Managementを導入・見直しする場合は、次の順序で進めてください。
| 順序 | 作業 | 完了条件 |
|---|---|---|
| 1 | 重要文書・重要メールの棚卸し | 対象、保存期間、責任部門が一覧化されている |
| 2 | 通常ラベル、レコード、規制レコードを分類 | 規制レコードの適用対象が限定されている |
| 3 | ファイル計画を作成 | ラベル名、保持起点、廃棄方法、根拠が整理されている |
| 4 | 権限とロールを設定 | Records Management管理者、閲覧専用、廃棄レビュアーが分離されている |
| 5 | テスト用サイト・メールボックスで検証 | ラベル反映、編集制限、削除制限、監査ログを確認済み |
| 6 | 自動適用または手動適用を設計 | 条件、例外、既存ラベルの扱いが明確 |
| 7 | ユーザー向けガイドを作成 | どのラベルをいつ使うか説明できる |
| 8 | 本番展開後に定期レビュー | ファイル計画のCSV出力と部門レビューを実施 |
Microsoft Purview Records Managementは、設定項目だけを見ると複雑ですが、設計の軸はシンプルです。重要なのは、「何を記録として残すのか」「いつまで保持するのか」「誰が廃棄を判断するのか」「その判断を後から説明できるのか」の4点です。まずは重要文書と重要メールを棚卸しし、通常の保持ラベルで足りるもの、レコード化すべきもの、規制レコードにすべきものを分けるところから始めましょう。
コメント