Microsoft Purview Data Lifecycle Managementの「Archive OneDrive and SharePoint files under retention」は、保持ポリシーや保持ラベルで守られているOneDrive／SharePointファイルを、削除せずに低コストのアーカイブ領域へ移すための更新です。結論から言うと、長期保持が必要なため消せないファイルのストレージコストを抑えつつ、コンプライアンス、検索、eDiscovery、Copilotの関連性を維持したい組織は、2026年6月の一般提供予定に向けて準備すべき機能です。Microsoft 365 Roadmapの該当項目は、Roadmap ID 561208、状態は「In development」、リリースフェーズは「General Availability」、対象クラウドは「Worldwide (Standard Multi-Tenant)」、提供予定は「June CY2026」とされています。(Microsoft)
特に確認が必要なのは、すでにSharePointやOneDriveに長期の保持ポリシーを適用している企業、Copilotの検索結果に古い資料が混ざりやすい企業、退職者や終了プロジェクトのファイルがストレージを圧迫している企業です。ただし、Microsoft 365 Roadmapの公開予定日は変更される可能性があるため、実装前には管理センターやMessage Centerで最新状態を確認してください。(Microsoft)
Microsoft Purview Data Lifecycle Managementの今回の変更点
今回の更新は、Microsoft Purview Data Lifecycle Managementにおいて、保持対象のOneDriveおよびSharePointファイルをアーカイブできるようにするものです。Microsoftの説明では、保持ベースのファイルアーカイブにより、非アクティブなコンテンツを低コストストレージへ移動し、コンプライアンスを損なわずにコストを下げ、データの検出性とCopilot検索結果の関連性を維持できるとされています。(Microsoft)
重要なのは、この機能が「削除」ではなく「アーカイブ」である点です。保持ポリシーや保持ラベルの対象になっているファイルは、法務・監査・社内規程の都合で簡単に削除できません。一方で、何年も参照されていないファイルをアクティブ領域に置き続けると、ストレージコストや検索ノイズが増えます。このギャップを埋めるのが、保持中ファイルのアーカイブです。
| 確認項目 | 内容 |
|---|---|
| Roadmap ID | 561208 |
| 対象サービス | Microsoft Purview |
| 機能名 | Data Lifecycle Management – Archive OneDrive and SharePoint files under retention |
| 対象データ | 保持対象のOneDrive／SharePointファイル |
| 提供状態 | In development |
| リリースフェーズ | General Availability |
| GA予定 | 2026年6月 |
| プラットフォーム | Web |
| 対象クラウド | Worldwide (Standard Multi-Tenant) |
何が変わるのか：保持中のファイルを「消さずに軽くする」
従来、保持ポリシーが強く効いている環境では、不要に見えるファイルでも簡単に削除できないケースがありました。たとえば、全社のSharePointとOneDriveに7年保持のポリシーを適用している場合、終了済みプロジェクトの資料、古い会議録、過去の添付ファイル、退職者のOneDriveデータなどが長期間残り続けます。
今回の更新により期待できる変化は、次の3つです。
- 保持義務のあるファイルを削除せず、低コストのアーカイブ領域へ移動しやすくなる
- アクティブな作業領域から古いファイルを分離し、検索やCopilotの結果を整理しやすくなる
- eDiscoveryやコンテンツ検索など、コンプライアンス用途の検出性を維持しやすくなる
Microsoft 365 Archiveは、非アクティブなSharePointファイルやサイトを低コストで保持するための仕組みで、アーカイブされたデータは同じ検索性、セキュリティ、コンプライアンス基準を維持すると説明されています。また、アーカイブされたコンテンツはCopilotの応答関連性を高める観点でも利点があるとされています。(Microsoft Learn)
影響範囲：管理者が特に見るべき環境
この更新の影響を受けやすいのは、次のようなMicrosoft 365環境です。
| 環境 | 影響の見方 |
|---|---|
| SharePointに長期保持ポリシーを適用している | 古いドキュメントがアクティブストレージを圧迫している可能性がある |
| OneDriveを退職者データの保管場所として使っている | 非アクティブな個人領域データの扱いを見直す必要がある |
| Microsoft 365 Copilotを導入済み、または導入予定 | 古い資料がCopilotの参照候補に入り、回答の関連性を下げる可能性がある |
| eDiscoveryやContent Searchを利用している | アーカイブ後も検索・調査に使えるか検証が必要 |
| Graph APIやSharePoint APIでファイルを読むアプリがある | アーカイブ済みファイルを通常ファイルとして扱うとエラーになる可能性がある |
SharePointおよびOneDriveに保存されたファイルは、保持ポリシーまたは保持ラベルで保持できます。SharePointでは、アクティブサイトだけでなくアーカイブサイトも保持の対象として扱われます。(Microsoft Learn)
また、保持対象のSharePoint／OneDriveコンテンツでは、ユーザーが編集・削除しても、必要に応じてPreservation Hold libraryにコピーが保持されます。これは、ユーザー操作を完全に止めるのではなく、コンプライアンス上必要な元データを保持するための仕組みです。(Microsoft Learn)
アーカイブ、保持、バックアップを混同しない
この機能を検討するときに最も多い誤解は、「アーカイブすれば保持やバックアップの代わりになる」と考えることです。実務では、それぞれの役割を分けて設計する必要があります。
| 仕組み | 主な目的 | 代表的な使いどころ |
|---|---|---|
| 保持ポリシー／保持ラベル | データを一定期間保持または削除する | 法務、監査、社内規程、業界要件への対応 |
| Microsoft 365 Archive | 非アクティブデータを低コスト領域に移す | 終了プロジェクト、古い資料、大容量ファイルの整理 |
| バックアップ | 障害・誤削除・ランサムウェアなどから復旧する | 復元ポイントが必要な業務データ保護 |
保持は「いつまで残すか」、アーカイブは「どこに置くか」、バックアップは「どう戻すか」を扱う仕組みです。保持ポリシーの対象だからといって、業務上すぐ開ける必要があるとは限りません。一方で、アーカイブしたからといって、復旧要件を満たすとは限りません。
管理者が事前に確認すべき設定
保持ポリシーと保持ラベルの棚卸し
まず確認すべきは、Microsoft Purviewで設定している保持ポリシーと保持ラベルです。対象場所、保持期間、削除アクション、静的スコープ／適応型スコープ、例外設定を一覧化してください。
特にSharePointとOneDriveでは、ファイル単位の保持だけでなく、サイト、ライブラリ、フォルダー、ラベルの自動適用が絡みます。Microsoftのドキュメントでも、個別のメールや文書に例外的な保持期間を設定する場合は、保持ラベルを発行してユーザーや自動適用で処理すると説明されています。(Microsoft Learn)
棚卸しでは、次のように分類すると判断しやすくなります。
| 分類 | 判断基準 | 対応例 |
|---|---|---|
| 現役ファイル | 直近で編集・参照されている | アーカイブ対象外 |
| 長期保持ファイル | 法務・監査上、削除できない | 保持継続、非アクティブならアーカイブ候補 |
| 記録管理対象 | レコードまたは規制レコードとして扱う | Records Management側の設計を優先 |
| 大容量だが低利用 | 会議録画、古い設計書、過去資料 | パイロット対象にしやすい |
| 業務アプリ連携ファイル | APIや自動処理が参照する | アーカイブ前にアプリ影響を検証 |
高価値の文書を法的・規制上の記録として管理する必要がある場合は、Data Lifecycle Managementの保持ラベルだけでなく、Records Managementを使うべきケースがあります。(Microsoft Learn)
Microsoft 365 Archiveの課金とストレージ状況
Microsoft 365 Archiveはストレージ課金モデルを持ちます。Microsoftの料金モデルでは、アーカイブストレージとアクティブSharePointストレージの合計が、テナントに含まれる、またはライセンスで割り当てられたSharePointストレージ容量を超える場合に、アーカイブストレージのメーター課金が発生すると説明されています。(Microsoft Learn)
つまり、「アーカイブすれば必ず追加費用が発生する」わけではありません。逆に、ストレージ超過が大きいテナントでは、標準ストレージを買い足し続けるより、アーカイブ領域へ移すほうがコストを抑えられる可能性があります。
導入前には、少なくとも次の数値を確認してください。
- SharePointの現在の使用量
- OneDriveの使用量と増加傾向
- 上位の大容量サイト、ライブラリ、ユーザー
- 保持ポリシー対象のファイル量
- 直近6か月から1年で参照されていない大容量ファイル
- Microsoft 365 Archiveを有効化した場合の想定課金
アーカイブ後のアクセスと再アクティブ化
アーカイブされたファイルやサイトは、アクティブ領域と同じ感覚で即時利用できるとは限りません。Microsoft 365 Archiveでは、ファイルまたはサイトがアーカイブされると、より低温のストレージ階層に移動し、アクティブストレージクォータを消費しなくなります。一方で、その階層のコンテンツは誰も直接アクセスできず、Purview Content Search、エンドユーザー検索、eDiscovery検索は機能しますが、アーカイブ済みコンテンツのエクスポートには時間がかかる場合があります。(Microsoft Learn)
利用者にとっては、「ファイルが消えた」のではなく「再アクティブ化が必要な状態」になります。ヘルプデスクには、次のような案内文を用意しておくと混乱を減らせます。
| 利用者の問い合わせ | 案内例 |
|---|---|
| ファイルが開けない | このファイルはアーカイブされています。SharePointまたはOneDrive上で再アクティブ化してから開いてください。 |
| 検索には出るが中身を開けない | 検索結果には表示されますが、内容を読むには再アクティブ化が必要です。 |
| すぐ使いたい | 再アクティブ化には時間がかかる場合があります。重要ファイルは事前に対象外へ分類してください。 |
展開前に行うべき実務手順
現状把握
最初に、保持ポリシーとストレージ使用量を同じ表で見られるようにします。ストレージだけを見ると「大きいサイトを削ればよい」となりがちですが、保持やeDiscoveryホールドが効いていると削除できません。逆に、保持が必要なだけで日常利用されていないファイルは、今回のアーカイブ候補になり得ます。
確認する項目は、サイト名、所有者、データ量、最終更新日、最終アクセス傾向、保持ポリシー、保持ラベル、eDiscoveryホールド、業務アプリ連携の有無です。
対象を小さく分けてパイロットする
最初から全社適用するのは避けてください。おすすめは、終了済みプロジェクトのSharePointサイト、過去年度の資料ライブラリ、大容量の会議録画や古いファイルが多い部門など、影響を把握しやすい範囲から始めることです。
パイロットでは、次の観点で検証します。
| 検証項目 | 見るべきポイント |
|---|---|
| ユーザー体験 | アーカイブ済みファイルの表示、再アクティブ化、問い合わせ件数 |
| 検索 | SharePoint検索、Microsoft 365検索、Purview Content Searchで検出できるか |
| Copilot | 古い資料の混入が減り、回答の関連性が改善するか |
| eDiscovery | ケース作成、検索、エクスポートで問題が出ないか |
| API連携 | Graph APIやSharePoint APIでエラー処理できるか |
| コスト | 想定より課金が増えないか、標準ストレージ購入を抑えられるか |
本番展開では対象外条件を明確にする
アーカイブ対象は「古いかどうか」だけで決めないでください。最終更新日が古くても、日常的に参照される規程、テンプレート、設計標準、顧客契約、監査資料などはあります。
対象外にすべき代表例は次のとおりです。
| 対象外にする候補 | 理由 |
|---|---|
| 現行業務の手順書・テンプレート | 更新されなくても頻繁に参照される |
| 法務・監査チームが即時参照する資料 | 再アクティブ化待ちが業務遅延につながる |
| Power Automateや業務アプリが読むファイル | 内容取得エラーでワークフローが止まる可能性がある |
| 経営会議・取締役会関連資料 | 権限、検索、監査要件を慎重に確認すべき |
| レコード管理対象ファイル | Records Management設計を優先すべき |
開発者・アプリ担当が確認すべきAPI影響
開発者にとって重要なのは、アーカイブ済みファイルが「一覧には出るが、中身はすぐ読めない」可能性がある点です。Microsoftの開発者向けガイダンスでは、アーカイブ済みファイルはリストやライブラリのビューには表示され続けるものの、再アクティブ化されるまで内容のダウンロードやオープンはできないと説明されています。(Microsoft Learn)
Graph APIやSharePoint APIでファイルを列挙する処理は、アーカイブ済みアイテムも返します。APIはメタデータを返すため、一覧取得だけなら大きな問題になりにくい一方、ファイル内容を読む処理では失敗することがあります。Microsoftのガイダンスでは、アクティブファイルではarchiveStatusが空になり、アーカイブ中または再アクティブ化中のファイルでは対応する状態が示されるとされています。(Microsoft Learn)
特に注意すべき実装は次のとおりです。
| 処理 | リスク | 対応 |
|---|---|---|
| ファイル一覧の取得 | アーカイブ済みファイルも通常ファイルのように見える | archiveStatusや_FileArchiveStatusを確認する |
| ファイル内容のダウンロード | 423 Lockedなど、内容取得不可のエラーが返る可能性 | 障害扱いではなく、アーカイブ状態として処理する |
| 自動リトライ | 取得できないファイルに対して再試行が集中する | 短時間の連続リトライを避ける |
| インポート処理 | Power BIや独自アプリがファイルを読めない | アーカイブ対象外リストを作る |
| ユーザー通知 | エラー理由が分からず問い合わせが増える | 「再アクティブ化が必要」と明示する |
Microsoftは、アーカイブ済みファイルの内容をダウンロードしようとした場合、423 Lockedまたは類似のコンテンツ利用不可エラーが返り、再アクティブ化が必要になると説明しています。アプリ側では、これを一時的なプラットフォーム障害ではなく、通常起こり得る状態として扱うべきです。(Microsoft Learn)
また、Microsoft Graphではファイルのアーカイブと再アクティブ化に対応する操作として、POST /drives/{driveId}/items/{itemId}/archiveとPOST /drives/{driveId}/items/{itemId}/unarchiveが示されています。自動化を検討する場合は、権限、スロットリング、エラー処理を含めて検証してください。(Microsoft Learn)
展開時に失敗しやすいポイント
保持ポリシーを「ストレージ削減策」としてだけ見る
保持ポリシーは、コスト削減のためではなく、コンプライアンスや情報ガバナンスのための仕組みです。ストレージ削減を急ぐあまり、保持期間や対象範囲を不用意に変えると、法務・監査上のリスクが生じます。
コストを下げたい場合は、保持設定を短くする前に、保持対象のままアーカイブできるファイルがないかを確認してください。
Copilot対策として過度に期待する
今回の機能は、古いファイルをアクティブな作業領域から分離し、Copilotの関連性を保ちやすくする点で有効です。ただし、Copilotの回答品質は、権限、検索インデックス、ファイル名、文書品質、重複データ、最新資料の整備にも左右されます。
「古いファイルをアーカイブすればCopilotが必ず正確になる」と考えるのではなく、サイト設計、情報分類、権限整理、コンテンツ品質改善とセットで進めるべきです。
Teams連携サイトやモバイル利用を軽視する
Microsoft 365 Archiveには制限もあります。たとえば、Teamsに関連付いたサイトのうち、標準チャネルのみを使うサイトはアーカイブ対象になりますが、プライベートチャネルや共有チャネルを含むTeams関連サイトは部分的なサポートにとどまると説明されています。(Microsoft Learn)
また、ファイルレベルアーカイブのプレビュー段階では、一部のMicrosoft 365アプリやサービスがまだ完全には対応しておらず、WordやPowerPoint Online、Teams、OneDriveやSharePointのモバイルアプリ、古いOfficeデスクトップアプリなどで制限があるとされています。(Microsoft Learn)
そのため、モバイル中心の現場、Teamsチャネルでファイルを頻繁に扱う部門、古いOfficeクライアントが残っている環境では、展開前の検証が必須です。
エンドユーザーへの説明を後回しにする
保持ポリシーは多くの場合バックグラウンドで動作しますが、保持ラベルを併用する場合はMicrosoft 365アプリ上に表示されるため、ユーザーやヘルプデスク向けの説明が必要です。Microsoftも、保持ラベルを本番展開する前に、エンドユーザーとヘルプデスクへ情報と手順を提供することを推奨しています。(Microsoft Learn)
アーカイブについても同じです。ユーザーが「開けない」「消えた」「検索結果がおかしい」と感じる前に、次の3点を周知してください。
- アーカイブは削除ではない
- 必要な場合は再アクティブ化できる
- 再アクティブ化には時間がかかる場合がある
導入判断の基準
この機能は、すべてのテナントで即時に広範囲展開すべきものではありません。導入効果が出やすいのは、次の条件に当てはまる組織です。
| 導入を検討すべきケース | 理由 |
|---|---|
| SharePointストレージの追加購入が続いている | 長期保持データを低コスト領域へ移す余地がある |
| 全社的な長期保持ポリシーを設定している | 削除できない古いファイルが増えやすい |
| Copilot導入後、古い資料の参照が問題になっている | アクティブデータと非アクティブデータの分離が役立つ |
| プロジェクト終了後の資料が大量に残る | 終了プロジェクト単位で整理しやすい |
| eDiscoveryや監査要件を維持したい | アーカイブしつつ検出性を確保しやすい |
一方で、次のような環境では慎重な検証を優先してください。
| 慎重に進めるべきケース | 注意点 |
|---|---|
| 業務アプリがSharePointファイルを直接読む | アーカイブ済みファイルの内容取得に失敗する可能性がある |
| モバイルアプリ利用が多い | ファイルレベルアーカイブの表示・操作制限を確認する |
| Teamsのプライベート／共有チャネルを多用している | サイトアーカイブのサポート範囲を確認する |
| 法務・監査部門が即時アクセスを必要とする | 再アクティブ化時間を考慮する |
| 情報分類や所有者情報が未整備 | 誤ったファイルをアーカイブしやすい |
2026年6月のGA予定までにやるべきこと
今回のMicrosoft Purview Data Lifecycle Management更新に備えるなら、まずは設定変更ではなく、棚卸しとパイロット計画から始めるのが安全です。
実務では、次の順序で進めると失敗しにくくなります。
| 期限の目安 | やること |
|---|---|
| すぐ | Microsoft 365 Roadmap ID 561208とMessage Centerの更新を監視する |
| 1〜2週間以内 | SharePoint／OneDriveの保持ポリシー、保持ラベル、eDiscoveryホールドを棚卸しする |
| 1か月以内 | ストレージ上位サイト、非アクティブファイル、大容量ファイルを抽出する |
| GA前 | パイロット対象サイトと対象外条件を決める |
| GA後 | 小規模に適用し、検索、eDiscovery、Copilot、API連携を検証する |
| 展開後 | ヘルプデスク手順、ユーザー向け案内、運用レビューを整備する |
最初の一歩としては、「保持されているが、過去6か月以上ほとんど参照されていない大容量ファイル」を可視化してください。そのうえで、業務上すぐ開く必要があるもの、法務・監査で即時参照が必要なもの、API連携で使われているものを除外します。
Microsoft Purview Data Lifecycle Managementの今回の更新は、単なるストレージ節約機能ではありません。保持、アーカイブ、検索、Copilot、eDiscoveryをつなぐ情報ガバナンスの改善策です。2026年6月の一般提供に向けて、管理者は保持ポリシーとストレージの棚卸し、開発者はアーカイブ済みファイルを前提にしたAPIエラー処理、現場部門は再アクティブ化時の運用ルールを整えておきましょう。
コメント