Microsoft Purview の DLP によって SharePoint / OneDrive のファイルが「所有者・サイト管理者のみ閲覧可」に変わり、他の利用者から見えなくなる――この現象は多くの組織で発生します。本記事では、ポリシーを削除しても自動復帰しない理由と、確実に再表示させるための実践的な手順（GUI／PowerShell／運用設計）を、現場運用に耐える粒度でまとめます。
目次
対象読者と前提
- Microsoft 365（SharePoint Online / OneDrive for Business）を利用しており、Microsoft Purview の DLP ポリシーを適用している。
- 突然ファイルが見えなくなった／共有リンクが無効になった／検索にヒットしなくなった、といった問い合わせに対応する IT 管理者・情報システム部門。
- 権限モデル（サイト権限・アイテムの一意権限）と PowerShell に最低限の知見があることを想定。
結論（先に要点だけ）
- DLP ポリシーを削除・無効化しても、既に変更されたファイルの権限（ACL）は自動では元に戻りません。
- 再表示には、Purview での「上書き（Override / 解除）」、SharePoint / OneDrive からの再共有、PowerShell での一括権限復旧のいずれかが必要です。
- 復旧より先に 誤検知の原因ポリシーを調整（除外・条件見直し・テストモード）しないと、復旧直後に再度 DLP が発動します。
DLP でファイルが「非表示」になる仕組み
DLP ポリシーが SharePoint / OneDrive のファイルを検知した場合、実行アクションとして「アクセス制限（共有のブロック）」等が選択されていると、対象ファイルのアイテム権限が自動で書き換えられ、所有者（作成者・最終更新者）とサイト管理者（サイト コレクション管理者）だけが閲覧可能になります。これにより、組織内の他ユーザーや外部ゲスト、共有リンクの受信者は当該ファイルにアクセスできなくなり、ライブラリ一覧や検索結果にも現れにくくなります（表示対象外、もしくは資格がないためアクセス不能）。
重要なのは、DLP は「検知時点」でアイテムの ACL（アクセス制御リスト）を変更する点です。ポリシーを後から削除・無効化しても、アイテムに付与された一意権限はそのまま残るため、非表示状態も継続します。つまり、ポリシーの有無と権限の現在値は別物です。
再表示（復旧）方法の全体像
| 方法 | 主な操作手順 | 権限要件 | 適した規模 | 主な注意点 |
|---|---|---|---|---|
| Purview で DLP「上書き / 解除」 | コンプライアンス ポータル > データ損失防止 > アラート/インシデントを開き、対象イベントで 上書き（Override）/ 解除（Resolve/Release） を実行 | グローバル管理者（GA）またはファイル所有者（ポリシー設計により異なる） | 少〜中規模 | UI 表示はテナント設定と時期により名称差異あり。根本ポリシーを先に調整。 |
| SharePoint / OneDrive から手動再共有 | ライブラリで対象アイテムを選択 > 詳細 > アクセス許可の管理 からユーザー/グループへ権限付与、または 詳細設定 で「親から権限を継承」に戻す | サイト所有者、ファイル所有者 | 少量（都度対応） | 復旧直後に DLP 条件を満たすと再度ブロックされる可能性。 |
| PowerShell 一括復旧（PnP / REST） | 対象ライブラリのアイテムを列挙し、一意権限の解除（親からの継承に戻す）、または所定のグループに一括付与 | SharePoint 管理者 / サイト コレクション管理者 | 中〜大規模 | 対象選定・検証・ロールバック計画必須。業務影響に注意。 |
手順詳細：Purview コンプライアンス ポータルで「上書き」
最もガバナンスに沿った方法は、コンプライアンス ポータル側で発生した DLP イベントを調査し、上書き（Override）または解除（Resolve/Release）を行うことです。これにより、監査証跡と整合性を保ちつつアクセスを戻せます。
- コンプライアンス ポータルにサインインし、データ損失防止 > アラート（またはインシデント） を開く。
- 該当アイテムのイベント詳細を表示し、上書き / 解決 / 解除 のアクションを選ぶ。必要に応じて理由（ビジネス正当性）を記入。
- 処理が完了すると、アクセス制限が解除され、共有・検索も段階的に復帰する。
注意：テナントのロール/ポリシー設定により、上書き可能なロール（GA、コンプライアンス管理者、ファイル所有者など）が異なる場合があります。運用開始前に「誰が解除できるか」を明文化しておくと、復旧のリードタイム短縮に繋がります。
手順詳細：SharePoint / OneDrive から手動で再共有
対象ファイル数が少ない場合は、所有者またはサイト所有者が GUI で権限を戻すのが最も速いです。
- 対象ドキュメント ライブラリでファイルを選択し、右ペインの 詳細 > アクセス許可の管理 を開く。
- ユーザーの追加 または リンクの作成 で、組織内の必要なユーザー/グループ（例：Site Members、部門セキュリティ グループ）に 表示/編集 権限を再付与する。
- アイテムが一意権限になっている場合は、詳細設定 から権限ページを開き、「このアイテムは親から権限を継承していません」 の表示を確認。親から権限を継承 を実行して継承状態に戻す。
ポイント：ライブラリ全体の既定権限が適切であれば、継承に戻すのが運用負荷も低く堅牢です。個別付与は短期的な対処としては有効ですが、アイテムの権限が散逸しやすく、後続運用（棚卸・レビュー）を複雑にします。
手順詳細：PowerShell で一括復旧
誤検知が広範囲に及んだ場合は、PnP.PowerShell と SharePoint REST API を併用し、一意権限の解除（親から権限を継承） を自動化するのが現実的です。以下は安全策を織り込んだテンプレートです。
前提
- PnP.PowerShell が実行環境にインストール済み。
- 対象サイトに対してサイト コレクション管理者の権限を持つ。
- 実行前に 誤検知ポリシーの調整（除外・条件見直し・一時無効化）を済ませておく。
一意権限のアイテムのみを継承に戻す（Dry Run → 実行）
# 接続
$siteUrl = "https://contoso.sharepoint.com/sites/TeamA"
$listTitle = "Documents"
Connect-PnPOnline -Url $siteUrl -Interactive
# 一意権限のあるアイテムを収集（ページング推奨）
$items = Get-PnPListItem -List $listTitle -PageSize 500 -Fields "HasUniqueRoleAssignments","FileLeafRef","FileRef"
# Dry Run（対象の可視化）
$targets = @()
foreach ($i in $items) {
if ($i.FieldValues["HasUniqueRoleAssignments"] -eq $true) {
$targets += [pscustomobject]@{
Id = $i.Id
Url = $i.FieldValues["FileRef"]
Name = $i.FieldValues["FileLeafRef"]
}
}
}
$targets | Format-Table -AutoSize
# <確認後に> 実行：resetroleinheritance を REST で叩いて継承に戻す
foreach ($t in $targets) {
$endpoint = "/_api/web/lists/getbytitle('$listTitle')/items($($t.Id))/resetroleinheritance"
Invoke-PnPSPRestMethod -Method Post -Url $endpoint -ContentType "application/json;odata=verbose"
Write-Host "Reset inheritance: $($t.Url)"
} 復旧と同時に標準グループへ権限を再付与（例：Members = 編集）
# 継承に戻した後に、必要であれば既定グループを明示的に付与
$membersGroup = Get-PnPGroup -AssociatedMemberGroup
foreach ($t in $targets) {
# 念のため再度継承を適用（冪等）
$endpoint = "/_api/web/lists/getbytitle('$listTitle')/items($($t.Id))/resetroleinheritance"
Invoke-PnPSPRestMethod -Method Post -Url $endpoint
# 必要に応じて個別付与（継承で足りる場合は不要）
# 例：編集（Contribute）ロールを付与
Set-PnPListItemPermission -List $listTitle -Identity $t.Id -User $membersGroup.LoginName -AddRole "Edit"
} CSV で指定したファイル URL だけを復旧
# CSV 形式：Url 列にサーバー相対パス（例：/sites/TeamA/Shared Documents/xxx.docx）
$csv = Import-Csv ".\restore-targets.csv"
Connect-PnPOnline -Url "[https://contoso.sharepoint.com/sites/TeamA](https://contoso.sharepoint.com/sites/TeamA)" -Interactive
foreach ($row in $csv) {
$item = Get-PnPListItem -List "Documents" -Query "$($row.Url)"
if ($item) {
$endpoint = "/_api/web/lists/getbytitle('Documents')/items($($item.Id))/resetroleinheritance"
Invoke-PnPSPRestMethod -Method Post -Url $endpoint
Write-Host "Restored: $($row.Url)"
}
} 補足：「誰に戻すか」は各組織の既定権限設計に依存します。親からの継承に戻す運用が最もシンプルで、棚卸し・レビューも楽になります。個別付与を採る場合は、セキュリティ グループ（Azure AD グループ）を活用して管理対象を最小化しましょう。
復旧前に必ずやるべき「再発防止」設定
- ポリシーのテストモード（監査のみ）で再評価：検知条件・重要度・範囲（スコープ）を見直し、誤検知の要因（例：形式誤判定、業務文書の定型文）を除外。
- 除外ルールの適切化：部門サイト、特定ライブラリ、特定の分類ラベル、拡張子、信頼済みアップローダーのアカウントなどを除外。
- 精度向上オプションの活用：キーワード一致だけでなく、EDM（Exact Data Match）や機械学習型分類子、コンテンツ マーク（機密ラベル）との組み合わせを検討。
- ユーザー教育とポリシー ヒント：所有者が正当な理由で上書きできる設計にする場合、理由の記録と監査の可視化を必ずセットに。
復旧後に発生しがちな問い合わせと対策
| 症状 | 原因 | 対処 |
|---|---|---|
| 検索にすぐ出てこない | クロール/インデックスの反映待ち | 時間経過で解消。急ぐ場合はライブラリ設定から 再インデックス を実施。 |
| 既存の共有リンクが無効のまま | DLP によりリンク自体が破棄された | 復旧後に新しい共有リンクを発行。可能なら組織内限定リンクに統一。 |
| 外部ゲストに再共有できない | テナント/サイトの外部共有ポリシーがより厳格 | サイト/テナントの外部共有レベルと DLP の組合せを要確認。 |
| すぐにまた非表示になる | ポリシー条件が未調整のまま | 先にポリシーを見直しテストモードで検証。その後に復旧を実施。 |
運用設計（Runbook）テンプレート
役割分担
- 一次対応（サービスデスク）：影響範囲の切り分け（ユーザー/サイト/ライブラリ/ファイル数）、SLA の案内、チケット起票。
- セキュリティチーム（Purview 管理）：アラート調査、正当性判定、上書き可否の決定、ポリシー調整。
- SharePoint 管理：権限の復旧（GUI/PowerShell）、監査・証跡の収集、影響ユーザーへの周知。
標準フロー
- 発生検知：ユーザー問い合わせ／Purview アラートで認知。
- ポリシー再評価：テストモードで再現性・誤検知を確認し、必要な除外を追加。
- 復旧方式の選定：少量＝GUI、散在＝CSV 指定、広範＝全件スキャン。
- Dry Run：一意権限の検出結果を CSV に出力し、データオーナー承認を取得。
- 本復旧：継承に戻す → 必要に応じてグループ付与 → 共有リンク再発行。
- 事後：監査ログ保存、再発防止のポリシー改定、ナレッジ反映。
承認テンプレ（社内掲示例）
件名：DLP により非表示となったファイルの一括復旧について
対象：◯◯部 SharePoint サイト（/sites/◯◯）、文書ライブラリ「Documents」、対象アイテム数 1,248
内容：一意権限を「親から継承」に戻し、既定の Members 権限により編集可とする
予定：YYYY/MM/DD 20:00〜21:00（影響最小時間帯）
ロールバック：処理前の一意権限情報を CSV 退避し、必要時は個別復旧
承認：情報セキュリティ部／データオーナー
ターゲット選定の実務テクニック
- HasUniqueRoleAssignments = true のみを対象にする（標準継承のアイテムを巻き込まない）。
- 「DLP 影響らしさ」を高めるため、RoleAssignments にオーナー/サイト管理者以外が存在しないアイテムに絞るロジックを追加（PowerShell でロールを列挙して判定）。
- 処理前に アイテム ID, URL, 現在の割り当てロール を CSV に退避。ロールバックの保険になります。
現在の権限スナップショットを CSV に保存するスクリプト例
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/TeamA" -Interactive
$list = "Documents"
$items = Get-PnPListItem -List $list -PageSize 500 -Fields "FileRef","HasUniqueRoleAssignments"
$rows = @()
foreach ($i in $items) {
$roles = Get-PnPProperty -ClientObject $i -Property RoleAssignments
foreach ($ra in $roles) {
$member = Get-PnPProperty -ClientObject $ra -Property Member,RoleDefinitionBindings
foreach ($r in $member.RoleDefinitionBindings) {
$rows += [pscustomobject]@{
ItemId = $i.Id
Url = $i["FileRef"]
Unique = $i["HasUniqueRoleAssignments"]
Principal = $member.Member.Title
Role = $r.Name
}
}
}
}
$rows | Export-Csv ".\before-permissions.csv" -NoTypeInformation -Encoding UTF8 セキュリティと監査の観点
- 上書き（Override）の理由記録：Purview 上のインシデントで正当性を記録。後日の説明責任を担保。
- 最小権限の維持：復旧後に無制限な「共有リンク（匿名）」を乱発しない。できる限り組織内限定リンクを既定に。
- 外部共有のガードレール：サイト/テナントの外部共有レベルと DLP の方針を整合させる。
DLP 設計を賢くするチェックリスト
- いきなり「ブロック」ではなく、最初は監査モードで誤検知を洗い出す。
- ビジネス必須の文書テンプレは 除外条件（ファイル パス、ライブラリ、分類ラベル、アップローダー）で保護。
- EDM（Exact Data Match）や 機密ラベルを活用し、単なるキーワード一致から卒業。
- 所有者による正当化（ユーザー上書き）を許可する場合は、監査・SLA・周知テンプレをセットで整備。
FAQ
Q. ポリシーを削除すれば勝手に元に戻るのでは？
A. いいえ。DLP は検知時にアイテム権限を変更します。ポリシー削除では変更済み権限は戻りません。上書きまたは手動/スクリプトでの復旧が必要です。
Q. 復旧後にすぐまた非表示になるのはなぜ？
A. 条件を満たし続けているためです。先にポリシー調整（除外・条件見直し・監査モード）を行ってから復旧しましょう。
Q. どの方法が一番おすすめ？
A. 少量＝GUI、業務影響が大きい＝Purview で上書き、広範囲＝PowerShell の一括復旧が基本方針です。いずれも事前の Dry Run と承認が重要です。
トラブルシューティング補遺
- 同期クライアント（OneDrive for Business）の再表示：権限復旧後もキャッシュにより反映が遅れることがあります。クライアントの更新/再サインインで改善。
- バージョン履歴：権限復旧はコンテンツには影響しませんが、誤って「個別付与で上書き」すると履歴閲覧者が限定され続ける場合があります。継承に戻すのが安全。
- 監査ログの保全：発生～復旧までの監査イベントは必ずエクスポートして保全。再発分析に有用です。
サンプル：影響レポートの自動作成（任意）
# 一意権限かつオーナー/管理者のみのアイテムを抽出（ヒューリスティック例）
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/TeamA" -Interactive
$list = "Documents"
$items = Get-PnPListItem -List $list -PageSize 500 -Fields "FileRef","HasUniqueRoleAssignments"
$report = @()
foreach ($i in $items) {
if (-not $i["HasUniqueRoleAssignments"]) { continue }
$ras = Get-PnPProperty -ClientObject $i -Property RoleAssignments
$principals = @()
foreach ($ra in $ras) {
$member = Get-PnPProperty -ClientObject $ra -Property Member
$principals += $member.Member.Title
}
# 典型的な DLP 直後の状態（オーナー/管理者のみ）らしさを判定
$isLikelyDlp = ($principals -match "Owner|Site Collection Administrators").Count -ge ($principals.Count)
if ($isLikelyDlp) {
$report += [pscustomobject]@{
Id = $i.Id
Url = $i["FileRef"]
Principals = ($principals -join "; ")
}
}
}
$report | Export-Csv ".\dlp-likely-items.csv" -NoTypeInformation -Encoding UTF8 まとめ
- DLP ポリシーを消してもファイル権限は元に戻らない――非表示状態は続きます。
- 復旧は Purview の上書き、SharePoint/OneDrive の手動再共有、PowerShell 一括処理のいずれかで実施。
- 広範囲に誤検知が発生した場合は、HasUniqueRoleAssignments を手掛かりに Dry Run → 本復旧の順で安全に。
- 再発防止には、テストモード・除外ルール・EDM/分類子の活用と、上書き権限と理由記録の運用設計が不可欠。
「自動で戻るはず」という思い込みを捨て、ポリシー（検知）と権限（結果）を分けて考えるのが、DLP とうまく付き合う最短ルートです。この記事の手順とテンプレを基に、貴社の運用に合わせた復旧フローとガードレールを整えてください。
コメント