Microsoft PurviewでSharePointとOneDriveの保持設定を見直す場合、最初に押さえるべき結論は「保持ポリシーはサイトやアカウント単位、保持ラベルはファイルやフォルダーなどのアイテム単位で使い分ける」という点です。特にSharePoint Onlineの旧来の情報管理ポリシーやインプレースレコード管理を使っている環境では、Microsoft Purview Data Lifecycle ManagementやRecords Managementへの移行方針を早めに確認する必要があります。
Microsoft Learnの「Learn about retention for SharePoint and OneDrive」は、Microsoft 365全体の保持機能の中でも、SharePoint、OneDrive、SharePoint Embedded、Loop、Copilot Pages、クラウド添付ファイル、OneNote、Microsoft 365 Archiveに関わる保持・削除の動作を補足する公式情報です。なお、参照した公式ページでは最終更新日が2025年9月22日と表示されているため、本記事では2026年5月21日時点で管理者が確認すべき実務上のポイントとして整理します。(Microsoft Learn)
Microsoft PurviewのSharePoint／OneDrive保持で押さえるべき全体像
Microsoft Purviewの保持機能は、組織のデータを「必要な期間は保持し、不要になったら削除する」ための仕組みです。SharePointとOneDriveでは、ドキュメントライブラリ内のファイル、OneDrive上のファイル、SharePoint Embeddedに保存される一部のアプリデータなどが対象になります。Microsoftの公式情報では、SharePointおよびOneDriveサイトに保存されるすべてのファイルは、保持ポリシーまたは保持ラベルの適用によって保持できると説明されています。(Microsoft Learn)
実務では、次のように考えると判断しやすくなります。
| 判断ポイント | 保持ポリシー | 保持ラベル |
|---|---|---|
| 主な適用単位 | SharePointサイト、OneDriveアカウント、Microsoft 365グループなど | ファイル、フォルダー、ドキュメント、メールなどのアイテム |
| 向いている用途 | サイト全体、部門全体、全社共通の保持ルール | 契約書、請求書、規程文書など、種類ごとに保持期間が異なる文書 |
| ユーザー操作 | 基本的に管理者が設定し、ユーザーは意識しない | 手動適用、自動適用、既定ラベルなどで運用可能 |
| 移動時の考え方 | コンテナー単位の設定。移動先には保持設定がそのまま付いて回らない場合がある | Microsoft 365テナント内で移動してもラベルの保持設定が付いて回る |
| レコード管理 | 主用途ではない | レコード、規制レコードとしての管理に対応 |
Microsoftは、サイトやメールボックス単位で同じ保持設定を割り当てる場合は保持ポリシー、アイテム単位で異なる保持設定を割り当てる場合は保持ラベルを使う考え方を示しています。たとえば「経理サイト内のすべての文書を5年間保持する」なら保持ポリシー、「契約書は10年、見積書は3年、社内メモは1年」といった分類が必要なら保持ラベルが適しています。(Microsoft Learn)
今回の公式情報で特に重要な変更点・確認ポイント
このトピックで管理者が注目すべき点は、単に「保持できる」という説明ではありません。SharePointとOneDriveでは、保持対象、削除経路、バージョン、アーカイブサイト、クラウド添付ファイルの扱いが他のワークロードと異なります。
SharePoint Embedded、Loop、Copilot Pagesも保持設計に含める必要がある
SharePointとOneDriveの保持対象には、通常のドキュメントライブラリ内のファイルだけでなく、Microsoft LoopやCopilot Pagesで使われるファイルも含まれます。これらのコンテンツはSharePoint Embeddedコンテナーに保存される場合があり、コンテナー自体はSharePointサイトではないものの、保持と削除の目的ではSharePointサイトと同じように扱われます。(Microsoft Learn)
これは、AI活用やLoopの利用が広がっている組織にとって重要です。従来の「SharePointサイト一覧だけを見て保持設計を作る」方法では、LoopワークスペースやCopilot関連コンテンツの扱いが抜け落ちる可能性があります。
リストアイテムは保持ポリシーではなく保持ラベル中心で考える
SharePointのリストアイテムは、保持ポリシーではサポートされず、保持ラベルでサポートされます。ただし、システムリスト内のアイテムは例外です。添付ファイル付きのリストアイテムでは、保持ラベルの種類によって添付ファイルがラベル設定を継承するかどうかが変わります。(Microsoft Learn)
業務アプリとしてSharePointリストを使っている場合は、ドキュメントライブラリと同じ感覚でポリシーを当てると期待どおりに動かないことがあります。申請リスト、台帳、問い合わせ管理リストなどを保持対象にしたい場合は、保持ラベルの設計を先に確認してください。
保持設定はライブラリやフォルダー構造そのものには適用されない
保持ポリシーと保持ラベルの保持設定は、ライブラリ、リスト、フォルダー、Loopワークスペースといった「整理用の構造」そのものには適用されません。対象になるのは、基本的にその中にあるファイルや対応アイテムです。(Microsoft Learn)
そのため、「特定フォルダーを保持する」という表現で社内要件をまとめている場合でも、実装時には「そのフォルダー配下のファイルにどの保持ラベルを適用するか」「ライブラリの既定ラベルで対応できるか」という形に落とし込む必要があります。
Preservation Hold Libraryの動作を理解しておく
SharePointとOneDriveで保持対象のコンテンツを守るために使われるのが、Preservation Hold Libraryです。日本語では「アイテム保管ライブラリ」などと表示されることがあります。これはユーザーが通常操作する場所ではなく、コンプライアンス上必要なファイルコピーを保存する非表示のシステム領域です。Microsoftは、この領域内の保持ファイルを手動で編集、削除、移動したり、保持ラベルや秘密度ラベルを変更したりすることはサポートされないと説明しています。(Microsoft Learn)
実務上のポイントは、次の3つです。
| 確認項目 | 管理者が理解すべきこと |
|---|---|
| ユーザーが削除しても即時完全削除とは限らない | 保持対象のファイルは、削除や変更時にコピーがPreservation Hold Libraryへ保存される場合がある |
| ストレージ容量に影響する | SharePoint、OneDrive、Microsoft 365グループの保持済みアイテムはサイトのPreservation Hold Libraryに保存され、サイトのストレージクォータに含まれる可能性がある |
| 管理者が直接整理する場所ではない | 内容確認や調査にはeDiscoveryなどのコンプライアンスツールを使う |
特に容量計画では注意が必要です。大量のファイル更新があるサイト、バージョン数が多いライブラリ、退職者のOneDrive、Teams会議録画が蓄積される場所では、保持設定によってストレージ消費が想定より増えることがあります。Microsoftも、SharePointやOneDriveで保持設定を使う場合、Preservation Hold Libraryがサイトのストレージクォータに含まれるため、ストレージ増加が必要になる可能性を示しています。(Microsoft Learn)
削除までの流れは「保持期間終了＝即完全削除」ではない
保持設定で削除を指定していても、保持期間が終わった瞬間に必ず完全削除されるわけではありません。SharePointとOneDriveでは、ごみ箱やタイマージョブが関係します。
Microsoftの説明では、Preservation Hold Library内のコンテンツは30日以上経過した後、タイマージョブによって保持設定のクエリと照合されます。このタイマージョブは7日ごとに実行されるため、条件を満たしたコンテンツがPreservation Hold Libraryから削除されるまで最大37日かかる場合があります。(Microsoft Learn)
また、保持期間が終了したコンテンツは、第1段階または第2段階のごみ箱を経由します。第1段階と第2段階のごみ箱を合わせた保持期間は93日であり、最終的な完全削除はこの経路を通って行われます。(Microsoft Learn)
削除タイミングで誤解しやすい例
| よくある誤解 | 実際に確認すべきこと |
|---|---|
| 保持期間が終わればすぐ完全削除される | タイマージョブ、ごみ箱、別ポリシー、eDiscoveryホールドの有無を確認する |
| ごみ箱にあるファイルもeDiscoveryで必ず検索できる | Microsoftは、ごみ箱はインデックス化されず、eDiscovery検索で保留対象として見つからないと説明している |
| 1つの保持ポリシーで削除指定すれば必ず消える | 別の保持ポリシー、保持ラベル、eDiscoveryホールドで保持が必要な場合、完全削除は停止される |
保持設定の検証では、「ポリシーを作成したか」だけでなく、「実際にどの段階にファイルがあるか」「削除が止まる条件に該当していないか」を確認することが重要です。
管理者がまず確認すべき設定
SharePointとOneDriveの保持を見直す際は、いきなり新しいポリシーを作るのではなく、既存設定と対象範囲を棚卸ししてください。特に削除を伴うポリシーでは、対象範囲の指定ミスが重大なデータ損失につながります。
保持ポリシーと保持ラベルの使い分け
最初に確認するのは、「どの粒度で保持要件を満たすか」です。
| 要件 | 推奨される設計 |
|---|---|
| 全社のSharePointサイトを一律7年保持したい | 保持ポリシー |
| 特定部門のサイトだけを対象にしたい | 静的スコープまたはアダプティブスコープの保持ポリシー |
| 契約書だけ10年保持し、その他文書は3年にしたい | 保持ラベル |
| 機密文書をレコードとして編集・削除制限したい | レコードとして分類する保持ラベル |
| 退職、契約終了、製品終了などのイベントから保持期間を始めたい | イベントベースの保持ラベル |
| 開発アプリからファイルにラベルを付けたい | Microsoft Graph APIによる保持ラベル操作 |
Microsoft Graphでは、SharePointとOneDriveのdriveItemに保持ラベルを適用するAPIが提供されています。保持ラベルは、API経由で適用する場合、保持ラベルポリシーで公開されていなくても適用できると説明されています。(Microsoft Learn)
静的スコープとアダプティブスコープの選択
Microsoft Purviewの保持ポリシーでは、静的スコープとアダプティブスコープを選べます。既存の静的スコープからアダプティブスコープへ切り替えたい場合、Microsoftは既存ポリシーを残したまま、同じ保持設定を持つアダプティブスコープの新規ポリシーを作成し、対象が正しいことを検証してから古いポリシーを無効化または削除する考え方を示しています。(Microsoft Learn)
特にOneDriveでは、個別URL指定に注意が必要です。OneDrive URLはユーザーが初回アクセスするまで作成されない場合があり、UPN変更によってURLが変わることもあります。Microsoftは、個別ユーザーのOneDriveを静的スコープで指定する難しさがあるため、ユーザースコープのアダプティブスコープがより適していると説明しています。(Microsoft Learn)
対象範囲を「All」に戻してしまう事故に注意
削除を伴う保持ポリシーで特に危険なのが、対象の指定を外した結果、対象範囲が「All」に戻るケースです。Microsoftは、特定のサイトなどを含める設定で最後の対象を削除すると、その場所の構成が既定のAllに戻ることがあると警告しています。たとえば、削除設定を持つSharePoint保持ポリシーで1つのサイトだけを含めていたのに、そのサイト指定を削除すると、すべてのSharePointサイトが対象になり得ます。(Microsoft Learn)
本番環境で設定を変更する前に、次の手順を徹底してください。
| 手順 | 確認内容 |
|---|---|
| 変更前 | 現在の対象サイト、OneDriveアカウント、除外設定を記録する |
| 変更中 | 対象を削除した後、場所のトグルがオンのままAllになっていないか確認する |
| 変更後 | ポリシー詳細画面で配布状態と対象範囲を確認する |
| 展開後 | ヘルプデスクに削除・復元問い合わせの増加がないか確認する |
旧SharePoint機能からPurviewへ移行する際の注意点
SharePoint Onlineでは、旧来の情報管理ポリシー、インプレースレコード管理、ドキュメント削除ポリシー、サイト閉鎖と削除のポリシーなどが長く使われてきました。しかしMicrosoftは、Microsoft 365でコンテンツを保持または削除する必要がある場合、古いSharePointの情報管理・レコード管理機能ではなく、Microsoft Purview Data Lifecycle ManagementやMicrosoft Purview Records Managementを使うことを推奨しています。(Microsoft Learn)
公式の非推奨タイムラインでは、2026年4月に情報管理ポリシー、インプレースレコード管理、ドキュメント削除ポリシー、サイト閉鎖と削除のポリシーがMicrosoftのサポート対象外になる予定として示されています。ただし、Microsoftは将来の日付やタイムラインは計画の進行により変更される可能性があるとも明記しています。(Microsoft Learn)
移行時の対応表
| 旧機能 | Purviewでの移行先候補 | 確認すべきこと |
|---|---|---|
| 情報管理ポリシー | 保持ポリシー、保持ラベル | ライブラリ、フォルダー、コンテンツタイプ単位の要件をどう再現するか |
| インプレースレコード管理 | Purview Records Managementの保持ラベル | レコード化、ロック、解除、監査要件を整理する |
| ドキュメント削除ポリシー | Purview Data Lifecycle Managementの保持ポリシー | 削除のみか、保持後削除かを再定義する |
| Record Center | 通信サイト、保持ポリシー、保持ラベル、Power Automate | レコード集約先が本当に必要か、現場の業務導線を変えるか |
| Content Organizer | Power Automate、Microsoft Syntex、監査ログ | 自動振り分けロジックを保持機能と混同しない |
移行では「同じ名前の機能を探す」のではなく、「旧機能で満たしていた業務要件を分解する」ことが重要です。Microsoftの移行ガイダンスでも、既存の古いポリシーをレビューし、現代的な機能で再作成が必要なものを判断し、重複・古い・競合するポリシーを見直すことが推奨されています。(Microsoft Learn)
クラウド添付ファイルとCopilot利用時の影響
クラウド添付ファイルとは、ユーザーがOutlookメール、Teams、Viva Engage、Microsoft 365 CopilotやMicrosoft 365 Copilot Chatのやり取りで共有または参照するファイルへのリンクです。Microsoftの説明では、クラウド添付ファイルに保持ラベルを自動適用すると、元ファイルそのものではなく、共有ファイルのコピーに保持ラベルが適用され、そのコピーがPreservation Hold Libraryに保存されます。(Microsoft Learn)
この動作は、管理者が見落としやすいポイントです。ユーザーから見ると「Teamsでリンク共有しただけ」でも、保持設定上はコピーが作成される場合があります。さらに、保持期間の開始日は「ラベルが付けられた時点」を基準にすることが推奨されています。元ファイルの作成日時や最終変更日時を基準にすると、共有時点の元ファイルの日付が使われ、Preservation Hold Library内のコピーには期待した効果が出ない場合があります。(Microsoft Learn)
クラウド添付ファイルで確認すべきこと
| 確認項目 | 実務上の注意 |
|---|---|
| TeamsやOutlookでのリンク共有 | 共有されたファイルのコピーが保持対象になる場合がある |
| Copilotで参照されるファイル | Copilot利用が増えるほど、保持対象の設計範囲が広がる |
| 保持期間の開始日 | 「ラベル付けされた日時」を基準にする設計が推奨される |
| アーカイブサイト | すでにアクティブサイトから保持されたクラウド添付ファイルは設定対象だが、現在アーカイブサイト内にあるアイテムは自動適用保持ラベルで保持されない例外がある |
CopilotやLoopを導入している組織では、保持設計を「ファイルサーバー代替としてのSharePoint」だけで考えると不十分です。AIが参照するファイル、会議メモ、ページ、リンク共有されたコンテンツまで含めて、情報ライフサイクルを見直す必要があります。
OneNote、バージョン、Microsoft 365 Archiveの確認ポイント
SharePointとOneDriveの保持では、ファイルの種類やサイト状態によって挙動が変わります。特にOneNote、バージョン管理、Microsoft 365 Archiveは、運用後に問い合わせが起きやすい領域です。
OneNoteはセクション単位で保持される
OneNoteコンテンツに保持ポリシーを適用した場合、OneNoteの各セクションが個別ファイルとして保持設定を継承します。ページはセクションファイル内に含まれるため、保持と削除はセクション単位で考える必要があります。Microsoftは、個々のノートブックに表示される変更日はMicrosoft 365の保持では使用されないと説明しています。(Microsoft Learn)
現場には「ページ単位で消える」「ノートブック全体の更新日で保持期間が延びる」といった誤解が起きやすいため、OneNoteを業務記録として使う部門には事前説明が必要です。
バージョン管理は保持ポリシーと競合して見えることがある
SharePointとOneDriveのドキュメントライブラリでは、既定で少なくとも500のメジャーバージョンが保持されます。保持ポリシーやeDiscoveryホールドの対象になっているアイテムでは、ドキュメントライブラリ側のバージョン制限が保持期間に達するまで無視され、古いバージョンが自動的に削除されず、ユーザーによるバージョン削除も防止されます。(Microsoft Learn)
一方、保持ラベルだけが適用され、保持ポリシーやeDiscoveryホールドの対象でない場合は、ライブラリのバージョン制限が尊重されると説明されています。バージョン数を減らして容量を抑えたい場合は、どの保持設定が適用されているかを確認してください。
Microsoft 365 Archiveでは通常操作と保持操作を分けて考える
Microsoft 365 Archiveを使うサイトでも、保持ポリシーと保持ラベルの管理には大きな変更はないと説明されています。既定のポリシー構成では、アクティブサイトだけでなくアーカイブされたサイトも含まれます。アクティブサイトが保持ポリシーの対象で、その後アーカイブサイトになった場合も、引き続き保持ポリシーの設定対象です。(Microsoft Learn)
ただし、アーカイブサイトではユーザーがアイテムを表示・操作できないため、保持ラベルの手動適用や削除、レコードのロック・解除、レコードプロパティ編集などの通常操作は難しくなります。廃棄レビュー自体はMicrosoft Purviewポータルでサポートされますが、レビュー対象アイテムの内容表示やURLリンクが機能しない点にも注意が必要です。(Microsoft Learn)
開発者が確認すべきAPI・自動化のポイント
開発者や情シス部門が業務アプリとSharePoint／OneDriveを連携している場合、保持ラベルの適用や取得、レコードのロック制御を自動化できるかが重要になります。
Microsoft Purviewの拡張性に関する公式情報では、Microsoft Graph APIを使ってSharePointとOneDrive for Businessのアイテムに保持ラベルをプログラムから適用・管理できると説明されています。対応タスクには、保持ラベルの適用、削除、適用済み保持ラベルのメタデータ取得、レコードラベルのロック・ロック解除が含まれます。(Microsoft Learn)
開発・自動化での注意点
| 項目 | 確認ポイント |
|---|---|
| APIの対象 | driveItem、つまりSharePoint／OneDrive上のファイルやフォルダー |
| 権限 | APIごとに最小権限を確認する。レコード分類された保持ラベル変更には追加権限が必要な場合がある |
| SharePoint Embedded | 通常のGraph権限に加えて、FileStorageContainer.Selectedなどコンテナーアクセス権限が必要になる場合がある |
| ラベル公開 | Graph APIで適用する場合、保持ラベルポリシーで公開されていないラベルも適用できる |
| 業務アプリ連携 | 契約管理、退職処理、案件終了、製品ライフサイクルなどのイベントと保持ラベルを連動させる設計が有効 |
たとえば、契約管理システムで契約終了日が確定したら、該当するSharePoint文書に保持ラベルを適用し、イベントベースの保持を開始する、といった設計が考えられます。ただし、保持はコンプライアンス要件に関わるため、開発者だけで判断せず、法務、監査、セキュリティ、Microsoft 365管理者と要件をすり合わせる必要があります。
展開前に行うべき検証手順
保持設定は、一度本番展開するとユーザーの削除操作、復元、検索、容量、監査、eDiscoveryに影響します。小さく検証し、対象を段階的に広げるのが安全です。
| フェーズ | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 棚卸し | 既存の情報管理ポリシー、保持ポリシー、保持ラベル、eDiscoveryホールドを確認 | 旧SharePoint機能が残っていることに気付かない |
| 要件整理 | 文書種別ごとの保持期間、削除可否、レコード化要否を整理 | 「全部7年保持」のような粗い要件で例外が漏れる |
| テスト | テスト用サイト、テスト用OneDrive、サンプル文書で動作確認 | ごみ箱やタイマージョブの遅延を即時反映と誤解する |
| スコープ確認 | All、特定サイト、除外設定、アダプティブスコープを確認 | 最後の対象を削除してAllに戻る |
| 展開 | 部門単位、文書種別単位で段階展開 | ヘルプデスクや現場への説明不足 |
| 監視 | ポリシー状態、監査ログ、容量、ユーザー問い合わせを確認 | Preservation Hold Libraryの容量増を見落とす |
Microsoftの移行ガイダンスでも、新しい機能が期待どおりに動作しているかを確認するために、反映に必要な期間を待つこと、ポリシールックアップ、Activity Explorer、Content Explorer、ポリシー状態のエラー確認を行うことが示されています。(Microsoft Learn)
また、保持ポリシーは作成・送信後、適用まで最大7日かかる場合があります。配布状態はMicrosoft Purviewポータルの保持ポリシーページで確認できます。配布に時間がかかっている、またはエラーがある場合は、PowerShellで再配布を試す手順も公式に示されています。(Microsoft Learn)
よくある質問
保持ポリシーとバックアップは同じですか
同じではありません。保持ポリシーは、コンプライアンス要件に基づいて一定期間データを保持または削除するための仕組みです。バックアップのように、任意時点へ柔軟に復元することを主目的にした機能ではありません。ランサムウェア対策やポイントインタイム復元が必要な場合は、Microsoft 365の保持機能だけでなく、バックアップ戦略も別途検討してください。
ユーザーがファイルを削除しても管理者は復元できますか
保持対象であれば、削除されたファイルのコピーがPreservation Hold Libraryやごみ箱を経由する場合があります。ただし、復元可否は保持設定、ごみ箱の状態、eDiscoveryホールド、保持期間、削除経路によって変わります。エンドユーザーの第1段階ごみ箱だけを見て判断せず、サイトコレクション管理者の第2段階ごみ箱やコンプライアンスツールも確認してください。
OneDriveの退職者データはどうなりますか
OneDriveで保持ポリシーまたは保持ラベルの対象になっているファイルは、指定された保持期間中は保持設定の対象であり続けます。その間、共有アクセスは機能し、Content SearchやeDiscoveryで検出可能です。保持期間が終了し、削除アクションが含まれている場合、コンテンツはサイトコレクションのごみ箱へ移動し、管理者以外はアクセスできなくなります。(Microsoft Learn)
旧SharePointの情報管理ポリシーを使い続けてもよいですか
Microsoftは、Microsoft 365で保持や削除を管理する場合、古いSharePointの情報管理・レコード管理機能ではなく、Microsoft Purview Data Lifecycle ManagementやRecords Managementを使うことを推奨しています。また、旧機能は非推奨計画の対象であり、Microsoftが自動移行するわけではありません。移行しない場合、サポート対象外になったり、UIやプログラムから構成できなくなったりする可能性があります。(Microsoft Learn)
まず実施すべきアクション
Microsoft PurviewのSharePoint／OneDrive保持を見直すなら、最初に行うべきことは新規ポリシー作成ではなく、既存設定の棚卸しです。SharePointの旧機能、Purviewの保持ポリシー、保持ラベル、eDiscoveryホールド、OneDrive退職者データ、TeamsやCopilotで共有されるクラウド添付ファイルをまとめて確認してください。
次に、保持要件を「サイト単位でよいもの」と「文書単位で分けるべきもの」に分類します。サイト全体に同じ期間を適用するなら保持ポリシー、契約書や記録文書のように分類ごとに扱いが違うなら保持ラベルを使います。旧SharePoint機能を使っている場合は、Purview Data Lifecycle ManagementとRecords Managementへの移行計画を作り、テスト環境で対象範囲、削除タイミング、容量増加、ユーザー影響を確認してから本番へ展開してください。
コメント