はじめに
株式会社 IVRy で新規事業開発をしています@dr_paradi です。好きなトランペッターはエリック・ミヤシロです。
本記事はDatabricks Advent Calendar シリーズ1の23日目の記事です。
本記事は下記の 「FastAPI + htmxが最強説 — Pythonエンジニアがモック作るなら React は不要、Streamlit も捨てよう」 という Zenn 記事に多大な影響を受けています。元々社内アプリに限らず、アプリのモックを Streamlit で作るとメモリ管理やあまりに Streamlit ぽすぎる UI がイマイチなため FastAPI + 何らかのフロントエンドの技術を用いつつも「React書くの大変だし、Vibe Coding で React 書くのもなあ」と思っていたので非常に参考になりました。
背景
わたしが勤めている IVRy という会社には、音楽好きの集まる Slack チャンネルがあります。そこでは
- YouTube や Spotify で好きな曲のリンクを貼るスレ
- 淡々と iTunes を整理しながらのなつかしの楽曲を貼るスレ
- 特定の年代を代表するような曲が何かを議論するスレ
などが日々展開されています。しかし、一晩で 200 リプライを超えるスレが複数誕生するなどせっかくの知見が埋没する状態になっています。そこで、音楽チャンネルに貼られた YouTube を一覧表示・再生できる社内アプリを Databricks Apps で作ってみました。
上図のように times でピラフの話から突然BGMの話をしただけで500を超えるリプライがつきます。
Databricks Apps とは何か(公式ドキュメントより)
Databricks Apps は公式には次のように説明されています。
Databricks Apps を使用すると、開発者は安全なデータアプリケーションや AI アプリケーションを Databricks プラットフォーム上で直接構築してデプロイできるため、個別のインフラストラクチャが不要になります。
「Databricks の上で動く、認証込みの社内 Web アプリ基盤」です。特に重要なのは次の点です。
- Databricks にログインしているユーザーがそのままアプリのユーザー
- ユーザーのアクセストークンが自動でアプリに渡される
- SQL Warehouse の権限がそのまま効く
そのため、簡単な社内アプリを作成する際に大きな障壁となる「認証」 を考えなくていいことが大きなメリットだと考えています。
なぜ Databricks Apps を選んだのか
理由はシンプルに社内アプリで一番つらい(というかめんどくさい)のは認証だからです。
普通に社内 Web アプリを作ると、
- OAuth 実装
- 社内 SSO 連携
- トークン配布・管理
など、「蓄積された音楽を眺めたい」というしょうもない目的を達成するために仰々しい本質と無関係だが重要な作業が大量に発生します。Databricks Apps では、ユーザー認証を Databricks に丸投げ できます。
token = request.headers.get("x-forwarded-access-token")
これだけで、
- 誰がアクセスしているか
- どのデータにアクセスできるか
を Databricks 側に任せられます。また、Databricks Apps は公式には、Streamlit、Dash、Gradio、Flask などを デフォルトでサポートするフレームワーク としていますがDatabricks Apps を作成する画面で 「Create a custom app」を選択することで FastAPI + htmx のアプリも動かすことができます。
なぜ Streamlit ではなく FastAPI + htmx か
Streamlit はわたしのようなデータ系のエンジニアがモックを作るのに非常に便利ですが、
- UI が「とにかくStreamlit っぽい」固定デザインになりがち
- 状態管理・メモリ管理が辛くなりやすい
一方で FastAPI + htmx は、
- HTML をそのまま書ける
- 部分更新(hx-get / hx-target)が簡単
という利点があります。
実際に作ってみた
FastAPI + htmx の基本構成
FastAPI 側の例
from fastapiimport FastAPI, Request
from fastapi.responsesimport HTMLResponse
from fastapi.templatingimport Jinja2Templates
app = FastAPI()
templates = Jinja2Templates(directory="templates")
@app.get("/", response_class=HTMLResponse)
defindex(request: Request):
videos = load_videos()
return templates.TemplateResponse(
"index.html",
{"request": request,"videos": videos},
)
htmx 側の例
<button
hx-get="/page?page={{ next_page }}"
hx-target="#video-list"
hx-indicator="#loading">
次へ
</button>
JavaScript をほぼ書かずに、SPA的なアプリケーションを作成できます。
Databricks Apps でのローカル開発
databricks apps run-local を使うと、Databricks 上に deploy せずとも local で開発することができます。
command:
-.venv/bin/python
--m
-uvicorn
-main:app
---host
-0.0.0.0
---port
-"8000"
FastAPI / uvicorn はそのままで、環境変数で Warehouse の切り替えさえすれば通常の Web アプリと同じように開発することができます。作成したアプリのスクショは添付の通りです。
まとめると、Databricks Apps は
- 認証を作らなくていい
- データがすでに Databricks にある
- 権限管理を Databricks に委譲できる
- UI フレームワークは自由
という長所があります。そのため、軽量なフレームワークである FastAPI + htmx で簡易的な 社内アプリを作るには非常に向いていると感じました。
Lakebase / Agent Bricks への期待
このアプリは、今はDatabricks 上のデータを並べているだけですが、もっと音楽を深掘りしようとすると
- アプリからのいいねなどのリアクション
- 人気ランキング
- 似た曲を推薦する AI Agent
などを機能として追加したくなります。そのためには RDB や AI Agent 管理のシステムが必要になります。まさに最近 シリーズ L の調達をした Databricks は資金を主に
- Lakebase Postgres
- Agent Bricks
- Databricks Apps
に投資を当てるそうですので期待が持てますね。
おわりに
Databricks Apps は、重厚な業務アプリだけでなく
- 社内のSlack などの余白を可視化するアプリ
- モック / プロトタイプ開発
にも向いています。特に FastAPI + htmx での実装は、Streamlit の手軽さと React の重さの間を埋めるのにちょうどいい選択肢になるように感じました。今後も AI と Data がいい感じに連携する社内アプリを作っていきたいと思います。


