はじめに

2026年6月15日~18日サンフランシスコ・バーチャルにて開催されるDatabricks社主催の年間最大規模のカンファレンスイベント、「Databricks Data＋AI Summit 2026」（DAIS）が開催中です。

本記事はDAIS2026 Speed at Scale on the Lakehouse で発表された、Lakehouse RT による大規模・低レイテンシなクエリ提供と、Real-Time Lakehouse の方向性についてのセッション要約になります。

本記事はDatabricks公式発表を元にした非公式の日本語要約であり、すべての著作権・知的財産権はDatabricksに帰属します。

忙しい方用

Lakehouse RT は、既存の Delta / Iceberg テーブル をそのまま利用しながら、ミリ秒〜サブ秒レベルの低レイテンシなクエリ応答を目指す新しい Warehouse タイプ
データコピー不要、Unity Catalog をそのまま利用可能、高並列アクセスに対応 という点が大きな価値
セッション中で紹介されていた Zero Bus と組み合わせることで、データ取り込みから参照までの end-to-end な低遅延 を目指している
将来的には ingest → transform → serve 全体をリアルタイム化していくビジョンも示された

このセッションの位置づけ

このセッションは単なる新機能紹介というより、顧客向けアプリやダッシュボードにおける「大規模でも待たせない体験」を、Lakehouse 上でどう実現するかという観点で見ると理解しやすい内容でした。

特に、以下のような立場の読者にとって示唆が大きいセッションだと感じました。

顧客向け分析機能や埋め込みダッシュボードを開発している人
リアルタイム分析基盤を検討しているデータ基盤担当者
別の参照基盤を増やさずに構成をシンプルに保ちたいアーキテクト
ガバナンスを維持したまま低レイテンシ化したい Databricks 利用者

このセッションが扱っていた課題

セッション冒頭で語られていたのは、顧客向けアプリケーションやダッシュボードでよくある次のような課題です。

ダッシュボードの表示に 2〜5 秒かかる
少人数では問題なくても、同時アクセスが増えると遅くなる
高速化のために別の参照基盤を作ると、運用やガバナンスが複雑になる
リアルタイム分析をしたいが、データコピーは避けたい

セッションのメッセージを象徴していたのが、次の考え方です。

Going fast is easy, but going fast at scale is hard.
速いこと自体よりも、大規模に速いこと の方が難しい。

特に顧客向けアプリケーションでは、クエリが数秒で返ってきても、それだけで UX は悪化します。

数秒の遅さが問題になる理由

ドリルダウン時に画面が止まって見える
ユーザーが「壊れた？」と感じる
デモや営業で印象が悪くなる
分析機能の価値が伝わりにくくなる

つまり、バッチ分析なら許容される待ち時間でも、インタラクティブな UI ではそのまま体感速度の悪化につながるということです。

従来の 3 つの選択肢

セッションでは、従来よく取られてきた選択肢として 3 つのパターンが整理されていました。

選択肢	メリット	デメリット
既存 Warehouse 上でそのまま分析	すぐ使える、設定や権限を再利用できる	サブ秒応答は難しい、高並列で遅くなりやすい
BI ツール側にデータを抽出	高速、高並列にしやすい	データが古くなる、別パイプラインが必要
専用の参照基盤を別構築	低レイテンシを狙いやすい	データ再取り込み、ガバナンス二重化、運用が複雑

1. 既存 Warehouse 上でそのまま分析する

一番シンプルな方法です。
今ある Warehouse の上にそのままダッシュボードやアプリを載せられるので、導入の手間は最小です。

ただし、次のような課題があります。

体感として遅い
高並列になるとレイテンシが悪化しやすい
顧客向け UI では待ち時間が目立つ

2. BI ツール側にデータを抽出する

必要なデータを BI 側に持たせて高速化する方法です。
この方法は確かに速いのですが、その代わりに次の問題が出ます。

extract pipeline が必要になる
数分〜数時間おきの同期になりがち
最新データではなくなる

リアルタイム性が必要なケースでは、この データ鮮度の低下 が大きな問題になります。

3. 専用の参照基盤を別に作る

低レイテンシ専用のシステムを別に持つ方法です。
性能は出しやすい一方で、構成が分かれることによる負担が大きくなります。

データを別形式で再取り込みする必要がある
権限管理や監査を別で考える必要がある
ガバナンスが二重化しやすい

特に、Lakehouse 側で Unity Catalog による統制ができていても、別システムで同等の管理をどう再現するかが課題になります。

第 4 の選択肢: Lakehouse RT

こうした従来案に対する新しい選択肢として紹介されていたのが Lakehouse RT です。

セッションでは、Lakehouse RT は次のように説明されていました。

既存の Delta / Iceberg テーブルをそのまま利用
データコピー不要
Unity Catalog を継続利用
ミリ秒〜サブ秒レベルの低レイテンシ
高並列アクセスに対応

要するに、速い専用基盤を別に作るのではなく、Lakehouse のまま高速化するというアプローチです。

ここがこのセッションの一番重要なポイントだったと思います。

今年の特徴

このセッションで印象的だったのは、単にクエリ性能を改善する話ではなく、Lakehouse をリアルタイムアプリケーションの実行基盤として広げていく方向性が明確に打ち出されていた点です。

従来は、低レイテンシ分析を実現するために別基盤を組み合わせる前提で語られがちでしたが、今回は Lakehouse RT によって、Lakehouse のまま大規模・低レイテンシを実現する ことが主題になっていました。

また、Zero Bus や将来の real-time mode とあわせて、ingest → transform → serve 全体をリアルタイム化していく流れが示されていたのも、今年の特徴だと感じました。

Lakehouse RT の価値

Lakehouse RT の価値を整理すると、次のようになります。

単一コピーのデータで済む
既存のデータ資産をそのまま活かせる
Unity Catalog による統合ガバナンスを維持しやすい
追加のデータ移動パイプラインが不要
顧客向けアプリの体感速度を改善しやすい

特に印象的だったのは、新しいデータストアを作るのではなく、新しい Warehouse タイプとして使えるという点です。
これなら既存構成を大きく壊さずに試しやすいです。

どうやって低レイテンシを実現しているのか

セッションでは実装の詳細すべてが語られたわけではありませんが、主なポイントとして次の内容が紹介されていました。

ネイティブエンジン

Lakehouse RT では、新しいネイティブエンジンが使われており、JVM オーバーヘッドを避ける方向で設計されているとのことでした。
内部では Raiden という名前も紹介されていました。

Photon との連携

既存の Photon と効率的に連携し、処理パスを最適化していると説明されていました。

クラウドハードウェアの活用

SIMD などのハードウェア最適化
インスタンス間の広い帯域
オブジェクトストレージとの効率的なやり取り

といったクラウド基盤の進化も活用しているようです。

キャッシュの活用

キャッシュ対象は単なるデータだけではなく、

データ
メタデータ
クエリプラン

まで含まれており、これが低レイテンシの実現に効いているとのことでした。

なお、セッションでは 数十ミリ秒レベルの応答性能を目標にしている という説明でした。
あくまで「目指している性能」であり、すべてのケースで一律に保証されるという意味ではありません。

使い方のイメージ

利用方法はかなりシンプルに見えました。

SQL Warehouse を使うように compute を選ぶ
Lakehouse RT を選択する
既存のテーブルに対してクエリする

接続方法としては、以下が挙げられていました。

SQL Execution API
ODBC
JDBC

つまり、データ構造や ETL を大きく変えずに、参照レイヤの性能改善を狙える形です。

読み取り性能だけでは足りない

Lakehouse RT によって読み取りが速くなると、次に問題になるのが データ鮮度 です。

いくらクエリが速くても、見えているデータが古ければリアルタイム分析にはなりません。
そこでセッションでは、Zero Bus と組み合わせた構成が紹介されていました。

Zero Bus と組み合わせる意味

低遅延でデータを取り込む
managed table に素早く反映する
最適化しながら保持する
Lakehouse RT で即座に参照する

これにより、低レイテンシな参照だけでなく、新しいデータへの素早い追従も目指せます。

今後のビジョン: transformation もリアルタイム化

セッションでは、将来的な方向性として ingest → transform → serve 全体を低遅延化する構想も語られていました。

ここで言及されていたのが、Spark Declarative Pipelines の real-time mode です。

目指しているのは、

ingest
transform
serve

を個別に最適化するのではなく、end-to-end で極小の遅延に近づけることだと理解しました。

ただし、この点は すでに全面的に利用できる機能 としてではなく、今後のビジョンとして語られていた点には注意が必要です。

現時点では、セッションの文脈では 取り込みと参照のリアルタイム化が中心 であり、
変換処理まで含めた end-to-end リアルタイム化はこれからの方向性として示されていました。

どんなユースケースに向いているか

セッション内では、かなり実運用寄りのユースケースが紹介されていました。

リアルタイムダッシュボード

ドリルダウンが速い
画面遷移がスムーズ
顧客向け UI に組み込みやすい

オブザーバビリティ / モニタリング

障害や状態変化をすぐに見たい
直近イベントを追いたい
運用の初動を短縮したい

Customer 360 やコールセンター支援

顧客の最新状態を見たい
直近数秒〜数十秒のイベントを追いたい
ライブ troubleshooting を支援したい

セキュリティ分析

threat hunting を高速に回したい
大量ログから必要な情報を素早く探したい
調査の思考を待ち時間で止めたくない

Cisco の事例

セッション中では、Cisco のセキュリティ分析の例も紹介されていました。

従来: 3 秒 の lookup
Lakehouse RT 適用後: 460ms

この差は単に「速くなった」というだけではなく、

検索待ちが短くなる
調査の集中が切れにくい
次の仮説検証にすぐ進める
複数人同時利用でも UX が崩れにくい

という意味で大きいです。

セキュリティのように、考える → 調べる → 次を試すを高速に回したい業務では、数秒の差がそのまま生産性差になります。

従来構成との比較

最後に整理すると、Lakehouse RT は次のような特徴を持っています。

観点	従来 Warehouse	BI 抽出	専用参照基盤	Lakehouse RT
低レイテンシ	△	◎	◎	◎
高並列	△	◎	◎	◎
データ鮮度	◎	△	○	◎
データコピー不要	◎	×	×	◎
ガバナンス統合	◎	△	×	◎
構成のシンプルさ	◎	△	×	◎

Lakehouse RT の価値は、単体の性能だけでなく、
低レイテンシ・高並列・鮮度・ガバナンス・シンプルさを同時に満たそうとしている点にあると感じました。

このセッションから得られる示唆

このセッションから得られる示唆は、リアルタイム分析のために必ずしも別の専用基盤を増やす必要はないという点です。

もし既存の Lakehouse 上で次のような課題を感じているなら、

ダッシュボードの応答が遅い
高並列アクセスに弱い
データコピーを増やしたくない
ガバナンスを分断したくない

Lakehouse RT のようなアプローチは、構成を増やさずに性能と運用性を両立する選択肢として検討価値があると感じました。

まとめ

このセッションの内容をまとめると、次の通りです。

Lakehouse RT は、既存の Delta / Iceberg テーブル をそのまま使って低レイテンシなクエリ応答を実現する
データコピー不要
Unity Catalog による統合ガバナンスを維持できる
高並列アクセスでも使える規模を目指している
Zero Bus と組み合わせることで、データ取り込みから参照までの低遅延化を狙える
将来的には transform を含む end-to-end リアルタイム化 の方向性が示されている

一言でいえば、
リアルタイム分析のために別の参照基盤を増やさなくてもよい世界を目指すセッションでした。

お知らせ

ナレッジコミュニケーションでは、Databricks Data + AI Summit 2026 開催に伴い、日本語でのウェビナーや現地レポートを公開しております！

DAIS2026 Recap イベント
現地参加が難しかった方や、主要トピックスを短時間で振り返りたい方向けに、Recapイベントを開催します。
セッションの要点整理や、日本企業での実装観点も交えてご紹介予定です。

▼ 開催概要・お申し込みはこちら

ナレッジコミュニケーション DAIS2026 特設サイト
DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。
イベント情報の整理・社内共有にもご活用いただけます。

Databricks 導入支援サービスサイト
Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。