Databricks データ＋AI サミット 2026 後の考察：データ層が再び重要になる理由

今年のDatabricks データ＋AI サミットの後、筆者が考えたのは特定の発表ではなく、長い間抱えてきた疑問だった：AIが本当に本番環境に移行したとき、データ層はどうなるのか？ 答えは単純だ：このサイクルにおいて、データ層はAIスタックの中で最も再評価が遅れている部分だが、それが変わり始めている。

データ層は市場がまだ価格を付けていない部分だ。アルゴリズムは公開市場で再評価され、モデルは急速に改善し、計算リソースもNVIDIAやクラウドプロバイダー、資本市場によって再評価されている。しかしデータの動きは遅い。重要ではないからではなく、逆に重要だからこそ、議論するのが難しく修正も困難だからだ。企業データは散らかり、重複し、古くなり、誰も完全に理解していない権限で満ちている。ビジネスセマンティクスはシステム間で整合せず、「リアルタイム」と呼ばれるものは多くの場合、前夜に実行されたスケジュールジョブに過ぎない。この作業は苦痛で華やかさもないが、AIがデモから本番に移行すれば、その痛みは隠せなくなる。OpenAIやAnthropicなどモデル構築者との会話では、モデルは収束し、計算リソースは資金があれば購入可能であり、防御可能な層はますますデータそのもの（品質、新鮮さ、権限、有用なコンテキストへの変換速度）になりつつあるという点に戻ってくる。これはアプリケーション層の問題だけではない。モデル品質は依然としてデータパイプラインに大きく依存しており、トレーニング実行には数日間の準備が必要で、上流のフィールドが汚れていたりバッチのラベルが間違っていたりすると、数日分の計算と待機が無駄になる。

AIエージェントはデータ問題を隠せなくする。エージェントは運用形式で同じ問題を露呈する。本番環境でAIエージェントが失敗する主な原因は、モデルの能力不足ではなく、間違ったコンテキストに基づいて行動することだ。アクセスできないレコード、6時間前に期限切れになったドキュメント、一晩で静かに変化したデータソース、頻繁に使うには高すぎる検索パスなど。筆者は最近、優秀なチームが古いコンテキストパイプラインのためにほぼ1週間を無駄にするのを見た。エージェントは昨日の質問に自信満々で答えていた。モデルは馬鹿ではなかった。コンテキストが間違っており、システムはエラーがいつループに入ったかを証明する方法を持っていなかった。次のインフラボトルネックは単に優れた推論ではなく、モデルやエージェントが決定を下す瞬間に、新鮮で信頼でき、安価で監査可能なコンテキストを提供することだ。

Databricksは正しい問題を狙っている。筆者は「AIデータプラットフォーム」を名乗る多くの製品に懐疑的だが、Databricksは真剣に検討する価値がある。サミットで印象的だったのは二つ。第一にエンジニアリング文化だ。Databricksの規模なら純粋にセールス主導になるのは簡単だが、創業者たちは依然として実行エンジン、トランザクション、リアルタイム分析、製品の基盤となるパイプラインについて語っている。第二に顧客基盤だ。筆者が話したユーザーはAIをデモ層としてではなく、本番システムに押し込もうとしていた。彼らが述べた問題は具体的だった：エージェントはビジネス状態の読み書きを必要とし、リアルタイム分析はデータ移動のコストを払い続けられず、パイプラインはより自律的になる必要があり、エージェントの動作は事後だけでなく実行時にガバナンスされる必要がある。そのため、Lakebase、Lakehouse//RT、データエージェント、AIガバナンスなどの発表は、名前よりも方向性が重要だ。トランザクションをレイクに近づけ、リアルタイム分析を同じデータ基盤に引き寄せ、パイプラインを自動化し、ガバナンスを「誰がこのデータセットを見られるか」から「このエージェントはこの特定のステップで何を許可されるか」に拡張する。データベースは拡大しており、データの保存とクエリだけでなく、事実、状態、セマンティクス、ガバナンス、アクションの基盤になりつつある。

地図は良いが、完成していない。Databricksの方向性は正しいが、アーキテクチャは最終形に達していない。筆者は三つの不完全な領域を挙げている。第一にレイクベース自体。Postgresを起点とするのは賢明な入り口だが、AI時代の運用システムにはトランザクション、メモリ、ベクトル、マルチモーダルデータ、トレース、ブランチ、ロールバック、非常に細かいテナント分離が必要だ。従来のリレーショナルコアは拡張や周辺サービスでこれらの一部を公開できるが、ネイティブではない。従来のPostgresはクラウドネイティブ分散スケールや、短期間のデータベースを作成し状態をフォークしメモリに書き込みトレースを生成して消えるエージェント向けに設計されていない。Postgresをオブジェクトストレージに近づけてもこれらの問題は消えない。オブジェクトストレージは安価で信頼できるが、デフォルトでは低レイテンシではない。高速に感じさせるには、攻撃的で正しいキャッシュ層が必要だが、実際のトランザクション負荷下で安定したキャッシュはデータベースで最も難しいシステム問題の一つだ。第二にマルチモーダルデータ。DatabricksはOLTP、ウェアハウス、リアルタイム分析、データサイエンス、ガバナンスにわたる強力な地図を描いているが、AIアプリケーションはテキスト、画像、音声、ビデオ、埋め込み、行動ログ、エージェントトレースをますます消費する。これらはテーブルの隣にあるオブジェクトではなく、エージェントが検索し、推論し、変換し、書き戻すデータだ。マルチモーダルデータがコアマップの外に残れば、最も重要なAIデータ資産は依然として辺縁に生きることになる。第三にデフォルトユーザーの仮定。製品表面の多くは依然として人間のユーザーを想定している（ダッシュボード、自然言語BI、Excel風ワークフロー、アナリスト向け体験）。しかしエージェントはデータベースを異なる方法で使用する。エージェントはループで動作する：コンテキストを検索し、決定を下し、ツールを呼び出し、状態を書き込み、ポリシーをチェックし、繰り返す。すべてのステップが監査される可能性があり、すべての検索が次のアクションに影響し、すべての書き込みにロールバックが必要になる可能性があり、すべての権限チェックが実行時に行われる必要がある。これは異なるデータベースワークロードだ。

データベースユーザーがエージェントになるとき、質問はより広くなる：エージェントはどのようにして決定の瞬間に最も新鮮で信頼でき、低コストで監査可能なコンテキストを得るのか？ これは単なるクエリ最適化の問題ではなく、ストレージ、インデックス、ガバナンス、リネージ、リプレイ、コスト管理、ランタイムポリシー実行にわたるシステム問題だ。データシステムはもはやインテリジェンスシステム（質問して答えを得る）だけではいられない。AIのオペレーティングシステムに近づく必要がある：エージェントがコンテキストを読み、決定を下し、ツールを呼び出し、状態を書き込み、人間や他のシステムが検査できるトレースを残す場所。監査可能性は後付けできない。エージェントが間違った答えを出したり、間違った行動を取ったり、過剰なコストを使ったりした場合、最初の質問は「その瞬間に何を見ていたのか？」だ。それに答えるには、どのドキュメントが検索され、どのベクトルがマッチし、どのメタデータフィルタが適用され、どのリランカーが順序を変え、どのツールが呼び出され、どのポリシーが施行され、どの状態が書き戻されたかをシステムが知る必要がある。デバッグとガバナンスは同じワークフローになる。このアーキテクチャはまだ誰も完全に解決していないと筆者は考える。

「AIネイティブ」が実際に意味するもの：実際のエージェントワークロードから逆算すると、AIネイティブデータシステムは少なくともいくつかのことをうまく行う必要がある。マルチモーダルデータを第一級市民とすること、弾力性をワークロードから開始すること、マルチテナンシーをエージェントレベルに移行すること、ブランチとロールバックをコアデータベース機能とすること、トレースと決定論的リプレイを必須とすること。これらの特性が次世代データインフラを定義する。