Purview の感度ラベルは「既定ラベル」を使うと、Word/Excel/PowerPoint の新規ドキュメントに自動でラベルを付けられます。ところが、特定ユーザーだけ既定ラベルを変えたいのに反映されない……その原因は多くの場合「ラベル ポリシーの順序（Order）」です。本記事では、2ユーザーだけ既定ラベルを Internal にしたいのに付かないケースを、最短で直す手順と運用のコツまでまとめます。
起きていること：特定ユーザーだけ「既定の感度ラベル」が付かない
Microsoft Purview Information Protection（以下、Purview）の感度ラベル運用でよくあるのが、「全社では問題ないのに、特定ユーザーにだけ既定ラベルを自動適用したいときに限って動かない」という現象です。今回のケースは、全ユーザー向けのラベル ポリシーAが既に安定稼働している状態で、2ユーザーだけ既定ラベルを変える目的でポリシーBを追加したところ、Word/Excel/PowerPoint の新規ファイルに Internal が付かず、毎回手動選択が必要になってしまった、という状況です。
| 項目 | 既存ポリシーA（全ユーザー向け） | 新規ポリシーB（特定2ユーザー向け） |
|---|---|---|
| 対象 | 全ユーザー | 特定2ユーザーのみ |
| ドキュメントのラベル | 必須／既定ラベルなし | 必須／既定ラベル = Internal |
| メール・会議の既定ラベル | Internal | Internal |
| 順序（Order） | 1 | 0 |
見た目としては「ポリシーBが上に表示されている（=優先されそう）」にもかかわらず、現実の挙動は逆。これが混乱ポイントです。
結論：ラベル ポリシーは「順序番号が大きい方」が優先（Order が勝つ）
Purview の感度ラベル ポリシー（発行ポリシー）は、同じユーザーに複数のポリシーが適用されることがあります。その場合、ユーザーは複数ポリシーで公開されているラベル自体は“全部”見えますが、各設定項目（既定ラベル、ラベル必須、変更理由など）で競合が起きたときは、順序番号（Order）が最も大きい＝最も優先度が高いポリシーの設定が採用されます。
そして重要なのは、ポリシー一覧の表示順です。Microsoft Learn では「優先度が最も低いポリシーは一覧の上（最低の順序番号）／優先度が最も高いポリシーは一覧の下（最高の順序番号）」と説明されています。つまり、“下にあるほど強い”仕様です。
今回の構成で何が起きていたか
- 2ユーザーは「全ユーザー向け」のポリシーAにも、「2ユーザー向け」のポリシーBにも含まれる
- ドキュメント既定ラベル設定は、A が「なし」、B が「Internal」で競合している
- 順序（Order）は A=1、B=0 のため、Order が大きいAが勝ってしまい、2ユーザーの既定ラベルは「なし」になる
結果として、Word/Excel/PowerPoint で新規ファイルを作っても自動で Internal が付かず、ユーザーが毎回ラベルを選ばないといけない状態になります。
優先度が絡むのは「ラベル」と「ラベル ポリシー」で別々
Purview には “順序（Order）” が出てくる場所が2つあります。ここを混同すると、原因が見えなくなります。
| 対象 | 順序が影響するもの | よくある勘違い | 押さえるポイント |
|---|---|---|---|
| 感度ラベルの順序 | ラベル一覧での表示順、下位ラベルへの変更理由、（条件が重複した場合の）自動ラベル付けの選択など | 「ラベルの順序」と「ポリシーの順序」を同じ話だと思ってしまう | “どのラベルが強いか” を決めるのがラベルの順序 |
| ラベル ポリシーの順序 | 既定ラベル、ラベル必須、ユーザーがラベルを下げるときの理由要求など、ポリシー設定の競合解決 | 「上に表示されている方が強い」と思ってしまう | “どのポリシー設定が勝つか” を決めるのがポリシーの順序 |
今回のトラブルは「ラベルの順序」ではなく、ラベル ポリシーの順序で起きる典型例です。つまり、Internal ラベル自体が壊れているのではなく、Internal を既定にする設定が、別ポリシーに上書きされているという見立てになります。
ユーザーは複数ポリシーの“ラベル”をまとめて受け取るが、既定などの“設定”は勝ちポリシーが決める
「2ユーザー向けポリシーBを作ったのに、2ユーザーで既定が変わらない」場合、管理者が想像する動きは次のどちらかです。
- （誤解しやすい想像）ポリシーBが丸ごと優先され、2ユーザーはAの影響を受けない
- （実際）2ユーザーはAとBの対象になり、ラベルは両方の合算で見えるが、設定項目がぶつかったところだけ Order が大きい方が勝つ
この「合算＋競合だけ解決」という仕様があるため、メール既定ラベルが Internal のままでも不思議ではありません（AもBも Internal なので競合が起きない）。一方で、ドキュメント既定ラベルだけが “Aはなし／BはInternal” で差分があるため、そこだけが上書きの対象になります。
現場で迷わないための「Order 設計」小ワザ
ポリシーを増やしていく運用では、Order の設計を雑にすると、後から例外ポリシーを追加したときに再び競合が起きやすくなります。おすすめは、ベース（全体）を小さめ、例外（限定）を大きめにして“余白”を残すことです。
| 目的 | 例 | Order の付け方（例） | 狙い |
|---|---|---|---|
| 全社共通のベース | ラベル必須、メール既定=Internal | 0〜9 | 基本ルールを最優先にしない（例外で上書きしやすくする） |
| 部門・役職などの例外 | 法務だけ既定=Confidential、経理だけ理由必須 | 10〜19 | 例外同士の順序も付け替えやすい |
| 検証・テスト用 | PoC/パイロット向け設定 | 90〜99 | 本番へ影響を与えない設計がしやすい |
もちろんテナントによって既にポリシー数が多い場合もありますが、「勝たせたいポリシーは Order を大きくして下へ置く」という基本ルールさえ守れば、今回のような既定ラベルの不一致はかなり防げます。
順序を直しても改善しない場合の追加切り分け
Order を上げたのに、翌日になっても既定ラベルが付かない場合は、原因が “Order 以外” にある可能性が高いです。よくある追加原因と確認観点をまとめます。
| 追加で疑うポイント | 典型的な状況 | 確認・対処 |
|---|---|---|
| 別のポリシーCが存在 | 過去の検証で作ったポリシーが残っている | 発行ポリシー一覧で、対象ユーザーが入っていそうなポリシーを棚卸し（Order を含めて確認） |
| グループ/動的グループの反映遅延 | ユーザーをグループに入れた直後に期待動作しない | グループメンバーシップの反映を待つ／再ログインを依頼（最大24〜48時間想定） |
| Office アプリのポリシー無効化 | ラベルは見えるが、一部機能だけ効かない／端末差がある | 管理テンプレート・クラウド ポリシーの設定を再点検 |
| アカウントの切り替え | Office に個人アカウントも追加している | Office の「アカウント」画面で既定のサインイン先を確認し、対象テナントに統一 |
ここまで確認しても改善しない場合は、ポリシーのスクリーンショット（設定差分）と、対象ユーザーの Office バージョン情報をセットで集めると、サポートへエスカレーションするときも話が早いです。
推奨対応：ポリシーBの順序（Order）を全体ポリシーより大きくする
やりたいことが「2ユーザーだけ、より具体的に（あるいはより厳しく）設定したい」であれば、原則は限定ポリシーを“強く”するのが最短です。操作はシンプルで、ポリシーBをポリシーAより“下”に移動する（=Orderを大きくする）だけです。
手順（Purview 管理画面）
- Microsoft Purview ポータルを開き、情報保護（Information Protection）の発行ポリシー（Label policies / Publishing policies）へ移動します。
- ポリシー一覧で、2ユーザー向けのポリシーBの「…（その他の操作）」を開きます。
- 「下へ移動」を選び、ポリシーAより下（=Orderが大きい側）にします。
- 結果として、例として以下のようになればOKです。
| ポリシー | 対象 | Order | ドキュメント既定ラベル |
|---|---|---|---|
| ポリシーA | 全ユーザー | 1 | なし |
| ポリシーB | 特定2ユーザー | 2 | Internal |
この形にすると、2ユーザーは A/B 両方の対象である点は変わりませんが、競合する設定は Order=2 のポリシーBが勝つため、新規ドキュメントの既定ラベルが Internal に切り替わります。
順序変更後に意識したい「反映タイムラグ」
ラベルやラベル ポリシーの変更は、アプリやサービスに反映されるまで最大で約24時間かかる可能性があります。急に直らなくても、まずは反映待ち時間を織り込んで切り分けるのが安全です。
対象ユーザーには、反映を早めるために次を依頼すると効果的です。
- Word / Excel / PowerPoint / Outlook をすべて終了
- Office のアカウントからサインアウト → サインイン
- 可能なら PC を再起動（キャッシュの影響を切り分け）
- 新規の空白ドキュメントを作成し、リボンの「感度」やタイトルバーで既定ラベル表示を確認
ユーザー側で「既定ラベルが付いたか」を確認する具体ポイント
設定変更後は、管理者が「直ったはず」と思っても、ユーザーの確認方法が曖昧だと“直っていない”と判断されがちです。Office アプリでは、既定ラベルが反映されると次の場所に変化が出ます（アプリや表示設定で見え方は多少変わります）。
| アプリ | 確認ポイント | 期待される状態 |
|---|---|---|
| Word / Excel / PowerPoint（デスクトップ） | リボンの「感度」ボタン、またはタイトルバーのラベル表示 | 新規ファイルを開いた直後から Internal が選択済み |
| Outlook（デスクトップ） | 新規メール作成画面の「感度」 | 新規メールの既定が Internal |
| Office for the web | 上部メニューの「感度」 | 未ラベルの新規ファイルで Internal が既定 |
ポイントは、「既存のファイル」ではなく「完全な新規ファイル」で確認することです。既にラベルが付いているテンプレートや過去ファイルをコピーしていると、コピー元のラベルを引き継いで見えるため、既定ラベルの検証になりません。
“上へ移動 / 下へ移動” の直感に反する仕様を、運用ルールに落とし込む
ラベル ポリシーの画面では、つい「上＝強い」と思ってしまいます。しかし実際は、下にある（Order が大きい）ほど優先度が高いため、例外ポリシーほど下へ寄せるのが安全です。Microsoft Learn でも、期待動作が出ないときは順序を確認し、必要ならポリシーを下へ移動するよう案内されています。
社内手順書には、次の一文を入れておくと、担当者が変わっても事故が減ります。
- 「例外（限定ユーザー向け）ポリシーは、ベース（全体）ポリシーより下に置く（Order を大きくする）」
それでも直らないときの「運用上の最終手段」
原則は順序調整で解決しますが、例外的に運用設計上「全体ポリシーAに特定2ユーザーを含めたくない」事情があるなら、ポリシーAのスコープから2ユーザーを除外し、Bのみ適用にする方法もあります。
ただし、全社ポリシーに例外（除外ユーザー）が増えると、将来的に次のようなコストが上がります。
- 人事異動・入退社のたびに除外リストを見直す必要がある
- 「なぜこのユーザーだけ挙動が違うのか」を追跡しづらい
- 監査や運用引き継ぎで説明が難しくなる
そのため、まずはポリシーの優先度（Order）で解決し、除外は本当に必要なときだけに限定するのがおすすめです。
混同しやすいポイント：「既定ラベル」と「自動ラベル付け」は別物
検索で「感度ラベル 自動適用」と調べると、Purview の自動ラベル付け（Auto-labeling policy）の記事に行き着きやすいのですが、今回の現象はそれとは別です。新規ドキュメントに最初から付くラベルは、基本的に発行ポリシー（ラベル ポリシー）の“既定ラベル”設定で制御します。
| 機能 | 目的 | 主な適用タイミング | 典型例 |
|---|---|---|---|
| 既定ラベル（発行ポリシー） | ユーザーの初期値を決め、ラベル選択の手間を減らす | 新規作成／未ラベル状態のコンテンツ | 新規ドキュメントは Internal を初期値にする |
| 自動ラベル付け（Auto-labeling policy） | 機密情報検出など条件に一致したら自動でラベル付与 | サービス側でのスキャン、またはクライアントでの検出 | クレジットカード番号を含むファイルを Confidential にする |
「既定ラベルが効かない」トラブルは、まず発行ポリシーの Order（優先度）を見るのが近道です。
確認しておくと安心なチェックリスト
今回の原因が Order だとしても、現場では複数要因が重なることがあります。次のチェックを一度に確認しておくと、再発防止と切り分けが楽になります。
チェック項目（管理者側）
| チェック | 見るべきポイント | 意図 |
|---|---|---|
| ポリシーの順序（Order） | 特定ユーザー向けのポリシーが、全体ポリシーより下（Order大）にあるか | 競合設定で勝たせる |
| 競合している設定の洗い出し | 既定ラベル／ラベル必須／変更理由など、AとBで差分がある項目 | 「どの設定がどのポリシーで勝っているか」を理解する |
| ラベルのスコープ | Internal ラベルが「ファイル & 他のデータ資産」スコープを含むか | Word/Excel/PowerPoint で選べる前提を満たす |
| ラベル ポリシーの対象指定 | 個人指定よりグループ（動的グループ含む）を優先しているか | 運用負荷を下げ、対象漏れを減らす |
チェック項目（ユーザー側 / クライアント側）
| チェック | 見るべきポイント | 補足 |
|---|---|---|
| Office のサインイン先 | 対象テナントのアカウントでサインインしているか | 複数アカウント併用だと“別テナントのポリシー”を見ていることがあります |
| Office アプリのラベル機能が無効化されていないか | 管理テンプレートやクラウド ポリシーで「Sensitivity 機能」が無効になっていないか | 無効だとラベル自体が出ない／動きが不安定になります |
| 旧AIPアドインの影響 | Azure Information Protection アドインが強制有効になっていないか | 旧アドインは非推奨で、組み込みラベル機能と競合しやすいです |
| アプリ再起動 | 順序変更後に Office アプリを完全終了→起動し直したか | キャッシュされているポリシー情報を更新します |
「症状 → 原因 → 対処」が一目で分かる早見表
| 症状 | ありがちな原因 | 対処 |
|---|---|---|
| 特定ユーザーだけ新規ドキュメントに既定ラベルが付かない | 全体ポリシーと限定ポリシーが競合し、Order の大きい方が「既定なし」になっている | 限定ポリシーを下に移動し、Order を大きくする |
| ラベル自体は表示されるが、既定だけ効かない | ユーザーが複数ポリシー対象で、既定ラベル設定だけが競合している | 「競合項目」を洗い出し、勝たせたい設定を持つポリシーの Order を上げる |
| ラベルがまったく表示されない | ラベル ポリシーが発行されていない／Officeのラベル機能が無効化 | 発行ポリシーの対象・スコープ・Officeポリシー設定を確認 |
| 反映までに時間がかかる | サービス側のレプリケーション（最大24時間程度） | 時間を置く／アプリ再起動／サインアウト→サインインで更新を促す |
PowerShell で「どのラベル ポリシーが優先されているか」も確認できる
GUIで順序を見ても不安なときは、Security & Compliance PowerShell でラベル ポリシー情報を確認すると確実です。Purview のラベル ポリシーは PowerShell でも作成・変更・参照ができます（例：New-LabelPolicy など）。
たとえば、ポリシー一覧と優先度（Priority/Order相当）を確認する例です（環境により表示プロパティ名が異なる場合があります）。
Get-LabelPolicy | Select-Object Name,Priority,Enabled | Sort-Object Priorityまた、「特定ユーザーがどのポリシーの対象か」を見たい場合は、対象ユーザーを含むグループ設計や管理単位（Administrative Units）の有無も合わせて確認すると、後々のトラブルシュートが速くなります。
運用のコツ：ラベル ポリシーは増やしすぎない
Microsoft Learn でも「ラベル ポリシーは必要な場合だけ複数にし、できるだけ少なくする」方針が示されています。ユーザーに異なるラベルや異なるポリシー設定が必要なときだけ分け、不要に増やさないのが長期的に効きます。
どうしても分ける必要がある場合は、次のルールを社内標準にしておくと事故が減ります。
- 限定ユーザー向け（例外）ポリシーほど Order を大きくして下に置く
- ポリシー名に「対象」と「意図」を入れる（例：
SLP-ALL-Base/SLP-EXC-InternalDefault） - 個人指定より、メール有効なセキュリティグループ（動的グループ含む）で対象を管理する
- 「既定ラベル」「必須」「変更理由」など“衝突しやすい設定”は、なるべくベースと例外で差分を最小にする
まとめ：特定ユーザーにだけ既定ラベルを付けたいなら、まず Order を見直す
全体ポリシーが安定している状態で、特定ユーザーだけ既定ラベルを付けたいのに付かない場合、原因の第一候補はラベル ポリシーの優先度（Order）です。
- ユーザーが複数ポリシー対象になるのは普通に起きる
- 競合設定はOrder が最大のポリシーが勝つ（一覧では下にある）
- まずは限定ポリシーを下に移動して Order を上げる
- 反映には最大24時間程度かかることがあるので、ユーザー側の再サインイン・アプリ再起動もセットで案内する
このルールを押さえるだけで、「2ユーザーだけ Internal を既定にしたい」といったピンポイント運用も、余計な例外管理なしで安定させやすくなります。
コメント