Microsoft PurviewでMicrosoft Dataverseを管理対象にする場合、最初に押さえるべき結論は明確です。Dataverse環境をPurviewに登録し、スキャン用の認証を正しく構成すれば、環境やテーブル、列などの技術メタデータをData Mapに取り込み、Unified Catalogで検索・確認できるようになります。一方で、増分スキャンは未対応で、削除済みオブジェクトがPurview側から自動削除されないなど、運用設計で見落としやすい制限もあります。(Microsoft Learn)
この記事では、Microsoft PurviewでDataverseを接続・管理する際の変更点、影響範囲、管理者や開発者が確認すべき設定、移行・展開時の注意点を整理します。Power AppsやDynamics 365でDataverseを利用している組織が、データカタログ化、分類、棚卸し、ガバナンス強化を進めるための実務向けチェックリストとして活用できます。
Microsoft PurviewでDataverseを管理する目的
Microsoft Dataverseは、Power Apps、Power Automate、Dynamics 365などの業務アプリケーションで利用されるデータ基盤です。業務部門主導でアプリやテーブルが増えやすいため、管理者から見ると「どの環境にどのデータがあるのか」「個人情報や機密情報を含むテーブルはどれか」が見えにくくなることがあります。
Microsoft PurviewにDataverse環境を登録すると、Dataverseをデータソースとしてスキャンし、Microsoft Purview Data Mapにメタデータを取り込めます。公式情報では、Dataverseソースのスキャンで、環境、テーブル、列を含む技術メタデータの抽出がサポートされています。(Microsoft Learn)
これにより、次のような運用がしやすくなります。
- Dataverse環境やテーブルの棚卸し
- Power Platform環境のデータガバナンス強化
- 個人情報や重要データを含むテーブルの把握
- Microsoft Purview Unified Catalogでの検索・参照
- データ管理者、セキュリティ担当、開発者間での共通認識づくり
ただし、Purviewに接続すればすべての統制が自動化されるわけではありません。Dataverse側のアプリケーションユーザー、セキュリティロール、Purview側のコレクション権限、スキャン範囲、認証方式を適切に設計する必要があります。
今回の公式情報で押さえるべき変更点
今回整理すべきポイントは、「DataverseをPurview Data Mapに登録してスキャンするための手順と前提条件が明確化されていること」です。特に管理者が確認すべきなのは、対応機能、認証方式、既知の制限です。
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| メタデータ抽出 | 対応 | Dataverse環境、テーブル、列の棚卸しに使える |
| フルスキャン | 対応 | 初回登録時や定期的な全体確認に利用できる |
| 増分スキャン | 未対応 | 変更差分だけを軽量に取り込む運用は前提にしない |
| スコープスキャン | 対応 | 対象テーブルを絞ってスキャンできる |
| 認証方式 | システム割り当てマネージドID、サービスプリンシパル | 組織のID管理方針に合わせて選択する |
| 削除オブジェクトの扱い | Dataverse側で削除されてもPurview資産は自動削除されない | 定期的な棚卸しと手動整理が必要 |
| ソブリンクラウド | DataverseとPurview Data Mapの統合は利用不可 | 政府・特定地域クラウド利用時は要確認 |
Dataverseコネクタでは、必要に応じてスキャン対象のテーブルを選択できます。全テーブルを一律にスキャンするのではなく、個人情報、顧客情報、売上、問い合わせ履歴など、ガバナンス上の優先度が高いテーブルから段階的に始めるのが現実的です。(Microsoft Learn)
影響を受ける主なユーザーとシステム
Microsoft PurviewとDataverseの接続は、単なる管理画面の設定変更ではありません。Power Platform管理、ID管理、セキュリティ、データガバナンス、開発運用にまたがる作業です。
| 対象 | 影響 | 確認すべきこと |
|---|---|---|
| Power Platform管理者 | Dataverse環境ごとのアプリケーションユーザー作成が必要 | 対象環境、セキュリティロール、業務部門の所有者 |
| Microsoft Purview管理者 | データソース登録、スキャン、コレクション管理が必要 | Data Source Administrator、Data Readerなどの権限 |
| Microsoft Entra ID管理者 | サービスプリンシパル利用時にアプリ登録やシークレット管理が発生 | アプリ登録、クライアントID、テナントID、シークレット期限 |
| セキュリティ担当 | Dataverse内の機密データ把握に関与 | スキャン範囲、分類結果、閲覧権限 |
| 開発者 | テーブル設計や命名、不要テーブル整理に影響 | スキャン対象テーブル、削除済み資産の扱い |
| 業務部門 | 自部門アプリのデータがカタログ化される | データ所有者、利用目的、公開範囲 |
特に重要なのは、Purview側の権限とDataverse側の権限が別物である点です。Purviewでスキャンを作成できる権限があっても、Dataverse環境に対してメタデータを取得できる権限がなければ接続テストやスキャンで失敗します。
事前に確認すべき前提条件
DataverseをMicrosoft Purviewに登録する前に、次の前提条件を確認します。
AzureとMicrosoft Purviewの前提条件
公式手順では、アクティブなAzureサブスクリプション、アクティブなMicrosoft Purviewアカウント、Purviewのデータソース登録・管理に必要な権限が前提とされています。(Microsoft Learn)
Purview側では、少なくとも次の観点を確認します。
| 確認項目 | 判断基準 |
|---|---|
| Purviewアカウント | 対象テナント・リージョン・サブスクリプションが正しいか |
| コレクション設計 | 環境別、部門別、システム別など、権限管理しやすい単位になっているか |
| 管理者権限 | データソース登録とスキャン管理に必要なロールが割り当てられているか |
| 閲覧権限 | カタログ利用者に必要最小限のData Reader権限を付与しているか |
Microsoft Purviewのクラシックガバナンスポータルでは、コレクションを使ってソース、資産、成果物へのアクセスを整理・管理します。Data Source Administratorはデータソースとスキャン管理に関係するロールで、Data Readerは読み取り専用アクセスを提供します。(Microsoft Learn)
Dataverse側の前提条件
Dataverse環境では、Microsoft Purviewがスキャンに使用するアプリケーションユーザーを作成し、Service Readerロールを割り当てる必要があります。公式手順でも、Dataverse環境でアプリケーションユーザーを作成し、Service Readerロールを割り当てる権限が必要とされています。(Microsoft Learn)
Power Platform管理センターでは、環境を選択し、設定から「Users + permissions」「Application users」に進んでアプリケーションユーザーを管理できます。アプリケーションユーザーは環境ごとに作成し、Microsoft EntraアプリケーションやマネージドIDと関連付けます。(Microsoft Learn)
ここで失敗しやすいのは、PurviewのマネージドID名やアプリ名だけを見て設定してしまうことです。マネージドIDを使う場合は、Power Platform管理センターでアプリケーションユーザーを作成する際に、Managed Identity Application IDを使う必要があります。(Microsoft Learn)
登録手順の全体像
Microsoft PurviewでDataverseを管理する流れは、大きく分けて「データソース登録」「認証設定」「スキャン作成」「結果確認」の4段階です。
| 手順 | 作業内容 | 主な担当 |
|---|---|---|
| データソース登録 | PurviewのData MapでDataverseソースを登録 | Purview管理者 |
| 認証設定 | SAMIまたはサービスプリンシパルを使えるようにする | Purview管理者、Entra ID管理者、Power Platform管理者 |
| スキャン作成 | 統合ランタイム、資格情報、対象コレクションを選択 | Purview管理者 |
| スコープ設定・実行 | 対象テーブルを選び、単発またはスケジュールで実行 | Purview管理者、データ管理者 |
| 結果確認 | Unified CatalogでDataverse資産を検索・参照 | データ管理者、セキュリティ担当、開発者 |
公式手順では、Dataverseソースを登録する際に、Microsoft PurviewのData MapからSourcesへ進み、対象コレクションでDataverseデータソースを選択します。登録時には、Dataverse環境のWeb APIエンドポイントをEnvironment URLとして入力します。このWeb APIエンドポイントは、Power Apps makerポータルのDeveloper resourcesから確認できます。(Microsoft Learn)
認証方式はSAMIとサービスプリンシパルのどちらを選ぶべきか
DataverseスキャンでMicrosoft Purviewがサポートする認証方式は、システム割り当てマネージドIDとサービスプリンシパルです。(Microsoft Learn)
システム割り当てマネージドIDが向いているケース
システム割り当てマネージドIDは、Microsoft Purviewアカウントに直接関連付くIDです。Azureによって管理され、Purviewリソース作成時に作成されます。(Microsoft Learn)
次のような場合に向いています。
- Purviewアカウント単位でスキャン権限を管理したい
- シークレットの発行・保管・ローテーションを減らしたい
- まずはシンプルな構成でDataverseスキャンを開始したい
- 1つのPurviewアカウントで対象Dataverse環境を管理する方針が明確
設定時は、Purviewの新しいスキャン画面で「Microsoft Purview MSI (system)」を選択し、表示されるマネージドIDのアプリケーションIDを記録します。そのIDを使って、Dataverse環境側にアプリケーションユーザーを作成し、Service Readerロールを割り当てます。(Microsoft Learn)
サービスプリンシパルが向いているケース
サービスプリンシパルは、Microsoft Entra IDで登録したアプリケーションに権限を割り当てて利用する方式です。ユーザー個人に依存せず、アプリケーションID、テナントID、シークレットを使って認証します。(Microsoft Learn)
次のような場合に向いています。
- 既存の運用標準でサービスプリンシパル管理を行っている
- 複数環境や複数システムで認証情報を明確に分けたい
- シークレットの期限管理や監査を既存プロセスに組み込みたい
- Entra IDアプリ登録をIaCや申請フローで管理している
ただし、サービスプリンシパルではシークレット管理が重要です。公式手順では、アプリ登録後にDirectory（tenant）ID、Application（client）ID、Secret valueを記録し、シークレットは登録完了直後に控える必要があるとされています。画面を離れると再確認できないため、Key Vaultなど安全な場所に保管する運用が必要です。(Microsoft Learn)
Key Vaultと資格情報作成で注意すべきポイント
サービスプリンシパルを使う場合、Microsoft Purviewの資格情報作成ではAzure Key Vaultとの接続が関係します。公式手順では、Key VaultのSecretsにシークレット値を登録し、Microsoft PurviewからKey Vault接続を作成して、資格情報でシークレット名を参照する流れになっています。(Microsoft Learn)
ここで確認すべきポイントは次のとおりです。
| 項目 | 注意点 |
|---|---|
| シークレット名 | Purview資格情報に入力するのはシークレット値ではなく、Key Vault上のシークレット名 |
| シークレット値 | アプリ登録直後に安全な場所へ記録する |
| Key Vault権限 | Purviewのシステム割り当てマネージドIDがシークレットを参照できるようにする |
| 権限モデル | Key Vaultアクセスポリシー方式かAzure RBAC方式かを確認する |
| ローテーション | シークレット期限切れ前に更新し、Purview側の接続テストを行う |
よくある失敗は、Entra ID側でシークレットを更新したのにKey Vaultの値を更新していないケースです。この場合、Purviewの設定画面上は資格情報が存在していても、接続テストで認証に失敗します。
スキャン範囲は「全部」ではなく「重要テーブルから」が現実的
Dataverseスキャンでは、必要に応じて特定のテーブルを選び、スキャン範囲を絞れます。(Microsoft Learn)
初回から全テーブルを対象にすると、次の問題が起きやすくなります。
- 業務上ほとんど使っていないテーブルまでカタログに出る
- 所有者不明のテーブルが大量に見つかり、整理に時間がかかる
- 権限設計が未整理のまま閲覧範囲だけ広がる
- スキャン結果の確認担当が決まらず、運用に乗らない
おすすめは、次の優先順位で段階的に対象を広げる方法です。
| 優先度 | 対象例 | 理由 |
|---|---|---|
| 高 | 顧客、取引先、問い合わせ、契約、従業員関連テーブル | 個人情報・機密情報を含む可能性が高い |
| 中 | 売上、案件、在庫、申請、承認履歴 | 業務上の重要度が高い |
| 中 | Power Appsの主要アプリで利用されるカスタムテーブル | 開発者・業務部門が確認しやすい |
| 低 | 検証用、廃止予定、利用実績が不明なテーブル | 先に所有者確認や整理が必要 |
特に開発環境、テスト環境、本番環境が分かれている場合は、本番環境から先に着手するのではなく、検証環境で接続とスキャン範囲を確認してから本番展開するのが安全です。
統合ランタイムの選び方
スキャン作成時には、シナリオに応じた統合ランタイムを選択します。Microsoft Purviewの統合ランタイムは、データスキャンを実行するためのコンピューティング基盤です。Azure integration runtime、Managed Virtual Network integration runtime、Self-hosted integration runtimeなどが用意されています。(Microsoft Learn)
Dataverseについては、サポートされるデータソース一覧でAzure IR、Managed Virtual Network IRのv2、Self-hosted IRが示されています。(Microsoft Learn)
| 構成 | 向いているケース | 注意点 |
|---|---|---|
| Azure IR | 公開エンドポイント経由でシンプルに接続できる場合 | ネットワーク制限や組織のセキュリティ要件を確認 |
| Managed Virtual Network IR | プライベートエンドポイントなどを重視する場合 | 構成と運用設計がやや複雑 |
| Self-hosted IR | オンプレミスや閉域網に近い制御が必要な場合 | サーバー、更新、監視の運用負荷が発生 |
Managed Virtual Network IRは、一定期間利用されないと休止状態になる場合があります。休止状態から接続テストやスキャンを行うと、起動に追加時間がかかることがあるため、運用監視では「最初の接続テストだけ失敗した」「キュー状態が長い」と早合点しないことが大切です。(Microsoft Learn)
既知の制限と運用での回避策
Microsoft PurviewとDataverseの接続で、管理者が特に注意すべき制限は2つあります。
増分スキャンは未対応
公式情報では、Dataverseのスキャン機能としてメタデータ抽出、フルスキャン、スコープスキャンはサポートされていますが、増分スキャンは未対応です。(Microsoft Learn)
そのため、「前回から変更されたテーブルだけを短時間で取り込む」前提の運用は避けるべきです。スキャン頻度は、Dataverse環境の変更頻度とガバナンス要件に合わせて決めます。
例として、次のように分けると運用しやすくなります。
| 環境 | 推奨される考え方 |
|---|---|
| 本番環境 | 週次または月次で定期スキャンし、重要テーブルの変更を確認 |
| 開発環境 | 頻繁に変更されるため、必要なタイミングで単発スキャン |
| テスト環境 | リリース前後の確認用途に限定 |
| サンドボックス | 原則対象外、必要時のみスコープを絞って実施 |
Dataverse側で削除したオブジェクトはPurviewから自動削除されない
Dataverseのデータソースからオブジェクトを削除しても、後続のスキャンでMicrosoft Purview内の対応する資産は自動的に削除されません。(Microsoft Learn)
これは、移行やテーブル整理のタイミングで問題になりやすいポイントです。Dataverse側では削除済みなのに、Purviewのカタログ上には古い資産が残り、利用者が誤って参照する可能性があります。
回避策として、次の運用を決めておきます。
- Dataverseでテーブル削除・統廃合を行う際は、Purview側の資産確認も作業項目に含める
- 廃止予定テーブルには、削除前に所有者や廃止予定日をメモしておく
- Purview上で古い資産が残る前提で、定期的に棚卸しを行う
- アプリ移行後は、旧環境・旧テーブルのカタログ表示を確認する
移行・展開時に確認すべきチェックリスト
Dataverse環境をPurview管理下に入れる際は、設定手順だけでなく、移行計画や展開順序を決めておくことが重要です。
導入前チェックリスト
| チェック項目 | 確認内容 |
|---|---|
| 対象環境 | 本番、検証、開発、サンドボックスのどれを対象にするか |
| 所有者 | 各Dataverse環境の業務責任者・技術責任者が明確か |
| Web APIエンドポイント | Power Apps makerポータルのDeveloper resourcesで確認したか |
| Purviewコレクション | 部門別・環境別など、権限管理しやすい配置か |
| 認証方式 | SAMIかサービスプリンシパルか決定したか |
| Dataverseアプリケーションユーザー | 対象環境ごとに作成し、Service Readerロールを付与したか |
| Key Vault | サービスプリンシパル利用時にシークレットを安全に管理しているか |
| スキャン範囲 | 初回対象テーブルを絞っているか |
| 接続テスト | 本番前に検証環境で成功を確認したか |
| 運用ルール | スキャン頻度、失敗時対応、削除済み資産の整理方法を決めたか |
展開順序のおすすめ
実務では、次の順序で進めると失敗しにくくなります。
| フェーズ | 作業 | ゴール |
|---|---|---|
| 準備 | 対象環境と重要テーブルを洗い出す | 何をPurviewに登録するか決める |
| 権限設計 | PurviewコレクションとDataverseロールを確認 | 必要最小限の権限で接続できる状態にする |
| 検証 | 検証環境でDataverse登録、認証、スキャンを実施 | 接続方式と手順を確定する |
| 初回本番展開 | 重要テーブルに絞って本番スキャン | カタログ化の品質を確認する |
| 拡張 | 対象テーブルや環境を段階的に追加 | 全社的なデータ棚卸しに広げる |
| 運用定着 | 定期スキャン、棚卸し、削除済み資産整理を実施 | カタログを最新に保つ |
本番展開では、「接続できたか」だけで終わらせず、スキャン後にUnified Catalogで検索し、テーブル名、列情報、分類結果、所有者情報が期待どおりに確認できるかまで見ることが重要です。スキャン完了後は、Microsoft Purview Unified CatalogでDataverse関連資産を参照または検索できます。(Microsoft Learn)
管理者が見落としやすい失敗ポイント
Purview側の権限だけを見てDataverse側の権限を忘れる
PurviewでData Source Administratorが付与されていても、Dataverse環境側でアプリケーションユーザーが正しく作成されていなければスキャンは成功しません。
特にSAMIを使う場合、PurviewのマネージドIDのアプリケーションIDをDataverse側に登録し、Service Readerロールを割り当てる必要があります。(Microsoft Learn)
Environment URLに通常の環境URLを入れてしまう
登録時に入力するEnvironment URLは、Dataverse環境のWeb APIエンドポイントです。Power Apps makerポータルのDeveloper resourcesから取得する必要があります。(Microsoft Learn)
通常のアプリURLや管理センターのURLを入力すると、接続テストに失敗する原因になります。登録前に、対象環境名、環境ID、Web APIエンドポイントを一覧化しておくと安全です。
シークレットの期限切れを監視していない
サービスプリンシパル方式では、シークレットの期限切れがスキャン失敗に直結します。Key Vaultに保存していても、期限管理をしていなければ突然スキャンが止まります。
少なくとも次の運用を決めておきます。
- シークレット期限の90日前に更新タスクを作る
- 更新後にPurviewで接続テストを行う
- 古いシークレットを削除する前にスキャン成功を確認する
- 運用手順書にKey Vaultのシークレット名を記載する
スキャン結果の確認担当を決めていない
スキャンを実行しても、結果を誰も見なければガバナンスにはつながりません。
初回スキャン後は、次の担当を決めておくと運用に乗りやすくなります。
| 確認内容 | 担当例 |
|---|---|
| テーブル名・列名が想定どおりか | Dataverse開発者 |
| 業務上の意味が分かるか | 業務部門のデータ所有者 |
| 機密情報が含まれる可能性があるか | セキュリティ担当 |
| カタログ上の公開範囲が適切か | Purview管理者 |
| 不要・廃止予定のテーブルが残っていないか | Power Platform管理者 |
開発者が意識すべきDataverse設計のポイント
PurviewでDataverseをカタログ化すると、テーブルや列の設計品質が可視化されます。開発者は、単にアプリが動くかだけでなく、後から管理しやすい設計になっているかを意識する必要があります。
テーブル名と列名は業務担当者が理解できる名前にする
Purviewに取り込まれるのは技術メタデータです。テーブル名や列名が曖昧だと、カタログ上でも意味が伝わりません。
避けたい例は次のような名前です。
new_table1test_customerfield_atemp_statusold_data
望ましいのは、業務上の意味が推測できる名前です。
- 顧客マスター
- 契約申請
- 問い合わせ履歴
- 承認ステータス
- 解約予定日
開発段階で仮名を使った場合は、本番移行前に名称や説明を整理しておくと、Purview上での検索性が上がります。
不要テーブルを放置しない
Dataverse側で削除したオブジェクトがPurviewから自動削除されない制限があるため、不要テーブルの整理は慎重に行う必要があります。削除前に、Purview上の資産整理もセットで計画してください。(Microsoft Learn)
特に、検証用テーブルや一時的なインポート用テーブルを本番環境に残すと、カタログの信頼性が下がります。
個人情報を含む列は命名と説明を明確にする
氏名、メールアドレス、電話番号、住所、生年月日、従業員番号などを含む列は、後からセキュリティ担当が確認しやすいようにしておきます。
列名がtext1やvalue2のような汎用名だと、分類結果やレビュー時に確認コストが増えます。Dataverseの設計段階から、カタログ化されることを前提に名前を整えることが重要です。
セキュリティ更新として見るべき実務上のポイント
今回のDataverse接続手順は、単なるデータカタログ機能ではなく、Power Platform環境のセキュリティ管理にも関係します。特に、Dataverseは業務部門が迅速にアプリを作れる一方で、データの所在が分散しやすいサービスです。
管理者は、次の3点を優先して確認してください。
重要データを含む環境を先に可視化する
すべての環境を一度にPurviewへ登録するより、機密性の高いデータを扱う環境から始める方が効果的です。
例として、次のような環境は優先度が高くなります。
- 顧客情報を扱う営業支援アプリ
- 問い合わせ履歴を管理するサポートアプリ
- 契約や請求に関係する業務アプリ
- 従業員情報や申請情報を扱う社内アプリ
- 外部連携でデータを取り込むDataverse環境
閲覧権限を広げすぎない
Purviewに登録した資産は、コレクションとロールによってアクセス管理されます。Data Readerは読み取り専用ですが、カタログに表示される情報自体が機密性を持つ場合もあります。(Microsoft Learn)
たとえば、テーブル名や列名だけで、取引先名、案件種別、社内プロジェクト名が推測できることがあります。全社公開を前提にせず、部門別・環境別にコレクションを分ける設計を検討してください。
スキャン失敗を放置しない
Purviewのスキャン状態は、データソースの詳細から確認できます。スキャン詳細では、前回実行状態、スキャン・分類された資産数、進行状況を確認できます。実行履歴から再実行、編集、削除も可能です。(Microsoft Learn)
スキャン失敗が続く場合は、次の順に確認します。
| 確認順 | 見るべきポイント |
|---|---|
| 1 | DataverseのWeb APIエンドポイントが正しいか |
| 2 | アプリケーションユーザーが対象環境に存在するか |
| 3 | Service Readerロールが割り当てられているか |
| 4 | SAMIまたはサービスプリンシパルのIDが一致しているか |
| 5 | Key Vaultのシークレット名・値・期限が正しいか |
| 6 | 統合ランタイムの種類やネットワーク制約が合っているか |
| 7 | Purview側のコレクション権限が不足していないか |
まず管理者が取るべきアクション
Microsoft PurviewでDataverseを接続・管理する場合、最初から全社展開を狙う必要はありません。まずは、対象環境を1つ選び、重要テーブルに絞ってスキャンを成功させることが現実的です。
最初のアクションは次の順番で進めてください。
- 対象のDataverse環境を1つ選ぶ
- Power Apps makerポータルでWeb APIエンドポイントを確認する
- Purviewのコレクション設計と権限を確認する
- 認証方式をSAMIまたはサービスプリンシパルから選ぶ
- Dataverse環境にアプリケーションユーザーを作成し、Service Readerロールを割り当てる
- PurviewでDataverseソースを登録する
- 重要テーブルだけを対象にスキャンを実行する
- Unified Catalogで結果を確認し、所有者・分類・不要資産を整理する
この流れを検証環境で確立してから本番環境へ展開すれば、接続失敗や権限不足、不要な資産の大量登録を避けやすくなります。Dataverseの利用が広がっている組織ほど、Purviewによる可視化は早めに始める価値があります。まずは「重要データを含むDataverse環境がどこにあるか」を洗い出し、Purviewで管理できる状態にすることから着手してください。
コメント