同じ営業アシスタントが地域マネージャーと全国責任者に答えても、同じ企業データを見せる必要はない。難しいのは、質問が画面を離れてSQL、モデル呼び出し、エージェントのツール操作になった後も、その区別を保つことである。
Databricksは2026年10月7日、18カ月超の公開プレビューを経てAppsのユーザー認可を一般提供した。ユーザー代理認可（OBO）では、対応リクエストをアプリ自身のサービスプリンシパルだけで処理せず、ログインした本人のIDで実行できる。Unity Catalogの既存統制が本人に伴って適用される。重複したポリシーコードは減るが、委任すればアプリが自動的に安全になるわけではない。
アプリIDを置き換えず、別の経路を追加
Databricks Appsはサーバーレス基盤でデータアプリ、ダッシュボード、業務ツール、カスタムエージェントを動かす。各デプロイには専用のサービスプリンシパルが付き、そのインスタンスに付与された権限を持つ非人間IDとなる。共有設定、テレメトリー、保守、自動処理には今後もこのアプリ認可が有用だ。
ユーザー認可は別経路を加える。認証済みの人が対応操作を始めると、Databricksが実行環境へアクセストークンを渡し、アプリがその人の権限で承認済みAPIを呼ぶ。OAuth 2.0のモデルはユーザー対マシンの委任とマシン間処理を区別する。
統制対象データではUnity Catalogが既存の付与権限、行フィルター、列マスクを評価する。要求クエリを実行できるかはウェアハウス権限も別途決める。同じアプリ経路でも地域マネージャーは一地域、全国責任者はより広い範囲を見られる。後続要求は、アプリが別に持つコピーでなく、更新後のカタログポリシーに基づく。
これはよくある乖離を減らす。共有アプリIDではバックエンドに一つの権限集合が提示され、開発者が役割、対応表、ミドルウェア、別のポリシーサービスで各社員の結果を再構成する。それ自体は機能しても、カタログだけ変更されローカル対応表が残れば、情報露出や正当なアクセスの拒否につながる。
Apps OBOの公開プレビューは2025年3月26日に始まり、Unity Catalogテーブルやモデル配信エンドポイントなどを対象とした。一般提供は文書化された制限内での本番準備を意味し、全クラウド、地域、ワークスペース、コンプライアンス構成、下流APIの普遍的対応ではない。原報道はコンプライアンスセキュリティプロファイル付きワークスペースへの2026年9月下旬の展開予定にも触れるが、自環境の確認は必要だ。
共有指示の読み出しや指標記録をアプリIDで行い、顧客・営業記録を現在のユーザーIDで照会する使い分けができる。認証は誰がいるか、認可はそのIDが下流で何をできるかを決める。両者を混ぜると今回の本質を見落とす。
ユーザー権限とアプリのスコープの両方が必要
アプリが要求しただけでテーブルやウェアハウスにアクセスできるわけではない。本人が必要なリソース権限を既に持つ必要がある。同時に開発者はAPIスコープを宣言し、本人のために実行できる操作の種類を絞る。
二つは別の境界だ。スコープは新しいデータ権限を作らず、アプリによる既存アクセスの行使を制約する。Databricksは読み取り専用SQL分析向けにsql:restricted-queryを文書化し、広範なウェアハウス管理や無関係な管理操作なしで、本人として制限付きクエリを実行できる。
特権ユーザーほどこの違いが重要となる。幹部や管理者は多くの機密データに正当にアクセスできても、狭いスコープのアプリが本人の全機能を受け継ぐべきではない。本人の権限が広くても、アプリが実行可能な操作は絞られる。
ワークスペース管理者は、開発者が追加できるスコープの上限も設定する。許可リストは全対応API、特定スコープ、ユーザー認可なしを選べる。発表では既定値が全対応APIを含みうるため、これは統制上の選択であって厳しい初期基準の証拠ではない。
ただし上限には重要な例外がある。アカウント管理者はワークスペースの許可リストで除外されたスコープも追加できる。また許可済みスコープを取り消しても、既存アプリは直ちに停止せず動き続けられる。対象アプリは不許可スコープを外すまで、その後の起動、デプロイ、更新ができない。
したがって許可リスト変更は、すべての実行中利用の即時失効と同義ではない。管理者はデプロイ済みアプリ、スコープ責任者、業務依存を把握し、移行期間と次回デプロイの予期せぬ停止を管理する必要がある。制約した基準と記録された例外経路が、設定だけで十分という思い込みより役立つ。
トークンはエージェント全体でなく一回の要求に属する
アプリはユーザー用とアプリ用クライアントを分離すべきだ。統制対象の対話クエリはユーザー経路へ、共有設定やセッションなしで続ける仕事は適切に絞ったアプリ経路へ置く。主体を隠す汎用クライアントより、依存関係とハンドラーを分ける方が資格情報の誤用を発見しやすい。
ユーザー認可が必要な経路で転送トークンがなければ、要求を拒否すべきである。サービスプリンシパルへの暗黙の切り替えは、想定より広い、または狭い、別の権限で技術的に正しい答えを返してしまう。ユーザーにはID変更が見えないこともある。
転送トークンを出力、ログ記録、永続保存してはならない。Appsで動かすカスタムエージェントでは、Databricksは実行中のinvokeまたはstreamハンドラー内でユーザー用ワークスペースクライアントを初期化するよう説明する。トークンが存在するのは要求実行中だけで、グローバルなアプリ起動時ではない。
一つのエージェントプロセスは多人数を扱う。ユーザーIDをグローバル状態にするとコンテキストを失ったり混ぜたりする。共有指示はアプリ、統制対象財務データは本人、一般テレメトリーは再びアプリという多段処理でも、本人の資格情報は保持しない。各移行で主体とスコープを明確にする必要がある。
長時間・遅延処理には別の境界もある。本人が始めた処理が要求より長く続いても、転送トークンを保存してよい理由にはならない。アプリの仕事なら権限を絞ったサービスプリンシパルを使い、ユーザー文脈が必要なら文書化された別の委任方式を使う。
OBOは全外部連携に自動継承されない。下流が対応している必要があり、別資格情報、同意、スコープ、監査が求められる場合もある。トークンの対象と目的は固有で、MicrosoftのOBO指針も中間層トークンの不適切な転送を警告する。これはツールチェーン全体の無制限な代理ではなく、境界付き委任である。
アプリを開けてもデータを読めるとは限らない
Databricks Appsは匿名公開アプリの仕組みではない。利用者は認証し、外部協力者は対応するIDフェデレーションで参加する。管理された社員・パートナーのIDが自然な対象で、無制限の匿名訪問ではない。
CAN USEとCAN MANAGEはアプリの実行・管理を決め、背後のテーブル、行、ウェアハウス権限は与えない。アプリを開けてもデータ要求は拒否・制限されうる。逆にテーブル権限だけでアプリを開けるとも限らない。
従ってUnity Catalogの付与権限とは別に確認する。正しく委任したSQL結果が、誤ってアプリIDで取得したファイル結果と画面で結合される場合もある。プラットフォームだけでは全コード経路への正しいID割り当てを保証できない。
自由な質問を解釈し、ツールを選び、多段でクエリを作るエージェントはリスクを増す。取得文書のプロンプトインジェクションが、漏洩や不適切な行為を促しうる。OBOは現在ユーザーのアクセス範囲を守るが、有効IDや読み取り専用スコープだけでは各クエリが本人の意図に沿うとは証明できない。
同意も管理者レビューの代わりにはならない。本人はサービスや結果の組み合わせを十分理解せず承認するかもしれない。入力処理、ツール制約、出力統制、実行監視が必要であり、異常クエリ、拒否の反復、想定外のデータ量、動作変化を見る必要がある。
管理者だけの試験は拒否が少なく欠陥を隠す。地域限定、広範アクセス、テーブル権限なしのユーザーで、データと拒否挙動をともに確認する。Databricksは統制変更後の再試験を勧める。ログはアプリ操作と本人のための操作を区別しつつ、ベアラートークンや機密応答を残さない。
ポリシーの重複は減るがプラットフォーム依存は増す
委任は過剰な元権限を修正しない。グループ、カタログ権限、ウェアハウスアクセス、行フィルター、マスクの保守は必要だ。検索可能な技術知識ベースで脅威モデル、認可判断、レビュー証跡を実装文書と保存できるが、文書は強制機構ではない。
Databricksの特徴は委任の発明ではなく、自社の統制データ、SQL、実行環境との統合だ。MicrosoftはAPI向けOBOを既に文書化する。GoogleのID認識アクセスはホストアプリと文脈ポリシー、AWSは独自システム向け認可部品に重点を置く。プラットフォームと開発者の統合作業の分担は異なる。
既にUnity Catalogで統制するデータなら、Databricksは安全チームとアプリフレームワーク間の翻訳作業を減らせる。その代わり固有のスコープとID動作への依存が強まり、マルチクラウド資源には別認可層が必要な場合がある。
開発時間短縮や権限欠陥回避率を示す独立ベンチマークはない。異なる権限の利用者を実際に支える本番パターン、監査可能な混合サービス、細かなスコープ、明確な同意が一般提供という言葉より強い証拠になる。トークン事故、スコープ肥大、ID切り替えバグは逆の証拠だ。
今回の公開は本番採用の壁を一つ下げるが、どの操作をアプリ、どれを本人のものとするかは残る。SQL、エージェント、ファイル、外部サービスが一つの製品になっても区別を守れることに価値があり、ログインした人を無制限の資格情報として扱うことではない。
出典と関連資料
Databricks一般提供発表；Apps認可モデル；2025年3月プレビュー；Microsoft OBO指針；検索可能な技術知識ベースの関連解説；Apps権限レベル；Google ID認識アクセス。