【Data + AI Summit 2026 セッションレポート】「Building Better Apps」日本語訳まとめ：Databricks Appsで本番運用に耐える4つの設計原則

投稿日 2026年06月19日
カテゴリー DAIS2026
カテゴリー Databricks
カテゴリー DatabricksApps

● Databricks Apps を実運用で使いたい人

● Lakebase と Databricks SQL（DBSQL） / Lakehouse の使い分けに迷っている人

● AI エージェントをアプリに組み込む設計を考えている人

● セキュリティと性能を両立したい人

【3行でわかるこのセッション】

● Lakebase と Databricks SQL（DBSQL） / Lakehouse は競合ではなく、役割分担が大事。

● ユーザーごとの差があるなら、認可は OBO を基本に考える。

● エージェントは一部に絞り、性能は“測ってから”改善する。

2-2．まず押さえたい4つのポイント

【まずは「接続先の使い分け」を整理する】

このセッションで特にわかりやすかったのが、Lakebase と Databricks SQL（DBSQL） / Lakehouse の関係です。どちらが“上”という話ではなく、OLTP と OLAP の違いとして使い分けるのが基本だと整理されていました。

【4つの原則を、実務目線で見るとこうなる】

1　接続性と状態管理

● 低レイテンシな CRUD や状態管理は Lakebase が向いている。

● 分析・集計・可視化は Databricks SQL（DBSQL） / Lakehouse に任せるのが自然。

● 「慣れているエンジン」ではなく、「何をしたい処理か」で選ぶのがポイント。

2　認可とOBO

● ユーザーごとに見えるデータが違うなら、OBO（On-Behalf-Of）を基本に考える。

● 共有サービスプリンシパルだけで動かすと、可視性制御が難しくなりやすい。

● ユーザーごとに見えるデータが違うなら、OBO（On-Behalf-Of）を基本に考える。

● 共有サービスプリンシパルだけで動かすと、可視性制御が難しくなりやすい。

● Unity Catalog の行レベル制御や列マスキングとも組み合わせやすい。

3　エージェント設計

● エージェントは“アプリ全体”ではなく、“特定機能”として組み込むほうが堅牢。

● UI 制御や通常のアプリロジックまで無理に任せない設計が重要。

● エージェントは“アプリ全体”ではなく、“特定機能”として組み込むほうが堅牢。

● UI 制御や通常のアプリロジックまで無理に任せない設計が重要。

● LLM 呼び出しは待ち時間が出やすいため、async / await などの非同期化を意識する。

4　性能改善

● 最初にやるべきはスケールアップではなく、ボトルネックの測定と切り分け。

● 遅い原因はクエリ、ウェアハウス、ブラウザ描画、接続の張り直しなどさまざま。

● 最初にやるべきはスケールアップではなく、ボトルネックの測定と切り分け。

● 遅い原因はクエリ、ウェアハウス、ブラウザ描画、接続の張り直しなどさまざま。

● キャッシュ、接続プール、並列実行を優先し、増強は最後に検討する。

【実務でそのまま使えるチェックリスト】

設計レビューで確認したい4項目

その処理は OLTP か OLAP かを整理したか。
ユーザー権限を OBO で渡せるか検討したか。
エージェントに任せる範囲を絞れているか。
性能改善の前に、実際のボトルネックを測定できているか。

2-3．要約のまとめ

AI コーディング支援が普及した今でも、アプリの出来を分けるのはアーキテクチャです。Databricks Apps で本番に耐えるアプリを作るなら、「どこにつなぐか」「誰の権限で動くか」「エージェントに何を任せるか」「どこが遅いか」を先に整理することが、最短ルートだと感じるセッションでした。

ひとことで言うと：AIや機能の派手さよりも、接続先・権限・エージェント・性能の基本設計が品質を決める。

3．前年との違いと今年の特徴

ひとことで言うと、2025年は「Databricks 上でアプリを作れるようになった年」、2026年は「そのアプリを本番品質で安全に回すための設計が前面に出てきた年」です。

2025年6月11日には Databricks Apps が GA し、同日に Lakebase が Public Preview として公開されました。さらに翌6月12日には、ビジネスユーザーが Dashboards・Genie・Databricks Apps にアクセスしやすくする Databricks One も発表されています。つまり、2025年は、Databricksを「分析基盤」から「アプリを届ける場」へ広げるための 土台づくりの年だった と整理できます。

それに対して 2026年は、Summit 全体のメッセージ自体が 「BUILD APPS AND AGENTS THAT WORK」 になっています。実際、 Lakebase は 2026年2月3日に GA、AppKit は 2026年2月 に公開、そして 2026年6月16日には App Spaces / Genie App Builder / Serverless Micro Apps / Apps on Databricks Marketplace が発表されました。重心が「作れるかどうか」から、 「速く作れて、ガバナンスを効かせて、低コストに運用できて、必要なら配布までできるか」 へ移っているのが今年の特徴です。

セッション内容を見ると、このセッションは新機能の紹介よりも、 接続先の選び方、認可、エージェントの組み込み方、性能改善の順番 といった「設計判断」にほぼ時間を使っています。これは、Databricks Apps が“試せるサービス”の段階を超えて、 “失敗しやすい実装パターンを避けるべき実運用基盤” として扱われ始めたことを示していると思います。公式のセッション説明でも、テーマは Lakebase と Databricks SQL の使い分け、OBO、エージェント設計、キャッシュと低レイテンシ にはっきり寄っています。

さらに 2026年の流れを補強する材料として、Databricks は 直近6か月で active running apps がほぼ2倍、週間ユーザー数が3倍超に伸びた と述べています。利用者が増えれば、設計ミスのコストも上がります。だから今年のセッションが「まずは動くものを作ろう」ではなく、 「どうすれば壊れにくく、速く、監査しやすいアプリになるか」 に振り切っているのは、かなり自然な流れです。

(なお、2026年春以降は Databricks One のビジネスユーザー向け体験は Genie に統合されています。)

今年の特徴を3つに絞ると

● 機能紹介の年ではなく、設計原則の年になったこと

2025年は Apps の GA や Lakebase の登場が大きなニュースでしたが、2026年は「どう設計するか」が前面に出ています。

● Apps 単体ではなく、周辺基盤込みで語られるようになったこと

Lakebase GA、AppKit、Unity AI Gateway、App Spaces といった周辺機能が揃い、Apps を単なる UI ホスティングではなく、データ + 認可 + エージェント + ガバナンスをまとめる土台として見られるようになりました。

● 内製アプリだけでなく、配布・共有まで視野に入ったこと

Apps on Databricks Marketplace の登場で、2026年は「自社で作る」だけでなく、「サードパーティ製アプリを安全に導入する」方向にも広がっています。

4．今年のセッションで新しく見えた点

このセッションの新しさは、Databricks Apps の機能を並べることではなく、 「どの機能を、どの判断で使い分けるべきか」まで落としていること です。公式情報を見ると、Databricks Apps は serverless 上で動き、Unity Catalog・Databricks SQL・OAuth と統合され、Lakebase は PostgreSQL リソースとして Apps に追加でき、AI エージェントも Apps 上にデプロイできます。今年はそれらをバラバラの機能紹介としてではなく、 1本の設計原則としてつないで理解できる形 にしている点に価値があります。

今年のセッションで新しく見えたポイント

● Lakebase と Databricks SQL（DBSQL） / Lakehouse の違いを、機能差ではなく OLTP / OLAP の役割分担として整理していること。

これはかなり重要で、「どちらを使うか」が好みの問題ではなく、 アプリ状態・point lookup・高速更新なのか、集計・可視化・履歴分析なのか という設計判断になります。セッション概要でも Lakebase と Databricks SQL の使い分けが中心テーマになっています。

● OBO を“高度なセキュリティ設定”ではなく、本番アプリの基本設計として扱っていること。

Databricks Apps の認可モデルは app authorization と user authorization の2本立てですが、今回のセッションは後者、つまり 「ユーザー本人の権限をどうアプリに持ち込むか」 をかなり強く打ち出しています。ユーザーごとに見えるデータが違うアプリでは、ここが“あると便利”ではなく“最初に決めるべきこと”になっています。

● エージェントを“アプリ全体”ではなく“アプリの一部”として捉えていること。

2026年の Databricks は、Unity AI Gateway で モデル・エージェント・MCP サービス・skills までランタイムでガバナンスする方向に広がっており、AppKit や agent template も整ってきました。だからこそ、「全部をエージェントに任せる」のではなく、 UI・権限・状態管理の中にエージェントをどう埋め込むか が大事になる、という整理が効いてきます。

● 性能改善を“まず増強する”ではなく“まず測る”に戻していること。

Databricks のベストプラクティスでも、重い処理は Databricks-native サービスへオフロードし、起動時間や負荷試験を意識するよう案内されています。今回のセッションはその実務版で、 キャッシュ、接続プール、並列化、非同期化 まで含めて、「遅いならまずボトルネックを切り分ける」という順番を強調していました。

要するに、今年は 「Databricks でアプリが作れる」話を、「Databricks をどう使えば壊れにくい本番アプリになるか」という話に進めていること です。2025年の GA / Preview 発表を見ていた人ほど、今回のセッションが 紹介フェーズから設計フェーズへ移った ことを感じやすいはずです。

5．他社との違い

ここでは、比較対象として近い Snowflake と Microsoft Fabric を見ます。

結論から言うと、
Databricks の違いは「アプリ実行環境」「トランザクションDB」「分析基盤」「ユーザー権限」「AIガバナンス」までを、1つのアーキテクチャ課題としてまとめて扱っていること」です。

Snowflake と比べると

Snowflake にも、データの近くでアプリを動かす仕組みはあります。代表的なのは Streamlit in Snowflake で、 warehouse runtime と container runtime を選べますし、Native App Framework に Streamlit を組み込むこともできます。つまり、 「データを外に出さずにアプリを置く」 という発想自体は、Databricks だけのものではありません。

違いが出やすいのは、 権限の持たせ方 です。Snowflake の Streamlit アプリは owner’s rights が基本 で、viewer ではなく owner の権限で動くのがデフォルトです。restricted caller’s rights もありますが、これは container runtime 向け で、 warehouse runtime では非対応 です。Databricks Apps はこれに対して、 app authorization と user authorization を分けて持てる前提で、今回のセッションでも OBO を本番アプリの基本 として推しています。ユーザーごとに見えるデータが違うアプリを考えると、この思想の差はかなり大きいです。

もう1つの違いは、Databricks が Lakebase を OLTP、Databricks SQL（DBSQL） / Lakehouse を OLAP として明示的に使い分ける設計を前面に出していることです。Snowflake の公式ドキュメントで強く出てくるのは、同じ文脈では runtime 選択や権限モデルの話です。Databricks の今回のセッションは、そこに 「状態管理用のDBをどう持つか」 まで含めて話しているのが特徴です。

Microsoft Fabric と比べると

Microsoft Fabric も 2026年には Fabric Apps（preview） を出しており、 TypeScript のデータモデルから GraphQL API と DB スキーマを自動生成 し、認証やホスティングもまとめて扱えます。ただし思想はかなり違っていて、Fabric Apps は TypeScript 前提、SQL Server 前提、そして既存スキーマの DB をそのまま指すことはできません 。Databricks Apps はそれに対して、Python / Node.js の一般的なフレームワークを持ち込める BYO フレームワーク型 です。

認可まわりは、似ている部分もあります。Fabric data agent は Microsoft Entra ID のユーザー権限でデータにアクセスし、Purview ポリシーも尊重します 。これは Databricks の OBO と近い思想です。ですが Databricks はさらに、 Unity AI Gateway でモデル、エージェント、MCP サービス、skills までランタイムでまとめてガバナンスしようとしている点が今の違いです 。Fabric は「Microsoft エコシステムと自然につながる強さ」があり、Databricks は 「データ + アプリ + エージェントの実行時統制を1つに寄せる強さ」 がある、と見るとわかりやすいです。

ひとことで整理すると

● Snowflake は、特に Streamlit / Native App を中心に、Snowflake 上のデータアプリを素早く作りたいときに自然です。

● Microsoft Fabric は、 Power BI / Entra / Purview / Copilot など Microsoft エコシステムとのつながりを重視したいときに自然です。

● Databricks は、 Lakehouse の分析データ、Lakebase のトランザクション状態、OBO によるユーザー権限、AI Gateway による agent ガバナンス までをまとめて設計したいときに強みが出ます。今回のセッションが刺さるのも、まさにこの部分です。

参考文献

• Announcing General Availability of Databricks Apps

• Databricks Data + AI Summit 2026 | Leading AI Conference

• Building Better Apps: Architecture Best Practices and Common Patterns on Databricks Apps | Databricks

• Enabling Governed Vibe Coding for Enterprise Apps on Databricks

• Databricks Lakebase is now Generally Available

• Announcing Apps on Databricks Marketplace

• Databricks Apps | Databricks on AWS

• Configure authorization in a Databricks app | Databricks on AWS

• AI governance at Data + AI Summit 2026: What’s new with Unity AI Gateway | Databricks

• Best practices for Databricks Apps | Databricks on AWS

• About Streamlit in Snowflake