何が発表されたか
Databricksは火曜のData + AI Summitで、Lakehouse//RTとLTAP(Lake Transactional/Analytical Processing)の2製品を発表しました。Lakehouse//RTは、Delta/Icebergテーブルに対して直接ミリ秒級の応答を返す新コンピュートエンジン「Reyden」を搭載し、12,000クエリ毎秒で100ms未満、小規模データでは10ms、既存の専用サービング基盤比で最大16倍の性能を打ち出しています。クエリはUnity Catalogのガバナンス下で動き、別途の権限レイヤやデータコピー、取り込みパイプラインを持ちません。
一方のLTAPは、2月にGA化されたサーバレスPostgreSQL「Lakebase」を土台に、Postgresの書き込みをはじめからDelta/Iceberg形式で格納します。Postgresとオブジェクトストレージの間にあるキャッシュ層が、アイドル中のCPUで行→列変換を行いながら書き出す仕組みです。
なぜ重要か
これまでの企業データ基盤は、運用DB→ETL→DWH/Lakehouse→サービング層、という多段構成が前提でした。AIエージェントが業務システムを呼び出して動く時代には、この「コピーと同期」の連鎖そのものが、レイテンシ・コスト・ガバナンスの足かせになります。Databricks側のコメント「エージェントはもっとシンプルなスタックを好む」「HTAPは産業としての失敗だった」という言い回しは、エンジンを統合する従来HTAP(SingleStore、SAP HANA、Oracle MySQL Heatwaveなど、Gartnerが2014年に命名)ではなく、ストレージ層で1コピーに統一する方向を選んだという宣言です。
識者の論点
HyperFRAME ResearchのStephanie Walter氏は「オープンフォーマットに運用側の書き込みまで載せるのは珍しい一手」と評価しつつ、「両エンジンが本当に1コピーを共有しているのか、裏で静かな変換が走っていないか、エンジニアに説明してほしい」と指摘。Moor Insights and StrategyのMike Leone氏は「エンタープライズは何年もHTAPやストリーミング、運用ストアを使ってきた。違うのはエージェンティックAIという文脈だ」と整理し、CIOが求めるレイテンシ・信頼性・運用成熟度をLakebaseが満たせるかが次の論点だとしています。
周辺動向
VB Pulse Q1 2026(従業員100人超の組織を対象とした調査)では、ハイブリッド検索の意向が10.3%から33.3%へ三倍化し、単体ベクトルDBの採用は追跡対象の全ベンダーで低下しました。エージェントが業務データへ直接アクセスする世界では、運用と分析の境目を残したアーキテクチャは選ばれにくくなります。
💼 事業会社視点：これは自社にどう効くか
日本企業はどう読むべきか
EC・SaaS事業者にとっては、商品在庫・注文・ユーザー行動といった運用データを「分析用に複製してからエージェントに渡す」現行構成を見直す好機です。レコメンドや与信、不正検知のエージェントが運用DBを直接叩く設計に踏み込めるか、CTO/VPoEはPoCの題材を選び始めるべきタイミングです。
受託開発・SIerは要注意です。顧客に提案してきた「Aurora/Postgres + Glue/Embulk + Redshift/BigQuery」の多段ETLは、Databricks/Snowflake両陣営が共に「一つのコピーで済ませる」方向に舵を切ったことで、構築・運用案件の単価設計が中期的に崩れます。ETL構築の工数で売っている事業部は、Unity Catalog相当のガバナンス設計・エージェント連携・データ契約(Data Contract)設計に提案軸を移すべきです。
事業会社のCDO/CIOは、Walter氏が指摘した「本当に1コピーか、裏で同期していないか」を必ずベンダーに確認してください。GA前の発表段階であり、SLA・障害時の整合性・Postgres互換性の範囲を契約前に詰めないと、基盤刷新が「もう一段のサイロ」を生む可能性があります。
