はじめに
Databricks Appsを自然言語で構築できるGenie App Builderがベータとして提供されています。
Databricksのサンプルデータ samples.bakehouse を使って、売上ダッシュボードを作ってデプロイするところまで試しました。プロンプト1本でアプリの形はできましたが、データを表示するまでに権限の設定で一度つまずいています。そのあたりも含めて書いていきます。
今回の検証環境はAzure Databricksです。Free Editionでも試しましたが、プロンプトを送った段階でエラーになり、先に進めませんでした。原因は今回は確認できていません。
Genie App BuilderとApp Spaces
Genie App Builderは、DatabricksのUIの中で自然言語からDatabricks Appsを作る機能です。生成されるアプリはDatabricks AppKitというフレームワークで書かれます。
Genie App Builderで作ったアプリは、App Spaceという入れ物の中に置かれます。App Spaceは、スペース内のアプリがどの認可を使えるかを管理者がまとめて決めておくための仕組みです。関係を整理すると次のとおりです。
| 名前 | 役割 |
|---|---|
| Genie App Builder | 自然言語でアプリを生成し、プレビュー、デプロイする |
| App Space | アプリの置き場所。ユーザー認可に使えるプリンシパルやAPIスコープを制御する |
| Serverless Micro Apps | App Space内のアプリの実行形式。ゼロから1へのスケーリングのみ |
App Spaceとは
App Spaceは、アプリ開発の環境を管理者が統制するための入れ物です。管理者はスペースごとに、次の3つをあらかじめ決めておけます。
- 誰がアプリを作り、誰が使えるか
- アプリが何を実行できるか
- アプリがどのリソースを使えるか
開発者はアプリごとにリソースや権限を定義しなくて済みます。ドキュメントでは、ビジネスユーザーのような技術者でない人が、組織のガバナンスを崩さずにデータアプリを作れるようにすることが目的とされています。Genie App Builderで誰でもアプリを作れるようにするには、アプリが触れられる範囲を先に決めておく必要がある、ということだと思います。
スペースで設定すること
スペースの設定は、アプリの2種類の認可にそれぞれ対応しています。
| 認可 | 誰のIDで動くか | スペースで決めること |
|---|---|---|
| ユーザー認可 | サインインしているユーザー | 承認プリンシパル、APIスコープ |
| アプリ認可 | アプリのASP | なし (ASPは自動で付与される) |
ユーザー認可では、アプリはサインインしたユーザーのIDで動きます。アクセスできるのは、そのユーザーがもともと権限を持っているリソースだけです。スペースでは次の2つを設定します。
- 承認プリンシパル: 「任意のプリンシパル」ならアプリの共有先の全員がユーザー認可を使えます。「指定されたロールのみ」なら、選んだグループのユーザーに限られます。
- APIスコープ: スペース内のアプリがリクエストできるスコープの上限です。アプリ側は必要なスコープを宣言し、スペースで許可された範囲でだけ使えます。
アプリ認可では、アプリは自分のIDで動きます。スペース内の各アプリには、Application Service Principal (ASP) が1つずつ付与されます。ASPはアプリのライフサイクルに結び付いていて、監査ログでアプリを識別するために使われます。ユーザーはASPを作成、編集できず、ASPにアクセス権を付与することもできません。アプリ認可の対象は、Lakebaseデータベース、Model Serving EndpointやAI Gateway、シークレット、ボリュームのような、アプリが所有するリソースです。共有のLakebaseインスタンスや推論用のAI Gatewayのような共有リソースには、アプリ認可で直接アクセスできません。
このほか、スペース内のアプリはサーバーレス使用ポリシーに基づいて実行されます。コストの管理はこのポリシーで行います。
スペースの権限
スペース自体の権限は3段階です。Genie App Builderを使うには、スペースの CAN CREATE APP 以上が必要です。
| 権限 | できること |
|---|---|
| CAN READ | スペースを見る (アプリは作れない) |
| CAN CREATE APP | スペースでアプリを開発する |
| CAN MANAGE | スペースの設定を変更する |
制約
ドキュメントに書かれている主な制約は次のとおりです。
- App Space内のアプリは、Serverless Micro Appsとしてのみ実行される
- 水平スケーリングには対応していない (ゼロから1へのスケーリングのみ)
- App Space内のアプリは、Genie App Builderからのみ構築、デプロイできる
- 一般的なパブリックインターネットへのエグレスはない。外向きの通信はDatabricksワークスペースと、管理されたnpm/PyPIのパッケージプロキシに限られる
- スペースの外でアプリを作ることは防げない
最後の点は、App Spaceが既存のDatabricks Appsを置き換えるのではなく、ガバナンスを効かせたい場面で選ぶ入れ物だということを示しています。
事前準備
プレビュー機能を有効にする
ワークスペースのプレビュー設定で「Governed agentic app-building」をオンにします。説明文にあるとおり、この1つのスイッチでGenie App Builder、App Spaces、Serverless Micro Appsがまとめて使えるようになります。
有効にすると、Databricks Appsのホームに「Meet Genie App Builder and App Spaces」というバナーが出ます。左側のナビゲーションには、次の3つが並びます。
- ビルド
- アプリ
- Appスペース
App Spaceを作る
最初はスペースが1つもないので、「Appスペース」から「新しいスペース」で作ります。
今回は space-test という名前にしました。作成画面には、名前と説明のほかに「ユーザー認証」の設定があります。
ここで2つ注意があります。
- 名前は作成後に変更できません。
- 承認プリンシパル (「任意のプリンシパル」か「指定されたロールのみ」) も、作成後は変更できません。
APIスコープは作成後に追加できます。この設定が後で効いてきます。画面右側のサマリーには「範囲が追加されていません」と出ていますが、作成時点では気にせず進めました。
プロンプトからアプリを生成する
プロンプトを入力する
「ビルド」を開くと、プロンプトの入力欄が表示されます。入力欄の下で、アプリを置くApp Spaceを選べます。アプリ名は「自動命名」のままにしました。
ドキュメントでは、最初はシンプルなプロンプトから始めてフォローアップで反復すること、ページ、入力、グラフ、アクションを明示することが推奨されています。今回は1ページのダッシュボードに絞りました。
samples.bakehouse.sales_transactions テーブルを使って、ベーカリーの売上ダッシュボードを作ってください。
1ページ構成で、上部に総売上金額・取引件数・平均客単価のKPIカードを3つ並べ、
その下に日別売上金額の折れ線グラフを表示してください。
アプリの環境が用意される
送信すると、初回だけ「アプリ専用のホームを設定しています」という画面になります。アプリの環境とプレビュー用のリンクがが準備されます。
準備ができると、プレビューを見るためにサインインを求められます。
エージェントの作業を見る
画面の左側がチャット、右側がプレビューです。右上の「プレビュー」と「コード」で、生成されたコードに表示を切り替えられます。
エージェントは、テーブルのスキーマとAppKitのドキュメントを確認するところから始めます。途中で「scaffoldには分析プラグインとSQLウェアハウスがまだ接続されていません」と判断し、ワークスペースで使えるSQLウェアハウスを探していました。
コードを書く前に、実際のデータも確認しています。確認結果として、次の値が表示されました。
- 期間: 2024-05-01〜05-17
- 取引件数: 3,333件
- 総売上: $66,471
- 平均客単価: 約$19.94
確認の質問に答える
データの確認が終わると、作業を止めて確認の質問が2つ表示されました。1つ目は、SQLウェアハウス sqlw をこのアプリに接続してよいか、です。質問には「アプリレベルのリソース変更です」と注記がありました。
2つ目は金額の表示通貨です。データに通貨単位が書かれていないため、米ドル、日本円、通貨記号なしから選ぶ形でした。今回は日本円を選んでいます。
回答は「回答を確認」画面でまとめて見直してから送信します。
プロンプトで指定しなかった点は推測で埋められず、選択肢として確認されます。リソースの変更と表示の仕様を実装の前に決められるので、後から作り直す手間が減ります。
生成と型チェック
回答を送ると、「Wire analytics plugin & warehouse binding」というタスクリストが表示され、実装が進みます。クエリの型 (sales_date、daily_revenue、total_revenue、transaction_count、avg_ticket) を生成し、ダッシュボードのUIを書き、型チェックをしてからアプリを起動します。途中で「queryKey を使うとチャートが二重にフェッチする」ことに気づいて、取得済みのデータを渡す形に直していました。
プレビューでデータが表示されない
Query execution failed
アプリの画面はできましたが、プレビューには「データの取得に失敗しました」「Query execution failed」と表示されました。KPIカードは空のまま、グラフには「No data available」と出ています。
エージェントのログを追うと、途中で次の状況になっていました。
- 開発環境に
DATABRICKS_WAREHOUSE_IDがなく、サーバーの起動に失敗した - 原因は、スペースがアプリへのリソース接続を許可していないこと
- 回避策として、
app.yamlにウェアハウスIDを直接書いた
app.yaml への記述でサーバーは起動しました。しかし、クエリはウェアハウスの権限不足 (PERMISSION_DENIED) で失敗しています。
アプリのサービスプリンシパルには権限を付与できない
エージェントから、次の手順が案内されました。
- SQLウェアハウス
sqlwのアクセス許可を開く - アプリのサービスプリンシパル
bakery-sales-dashboardに「Can use」を付ける
ここが最初のハマりどころです。ウェアハウスのアクセス許可画面から、このサービスプリンシパルには権限を付与できませんでした。
App Spacesのドキュメントを読むと理由が分かります。スペース内の各アプリには、アプリ専用のApplication Service Principal (ASP) が付与されます。ただし、ユーザーはASPを直接作成、編集、アクセス権の付与ができず、ASPはアプリだけが使う、と書かれています。
認可の使い分けも、ドキュメントでは次のように整理されています。
| 認可 | 誰の権限で動くか | 対象の例 |
|---|---|---|
| ユーザー認可 | サインインしているユーザー | Unity Catalogのテーブル、Genieスペース |
| アプリ認可 | アプリのASP | Lakebaseデータベース、Model Serving Endpoint、シークレット、ボリューム |
テーブルを読むダッシュボードは、ユーザー認可の側に入ります。ASPに権限を足すのではなく、アプリを見るユーザー本人の権限でクエリを流すのがApp Spaceの想定です。
スペースにsqlスコープを追加する
ユーザー認可でSQLウェアハウスを使うには、App Spaceの設定でAPIスコープを許可します。スペースの「設定」→「ユーザー認証」→「APIスコープ」で「スコープを追加」から sql を追加して保存します。説明には「DatabricksでのSQLの実行とSQL関連リソースの管理をアプリに許可します」とあります。
App Spacesのドキュメントには、アプリが要求できる最大のスコープをスペースで制御すると書かれています。ただし、どのスコープを追加すればよいかまでは書かれていません。sql スコープの意味は、Databricks Appsの認証のページに、SQLウェアハウスでのクエリ用として載っています。2つのページを合わせて読むと、手順がつながります。
スコープを追加したら、エージェントにユーザー認可へ切り替えるよう依頼します。
スペースで sql のユーザー API スコープを許可しました。
サービスプリンシパルではなく、ログインしたユーザー本人の権限 (ユーザー認可) で
SQL ウェアハウス sqlw に照会するように変更してください。
デプロイ前のプレビューはASPで動く
ユーザー認可に切り替えても、プレビューのエラーは消えませんでした。サーバーログには execution.context: "service" と obo_dev_fallback: true が出ていました。この時点のプレビューでは、クエリがユーザー認可ではなくASPとして実行されています。ASPはウェアハウスの権限を持たないため、PERMISSION_DENIED になります。
エージェントからは、確認方法として次の2つが提示されました。
- デプロイして確認する (推奨)
- 開発中だけASPにウェアハウス権限を付けてプレビューで確認する (非推奨)
2つ目はユーザー認可で動かすという方針と逆行するので、デプロイして確認することにしました。デプロイ前のプレビューでデータが出ないのは、この構成ではコードの問題ではありません。ここでコードを直そうとして時間を使わないほうがよいです。
デプロイする
チャットで「デプロイして」と依頼すると、エージェントがデプロイ手順のスキルを読み、デプロイスクリプトを実行します。型生成、lint、型チェック、ビルドの検証がすべて通ると、変更が main に反映され、デプロイが始まります。進捗はデプロイメントパネルで追えます。
デプロイしたアプリを開くと、ユーザー本人の権限でクエリが実行され、KPIカードとグラフにデータが表示されました。値は、エージェントが最初にデータ確認で出していたものと一致しています。
- 総売上金額: ¥66,471
- 取引件数: 3,333件
- 平均客単価: ¥20
日別売上のグラフは、最終日だけ値が下がっています。サンプルデータの最終日の取引が少ないためと思われます。
エージェントの説明によると、デプロイしたアプリでは各リクエストに x-forwarded-access-token (ログインユーザーのトークン) が付きます。SQLクエリはこのトークンを使って、アクセスしたユーザー本人の権限で sqlw に照会されます。
認証後はプレビューでも表示される
デプロイしたアプリを開いて認証を済ませたあと、Genie App Builderのプレビューに戻ると、プレビューにもデータが表示されるようになっていました。グラフにカーソルを合わせると、日ごとの売上金額がツールチップで表示されます。
ユーザー認可で動くアプリなので、ほかの人と共有する場合は、その人自身にウェアハウスの CAN USE とテーブルの SELECT が必要です。今回の samples は誰でも読めるので、実際に必要なのはウェアハウスの権限だけです。
まとめ
Genie App Builderでアプリを作ってデプロイするまでに分かったことをまとめます。
- プレビュー設定の「Governed agentic app-building」を有効にすると、Genie App Builder、App Spaces、Serverless Micro Appsが使えるようになる
- App Spaceの名前と承認プリンシパルは、作成後に変更できない
- エージェントは実装の前にデータを確認し、ウェアハウスの接続や表示通貨のような未指定の点を質問として確認する
- アプリのASPには、ユーザーがウェアハウスの権限を付与できない。テーブルを読むアプリはユーザー認可で動かす
- ユーザー認可でSQLウェアハウスを使うには、App Spaceの設定でAPIスコープ
sqlを追加する - デプロイ前のプレビューではクエリがASPで実行され、データが表示されない。一度デプロイしてアプリで認証すると、プレビューでもデータが表示される
- 検証はAzure Databricksで行った。Free Editionでは、プロンプトを送った段階でエラーになった
一番の収穫は、App Spaceの権限の考え方をつかめたことでした。アプリのサービスプリンシパルに権限を足していく従来のDatabricks Appsの感覚のままだと、ASPに権限を付与できない時点で手が止まります。App Spaceでは、アプリ自体には共有リソースの権限を持たせず、見る人の権限でデータを読みます。そう考えると、スペースで sql スコープを許可する手順は自然に出てきます。プロンプトを書く前に、スペースのAPIスコープを確認しておくのがおすすめです。