フロンティアエコシステムはなぜオープンであるべきか — Matei Zaharia、Reynold Xin（Databricks）

Databricksの共同創業者であるMatei ZahariaとReynold Xinが、Latent Spaceのホストswyx（Shawn Wang）を迎え、2026年のData + AI Summitで発表された一連の新製品と、同社の長期的なビジョンについて深く語った。時価総額1,750億ドルにまで成長したDatabricksは、創業時の「ラップトップ上のSparkチュートリアル」から、今や「エンタープライズエージェントのためのオペレーティングシステム」へとその姿を変えつつある。議論の中心は、エージェント間のポータビリティとセキュリティを実現するオープンソースのメタハーネス「Omnigent」、そしてデータベースの長年の夢であるHTAPを「正しく実装した」と主張する新しいストレージアーキテクチャ「LTAP」の2つだ。両氏は、フロンティアモデルの性能がコモディティ化するにつれ、真の差別化要因は企業固有のデータ、ガバナンス、そしてエージェントに生きたコンテキストを提供するシステムにあると論じる。このエピソードは、データ基盤の巨人がAIエージェント時代にどのように適応し、自らを再定義しようとしているのか、その戦略と技術的基盤を詳細に解説している。

Matei ZahariaとReynold Xinは、Databricksが直面する2つの大きな流れがOmnigentの開発につながったと説明する。1つは社内の開発者体験だ。同社のDev Infraチームは、Claude CodeやCodexをラップする「Isaac」と呼ばれる社内ツールを構築していたが、エンジニアたちはさらに高度なワークフローを求めて独自のUIやエージェント連携を構築し始めていた。もう1つは、顧客向けエージェントの開発だ。データサイエンスエージェント「Genie」をはじめ、様々なエージェントを構築する中で、モデルやハーネス（エージェント実行基盤）を数ヶ月ごとに切り替える必要が生じ、さらにセッションの共有や履歴検索といったコラボレーション機能が欠如しているという共通の問題に直面した。Mateiは「コーディングエージェントとカスタムエージェントは、本質的に同じ問題を抱えている」と指摘し、両者を統合する共通APIの必要性を強調した。このAPIは、エージェントセッションに対するメッセージ送信、ファイル転送、ストリーミング応答、ツール呼び出し、キャンセルといった基本操作を抽象化する。これにより、Claude Code、Codex、Cursor、カスタムエージェントなど、異なるハーネスを同一のインターフェースで操作できるようになる。

8:39エージェントクラウド、共通API、そしてオープンソースの戦略

Omnigentは単なるAPI仕様ではなく、サーバーコンポーネントとランナーコンポーネントから構成されるフルスタックの「エージェントクラウド」だ。Reynoldは、自身が運転中にコーディングセッションを継続させるためにラップトップをテザリングし、信号待ちで画面を確認するという「暗黒時代」の体験を語り、クラウド上のサンドボックス環境の必要性を痛感したと述べる。このサンドボックスは、エージェントの実行環境をクラウド上に提供し、ローカルマシンに依存しない永続的なセッションを可能にする。Mateiは、このプロジェクトをオープンソースとして公開した理由を、Sparkの成功体験に基づいて説明する。Sparkがオープンソースだったからこそ、コミュニティによる多数のコネクタやライブラリが生まれ、エコシステムが拡大した。同様に、Omnigentもオープンにすることで、Kubernetes上での実行や様々なクラウドサンドボックスとの統合など、コミュニティからのコントリビューションを期待できる。公開からわずか数日で約400のマージリクエストが寄せられ、その半数近くが社外からのものであるという事実が、この戦略の有効性を裏付けている。一方で、データの永続性や運用の信頼性といった部分は、サービスとして提供する必要があるため、Databricksのコアビジネスとして残る。

16:52Databricksのスケールと内部AIワークフロー

Databricksのインフラストラクチャの規模は、同社の競争力の根幹を成す。Reynoldは、同社が1日に5,000万から6,000万もの仮想マシンを起動し、朝食前にエクサバイト規模のデータを処理していると明かす。この驚異的なスケールは、単なる計算資源の多さを示すだけでなく、長年にわたる運用データの蓄積を意味する。Mateiは、社内ではAIエージェントの使用に関して特に予算制限を設けておらず、エンジニアは自由に利用できると述べる。その代わり、同社は自社製品を使ってエージェントのトレースを分析し、最適化を行っている。この分析からは、例えば「R言語とTypeScriptではどのモデルが優れているか」といった、コードベースに特化した興味深い洞察が得られている。このような大規模な内部利用とデータ分析のフィードバックループが、OmnigentやLTAPといった製品の品質向上に直接貢献している。

18:03エージェントセキュリティ、ガバナンス、そして支出管理

エージェントのセキュリティは、Omnigentの設計において最も重要な要素の一つだ。Mateiは、従来の「許可/禁止」の二値的なポリシーでは不十分だと指摘する。例えば、エージェントが機密文書を読むことと、npmパッケージをインストールすることを個別に許可した場合、プロンプトインジェクションによって機密文書を外部に漏洩させる攻撃が可能になる。これを防ぐには、セッションの状態を追跡する「ステートフル（状態依存）ポリシー」、あるいは「コンテキスチュアルポリシー」が必要だ。これは「もしエージェントがリスクの高い行動（例えば、作成から1日しか経っていないnpmパッケージのインストールや、大量の機密文書の読み取り）を既に行っていた場合、次の危険な行動を禁止する」といった、より高度なルールを記述できる。Mateiは、このポリシーレイヤーを関数として設計し、コミュニティが低レベルのイベントを高レベルな意味にマッピングするライブラリを提供できるようにしたと説明する。また、ステートフルであることの副次的な利点として、セッションごとの支出追跡が可能になった点を挙げる。エージェントがデバッグ中に大量のログを読んで500ドルを消費するようなケースでも、「サブエージェントを起動して5ドルで上限を設定する」といった制御が可能になる。

27:34LTAPとデータベースの夢：HTAPを正しく実装する

Reynoldは、データベースの世界を「OLTP（トランザクション処理）」と「OLAP（分析処理）」の2つに大別し、その間にあるデータ連携の課題を説明する。多くの企業は、PostgreSQLなどのOLTPデータベースで日々のトランザクションを処理し、分析のためにChange Data Capture（CDC）と呼ばれる仕組みでデータをDatabricksなどの分析システムに複製している。しかしCDCは「Continuous Data Corruption（継続的なデータ破壊）」と揶揄されるほど脆く、スキーマ変更などでパイプラインが頻繁に壊れ、データエンジニアを深夜3時に起こす原因となる。これに対する従来の解決策がHTAP（Hybrid Transactional/Analytical Processing）だが、単一のエンジンで両方のワークロードを完璧に処理するのは難しく、結果的にどちらも中途半端になる「第二システム症候群」のリスクがある。Databricksが提案するLTAP（Lakehouse Transactional/Analytical Processing）は、クエリエンジンは統合せず、ストレージ層のみを統一するアプローチだ。具体的には、PostgreSQL互換のOLTPエンジンがデータをParquetのようなカラム指向フォーマットで直接データレイクに書き込む。これにより、分析エンジンはパイプラインを介さずに、ほぼリアルタイムでトランザクションデータにアクセスできるようになる。このアイデアは、あるエンジニアが「ストレージフリートには余剰CPUがあるので、それを使って行指向からカラム指向への変換（トランスコーディング）を行えばよい」と提案し、プロトタイプを短期間で作り上げたことで実現した。Reynoldは、この文化こそがDatabricksの革新の源泉だと強調する。

43:45データベースエンジンの再発明：トレースと機械学習によるアプローチ

LTAPのビジョンを支えるもう一つの重要なプロジェクトが、新しいデータベースエンジンの開発だ。Reynoldは、既存の分析用データベースエンジンはほとんどが10年前の設計であり、その後の機能追加は「ハックの積み重ね」で成り立っていると批判する。Databricksは、10年にわたる運用で蓄積された「クアドリリオン（千兆）単位のデータポイント」からなるトレースデータを活用し、新しいエンジンをゼロから設計している。このプロジェクトの特徴は、機械学習モデルを用いて、任意のクエリに対して最適なアルゴリズムとデータ構造を選択する「データベースエンジンのための工場」を構築した点にある。例えば、文字列の種類が国コードのように256種類しかない場合、ハッシュテーブルではなく単純な配列ルックアップの方が高速だ。このような「数百万の特徴量」をモデルが学習し、実装時および実行時に最適な戦略を動的に選択する。これにより、従来のアカデミックな論文ベースのアプローチでは見落とされがちな、実務上のパフォーマンスに大きな影響を与える「直感に反する」知見を発見できる。この新しいエンジンは、既存のシステムを置き換えるのではなく、低レイテンシのワークロードから段階的に機能を追加していく形でロールアウトされる。

52:32Databricks vs Snowflake、そしてMosaicの戦略

swyxは、Databricksが競合のSnowflakeを上回ることができた理由を問う。Reynoldは、最大の違いは「オープン性」と「AIへの初期からの注力」の2点だと答える。DatabricksはParquetやDelta Lakeといったオープンフォーマットを採用し、顧客のベンダーロックインへの懸念に対応してきた。一方、Snowflakeは独自のプロプライエタリなストレージフォーマットを採用していた。また、DatabricksはChatGPT登場以前から機械学習プラットフォームとしての側面を強く打ち出しており、AIへの移行がスムーズだった。さらに、CEOのAli Ghodsiのリーダーシップも重要な要素として挙げられる。MosaicMLの買収戦略については、Mateiが詳細を説明する。DatabricksはDBRXのような汎用的なフロンティアモデルの開発からは距離を置き、特定のユースケースに特化したモデルのカスタマイズとファインチューニングに注力する方向に舵を切った。その好例が、PDFやWord文書を解析するための文書理解モデルだ。これはフロンティアモデルと同等以上の精度を100分の1以下のコストで実現する。Mateiは、ベースモデルの性能向上とRL（強化学習）技術の進歩により、モデルのカスタマイズは今後ますます容易になり、主流になると予測する。

1:03:19フロンティアエコシステムとデータの価値

MicrosoftのSatya Nadellaが提唱する「フロンティアエコシステム」の概念について、Mateiは強く同意する。彼は、データの価値はAI技術の進歩とともに高まると述べ、電力会社のスマートメーターや自動車メーカーのセンサーデータを例に挙げる。AIエージェントは、これまで活用されていなかったデータから「顧客がファイルをアップロードできなくなっている」といった問題を自動的に検出できるようになる。Databricks自身も、自社のデータベースの全クエリ履歴とテーブル構造を活用することで、新しいエンジンを迅速かつ高品質に開発できた。Mateiは、最終的なテーゼとして「適切な場所にデータを配置し、その上にエージェントを載せる」というシンプルなパラダイムが、多くの従来型ソフトウェアを書き換えるだろうと予測する。エージェントのセキュリティ、マーケティング、セキュリティ運用といった分野向けに新たに発表された製品群も、この「データ＋エージェント」のアプローチに基づいている。

結びに

このエピソードが最も印象的に示したのは、Databricksという巨大企業が、創業時のビッグデータ処理基盤から、AIエージェント時代の「オペレーティングシステム」へと自らを進化させようとするダイナミズムである。OmnigentとLTAPという2つのプロジェクトは、一見すると異なる領域（エージェント基盤とデータベース）を扱いながらも、「ポータビリティ」「セキュリティ」「統一されたデータアクセス」という共通の哲学に貫かれている。特に、LTAPが目指す「ストレージ層の統一」は、AIエージェントが真に価値を発揮するために必要な「生きたビジネスコンテキスト」へのアクセスを提供するという点で、単なるデータベースの改良を超えた戦略的意義を持つ。また、社内のエンジニアが「やってみた」というプロトタイプから製品が生まれる文化や、オープンソースを戦略的に活用する姿勢は、規模が大きくなっても革新性を失わないための重要な教訓に富んでいる。AIモデル自体の性能がコモディティ化する中で、データとシステムインテグレーションこそが持続可能な競争優位の源泉であるという彼らの主張は、AIエンジニアにとって極めて示唆に富むものだ。