--- title: "Unity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】" url: "https://www.issoh.co.jp/tech/details/16134/" published: 2026-08-04 updated: 2026-08-04 categories: ["データベース"] publisher: "株式会社一創" --- # Unity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】 Unity Catalogは、Databricksに組み込まれたデータとAIの統合ガバナンス層です。この記事では、メタストアからカタログ・スキーマへ降りる3レベル名前空間の構造、USE CATALOGとUSE SCHEMAを土台にした権限継承の設計、Hive metastoreとの併存と移行経路の選び分け、コンピュート要件と制限、そしてOSS版と外部エンジン接続までを実装者の目線で整理します。 ## まとめ：Unity Catalog導入可否を分ける3つの判断材料 検討の実態は「入れるかどうか」ではありません。分かれ目は次の3点です。第一に、2023年11月9日以降に作成されたワークスペースでは自動的に有効になるため、論点は既存のHive metastore資産をどう畳むかへ移っていること。第二に、権限モデルが`USE CATALOG`などの使用特権と`SELECT`などのデータ特権の二段構えで、この構造を押さえずに付与を進めると「権限を与えたのに読めない」が量産されること。第三に、マネージドテーブルが`delta`または`iceberg`に限られバケットが非対応であるなど、後から設計をやり直させる制限が実在することです。 単一ワークスペースで対象が数テーブル、閲覧者が全員同じ権限で足りる規模なら、階層設計に工数を割く必要は薄いでしょう。以降ではこの3点を構造・権限・移行・要件・採用判断の順に分解します。 ## Unity Catalogの位置づけとガバナンス層としての守備範囲 最初に、何を担い何を担わないのかを押さえます。 ### Databricksに組み込まれたデータとAIの統合ガバナンス層という位置づけ Unity Catalogは、独立した製品として買い足すものではなく、Databricksの内側に組み込まれたガバナンス層です。ワークスペースで有効になっていれば、すべてのデータ操作とAI操作の下で自動的に動きます。クエリ時のアクセス制御、モデル呼び出し時の権限判定、系譜追跡、監査ログの記録が、利用者の意識とは無関係に走る構造です。操作の入口はカタログエクスプローラー、SQL、Databricks CLI、REST APIの4つでした。製品全体の像や課金は[Databricksとは？できること・DBU課金の料金・業種別の導入効果を2026年版で解説](https://www.issoh.co.jp/tech/details/3557/)で扱っているため、本記事はガバナンス層の実装に絞ります。 ### 発見・アクセス制御・リネージ・監査・共有まで一層で担う機能範囲 守備範囲は5つに整理できます。カタログエクスプローラーによるデータ発見、特権と行列フィルタによるアクセス制御、ソースからモデル・ダッシュボードまで自動で辿るリネージ、監査ログシステムテーブルによる証跡、OpenSharingによる組織間・クラウド間の共有です。機密データの自動分類とデータ品質監視も同じ層に載ります。押さえたいのは、「メタデータの一覧表示」より広い一方、Databricksの外側にある資産を包括的に束ねる用途には向かないという線引きでした。枠組みそのものの目的や導入判断は[データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説](https://www.issoh.co.jp/column/details/13792/)で整理しています。 ## Unity Catalogの3レベル名前空間とセキュリティ保護可能オブジェクト 実装として理解する近道は、オブジェクトモデルを先に頭へ入れることです。 ### メタストアからカタログ・スキーマへ降りる三段の階層と既定カタログ 管理対象はすべて「セキュリティ保護可能なオブジェクト」としてモデル化され、ユーザー・サービスプリンシパル・グループへ権限を付与できます。テーブル、ビュー、ボリューム、関数、モデル、モデルサービングやMCPサービスといった資産は、`catalog.schema.object`という3レベルの名前空間に従います。従来のHive metastoreが`database.table`の2レベルだったところへ、カタログが一段上に足された構造です。 | 階層 | 主なオブジェクト | 役割 | | ------ | ------------ | ----------- | | メタストア | カタログ・共有・接続 | アカウント単位の最上位 | | カタログ | スキーマ | 業務や環境で区切る境界 | | スキーマ | テーブル・ビュー | 従来のデータベース相当 | | オブジェクト | ボリューム・関数・モデル | 権限付与の最小単位 | ストレージ資格情報、外部ロケーション、接続、共有はこの3レベルの外側に置かれ、メタストアの直下に並びます。カタログ名を省いたときの既定カタログはワークスペースごとに構成され、自動で有効化された環境ではワークスペースカタログ、手動で有効化した場合は`hive_metastore`になります。移行途中で既存コードを壊したくないなら、後者のまま据え置く判断が扱いやすいでしょう。 ### マネージドと外部で分かれるテーブル形式の制約と使い分けの判断 テーブルとボリュームには、ガバナンスと実体ファイルのライフサイクル両方を任せるマネージドと、ガバナンスだけを任せる外部の2種類があります。この選択はファイル形式の制約に直結しました。マネージドで使えるのは`delta`と`iceberg`だけです。外部なら`delta`に加えてCSV、JSON、`avro`、`parquet`、ORC、テキストまで受け付けます。 落とし穴は、両者をあとから相互に移し替えられない前提で組むべき点にあります。浅いクローンはマネージド同士、外部同士でしか成立しません。既存のクラウドストレージ上に置かれたParquetの資産を段階的に取り込むなら外部テーブルから入り、新規に作る分析用テーブルはマネージドへ寄せる。この二本立てなら手戻りを避けられました。テーブル形式の選び方は[Apache Hudiとは？レコード単位の更新と増分取り込みを支える仕組みを実装視点で解説【2026年版】](https://www.issoh.co.jp/tech/details/15994/)のような個別解説と合わせて検討してください。 ## 権限モデルと継承の実装：USE CATALOGとUSE SCHEMAの二段構え 実装で最も問い合わせを生むのが権限まわりです。構造を先に理解すると事故が減ります。 ### 使用特権とデータ特権を分けた二段構えのGRANT設計と継承の効き方 テーブルを1行読むために必要な特権は1つではありません。テーブルへの`SELECT`、親スキーマへの`USE SCHEMA`、親カタログへの`USE CATALOG`の3つが同時に揃って初めて読めます。後者2つはそれ自体が何かを読ませる特権ではなく、下の階層へ入る通行許可にあたるものです。テーブル所有者が`SELECT`を配っても、カタログ所有者が通行許可を出していなければアクセスは通りません。この構造があるからこそ、カタログ所有者が全体の境界を握れます。 もう一方の柱が継承です。スキーマに`SELECT`を付与すれば、現在および将来のテーブルとビューへ自動的に及びます。部署単位のカタログを切って通行許可を配り、データ特権はスキーマ単位で継承させる形が管理しやすい設計でした。テーブル単位の個別付与を積み重ねると、新しいテーブルが作られるたびに付与作業が発生します。 ### ALL PRIVILEGESが含まない3特権とMANAGEを分ける運用上の理由 `ALL PRIVILEGES`は名前のとおり広い特権ですが、意図的な例外が3つあります。`EXTERNAL USE SCHEMA`、`EXTERNAL USE LOCATION`、そして`MANAGE`は含まれません。前2つは外部処理エンジンへ一時資格情報を渡す特権で、うっかり配ると想定外のデータ持ち出し経路が開くためです。外部ロケーションの所有者ですら既定では持ちません。 `MANAGE`は所有権に近い特権で、権限の管理、所有権の移譲、名称変更、削除ができます。所有者と違うのは、持つだけではデータ特権が自動で付かない点です。権限を配る役とデータを読む役を分離できます。コンテナへ付けると子オブジェクトすべてへ及ぶため、カタログ単位の管理委任に使えました。なお付与されていない特権は暗黙的に拒否され、`DENY`にあたる仕組みは持ちません。 ### BROWSEで発見だけ全社へ開く権限設計と要求ベース運用の手順 権限設計で見落とされやすいのが`BROWSE`です。データ本体へのアクセスを与えないまま、オブジェクトの存在・名前・説明・タグを見せ、アクセス権の要求を可能にする特権にあたります。カタログレベルで付与でき、通行許可を持たないユーザーでもメタデータを辿れる点が効きました。 1. 全アカウントユーザーのグループへカタログ単位で`BROWSE`を付与する 2. 利用者はカタログエクスプローラーで対象を探し、アクセス権を要求する 3. 管理者は要求に応じて通行許可とデータ特権を付与する 4. 付与はスキーマ単位で行い、継承で将来のテーブルまで届かせる この形にすると、管理者が先回りして権限を配る必要がなくなります。逆に配らないと、利用者は見えていないデータの存在を知る手段を持たず、整備の効果が出ないまま終わりがちです。 ## Hive metastoreとの違いと移行経路の選び分けを決める判断軸 既存ワークスペースを持つ組織にとって、実務の中心は移行です。 ### hive\_metastoreカタログとして併存させる移行期の実装と制約 Unity Catalogのメタストアは加算的な仕組みで、ワークスペースごとの従来型Hive metastoreと併存できます。従来のテーブルは3レベル名前空間の中で`hive_metastore`という最上位カタログとして見えるため、`hive_metastore.sales.sales_raw`のように書けば従来資産をそのまま参照でき、両者を結合するクエリも書けました。 ただし併存には性質の違いが残ります。Unity Catalogはアカウントレベルのオブジェクトで権限はアカウントグループへ適用されるのに対し、Hive metastore側はワークスペースレベルでローカルグループが対象です。従来のテーブルアクセス制御にあった`ANY FILE`や`ANONYMOUS FUNCTION`という概念は存在せず、`READ_METADATA`特権もありません。ビューの扱いも変わり、所有者が参照先テーブルの所有者である必要はなく`SELECT`があれば足ります。従来側には1時間あたりの同時接続数などの制限もあり、ジョブの同時起動が集中すると接続エラーになりました。 ### 一括アップグレードとHiveメタストアフェデレーションの選び分け 移行経路は2つ用意されています。登録済みテーブルをすべてUnity Catalogへアップグレードする一括型と、Hiveメタストアフェデレーションで従来のメタストアをミラーする外部カタログを作る段階型です。判断軸は単純にできます。対象が数十テーブルで参照ジョブの棚卸しが現実的なら一括型、数百規模で依存が読み切れないなら段階型でミラーを先に作り、参照経路を順に切り替えていく。 どちらの経路でも、移行後にHive metastoreへの直接アクセスを明示的に無効化する工程を計画へ入れてください。既定ではクラスタは移行後も従来のメタストアへ接続し続けるため、省くと新旧どちらを読んでいるか分からない状態が残ります。無効化はワークスペース全体でもクラスタ個別でも設定できました。 ## 導入前に押さえるコンピュート要件と後戻りを生む制限事項の確認手順 要件と制限は、設計に入る前に通しで読む価値があります。 ### Databricks Runtime 11.3 LTS以降とアクセスモードという前提 コンピュート側の前提は2つです。クラスタはDatabricks Runtime 11.3 LTS以降である必要があり、それ以前のランタイムではGAの全機能が揃いません。SQLウェアハウスは全バージョンで既定サポートです。もうひとつがアクセスモードで、標準または専用に構成されていないクラスタはデータへ到達できません。「権限は正しいのに見えない」という症状の相当数はここが原因でした。 ランタイム依存の制限も残ります。Python UDFはDatabricks Runtime 12.2 LTS以下では動かず、スカラーUDFは13.3 LTS以降のサポートです。標準アクセスモードでのScala UDFは14.2以降で使えます。行や列のセキュリティを効かせた動的ビューをRから照会する用途では、15.4 LTS以降の専用コンピュートが前提になりました。サーバーレス側の構成やコストは[Azure Databricksのサーバーレスコンピューティング｜種類・NCCとネットワーク・コスト管理](https://www.issoh.co.jp/tech/details/4362/)で扱っています。 ### 命名規則とバケット非対応など設計をやり直させる制限事項の実際 名前の制約は先に共有しておくと手戻りが減ります。オブジェクト名は255文字以内で、ピリオド・空白・スラッシュ・ASCII制御文字は使えません。名前はすべて小文字で格納され、ハイフンなどを含む名前をSQLで参照するときはバッククォートでのエスケープが要ります。列名は特殊文字を許容し大文字小文字も保持されますが、クエリ時の照合は区別しません。 設計をやり直させる制限として押さえたいのはバケットの非対応です。Unity Catalogのテーブルはバケット化をサポートせず、作成しようとするコマンドは例外になります。既存のHive metastore側でバケット設計を前提にしたテーブルを持っているなら、移行の見積もりへ再設計の工数を織り込んでください。ほかに実務で当たるのは、ワークスペースレベルの従来型グループが`GRANT`文で使えない点と、外部テーブルのパーティション操作にメタデータログの有効化が要る点でした。 ## Unity Catalog OSS版と外部エンジン接続から見る採用条件と見送り基準 ここからはDatabricksの外側から見た位置づけと、採用可否の線引きを条件付きで示します。 ### 2026年8月時点のOSS版リポジトリ実測とリリース系の位置づけ Unity Catalogはオープンソース実装としても公開されています。2026年8月4日にGitHub APIで確認した実測値は、リポジトリ作成が2024年6月13日、スター3,475、フォーク656、オープンissue447、ライセンスはApache-2.0、主要言語はJava、直近のプッシュは2026年8月3日でした。リリースは2026年6月18日のv0.5.0に続き、7月18日にv0.5.1が出ています。リポジトリ自身はデータとAIの資産を同じカタログで扱う方向を掲げました。 読み取るべきは版番号です。0.5系という段階にあり、マネージド機能と同じ成熟度を期待して本番のガバナンス基盤に据えるのは早いでしょう。OSS版が効くのは、カタログAPIの互換性や複数エンジンからの接続構成を手元で確かめたい場面です。同じくOSSのカタログ製品には[Apache Polarisとは何か？Apache Icebergに対応するオープンソースカタログの機能と利点を徹底解説](https://www.issoh.co.jp/tech/details/9631/)があり、Iceberg中心の構成では比較対象へ入ります。 ### Iceberg REST APIで外部エンジンから読む構成と権限の落とし穴 外部の処理エンジンからテーブルを読む経路も用意されています。仕組みは、オープンAPIまたはIceberg REST APIを通じて一時的な資格情報を取得する形です。この経路を開くのが`EXTERNAL USE SCHEMA`で、2026年8月時点ではパブリックプレビューの位置づけになっています。 落とし穴は権限の付与ルートにあります。前述のとおり`ALL PRIVILEGES`にこの特権は含まれず、スキーマ所有者も既定では持ちません。付与できるのはカタログ所有者だけです。外部ロケーションを直接叩く`EXTERNAL USE LOCATION`も同様で、こちらは`MANAGE`を持つユーザーだけが配れます。設計時は誰が配る権限を持つかを先に決め、経路を1本に絞ってください。通常のテーブル権限と同じ感覚で扱うと監査で穴になります。 ### Unity Catalogを採用してよい条件と見送るべき3つの場面の判断 採用してよいのは次の条件が揃うときです。分析基盤の中心がDatabricksであること、部署や環境をまたいで同じデータを参照すること、アクセス権の付与と棚卸しを担う担当を最低1名置けること。揃うなら階層設計と継承の効果が工数を上回ります。 見送る、あるいは急がなくてよい場面は3つあります。第一に、Databricksを使っておらず、整備対象が複数ベンダの製品にまたがる場合。ベンダ非依存のOSSカタログのほうが合い、[OpenMetadataとは？データカタログOSSの構成・実装手順と採用判断を解説【2026年版】](https://www.issoh.co.jp/tech/details/16132/)で扱った製品群が候補になります。第二に、単一ワークスペースで対象が数テーブル、閲覧者が全員同権限で足りる規模。階層設計そのものが空回りします。第三に、バケット設計や従来型グループへ深く依存した資産が大量にあり、再設計の工数を確保できない状況。ここはフェデレーションで併存させ、予算が取れた時点で寄せる進め方が現実的でした。 ## 自社のデータ基盤へ載せるときの体制と初期工数の見積もりの進め方 最後に、社内へ載せる前提で工数と体制を具体化します。 ### 棚卸しと所有者割り当てに寄る立ち上げ工数の内訳と見積もり手順 工数の重心は設定作業ではありません。既定で有効なワークスペースなら、技術的な立ち上げはカタログとスキーマを切って権限を構成するまでで済みます。重いのはその前後で、どのデータをどのカタログへ置くかの合意、所有者の割り当て、既存ジョブが参照する名前空間の棚卸しでした。とくに従来資産を抱える環境では、参照側のコードが`hive_metastore`を前提にしている箇所の洗い出しが全体の山になります。 見積もりは、対象テーブル数と参照ジョブ数を数え、バケット依存など再設計が要る資産を抽出し、移行経路を一括型と段階型で分けて見る順が扱いやすいでしょう。再設計の有無で工数が数倍変わる構造が早い段階で見えます。 ### 内製と外部委託で変わる運用体制の設計と移管までの進め方の判断 体制の判断は、基盤エンジニアが社内にいるかどうかで分かれます。いるなら、階層設計と権限モデルの初期設計だけ外部の知見を借り、構築と運用は内製する形が費用面で有利でした。いない場合は、カタログ設計から移行、権限の初期構成、監査とリネージの運用ルールづくりまでを一括で委ね、運用を段階的に引き継ぐ進め方が無理のない選択でしょう。どちらでも、権限の棚卸しを誰がいつ回すかを決めずに走ると、付与だけが増えて剥がされない状態になります。一創では[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)として、ガバナンス層の設計・構築から運用移管までを請け負っています。 ## よくある質問 導入検討でよく挙がる質問を、実装と運用の観点でまとめます。 ### Unity Catalogを使うのに追加の申し込みは要りますか？ 2023年11月9日以降に作成されたDatabricksワークスペースでは自動的に有効になっているため、別途の導入作業は不要です。まずセットアップガイドに沿って有効化状態と構成を確認してください。それ以前のワークスペースはアップグレードの手順を踏みます。有効化より、既存のHive metastore資産をどう扱うかの設計へ時間を配分するほうが実務的でした。 ### 権限を付与したのにテーブルが読めないのはなぜですか？ 原因の多くは通行許可の欠落です。テーブルを読むには`SELECT`に加えて、親スキーマへの`USE SCHEMA`と親カタログへの`USE CATALOG`が同時に要ります。テーブル所有者が`SELECT`を配っても、カタログ側の通行許可がなければ到達できません。もうひとつ多いのがクラスタのアクセスモードで、標準か専用に構成されていないクラスタからは到達できない仕様です。 ### Hive metastoreとUnity Catalogは併用できますか？ 併用できます。従来のメタストアは3レベル名前空間の中で`hive_metastore`という最上位カタログとして見え、両者を結合するクエリも書けます。ただし結合はそのデータが存在するワークスペース内でのみ成立し、別ワークスペースから実行するとエラーになりました。移行が済んだら、直接アクセスを明示的に無効化するところまでを工程へ含めてください。 ### マネージドテーブルと外部テーブルはどちらを選ぶべきですか？ 新規に作る分析用テーブルはマネージド、既存のクラウドストレージ上の資産は外部から入る切り分けが扱いやすいでしょう。マネージドは`delta`と`iceberg`の2形式に限られる代わりに、ファイルのライフサイクルまで任せられます。外部はCSVやParquetなど幅広い形式を受けますが、ガバナンスのみが対象です。浅いクローンは同じ種別同士でしか成立しません。 ### 外部の処理エンジンからUnity Catalogのテーブルを読めますか？ Unity CatalogのオープンAPIまたはIceberg REST APIを通じて一時的な資格情報を取得する経路が用意されています。必要な特権は`EXTERNAL USE SCHEMA`で、2026年8月時点ではパブリックプレビューの位置づけです。この特権は`ALL PRIVILEGES`に含まれず、スキーマ所有者も既定では持たないため、カタログ所有者が明示的に付与します。 ## 関連記事 - [DataHubとは？OSSメタデータ基盤の構成・取り込み実装と採用判断を解説【2026年版】](https://www.issoh.co.jp/tech/details/16128/)：ベンダ非依存でカタログを組む場合の代替候補として比較できます - [Azure Databricksのサーバーレスコンピューティング｜種類・NCCとネットワーク・コスト管理](https://www.issoh.co.jp/tech/details/4362/)：Unity Catalogが前提とするコンピュート側の構成とコストが分かります - [Apache Hudiとは？レコード単位の更新と増分取り込みを支える仕組みを実装視点で解説【2026年版】](https://www.issoh.co.jp/tech/details/15994/)：カタログの下に置くテーブル形式の選び方に触れています --- 出典: [Unity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】]()（株式会社一創）