全社のデータ分析基盤としてDatabricksを使い、部門ごとにアクセス権限を細かく分けて運用してきた数千人規模企業のデータガバナンス担当者は、Unity Catalog（Databricksのデータ資産を横断的に管理・統制する仕組み）上のMANAGE権限（権限の付与や所有権の移転を行える、実質的にオブジェクト所有者に近い管理権限）の付与状況を、あらためて棚卸しする必要が出てきた。情報システム部門やデータガバナンス部門が過去数年かけて設計した権限体系が、2026年8月3日付の仕様変更によって意図せず範囲を広げている可能性があるためだ。
対象はUnity Catalogの権限モデルそのもので、カタログ・スキーマ単位で権限を委譲する運用をしている組織ほど影響が大きい。この変更は新機能の追加ではなく、既存のMANAGE権限の「効き方」を変えるものであり、過去に付与した権限が管理者の意図を超えて有効化される点が実務上の論点になる[1]。その1週間後の8月10日にはREAD METADATA権限（権限付与状況などの機微な情報を読み取れる権限）が正式提供（GA）となり、監査効率と情報露出のトレードオフも生まれた[1][2]。本稿では変更の中身と、既存付与の点検手順を整理する。
予備知識
- Unity Catalog: Databricks上のカタログ・スキーマ・テーブルなどのデータ資産を横断的に管理し、アクセス権限を一元統制する仕組み。
- MANAGE権限: 対象オブジェクトの権限付与・剥奪、所有権移転ができる管理者相当の権限。
- USAGE権限（USE CATALOG／USE SCHEMA）: カタログやスキーマに「アクセスする土台」を得るための前提権限。単独ではデータ本体は読めない。
- READ METADATA権限: 権限付与状況、行フィルタ、列マスクなど、所有者やMANAGE保持者と同等の機微なメタデータを読み取れる権限。
- BROWSE権限: オブジェクトの存在・名前・タグなど、機微情報を含まない範囲だけを閲覧できる軽い権限。
権限設計を含むデータガバナンス体制をどう仕組み化するかを、実務目線で確認できる
MANAGE権限の何が変わったのか
2026年8月3日付の仕様変更は、MANAGE権限を行使する際に対象オブジェクト自体のUSAGE権限を別途持つ必要がなくなった、という挙動変更だ[1]。以前は、あるスキーマを管理するにはUSE CATALOG＋USE SCHEMA＋MANAGEの3つを同時に持つ必要があった。変更後は、そのスキーマ自体についてはUSE CATALOG＋MANAGEの2つで足り、対象スキーマ分のUSE SCHEMAは不要になった。
免除されるのは対象オブジェクト自体の分だけで、親コンテナ（カタログ）側のUSAGE権限は引き続き必須だ[1]。Databricksはこの変更を「MANAGE権限の挙動をオブジェクト所有者の挙動に近づけるもの」と説明している。所有者はUSAGE権限の有無にかかわらず自分のオブジェクトを管理できるが、従来のMANAGE権限保持者はUSAGE権限を欠くと管理操作が機能しない場面があった。その非対称性を解消する変更だ[1]。
| 対象 | 変更前（〜2026年8月2日） | 変更後（2026年8月3日〜） |
|---|---|---|
| カタログのMANAGE | USE CATALOG + MANAGE | MANAGE のみ（USAGE不要） |
| スキーマのMANAGE | USE CATALOG + USE SCHEMA + MANAGE | USE CATALOG + MANAGE（USE SCHEMA不要） |
| テーブル・ビュー・ボリューム・関数のMANAGE | USE CATALOG + USE SCHEMA + MANAGE | 変更なし（従来どおり両方必要） |
| MANAGEの挙動 | 所有者と非対称 | 所有者の挙動に統一 |
最小権限の原則に基づくアクセス制御設計の考え方を、Databricks以外の文脈も含めて整理できる
なぜ「総点検」が必要なのか
この変更で最も注意すべきなのは、過去に権限委譲を簡略化する目的でUSAGE権限を伴わずMANAGE権限だけを広く付与していたケースが、変更後に実際に機能し始める点だ[1]。複数部門の管理者にスキーマ横断のMANAGE権限を委譲する際、USE SCHEMAをあえて付与せず事実上のブロック役として使っていた設計があれば、8月3日以降はその制限が外れる。
Databricksはリリースノートの中で、既存のMANAGE権限付与を確認するよう明確に推奨している[1]。これは「新たに危険な権限を付与した」のではなく「過去の設計で眠っていた権限が起動した」状態であり、権限一覧上の見た目は変わらないまま挙動だけが変わる点が点検を難しくする。
READ METADATA権限のGA、監査効率と新たな露出面
READ METADATA権限は、所有者やMANAGE保持者と同じ範囲のメタデータ（権限付与状況、行フィルタ、列マスク、ABACポリシーなど）を読み取り専用で閲覧できる権限で、2026年8月10日にGAとなった[1]。セキュリティ監査担当者やデータガバナンスチーム、SREがアクセス制御を点検・デバッグする用途を想定した権限であり、データ本体へのアクセス権は伴わない[2]。
一方でBROWSE権限はオブジェクトの存在・名前・説明・タグを閲覧できるだけで、権限付与状況のような機微情報は見えない。READ METADATA権限はBROWSEより一段深く、MANAGEより浅い中間層にあたる。Databricksはこの権限を「機微なメタデータを扱うため、信頼できるプリンシパルにのみ付与すべき」と注記している[2]。
| 権限 | データ本体へのアクセス | メタデータ閲覧範囲 | 権限管理 |
|---|---|---|---|
| BROWSE | 不可 | 存在・名前・タグのみ | 不可 |
| USAGE | 前提のみ（単独では不可） | 不可 | 不可 |
| READ METADATA | 不可 | 権限付与状況・行フィルタ・列マスク等を含め全読取 | 不可 |
| MANAGE | データ権限の有無に依存 | 全読取 | 可（付与・剥奪・所有権移転） |
| OWNER | 全て | 全て | 全て |
日本企業の権限棚卸しはなぜ承認まで時間がかかるのか
Unity Catalogを使う限り、同じ仕様変更の影響は国内企業にも等しく及ぶ。違うのは点検から是正までの所要時間だ。日本企業は運用をSIerに委託しているケースが多く、権限設計の変更検知から改修提案までに保守契約上のエスカレーション経路を経る。加えて既存権限を剥奪する変更には稟議が必要で、変更管理プロセス上は「小さな設定変更」であっても承認に数週間かかることがある。
内部統制・監査対応も国内特有の負荷を生む。日本版SOX対応が求められる上場企業では、権限棚卸しの実施記録そのものが監査証跡になるため、点検して終わりではなく「いつ・誰が・何を確認したか」を残す作業が追加で発生する。
| 観点 | 一般的な想定 | 日本企業で追加される負荷 |
|---|---|---|
| 変更の実施主体 | 社内データ基盤チーム | SIer委託の場合は契約範囲の確認から |
| 権限剥奪の承認 | 担当者判断で即時 | 稟議・変更管理承認が前提 |
| 監査対応 | 点検結果の把握で足りる | 実施記録を監査証跡として保存 |
IT部門の判断は、まず影響範囲（MANAGE権限付与済みのオブジェクト一覧）を機械的に洗い出し、USAGE権限の有無で「新たに有効化された組」を先に特定することだ。決裁側は、是正の緊急度を「機微データを含むスキーマか否か」で切り分け、監査証跡が必要な対象から優先的に予算と期限を割り当てる判断が求められる。
まとめ
IT部門の担当者は、Unity Catalog上のMANAGE権限付与一覧を洗い出し、USAGE権限を伴わない付与から優先的に点検する一手を早期に着手する。決裁側は、機微データを扱うスキーマを対象にした是正対応に限って優先予算と期限を割り当て、全件同時対応によるコスト膨張を避ける判断をする。仕様変更そのものはDatabricksの設計改善だが、既存の権限設計が意図と食い違う形で有効化される点は、運用側の点検抜きには解消しない。
よくある質問（FAQ）
Q1. MANAGE権限の変更はいつから適用されますか？
2026年8月3日付で適用されています。既存のMANAGE権限付与は自動的に新しい挙動になり、明示的な再設定は不要です[1]。
Q2. READ METADATA権限は誰に付与すべきですか？
セキュリティ監査担当者やデータガバナンスチームなど、権限設定を点検・デバッグする役割に限定すべきとDatabricksは推奨しています。権限付与状況など機微な情報が見えるため、付与対象は絞り込む必要があります[2]。
Q3. 既存のMANAGE権限を安全な状態に戻すにはどうすればよいですか？
まずMANAGE権限付与一覧とUSAGE権限の有無を突き合わせ、意図せず有効化された組み合わせを洗い出します。その上で、委譲範囲を絞りたい場合はMANAGE自体を剥奪するか、より狭いREAD METADATA権限への置き換えを検討します。
