感度ラベル（Sensitivity label）の体系を変更したあとに必ず出てくるのが、「すでに旧ラベルが付いている大量のファイルを、新ラベルへまとめて付け替えたい」という悩みです。しかも対象がローカルと OneDrive／SharePoint にまたがると、同じ手順では片付きません。この記事では、保存場所ごとに現実的な“最短ルート”を整理し、移行設計から実行・例外対応まで、実務でそのまま使える形でまとめます。
結論：一括リラベルは「保存場所ごと」に最適解が分かれる
感度ラベルの一括置換（旧ラベル→新ラベル）は、理屈としては同じでも、実際には保存場所（ローカル／ファイル共有 vs OneDrive／SharePoint）で使える手段・制約・成功率が変わります。まずは全体像を押さえてから、あなたの環境に合うルートを選ぶのが最短です。
| 対象 | 現実的な一括リラベル手段 | 向いているケース | 注意点 |
|---|---|---|---|
| ローカルドライブ／ネットワーク共有 | MIP（Microsoft Information Protection）系 SDK／PowerShell で走査＆再付与 | フォルダー単位で「この範囲はこのラベル」と確実に置換したい | 暗号化／権限／ファイル形式で失敗が出る。実行アカウント設計が重要 |
| ファイルサーバー（オンプレ共有） | AIP Scanner 相当（Purview Information Protection scanner）でスキャン＆リラベル | 大規模共有領域を継続的にメンテしたい | 導入・運用がやや重い。ポリシー設計とリポジトリ管理が必要 |
| OneDrive／SharePoint | Microsoft Purview の自動ラベル（Auto-labeling） | ルールに合うコンテンツを継続的に自動適用したい | ルール設計が肝。ライセンス要件や反映までの時間差が出る |
| OneDrive／SharePoint（補助策） | OneDrive 同期でローカルへ寄せて、ローカル側のスクリプトで再付与 | 「このフォルダー一式をこの新ラベルにしたい」など手元で制御したい | 同期容量・速度・オンデマンド設定に影響。漏れが出ない設計が必要 |
最初にやるべき「移行設計」：旧→新のマッピング表を作る
一括リラベルで一番の事故原因は、技術よりも「置換ルールが曖昧なまま走り出すこと」です。旧ラベルと新ラベルの対応を、必ず表にして合意してから進めます。特に重要なのは、暗号化やアクセス制御をどう扱うかです。同じ“分類名”でも、暗号化設定が変わると利用者体験が大きく変わります（開けない、共有できない、アプリが落ちる等）。
| 旧ラベル | 新ラベル | 暗号化（保護） | 付与条件 | 例外 | 備考 |
|---|---|---|---|---|---|
| Confidential – Internal | 機密：社内限定 | 継続（同等） | 旧ラベルが付いているものを原則置換 | 外部共有が必要な案件フォルダー | 例外は別ラベル（例：機密：社外共有可）へ |
| General | 社内 | なし | 旧 General を新 社内へ | 顧客情報を含むもの | 顧客情報は上位ラベルへ上げる運用も検討 |
| Highly Confidential | 極秘 | 強化（より厳格） | 特定部署フォルダー配下 | 共同編集が必要な一部テンプレ | 共同編集不可になる場合はラベル設計見直し |
このマッピング表があると、作業は一気に楽になります。スクリプトでもスキャナーでも Purview でも、最終的に必要なのは「どの条件で何を付けるか」だからです。
前提条件チェック：ここを落とすと“適用できない”が頻発する
一括で付け替える前に、以下を満たしているかを確認します。特に「新ラベルが公開されていない」状態だと、どんな方法でも詰みます。
- 新ラベルが対象ユーザー／サービスアカウントに発行（公開）されている（ラベルポリシーで配布済み）
- 旧ラベルと新ラベルの“保護設定（暗号化）差分”を把握している（上書きで業務影響が出ないか）
- 自動化するなら実行主体（ユーザー／サービスプリンシパル）と必要権限が決まっている
- 対象範囲のファイル形式（Office、PDF、画像、CAD、圧縮、メール等）とボリュームを把握している
- 失敗時のログ取得と再実行方針（リトライ／隔離／手動対応）が決まっている
| チェック項目 | 確認ポイント | 見落としがちな罠 | 対策 |
|---|---|---|---|
| ラベル公開 | 新ラベルが対象に見える | 管理者には見えるのに実行アカウントには見えない | ラベルポリシーの対象をサービス／実行ユーザーまで含める |
| 権限 | ファイルを開ける／書き換えできる | 共有リンクや所有者不明でアクセスできない | 事前にアクセス棚卸し、例外フォルダーを切り分け |
| 暗号化 | 再ラベルで保護が変わる | 暗号化の付与・解除が失敗しやすい | 保護ありは別バッチに分離し、パイロットで検証 |
| 同期 | OneDrive 同期対象が完全 | オンデマンドで未ダウンロードのまま処理して漏れる | 「常にこのデバイスに保持」や事前ダウンロードで担保 |
ローカルドライブ／ファイル共有の一括リラベル：MIP SDK／PowerShell で“確実に置換”
ローカルやネットワーク共有は、Purview の自動ラベルだけではカバーしづらい領域です。現場で強いのは、MIP（Microsoft Information Protection）系の SDK／PowerShell でフォルダーを走査し、旧ラベルを検出して新ラベルを適用するやり方です。
MIP 系スクリプトが強い理由
- フォルダー単位の強制置換ができる（「この範囲は必ず新A」など）
- 旧ラベルを読んで条件分岐できる（旧B→新C、旧D→新E）
- 失敗ファイルをログ化して再実行しやすい
- ユーザー認証だけでなくサービスプリンシパル（アプリ）を使った自動化設計が可能
実行の流れ（現場向けテンプレ）
- 対象フォルダーを「バッチ単位」に分割（部署／容量／機密度など）
- まずは読み取りのみで棚卸し（旧ラベルの分布、保護ありの比率、エラーの種別）
- マッピング表に沿ってテスト適用（小さい範囲）
- 例外（アクセス不可、破損、保護失敗）を切り分け、処理順を最適化
- 本番バッチを実行し、ログを集約して監査可能な形で保存
PowerShell の考え方（擬似コード例）
環境や採用モジュールによりコマンド名は変わるため、ここでは「どう組むべきか」が伝わる形で例を示します。ポイントは、旧ラベルの識別子（Id/Name）を取って、マッピングに従って新ラベルを適用し、上書きフラグ（Force 相当）とログを徹底することです。
# 例：マッピング（旧ラベル名→新ラベルId）
$Map = @{
"Confidential - Internal" = "11111111-1111-1111-1111-111111111111"
"General" = "22222222-2222-2222-2222-222222222222"
}
$Root = "D:\TargetFolder"
$Log = "D:\Logs\relabel_$(Get-Date -Format yyyyMMdd_HHmmss).csv"
# 例：対象ファイル列挙（必要に応じて拡張子フィルター）
Get-ChildItem -Path $Root -Recurse -File | ForEach-Object {
$path = $_.FullName
try {
# 1) 現在ラベルを取得
$current = Get-FileSensitivityLabel -Path $path # 環境に合わせて置換
$oldName = $current.Name
# 2) 旧ラベル→新ラベルに該当するものだけ適用
if ($Map.ContainsKey($oldName)) {
$newId = $Map[$oldName]
# 3) 新ラベルを上書き適用（Force 相当）
Set-FileSensitivityLabel -Path $path -LabelId $newId -Force # 環境に合わせて置換
# 4) ログ
[pscustomobject]@{
File = $path
Old = $oldName
New = $newId
Result = "OK"
} | Export-Csv -Path $Log -Append -NoTypeInformation -Encoding UTF8
}
}
catch {
[pscustomobject]@{
File = $path
Old = $oldName
New = $Map[$oldName]
Result = "NG"
Error = $_.Exception.Message
} | Export-Csv -Path $Log -Append -NoTypeInformation -Encoding UTF8
}
}この形にしておくと、「どのファイルが、何から何へ変わったか」が後から追えるため、ユーザー問い合わせや監査対応が圧倒的に楽になります。さらに、NG の行だけを抽出して再実行（リトライバッチ）に回せます。
実運用のコツ：成功率を上げる“順番”を決める
- 保護（暗号化）なしのファイルを先に流す（成功率が高く、全体の進捗が読める）
- 次に Office/PDF など一般的な形式、最後に特殊形式（CAD、巨大ファイル、壊れやすい形式）
- ネットワーク共有は夜間バッチにして、ユーザー利用と競合しないようにする
- 「更新日時が変わる」「チェックアウト扱いになる」など、運用上の影響がある場合は事前に周知
（オンプレ共有が主役なら）AIP Scanner 相当でスキャン＆リラベルする
ファイルサーバー上に何十万・何百万ファイルがある場合、端末スクリプトで回すより、スキャナー方式が向くことがあります。考え方は、専用 VM 等にスキャナーを入れて共有フォルダーをリポジトリ登録し、ポリシーに従ってスキャン→ラベル適用（または推奨）を行う方法です。
スキャナーが向くケース
- 部署共有やプロジェクト共有など、サーバー上に大量の定型データが集まっている
- 移行後も新規ファイルが増えるため、継続的にスキャンして整備したい
- 端末を横断して回すのが難しい（PC が散在、電源/オンライン不確実）
導入・運用で押さえるべきポイント
| 観点 | ポイント | ありがちな落とし穴 | 現実的な対策 |
|---|---|---|---|
| 認証 | サービスアカウント／アプリの設計 | 共有へのアクセス権が足りない | 読み取り＋ラベル書き込みに必要な権限を事前付与 |
| スコープ | リポジトリ（共有）の分割 | 一気に登録して負荷過多 | 容量や部署で分割し、段階的に増やす |
| ポリシー | 自動適用か推奨か | 誤検知で大量に誤ラベル | 最初は推奨／監査モードで精度を確認 |
| 性能 | スキャン時間とI/O | 業務時間帯にサーバーが重い | 夜間実行、除外拡張子、増分スキャン設計 |
スキャナーは“導入コスト”はかかりますが、うまくはまるとファイルサーバーのラベル整備を仕組み化できます。「一度きりの置換」より、「今後も増える共有データを整え続けたい」組織ほど効果が出ます。
OneDrive／SharePoint の一括リラベル：Microsoft Purview 自動ラベルを軸に考える
OneDrive と SharePoint は、クラウド側でスキャンしてラベルを適用できるのが強みです。ローカルに集めなくても進められるため、対象が多いほど価値が上がります。中心となるのは、Microsoft Purview の自動ラベル（Auto-labeling）です。
Purview 自動ラベルで「旧→新」を実現する考え方
自動ラベルは、基本的にコンテンツの条件（キーワード、機微情報、メタデータ、ファイル種類、場所など）で判定し、合致したものにラベルを適用します。旧ラベルの置換をしたい場合は、次のどちらか（または併用）で組み立てるのが現実的です。
- パターン・条件で再判定して新ラベルを付ける（旧ラベルに依存しない）
- 場所（サイト／ライブラリ／フォルダー）で狙い撃ちし、ルールを簡素にする
特におすすめは、移行期間だけでも「場所で狙い撃ち」を強めることです。旧ラベルが付いたファイルが特定サイトや特定ライブラリに固まっているなら、条件式を複雑にして誤検知と戦うより、スコープを絞って確実に置換した方が早く安全です。
導入の進め方：いきなり自動適用しない
Purview 側の自動ラベルは、運用を間違えると「広範囲に誤ラベル」が起きます。そこで、現場で安全に進める定石は次の順です。
- シミュレーション（評価）で対象件数とヒット理由を確認
- 小さなスコープ（特定サイト／小規模ユーザー）でパイロット
- 例外パターンを条件に反映（除外キーワード、除外場所、上書き可否など）
- 段階的に本番スコープを拡大
自動ラベルのルール設計を“移行目的”に寄せる
「分類のための精密ルール」と「体系移行のための一時ルール」は、最適化の方向が違います。旧→新の置換が目的なら、次の観点を優先すると失敗しにくくなります。
- 高精度を求めすぎない（移行後に恒久ルールへ置き換える前提で設計）
- まずは“確実に当たる範囲”から（場所スコープ、明確なキーワード、定型文書）
- 「上書き」の扱いを決める（既に別ラベルが付いているものをどうするか）
- 最終的にユーザーが手動調整できるよう、例外ルートを用意する
OneDrive 同期＋スクリプト適用：ルールではなく“フォルダー単位”で確実に変えたいとき
Purview の自動ラベルは強力ですが、置換条件が「内容」ではなく「ここにあるもの全部」になりがちな移行局面では、逆に回り道になることがあります。その場合、OneDrive 同期で対象をローカルに寄せて、ローカル側の MIP スクリプトで置換する方法が効きます。
この方法が向くケース
- 部門ごとに OneDrive／SharePoint のフォルダー構造が整っており、場所で一律に置換したい
- 自動ラベルのルール設計に時間をかけられない
- 移行の責任範囲を明確にし、「このフォルダーは完了」を作りたい
同期方式で漏れを出さないための要点
| 論点 | なぜ重要か | 推奨設定／運用 |
|---|---|---|
| ファイル オンデマンド | 未ダウンロードのまま処理してラベル漏れが起きる | 対象範囲は「常にこのデバイスに保持」や事前ダウンロードで実体化 |
| 同期競合 | 書き換えで競合コピーが増えると混乱する | 実行時間をずらす／対象ユーザーに編集停止を周知 |
| 帯域・容量 | 大量同期でネットワークと端末が詰まる | 部署ごと／サイトごとに分割し段階実行、専用端末で実施 |
| 監査 | 何が置換されたか追えないと後で揉める | スクリプト側で CSV ログ、SharePoint 側の監査ログも併用 |
同期方式は“力技”に見えますが、移行の現場ではコントロール性が高いのが最大のメリットです。特に「ルールで当てにいくと例外が多すぎる」環境では、結果的に最短になります。
よくある失敗パターンと対策（原因別に潰す）
一括リラベルは、一定割合で必ず失敗が出ます。大事なのは「失敗ゼロ」を目指すより、失敗を想定して分類し、処理ルートを用意することです。
| 症状 | 主な原因 | 切り分けのコツ | 対策 |
|---|---|---|---|
| 新ラベルを適用できない／一覧に出ない | ラベルが未公開、実行アカウントに未発行 | 実行アカウントでラベルが見えるか確認 | ラベルポリシーの対象に実行主体を追加 |
| 一部ファイルだけ失敗（アクセス拒否） | 権限不足、所有者不明、リンク共有のみ | パスと ACL をログに残す | 例外フォルダーを分離し、権限付与 or 所有権整理 |
| 暗号化（保護）ありのファイルが失敗 | 保護解除不可、権限不足、古いクライアント | 保護あり／なしでバッチを分ける | 保護ファイル専用バッチ、事前検証、必要なら段階移行 |
| 処理が遅い／終わらない | 対象が広すぎ、ネットワーク I/O、巨大ファイル | 拡張子・容量・更新日で分割 | 夜間実行、除外リスト、分割バッチ、専用実行環境 |
| OneDrive／SharePoint で反映が遅い | クラウド側スキャンのタイミング、キュー | シミュレーション結果と適用結果の差分を見る | 段階展開、スコープ縮小、運用周知（タイムラグ前提） |
移行を“作業”で終わらせない：一度きりの置換と、継続運用を分ける
ラベル体系を変えた直後は「既存を全部直す」がゴールに見えますが、運用の視点では“直したあとに増えるファイル”の方が厄介です。そこで、設計を次の2層に分けると安定します。
- 移行バッチ（短期）：旧ラベルが付いた既存ファイルを、新体系へ寄せる
- 恒久運用（長期）：新規作成・アップロード時に、新体系でブレないようにする
移行バッチは、スクリプトや同期など“強制力の高い”方法でも構いません。一方で恒久運用は、Purview の自動ラベルやユーザー教育（既定ラベル、推奨、UI の整備）など、継続的に回る仕組みが重要になります。
現場で使える「進め方」テンプレ（検証→本番の型）
最後に、実行計画をそのままプロジェクトに落とせるよう、よく効く手順をテンプレ化します。
ステップ1：棚卸し（量・種類・例外の把握）
- 対象パス一覧（ローカル／共有／サイト）を確定
- 旧ラベルの分布（どのラベルが何件）を取得
- 保護ありファイルの割合、巨大ファイル、特殊拡張子を抽出
ステップ2：小規模パイロット（成功率と業務影響を確認）
- 1部署または1サイト、数百〜数千ファイル程度で実施
- 「開けない」「共有できない」「共同編集できない」など利用者影響を洗い出す
- ログ（OK/NG/理由）を残し、NG を原因別に分類
ステップ3：本番適用（段階的にスコープを拡大）
- バッチ単位（部署／サイト／容量）で順番を決める
- スクリプト実行ならリトライ設計（NG のみ再実行）
- Purview 自動ラベルなら評価→適用→拡大の順で
ステップ4：移行後の安定化（恒久運用へ）
- 新ラベルの既定設定、推奨設定、ユーザー向けガイド整備
- 例外ラベル（社外共有可、プロジェクト例外など）の運用ルール確定
- 監査・レポートの定期確認（想定外のラベル増減を検知）
監査と説明責任：ログは“技術”ではなく“保険”
感度ラベルの付け替えは、セキュリティ施策の中でも説明責任が発生しやすい作業です。「誰が、いつ、どの範囲を、何から何へ変えたか」を答えられるように、最低限次を用意しておくと安心です。
- スクリプト実行ログ（CSV：ファイルパス、旧、新、結果、エラー）
- バッチごとの完了報告（対象範囲、件数、NG 件数、対応方針）
- クラウド側は Purview／Microsoft 365 側の監査ログやアクティビティも参照できる状態に
この“保険”があるだけで、移行後の問い合わせ対応コストが大きく下がります。
まとめ：あなたの環境での最短ルート
- ローカル／共有が中心なら、MIP 系スクリプトで「旧→新」の置換を確実にする
- オンプレ共有が膨大なら、スキャナーで仕組み化（短期＋長期運用を見据える）
- OneDrive／SharePoint は、まずPurview 自動ラベルの評価から始め、条件が合わない部分を同期＋スクリプトで補う
- どの方法でも、ラベル公開・権限・暗号化差分・ログの4点を先に固めると失敗が激減する
コメント