AIエージェントが企業システムの中核になりつつある現在、データ基盤にも大きな転換が求められている。Databricks(データブリックス)は6月に開催した年次カンファレンス「Data + AI Summit 2026」で、新しいデータアーキテクチャ「LTAP(Lake Transactional/Analytical Processing)」をはじめ、実行エンジン「Reyden」や「Agentic SoR」構想を打ち出した。

その根底にあるのは、分断されたデータやシステムを1つの基盤へ統合する「Unification」という考え方だ。共同創業者兼Chief ArchitectのReynold Xin(レイノルド・シン)氏に、その狙いと将来像を聞いた。

  • Databricks 共同創業者兼Chief ArchitectのReynold Xin(レイノルド・シン)氏

    Databricks 共同創業者兼Chief ArchitectのReynold Xin(レイノルド・シン)氏

シン氏は、Databricksの共同創業者兼Chief Architectを務め、ビッグデータや分散システム、クラウドコンピューティングを専門とし、Apache Sparkの主要開発者として知られる。CEOのAli Ghodsi(アリ・ゴディ)氏と同様に、UC BerkeleyのAMPLab在籍時からSpark関連プロジェクトに携わり、GraphX、Project Tungsten、Structured Streaming、DataFramesなどの設計・開発にも関与した。Databricksでは、Sparkの技術発展やデータ/AI基盤のアーキテクチャ設計をリードしている。以下からがインタビューだ。

DatabricksがLTAPを実現できた訳 - Lakebaseアーキテクチャの核心

--まず、新たなデータ基盤アーキテクチャ「LTAP」について伺います。従来はOLTP(オンライントランザクション処理)とOLAP(オンライン分析処理)は性質が異なるため、分離するのが当然と考えられていました。LTAPはその前提を覆すものですが、なぜ実現できたのでしょうか？

シン氏(以下、敬称略)：LTAPはOLTPデータを単一コピーのまま、分析に適した列指向形式でも利用できるようにするアーキテクチャです。データを分析に即座に利用できるようにするものです。今後、数カ月の間にロールアウトを開始する予定です。

これまでの前提を覆すことを可能にしているものが、トランザクショナルデータベース「Lakebase」のアーキテクチャです。もともと単一のモノリシックなPostgresを、ストレージとコンピュートに分離します。

コンピュートはステートレスになる一方、ストレージ側にはストレージファームが存在し、その最終的な保存先はAmazon S3やAzure Blob Storage、Google Cloud Storageなどのオブジェクトストレージになります。この分離型アーキテクチャこそが、LTAPを成立させる前提になっています。

  • Lakebaseはコンピュート層とストレージ層を分離するアーキテクチャを採用。ストレージ側でデータを管理することでLTAPの実現を可能にする

    Lakebaseはコンピュート層とストレージ層を分離するアーキテクチャを採用。ストレージ側でデータを管理することでLTAPの実現を可能にする

ストレージ層にはPageServerがあります。これは高速な読み取りのために利用されます。また、SafeKeeperは高速な書き込みのために利用されます。これらのストレージサービスには、未使用のCPUリソースがあります。もともとストレージ機能が主な役割であり、CPUを大量に消費するわけではないからです。

そこで私たちは余剰分のCPUを利用して、データをオブジェクトストレージに永続化する過程で、行指向形式からカラムナー指向形式に変換しています。つまり、Parquet形式へ変換しているのです。

LTAPでは、OLTPデータを行指向形式のまま保持しながら、ストレージ層でParquetベースのカラムナー形式へ自動変換します。これにより、トランザクション処理はPostgresが担いながら、分析側はParquetデータとして即座に利用できるようになります。

重要なことは、この処理が私たちに追加コストを発生させないことです。すでに、稼働しているストレージサービスの余剰CPUを活用しているだけだからです。

そして、データがParquet形式で保存された瞬間、分析システムはETL(抽出、変換、格納)やCDC(Change Data Capture：変更データキャプチャ)パイプラインを介さず、そのデータを通常のParquetファイルと同じように読み取れます。

私はこれこそが従来のHTAP(Hybrid Transactional and Analytical Processing：トランザクション処理と分析処理の統合)との本質的な違いだと考えています。

しかし、それは非常に難しい取り組みでした。性能面・エコシステム面の双方で制約が生じます。本当に価値があるのは単一のエンジンではありません。単一のデータコピーです。

  • Databricksは「データをコピーしない」ことをLTAPの中核思想として掲げている

    Databricksは「データをコピーしない」ことをLTAPの中核思想として掲げている

単一のエンジンには多くの妥協がありますが、単一のデータコピーには妥協がありません。OLTPにはPostgres、分析にはApache Sparkなどのように、用途に最適なエンジンを利用すれば問題はないと考えています。

それぞれの仕事に最適なエンジンを利用しながら、Single Source of Truth(信頼できる唯一の情報源)を維持できるのです。それを可能にしているのがLakebaseアーキテクチャです。

  • LTAPはトランザクション処理と分析処理を単一のデータコピー上で実現する新アーキテクチャ。OLTPと分析を異なるエンジンで処理しながら、整合性を維持できるという

    LTAPはトランザクション処理と分析処理を単一のデータコピー上で実現する新アーキテクチャ。OLTPと分析を異なるエンジンで処理しながら、整合性を維持できるという

もしモノリシックなデータベースで同様のことを実行しようとすれば、行形式からカラムナー形式への変換で膨大なCPUを消費し、データベースそのものに悪影響を与えてしまいます。

また、ストレージとコンピュートを分離していたとしても、ストレージが独自形式であれば意味がありません。分析エンジンがデータへアクセスできないからです。たとえ、カラムナー形式で保存したとしても、それを活用できなければ意味がありません。

LTAPにおけるデータ整合性・DR・監査はどう管理するのか

--LTAPはデータコピーを不要にし、単一のデータソースを実現するとしていますが、実運用においてデータの整合性、DR(災害復旧)、監査などは、どのように管理するのでしょうか。

シン：そこに魔法はありません。ただし、Lakebaseのアーキテクチャには大きな利点があります。ストレージが常にバージョン管理されていることです。そして、コンピュートは一時的にステートレスです。

たとえば、本来やるべきではない操作を実行してしまったとします。その場合、本番環境のデータベースを停止し、ストレージを特定時点まで巻き戻して、新しい本番インスタンスを起動できます。こうした作業は1秒もかかりません。そして、その状態へワークロードを向け直せばいいのです。私たちは、これが運用を劇的に簡素化すると考えています。

さらに、リスクが高い作業の場合は、まずブランチを作成してその上で実行すべきだと考えています。そこで問題がないことを確認してから本番環境に適用する、あるいは本番環境をそのブランチへファストフォワードすることの方がはるかに安全です。

  • キーノートで講演を行うシン氏

    キーノートで講演を行うシン氏

データベース運用で最も恐ろしいことの1つは、どの操作がシステムを停止させるのか、あるいは性能を大幅に低下させるのか事前には分からないことです。この方式なら、安全に試行し、検証できます。

DRについても同様です。従来のデータベースでは、DRはリージョン間でCDCを転送する仕組みに依存していました。しかし私たちの場合、最終的にはすべてのデータがオブジェクトストレージへ保存されます。

そのため、基盤となるクラウドネイティブなオブジェクトストレージのDR機能を活用できます。私たちが扱う必要があるのは最新の差分データだけです。そのためクロスリージョンレプリケーションも容易になります。

実行エンジン「Reyden」の将来像

--キーノートで発表された新しい実行エンジン「Reyden」はLakehouse//RTで利用されていますが、将来的にはバッチ処理やAI推論を含む汎用エンジンになるのでしょうか。

シン：もちろんです。Reydenはもともと、あらゆるワークロードを処理するために設計されています。

ただし、ソフトウェア開発には「Second System Syndrome(セカンドシステム症候群)」という言葉があります。最初のシステムで成功した後、第二世代のシステムで過度に野心的になり、結果として失敗してしまう現象です。私たちはそれを避けたいのです。

Reydenは最終的にすべてを処理できるよう設計されています。しかし、段階的に展開するとともに価値を提供していきます。そうすることでセカンドシステム症候群に陥ることを避けられます。最終的な目的は、すべてを処理できることです。

Lakehouse//RTはその第一歩に過ぎません。将来的にはReydenが、あらゆる分析処理、そしてAI/機械学習処理を支える基盤になると考えています。

  • ReydenはDatabricksの次世代実行エンジンとして位置付けられている

    ReydenはDatabricksの次世代実行エンジンとして位置付けられている

「Agentic SoR」の実現に向けてDatabricksはどう進化するのか

--キーノートでは「Agentic SoR(Agentic System of Record)」が大きなテーマになっていました。その実現に向けて多くの新機能も発表されました。Databricksは今後どのように進化していくのでしょうか。

シン：私は、この取り組みは複数のレイヤから成り立っていると考えています。最も根本にある考え方は非常にシンプルです。エージェントやLLM(大規模言語モデル)は、すでに非常に高い推論能力を持っています。最先端モデルはもちろん、オープンソースモデルでさえ非常に優秀です。

仮に適切なデータと適切なコンテキストを与えることができれば、驚くようなことを実現できます。しかし、現在の企業システムでは多くの場合、必要なデータが適切な場所にありません。あるいは逆に、データが多すぎて何が適切なコンテキストなのか分からなくなっています。私たちが解決しようとしているのは、まさにこの問題です。

Databricks全体が、その方向へ進化しつつあります。まず最下層には、私たちが「Agentic Data Foundation」と呼んでいる層があります。Lakeflowは、その代表例です。

そして、さまざまな場所に存在するデータをLakehouseへ集約する。あるいは、運用システムで生成されるデータを即座にLakehouseに取り込む。LTAPもその一部です。つまり、「必要なデータを適切な場所へ配置できるか」が最初の課題なのです。

その次に来るのがUnity Catalogです。データを1箇所へ集約したからといって、誰もがすべてのデータへアクセスできて良いわけではありません。ガバナンス、アクセス制御、権限管理は非常に重要です。さらに興味深いのは「すべてのデータがある」こと自体が必ずしも良いことではないという点です。

たとえ、モデルが100万トークンのコンテキストウィンドウを持っていたとしても、本当に100万トークンをそのまま与えれば性能が大きく低下します。そのため、新しいコンテキスト基盤で、社内のデータ、文書、アプリ、チャット、会議情報などを横断的に統合し、企業全体の知識を継続的に学習する「Genie Ontology」が重要になります。

  • Genie Ontologyは、企業データや業務知識を意味情報として整理し、エージェントやLLMへ最適なコンテキストを提供する仕組みだ

    Genie Ontologyは、企業データや業務知識を意味情報として整理し、エージェントやLLMへ最適なコンテキストを提供する仕組みだ

私たちは「ある質問に対して何が重要なのか」を定義できるようにしたいのです。適切なグラフをたどりながら、本当に必要なコンテキストだけを抽出し、LLMに渡せるようにしたいと考えています。

将来的には、私たちは多くの業務アプリケーションも構築していく予定です。業務アプリケーションは、さらに豊富な意味情報(セマンティクス)を提供できるからです。その際も、アプリケーションごとに独立したストレージやデータサイロを作るつもりはありません。最終的には、すべてのデータがDatabricksのアカウントへ集約されるべきだと考えています。そうなれば、エージェントはそれら全体を対象に推論できるようになります。

ある意味では非常にシンプルです。適切な場所にすべてのデータがあり、適切なコンテキストを定義するオントロジーが存在する。その上に推論エンジンを載せれば、驚くようなことが実現できます。

競争優位性は「データ」にあり

--AI市場には数多くのプレイヤーが存在します。それぞれに異なる強みや専門性がありますが、その中でDatabricksの優位性は何でしょうか。

シン：まず大前提として、この領域をDatabricksだけで担うとは考えていません。これは巨大なエコシステムです。私たちは多くの企業と協力しながら、この市場を形成していきたいと思っています。ただ、最も重要な課題はやはりAIへ適切なコンテキストを提供することです。

もちろん私たちは推論サービスも提供しますし、コスト管理機能なども提供しています。しかし最終的にAIの性能を左右する最も重要な要素はデータです。モデル自体は、すでに十分優秀です。

問題はデータです。世界中の企業データはすでにデータレイクへ流れ込み始めています。そして私たちは、その流れをさらに加速させたいと考えています。

だからこそ、オープンなエコシステム、オープンフォーマット、オープンソースのデータベースやエンジンを重視しています。そうすることで、業界全体の標準となる仕組みを構築できると考えています。

オープンソースとオープン標準を重視する理由

--Databricksはオープンソースを基盤に成長してきた企業です。Delta LakeやSparkもそうですし、エコシステムの観点でも、オープンソースはどのような役割を果たすのでしょうか。また、ユーザーのロックイン回避という観点では、Databricksはどのような立場を目指しているのでしょうか。

シン：私たちの哲学は非常にシンプルです。顧客がDatabricksを使い続ける理由は「移行が難しいから」ではなく「価値があるから」であるべきだと考えています。もちろん、どの本番システムであっても、他のプラットフォームへ移行する際には一定のコストや労力が発生します。それは避けられません。

しかし私たちにとって重要なのは、データを常にオープンなストレージとオープンなフォーマットに置くことです。私たちは独自フォーマットによる囲い込みをしたいとは考えていません。

特にデータフォーマットは、最も強力なロックイン要因の1つだからです。だからこそ私たちは、これまで強くオープンフォーマットを推進してきました。また、私たちはAPIも非常に重要だと考えています。

システムが高度化するにつれて、本当のロックイン要因になるのはAPIだからです。複雑なシステムになるほど、そのシステムが依存するAPIを変更することは難しくなります。そのためAPI自体もオープンでなければなりません。Spark APIを使う。Postgresを使う。私たちはその下のエンジンやストレージで非常に難しいエンジニアリングを行います。しかし、ユーザーが利用するインターフェースはオープンであり続けるべきです。

さらに、私たちが重視しているのが、データ交換のためのオープンな標準です。今回発表した「OpenSharing」も、その考え方に基づいています。これは単にデータ共有だけではありません。機械学習モデルの共有もそうですし、LLMスキルの共有も含まれます。

  • DatabricksはOpenSharingでデータ、AI資産、アプリケーション間の相互運用を促進し、オープンなエコシステム形成を目指すだ

    DatabricksはOpenSharingでデータ、AI資産、アプリケーション間の相互運用を促進し、オープンなエコシステム形成を目指す

なぜそれが重要かというと、ネットワーク効果を生み出したいからです。オープンソースは、そのネットワークを作る非常に優れた手段なのです。結局のところ、私たちの考え方は次の言葉に集約されます。

「速く進みたいなら一人で進め。大きく広げたいならコミュニティと共に進め」

これが私たちの哲学です。

Databricksが目指すデータ基盤は「Integration」ではなく「Unification」

--Databricksは以前から統合アーキテクチャを目指してきました。今回の発表を見ると、1つのプラットフォームであらゆるワークロードを処理するというビジョンが現実味を帯びてきたようにも見えます。

シン：私は「Integration(統合)」というより、「Unification（統一）」という言葉を使いたいと思います。Unificationとは究極のシンプルさです。私たちは、データをあちこちへ移動しなくて済む世界を目指しています。データサイロが存在しない世界です。

  • シン氏

    シン氏

そのためには、非常に多様なワークロードを同じ基盤で扱えなければなりません。最重要システムに相当するTier 0レベルのミッションクリティカルなOLTP処理もあれば、数十ミリ秒レベルの超低レイテンシが求められるリアルタイム処理もあります。Databricksにとって長年の弱点は、OLTPと超低レイテンシ処理でした。

しかし、LakebaseとReydenによって、そのギャップは大きく埋まりつつあります。もちろん、まだ十分に対応できないワークロードもあるでしょう。ソフトウェアは終わりのない改善のプロセスです。10年後に再びお会いしたとしても、私たちはまだ改善について議論していると思います。

しかし、大局的に見れば、現在のDatabricksは大半のワークロードを十分処理できる段階に来ていると考えています。「OLTPとOLAPの統合」とだけ思われがちですが、私たちが目指しているのはそれだけではありません。

例えば今回のカンファレンスでは「Databricks AI Search(旧Vector Search)」が10億規模のベクトル検索を実現したことも発表しました。これもUnificationの一例です。過去にはベクトルデータベースという独立したカテゴリがありました。

私たちの考えでは、本来ユーザーは別のベクトルデータベースを用意する必要はありません。たとえ数兆規模のベクトルを扱うとしてもです。

ユーザーは「この検索方式を使うから専用システムを導入する」とか「別の場所へデータをロードしなければならない」と考える必要がないはずです。ベクトル検索は、プラットフォームの標準機能として提供されるべきです。ベクトルインデックスもベクトル検索も、Lakehouseの一部として利用できるべきだと考えています。

以上がシン氏のインタビューだ。LTAP、Lakebase、Reyden、Agentic SoRという一連の構想に共通しているのは、データを移動させ、複製し、個別最適されたシステムへ分断してきた従来のデータ基盤を、よりシンプルな形へ再設計しようとする思想だ。AIエージェントが企業システムの中で役割を広げるほど、必要になるのは高性能なモデルだけではない。

正しいデータに、正しい権限で、正しい文脈からアクセスできる基盤である。Databricksが掲げる「IntegrationではなくUnification」という言葉は、単なる製品戦略ではなく、AI時代のデータアーキテクチャそのものへの問題提起といえるだろう。