DatabricksのUnity Catalog：ガバナンスを正しく設定する

Unity CatalogはDatabricksのガバナンス層です。すべてのテーブル、ビュー、ファイルボリューム、関数、AIモデルについて誰が閲覧と変更をできるかを制御し、それらの間のリネージを記録し、アクセスをログに残して監査人に証明できるようにします。

現在Databricksを運用しているなら、すでにUnity Catalogを使っているか、移行中のはずです。従来のHive metastoreは廃止に向かっており、Databricksの新しい機能はすべてUnity Catalogが下にあることを前提にしています。

もはや問題は導入するかどうかではありません。新しいチーム、新しいデータ、そして1、2回の監査を経た3年後にも、カタログの設計が筋の通ったものであり続けるかどうかです。

私が関わってきた製造業と防衛分野のプログラムでは、技術が難所になることはまれでした。難しかったのは、どのデータを誰が所有するか、環境をどう分離するか、セキュリティチームがどんな証跡を求めるかについて合意することです。

すべては最上位のコンテナであるメタストアの下にあります。その下で、データとAIの資産はcatalog.schema.objectという3階層の名前空間を使います。prod_finance.gl.journal_linesに対するクエリは、カタログ、スキーマ、テーブルを指定しています。

権限を付与する対象のオブジェクトは、セキュリティ保護可能なオブジェクトと呼ばれます。Unity Catalogのドキュメントによると、これらは2つのグループに分かれます。

1. 名前空間内の資産： テーブル、ビュー、ボリューム（統制されたファイルストレージ）、関数、モデル、サービス。
2. メタストアレベルのオブジェクト： ストレージ資格情報、外部ロケーション、接続（外部データベースへの接続）、共有。

メタストアレベルのオブジェクトのうち2つは、データが物理的にどこに置かれるかを決めるため、わかりやすく説明しておきます。

ストレージ資格情報は、IAMロールやマネージドIDなど、ストレージアカウントやバケットにアクセスできるクラウドのIDをまとめたものです。外部ロケーションは、ストレージのパスと資格情報を組み合わせたものです。この2つによって、Unity Catalogはユーザーにキーを渡すことなくクラウドストレージの読み書きができます。

次にマネージドと外部の違いです。マネージドテーブルでは、Unity Catalogがテーブルを統制し、そのファイルも管理します。外部テーブルでは、統制するのはアクセスだけです。

Databricksは現在、すべての新しいデータにマネージドテーブルを推奨しており、外部テーブルは主にHiveからのアップグレード用に残しています。私も同意見です。他のツールが同じパスに書き込んでいるなら、通常それはテーブルをずっと外部のままにしておく理由ではなく、パイプラインを直す理由です。

すべてを左右する制約が1つあります。メタストアはクラウドリージョンごとに1つしか持てません。分離をメタストアの数で解決することはできません。カタログで解決します。

Unity Catalogの権限は、下位に継承される標準的なSQLの権限付与です。カタログへの権限付与は、その中のすべてのスキーマとテーブルに適用されます。ユーザーがテーブルにたどり着くにはUSE CATALOGとUSE SCHEMAが必要で、読み取るにはさらにSELECTが必要です。

GRANT USE CATALOG ON CATALOG prod_finance TO `finance-analysts`;
GRANT USE SCHEMA ON SCHEMA prod_finance.gl TO `finance-analysts`;
GRANT SELECT ON SCHEMA prod_finance.gl TO `finance-analysts`;

権限付与が答えるのは「このグループはこのテーブルを読めるか」という問いです。規制対象のデータには、よりきめ細かな答えが必要で、そこで他の制御が登場します。

以下の表は、2026年10月時点の主なアクセス制御とその状況をまとめたものです。

制御	何をするか	状況（2026年10月）
権限付与と所有権	オブジェクト単位の権限。カタログからスキーマ、オブジェクトへと継承	一般提供
テーブル単位の行フィルターと列マスク	1つのテーブルに付けたSQL関数で、行を隠すか値をマスクする	一般提供
ABACの行フィルターと列マスクのポリシー	カタログ、スキーマ、テーブルのいずれかのレベルで定義した1つのポリシーが、ガバナンスタグの付いたすべてのオブジェクトに適用される	2026年4月28日からGA
ガバナンスタグ	キー、値、付与できる人を管理するアカウントレベルのタグ	2026年4月2日からGA
データ分類	テーブルをスキャンし、個人情報などの機密データを検出する	2026年4月20日からGA、カスタム分類器はBeta
ABACのDENYポリシーとメタストアレベルのポリシー	権限付与より優先される明示的な拒否、メタストア範囲のポリシー	Beta
エンジン横断のABAC	外部エンジンがABACで保護されたマネージドテーブルを読み取り、ポリシーはDatabricksのサーバーレスコンピュートが適用する	2026年10月1日からGA

日付はDatabricksの2026年4月のリリースノートと2026年10月のリリースノートによるものです。

ABAC（属性ベースのアクセス制御）は、大規模な環境にとって最も重要な変更です。テーブルごとにマスクを書く代わりに、列にタグ（たとえばclassification = export_controlled）を付け、指定したグループ以外のすべての人に対してタグ付きの列をすべてマスクするポリシーを1つ書きます。

新しいテーブルは、タグが付いた時点で保護されます。タグはデータ分類が提案してくれます。

まずコンピュートを確認してください。ABACで保護されたテーブルには、サーバーレスコンピュートか、Databricks Runtime 16.4以上が必要です。それより古いクラスターでは一切読み取れません。

早めに指摘しておきたい落とし穴が2つあります。同じユーザーの同じ列に矛盾するポリシーがあると、クエリはエラーでブロックされます。

また、パイプラインの実行IDがマスクの対象に入っていると、更新されたデータがマスクされた状態で保存されることがあります。サービスIDは意図的に除外し、その理由を文書化してください。

リネージは、メタストアに接続されたすべてのワークスペースで、Databricks SQLとSpark DataFramesを通じて実行されたクエリについて、列レベルまで自動的に取得されます。ノートブック、ジョブ、パイプライン、ダッシュボードが対象です。コードがストレージのパスでテーブルを参照すると列のリネージは失われます。パスベースのアクセスを廃止すべき理由がもう1つ増えます。

監査の証跡はシステムテーブルから得られます。system.access.auditは監査イベントを保持し、システムテーブルのドキュメントではまだPublic Previewとされています。

その隣にリネージと請求のテーブルがあり、365日間は無料で保持されます。既定ではシステムテーブルを見られるのはアカウント管理者とメタストア管理者だけなので、誰に読み取りアクセスを与えるか、より長く保持するために監査データをSIEMにコピーするかを早めに決めてください。

共有は今年名前が変わりました。Databricksは2026年6月10日に、Delta Sharingプロトコルの次のバージョンとしてOpenSharingを発表しました。現在はLinux Foundationがホストし、AI資産とIcebergクライアントにも対象を広げています。

古いドキュメントや契約書には、まだ「Delta Sharing」と書かれています。共有はUnity Catalogのオブジェクトであり、Databricks間の共有は、リージョンごとのメタストアの間でデータを移動する方法でもあります。

混在環境向けには、マネージドApache Icebergテーブルと外部Apache Icebergテーブルが2026年5月21日に一般提供になりました。外部テーブルは、AWS GlueやSnowflake Horizonなどのカタログから、Lakehouse Federationを通じて読み取ります。Spark、Flink、Trinoなどのエンジンは、Unity CatalogのIceberg RESTカタログのエンドポイントを使えます。

LF AI & Data Foundationのもとにオープンソース版のUnity Catalogもありますが、これはサンドボックス段階のプロジェクトであり、マネージドサービスではありません。テストせずに出口戦略をこれに頼らないでください。

カタログが分離の主な単位です。DatabricksのUnity Catalogのベストプラクティスによると、カタログは通常、環境、チーム、事業部門、またはその組み合わせに対応します。現実の設計の大半は組み合わせです。

カタログの分け方は二通り

環境ごとのカタログ

• dev、test、prodのカタログに、ドメインごとのスキーマ
• 各カタログをそのワークスペースに結び付けやすい
• 一つのカタログ内でドメインが増えると所有があいまいになる
• 小規模なチームや初期の展開に向く

ドメインと環境ごとのカタログ

• prod_finance、prod_quality、dev_financeなど
• 各ドメインのグループが自分のカタログを所有する
• 責任が明確で、監査の範囲もすっきりする
• 命名、結び付け、権限付与の対象となるカタログが増える

データチームが数チーム以上ある企業なら、私はドメインと環境の組み合わせを既定にします。最初に命名の規律を求められる分、手間はかかります。その代わり、誰もが問い合わせるのに誰も保守していないテーブルの所有者をめぐる、2年後の言い争いを避けられます。

残りの設計は、次の4つのルールに集約されます。

1. グループはIDプロバイダーから取り込む。 自動ID管理、またはプロバイダーが対応していなければSCIMで、ユーザーとグループをDatabricksアカウントにプロビジョニングします。グループはDatabricksではなく、Microsoft Entra ID、Oktaなどで定義します。誰かが退職すれば、ディレクトリのアカウントとともにアクセスもなくなります。
2. 本番のオブジェクトはグループが所有する。 Databricks自身のガイダンスでは、本番のカタログとスキーマの所有権はグループに割り当て、決して個人には割り当てないとしています。所有者はアクセスを付与できるので、個人が所有者であることは常設の例外になってしまいます。
3. カタログをワークスペースに結び付ける。 本番のワークスペースにだけ結び付けた本番カタログは、権限付与の内容にかかわらず、サンドボックスからはクエリできません。
4. 権限付与の前に分類する。 短いタグの語彙（機密度、個人データ、輸出管理、ソースシステム）をガバナンスタグとして合意し、それに対してABACポリシーを書きます。

製造業では、私はカタログを工場ではなく、工場のシステム、つまりOTとソースシステムのドメインで整理しました。ヒストリアン、MES、センサーからのOTデータは専用のカタログに置き、オペレーションまたはエンジニアリングのデータチームが所有します。ERP（SAP、Oracle、Microsoft Dynamics 365）、品質、サプライチェーンからのITデータは別のカタログに置きます。

アナリスト向けに整えて結合したデータは、3つ目のカタログ群に置きます。OTとITの境界が、カタログそのものの中で見えるようになります。ERPの抽出が範囲に含まれるなら、SAPのデータ移行が失敗する理由についての私のメモは、ERPのデータフィードにも当てはまります。

防衛分野のプログラムでは、セキュリティチームから4つの質問が来ると考えてください。輸出管理の対象データを誰が見られるのか。他のすべてのデータとどう分離されているのか。

どこに保存されているのか。過去1年間のどの日についても、そのすべてを証明できるのか。

それを前提に設計すれば、Unity Catalogはその大半に答えられます。

1. 最小権限。 メタストアやカタログのレベルで、範囲の広いグループに権限を付与しません。スキーマのレベルで名前の付いたグループに付与し、管理対象としてタグ付けされた列にはABACのマスクを使います。DENYポリシーを使うのは、Betaを抜け、認定機関が受け入れてからにしてください。
2. 分離。 管理対象のデータには、専用のマネージドストレージのロケーションを持つ別のカタログを用意し、専用のワークスペースに結び付けます。Databricksはカタログレベルのマネージドストレージを主な分離の単位として推奨しており、これはこの用途によく合います。
3. データ所在地。 メタストアはリージョンごとに1つなので、誰かが共有しない限り、データはそのストレージのリージョンにとどまります。OpenSharingのすべての共有と、リージョンをまたぐすべてのリンクを、承認が必要なデータ所在地の判断として扱ってください。
4. 監査の証跡。 リネージとsystem.access.auditをSIEMにエクスポートすれば、誰が何にアクセスし、それがどこへ行ったかがわかります。監査テーブルはまだPublic Previewであることを念頭に置いてください。私の防衛分野の仕事では、セキュリティチームは監査ログをDatabricksのシステムテーブルに置いたままにするのではなく、自分たちのSIEMにコピーすることを求めました。そのフィードは最初から計画に組み込んでください。

Unity Catalogは、何が機密データやITARの管理対象データにあたるかを決めるものではなく、認定の代わりにもなりません。防衛分野のワークロードの中には、商用クラウドのリージョンでは一切動かせないものもあります。

それでもカタログの設計は役に立ちます。プラットフォームに載せてよいものと載せてはいけないものの間に、はっきりと線を引けるからです。プラットフォームの上位にあるポリシー層を書いているなら、私のAIガバナンスフレームワークのガイドで役割と承認の面を扱っています。

Hive metastoreから移行する企業、または新たに始める企業に対して、私が従う順番です。

1. カタログのモデルと命名規則に合意する。 ドメインと環境の組み合わせを文書にし、データオーナーの承認を得ます。後で変えれば、すべての名前を付け直すことになります。
2. IDプロバイダーを接続する。 アカウントレベルのプロビジョニングを行い、グループはディレクトリで定義し、Unity CatalogのワークスペースではワークスペースレベルのSCIMを無効にします。
3. ストレージ資格情報と外部ロケーションを設定する。 プラットフォームのグループが所有します。他の誰にもCREATE EXTERNAL LOCATIONを与えません。
4. マネージドストレージとワークスペースの結び付けを持つカタログを作成する。 本番のカタログは初日からグループが所有します。
5. ガバナンスタグを定義し、データ分類を有効にする。 その検出結果を確認してから、それに基づくポリシーを書きます。
6. 機密性の高い列にABACポリシーを書く。 Runtime 16.4未満のクラスターが残っていればそれも含め、運用しているすべてのコンピュートの種類で、実際のユーザーとともにテストします。
7. Hive metastoreから移行する。 Databricksは現在、まずHive metastoreをフェデレーションし、そのうえでテーブルをその場でアップグレードすることを推奨しています。UCXは大規模な環境で役立ちますが、Databricks Labsのプロジェクトであり、公式サポートではなくコミュニティによる保守です。その前提で計画してください。
8. 監査のエクスポートとリネージのレビューを有効にする。 システムテーブルへの読み取りアクセスを付与し、SIEMへのフィードを設定し、誰が何をレビューするかに合意します。
9. Hive metastoreへのアクセスを無効にする。 すべての移行が済んだら無効にし、誰も古い経路の上に黙って構築しないようにします。

1. 個人への権限付与。 1週間はうまくいきます。その後、誰が何にアクセスできるのか誰も答えられなくなります。
2. チームごとのスキーマを持つ巨大なカタログ1つ。 所有と監査の範囲があいまいになり、後で作り直すことになります。
3. テーブルを「当面は」外部のままにしておくこと。 マネージドテーブルの機能を失い、すべてのファイルに所有者が2人いる状態が続きます。
4. 1種類のクラスターでポリシーをテストすること。 ABACの挙動はコンピュートによって異なり、古いランタイムではそもそも失敗します。
5. 監査を後のフェーズとして扱うこと。 監査人は、有効にする前の期間について質問してきます。

初期段階なら、誰かがカタログを作る前に、カタログのモデルとタグの語彙を1ページにまとめてください。移行の途中なら、アセスメントを実施し、まだ外部のテーブルやHive metastore上に残っているテーブルをすべて洗い出し、それぞれに所有者と期日を割り当ててください。

全体像についてはDatabricksは何に使われるのかから始め、ABAC用のサーバーレスコンピュートの規模を決める前にDatabricksの料金を確認してください。プラットフォームを比較検討しているなら、私のSnowflakeとDatabricksの比較で両者のガバナンスを扱っています。私は製造業と防衛分野の組織がこうした設計の判断を下すのを支援しています。セカンドオピニオンが必要なら、打ち合わせを予約してください。

DatabricksのUnity Catalogとは何ですか？

Unity CatalogはDatabricksのガバナンス層です。テーブル、ビュー、ファイルボリューム、関数、AIモデルへのアクセスを1か所で管理し、リネージを自動的に取得し、アクセスを監査用のシステムテーブルに記録します。資産は、リージョンごとに1つのメタストアのもとで、catalog.schema.objectとして指定します。

DatabricksのABACは一般提供されていますか？

はい。行フィルターと列マスクのための属性ベースのアクセス制御のポリシーは、2026年4月28日に一般提供になりました。ガバナンスタグとデータ分類も2026年4月にGAになっています。DENYポリシー、メタストアレベルのポリシー、カスタム分類器は、2026年10月時点でまだBetaでした。

Delta SharingとOpenSharingは同じものですか？

はい。Databricksは2026年6月に、Delta Sharingプロトコルの次の進化形としてOpenSharingを発表しました。現在はLinux Foundationがホストし、AI資産とIcebergクライアントにも対象を広げています。Databricksのドキュメントでは、共有をOpenSharingの名前で説明するようになっています。

Unity Catalogではマネージドテーブルと外部テーブルのどちらを使うべきですか？

すべての新しいデータにはマネージドテーブルを使います。Unity Catalogがファイル、保守、パフォーマンス機能を管理するため、Databricksはマネージドテーブルを推奨しています。外部テーブルは、別のシステムがファイルを所有しなければならない場合か、Hive metastoreのアップグレード中に限って残し、変換を計画してください。

Hive metastoreからUnity Catalogへはどう移行しますか？

Databricksは、まずHive metastoreを外部カタログとしてフェデレーションし、そのうえでデータを移動せずにテーブルをその場でアップグレードすることを推奨しています。大規模な環境では、Databricks LabsのUCXツールが準備状況を評価し、グループ、権限、テーブルを移行しますが、UCXは公式サポートではなくコミュニティによる保守です。

カタログは環境ごとと業務ドメインごとのどちらで整理すべきですか？

多くの企業にとっては両方です。prod_financeやdev_financeのように、ドメインごと、環境ごとに1つのカタログを持ちます。各ドメインのグループに明確な所有権と、すっきりした監査の範囲が与えられます。小規模なチームは、環境ごとに1つのカタログとドメインごとのスキーマから始めてもかまいません。