Microsoft Purviewの権限設計で迷いやすいのは、「誰に何を見せるか」だけでなく、「Data Map、Unified Catalog、Microsoft Entra ID、Azure／Microsoft Fabric側の権限がどこで効くのか」が重なっている点です。
2026年4月24日に更新された公式ドキュメント「Data Governance Roles and Permissions in Microsoft Purview」でまず押さえるべき結論は、Microsoft Purviewのデータガバナンス権限は新しいMicrosoft PurviewポータルとUnified Catalogを前提に、Data Map、Unified Catalog、既存のデータアクセス権限を組み合わせて管理する設計になっているという点です。旧来のClassic Data Catalogや従来ポータルの権限とは分けて確認する必要があります。(Microsoft Learn)
なお、Microsoft Learnの当該ページには旧版との差分表は掲載されていません。そのため、ここでは2026年4月24日更新版で明示されている権限設計上の重要ポイントを、security admins、identity teams、compliance teamsが実務で確認すべき観点に絞って整理します。(Microsoft Learn)
Microsoft PurviewのData Governance Roles and Permissionsで確認すべき更新ポイント
今回の更新版で最も重要なのは、Microsoft Purviewのデータガバナンス権限を「単一の管理者ロール」ではなく、複数レイヤーの組み合わせとして理解することです。
Microsoft Purview data governanceには、Data MapとUnified Catalogという2つの主要ソリューションがあります。これらは、テナントまたは組織レベルの権限、既存のデータアクセス権限、ドメイン／コレクション単位の権限を組み合わせて、ユーザーがガバナンスツールやデータ資産へアクセスできるようにします。(Microsoft Learn)
実務では、次のように整理すると判断しやすくなります。
| 観点 | 何を管理するか | 主な確認ポイント |
|---|---|---|
| テナント／組織レベル | Purview全体やデータガバナンスの管理権限 | Purview Administrators、Data Source Administrators、Data Governanceの割り当て |
| Unified Catalog | ガバナンスドメイン、データ製品、用語、データヘルスなど | Catalog levelとGovernance domain levelの権限分離 |
| Data Map | データ資産、ソース、スキャン、コレクション | Data Map側の閲覧権限がUnified Catalog検索結果に影響する |
| 既存リソース権限 | AzureやMicrosoft Fabricなどの実データ側の権限 | Read権限を持つユーザーが想定以上に資産を見つけられる可能性 |
| Microsoft Entra ID | 管理者ロール、ID、グループ管理 | EntraロールとPurviewロールの優先関係を確認 |
単純に「Purviewのロールを付ければ完了」と考えると、検索結果にデータ資産が出ない、逆に見せたくない資産が見える、ドメイン内でロールを委任できない、といった問題が起きやすくなります。
対象は新しいMicrosoft PurviewポータルとUnified Catalog
今回の公式ドキュメントは、新しいMicrosoft PurviewポータルでMicrosoft Purview Unified Catalogを使う場合のデータガバナンス権限を対象にしています。Classic Data Catalogや従来のMicrosoft Purviewガバナンスポータルを使っている場合は、別の権限ドキュメントを確認する必要があります。(Microsoft Learn)
ここは移行中の組織ほど見落としやすいポイントです。
たとえば、以前のData Catalog運用で「カタログ閲覧者」「キュレーター」「コレクション管理者」のような考え方に慣れている場合でも、Unified Catalogではガバナンスドメイン、データ製品、データヘルス、データ品質などの権限がより細かく分かれます。
まず確認すべきことは、現在の環境が無料アカウントなのか、エンタープライズアカウントなのかです。Microsoft PurviewポータルのSettingsからAccount typeを確認でき、利用できる権限の種類はアカウントタイプによって変わります。(Microsoft Learn)
権限設計の基本は「最小権限」と「役割の分離」
Microsoftは、Microsoft Purviewの権限設計でも最小権限の利用を推奨しています。特にGlobal Administratorの人数を最小化することは、組織全体のセキュリティを高めるうえで重要です。(Microsoft Learn)
実務上は、次のように役割を分けると運用しやすくなります。
| 担当者 | 付与を検討する権限 | 判断基準 |
|---|---|---|
| Purview全体の管理者 | Purview Administrators | ドメイン作成、編集、削除、ロール割り当てまで担当する場合 |
| データソース管理者 | Data Source Administrators | ソース登録、スキャン、資格情報、データソース管理を担当する場合 |
| データガバナンス運用責任者 | Data Governance | Governance Domain Creatorなどの上位権限委任が必要な場合 |
| ドメイン責任者 | Governance Domain Owner | 特定ドメイン内でロール委任、データ製品、ポリシー、品質設定を管理する場合 |
| データ製品責任者 | Data Product Owner | 特定ドメイン内でデータ製品を作成、更新、管理する場合 |
| データスチュワード | Data Steward | 用語、成果物、ポリシー、データ製品の実務運用を担う場合 |
| 閲覧ユーザー | Global Catalog ReaderまたはLocal Catalog Reader | 公開済み概念をどの範囲で見せるかに応じて選択 |
「管理者だから全部付ける」ではなく、「どの範囲で、何を、どこまで操作する必要があるか」を先に決めるのがポイントです。
Unified Catalogの権限は3階層で考える
Unified Catalogの権限は、大きく3階層で構成されています。公式ドキュメントでは、データガバナンスのテナントレベル、カタログレベル、ガバナンスドメインレベルの3つが示されています。(Microsoft Learn)
| 階層 | 主な役割 | 実務での使いどころ |
|---|---|---|
| データガバナンス テナントレベル | Data Governance Administrator | Governance Domain Creatorなど、カタログレベル権限の初期委任 |
| Catalog level | Governance Domain Creator、Global Catalog Reader、Data Health Owner、Data Health Reader | ドメイン作成、全体閲覧、データヘルス管理 |
| Governance domain level | Governance Domain Owner、Data Product Owner、Data Steward、Local Catalog Readerなど | 特定ドメイン内のデータ製品、用語、品質、ポリシー管理 |
重要なのは、Data Governance AdministratorがUnified Catalog内に見える通常ロールではなく、Unified Catalogで権限を割り当てる能力に影響する上位の権限である点です。権限設計を調査するときは、Unified Catalogの画面だけでなく、Microsoft Purviewポータル側のロールグループも確認する必要があります。
Unified Catalog検索は「Catalog権限だけ」では決まらない
Unified Catalogで検索できるかどうかは、Catalog側の権限だけで決まりません。公式ドキュメントでは、Unified Catalogの検索自体に特定のUnified Catalog権限は不要とされていますが、検索結果にはData Mapで表示権限を持つ関連データ資産だけが返ると説明されています。さらに、AzureやMicrosoft Fabricリソースに対するRead権限も、資産の見え方に影響します。(Microsoft Learn)
これは、権限設計で最も誤解されやすい部分です。
たとえば、ユーザーAにUnified Catalogの閲覧ロールを付与しても、Data Map側で対象資産を読めなければ、期待したデータ資産が検索結果に出ない可能性があります。逆に、Azure側でRead権限を持っているユーザーは、Purview側で明示的に意図していない資産へアクセスできる可能性があります。
実務では、次の観点で確認してください。
| 症状 | 確認すべき場所 | よくある原因 |
|---|---|---|
| Unified Catalogで資産が見つからない | Data Mapのドメイン／コレクション権限 | Data Reader相当の権限が不足している |
| データ製品は見えるが資産を追加できない | Data Map権限とGovernance domain権限 | Data Product OwnerまたはData StewardにData Map閲覧権限がない |
| 想定外の資産が検索に出る | Azure／Microsoft Fabric側のRead権限 | 実データ側の権限が広すぎる |
| 権限を付けたのに反映されない | Microsoft Entra IDとPurview側の反映状況 | 新規Entra IDユーザーの権限伝播に時間がかかっている |
特にidentity teamsは、Purview側のロールだけでなく、Azure RBAC、Microsoft Fabric権限、Entra IDグループのメンバーシップまで含めて棚卸しする必要があります。
Global Catalog ReaderとLocal Catalog Readerの違い
2026年4月更新版で実務上とくに重視したいのが、Global Catalog ReaderとLocal Catalog Readerの使い分けです。
Global Catalog Readerは、公開されたガバナンスドメインの公開済みビジネス概念へ広くアクセスできるロールです。一方、Local Catalog Readerは特定のガバナンスドメイン内で公開済み概念を読める範囲を大きく制限するロールです。公式ドキュメントでは、規制や法的要件によってドメインへのアクセス制限が必要な場合にLocal Catalog Readerが有用である一方、過剰に使うとフェデレーション型データガバナンスを妨げる可能性があると説明されています。(Microsoft Learn)
判断基準はシンプルです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Global Catalog Reader | 社内の多くのユーザーに、公開済みデータ製品やビジネス用語を見つけてもらいたい | 見える範囲が広くなるため、公開前レビューが重要 |
| Local Catalog Reader | 法務、医療、金融、人事など、閲覧範囲を厳密に分けたいドメイン | 使いすぎるとデータ発見性が落ち、部門横断の活用が進みにくい |
おすすめは、通常の業務データはGlobal Catalog Readerを基本にし、規制対応や契約上の制約があるドメインだけLocal Catalog Readerを使う設計です。Local Catalog Readerを乱用すると、「安全だが誰もデータを見つけられないカタログ」になりやすいためです。
Governance Domain Ownerは最低2名を割り当てる
公式ドキュメントでは、データガバナンスまたはUnified Catalogを運用する組織のユーザーがGovernance Domain Ownerを持つべきであり、少なくとも2名をGovernance Domain Ownerとして割り当てることが推奨されています。Governance Domain Ownerは、ガバナンスドメイン、データ製品、用語集用語などを構築するうえで不可欠なロールです。(Microsoft Learn)
これは単なる冗長化ではありません。
1名だけにすると、休職、異動、退職、アカウント無効化、緊急対応時にドメイン内の権限委任やポリシー変更が止まります。security adminsとcompliance teamsは、特権ID管理の観点からも、ドメインごとに最低2名の責任者を置き、定期的に妥当性を確認するべきです。
実務では次のルールを推奨します。
| ルール | 理由 |
|---|---|
| 各ガバナンスドメインにOwnerを2名以上置く | 単一障害点を避ける |
| Ownerは個人ではなく職務に基づいて選ぶ | 異動時の引き継ぎを容易にする |
| 四半期ごとにOwner一覧を確認する | 退職者、異動者、不要権限を除去する |
| 緊急用のGlobal Administrator常用を避ける | 最小権限を維持する |
Data QualityとData Profileのロールは「サブロール」に注意
Unified Catalogでは、Data QualityやData Profile関連のロールも整理されています。Data Profile Reader、Data Profile Steward、Data Quality Metadata Reader、Data Quality Reader、Data Quality Stewardなどは、それぞれ閲覧、ジョブ実行、品質ルール管理、スキャン、しきい値やアラート設定などで権限範囲が異なります。(Microsoft Learn)
重要なのは、これらの多くが単独で完結するロールではなく、Governance Domain ReaderやGlobal Catalog Reader／Local Catalog Reader、Data Product Ownerなどの併用を必要とするサブロールとして説明されている点です。(Microsoft Learn)
たとえば、データ品質の分析情報を見せたいだけならData Quality Reader系を検討できますが、品質ルールの管理やスキャン実行まで任せるならData Quality Stewardが候補になります。ただし、品質スキャンの実行権限を安易に広げると、不要なジョブ実行や運用コスト増につながる可能性があります。
| やりたいこと | 検討するロール | 注意点 |
|---|---|---|
| データ品質の結果を確認したい | Data Quality Reader、Data Quality Metadata Reader | 実行権限までは付けない |
| データプロファイルの統計を確認したい | Data Profile Reader | 列レベル情報の閲覧範囲に注意 |
| プロファイリングジョブを実行したい | Data Profile Steward | 必要な上位ロールとの組み合わせを確認 |
| 品質ルール管理やスキャンを行いたい | Data Quality Steward | 実行対象、スケジュール、アラート設定の責任者を明確にする |
Data ObservabilityはUnified Catalogのロール設計に含めて考える
Data Observabilityは、Unified Catalogの他の機能と同じロールを使います。公式ドキュメントでは、Catalog ReaderはData Observabilityの広範なエクスプローラービューにはアクセスできず、公開済み概念のみ表示できると説明されています。一方、Data Steward、Data Product Owner、Governance Domain Owner、Governance Domain Creatorは、表示可能な概念とデータヘルス管理ビューの両方でData Observabilityビューにアクセスできます。(Microsoft Learn)
つまり、Data Observabilityを導入する場合も、「監視ダッシュボードだけ別権限で見せる」という発想ではなく、Unified Catalog全体のロール設計の中で扱う必要があります。
compliance teamsがデータ品質やデータヘルスを確認するだけなら、Data Health Readerなどの読み取り系ロールを検討します。改善アクションやレポート作成まで担う場合は、Data Health OwnerやData Stewardとの組み合わせを検討するのが現実的です。
Data Product OwnerとData StewardにはData Map権限も必要
Data Product OwnerやData Stewardを付けたのに、データ資産をデータ製品へ追加できない。このトラブルは、Unified Catalog側の権限だけを見ていると起きやすくなります。
公式ドキュメントでは、Data Product OwnerとData Stewardがデータ資産をデータ製品に追加するには、Data Mapでそのデータ資産を読み取るためのData Map権限も必要だと説明されています。(Microsoft Learn)
実務では、次のようにセットで確認してください。
| 役割 | Unified Catalog側で必要なもの | Data Map側で必要なもの |
|---|---|---|
| Data Product Owner | データ製品の作成、更新、読み取り | 追加対象資産を読める権限 |
| Data Steward | 成果物、ポリシー、関係性の管理 | 対象資産を読める権限 |
| Governance Domain Owner | ドメイン内の権限委任、品質設定、アクセスポリシー | 必要に応じて対象コレクションへのアクセス |
| 一般閲覧者 | Catalog Reader系の権限 | 検索対象資産の閲覧権限 |
Data Mapでは、ドメインとコレクションを使って資産、ソース、成果物を階層化し、アクセス制御を管理します。Unified Catalogの運用担当者にData Map権限を適切に付けることは、データ製品の作成や資産キュレーションを止めないために重要です。(Microsoft Learn)
Microsoft Entra IDロールの優先関係も確認する
identity teamsが見落としてはいけないのが、Microsoft Entra IDのロールとMicrosoft Purview側のスコープ付きロールの関係です。
Microsoft Purviewポータルの権限ドキュメントでは、Entraロールとスコープ付きMicrosoft Purviewロールグループ割り当ての両方が存在する場合、実行時にはEntraロールが優先され、スコープ付き割り当てがあっても有効なアクセス許可がスコープなしになる場合があると説明されています。(Microsoft Learn)
これは、Administrative Unitで範囲を絞ったつもりでも、Entra側で広いロールを持っているユーザーには、想定より広いアクセスが残る可能性があるという意味です。
確認すべきポイントは次の3つです。
| 確認項目 | 見る場所 | 理由 |
|---|---|---|
| Entra管理者ロール | Microsoft Entra管理センター | Purview側のスコープ制限を上書きする可能性がある |
| Purviewロールグループ | PurviewポータルのRoles and scopes | 実際に付与されているPurview権限を確認する |
| グループメンバーシップ | Entra IDグループ | 間接的な権限付与を見落とさないため |
security adminsは、Global Administrator、Compliance Administrator、Global Readerなどの広範なロールを持つユーザーを定期的に棚卸しし、日常運用ではより限定的なPurviewロールへ置き換えることを検討すべきです。
チーム別に見る実務アクション
今回の更新版を受けて、各チームがすぐ確認すべき作業は次のとおりです。
| チーム | すぐ確認すべきこと | 目的 |
|---|---|---|
| security admins | Global Administrator、Purview Administrators、Role Management保持者の棚卸し | 特権ロールの過剰付与を防ぐ |
| identity teams | Entra IDロール、Purviewロールグループ、グループメンバーシップの突合 | 有効権限とスコープのズレをなくす |
| compliance teams | Local Catalog Readerが必要なドメインの特定 | 規制・契約・法務要件に沿った閲覧制限 |
| data governance leads | Governance Domain Ownerを各ドメイン2名以上にする | 権限委任と運用継続性を確保 |
| data stewards | Data Map権限とUnified Catalog権限の両方を確認 | データ製品作成や資産追加の失敗を防ぐ |
| platform admins | アカウントタイプ、ポータル種別、Classic利用有無を確認 | 参照すべき権限ドキュメントを間違えない |
特に大規模組織では、Purviewの画面だけを見ても実効権限は判断できません。Entra ID、Azure、Microsoft Fabric、Purview Data Map、Unified Catalogを横断して確認する必要があります。
権限見直しの進め方
Microsoft PurviewのData Governance Roles and Permissionsを見直すときは、いきなりロールを変更するのではなく、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | 利用中のPurviewポータルとアカウントタイプを確認する | 対象範囲の明確化 |
| 2 | 既存のEntra IDロールとPurviewロールグループを棚卸しする | 特権ロール一覧 |
| 3 | ガバナンスドメインごとのOwner、Steward、Readerを整理する | ドメイン別権限マップ |
| 4 | Data Mapのコレクション権限とUnified Catalogの権限を突合する | 資産閲覧と製品管理の整合性確認 |
| 5 | Global Catalog ReaderとLocal Catalog Readerの使い分けを決める | 閲覧範囲ポリシー |
| 6 | Data Quality、Data Profile、Data Healthの運用担当を決める | 監視・品質管理ロール表 |
| 7 | テストユーザーで検索、閲覧、データ製品追加、アクセス要求を検証する | 権限検証結果 |
| 8 | 四半期ごとのレビューサイクルを設定する | 継続的な権限管理プロセス |
この順序なら、「付けたはずの権限が効かない」「見えないはずの資産が見える」「誰もドメイン権限を委任できない」といった問題を事前に発見できます。
よくある失敗と回避策
Microsoft Purviewの権限設計では、次の失敗がよく起きます。
| 失敗 | 原因 | 回避策 |
|---|---|---|
| Purview管理者を増やしすぎる | すぐ作業できるように広い権限を付けてしまう | 作業別にData Governance、Data Source Administrators、Governance Domain Ownerへ分ける |
| Unified Catalogだけ見て権限判断する | Data MapやAzure側の権限を見落とす | 検索・閲覧・資産追加はData Map権限も確認する |
| Local Catalog Readerを多用する | 閲覧制限を強めすぎる | 規制対象ドメインに限定し、通常ドメインはGlobal Catalog Reader中心にする |
| Governance Domain Ownerが1名だけ | 担当者依存の運用になる | 各ドメイン最低2名を割り当てる |
| Entraロールの広い権限に気づかない | Purview側のスコープだけ見ている | Entraロールの優先関係を含めて確認する |
| 新規ユーザーの権限確認を急ぎすぎる | Entra IDの権限反映に時間がかかる場合がある | 反映待ちを考慮し、即時に二重付与しない |
権限トラブルの多くは、ロール名の理解不足ではなく、レイヤー間の関係を見落とすことで起きます。特に「検索できるか」「資産を追加できるか」「ドメイン内で委任できるか」は、それぞれ効いている権限が異なるため、個別に検証してください。
まとめ：2026年4月更新版を読むなら、ロール一覧より権限のつながりを見る
Microsoft Purviewの「Data Governance Roles and Permissions in Microsoft Purview」2026年4月24日更新版で重視すべき点は、ロール名を暗記することではありません。
重要なのは、Data Map、Unified Catalog、ガバナンスドメイン、既存のAzure／Microsoft Fabric権限、Microsoft Entra IDロールがどのようにつながっているかを理解し、最小権限で設計することです。
まずは、現在のPurview環境が新しいポータルとUnified Catalogを使っているかを確認してください。そのうえで、特権ロール、Governance Domain Owner、Catalog Reader、Data Map権限、Entra IDロールを棚卸しします。最後に、テストユーザーで検索、閲覧、データ製品追加、データ品質確認まで検証すれば、実運用での権限ミスを大きく減らせます。
コメント