Microsoft Purview の「感度ラベル（機密ラベル）」ページだけ、特定ユーザーが開けずエラーになることがあります。同じ権限レベルのはずでも差が出るのは、Purview 側ではなく Microsoft 365 コンプライアンス基盤のロール・ライセンス・トークン状態が噛み合っていないケースが多いからです。最小限の権限と、現場で再現性高く切り分ける手順を整理します。
現象の整理：なぜ「同じ権限のはず」でも感度ラベルだけ開けないのか
Microsoft Purview には複数の領域（コンプライアンス／情報保護、データガバナンス、監査など）があり、画面ごとに参照している権限体系が異なります。特に「感度ラベル（機密ラベル）」は、Microsoft Purview ポータルの見た目で表示されていても、実体は Microsoft 365 コンプライアンス基盤（旧コンプライアンス センター）の機能として動作します。
そのため、Azure サブスクリプション側の Purview リソース権限（Azure RBAC）や、Purview 内の別機能の権限が揃っていても、Entra ID（旧 Azure AD）側の管理ロールや、コンプライアンス権限が不足していると「感度ラベル」ページだけが読み込めないことがあります。
| よく混同されるポイント | 実際に影響する範囲 | 感度ラベル画面への影響 |
|---|---|---|
| Azure の「所有者／共同作成者／閲覧者」など（Azure RBAC） | Azure サブスクリプション配下のリソース操作 | 原則として直接は効かない（感度ラベルは M365 側の機能） |
| Purview 内のデータカタログ／スキャン等の権限 | データガバナンス機能の操作 | 画面が表示されるように見えても、感度ラベルの管理権限とは別 |
| Entra ID の管理ロール（Compliance Administrator 等） | Microsoft 365 コンプライアンス機能の管理 | 最重要。不足すると「ページが開けない」「権限不足」になりやすい |
| Microsoft 365 のライセンス | 利用できる情報保護機能の範囲 | ロールが正しくても UI が不安定／操作不可になるケースがあるため要確認 |
結論：感度ラベルページにアクセスするための最小権限は「Compliance Administrator」
本件のように「ユーザーAは開けるが、同等と思われるユーザーBは開けない」ケースで検証したところ、対象ユーザーに「Compliance Administrator（コンプライアンス管理者）」ロールを付与することで解消した、という結果が得られています。
初期段階では「Compliance Manager Readers（コンプライアンス マネージャー閲覧者）」などの閲覧系ロールも候補になりがちですが、少なくとも今回の事象では、最終的に有効性が確認できたのは Compliance Administratorでした。運用上は、まずこのロールを起点に切り分けるのが最短です。
ポイント：「感度ラベル」は“情報保護の設定画面”であるため、単なる閲覧者ロールでは API/バックエンド呼び出しが許可されず、UI がエラーになって表面化することがあります。
ロール別：できること／できないことの目安
組織の権限制御方針によって最小権限は前後しますが、現場で判断しやすいように「どのロールが何に効くか」を整理します。
| ロール（例） | 主な用途 | 感度ラベル画面 | 備考 |
|---|---|---|---|
| Compliance Administrator | コンプライアンス機能全般の管理 | 表示・設定が安定しやすい | 本件の解決に直結。最初に試す価値が高い |
| Information Protection Administrator / Analyst | 情報保護の運用・分析 | 環境により可否が分かれる | 組織のロール設計によっては補助的に必要 |
| Compliance Data Administrator | コンプライアンス データの管理 | 直接の解決にならない場合あり | 監査/検索等で必要になることがある |
| Global Administrator | テナント全体の管理 | ほぼ確実に表示可能 | 最小権限の観点では過剰。検証用途には有効 |
Compliance Administrator を付与する具体的な手順（管理者向け）
「ロールを付与したつもり」でも、実際は別のロールを付けていた／別テナントに付けていた、という取り違えがよく起きます。手順は環境や管理画面の表記で多少変わりますが、少なくとも次の観点が揃っていれば OK です。
Entra ID（旧 Azure AD）での付与ポイント
- 対象ユーザーが所属する同一テナントで作業している
- ロール名が「Compliance Administrator（コンプライアンス管理者）」になっている（類似名の閲覧ロールと混同しない）
- PIM を使っている場合は、付与後にユーザー側でアクティブ化が必要な設計になっていないか確認する
Microsoft 365 管理センターでの付与ポイント
- 「ユーザー」→「アクティブなユーザー」から対象ユーザーのロールを確認できる
- ロール付与後は、対象ユーザーに再サインインさせて古いセッションを切る
Purview ポータル側での確認ポイント
- Purview ポータルに入れることと、感度ラベルを操作できることは別（入れるだけなら別ロールでも可能）
- 「アクセス許可」「ロール グループ」などの画面で、情報保護系のロール グループに入っているかも併せて確認する
エラー文から切り分ける：よくある症状と意味
「開けない」といっても、エラーの出方で原因が変わります。まずは、ユーザーBで出るメッセージ（スクリーンショット推奨）を、次の表に当てはめてみてください。
| 症状 | 原因として濃いもの | 最初に試すこと |
|---|---|---|
| 「アクセスが拒否されました」「権限がありません」系 | ロール不足、PIM 未アクティブ、別テナントでログイン | Compliance Administrator の付与と PIM 状態確認、シークレットで再ログイン |
| 真っ白／読み込みが終わらない | キャッシュ、拡張機能、セッション不整合、プロキシ | シークレット、別ブラウザー、拡張機能無効化、別回線で比較 |
| 「Something went wrong」系の汎用エラー | サービス側一時障害、同期遅延、トークン不整合 | 再ログイン、時間を置く、正常ユーザーAと比較、必要ならサポートへ |
| 特定の端末だけ再現 | 端末側要因（証明書、セキュリティソフト、社内プロキシ） | 別端末・モバイル回線で再現確認、ネットワーク経路の差分確認 |
「自分の環境だけ」ではないかも：サービス正常性の確認も忘れない
まれに、情報保護（ラベル）周辺でサービス側の問題が発生し、特定画面だけ不安定になることがあります。権限やブラウザー切り分けで説明がつかない場合は、Microsoft 365 管理センターのサービス正常性（Service health）も確認し、「同時刻に障害が出ていないか」を押さえておくと、社内説明がスムーズになります。
まず確認するべき権限の場所：Entra ID ロールと Purview の権限は別物
「Purview の権限を付けたのに直らない」場合、付けた場所が違っていることが多いです。感度ラベルに関しては、少なくとも次の観点で確認してください。
チェックすべき権限のレイヤー
| レイヤー | どこで付与するか | 確認のコツ |
|---|---|---|
| Entra ID の管理ロール | Entra 管理センター（ユーザーにロール割り当て） | 「有効な割り当て」か、「PIM でアクティブ化が必要」かを必ず見る |
| Microsoft Purview（コンプライアンス）側の権限 | Purview ポータルの「アクセス許可」/「ロール グループ」 | 役割がロール グループ経由で付与されていると反映に差が出ることがある |
| Azure サブスクリプションの RBAC | Azure ポータル（IAM） | Purview アカウント（リソース）を操作する権限であり、感度ラベル管理とは切り離す |
「ユーザーAはOK、ユーザーBはNG」になりやすい差分
- PIM を使っていて、ユーザーBのロールが未アクティブ（割り当てはあるが“有効化”されていない）
- ユーザーAは直接ロール付与、ユーザーBはグループ経由付与（反映タイミングや適用条件が異なる）
- ユーザーBが別テナントのアカウントでサインインしている（ブラウザーのアカウント切替で起きやすい）
- ユーザーBのみ条件付きアクセスやセッション制御が強く、コンプライアンス側のトークン取得で失敗している
- ユーザーBに必要な管理センターへのアクセス制限（管理ユニット、Privileged Access Group 等）がかかっている
ライセンス確認：ロールが正しくても画面が不安定になることがある
感度ラベル（Microsoft Purview Information Protection）は、テナント契約や利用する機能範囲によって必要ライセンスが変わります。多くの環境では、以下のいずれかのライセンス体系で運用されています。
| ライセンス例 | 想定される運用 | 確認しておきたい点 |
|---|---|---|
| Microsoft 365 E5 / A5 / G5 | 情報保護をフル活用（自動ラベル等も視野） | 管理者・運用担当者が必要機能にアクセスできるか |
| Microsoft 365 E3 ＋ Compliance / 情報保護系アドオン | 段階的に機能拡張しながら運用 | 「どのアドオンがどの機能に効くか」を社内で整理しておく |
| Microsoft Information Protection を含むライセンス | ラベル付け・保護を中心に導入 | 対象ユーザー（運用者・テストユーザー）に割り当て済みか |
管理画面の閲覧だけであればライセンス影響が小さい場面もありますが、実運用では「ラベルを作成・公開して、実際にクライアントで動くか」まで確認するのが普通です。運用担当者がテストできるライセンスを持っていないと、UI では見えても途中でエラーになりやすいため、ロールと合わせてチェックしてください。
テクニカル切り分け：ロール・ライセンスが揃っているのに開けないとき
権限とライセンスを満たしているのに「感度ラベル」ページが真っ白になる、読み込みで止まる、エラー画面になる場合は、クライアント側（ブラウザー）か認証トークンの不整合が疑わしいです。再現率が高い切り分け順をまとめます。
ブラウザー起因の切り分け（最短で効く）
- シークレット（プライベート）ウィンドウで同じ URL を開く
- キャッシュ／Cookie をクリアしてから再ログインする
- 別ブラウザー（Edge / Chrome）で再現するか比較する
- 拡張機能（広告ブロック、スクリプト制御、セキュリティ系）を一時的に無効化して試す
PIM（Privileged Identity Management）利用時の落とし穴
PIM 環境では「ロールを割り当てた＝すぐ使える」ではありません。ユーザーBが PIM 対象の場合、感度ラベルを開く直前にロールをアクティブ化する必要があります。
| チェック項目 | ありがちな状態 | 対処 |
|---|---|---|
| PIM のロール状態 | 「Eligible（割り当て可能）」のまま | Compliance Administrator を「Active」にしてから再アクセス |
| アクティブ化後の反映 | ブラウザーに古いトークンが残る | サインアウト→サインイン、またはシークレットで再試行 |
| 多要素認証・条件付きアクセス | アクティブ化に成功してもセッションが制限される | 管理者用の条件付きアクセス例外設計を検討（ポリシー次第） |
サインインしているアカウント・テナントの確認
特に複数テナントを扱う担当者は、ブラウザーに複数アカウントが混在しがちです。感度ラベルの画面は権限がないと即エラーになりやすいので、次の観点で確認します。
- 右上のアカウント情報で、想定テナントにサインインしているか
- 同じブラウザーで別テナントに切り替えた直後に再現していないか
- ゲストアカウント（B2B）で開こうとしていないか
Purview とテナント構成の注意点：リージョン／マルチジオが絡む場合
Purview を Azure サブスクリプションに作成した場合でも、感度ラベルの実体は Microsoft 365 側サービスに依存します。テナントがマルチジオ構成だったり、Purview アカウントのリージョンが特殊な場合は、一部ユーザーだけ UI で不整合が出ることがあります。
このレイヤーは運用担当者が「画面だけ」で完結しにくい領域ですが、疑うべき状況を挙げます。
- 同じロールを付与しても、ユーザーごとに再現有無が変わる
- 特定のネットワーク（社内／VPN）経由のみで失敗する
- ポータル表示言語やロケーション設定がユーザーによって異なる
| 疑うポイント | 症状の例 | 現場でできる確認 |
|---|---|---|
| サービス側の同期遅延 | ロール付与直後だけ開けない | 時間を置いて再試行、再ログイン、別ブラウザーで比較 |
| テナントの構成差（マルチジオ等） | ユーザー属性や配置で差が出る | 影響ユーザーの共通点（場所、所属、ライセンス）を洗い出す |
| 条件付きアクセス／プロキシ | 特定ネットワークだけ失敗 | 社外回線・モバイル回線で再現するかを比較 |
それでも解決しない場合：サポートへ渡すと早い情報
ロール（Compliance Administrator）付与、ライセンス確認、ブラウザー切り分けをしても改善しない場合は、ポータルから見えないバックエンド要因（トークン不整合、同期不具合、サービス側の状態）を疑います。ここまで来たら、Microsoft 公式サポートへのエスカレーションが現実的です。
問い合わせ時に情報が揃っていると、やり取りが短くなりやすいです。
- 発生ユーザー（ユーザーB）と、正常ユーザー（ユーザーA）の UPN
- 発生日時（できれば複数回）とタイムゾーン
- アクセスしたポータル（Purview のどの URL か）と、遷移手順
- 表示されたエラーメッセージ全文、可能なら「Correlation ID」などの識別子
- 付与済みロール（Compliance Administrator 付与済みであること）と、PIM の有無
- 割り当てライセンスの種類
- ブラウザー種別、拡張機能有無、シークレットでの再現可否
| サポートへ伝える一文（例） | 意図 |
|---|---|
| 「Microsoft Purview の感度ラベル画面が特定ユーザーだけ表示できない。Compliance Administrator 付与済みでも再現する」 | 権限不足ではなく、バックエンド調査が必要な事象として扱ってもらいやすい |
実務で迷わないための「とりあえず」対応手順
同様の相談が来たときに、担当者が短時間で切り分けられるように、現場向けの手順に落とし込みます。
| やること | 目的 | 判断の目安 |
|---|---|---|
| Compliance Administrator を付与 | 最小権限の有力解を即試す | これで開ければ「権限設計」の問題に絞れる |
| 再ログイン／別ブラウザー／シークレットで確認 | トークンやキャッシュ要因を除外 | シークレットで直るならクライアント側が濃厚 |
| PIM のアクティブ化状態を確認 | 「割り当て済みなのに効かない」を潰す | Eligible のままだと再現しやすい |
| ライセンス割り当てを確認 | 機能不足・UI 不安定の可能性を除外 | 運用担当者・テストユーザーに必要ライセンスがあるか |
| 改善しなければサポートへ | ポータル外の要因を調査してもらう | Correlation ID と再現手順があると早い |
よくある質問（現場で詰まりやすいポイント）
Compliance Administrator を付与したのに、すぐ反映されません
ロール付与後、ブラウザーに古い認証情報が残っていると、画面が権限不足のままに見えることがあります。まずはサインアウト→サインイン、またはシークレットウィンドウで再確認してください。PIM 利用時は、ロールが Active になっているかも必ず確認します。
最小権限で運用したいが、Compliance Administrator は広すぎませんか
最小権限の設計は組織のガバナンス方針次第です。ただし、障害切り分けとしては「最小権限の候補を狭める」より「確実に開ける状態を作る」方が先です。まず Compliance Administrator（または一時的に Global Administrator）で開けることを確認し、その後にロールを段階的に落として「どこまで削れるか」を検証すると、結果的に安全で再現性のある最小権限設計に近づけます。
ユーザーBだけエラーになるのは、端末の問題ですか
端末要因（キャッシュ、拡張機能、証明書、プロキシ）は十分あり得ます。一方で、ユーザー単位の条件付きアクセスや、PIM の未アクティブ、ライセンス差分など「アカウント属性」の問題でも同じように見えます。端末要因はシークレット／別ブラウザーで素早く切り分けられるので、まずそこから始めるのが効率的です。
Purview アカウントを Azure で作成したのに、なぜ Microsoft 365 側のロールが必要なのですか
感度ラベルは Microsoft 365 の情報保護機能（Microsoft Purview Information Protection）として提供されており、設定・公開の権限は Entra ID とコンプライアンス基盤の RBAC によって制御されます。Azure サブスクリプションの権限は、あくまで Azure リソースを操作するためのもので、感度ラベル管理の権限とは別レイヤーになります。
「Purview だから Azure 権限だけで良いはず」という前提が崩れるところが、本件の最大の落とし穴です。役割の付与先が正しいか（Entra ID / コンプライアンス側か）を最初に疑うと、遠回りを減らせます。
コメント