Azure Databricksのusersシステムグループから自動継承される権限を前提に、SCIMやTerraformでユーザーを追加している環境は、移行前の見直しが必要です。2026年9月14日以降、usersグループはentitlementを持たなくなり、新しく追加するユーザー、グループ、サービスプリンシパルには必要なworkspace entitlementを明示的に付与しなければなりません。
特に危険なのは、既存ユーザーの権限が移行用クローングループによって維持されるため、一見すると問題なく移行できたように見える点です。実際には、移行後に追加したユーザーだけがワークスペースへ入れない、SQL機能を使えない、ジョブを実行できないといった問題が起こり得ます。
対策は、SCIM・Terraform・運用手順を「ユーザーをワークスペースへ追加する処理」と「entitlementを付与する処理」に分け、consumer-only利用者とauthoring利用者を別グループで管理することです。公式の移行機能と手順はすでに提供されています。(Microsoft Learn)
結論：usersグループ継承を前提にした自動化を廃止する
Azure Databricks workspace entitlementsの移行では、次の4つを別々の設定として管理する必要があります。
- Microsoft Entra IDからAzure DatabricksアカウントへIDを同期する
- ユーザーやグループを対象ワークスペースへ割り当てる
- Consumer access、Databricks SQL access、Workspace accessを明示的に付与する
- SQLウェアハウス、ノートブック、ジョブ、Unity Catalogデータなどの権限を付与する
これまでの構成では、ワークスペースへ追加されたプリンシパルが自動的にusersグループへ入り、そこからWorkspace accessとDatabricks SQL accessを継承することが一般的でした。新しい動作ではusersグループのentitlementが空になり、adminsグループにはすべてのworkspace entitlementが固定で付与されます。両システムグループのentitlementは変更できなくなります。(Microsoft Learn)
| 項目 | 従来の動作 | 新しい動作 |
|---|---|---|
usersグループ | Workspace accessやDatabricks SQL accessを継承元として利用 | entitlementなし、変更不可 |
adminsグループ | 管理者向けentitlementを保持 | すべてのworkspace entitlementを保持、変更不可 |
| 新規プリンシパル | usersから自動継承 | 追加時にentitlementを明示 |
| 既存プリンシパル | usersから継承 | クローングループへ移行して維持 |
| システムグループのネスト | 構成によっては利用されている | usersとadminsのネストは禁止 |
| Terraform・SCIM | usersを更新するコードが動作 | システムグループ更新は失敗 |
したがって、次のような処理だけでユーザー登録を完了させている場合は要修正です。
resource "databricks_permission_assignment" "user" {
principal_id = var.principal_id
permissions = ["USER"]
}Terraform Providerのpermissions = ["USER"]は、プリンシパルをワークスペースのusersグループへ追加する設定です。しかし、新しい動作ではusersグループにentitlementがないため、移行後はUSER割り当てをワークスペース所属の設定として扱い、別途databricks_entitlementsで機能アクセスを明示する設計が安全です。 (GitHub)
2026年9月14日までの移行スケジュール
公式に示されている移行スケジュールは次のとおりです。(Microsoft Learn)
| 日付 | 変更内容 | 管理者が行うこと |
|---|---|---|
| 2026年6月15日 | 新しい動作への事前移行が可能 | 検証環境でオプトインする |
| 2026年7月27日 | オプトイン・オプトアウトしていないワークスペースで自動有効化 | 自動有効化前に自動化を点検する |
| 2026年9月14日 | すべての対象ワークスペースで強制適用 | オプトアウト不可。明示的entitlementへ完全移行する |
2026年7月27日の自動有効化後も、9月14日までは一時的にオプトアウトできます。ただし、9月14日以降は元の動作へ戻せません。
なお、公式の移行ドキュメントでは、この変更はAzure Governmentワークスペースには適用されないとされています。(Microsoft Learn)
SCIM・Terraformで起こりやすい4つの問題
permissions = ["USER"]だけで登録を完了している
最も起こりやすいのは、SCIMやTerraformでユーザーまたはグループをワークスペースへ追加した時点で、権限付与も完了したと判断している構成です。
新しい動作では、ワークスペースに所属していても、少なくとも1つのアクセスentitlementがなければワークスペースを利用できません。アクセスentitlementにはConsumer access、Databricks SQL access、Workspace accessがあります。(Microsoft Learn)
次のような自動化は見直し対象です。
- Microsoft Entra IDのグループ同期だけで利用開始としている
databricks_permission_assignmentまたはdatabricks_mws_permission_assignmentのUSER割り当てだけを実行している- SCIMでユーザーを作成した後、entitlementの付与処理がない
- 手順書に「ユーザーを追加すれば自動的にSQLとWorkspaceが利用可能」と記載している
移行後は、ID同期成功、ワークスペース割り当て成功、entitlement付与成功を別々に確認してください。
usersまたはadminsをTerraformで更新している
次のようにシステムグループを取得し、entitlementを設定しているコードは移行対象です。
data "databricks_group" "users" {
display_name = "users"
}
resource "databricks_entitlements" "workspace_users" {
group_id = data.databricks_group.users.id
workspace_access = true
databricks_sql_access = true
}新しい動作ではusersとadminsのentitlementがロックされるため、Terraform、Workspace SCIM API、独自スクリプトから変更しようとすると失敗します。公式も、自動化の対象をシステムグループから標準のアカウントグループへ変更するよう案内しています。(Microsoft Learn)
Terraformコードは、次の文字列をリポジトリ全体から検索すると見落としを減らせます。
rg -n \
'display_name\s*=\s*"users"|display_name\s*=\s*"admins"|databricks_entitlements|permissions\s*=\s*\["USER"\]' \
.Terraform以外にも、PowerShell、Python、Azure DevOps Pipeline、GitHub Actions、Databricks CLIのスクリプトを確認してください。
SCIMのクリーンアップ処理がクローングループを削除する
移行時、Azure Databricksはusersに付与されていたentitlementを、標準では次の名前を持つワークスペースローカルグループへ移します。
users-clone-<TIMESTAMP>既存のユーザー、サービスプリンシパル、ワークスペースへ直接割り当てられているアカウントグループも、このクローングループへ追加されます。これにより既存プリンシパルのアクセスレベルが維持されます。(Microsoft Learn)
ただし、SCIM同期や独自の整合性チェック処理が「Microsoft Entra IDに存在しないワークスペースローカルグループを削除する」設計になっていると、クローングループが削除される可能性があります。クローングループを削除すると、そこからentitlementを受け取っていた既存プリンシパルが権限を失います。公式にも、SCIM同期が認識していないグループを削除する場合は、クローングループを保存するよう設定変更が必要と明記されています。(Microsoft Learn)
除外設定では、タイムスタンプを含む完全一致ではなく、次のような命名規則や専用の固定名を使用する方が安全です。
adb-entitlement-migration-existing-authors事前オプトインではクローングループ名を指定できるため、自動削除対象から明確に除外できる名前に変更しておくと運用しやすくなります。
usersやadminsを別グループへネストしている
新しい動作では、usersおよびadminsシステムグループを別グループのメンバーとしてネストできません。既存構成にネストがある場合は、移行前に解消する必要があります。(Microsoft Learn)
また、Microsoft Entra IDとの同期方法にも注意が必要です。Azure DatabricksのAutomatic Identity Managementはネストされたグループをサポートしますが、従来のSCIM provisioning connectorはネストグループをサポートしません。SCIMを継続利用する場合は、必要に応じてメンバーシップをフラット化してください。(Microsoft Learn)
consumer-only利用者とauthoring利用者を分ける
新しい明示的entitlementの利点は、閲覧だけを行うビジネスユーザーへ、ノートブックやクエリの作成権限を自動的に与えずに済むことです。
アクセスentitlementごとの主な違いは次のとおりです。(Microsoft Learn)
| 利用者タイプ | 推奨entitlement | 主な用途 | 移行テスト |
|---|---|---|---|
| consumer-only | Consumer accessのみ | 共有されたダッシュボード、Genie Agents、Databricks Appsの閲覧・実行 | 閲覧でき、オブジェクトを新規作成できない |
| SQL利用者 | Databricks SQL access | SQLクエリ、SQLウェアハウス、ダッシュボードの作成・編集 | SQLエディターを利用できる |
| データエンジニア・データサイエンティスト | Workspace access | ノートブック、ジョブ、モデル、パイプライン | ノートブックやジョブを作成できる |
| 複合的な作成者 | Workspace accessとDatabricks SQL access | ノートブックとSQLの両方を作成 | 両方の画面・機能を利用できる |
| ワークスペース管理者 | Admin割り当て | ワークスペース設定・ID管理 | 管理画面を操作できる |
| 自動化用サービスプリンシパル | 処理に必要なentitlementのみ | ジョブ、API、デプロイ | 対象ジョブとAPIだけが成功する |
Consumer accessは他のentitlementと組み合わせるための「追加権限」ではありません。entitlementは加算方式であり、Consumer accessにWorkspace accessやDatabricks SQL accessを追加すると、consumer-only向けの制限された画面ではなくなります。consumer-only利用者にはConsumer accessだけを付与してください。(Microsoft Learn)
また、ダッシュボードの閲覧だけが目的であれば、そもそもワークスペースへ所属させる必要がないケースもあります。Azure Databricksアカウントのユーザーは、共有方法やデータ構成によってはワークスペースメンバーにならずに公開済みダッシュボードを閲覧できます。一方、ワークスペースに紐づくセキュラブル、共有されたGenie Agents、Databricks Apps、限定されたワークスペースUIが必要な場合はConsumer accessを検討します。(Microsoft Learn)
entitlementとデータ権限を混同しない
Workspace accessやDatabricks SQL accessを付与しても、すべてのデータやオブジェクトを自動的に利用できるわけではありません。
たとえばDatabricks SQL accessを持つユーザーがSQLウェアハウスでクエリを実行するには、別途次のような権限が必要です。
- SQLウェアハウスに対する利用権限
- Unity Catalogのカタログ、スキーマ、テーブルに対する権限
- ダッシュボードやクエリに対するACL
- 必要に応じて行フィルターや列マスクを通過できる権限
Workspace accessについても同様に、ノートブック、フォルダー、ジョブ、クラスター、クラスターポリシーなどの権限は別管理です。
移行設計では、次の4層を同じTerraformリソースやSCIM処理へ混在させないことが重要です。
| レイヤー | 管理対象 | 主な管理手段 |
|---|---|---|
| ID同期 | ユーザー、グループ、サービスプリンシパル | Automatic Identity Management、SCIM |
| ワークスペース割り当て | USER、ADMIN | Permission Assignment API、Terraform |
| entitlement | Consumer、SQL、Workspace、Compute | Workspace SCIM API、Terraform |
| リソース・データ権限 | SQLウェアハウス、ジョブ、Unity Catalogなど | Permissions API、Unity Catalog grants、Terraform |
Terraformの修正例
Terraformでは、ワークスペース割り当てとentitlementを別リソースとして管理できます。
次の例では、Microsoft Entra IDから同期されたアカウントグループを、consumer-onlyグループとauthoringグループに分けています。
data "databricks_group" "consumers" {
provider = databricks.account
display_name = "adb-ws-consumers"
}
data "databricks_group" "authors" {
provider = databricks.account
display_name = "adb-ws-authors"
}
resource "databricks_permission_assignment" "consumers" {
provider = databricks.workspace
principal_id = data.databricks_group.consumers.id
permissions = ["USER"]
}
resource "databricks_permission_assignment" "authors" {
provider = databricks.workspace
principal_id = data.databricks_group.authors.id
permissions = ["USER"]
}
resource "databricks_entitlements" "consumers" {
provider = databricks.workspace
group_id = data.databricks_group.consumers.id
workspace_consume = true
depends_on = [
databricks_permission_assignment.consumers
]
}
resource "databricks_entitlements" "authors" {
provider = databricks.workspace
group_id = data.databricks_group.authors.id
workspace_access = true
databricks_sql_access = true
depends_on = [
databricks_permission_assignment.authors
]
}databricks_entitlementsで利用できる主なTerraform属性は次のとおりです。(GitHub)
| Terraform属性 | 対応するentitlement |
|---|---|
workspace_consume | Consumer access |
workspace_access | Workspace access |
databricks_sql_access | Databricks SQL access |
allow_cluster_create | Allow unrestricted cluster creation |
allow_instance_pool_create | Allow pool creation |
workspace_consumeは、workspace_accessまたはdatabricks_sql_accessと同じプリンシパルへ同時に設定できません。
また、同じプリンシパルのentitlementをdatabricks_groupやdatabricks_userの属性とdatabricks_entitlementsの両方で管理すると、非決定的な動作になると公式Providerドキュメントに記載されています。entitlementの管理先は1つのリソースへ統一してください。(GitHub)
databricks_entitlementsはワークスペースレベルの設定であるため、移行時はワークスペース用Providerを明示的に使う構成が分かりやすく、安全です。複数ワークスペースを管理する場合は、ワークスペースごとにProvider aliasとentitlementリソースを分けてください。
unrestricted cluster creationを安易に付与しない
Workspace accessを付与したからといって、allow_cluster_create = trueも一律に付与する必要はありません。
一般ユーザーにはクラスターポリシーに対する利用権限を与え、ポリシーの範囲内でクラスターを作成させる方法があります。allow_cluster_createは、制限のないクラスター作成が業務上必要なユーザーやサービスプリンシパルだけに限定するのが安全です。Terraform Providerの公式ドキュメントでも、allow_cluster_createがなくてもクラスターポリシーの利用権限があれば、そのポリシー内でクラスターを作成できると説明されています。(GitHub)
Workspace SCIM APIを使う場合の更新方法
Workspace SCIM APIでは、次のAPI名を使用してentitlementを管理します。(Microsoft Learn)
| 表示名 | API名 |
|---|---|
| Consumer access | workspace-consume |
| Workspace access | workspace-access |
| Databricks SQL access | databricks-sql-access |
| Allow unrestricted cluster creation | allow-cluster-create |
| Allow pool creation | allow-instance-pool-create |
たとえば標準のアカウントグループへConsumer accessを付与する場合は、Workspace Groups APIを使用します。
curl --netrc -X PATCH \
https://<workspace-host>/api/2.0/preview/scim/v2/Groups/<group-id> \
--header 'Content-Type: application/scim+json' \
--data @consumer-entitlement.jsonconsumer-entitlement.jsonは次のようにします。
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "add",
"path": "entitlements",
"value": [
{
"value": "workspace-consume"
}
]
}
]
}このPATCHの送信先をusersまたはadminsにしてはいけません。移行後はシステムグループのentitlement変更が拒否されます。
独自スクリプトでは、毎回無条件にentitlementを追加するのではなく、次の処理にしてください。
- 現在のentitlementを取得する
- 期待するentitlementセットと比較する
- 不足分の追加と不要分の削除を行う
- 再取得して期待値と一致することを確認する
- consumer-onlyグループにauthoring entitlementが混在していないことを確認する
SCIM同期が成功したことだけをもって、entitlement付与も成功したと判断しないことが重要です。
移行前チェックリスト
| 確認項目 | 合格条件 | 問題がある場合の影響 |
|---|---|---|
usersへのentitlement設定 | Terraform・API・スクリプトに存在しない | 移行後に更新処理が失敗 |
adminsへのentitlement設定 | 変更処理が存在しない | 移行後に更新処理が失敗 |
USER割り当て後の処理 | 明示的entitlement付与がある | 新規ユーザーが利用不能 |
| Consumer access設計 | Consumer accessだけを持つ専用グループがある | 閲覧者が作成機能まで利用 |
| authoring設計 | SQL、Workspace、複合利用者を区別している | 過剰権限または機能不足 |
| サービスプリンシパル | 必要なentitlementがコード化されている | ジョブ、API、デプロイが失敗 |
| クローングループ | SCIM削除・棚卸し処理の除外対象 | 既存ユーザーが権限喪失 |
| システムグループのネスト | users、adminsのネストなし | 移行エラーまたは構成不整合 |
| Terraform管理の重複 | 1プリンシパルにつき1管理元 | ドリフトや非決定的変更 |
| オブジェクト権限 | entitlementとは別に検証 | ログインできても処理不能 |
| 新規ユーザーテスト | 移行後に新規追加して確認 | 既存ユーザーだけの試験で見落とす |
| 伝播待ち | 数分後に再検証する仕組み | 一時的な未反映を障害と誤認 |
グループメンバーシップの変更は、システム全体へ反映されるまで数分かかる場合があります。自動テストでは即時判定だけで失敗させず、一定間隔で再試行する設計が必要です。(Microsoft Learn)
安全な移行手順
現在のentitlementを記録する
移行前に、ユーザー、グループ、サービスプリンシパルごとの現在値を記録します。
最低限、次の情報を保存してください。
- プリンシパルID
- 表示名
- ユーザー、グループ、サービスプリンシパルの種別
- ワークスペースへの割り当て状態
- 直接付与されたentitlement
- グループから継承したentitlement
usersグループの現在のentitlementadminsグループの現在のentitlement- SQLウェアハウスやジョブなどの主要権限
画面のスクリーンショットだけではなく、APIまたはTerraform stateから機械的に比較できる形式で保存するのが理想です。
利用者をペルソナ別グループへ分ける
少なくとも次のグループを用意します。
adb-ws-consumers
adb-ws-sql-authors
adb-ws-workspace-authors
adb-ws-admins
adb-ws-automationすべての利用者へWorkspace accessとDatabricks SQL accessを一律付与する構成をそのまま再現するのではなく、実際の利用機能に合わせて縮小してください。
検証用ワークスペースで事前移行する
ワークスペース管理者は、ワークスペース設定の次の場所から新しい動作へ移行できます。
Settings
└ Advanced
└ Access control
└ New behavior: Choose entitlements when adding principals to workspacesUse new behaviorを選び、既存entitlementの移行先となるクローングループ名を指定して保存します。(Microsoft Learn)
クローングループを確認する
移行後は、次の状態を確認します。
- 指定したクローングループが作成されている
- 移行前に
usersが持っていたentitlementが付与されている - 直接追加されたユーザーとサービスプリンシパルが含まれている
- ワークスペースへ割り当てられていたアカウントグループが含まれている
usersのentitlementが空になっているadminsがすべてのworkspace entitlementを持っている
クローングループの直接メンバー数が、従来のusersグループより少なく見えることがあります。アカウントグループ経由で参加しているユーザーは、個人単位ではなくアカウントグループ自体がクローングループへ追加されるためです。人数だけで移行失敗と判断せず、グループ経由のアクセスも確認してください。(Microsoft Learn)
既存ユーザーではなく新規ユーザーで試験する
既存ユーザーはクローングループによって権限が維持されるため、既存アカウントだけの試験では自動化の不備を検出できません。
移行後に新しいテストユーザーを用意し、次の流れを実行してください。
- Microsoft Entra IDの対象グループへ追加する
- Azure Databricksアカウントへ同期されることを確認する
- 対象ワークスペースへ割り当てられることを確認する
- 期待するentitlementが付与されることを確認する
- 実際にサインインして機能を操作する
- 不要な機能を操作できないことも確認する
「できること」だけでなく、「できてはいけないこと」を確認するのが重要です。
ペルソナ別の受け入れテスト
consumer-only利用者
確認することは次のとおりです。
- サインイン後にGenie Oneの限定された画面へ移動する
- 共有されたダッシュボードを閲覧・実行できる
- 共有されたGenie AgentやDatabricks Appsを利用できる
- 新しいノートブックやSQLオブジェクトを作成できない
- Workspace accessやDatabricks SQL accessを継承していない
Consumer accessだけを持つユーザーは新しいワークスペースオブジェクトを作成できません。(Microsoft Learn)
SQL authoring利用者
次を確認します。
- SQLエディターを開ける
- クエリを作成・保存できる
- ダッシュボードを作成・編集できる
- 許可されたSQLウェアハウスを利用できる
- 許可されたUnity Catalogデータだけを参照できる
Databricks SQL accessはSQL機能へのアクセスを与えますが、SQLウェアハウスやデータの権限は別途必要です。(Microsoft Learn)
Workspace authoring利用者
次を確認します。
- ノートブックを作成・編集できる
- 許可されたジョブやパイプラインを作成できる
- クラスターポリシーの範囲内でコンピュートを利用できる
- 許可されていないクラスターやデータへアクセスできない
サービスプリンシパル
対話的な画面確認だけではなく、実際の自動処理を実行します。
- OAuthなど既存の認証方式で接続できる
- Jobs APIやWorkspace APIを呼び出せる
- Terraformやデプロイ処理を実行できる
- ジョブが必要なノートブックやデータへアクセスできる
- 不要なUIアクセスやクラスター作成権限を持っていない
移行後の症状から原因を切り分ける
| 症状 | 主な原因 | 確認する場所 |
|---|---|---|
| ユーザー追加は成功したがワークスペースへ入れない | アクセスentitlement未付与 | UserまたはGroupのEntitlements |
| consumer利用者が通常のワークスペース画面を利用できる | Workspace accessまたはSQL accessを継承 | Parent groupsとEntitlements |
| Terraform applyがシステムグループ更新で失敗 | usersまたはadminsを更新している | databricks_entitlementsの対象ID |
| 既存ユーザーが移行後に利用不能 | クローングループ削除、entitlement消失 | Workspace-local groups |
| 一部のグループメンバーだけ反映されない | ネストグループ、同期遅延、SCIM制限 | Entra IDとDatabricksのメンバー比較 |
| ログインできるがSQLを実行できない | SQLウェアハウスまたはデータ権限不足 | Warehouse permissions、Unity Catalog |
| ジョブだけ失敗する | サービスプリンシパルのentitlementまたはオブジェクト権限不足 | Job owner、Run as、Workspace access |
| consumer-onlyにならない | Consumer access以外のentitlementが加算されている | 直接付与とグループ継承の両方 |
9月14日以降を見据えた運用ルール
移行後の運用手順には、ユーザー追加時に選択するentitlementを明記します。
たとえば申請フォームに「Azure Databricksを利用する」という1項目だけを用意するのではなく、次の選択肢へ分けます。
- 共有コンテンツの閲覧のみ
- SQLクエリ・ダッシュボードの作成
- ノートブック・ジョブ・パイプラインの作成
- 自動化用サービスプリンシパル
- ワークスペース管理
承認後は個人へ直接entitlementを付与するのではなく、原則としてペルソナ別のアカウントグループへ追加します。これにより、SCIMによる入退社対応とTerraformによるワークスペース権限管理を分離できます。
また、2026年9月14日以降の復旧手順は「usersグループへentitlementを戻す」ではありません。標準のアカウントグループまたは対象プリンシパルへ、必要なentitlementを明示的に付与することが復旧方法になります。
まとめ：移行成功の判定は新規ユーザーで行う
Azure Databricks workspace entitlementsの変更では、既存ユーザーの権限がクローングループによって維持されます。そのため、既存ユーザーが利用できるだけでは、SCIMやTerraformの移行が完了したとは判断できません。
2026年9月14日までに、次の状態を完成させてください。
usersとadminsをentitlement管理対象から外す- ワークスペース割り当てとentitlement付与を別処理にする
- consumer-onlyとauthoring利用者を別グループにする
- SCIMの削除処理から移行用クローングループを保護する
- サービスプリンシパルにも必要なentitlementを明示する
- 検証環境で新しい動作へ事前移行する
- 移行後に追加した新規ユーザーで一連の処理を試験する
- entitlementだけでなく、SQLウェアハウス、ジョブ、Unity Catalogの権限まで確認する
最優先で確認すべきなのは、Terraform内のpermissions = ["USER"]と、usersシステムグループを対象にしたdatabricks_entitlementsです。これらを標準のアカウントグループと明示的entitlementへ置き換えることで、2026年9月14日の強制適用後もSCIM・IaCによるユーザー追加を継続できます。
コメント