2026年5月12日時点で確認すべきポイントは、Microsoft PurviewとMicrosoft Fabricの連携が「データカタログ」「秘密度ラベル」「DLP」「監査」「インサイダーリスク」「Copilot/エージェント」「OneLake catalog」まで広がり、Fabricのデータ資産をPurview側で見つける、分類する、保護する、監査する運用がより重要になったことです。今回のMicrosoft Purviewの更新は、単なる脆弱性修正ではなく、Fabricを全社データ基盤として使う組織が、管理者設定・権限・スキャン・ラベル・DLPポリシーを見直すべき内容です。Microsoft公式情報では、Purviewはデータガバナンス、リスク、コンプライアンスのソリューション群として、Microsoft 365、オンプレミス、マルチクラウド、SaaSのデータサービスを対象にできると説明されています。(Microsoft Learn)
特に注意したいのは、Fabric管理ポータルで読み取り専用Admin APIを許可すると、Fabric内のレポート名、所有者、説明などのメタデータがMicrosoft Purviewに取り込まれ、以後はPurview側の権限でメタデータの可視性が決まる点です。設定を戻しても、すでに抽出されたメタデータは自動削除されません。管理者は「連携できるか」だけでなく、「誰が何のメタデータを見られるようになるか」まで確認してから展開する必要があります。(Microsoft Learn)
Microsoft PurviewとMicrosoft Fabric連携で何が整理されたのか
Microsoft Learnの「Use Microsoft Purview to govern Microsoft Fabric」では、Microsoft PurviewとMicrosoft Fabricを組み合わせることで、Fabricアイテムの検出、メタデータ管理、秘密度ラベル、DLP、監査ログ、インサイダーリスク管理、Fabric Copilotやエージェントのガバナンスまで扱えることが整理されています。Power BIレポートからLakehouse、Warehouse、KQL Database、SQL Database、Semantic modelまで、Fabric上のデータ活用が広がるほど、Purview側の統制設計が重要になります。(Microsoft Learn)
| 領域 | できること | 管理者が見るべきポイント |
|---|---|---|
| Microsoft Purview Unified Catalog | Fabricアイテムのメタデータをカタログで確認し、同一テナントまたはクロステナントのFabric接続を構成できる | Live viewで十分か、スキャン登録が必要かを切り分ける |
| Information Protection | Fabricアイテムに秘密度ラベルを適用し、対応するエクスポート経路でも保護を維持できる | ラベルが対象ユーザーに発行済みか、旧Azure Information Protectionラベルを使っていないかを確認する |
| Protection policies | 秘密度ラベルに基づき、Fabricアイテムへのアクセスを制御できる | ラベル適用者、既存権限、許可グループの関係をテストする |
| DLP | Lakehouse、Warehouse、KQL Database、Mirrored database、SQL Database、Semantic modelなどで機密情報を検出し、通知・アラート・アクセス制限を実行できる | DirectQuery、ライブ接続、Delta形式、分類条件の制限を確認する |
| Audit | Fabricユーザーの操作をMicrosoft Purview監査ログで確認できる | 監査ログ閲覧ロール、検索期間、UTC表示を運用手順に入れる |
| Insider Risk Management | Power BIやLakehouseなどのFabric関連アクティビティをリスク指標として扱える | 退職予定者、外部共有、大量エクスポートなどの検知シナリオを定義する |
| Fabric Copilots and agents | プロンプトや応答、AI生成コンテンツに対するリスク検出、監査、保持、eDiscoveryの適用範囲を整理できる | Copilot利用部門とデータ管理部門の責任分界を決める |
| OneLake catalog | 従来Microsoft Purview Hubで確認していたセキュリティ関連の分析情報が、OneLake catalogのGovernタブで確認できる | Fabric管理者とデータ所有者で見える範囲が異なる点を周知する |
影響範囲は管理者だけでなく、データ所有者と開発者にも及ぶ
今回のポイントは、Microsoft Purview管理者だけで完結しません。Fabric管理者、Microsoft 365コンプライアンス管理者、セキュリティ担当者、データエンジニア、Power BI開発者、データ所有者が同じ前提を共有する必要があります。
| 立場 | 影響を受ける内容 | 具体的に確認すること |
|---|---|---|
| Fabric管理者 | テナント設定、Admin API、OneLake設定、ワークスペース管理 | 読み取り専用Admin APIをどのセキュリティグループに許可するか |
| Purview管理者 | Data Map、Unified Catalog、スキャン、分類、コレクション | Fabricテナントを同一テナントで登録するか、クロステナントで登録するか |
| セキュリティ・コンプライアンス担当 | DLP、秘密度ラベル、監査、インサイダーリスク | DLPポリシーの条件、通知、アラート、アクセス制限を段階展開するか |
| データ所有者 | OneLake catalog、ラベル、DLP警告、メタデータ品質 | 自分のアイテムに説明、所有者、用途、ラベルが付いているか |
| 開発者・データエンジニア | Lakehouse、Warehouse、Notebook、Pipeline、Semantic model | スキャン制限、DLP対象形式、API・自動化処理への影響を確認する |
Fabricのデータ資産は、従来のPower BI中心の運用よりも対象が広くなります。たとえばLakehouseに機密データを取り込むと、DLP評価、秘密度ラベル、OneLake catalog上の可視性、監査ログが関係します。管理者だけが設定して終わりではなく、データ所有者が「どのデータが機密なのか」「誰が利用してよいのか」を明確にしなければ、ポリシーの誤検知やアクセス遮断につながります。
まず確認すべき管理者設定
Microsoft PurviewからFabricを統制する場合、最初に確認すべき設定は「Purviewアカウント」「Fabricテナント」「Microsoft Entra ID」「認証方式」「ネットワーク」「OneLake」の6つです。公式ドキュメントでは、同一テナントのFabricスキャンでManaged Identity、Service Principal、Delegated Authenticationを利用でき、シナリオに応じてAzure Integration Runtime、Self-hosted Integration Runtime、Managed Virtual Network IRを選択できるとされています。(Microsoft Learn)
| 確認項目 | 推奨される確認内容 | 失敗しやすいポイント |
|---|---|---|
| FabricテナントID | 登録時に正しいテナントIDを指定する | 同一テナント前提で自動入力されたIDを、クロステナント環境で見落とす |
| Fabricメタデータモデル | メタデータスキャンが有効か確認する | スキャンしても期待した詳細メタデータが出ない |
| 読み取り専用Admin API | 「Allow service principals to use read-only admin APIs」を対象セキュリティグループに限定する | 全体に広く許可しすぎる |
| 詳細メタデータ応答 | 詳細メタデータやDAX・mashup式に関するAdmin API応答の設定を確認する | 取得対象を理解せずに有効化する |
| OneLake外部アクセス | 「Users can access data stored in OneLake with apps external to Fabric」を確認する | PurviewからOneLake関連の確認ができない |
| Key Vault | シークレット名、値、get/list権限を確認する | Service Principalや委任認証の接続テストで失敗する |
| ネットワーク | PurviewとFabricのパブリックアクセス可否、IRの種類を確認する | private link構成との相性を誤解する |
Fabric管理ポータルでAdmin API設定を変更した後は、スキャン登録や接続テストの前に反映待ちが必要です。公式ドキュメントでは、FabricテナントのAdmin API設定更新後、スキャン登録と接続テストの前に約15分待つよう案内されています。(Microsoft Learn)
Live viewとスキャンを混同しない
Microsoft PurviewのLive viewは、同一テナントの一部リソースについて、スキャン設定なしでカタログ上にメタデータを表示できる機能です。FabricについてはWorkspaceとItemがLive viewの対象に含まれますが、公式情報ではこの機能はプレビューであり、個人用ワークスペースは未対応、Fabricではアイテムレベルのメタデータのみ利用可能、スキャンされていないPower BI Datasetではスキーマ表示に制限があるとされています。(Microsoft Learn)
重要なのは、Live viewだけでは自動分類が付かないことです。分類を自動適用したい場合は、Microsoft PurviewのEnterprise版でリソースを登録し、スキャンを実行する必要があります。また、Live viewの権限拡張はFabricソースでは利用できないため、「Fabricのメタデータを全員に見せるためにLive view権限を拡張する」といった設計はできません。(Microsoft Learn)
実務では、次のように使い分けると判断しやすくなります。
| 目的 | 選ぶべき方法 | 理由 |
|---|---|---|
| まずFabricアイテムの存在を把握したい | Live view | 追加設定を抑えて、カタログ上で概況を確認しやすい |
| メタデータ、リネージ、分類を本格管理したい | 登録とスキャン | 分類や詳細なガバナンス運用に進められる |
| クロステナントのFabricを管理したい | クロステナント接続とスキャン | Live viewは同一テナント向けのため |
| データ品質、データ製品、用語集まで整備したい | Unified Catalog中心の運用 | カタログ運用とデータ所有者の作業を結び付けやすい |
同一テナントとクロステナントで設計が変わる
Microsoft PurviewアカウントとFabricテナントが同じMicrosoft Entraテナントにある場合、Managed Identityを使った構成を選べます。公式情報では、Fabric LakehouseのスキャンでManaged Identityが利用可能になり、Managed Virtual Network IRによるFabric Lakehouseスキャンも利用可能になったと説明されています。これは、サービスプリンシパルのシークレット管理を避けたい組織にとって、運用負荷を下げる可能性があります。(Microsoft Learn)
一方、クロステナント接続では、Service PrincipalまたはDelegated Authenticationを使います。クロステナントの公式サポート表では、メタデータ抽出、フルスキャン、増分スキャン、スコープ指定スキャン、リネージはサポートされる一方、分類、ラベル付け、アクセスポリシー、データ共有、Live viewはサポート対象外として整理されています。(Microsoft Learn)
| 構成 | 向いているケース | 注意点 |
|---|---|---|
| 同一テナント + Managed Identity | PurviewとFabricを同じ組織テナントで運用している | PurviewのManaged Identityをセキュリティグループに追加する |
| 同一テナント + Service Principal | 自動化や既存のアプリ登録を使いたい | Key Vault、Client ID、シークレット、API権限を厳密に管理する |
| 同一テナント + Delegated Authentication | Fabric管理者ユーザーを使って接続する必要がある | MFAや条件付きアクセスがあると要件に合わない場合がある |
| クロステナント + Service Principal | グループ会社や別テナントのFabricを統制したい | アプリ登録をマルチテナントとして設計し、対象テナント側の同意を確認する |
| クロステナント + Delegated Authentication | 一時的な接続検証や限定的な運用 | 管理者ユーザーの取り扱い、条件付きアクセス、監査を事前に決める |
Delegated Authenticationは便利に見えますが、公式チェックリストでは、対象ユーザーがFabric Administratorであること、初回サインイン済みであること、MFAや条件付きアクセスが強制されていないことが確認項目に含まれています。セキュリティ要件が厳しい組織では、Managed IdentityまたはService Principalを優先し、委任認証を使う場合は専用アカウント、保管場所、監査手順を明確にしておくべきです。(Microsoft Learn)
DLPは「作成して終わり」ではなく、対象形式と制限の確認が必須
Microsoft Purview DLP for Fabric and Power BIは、Semantic model、Lakehouse、Warehouse、KQL Database、Mirrored database、SQL Databaseをサポート対象としており、ポリシー一致時にはポリシーヒント、管理者アラート、メール通知、アクセス制限を実行できます。アクセス制限はプレビューとして提供され、条件に一致した場合にデータ所有者または組織内メンバーにアクセスを限定する構成が可能です。(Microsoft Learn)
ただし、DLPはすべてのFabricデータに万能に効くわけではありません。公式情報では、DLPポリシーはFabricまたはPremium容量でホストされたワークスペースに適用され、Fabric向けDLPポリシーテンプレートはサポートされないためカスタムポリシーを選ぶ必要があります。また、DirectQueryやライブ接続を使うSemantic model、サンプルSemantic model、streaming datasetはサポート対象外です。(Microsoft Learn)
LakehouseやWarehouseを扱うデータエンジニアは、Delta形式の制限も確認してください。DLP for FabricはDelta形式のテーブル内データに適用されますが、Binary、Struct、Array、Map、Jsonなど一部のDelta Parquetデータ型や、LZ4、Zstd、Gzip圧縮コーデックのデータはサポート対象外です。EDM、trainable classifier、credential classifier、named entitiesなどの高度な分類子もFabric DLPではサポートされないため、条件に指定しても期待どおり検出されない場合があります。(Microsoft Learn)
DLP展開時は、最初から全社にアクセス制限を適用するのではなく、次の順序で進めると事故を減らせます。
| フェーズ | 実施内容 | 成功基準 |
|---|---|---|
| 検出フェーズ | 対象ワークスペースを限定し、ポリシーヒントとアラートだけを有効化する | 誤検知、対象外データ型、通知先を把握できる |
| 調整フェーズ | 秘密度ラベル、機密情報の種類、しきい値を調整する | 業務上問題ないデータが過剰に検出されない |
| 制限フェーズ | 高リスクデータに限定してアクセス制限をテストする | データ所有者、管理者、利用者の復旧手順が確認できる |
| 本番展開 | 容量、ワークスペース、部門ごとに段階展開する | アラート対応フローと監査ログ確認が定着する |
秘密度ラベルとProtection policiesは権限設計とセットで見る
FabricとPower BIのInformation Protectionでは、Microsoft Purview Information Protectionの秘密度ラベルとポリシーを使って、機密データの分類と保護を行います。利用前には、適切なライセンス、対象ユーザーやグループへのラベル発行、Power BIアイテムにラベルを適用するユーザーのライセンス要件を確認する必要があります。Azure Information Protectionの秘密度ラベルを使っている組織は、Fabricで利用するためにMicrosoft Purview Information Protectionの統合ラベルプラットフォームへ移行する必要があります。(Microsoft Learn)
Protection policies for Fabricは、秘密度ラベルに関連付けられたポリシーによって、指定されたユーザーやグループが既存の権限を保持できるようにし、それ以外のユーザーをブロックします。ここで重要なのは、Protection policyが新しい権限を付与する仕組みではなく、既存権限を前提にアクセスを制御する仕組みであることです。また、ラベルを最後に適用したユーザーは、ポリシーに含まれていなくてもそのアイテムへのアクセスを拒否されないという例外があります。(Microsoft Learn)
実務では、ラベル名だけで設計しないことが重要です。たとえば「Confidential」というラベルを用意しても、誰がそのラベルを適用できるのか、ラベル適用時にどのProtection policyが動くのか、既存のワークスペース管理者やメンバーがどう扱われるのかを確認しなければ、意図しないアクセス遮断や、逆に過剰な閲覧許可が起きます。
監査ログとインサイダーリスク管理で確認すべきこと
Microsoft Fabricのユーザー操作はMicrosoft Purviewの監査ログで追跡できます。公式情報では、Fabricで「誰が、どのアイテムに、何をしたか」を把握することは、規制対応や記録管理の要件を満たすうえで重要とされています。監査ログにアクセスするには、Exchange OnlineのAudit Logsロールが必要で、検索では日時範囲、アクティビティ、ユーザー、ファイル名やURLなどのフィルターを利用できます。(Microsoft Learn)
監査運用で見落としやすいのは、ログの時刻表示です。Microsoft Purviewで監査ログを検索する際、日時はUTC形式で表示されます。日本国内の運用では、インシデント対応の時刻、管理者への報告時刻、業務部門からの問い合わせ時刻をJSTに変換して照合する手順を用意しておくと、調査の行き違いを防げます。(Microsoft Learn)
Insider Risk Managementでは、ポリシー指標とトリガーイベントの理解が欠かせません。公式ドキュメントでは、トリガーイベントがないユーザーはポリシー上の潜在リスクとして評価されないこと、グローバル設定で有効にした指標がポリシーで利用可能な指標や収集シグナルを定義することが説明されています。FabricのPower BIエクスポートやLakehouse・Warehouse関連のデータ移動をリスクシナリオに入れる場合は、DLPアラート、退職予定者、高権限ユーザーなどの条件と組み合わせて設計するのが現実的です。(Microsoft Learn)
OneLake catalogのGovernタブは管理画面として使える
公式情報では、従来Microsoft Purview Hubで利用できたセキュリティ分析情報が、OneLake catalogのGovernタブで確認できるようになったと説明されています。Governタブでは、Fabric内のデータガバナンス状態を評価し、改善のための推奨アクションや関連ツールへのリンクを確認できます。(Microsoft Learn)
Fabric管理者がGovernタブを見る場合、ワークスペース、容量、ドメインを含むテナント全体のメタデータに基づく分析情報が表示されます。一方、データ所有者は自分が所有するアイテムを中心に確認します。管理者向けの分析情報はAdmin Monitoring Storageの最終更新データを使い、データ所有者向けの情報はGovernタブを開いた際の更新や手動更新で最新化できます。(Microsoft Learn)
つまり、OneLake catalogは単なる一覧画面ではありません。管理者にとっては「どのドメインのデータ統制が遅れているか」を見る画面であり、データ所有者にとっては「自分のアイテムにラベル、説明、所有者、品質情報が整っているか」を確認する作業画面です。展開時には、管理者だけでなくデータ所有者にもGovernタブの見方を説明しておくと、メタデータ整備が進みやすくなります。
開発者・データエンジニアが注意すべき技術的な落とし穴
Fabricのスキャンでは、Power BI以外のFabricアイテムについて、基本的にアイテムレベルのメタデータとリネージが対象です。Lakehouseのテーブルやファイルではサブアイテムレベルのメタデータスキャンに対応しますが、サブアイテムレベルのリネージはサポートされません。空のワークスペースはスキップされ、Fabric DAX expressionsはメタデータスキャン対象外です。(Microsoft Learn)
複数のFabricスキャンやPower BIスキャンを同時に実行すると、Too many requestsエラーが発生する可能性があります。公式ドキュメントでは、その場合は同時実行スキャンを減らし、スキャン時間を分散することが推奨されています。増分スキャンでは、データソースに変更がない場合でも、取り込み済み資産数や検出済み資産数が0以外で表示される場合があるため、単純な件数だけで異常判断しないようにしましょう。(Microsoft Learn)
Lakehouseでスキーマ有効データベースを使う場合も注意が必要です。公式情報では、スキーマ名とテーブル名がData Map上のqualified nameで%252Fを区切りとして結合されると説明されています。たとえば、OneLakeパス上でTables/dbo/my_tableにあるテーブルは、Data Mapではdbo%252Fmy_tableのような形を含むqualified nameになります。自動化スクリプトや外部台帳でPurviewのqualified nameを照合している場合は、文字列一致ロジックを見直す必要があります。(Microsoft Learn)
移行・展開前のチェックリスト
Microsoft PurviewでMicrosoft Fabricを統制する展開は、いきなり全社適用せず、小さな対象から検証するのが安全です。特に秘密度ラベル、DLP、Protection policiesは、設定ミスが業務停止につながる可能性があります。
| チェック | 確認内容 | 完了の目安 |
|---|---|---|
| 対象棚卸し | Fabricワークスペース、容量、ドメイン、所有者、データ種別を一覧化する | 高リスクデータと対象外データを区別できている |
| 権限設計 | Fabric権限、Purviewコレクション権限、Microsoft Entraセキュリティグループを整理する | メタデータを見られる人とデータを見られる人を分けて説明できる |
| 認証方式 | Managed Identity、Service Principal、Delegated Authenticationのどれを使うか決める | シークレット管理、監査、条件付きアクセスの方針が決まっている |
| スキャン設計 | Live view、フルスキャン、増分スキャン、スコープ指定スキャンの使い分けを決める | スキャン頻度と同時実行数を制御できる |
| ラベル移行 | Azure Information Protectionラベル利用有無を確認する | Purview統合ラベルとして利用できる状態になっている |
| DLP検証 | 対象アイテム、データ型、条件、通知、アラートをテストする | 誤検知とアクセス制限時の復旧手順が確認済み |
| 監査運用 | Audit Logsロール、検索条件、UTC/JST変換、PowerShell利用有無を決める | インシデント時に誰がログを確認するか決まっている |
| データ所有者教育 | OneLake catalogのGovernタブ、DLP警告、ラベル運用を説明する | 所有者が自分のアイテムを改善できる |
よくある疑問
Microsoft Purviewを有効化すればFabricの権限管理は不要になる？
不要にはなりません。Microsoft Purviewは、Fabricのデータ資産を発見、分類、保護、監査するための統制基盤です。Protection policiesやDLPでアクセス制限を行える場面はありますが、Fabricワークスペース、アイテム、OneLake Security、Microsoft Entra IDの権限設計は引き続き必要です。
Live viewだけで十分？
棚卸しの第一歩としては有効ですが、本格的な分類、自動スキャン、詳細メタデータ管理まで行うなら、登録とスキャンを設計する必要があります。Live viewはプレビューであり、Fabricでは個人用ワークスペース未対応、アイテムレベルメタデータ中心、自動分類なしといった制限があります。(Microsoft Learn)
開発者側でコード修正は必要？
多くの場合、アプリケーションコードの大規模移行は不要です。ただし、Purview Data Mapのqualified nameを使って自動照合している場合、Lakehouseのスキーマ付きテーブル名の扱いに注意が必要です。また、DLPやProtection policiesの展開後は、これまでアクセスできたデータに制限がかかる可能性があるため、Pipeline、Notebook、Semantic modelの実行ユーザーやサービスプリンシパルを確認しておくべきです。(Microsoft Learn)
DLPはすぐアクセス制限まで有効化してよい？
最初はポリシーヒントとアラートから始めるのが安全です。Fabric DLPには対象アイテム、Delta形式、データ型、分類子、容量、リージョンなどの制限があります。検出条件の妥当性を確認する前にアクセス制限を有効化すると、業務で必要な利用者までブロックされる可能性があります。(Microsoft Learn)
管理者が次に取るべき行動
まず、Fabric管理者とPurview管理者で対象ワークスペースを1つ選び、Live viewで見える範囲、スキャンで取得できるメタデータ、秘密度ラベル、DLP検出、監査ログの出力を確認してください。そのうえで、読み取り専用Admin APIを許可するセキュリティグループ、Purviewコレクション権限、DLPポリシーの通知先、OneLake catalogの運用担当を決めるのが現実的です。
今回のMicrosoft PurviewとMicrosoft Fabricの更新で重要なのは、「FabricのデータをPurviewで見えるようにする」ことではありません。見えるようになったメタデータや機密データを、誰が管理し、誰が利用し、どの条件で制限し、どのログで説明責任を果たすかを決めることです。小さく検証し、権限とポリシーを文書化し、データ所有者にOneLake catalogのGovernタブを使ってもらうところから始めると、ガバナンスを業務に定着させやすくなります。
コメント