Databricks Data + AI Summit 2026からのいくつかのメモ：データレイヤーが再び重要になる理由
今年のDatabricks Data + AI Summitの後、私は特定の発表についてというよりも、しばらく頭から離れないある問いについて考えていました。
AIが本当に本番環境に移行するとき、データレイヤーは何になるのか？
現時点での私の答えはシンプルです。ただし、その含意はシンプルではありません。このサイクルにおいて、データレイヤーはAIスタックの中で最も再評価が遅れていた部分です。それが変わり始めています。
データ：市場がまだ価格に織り込んでいないAIスタックの一部
アルゴリズムは公の場で再評価されてきました。モデルは急速に改善し、業界はほぼ毎週その進歩を目にしています。コンピュートはNVIDIA、クラウドプロバイダー、そして資本市場によって再評価されてきました。GPUが重要であることは誰もが理解しています。
データの変化はよりゆっくりでした。重要性が低いからではありません。むしろその逆です。データの再評価が遅いのは、それについて語るのが難しく、修正するのはさらに難しいからです。企業データは混沌としており、分散し、重複し、古くなり、誰も完全には理解していない権限で満ちています。ビジネス上の意味づけはシステム間できれいには揃いません。人々が「リアルタイム」と呼ぶものは、実際には昨夜のどこかの時点で実行されたスケジュールジョブであることも少なくありません。
その作業は苦痛を伴います。そして、あまり華やかでもありません。しかしAIがデモから本番環境へ移ると、その痛みは隠しようがなくなります。
OpenAIやAnthropicの人々を含め、モデルを構築し訓練している人たちとの会話では、議論はしばしば同じ点に戻ってきます。モデルは収束しつつあります。コンピュートは、少なくとも十分な資金があれば買うことができます。防御可能なレイヤーは、ますますデータになりつつあります。つまり、その品質、新鮮さ、それを取り巻く権限、そしてそれを有用なコンテキストへ変換できる速度です。
これはアプリケーションレイヤーだけの問題ではありません。モデル企業の内部でも、モデル品質は依然としてデータパイプラインに大きく依存しています。本格的な実験が始まる前に、トレーニング実行には数日間の準備が必要になることがあります。上流のフィールドが汚れていたり、バッチに誤ったラベルが付いていたり、フィルタリングルールが間違っていたりすると、損失曲線が逸脱したことに誰かが気づく前に、数日分のコンピュートと待機時間が消えてしまうことがあります。
AIエージェントはデータ問題を隠しきれないものにする
エージェントは同じ問題を、より運用上の形で露呈させます。
AIエージェントが本番環境で失敗するとき、最初の原因は多くの場合、モデルに能力がないことではありません。モデルが誤ったコンテキストに基づいて動いていることです。アクセスできないレコード、6時間前に期限切れになったドキュメント、一晩のうちにひそかに変わったデータソース、あるいは十分な頻度で使うには高価すぎる検索経路。最近、ある優秀なチームが古いコンテキストパイプラインのためにほぼ1週間を失うのを見ました。そのエージェントは、昨日の質問に自信満々に答えていました。モデルが愚かだったわけではありません。コンテキストが間違っていたのです。そしてシステムには、その誤りがループのどこで入ったのかをきれいに証明する方法がありませんでした。
それこそが重要な失敗モードです。次のインフラストラクチャのボトルネックは、単に推論能力を高めることではありません。モデルやエージェントが意思決定を行う瞬間に、新鮮で、信頼でき、安価で、監査可能なコンテキストを提供することです。
だからこそ、私はデータレイヤーがAIスタックの中で次に再評価される部分だと考えています。
Databricksは正しい問題を狙っている
私は「AIデータプラットフォーム」を自称する多くの製品に懐疑的です。あまりにも多くの場合、システムより先にストーリーがやって来ます。
Databricksは、真剣に注目するに値するほどには違います。Summitで私にとって際立っていたことが2つあります。
1つ目は、今なお残るエンジニアリング文化です。 Databricksの規模であれば、同社が純粋に営業主導になるのは容易なはずです。それでも創業者たちは今なおステージ上で、実行エンジン、トランザクション、リアルタイム分析、そして製品の下にあるパイプについて語っています。私はそこを評価しています。企業の中核にまだプロダクトとエンジニアリングの直感が残っているとき、それは感じ取れます。それは基調講演に現れるずっと前に、小さなアーキテクチャ上の意思決定に現れます。
2つ目は顧客基盤です。 Summitで私が話したユーザーたちは、AIをデモ用のレイヤーとして語っていたわけではありません。彼らはAIを本番システムに押し込もうとしており、彼らが説明した問題ははるかに具体的でした。エージェントはビジネスの状態を読み書きする必要がある。リアルタイム分析はデータ移動のコストを払い続けることはできない。パイプラインはより自律的になる必要がある。エージェントの振る舞いには、事後だけでなく実行時のガバナンスが必要である。
だからこそ、Lakebase、Lakehouse//RT、データエージェント、AIガバナンスといった発表には意味があります。名称そのものよりも重要なのは方向性です。トランザクションをレイクに近づける。リアルタイム分析を同じデータ基盤へ引き戻す。パイプラインのより多くを自動化する。ガバナンスを「誰がこのデータセットを見られるか」から「この特定のステップで、このエージェントに何を許可するか」へと拡張する。
私はそれを誤った方向転換だとは見ていません。私には、多くの人が同じ未来を異なる角度から見ている証拠に見えます。
データベースは拡張しています。それはもはや、データを保存し クエリ するためだけの場所ではありません。事実、状態、セマンティクス、ガバナンス、そしてアクションの基盤になりつつあります。
地図はよくできている。しかし、まだ完成していない。
Databricksの方向性は正しいです。だからといって、アーキテクチャが最終形に到達したという意味ではありません。
写真：The Known Data Realm · Databricks Data + AI Summit 2026
私には、この地図がまだ不完全な領域が3つあるように見えます。
lakebaseそのもの。
Postgresから始めるのは賢い入口です。開発者はそれを知っています。エコシステムは巨大です。互換性は導入の摩擦を下げます。それは重要です。
しかし、人々を入口まで連れてくるアーキテクチャが、最終的なワークロードで勝つアーキテクチャとは限りません。
AI時代の運用システムには、トランザクション、メモリ、ベクトル、マルチモーダルデータ、トレース、ブランチ、ロールバック、そして非常に細かなテナント分離が必要です。従来のリレーショナルコアは、拡張機能や周辺サービスを通じてこれらの一部を表現できますが、それによってそれらがネイティブになるわけではありません。Classic Postgresは、クラウドネイティブな分散スケールのために設計されたものではなく、短命のデータベースを作成し、状態をフォークし、メモリに書き込み、トレースを生成して消えていくエージェントのために設計されたものでもありません。
Postgresをオブジェクトストレージに近づけても、それらの問いが消えるわけではありません。オブジェクトストレージは安価で信頼性がありますが、デフォルトで低レイテンシではありません。それを高速に感じさせるには、積極的でありながら正確でもあるキャッシュレイヤーが必要です。実際のトランザクション負荷の下で安定し続けるキャッシュは、データベースにおける最も難しいシステム問題の1つです。だからLakebaseについての私の率直な問いは、デモが印象的かどうかではありません。そのシステムが、本番規模で実際のOLTPワークロードを支えられるのか、そしてそのキャッシュが午前3時に人々を起こす存在にならずに済むのか、ということです。
マルチモーダルデータ。
Databricksは、OLTP、ウェアハウジング、リアルタイム分析、データサイエンス、ガバナンスにまたがる強力な地図を描いています。しかしAIアプリケーションはますます、テキスト、画像、音声、動画、埋め込み、行動ログ、エージェントのトレースを消費しています。それらは単にテーブルの隣に置かれたオブジェクトではありません。エージェントが取得し、推論し、変換し、書き戻すデータなのです。
マルチモーダルデータがコアの地図の外側に残るなら、最も重要なAIデータ資産は依然として周縁に存在することになります。
デフォルトのユーザー。
製品画面の多くは、依然として人間のユーザーを前提としています。ダッシュボード、自然言語BI、Excel風のワークフロー、そしてアナリスト向けの体験です。それらには価値があります。しかしエージェントはデータベースを異なる方法で使います。
エージェントは1日に1回ダッシュボードを開くわけではありません。ループの中で動作します。コンテキストを取得し、意思決定を行い、ツールを呼び出し、状態を書き込み、ポリシーを確認し、繰り返します。すべてのステップで監査が必要になるかもしれません。すべての取得が次のアクションに影響するかもしれません。すべての書き込みにロールバックが必要になるかもしれません。すべての権限チェックが実行時に発生する必要があるかもしれません。
それは異なるデータベースワークロードです。
写真: Unity AI Gateway · ガバナンス —— Databricks Data + AI Summit 2026
データベースユーザーがエージェントであるとき
何十年もの間、データベースはほとんどの場合、1つの問いに集中できた。この クエリ を正しく、速く実行するにはどうすればよいか。
エージェントの時代には、その問いはより広がる。
エージェントは意思決定を行う瞬間に、最も新鮮で、最も信頼でき、最も低コストで、最も監査可能なコンテキストをどのように取得するのか？
これは単なるクエリ最適化の問題ではない。ストレージ、インデックス作成、ガバナンス、リネージ、リプレイ、コスト管理、ランタイムポリシー適用にまたがるシステムの問題である。
ここでカテゴリーが変わり始める。データシステムは、もはや単なるインテリジェンスシステムではいられない。つまり、質問を投げれば答えを返す、というだけでは不十分だ。AIのためのオペレーティングシステムに近いものになる必要がある。エージェントがコンテキストを読み、意思決定し、ツールを呼び出し、状態を書き込み、人間や他のシステムが検査できる痕跡を残す場所である。
監査可能性は、後から付け足すことはできない。エージェントが間違った答えを出したり、間違った行動を取ったり、過剰に費用を使ったりした場合、最初の問いはこうなるだろう。その瞬間に、それはいったい何を見ていたのか？
それに答えるためには、システムは、どのドキュメントが取得され、どのベクトルがマッチし、どのメタデータフィルターが適用され、どのリランカーが順序を変え、どのツールが呼び出され、どのポリシーが適用され、どの状態が書き戻されたのかを把握している必要がある。デバッグとガバナンスは同じワークフローになる。
これこそが、まだ誰も完全には解決していないと私が考えるアーキテクチャである。
「AI-native」が実際に意味すべきこと
「AI-native」は、ほとんど何でも意味し得るフレーズの1つになりつつある。まだ明確な定義はないと思う。しかし実際のエージェントワークロードから逆算すると、AI-nativeなデータシステムは、少なくともいくつかのことをうまく行う必要がある。
マルチモーダルデータは第一級でなければならない
テキスト、画像、音声、動画、埋め込み、ログ、トレースは、リレーショナルテーブル、ベクトル列、オブジェクトバケット、そして複数のサイドインデックスに散らばっているべきではない。それらは、検索、フィルタリング、ランキング、ガバナンスを一緒に行える1つの論理システム内に存在する必要がある。
難しいのは、これらの資産を保存することではない。難しいのは、アーキテクチャをまた別のパイプライン問題に変えることなく、それらをまとめてクエリ可能にすることである。
エラスティシティはワークロードから始まらなければならない
エージェントのトラフィックはバースト的である。システムは1時間静かだったかと思うと、検索、メモリ、ツール利用のリクエストが一気に押し寄せるかもしれない。データレイクやオブジェクトストアは、安価で信頼性が高く、コンピュートから分離された、永続的な基盤になるべきである。
しかし、コーパスが存在するというだけで、コンピュートが高コストのままであってはならない。誰も検索していないなら、システムの支出はごくわずかであるべきだ。ワークロードが起動したなら、コンピュートは素早く立ち上がるべきである。その世界では、自然な課金単位は常に恒久的なクラスターとは限らない。クエリ、セッション、あるいはアクティブなコンピュートの分数かもしれない。
マルチテナンシーはエージェントレベルへ移行しなければならない
従来のマルチテナントシステムは、管理可能な数の大規模テナントを前提としていることが多い。エージェント型システムは、何百万、何十億もの小さく、短命で、分離された状態を作成する可能性がある。各エージェントは、それぞれ独自のメモリ、権限、トレース、一時ブランチ、書き込みパスを持つかもしれない。
数千の大規模テナント向けに構築された設計は、テナントがエージェント実行そのものになったときに苦戦するだろう。
ブランチングとロールバックは中核的なデータベース機能になる
エージェントは間違ったものを書き込む。それは例外的なケースではない。ワークロードの一部である。
有用なAIデータレイヤーには、データ状態のためのGitのようなブランチングと高速なロールバックが必要である。エージェント実行は、作業ブランチをフォークし、アクションをテストし、一時的な状態を書き込み、それを破棄または昇格できるべきだ。悪い更新が入った場合、システムは既知の良好な時点へ迅速に戻れるべきである。
バージョニングは、もはや分析上の利便性だけではない。運用上の安全機構になる。
トレースと決定論的リプレイは必須である
エージェントが失敗したとき、問うべきなのは単に「最終的な答えは何だったのか？」ではありません。「エージェントは何を見て、取得し、ランク付けし、判断し、呼び出し、書いたのか？」です。
そのためには、意味のあるすべてのステップのトレースが必要です。さらに重要なのは、再生が必要だということです。システムは、文書が変更された後やインデックスが再構築された後の状態ではなく、その時点で存在していた意思決定コンテキストを再構築できるべきです。
エージェントにとって、監査可能性とデバッグ可能性は同じ要件に収れんします。
権限は行だけでなく、アクションを統制しなければならない
従来の認可は、誰がテーブル、列、または行を読めるかを問います。エージェント型システムには、より動的な問いが必要です。この特定のステップにおいて、このエージェントは何を取得し、呼び出し、変更し、開示し、消費することを許可されているのか？
難しい部分は、読み取り経路からアクション経路へ移ります。ポリシーの適用は、人間がダッシュボードを開くときだけでなく、エージェントが実行されている間に行われなければなりません。
運用は自律化しなければならない
エージェントレベルのスケールは、人間が運用するインフラを破綻させます。小さく高速に変化する何百万ものワークロードにわたって、インデックス、コンパクション、キャッシュのウォーミング、テナント配置、リカバリ、リソーススケジューリングを手作業で管理できるチームはありません。
システムは自らを運用しなければなりません。そうでなければ、そのアーキテクチャは図の中では機能しても、唯一重要な場所、つまり本番環境では失敗するかもしれません。
SQL は最終インターフェースとしては十分ではない
もう一つ、私がますます考えるようになっている問題があります。それはインターフェースそのものです。
SQL はアナリスト時代にふさわしいインターフェースでした。今でも不可欠です。しかし、データベースと分析を中心に築かれた企業にとって、SQL は経路依存の一形態にもなり得ます。製品の表面、ユーザーモデル、さらには組織でさえ、主要なユーザーはクエリを書ける人であると想定していることがよくあります。
AI 時代のデータにおける最終インターフェースは、少し良くなった SQL エディタではありません。また、データベースの前に貼り付けられたチャットボットでもありません。
より興味深い到達点は、ヘッドレスで自然言語ネイティブなデータシステムです。人やエージェントが意図を直接述べることができ、システムがすべての内部ステップをクエリ作成の作業として露出することなく、答えたり、行動したり、適切な実行計画を準備したりできるものです。
しかしこれは、データベースの前に立つ別のエージェントではなく、データベースにネイティブでなければなりません。
自然言語が単なるアプリケーション層にすぎないなら、システムは取り除こうとしているまさにその継ぎ目を再び持ち込むことになります。もう一つの翻訳ステップ、もう一つの古くなったコンテキストウィンドウ、もう一つのガバナンスの隙間です。データベース自体が、質問、データ、ポリシー、実行経路を理解する必要があります。
それは、親しみやすいインターフェースを作るよりもはるかに難しいことです。つまり、データベースがセマンティクスを所有しなければならないということです。
それでも重要な堀
私には完璧にすっきりした結論はありません。おそらくそれが適切なのでしょう。市場はあまりに速く動いており、あまりに多くの古い前提が予想以上の速さで水抜きされています。
独自のクエリ方言は、かつてのような堀ではありません。エージェントが統合コードを書き換えられるなら、移行コストは弱まります。次のユーザーが人間ではないかもしれないなら、馴染みのある UI の重要性は下がります。データを単に所有しているという静かな優位性でさえ、オープンなテーブル形式、自然言語インターフェース、ツールを使うエージェントが移動を容易にすると弱まります。
それでも私が信じている堀は、より地味なものです。長い時間をかけて、辛抱強く、繰り返し、実際のユーザー価値を生み出す能力です。
だからこそ、私は Summit から戻ってきて Databricks を真剣に受け止めるようになりました。Databricks には、データ領域における次の 1 兆ドル企業になる本当のチャンスがあると思います。すべての製品発表が最終的な答えだからではありません。その一部は変わるでしょう。一部はおそらく間違っているでしょう。それは普通のことです。重要なのは、同社が正しい問題へと歩み戻り続けていることです。
そして正しい問題は、もはや分析、ウェアハウジング、またはトランザクションストレージだけではありません。それは、行動する AI システムのためのデータ基盤です。
Zilliz 側でも、私たちは別の方向から同様の結論にたどり着いています。ベクトルデータベースは消えつつあるわけではありません。非構造化データやマルチモーダルデータのための、より広範なアーキテクチャの内側でサービングエンジンになりつつあります。だからこそ私たちは Vector Lakebase という観点で考えています。これはベクトルデータベースの置き換えではなく、AI ワークロードがより継続的で、弾力的で、エージェント的になるにつれて、それらを中心に構築される次のアーキテクチャです。
地図はまだ完成していません。そこが一番面白いところです。
安いものは高いものに勝つ。信頼できるものは信頼できないものに勝つ。慎重さは不注意に勝つ。忍耐は性急さに勝つ。
AI ネイティブデータベースは、まだ描かれている途中です。この領域で開発しているすべての人にとって、それは非常に良いニュースです。
もうひとつ：Zilliz Vector Lakebase がパブリックプレビューで利用可能になりました
私たちは Zilliz Vector Lakebase のパブリックプレビューを開始しました。これは Zilliz Cloud を純粋なベクトルデータベースから、AI のためのレイクネイティブなデータ基盤へと進化させる大きな一歩であり、低レイテンシのベクトルサービングと、データレイクのオープン性、スケーラビリティ、経済性を組み合わせたものです。
Zilliz Vector Lakebase の主な機能：
- さまざまなリアルタイム性能とコストのトレードオフに最適化された階層型サービング
- 常時稼働のコンピュートなしで、大規模または探索的ワークロードに対応するオンデマンド検索
- 外部データレイク検索 — 既存のレイクデータに対して直接インデックス作成と検索を実行
- ベクトル、テキスト、JSON、地理空間データにまたがるフルスペクトラム検索、ハイブリッド検索とリランキングに対応
- Vortex 上に構築された統合レイクネイティブストレージ。Lance や Parquet よりも高速かつ低コストなランダム読み取りを実現するオープンフォーマット
現在のスタックでサービングとディスカバリーが別々のシステムに分かれているなら、Vector Lakebase は検討する価値があるかもしれません。Zilliz Cloud でお試しください — 新規の仕事用メールでの登録には $100 の無料クレジットが付与されます — または、ユースケースについてお問い合わせください。
読み続けて
Similarity Metrics for Vector Search
Exploring five similarity metrics for vector search: L2 or Euclidean distance, cosine distance, inner product, and hamming distance.
Zilliz Cloud BYOC Upgrades: Bring Enterprise-Grade Security, Networking Isolation, and More
Discover how Zilliz Cloud BYOC brings enterprise-grade security, networking isolation, and infrastructure automation to vector database deployments in AWS
Multimodal Pipelines for AI Applications
Learn how to build scalable multimodal AI pipelines using DataVolo and Milvus. Discover best practices for handling unstructured data and implementing RAG systems.