Azure Databricks の Unity Catalog は、データとAI資産を横断してアクセス制御、監査、リネージ、データ探索、品質管理を統合するガバナンス基盤です。2026年6月30日に更新された Microsoft Learn の「What is Unity Catalog?」では、Unity Catalog が単なるテーブル権限管理ではなく、モデル、サービス、MCPサービスなどのAI関連資産まで含めて管理する中核機能であることが改めて整理されています。(Microsoft Learn)
結論から言うと、管理者がすぐ確認すべきことは4つです。既存の Azure Databricks ワークスペースが Unity Catalog メタストアに接続されているか、ユーザーとグループがアカウントレベルで管理されているか、Hive metastore や DBFS 依存のジョブが残っていないか、そしてAI利用を含む新しいガバナンス範囲に権限設計が追いついているかです。公式情報上、今回のページ更新だけで全環境に共通する一律の移行期限が追加されたわけではありません。ただし、既存ワークスペースでは移行計画を後回しにすると、ジョブ改修、権限再設計、DBFS整理、監査対応が一度に重なりやすくなります。
Azure Databricks Unity Catalogとは何か
Unity Catalog は、Azure Databricks に組み込まれた「データとAIの統合ガバナンスレイヤー」です。ワークスペースで有効化されると、テーブルのクエリ、モデルの呼び出し、データ資産の利用などの操作に対して、アクセス制御、リネージ追跡、監査ログ記録を自動的に適用します。管理対象のオブジェクトは Catalog Explorer、SQL、Azure Databricks CLI、REST API から操作できます。(Microsoft Learn)
特に重要なのは、Unity Catalog が「データカタログ」だけではない点です。テーブル、ビュー、ボリューム、関数に加えて、モデルやサービスもセキュリティ保護可能なオブジェクトとして扱われます。公式ドキュメントでは、データとAI資産が catalog.schema.object の3階層名前空間で管理されることが説明されています。(Microsoft Learn)
2026年6月30日更新で押さえるべき位置づけ
今回の更新ポイントは、Unity Catalog を「Azure Databricks 全体のデータ・AIガバナンスの土台」として捉える必要がある点です。アクセス制御だけでなく、データ探索、リネージ、監査、データ分類、データ品質監視、データ共有、AIガバナンスまでが主要機能として整理されています。(Microsoft Learn)
| 確認ポイント | 実務上の意味 |
|---|---|
| データとAIを同じガバナンス基盤で扱う | テーブル権限だけでなく、モデル、MCPサービス、AIサービスの利用権限も設計対象になる |
catalog.schema.object の3階層が基本 | 既存の database.table 前提のクエリやジョブは見直しが必要になる |
| 新規ワークスペースでは標準化が進んでいる | 2023年11月9日以降に作成された Azure Databricks ワークスペースでは Unity Catalog が自動的に有効化される |
| 既存ワークスペースは移行計画が必要 | Hive metastore、DBFS、古いランタイム、ワークスペースローカルグループが残っていないか棚卸しが必要になる |
2023年11月9日以降に作成された Azure Databricks ワークスペースでは Unity Catalog が自動的に有効化されます。一方、それ以前に作成されたワークスペースでは、Unity Catalog へのアップグレード手順を確認する必要があります。(Microsoft Learn)
Unity Catalogのオブジェクトモデルを理解する
Unity Catalog では、管理対象のデータやAI資産を「セキュリティ保護可能なオブジェクト」として扱います。権限はユーザー、サービスプリンシパル、グループに対して付与されます。実務では、この階層を理解しないまま権限を付けると、あとで「見えるが読めない」「ジョブだけ失敗する」「特定ワークスペースだけ動かない」といったトラブルにつながります。(Microsoft Learn)
| 階層 | 主な役割 | 設計時の考え方 |
|---|---|---|
| Metastore | Unity Catalog の最上位コンテナ。リージョン単位で管理される | リージョンごとのガバナンス境界として扱う |
| Catalog | データ分離の主要単位 | 本番・開発、部門、データプロダクト単位で分ける |
| Schema | Catalog 内の整理単位 | チーム、用途、アプリケーション単位で整理する |
| Object | テーブル、ビュー、ボリューム、関数、モデル、サービスなど | 実際に権限、監査、リネージの対象になる |
公式ベストプラクティスでは、データ分離は通常 Catalog を起点に考えるとされています。たとえば dev、staging、prod のように環境で分ける方法、finance、marketing、engineering のように部門で分ける方法、主要なデータプロダクトごとに分ける方法があります。(Microsoft Learn)
影響範囲：どの環境・設定を見直すべきか
Unity Catalog の影響は、テーブルの保存先だけに限定されません。ID管理、権限設計、コンピュート、ジョブ、DBFS、AI利用、監査まで広がります。
| 影響範囲 | 確認すべき内容 | 放置した場合のリスク |
|---|---|---|
| ワークスペース | Unity Catalog メタストアに接続されているか | Unity Catalog の権限、リネージ、監査を利用できない |
| ID管理 | ユーザー・グループ・サービスプリンシパルがアカウントレベルで管理されているか | GRANT にワークスペースローカルグループを使えない |
| コンピュート | Unity Catalog 対応のアクセスモードか | クエリやジョブが Unity Catalog のデータにアクセスできない |
| Hive metastore | 既存テーブルやビューが残っていないか | ガバナンス対象外のデータ利用が残る |
| DBFS | /FileStore、/mnt、DBFS上のスクリプトやライブラリが残っていないか | 移行後にジョブ失敗、二重管理、監査漏れが発生する |
| 権限 | USE CATALOG、USE SCHEMA、SELECT、MODIFY、BROWSE を適切に付与しているか | 見えるが使えない、使えるが発見できない状態になる |
| AI資産 | モデル、MCPサービス、AIサービスの権限と利用状況を管理しているか | AI利用のコスト、リスク、監査が分散する |
Unity Catalog では、ワークスペースローカルグループを GRANT 文で使えません。グループはアカウントレベルで作成し、SCIM や Microsoft Entra ID などのIdP連携もアカウントレベルに寄せる設計が推奨されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Unity Catalogが有効か確認する
まず、対象ワークスペースが Unity Catalog メタストアに接続されているか確認します。アカウント管理者であればアカウントコンソールの Workspaces 画面で Metastore 列を確認できます。SQL で確認する場合は、Unity Catalog 対応のコンピュートに接続して次のクエリを実行します。(Microsoft Learn)
SELECT CURRENT_METASTORE();メタストアIDが返れば、そのワークスペースは Unity Catalog が有効です。返らない場合や権限不足で確認できない場合は、アカウント管理者にメタストア接続状況を確認してください。
Unity Catalog対応コンピュートを使っているか確認する
Unity Catalog を使うには、コンピュート側も対応している必要があります。セットアップガイドでは、SQL warehouse、サーバーレスコンピュート、Single user または Shared アクセスモードのクラスターが Unity Catalog 対応として示されています。一方、No isolation shared access mode は Unity Catalog 非対応です。(Microsoft Learn)
| コンピュート種別 | Unity Catalog対応 | 管理者の確認ポイント |
|---|---|---|
| SQL warehouse | 対応 | BI、SQL分析用の標準経路として利用しやすい |
| Serverless compute | 対応 | ノートブック、ジョブ、パイプラインで利用状況を確認する |
| Single user / Dedicated系のアクセスモード | 対応 | 個別ユーザーや本番ジョブ向けに適用しやすい |
| Shared / Standard系のアクセスモード | 対応 | 複数ユーザー利用時の権限分離を確認する |
| No isolation shared | 非対応 | 新規作成を抑止し、既存クラスターを棚卸しする |
Unity Catalog の要件ページでは、Databricks Runtime 11.3 LTS 以上のクラスターで Unity Catalog がサポートされる一方、移行作業ではジョブとコンピュートを Databricks Runtime 13.3 LTS 以上へ上げることが推奨されています。特に既存ワークスペースでは、古いランタイムのまま残っているジョブがないか確認が必要です。(Microsoft Learn)
権限は個人ではなくグループに付与する
Unity Catalog の権限設計では、個人ユーザーへ直接 SELECT や MODIFY を付与するより、アカウントレベルのグループに付与する方が運用しやすくなります。入退社、異動、委託先変更があっても、IdP側のグループメンバーシップを更新すれば権限を追跡しやすいためです。(Microsoft Learn)
データ探索をしやすくするには、BROWSE 権限も重要です。BROWSE はメタデータを見つけるための権限であり、データ本体へのアクセスを許可するものではありません。利用者が Catalog Explorer で必要なデータを発見し、アクセス申請できる状態を作るために役立ちます。(Microsoft Learn)
GRANT BROWSE ON CATALOG <catalog-name> TO `account users`;
GRANT USE CATALOG ON CATALOG <catalog-name> TO `<group-name>`;
GRANT USE SCHEMA ON SCHEMA <catalog-name>.<schema-name> TO `<group-name>`;
GRANT SELECT ON SCHEMA <catalog-name>.<schema-name> TO `<group-name>`;ここで注意したいのは、USE CATALOG や USE SCHEMA だけではテーブルの読み取り権限にはならないことです。親階層を利用するための前提権限と、テーブルやスキーマに対する SELECT などの操作権限を組み合わせて設計します。(Microsoft Learn)
設定変更と移行期限の考え方
公式情報では一律の移行期限は示されていない
2026年6月30日更新の「What is Unity Catalog?」自体には、すべての Azure Databricks 環境に共通する強制移行期限は明記されていません。ただし、既存の Hive metastore、DBFS、古い Databricks Runtime、非対応アクセスモードからの移行は、公式のアップグレード手順として整理されています。(Microsoft Learn)
そのため、管理者は「Microsoft が示した期限を待つ」のではなく、自社の移行期限を決めるべきです。目安としては、新規データ基盤や新規AI活用案件は Unity Catalog 前提で開始し、既存ワークスペースはテーブル、ジョブ、DBFS、権限、監査の棚卸しを行ったうえで段階移行するのが現実的です。
既存ワークスペースの移行でやること
既存ワークスペースを Unity Catalog に移行する場合、公式ドキュメントでは、ID管理の見直し、ワークスペースローカルグループの移行、メタストア接続、Hive metastore のテーブル移行、ジョブやクエリの参照先更新、DBFS からの移行、コンピュート更新、レガシー機能の無効化が主要ステップとして整理されています。(Microsoft Learn)
| 順序 | 作業 | 実務での確認ポイント |
| -: | ————————— | ———————————————————- |
| 1 | IDをアカウントレベルへ統一 | SCIM、Terraform、IdP連携がワークスペースエンドポイントを参照していないか |
| 2 | ワークスペースローカルグループを移行 | 既存のテーブル権限とグループ対応表を作る |
| 3 | メタストアに接続 | 対象リージョンに Unity Catalog メタストアがあるか |
| 4 | Hive metastore のテーブル・ビューを移行 | Federation、SYNC、CTAS のどれを使うか決める |
| 5 | 権限を再付与 | アカウントレベルのユーザー、グループ、サービスプリンシパルへ付与する |
| 6 | クエリとジョブを修正 | catalog.schema.object 形式へ参照を更新する |
| 7 | DBFS依存を解消 | ファイルは Volumes、コードは workspace files や Git folders へ移す |
| 8 | ランタイムとアクセスモードを更新 | Databricks Runtime 13.3 LTS 以上、Unity Catalog対応アクセスモードを優先する |
| 9 | レガシー機能を無効化 | 検証後に Hive metastore、DBFS root、No isolation shared などを制限する |
大規模移行では、Hive metastore federation を使って段階的に移行する選択肢があります。公式ドキュメントでは、Hive metastore を foreign catalog としてフェデレーションし、その後 Unity Catalog テーブルへアップグレードする方法が推奨されています。この方法では、データ移動なしで履歴、設定、権限、ビューを保持しながら移行できると説明されています。(Microsoft Learn)
ALTER TABLE <foreign_catalog>.<schema>.<table_name> SET MANAGED;管理テーブルに移行すると、Unity Catalog の予測最適化による自動メンテナンスやパフォーマンス改善を活用しやすくなります。一方、外部テーブルとして残す場合は、ストレージライフサイクルを自社側で管理し続ける前提になります。(Microsoft Learn)
DBFSとHive metastoreで失敗しやすいポイント
Unity Catalog 移行でトラブルになりやすいのは、テーブル定義だけを移して「完了」と判断してしまうケースです。実際には、DBFS root、DBFS mounts、ジョブスクリプト、init scripts、ライブラリ、古いクラスター設定が残っていると、移行後にジョブが失敗したり、ガバナンス対象外の経路が残ったりします。(Microsoft Learn)
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| 移行後にジョブが失敗する | ジョブが hive_metastore や /mnt パスを参照している | ジョブ定義、ノートブック、SQLを検索し、Unity Catalog テーブルや Volumes へ変更する |
| 権限を付けたのにアクセスできない | USE CATALOG、USE SCHEMA、SELECT の組み合わせが不足 | 親階層の利用権限と対象オブジェクトの操作権限をセットで確認する |
| 監査・リネージが抜ける | 直接ストレージアクセスやレガシー経路が残っている | 外部ロケーション、Volumes、Unity Catalog対応コンピュートに寄せる |
| Hive metastoreを無効化したら障害になる | 移行前のテーブルや古いランタイムのジョブが残っている | 無効化前に全テーブル移行、全ジョブ検証、Runtime 13.3 LTS 以上への更新を行う |
| No isolation shared クラスターが残る | Unity Catalog 非対応またはレガシー制限を回避する経路になる | 新規作成を制限し、既存クラスターを対応モードへ置き換える |
Hive metastore への直接アクセスを無効化する前には、すべてのテーブル移行が完了していること、ユーザーにレガシーメタストア利用を停止させる段階であること、ジョブが Databricks Runtime 13.3 LTS 以上に更新されていることを確認します。無効化後、Hive metastore 上のテーブルを参照するジョブや古いランタイムのジョブは失敗する可能性があります。(Microsoft Learn)
Managed assetsとExternal assetsの選び方
Unity Catalog では、テーブルとボリュームについて「Managed」と「External」の2種類があります。Managed assets は Unity Catalog がガバナンスとストレージライフサイクルの両方を管理します。External assets は Unity Catalog がアクセス制御、監査、リネージなどのガバナンスを担い、実際のストレージ配置やファイルライフサイクルは利用者側が管理します。(Microsoft Learn)
| 種類 | 向いているケース | 注意点 |
|---|---|---|
| Managed table / volume | 新規テーブル、標準化されたデータ基盤、本番データマート | Drop時に基になるデータファイルの削除挙動を理解しておく |
| External table / volume | 既存ストレージをそのまま使う、外部システムが生成するデータを参照する | Unity Catalogを経由しない直接アクセスを許すと監査やアクセス制御を迂回する |
| External location | 既存の Azure Storage パスを Unity Catalog 管理下に置く | DBFS mount と併用すると経路が分散しやすい |
公式ベストプラクティスでは、多くのユースケースで Managed table と Managed volume が推奨されています。新しい Azure Databricks 機能は Managed table を優先する傾向があり、外部テーブルは既存 Hive metastore からの移行や、外部リーダー・ライターとの連携が必要な場合に検討する位置づけです。(Microsoft Learn)
リネージ、監査、データ分類の活用ポイント
Unity Catalog の価値は、権限管理だけではありません。リネージ機能では、テーブルを作成したクエリ、変換したジョブやノートブック、利用しているダッシュボードなどを追跡できます。公式ドキュメントでは、Unity Catalog が Azure Databricks 上のクエリのリネージを自動的に取得し、メタストアに接続されたワークスペース全体で集約すると説明されています。(Microsoft Learn)
実務では、次の場面で特に効果があります。
| 活用シーン | 具体例 |
|---|---|
| 影響調査 | 本番テーブルの列名変更前に、下流のジョブやダッシュボードを確認する |
| 障害調査 | レポート数値の異常時に、上流データや変換処理をたどる |
| 監査対応 | 個人情報や規制対象データがどのテーブルやダッシュボードに流れているか確認する |
| データ品質改善 | 利用頻度が高いテーブルから優先して品質監視や所有者設定を行う |
ただし、リネージにも制約があります。たとえば、パス参照で読み書きしている処理や、RDD、グローバル一時ビューなどは取得範囲に制限があります。列レベルリネージを確実に活用したい場合は、データをテーブル名で参照し、Unity Catalog の管理対象として登録することが重要です。(Microsoft Learn)
AIガバナンスへの影響
2026年時点の Unity Catalog では、AI資産の管理も重要なテーマです。関連ドキュメントでは、Unity AI Gateway が Azure Databricks のエンタープライズAI向けガバナンス機能として説明されています。モデル、エージェント、MCPサーバー、ツールの利用を Unity Catalog の権限で制御し、レート制限、予算管理、フォールバック、サービスポリシー、監査、利用状況の追跡を行う構成です。なお、Unity AI Gateway は該当ドキュメント上で Beta とされ、利用にはプレビュー機能の有効化が必要です。(Microsoft Learn)
AI活用を進める組織では、次のような設計が必要になります。
| 管理対象 | 確認ポイント |
|---|---|
| モデル | 誰がどのモデルを呼び出せるか、外部モデル利用を許可するか |
| MCPサービス | どのツールや外部サービスにエージェントがアクセスできるか |
| サービスポリシー | PII、プロンプトインジェクション、不適切コンテンツをどう扱うか |
| コスト | ユーザー、チーム、モデルごとの利用量と予算上限をどう管理するか |
| 監査 | 誰が、いつ、どのAIサービスを使い、どのような結果になったか追跡できるか |
ここでのポイントは、AIをデータ基盤の外側で別管理しないことです。データテーブルの権限は厳格でも、AIエージェントが外部ツールやモデルを自由に呼び出せる状態では、統制が崩れます。Unity Catalog を使う場合、データ資産、モデル、関数、MCPサービスを一貫した権限モデルで扱う設計が重要です。
グローバル環境での設計ポイント
グローバル企業で Azure Databricks を使う場合は、リージョン、ワークスペース、カタログの役割を混同しないことが重要です。Unity Catalog は全リージョンでサポートされるとされていますが、メタストアはリージョン単位の考え方を持ちます。公式ベストプラクティスでは、1リージョンにつき1つのメタストアを持ち、そのリージョン内のワークスペースが共有する形が説明されています。(Microsoft Learn)
グローバル設計では、次のように分けて考えると整理しやすくなります。
| 設計項目 | 推奨される考え方 |
|---|---|
| リージョン | データ所在地、法規制、レイテンシ、災害対策で決める |
| メタストア | リージョン内の統合ガバナンス境界として設計する |
| Catalog | 環境、部門、データプロダクトなどの分離単位にする |
| Schema | チームや用途別の整理単位にする |
| 権限 | グローバル共通ロールと地域・部門ロールを分ける |
| 共有 | リージョン間・組織間共有は直接ストレージ共有ではなく、OpenSharing などの機能を検討する |
特に避けたいのは、同じ外部テーブルを複数メタストアへ安易に登録する運用です。公式ベストプラクティスでは、頻繁にアクセスされる外部テーブルを複数メタストアへ登録することは、メタデータ不整合や一貫性の問題につながる可能性があるため推奨されていません。(Microsoft Learn)
管理者向けチェックリスト
最後に、今回の更新内容を踏まえて管理者が確認すべき項目をまとめます。まずは「Unity Catalog が有効か」だけでなく、「Unity Catalog を前提とした運用になっているか」を確認してください。
| チェック項目 | 確認方法 |
|---|---|
| ワークスペースが Unity Catalog メタストアに接続されている | SELECT CURRENT_METASTORE(); またはアカウントコンソールで確認 |
| アカウントレベルのユーザー・グループを使っている | ワークスペースローカルグループへの依存を棚卸し |
| Unity Catalog対応コンピュートを使っている | クラスターのアクセスモードと Runtime バージョンを確認 |
| Hive metastore のテーブルが残っていない | hive_metastore 参照のクエリ、ジョブ、ノートブックを検索 |
| DBFS root / mounts 依存が残っていない | /FileStore、/mnt、dbfs:/databricks/init などを確認 |
| Catalog / Schema 設計が運用境界と合っている | 本番・開発、部門、データプロダクト単位で再整理 |
BROWSE とアクセス申請の導線がある | 利用者がデータを発見し、申請できる状態にする |
| AI資産の権限設計がある | モデル、MCPサービス、関数、エージェントの利用範囲を定義 |
| レガシー機能を無効化する準備ができている | すべての移行・検証後に Hive metastore や DBFS root の制限を検討 |
Azure Databricks Unity Catalog の更新ポイントは、「便利なカタログ機能が増えた」という話ではありません。データ、AI、権限、監査、ジョブ、ストレージを、Unity Catalog を中心に再設計する必要があるというメッセージです。まずは既存ワークスペースのメタストア接続、ID管理、Hive metastore 依存、DBFS 依存、コンピュート設定を棚卸しし、新規開発は Unity Catalog 前提に切り替えるところから始めるのが現実的です。
コメント