SharePoint OnlineでMicrosoft Purviewの自動ラベル付け（auto-labeling）を使うと、PII（個人情報）を含むファイルへ感度ラベルを自動適用できます。ただし「/sites/site1だけ有効にして、/sites/site2では無効にしたい」という要件では、スコープの考え方と“別要因でラベルが付いたように見える”パターンを押さえることが重要です。
今回の悩み：SharePoint Onlineの特定サイトだけ自動ラベル付けしたい
同一テナントのSharePoint Onlineで、次のように複数サイト（サイトコレクション）があるケースを想定します。
- 共通ドメイン：https://mycompany.sharepoint.com
- 対象サイト：/sites/site1（PIIを含むファイルに自動ラベル付けを有効化したい）
- 除外したいサイト：/sites/site2（自動ラベル付けを無効にしたい）
このときの論点はシンプルで、「Purviewの自動ラベル付けポリシーでsite1だけを指定した場合、site2にも自動ラベルがかかってしまうのか？」です。さらに検証環境（Devテナント）では、site2をポリシーに含めていないのにラベルが付いたように見える事象が起こり、混乱しやすいポイントでもあります。
結論：自動ラベル付けは“指定したサイトコレクション”にだけ適用できる
Microsoft Purviewの自動ラベル付けポリシーは、基本的にポリシーで指定した場所（Location / Scope）にのみ作用します。SharePoint Onlineの場合、スコープは原則としてサイト（サイトコレクション）単位で指定します。
つまり、ポリシーで「特定のSharePointサイト（site1）」だけを指定すれば、設計としては次の動きになります。
| スコープ指定 | 期待される適用範囲 | 結果（考え方） |
|---|---|---|
| site1 を指定 | /sites/site1（そのサイトコレクション配下） | site1のファイルにのみ自動ラベル付けが走る |
| site2 を指定しない | /sites/site2 | 原則として自動ラベル付けの対象外 |
| SharePoint全体（All sites）を指定 | テナント内の全SharePointサイト | site2も含め、全体に自動ラベル付けが走る |
要点は、ルート（全SharePointサイト）を対象にしない限り、勝手に“全サイト一括”にはならないという点です。逆に言えば、site2にラベルが付いたように見えるなら、別の経路でラベルが付いている可能性が高い、というのが実務的な結論になります。
前提整理：Purviewの「自動ラベル付け」と「ラベルを使えるようにする」は別
感度ラベル周りは設定項目が多く、似た画面が並ぶため混同が起きやすい領域です。現場で切り分けを速くするには、次の3要素を分けて理解するのが近道です。
| 要素 | 役割 | 主なスコープ | site2に影響しやすい落とし穴 |
|---|---|---|---|
| 感度ラベル（Sensitivity label） | 分類（機密度）と保護（暗号化/透かし等）の定義 | ラベル自体は“定義”であり、場所指定ではない | 同じラベル名が多用されると、付与経路の推測を誤りやすい |
| ラベルの公開（ラベルポリシー/公開ポリシー） | ユーザー/グループにラベルを“見せる/使わせる” | ユーザー単位（誰に見せるか） | 全ユーザー公開＋既定ラベル設定で、保存時にラベルが付く |
| 自動ラベル付け（Auto-labeling policy） | 条件（PII検出など）に合致したコンテンツへ自動適用 | 場所（SharePoint/OneDrive/Exchangeなど） | SharePoint全体を対象にする別ポリシーがあるとsite2にも付く |
「site2でラベルが付いた＝auto-labelがsite2に走った」とは限りません。ラベルが付与される経路は複数あるため、“付いた事実”だけで原因を断定しないことが、運用では非常に重要です。
仕様のポイント：SharePointは“サイト単位”で、ライブラリ/フォルダ単位には基本的に切れない
Purviewの自動ラベル付けは、SharePoint Onlineに対してはサイト（サイトコレクション）単位のスコープで設計するのが基本です。ドキュメントライブラリ単位、フォルダ単位のような、より細かい単位で「ここだけ除外」をする設計は取りにくく、運用上はサイト設計で吸収するのが現実的です。
| やりたいこと | 実現しやすさ | 推奨アプローチ |
|---|---|---|
| site1だけ自動ラベル付け | 高い | 自動ラベル付けポリシーのSharePoint場所にsite1のみ指定 |
| 同じsite内で“このフォルダだけ除外” | 低い | 除外したい領域を別サイトへ分離し、スコープで制御 |
| 部門サイトの一部だけ対象 | 中〜低 | 対象コンテンツを集約するサイトを用意し、そこだけスキャン |
結果として、site1は「PIIが混入し得る業務保管庫」、site2は「公開資料・テンプレ・一般情報」のように役割でサイトを分ける設計が、最も管理しやすく、監査もしやすい形になります。
設計手順の考え方：site1だけを対象にする最短ルート
画面の名称や配置は更新されることがありますが、設計の筋は変わりません。ここでは“事故を起こしにくい進め方”として、作業の順番と確認ポイントを整理します。
手順1：ラベルと検出条件を先に固める
スコープ（場所）より先に、まず何を検出して、何のラベルを付けるかを明確にします。
- 対象ラベル例：「個人情報（PII）-社外共有禁止」
- 検出条件例：マイナンバー、運転免許証番号、クレジットカード番号、住所・氏名の組み合わせ など
- しきい値例：特定PIIが2件以上検出されたら付与（誤検知対策として有効）
- 動作モード：最初はテスト（シミュレーション）/推奨で開始し、誤検知が落ち着いたら自動適用へ
手順2：自動ラベル付けポリシーのSharePoint場所にsite1だけを入れる
ここが本題です。設定時は次の2点を強く意識してください。
- SharePointの対象指定は、「すべてのサイト」ではなく「特定サイト」を選ぶ
- URLはサイトコレクションのURLを入れる（例：https://mycompany.sharepoint.com/sites/site1）
site2（https://mycompany.sharepoint.com/sites/site2）は追加しない、これだけで設計上は「site2は対象外」にできます。
手順3：検証は“同じテストファイル”でsite1とsite2を比較する
検証で重要なのは、条件を揃えることです。おすすめは以下です。
- 同一のWord/Excelファイル（同一のPII文字列）を2つ用意
- 片方をsite1へ、もう片方をsite2へアップロード
- ラベルの付与状況、付与までの時間、付与者（自動/手動）を確認
ここで、site2にラベルが付いた場合は「auto-labelがsite2に走った」と決めつけず、次章の“典型パターン”で切り分けを行います。
site2にもラベルが付いたように見えるときの“典型パターン”
「site2をスコープに入れていないのにラベルが付く」という現象は、実際にはauto-label以外の経路でラベルが付いているケースが少なくありません。現場で遭遇しやすい原因を、確認観点とセットで紹介します。
パターンA：別の自動ラベル付けポリシーがSharePoint全体を対象にしている
最頻出の原因です。過去の検証用ポリシー、別部門が作成したポリシーなどがSharePoint全体を対象にしていると、site2にもラベルが付きます。
- 確認観点：自動ラベル付けポリシーが複数存在しないか
- 確認観点：同じPII条件（またはより広い条件）で動作するポリシーがないか
パターンB：既定ラベル（デフォルト感度ラベル）で付与されている
ラベルは「検出して自動適用」だけでなく、「既定で付ける」経路でも付与されます。例えば、
- Officeアプリ側で、ユーザーが保存するたびに既定ラベルが付く
- SharePointのドキュメントライブラリ側で、アップロード時に既定ラベルが付く
これらはauto-labelとは別の仕組みなので、site2が自動ラベル付けポリシーの対象外でも“ラベルが付く”という見え方になります。
パターンC：ユーザーの手動付与、または推奨に従った付与
ラベルがユーザーに公開されている場合、ユーザーが手動で付けることがあります。また、推奨のメッセージに従って付けた場合も、結果だけを見ると「勝手に付いた」ように見えがちです。
- 確認観点：監査ログ等で、ラベル適用の実行者が“ユーザー”になっていないか
- 確認観点：テスト後にOfficeで開いて保存し直していないか（保存時に付くケースがある）
パターンD：site1からsite2へコピー/移動したファイルが“ラベルを保持”している
感度ラベルはファイルのメタデータとして保持されるため、site1で付いたラベル付きファイルをsite2へコピーすると、site2上でもラベルが付いた状態のまま存在します。これは「site2でauto-labelが走った」のではなく、もともとラベルが付いていただけ、というケースです。
パターンE：ポリシー変更の反映遅延で、旧設定が残って見える
自動ラベル付けは、ポリシー変更直後に必ず即時反映されるとは限りません。特にSharePointのコンテンツスキャンは、ファイル数やサービス側の処理状況によりラグが出ます。
- 確認観点：過去にsite2をスコープに入れていた時期がないか
- 確認観点：変更後、十分な時間を置いて同条件で再検証したか
- 確認観点：対象ファイルが“新規作成/更新”なのか、“過去に処理対象だったもの”なのか
パターンF：Dev/Testテナント特有の構成差分（設定の残骸）
検証環境（Dev）では、試行錯誤の過程でポリシーが乱立しやすく、担当者が変わると「誰が何を作ったのか分からない」状態になりがちです。その結果、
- SharePoint全体スコープのポリシーが残っていた
- 既定ラベル設定だけが残っていた
- テスト用ユーザーのOffice設定が本番と違う
といった差分が原因で、「Devではsite2にも付くのに、Prodでは付かない（またはその逆）」が起こります。
原因特定を速くする：チェックリスト（現場向け）
「どの仕組みでラベルが付いたか」を確定できると、一気に解決が近づきます。以下の表の順で潰すと迷子になりにくいです。
| 症状 | 疑うべき原因 | 最短の確認 | 対処の方向性 |
|---|---|---|---|
| site2の複数ファイルに一斉に同じラベルが付く | 別のauto-labelポリシー（全体スコープ） | 自動ラベル付けポリシー一覧で“SharePoint全体対象”がないか探す | 不要ポリシーを停止/削除、またはスコープをsite1に限定 |
| アップロード直後からラベルが付いている | 既定ラベル（ライブラリ/Office） | site2側のライブラリ既定ラベル、ユーザーのOffice既定設定を確認 | site2の既定ラベルを解除、または既定設定を設計どおりに統一 |
| Officeで開いて保存した後にラベルが付く | ユーザー操作/推奨に従った付与 | 監査ログ等で実行者を確認（ユーザーかサービスか） | ユーザー周知、推奨/必須の方針を見直す |
| site1由来のファイルだけラベルが付いている | コピー/移動によるラベル保持 | ファイルの出所（移動経路）を確認 | 持ち込み運用をルール化、必要なら移動先サイトの扱いも再設計 |
| ポリシー変更後もしばらく付与が続く | 反映遅延/スキャン遅延 | 変更前の設定履歴、時間経過、対象ファイルの更新日時を確認 | 時間を置いて再検証＋“どのポリシーが発火したか”を追う |
追跡のコツ：「どのポリシーがラベルを付けたか」を見える化する
Purview運用で大事なのは、トラブル時に証跡を取れることです。次の観点を押さえると、原因特定が早くなります。
- 監査ログ（Audit）：ラベル適用のイベントが記録される場合があります。実行者（ユーザー/サービス）とタイムスタンプで切り分けを行います。
- アクティビティ/コンテンツの可視化：利用できる機能（Activity explorer等）はライセンスや権限に依存しますが、検出・適用状況の俯瞰に役立ちます。
- テストは専用ユーザー1名：複数人が触ると「誰の操作で付いたか」が分からなくなりがちです。
運用者向け：PowerShellで“意図しないポリシー”を棚卸しする発想
GUIだと見落としやすい場合、Microsoft Purview（コンプライアンス）系のPowerShellで棚卸しすると整理しやすいことがあります。環境によりコマンドレット名や権限が異なるため、ここでは“発想”として参考例を置きます。
# 例：自動ラベル付けポリシーの一覧を取得（環境によりコマンドは異なります）
Get-AutoSensitivityLabelPolicy
# 例：特定ポリシーの詳細（場所/状態）を確認
Get-AutoSensitivityLabelPolicy -Identity "PII_AutoLabel_SPO"狙いは、「SharePoint全体を対象にしているポリシーが残っていないか」「古い検証ポリシーが有効になっていないか」を機械的に洗い出すことです。
Dev/Test/Prodでズレを起こさない：差分管理のコツ
今回の結論（現場でよくある着地）は、次の形になりがちです。
- 製品仕様としては：自動ラベル付けは“指定したサイトにだけ適用”が正しい
- 見え方が崩れた原因は：Devテナントの構成や設定差分（重複ポリシー、既定ラベル、過去設定の残り）
- 本番（Prod）では：site1のみ指定で、site1にだけ自動ラベルが付与され、site2は対象外になった
このズレを防ぐには、環境ごとに次の項目を一覧化しておくのが効果的です。
| 管理項目 | なぜ重要か | おすすめの管理方法 |
|---|---|---|
| 自動ラベル付けポリシーの数と状態（有効/無効） | 古い検証ポリシーが残ると、想定外にsite2へ適用される | 命名規則＋棚卸し（四半期ごと） |
| SharePointの対象スコープ（site1のみ/全体） | ここがズレると結果が180度変わる | 設定証跡（スクリーンショット）を変更チケットに添付 |
| 既定ラベル（Office/ライブラリ） | auto-labelと誤認しやすい | “既定ラベルはどこで設定しているか”を台帳化 |
| テストユーザーの設定 | 個人設定が混ざると再現性が落ちる | 検証用ユーザーを固定し、手順書どおりに操作 |
運用ベストプラクティス：安全に自動ラベル付けを回すために
最初はテスト/推奨で誤検知を潰してから自動適用へ
PII検出は強力ですが、文脈次第で誤検知が起きます。いきなり強制適用にすると、業務ファイルに大量のラベルが付与され、現場が混乱するリスクがあります。まずはテスト/推奨で開始し、誤検知が少ない条件へ調整してから自動適用へ移行するのが安全です。
“除外したいコンテンツ”はsite2へ逃がす（サイト設計で解く）
フォルダ単位で除外しづらい前提では、設計で回避するのが最も堅牢です。
- site1：PIIを扱う業務の保管庫（自動ラベル付け対象）
- site2：公開資料/テンプレ/一般情報（対象外）
このようにサイトの役割を分けると、スコープも運用もシンプルになり、監査・説明責任も果たしやすくなります。
ポリシー変更後は“反映ラグ”を前提に検証計画を組む
変更直後の結果だけで判断すると、旧設定の影響を“バグ”と誤認しやすくなります。おすすめは次の流れです。
- 変更前後の設定証跡を残す（変更点が説明できる状態にする）
- 一定時間を置いて再検証する
- 新規アップロードのテストファイルで同条件比較する
命名規則と責任者（オーナー）を決め、重複ポリシーに備える
Purviewのポリシーは増えやすいため、最初からルールを決めるとトラブルが激減します。
- 命名規則：[対象]_[目的]_[環境]_[状態]（例：SPO_PII_Site1_Prod_Enforced）
- オーナー：ポリシーごとに責任者（部署）を明確化
- 棚卸し：定期的に無効化ポリシー、重複条件を整理
よくある質問
site1配下のサブサイトも対象になりますか？
サイトコレクション配下で運用している場合、同じスコープとして扱われることがあります。サブサイト運用をしている場合は、site1に含めた範囲に何がぶら下がっているかを事前に把握しておくと安心です。
「site1は有効、site2は無効」を確実にするための最短チェックは？
- 自動ラベル付けポリシーのSharePoint対象がsite1のみになっている
- SharePoint全体を対象にした別ポリシーが存在しない
- site2側に既定ラベルが設定されていない
すべて確認してもsite2で説明がつかない場合は？
スコープ設定が正しく、重複ポリシーもなく、反映時間も十分に確保しているのにsite2で自動ラベル付けが動いているように見える場合、テナント固有の状態やサービス側の問題の可能性が残ります。その場合は、
- 再現手順（いつ、誰が、どのファイルで、どのラベルが付いたか）
- ポリシー設定の証跡
- 監査ログ等の該当イベント
をまとめたうえで、Microsoftサポートへエスカレーションするのが現実的です。証跡が揃っているほど、切り分けは早くなります。
まとめ：仕様は“サイトコレクション単位”、見え方の罠は“別経路のラベル付与”
- Purviewの自動ラベル付けは、SharePoint Onlineでは指定したサイトコレクションにだけ適用できるため、site1のみ対象・site2は対象外の設計は可能
- site2にラベルが付いたように見える場合、別ポリシーの重複、既定ラベル、ユーザー操作、コピー/移動、反映遅延を疑うのが近道
- Dev/Test/Prodの差分は“設定が残りやすい”ので、環境ごとの棚卸しと命名規則が効果的
「site1だけ自動ラベル付け、site2は無効」は、正しくスコープを絞れば実現できます。重要なのは、ラベルの付与経路を取り違えず、ログと設定の両面から切り分けることです。
コメント