※本画像は生成AIにより作成したイメージです
前提条件・対象読者
- 本記事は Databricks および Microsoft Entra ID を利用したデータ基盤を前提としています
- 対象読者：データガバナンス設計に関わるエンジニア・アーキテクト
はじめに
はじめまして、株式会社NTTデータ九州 ビジネス共創部 デジタルビジネス推進室 パブリッククラウド担当の小薗です。
本記事では、「データの民主化（誰もがデータにアクセスできる状態）」と「ガバナンスの維持（誰がどのデータを見られるか）」のトレードオフを出発点にしています。SCIM（System for Cross-domain Identity Management）とJIT（Just-In-Time Provisioning）の違いを入口としながら、Databricks Apps時代におけるSCIMの価値を考察します。
現在私は、Azure、**Amazon Web Services（AWS）**をベースに Databricks を活用したデータプラットフォームの設計・構築、技術検証に関する支援に携わっています。実務を通じて得たデータガバナンスにおける気づきをまとめてみましたので、最後までご一読いただけますと幸いです。
皆さんはユーザー管理における SCIM についてご存じでしょうか。
SCIMについて調べると、多くの記事で「SCIMとJITの違い」等が解説されています。
一般的には、
- SCIMはシステム間のユーザーやグループを事前に同期する仕組み
- JITは初回ログイン時にユーザーを自動生成する仕組み
という説明がされています。
私がDatabricksを学び始めた当初は、「SCIMとは単にEntra IDとDatabricksのユーザー・グループを同期する機能」程度にしか認識していませんでした。
（シングルサインオン（SSO）でログインできればそれで十分だと思っていた）
しかし、 Databricks Appsに関する理解を深める中でその認識は大きく変わりました。SCIMは単なるユーザー同期機能ではなく、Databricks Apps時代においては、データガバナンスをスケールさせるための重要なアーキテクチャ要素であると考えるようになりました。
Databricks Apps は、Databricks上のデータやAI機能を活用したアプリケーションをサーバレスで開発・公開できる仕組み
SCIMとJITの比較だけでは語れない本質
ユーザー管理について学ぶと、SCIMとJITが比較されていることが多くあります。
それぞれの特徴を簡単に整理すると以下のようになります。
| 項目 | SCIM | JIT |
|---|---|---|
| ユーザー作成タイミング | 事前同期 | 初回ログイン時 |
| グループ同期 | 可能 | 不可 |
| ユーザーライフサイクル管理 | 可能 | 限定的 #1 |
| 大規模運用 | 向いている | 向いていない |
#1：ここでの「限定的」とは「初回作成後の更新・削除をIdPの変更に対して自動追随できない」ことを指す
※本画像は生成AIにより作成したイメージです
一般ユーザー向けのアプリケーションにおいては、管理の手間を減らすためにJITが推奨されるケースは多くあります。
しかし重要なのはどちらが優れているかという機能比較ではなく、データプラットフォームが求めるガバナンス要件から逆算したとき何が必要かです。企業のデータ活用で重要なのは、「ユーザーをいつ作るか」ではなく、「利用者が増えてもデータガバナンスを維持できるか」だと考えるからです。
JITはあくまで「初回ログイン時にユーザーを作るだけ」の仕組みです。一方、データガバナンスに必要なのは、ユーザーの作成・削除だけでなく、組織変更に伴うグループ所属の変更までを含めた ユーザーライフサイクルの完全な管理 です。人事異動で部門が変わった時、あるいは退職した時に、即座にデータアクセス権限を剥奪・変更できなければ、データプラットフォームのガバナンスを保証できなくなります。
「単なるユーザー自動作成（JIT）」と「組織構造の同期（SCIM）」は、ガバナンスの観点において全く別物であり、PoC環境や小規模利用であればJITでも十分なケースはありますが、本番・大規模運用においてガバナンスを維持する場合にはSCIMが必須という判断になると考えます。
そして、SCIM自体は以前から重要な仕組みだったもののDatabricks Appsの登場によってその価値がより明確になったと考えています。
実務を通じて注意した運用ポイント
SCIMによりEntra IDとDatabricksのユーザー同期を運用する際の注意として、Databricks側を起点にユーザー・グループ設定の管理はしないこと。同期はEntra IDのユーザー・グループ情報を正とし、他方のシステムに同期します。
Databricks Appsが変えたSCIMの見方
これまでのDatabricksは、主にデータ専門職が利用するプラットフォームでした。
例えば、
- データエンジニア
- データサイエンティスト
- データアナリスト
などです。
利用イメージは非常にシンプルです。
データ専門職
↓
Notebook / Dashboard
↓
データ
Databricks利用者とデータ利用者はほぼ同義であり、利用者数も数十人から数百人程度かと思います。しかし、Databricks Appsの登場でこの構図が完全に変わったと考えます。
Databricks上で、
- 営業向け分析アプリ
- 人事向けダッシュボード
- 経営分析ポータル
- 社内向け生成AIチャットボット
- 業務支援アプリ
など、アプリケーションを直接開発したり公開できるようになりました。
すると利用者は、データ専門職だけでなく、
- 営業担当者
- 人事担当者
- 経理担当者
- 経営層
- パートナー企業
- 顧客企業
へと一気に広がります。
※本画像は生成AIにより作成したイメージです
従来もBIツール経由でデータ利用者は存在していましたが、Databricks Appsの登場により、Databricks自身が業務利用者向けアプリケーションの実行基盤となれるようになりました。
ここでSCIMとの接続が重要になります。利用者が数千人・数万人に膨らんだとき、JITベースの管理では退職者のアクセスが残存したり、部門異動後も旧部門のデータが参照可能なまま放置されたりするリスクが生まれます。逆にSCIMでEntra ID上のグループをDatabricksへ継続的に同期しておけば、Entra ID側の変更がそのままDatabricksの権限に反映されます。利用者規模の拡大は、SCIMが担うライフサイクル管理の重要性を一気に高めます。
重要なのは「認証」よりも「認可」
私がDatabricks Appsの登場で重要と感じたことは、「誰がログインできるか（認証）」ではなく、「誰がどのデータを参照できるか（認可）」です。
例えば営業向けアプリについて、
- 営業部門Aは自部門の売上のみ参照したい
- 営業部門Bには他部門の情報を見せたくない
- 経営層は全社データを参照したい
- 外部パートナーには限定されたデータのみ公開したい
などの要望があるとします。
このような要件はアプリケーション側で制御することも可能ですが、アプリごとに権限制御を実装すると、
- 実装コストが高い
- アプリごとに権限ロジックが分散する
- ガバナンスが統一できない
- 監査が困難になる
などの問題が発生します。
ここで重要になるのがUnity Catalogです。そしてUnity Catalogがこのような権限管理をスケールさせるためには、SCIMによってグループ情報が正確に同期されていることが大前提です。
Unity Catalogが目指している世界
Unity Catalog は単なるデータカタログ機能ではありません。
データアクセスを統一的に管理・制御する主体としても機能します。
従来の権限管理では、アプリケーションごとに「ユーザー ⇄ 権限」のセットを作る必要がありましたが、Unity Catalogではデータに対してアクセス権限を持たせます。
※本画像は生成AIにより作成したイメージです
データそのものに対してアクセス権限を定義することで、Databricks Appsが増えたとしてもデータガバナンスを一箇所で管理できる設計です。
SCIMの本当の価値
私はここで初めてSCIMの重要性を感じました。
例えばEntra IDで、
- Sales
- Finance
- HR
- Executive
というグループを管理しているとします。
SCIMはこれらのグループ情報をDatabricksへ同期します。
この時Unity Catalogは、
Finance
↓
Finance Catalog
HR
↓
HR Catalog
Sales
↓
Sales Catalog
といった権限モデルを構築します。
つまり、SCIMは単なるユーザー同期機能ではなく、組織構造をDatabricksへ投影し、組織情報をデータガバナンスへ変換する仕組みであると理解しました。
Entra ID上のグループがそのままUnity Catalogの権限モデルの構成要素になることで、「誰がどのデータを見られるか」が組織構造と一致した状態で維持できます。
Databricks SCIMの同期間隔は20～40分です
実際に設計支援や技術検証を進める中でも、Databricks Apps時代において、SCIMは認証基盤（IdP）とデータガバナンス基盤をつなぐ橋渡しとして機能していると再認識しました。
基盤管理者視点で見た革新性
私がDatabricksの設計思想に魅力を感じたのは以下です。
従来のシステムでは、
- BIツール
- Webアプリ
- 分析基盤
それぞれが独自の権限管理を行っているため、人事異動や組織変更のたびに複数システムの権限更新が必要です。
しかしDatabricksでは、
Entra ID（組織・グループ管理）
↓
SCIM（同期）
↓
Unity Catalog（データアクセスの権限管理）
↓
Databricks Apps（すべてのアプリ）
という一元管理の構成をとります。
人事異動が発生した場合でも、基盤管理者のオペレーションは最小限で済みます。
権限変更を各アプリケーションで個別に実施する必要がないため、運用性の向上だけでなく、企業全体のデータガバナンスを一元的に管理できるアーキテクチャと言えます。
Databricks Appsがもたらす未来
Databricks Appsの普及によって、Databricksは誰もが簡単にデータにアクセスできる「業務アプリケーション基盤」へと進化しつつあると考えます。
今後は、
- 社内業務アプリ
- AIエージェント
- 顧客向けサービス
- パートナー向けサービス
などがDatabricks上で動作するケースも増えていくと考えており、「データの民主化」 が本当の意味で実現される未来が近づいています。
しかし、データが身近になればなるほど、セキュリティやガバナンスのハードルは跳ね上がります。
そこで重要となるのが、繰り返しにはなりますが、 「利用者が増えてもガバナンスをいかに維持できるか」 です。
そしてその実現を支えるのが、
- Entra ID
- SCIM
- Unity Catalog
- Databricks Apps
の組み合わせと考えています。
まとめ
私自身、当初は「SCIM = ユーザー同期機能」という理解でした。しかしDatabricks AppsやUnity Catalogの活用を考える中で、SCIMは組織構造をデータアクセス制御へとダイレクトに変換するための重要なアーキテクチャ要素だと感じるようになりました。
「データの民主化」と「ガバナンスの維持」はトレードオフに見えますが、Entra ID × SCIM × Unity Catalog × Databricks Appsという組み合わせは、このトレードオフを解消しうるアーキテクチャだと考えます。
Databricks Appsによって利用者が数十人から数千人、数万人へ拡大していくこれからの時代、SCIMは単なるユーザー管理の便利機能ではなく、データガバナンスをスケールさせるためのコア技術として再評価されるのではないかと私は考えています。
本記事が皆さんの参考になれば、ぜひコメントや質問をいただけたら嬉しいです。
執筆日・免責事項
- 執筆日：2026年6月17日
- 免責事項：本記事は執筆時点の情報に基づいています。内容は将来変更される可能性があります。