Microsoft PurviewでAzure Databricks Unity Catalogを管理する場合、まず確認すべき結論は「新しいデータソースである Azure Databricks Unity Catalog を使うか、従来の Azure Databricks ソースを使い続けるか」です。2026年5月13日に確認された公式情報では、Unity Catalog向けにメタデータ抽出、フルスキャン、増分スキャン、リネージ取得が整理され、認証方式やIntegration Runtimeの選択肢も明確になっています。(Microsoft Learn)
特に管理者は、スキャン対象、認証方式、SQL Warehouse、リネージ用の system.access 権限、ネットワーク接続の4点を確認してください。設定が不足していると、スキャン自体は成功しても列レベルのリネージが出ない、削除済み資産がPurview上に残る、タイムアウトする、といった運用上の問題が起きやすくなります。
Microsoft PurviewでAzure Databricks Unity Catalogを扱う更新の要点
今回の公式情報で押さえるべきポイントは、Microsoft PurviewがAzure Databricks Unity Catalogのメタデータを取り込み、PurviewのData Map上で検索・参照・リネージ確認に使えるようにする手順と制限が整理されたことです。
Microsoft PurviewがAzure Databricks Unity Catalogスキャンで扱える主な情報は、メタストア、カタログ、スキーマ、テーブル、列、ビュー、Unity Catalogのタグです。テーブル・ビュー・列の関係については、Databricksノートブック実行中に取得されたリネージも取り込めます。(Microsoft Learn)
一方で、すべてのDatabricks情報が完全に取り込めるわけではありません。外部テーブルのメタデータはサポートされていますが、外部テーブルのリネージはサポート対象外です。また、外部テーブルまたは動的テーブルのスキャンには制限があるため、データ基盤全体の可視化をPurviewだけで完結できると考えるのは危険です。(Microsoft Learn)
管理者視点では、今回の内容は「新機能の紹介」よりも「運用設計の確認リスト」として読むべきです。Unity Catalogをすでに使っている組織ほど、スキャン対象の範囲、権限、ネットワーク、リネージの取得条件を事前に棚卸しする必要があります。
影響範囲：誰が何を確認すべきか
Microsoft PurviewとAzure Databricks Unity Catalogの連携は、データ管理者だけでなく、Databricks管理者、データエンジニア、セキュリティ担当者にも影響します。
| 立場 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| Microsoft Purview管理者 | データソース登録、スキャン、コレクション管理が必要 | Data Source Administrator、Data Reader権限があるか |
| Azure Databricks管理者 | SQL Warehouse、Unity Catalog、権限設定が必要 | Unity Catalogが有効で、対象メタストアに接続されているか |
| データエンジニア | リネージ取得結果が開発・運用の可視化に影響 | ノートブック実行、ジョブ実行、SQL Warehouse実行の違いを理解しているか |
| セキュリティ担当者 | 認証方式、Key Vault、ネットワーク制御が影響 | PAT依存を続けるか、マネージドIDやサービスプリンシパルへ移行するか |
| データ利用部門 | 検索・参照できる資産の範囲が変わる | 必要なカタログやワークスペースがスキャン対象に含まれているか |
実務では、Purview担当だけで設定を完結しようとすると失敗しやすくなります。Microsoft Purviewはスキャンを実行する側ですが、実際に接続先となるSQL Warehouse、Unity Catalog権限、リネージ用システムテーブルはDatabricks側で整える必要があるためです。
新しいAzure Databricks Unity Catalogソースと従来ソースの違い
Microsoft Purviewでは、Azure Databricks Unity Catalog連携に「Azure Databricks」という従来ソースと、「Azure Databricks Unity Catalog」という新しいソースを使えます。公式情報では、どちらか一方だけでなく、組織の状況に応じて併用できると説明されています。併用してもMicrosoft Purview上で資産が重複しない点は、移行計画を立てるうえで重要です。(Microsoft Learn)
| 比較項目 | 従来のAzure Databricksソース | Azure Databricks Unity Catalogソース |
|---|---|---|
| 対象 | Hive MetastoreとUnity Catalog | Unity Catalog |
| 個人用アクセストークン | 対応 | 対応 |
| サービスプリンシパル | 非対応 | 対応 |
| マネージドID | 非対応 | システム割り当てマネージドIDに対応 |
| Azure IR | 対応 | 対応 |
| Managed Virtual Network IR | 対応 | 対応。ただし条件に注意 |
| Kubernetes Self-Hosted IR | 対応 | 対応 |
| スコープスキャン | カタログレベルで対応 | 非対応 |
| 増分スキャン | 非対応 | 対応 |
| リネージ | 対応 | 対応 |
選定の目安は明確です。Unity Catalog中心の運用に移行している組織は、新しいAzure Databricks Unity Catalogソースを優先して検証します。サービスプリンシパルやマネージドIDを使いたい場合も、新しいソースが有力です。
一方、Hive Metastore由来の資産が残っている場合や、カタログ単位のスコープスキャンを既存運用で使っている場合は、従来ソースをすぐに廃止しないほうが安全です。公式情報でも、両方を並列利用できるとされているため、まずは併用期間を設けてスキャン結果、リネージ、検索性を比較するのが現実的です。(Microsoft Learn)
管理者が最初に確認すべき前提条件
Azure Databricks Unity CatalogをMicrosoft Purviewでスキャンするには、単にPurview側でデータソースを登録するだけでは不十分です。以下の前提条件を満たしていないと、接続テストやスキャン、リネージ取得で問題が起きます。
| 確認項目 | 内容 | 不備がある場合の影響 |
|---|---|---|
| Azureサブスクリプション | 有効なAzureアカウントとサブスクリプションが必要 | PurviewやDatabricksの構成が進められない |
| Microsoft Purviewアカウント | アクティブなPurviewアカウントが必要 | Data Mapへの登録・スキャンができない |
| Azure Key Vault | シークレット管理に利用 | PATやサービスプリンシパルの資格情報管理が不安定になる |
| Purview権限 | Data Source AdministratorとData Readerが必要 | ソース登録や管理ができない |
| Unity Catalog | Databricksワークスペースで有効化し、対象メタストアに接続 | Unity Catalog資産をスキャンできない |
| SQL Warehouse | Microsoft Purviewの接続先として必要 | 接続テストやスキャンが失敗する |
| HTTP path | SQL Warehouseの接続情報として指定 | スキャン設定が完了しない |
| Can Use権限 | スキャンユーザーがSQL Warehouseを利用できる必要 | PurviewからSQL Warehouseへ接続できない |
公式情報では、Microsoft PurviewがAzure Databricksワークスペース内のSQL Warehouseに接続してスキャンを行うため、スキャン設定前にSQL Warehouseが実行中である必要があるとされています。(Microsoft Learn)
ここでよくある失敗は、「Databricks側のテーブル権限はあるが、SQL WarehouseのCan Use権限がない」というケースです。テーブルへのSELECT権限だけでは接続経路が成立しないため、Purviewの接続テストで止まる可能性があります。
認証方式はPATだけでなくマネージドIDとサービスプリンシパルも検討する
Azure Databricks Unity Catalogソースでは、スキャン認証に個人用アクセストークン、システム割り当てマネージドID、サービスプリンシパルを利用できます。(Microsoft Learn)
短期的な検証では個人用アクセストークンが扱いやすい一方、本番運用ではマネージドIDまたはサービスプリンシパルを検討したほうが管理しやすくなります。個人ユーザーに依存したトークンは、退職、異動、期限切れ、権限変更の影響を受けやすいためです。
| 認証方式 | 向いている場面 | 注意点 |
|---|---|---|
| 個人用アクセストークン | PoC、短期検証、既存構成の暫定運用 | Key Vaultへの格納、期限管理、所有者変更に注意 |
| システム割り当てマネージドID | Azure中心の本番運用、資格情報の露出を減らしたい場合 | Databricks側でMicrosoft Entra ID管理のサービスプリンシパル追加が必要 |
| サービスプリンシパル | 組織的な運用、CI/CDや権限分離を重視する場合 | シークレット管理、ローテーション、最小権限設計が必要 |
Microsoft Purviewに取り込む対象については、ユーザーまたはサービスプリンシパルに、テーブル/ビューへのSELECT、対象カタログへのUSE CATALOG、対象スキーマへのUSE SCHEMAが必要です。Unity Catalogメタストア全体をスキャンする場合は、メタストア管理者ロールを持つアカウントの利用が説明されています。(Microsoft Learn)
ただし、実務では強い権限を持つ管理者アカウントを恒常的なスキャンに使うのは避けたいところです。まず検証環境でメタストア全体のスキャンを確認し、本番では対象カタログ・スキーマに応じて専用のスキャン用IDを設計するのが安全です。
リネージ取得で確認すべき設定
Microsoft PurviewでUnity Catalogのリネージを取得するには、Unity Catalog側のシステムスキーマ system.access を有効にする必要があります。さらに、スキャンに使うユーザーには system.access.table_lineage と system.access.column_lineage へのSELECT権限が必要です。加えて、system カタログへのUSE CATALOG、system.access スキーマへのUSE SCHEMAも必要です。(Microsoft Learn)
リネージが表示されない場合、原因はPurviewではなくDatabricks側にあることが少なくありません。たとえば、ノートブック実行後、Databricksのシステムテーブルにリネージ情報が反映されるまで数分かかる場合があります。そのため、ノートブック実行直後にPurviewで確認して「取得できていない」と判断するのは早計です。(Microsoft Learn)
列レベルリネージが出ない場合の典型パターン
列レベルリネージは、ノートブックをクラスターから実行した場合に表示されます。一方、SQL Warehouseでは列レベルリネージが生成されないと公式FAQで説明されています。(Microsoft Learn)
つまり、次のような切り分けが必要です。
| 症状 | 確認すべき原因 | 対応 |
|---|---|---|
| テーブルリネージは見えるが列レベルが見えない | SQL Warehouse経由の実行ではないか | クラスターからノートブックを実行した結果を確認する |
| 一部のテーブルだけリネージが欠ける | 関連オブジェクトがすべてスキャンされているか | 入出力先のワークスペースやカタログもスキャン対象に含める |
| ADFとの依存関係が見えない | 外部サービス起点の実行ではないか | Databricksノートブック内で取得されるリネージ範囲として整理する |
| 実行後すぐに見えない | システムテーブル更新待ちではないか | 数分待ってから再スキャンまたは確認する |
リネージを監査や影響分析に使う場合は、「Purviewに表示されるリネージ」と「実際の処理依存関係」は必ずしも同じではありません。ADFパイプラインがDatabricksジョブを呼び出すような構成では、Purview上にADFデータセットとDatabricks資産の依存関係が表示されない場合があります。(Microsoft Learn)
スキャン設定の実務手順
Microsoft PurviewでAzure Databricks Unity Catalogをスキャンする流れは、大きく分けて登録、スキャン作成、接続テスト、実行、結果確認です。
| 手順 | 作業 | 実務上の確認ポイント |
|---|---|---|
| 1 | PurviewのData Mapでソースを登録 | ソース種類はAzure Databricks Unity Catalogを選ぶ |
| 2 | メタストアIDを入力 | 対象Unity Catalogメタストアを誤らない |
| 3 | コレクションを選択 | 部門別・環境別の権限設計と合わせる |
| 4 | 新しいスキャンを作成 | スキャン名は環境、対象、頻度が分かる命名にする |
| 5 | Integration Runtimeを選択 | Azure IR、Managed Virtual Network IR、Kubernetes Self-Hosted IRから選ぶ |
| 6 | 資格情報を選択 | PAT、マネージドID、サービスプリンシパルのどれを使うか決める |
| 7 | Workspace URLとHTTP pathを指定 | SQL Warehouseの接続情報を正確に入力する |
| 8 | リネージ抽出をオンにする | 必要な場合のみオン。権限とsystem.accessを事前確認 |
| 9 | 接続テストを実行 | 失敗時は権限、Warehouse稼働、ネットワークを優先確認 |
| 10 | スケジュールまたは1回実行を選択 | 初回は1回実行で結果を確認してから定期実行にする |
初回から定期スキャンを組むより、まず1回実行で対象資産数、所要時間、リネージ表示、不要な資産の混入を確認してください。大規模なUnity Catalogでは、スキャン範囲が広すぎるとタイムアウトにつながる可能性があります。公式FAQでも、資産数が多い場合は一度に数個のカタログへ範囲を絞る方法が示されています。(Microsoft Learn)
ネットワークとIntegration Runtimeの注意点
Azure Databricksワークスペースがパブリックネットワークからのアクセスを許可していない場合、またはMicrosoft Purviewアカウントがすべてのネットワークからのアクセスを有効にしていない場合は、Managed Virtual Network Integration RuntimeまたはKubernetes対応のセルフホステッドIntegration Runtimeを使ってスキャンできます。(Microsoft Learn)
ここで注意すべきなのは、Integration Runtimeを選べば必ずプライベート接続が成立するわけではないことです。公式情報では、Azure Databricks Unity CatalogのスキャンはManaged Virtual Network Integration Runtimeでサポートされる一方、この場合はManaged Private Endpointがサポートされないと説明されています。(Microsoft Learn)
ネットワーク制限が厳しい環境では、次の順で確認すると切り分けしやすくなります。
| 確認順 | 確認内容 |
|---|---|
| 1 | DatabricksワークスペースがPurviewから到達可能か |
| 2 | SQL Warehouseが実行中か |
| 3 | DBFS内部ストレージへのアクセスが必要な構成か |
| 4 | Integration Runtimeの種類が要件に合っているか |
| 5 | Managed Private Endpointの利用可否を誤解していないか |
| 6 | 接続テストとスキャン実行の両方で成功するか |
特に、スキャン結果が1MBを超え、Databricks管理のBlob Storageがパブリックネットワークアクセスを拒否している場合、エラーが発生する可能性があると公式情報で説明されています。この場合は、Microsoft Purviewが対象ワークスペースの内部DBFSストレージへアクセスできるかを確認する必要があります。(Microsoft Learn)
移行時に注意すべきポイント
従来のAzure DatabricksソースからAzure Databricks Unity Catalogソースへ移行する場合、単純に「新しいほうへ切り替える」だけでは不十分です。特に以下の点を確認してください。
| 移行観点 | 確認ポイント | 判断基準 |
|---|---|---|
| 資産の重複 | 併用してもPurview上で資産が重複しないか | 公式情報では重複しないとされるが、検索表示や運用ルールは確認する |
| Hive Metastore資産 | 従来ソースでしか必要な情報がないか | Hive由来の資産が残るなら従来ソースを維持 |
| 増分スキャン | 新ソースで増分スキャンを使うか | 大規模環境では新ソースの利点になりやすい |
| スコープスキャン | カタログ単位の絞り込みが必要か | 従来ソースのほうが適する場合がある |
| 認証 | PATからマネージドIDまたはサービスプリンシパルへ移行するか | 本番では属人性を減らす設計を優先 |
| リネージ | 移行前後でリネージの見え方が変わらないか | 重要なデータフローで比較検証する |
移行では、まず開発環境または限定カタログで新ソースを登録し、従来ソースと並行してスキャンします。そのうえで、同じテーブル・ビューがPurview上でどのように参照できるか、リネージが欠けていないか、検索結果が利用者にとって分かりやすいかを比較してください。
本番移行の完了条件は、「スキャンが成功した」ではありません。データ利用者が必要な資産を検索できること、管理者がリネージと権限の妥当性を確認できること、不要な古い資産が運用ルールに従って整理されていることまで含めて判断します。
運用で見落としやすい制限事項
Azure Databricks Unity Catalog連携では、スキャン後の運用にも注意が必要です。
まず、データソース側でオブジェクトを削除しても、その後のスキャンでMicrosoft Purview上の対応する資産が自動削除されるわけではありません。(Microsoft Learn) そのため、削除済みテーブルや廃止済みビューが検索結果に残る可能性があります。定期的に資産の棚卸しを行い、廃止済み資産の扱いを運用ルールに含める必要があります。
また、Microsoft PurviewではDatabricksノートブック名が読みやすい名前ではなく数値IDとして表示されます。これはDatabricksがUnity Catalogのシステムテーブルにノートブック名を公開していないことに起因する制限です。(Microsoft Learn) 監査や障害調査でノートブックを特定する必要がある場合は、Databricks側でジョブ名、ノートブックパス、IDの対応表を残しておくと調査が早くなります。
中国リージョンのAzure Databricksワークスペースでは、Databricksシステムテーブルがサポートされていないため、Microsoft Purviewでリネージ情報を取得できないと説明されています。(Microsoft Learn) グローバル展開している企業では、リージョンごとに同じリネージ運用ができるとは限らない点に注意してください。
展開前チェックリスト
本番展開前には、以下のチェックリストで抜け漏れを確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| 対象メタストアを特定した | メタストアID、対象カタログ、対象スキーマが一覧化されている |
| 認証方式を決めた | PAT、マネージドID、サービスプリンシパルの選定理由が明確 |
| 最小権限を設計した | SELECT、USE CATALOG、USE SCHEMAの付与範囲が明確 |
| SQL Warehouseを確認した | HTTP path、Can Use権限、稼働状態を確認済み |
| リネージ要件を整理した | テーブル、ビュー、列レベルのどこまで必要か決まっている |
system.accessを確認した | table_lineage、column_lineageへのアクセスを確認済み |
| ネットワーク経路を確認した | IRの種類、プライベート接続、DBFSアクセスを確認済み |
| 初回スキャンを実行した | スキャン時間、失敗件数、取り込み資産数を確認済み |
| 利用者目線で検索確認した | 主要テーブルが見つかり、説明やタグが理解できる |
| 廃止資産の運用を決めた | Purview上に残る古い資産の整理ルールがある |
このチェックリストを使うと、単なる接続確認ではなく、データガバナンスとして使える状態になっているかを判断できます。
まずは小さく検証し、認証とリネージを重点確認する
Microsoft PurviewでAzure Databricks Unity Catalogを管理する際は、新しいAzure Databricks Unity Catalogソースを中心に検討しつつ、従来ソースとの併用も含めて段階的に展開するのが現実的です。
最初に行うべきことは、対象メタストアとカタログを絞った小規模スキャンです。次に、認証方式を本番運用に適した形へ寄せ、リネージ取得に必要な system.access の設定と権限を確認します。最後に、検索結果、リネージ、削除済み資産の扱いまで含めて運用ルールを整えます。
「スキャンできる」だけでは、データガバナンスの完成ではありません。Microsoft Purview上で、利用者が必要なAzure Databricks Unity Catalog資産を見つけられ、管理者がリネージと権限を説明できる状態まで確認してから、本番展開に進めることが重要です。
コメント