見出し画像

3-9.Databricks / Mosaic AIの企業データAI戦略を読む

香川友志

Databricksは企業データAIの覇者か――Mosaic AI、Lakehouse、企業LLM基盤の実力

欧米生成AI 2026 完全版 第9回

シリーズ：欧米生成AI 2026 完全版
副題：LLM・画像生成・動画生成・AI Agentで見る“欧米AI企業TOP20＋番外編”
第9回：Databricks / Mosaic AI
評価軸：AI部門の有名度 / 資本力 / 技術力 / 収益度 / AI部門価値
注記：本記事は2026年7月16日時点のDatabricks公式発表、製品ドキュメント、Data + AI Summit 2026の発表、資金調達・評価額に関する主要報道をもとにした分析記事です。製品名、提供地域、料金、評価額、IPO計画は変動する可能性があります。
為替は1ドル＝160円で概算換算しています。

読む前に｜企業AIの勝敗は「モデル」より「データ」で決まる

生成AIの話題は、どのモデルが最も賢いかに集中しがちです。

しかし企業がAIを導入すると、すぐに別の問題へぶつかります。

社内データはどこにあるのか。

最新版はどれか。

誰がアクセスできるのか。

売上、在庫、顧客、製造、文書、ログをどう結びつけるのか。

Agentが使ったデータとモデルを監査できるのか。

AIの回答が正しいかをどう評価するのか。

Databricksは、この問題を解く会社です。

同社はApache Spark、Delta Lake、MLflow、Unity Catalog、Lakehouseを作り、企業データの保存、処理、分析、機械学習を一つの基盤へまとめてきました。

現在は、Mosaic AI、Agent Bricks、Unity AI Gateway、Genie、Lakebase、Vector Search、Model Servingを加え、企業データとAI Agentを同じガバナンスの下で動かす標準基盤を狙っています。

Databricksの本質は、LLMを一つ作ることではありません。

どのモデルを使っても、企業のデータ、権限、評価、コスト、AgentをDatabricks上で管理することです。

目次

はじめに――なぜ第9回はDatabricks / Mosaic AIなのか
Databricksの現在地――企業データとAI Agentを統合する会社
第1章　5軸評価で見るDatabricks / Mosaic AIの総合力
第2章　Databricksとは何か――LakehouseからData Intelligence Platformへ
第3章　創業史――Apache Sparkの研究者が作った企業
第4章　Lakehouse――データレイクとデータウェアハウスを統合する
第5章　MosaicML買収とMosaic AI――モデル開発からAgent運用まで
第6章　Unity Catalog――企業データAIのガバナンス基盤
第7章　Agent Bricks――企業データで動くAI Agentの工場
第8章　Unity AI Gateway――モデル、Agent、MCP、コストを統制する
第9章　Genie One、Genie Agents、Genie Ontology――全社員へ企業コンテキストを届ける
第10章　Lakebase――Agent時代のServerless Postgres
第11章　MLflow、Model Serving、Vector Search――AI品質を継続改善する
第12章　マルチクラウドとオープンエコシステム――囲い込みを避ける戦略
第13章　資本力と成長――評価額1340億ドル、AI売上17億ドル超
第14章　競合比較――Snowflake、Microsoft、AWS、Googleとの違い
第15章　弱点とリスク――複雑性、コスト、クラウド依存、IPO期待
第16章　日本企業がDatabricksから学ぶべきこと
結論――Databricksは企業データAIの覇者か
次回予告――Cursor / Anysphereを読む

はじめに――なぜ第9回はDatabricks / Mosaic AIなのか

Databricksは、OpenAIやAnthropicのようなモデル企業ではありません。

ChatGPTのような一般消費者向けサービスでもありません。

それでも、企業AIでは最重要企業の一つです。

理由は、企業AIの燃料であるデータを握るからです。

企業には、構造化データがあります。

売上。

顧客。

在庫。

製造。

会計。

人事。

センサーデータ。

同時に、非構造化データがあります。

PDF。

メール。

会議録。

画像。

音声。

コード。

ログ。

AI Agentが実務で働くには、これらを安全に読み、正しい権限で利用し、結果を書き戻す必要があります。

Databricksは、データエンジニアリング、分析、BI、機械学習、生成AI、Agent、データベースを一つのData Intelligence Platformへ統合しようとしています。

本稿では、Databricksがモデル企業ではないのに、なぜAI時代の勝者候補なのかを読み解きます。

Databricksの現在地――企業データとAI Agentを統合する会社

Databricksを一言で表すなら、こうなります。

Databricksは、企業データ、分析、モデル、Agent、アプリ、ガバナンスをLakehouse上で統合し、企業AIのデータOSを狙う会社である。

Databricksの戦略には、六つの層があります。

第一層は、データです。

Delta Lake、Lakeflow、Lakehouse Federation、Iceberg互換などで、データを集め、保存し、処理します。

第二層は、ガバナンスです。

Unity Catalogで、データ、モデル、Feature、Prompt、Agent、Tool、Dashboardを管理します。

第三層は、AI開発です。

Mosaic AI Training、Model Serving、Vector Search、MLflowを使います。

第四層は、Agentです。

Agent Bricksで、企業データへ接続したAgentを作り、評価し、配布します。

第五層は、利用者です。

Genie One、Genie Agents、Genie Codeで、経営者、営業、分析者、開発者へAIを届けます。

第六層は、業務アプリです。

Lakebase、Databricks Apps、Marketplace、MCPを使い、Agentが状態を持ち、業務を実行します。

この全体をUnity CatalogとUnity AI Gatewayで統制することが、Databricksの強みです。

2026年7月16日時点の最新状況

2026年6月のData + AI Summitで、Databricksは企業AIの中心を「モデル」から「コンテキストと運用」へ移しました。

重要な更新は、六つあります。

第一に、Agent Bricksの拡張です。

Databricksによれば、同基盤では10万を超えるAgentが構築され、年間1000兆トークンを超える処理規模へ成長しています。

第二に、Omnigentです。

異なるAgent SDKやCoding Agentを一つのポリシー、セッション、予算、サンドボックスの下へまとめるメタハーネスです。

第三に、Genie One、Genie Agents、Genie Ontologyです。

企業データだけでなく、メール、チャット、文書、業務アプリの意味と関係を継続的に理解する企業向けContext Layerを作ります。

第四に、Lakebaseです。

Serverless PostgresをLakehouseへ統合し、AgentのMemory、状態、ユーザー設定、業務トランザクションを保存します。

第五に、セキュリティです。

Agent型SIEMのLakewatchを発表し、2026年6月にはPanther Labsの買収合意を発表しました。

第六に、業績です。

2026年6月16日、Databricksは年間売上ランレートが69億ドル、前年同期比80%超に達したと明らかにしました。

2月時点の54億ドルから、年換算した事業規模が15億ドル拡大した計算です。

これは4か月間に15億ドルの売上を追加計上したという意味ではなく、各時点の直近売上を年換算したランレート同士の差です。

ただしGhodsi CEOは、粗利率が今後さらに下がるとも述べました。Agentがクエリを増やすほど、外部モデルへの支払いが膨らむためです。

一方、2026年6月に報じられた評価額1650億〜1750億ドルの追加資金調達は、7月16日時点で完了を示す公式発表がありません。

現在の確定評価額は、2026年2月の資金調達時点の1340億ドルです。

第1章　5軸評価で見るDatabricks / Mosaic AIの総合力

【AI部門の有名度】
Databricks評価：企業データ・AI分野で世界最高クラス
点数：9.3 / 10
一言評価：一般消費者には見えにくいが、データ・ML・企業AIでは代表的ブランド。

【資本力】
Databricks評価：非上場企業として世界最強クラス
点数：9.6 / 10
一言評価：評価額1340億ドル、巨額調達、急成長売上を持つ。

【技術力】
Databricks評価：データとAIの統合で世界最高クラス
点数：9.8 / 10
一言評価：Spark、Delta Lake、MLflow、Unity Catalog、Agent Bricksを生み出した。

【収益度】
Databricks評価：高成長、利益率には課題
点数：9.0 / 10
一言評価：年間売上ランレート69億ドル、AI製品は17億ドル超へ成長。

【AI部門価値】
Databricks評価：企業AIのデータOS候補
点数：9.8 / 10
一言評価：企業データとAgentを同じ権限・監査で動かせる点が強い。

【総合評価】
Databricks評価：企業データAIの覇者候補
点数：47.5 / 50
一言評価：モデル競争の外側で、すべての企業AIを支える基盤を狙う。

Databricksの評価は、どのLLMを作ったかでは決まりません。

企業データを整える。

モデルを選ぶ。

Agentを作る。

評価する。

監査する。

現場へ配る。

このサイクル全体を握れるかで決まります。

第2章　Databricksとは何か――LakehouseからData Intelligence Platformへ

Databricksは、もともとデータ処理の会社です。

現在は、自らをData and AI company、あるいはData Intelligence Platformと位置づけています。

主要製品を整理します。

【Lakeflow】
データ取り込み、変換、オーケストレーションを扱います。

【Delta Lake / Delta Sharing】
信頼できるデータ保存と共有の基盤です。

【Databricks SQL / AI/BI】
分析、Dashboard、自然言語問い合わせを提供します。

【Unity Catalog】
データとAI資産を統合管理します。

【Mosaic AI】
モデル学習、Serving、RAG、評価、Agentを扱います。

【Agent Bricks】
企業Agentを構築・最適化・配布する基盤です。

【Genie】
自然言語でデータ、分析、コードを利用するAIです。

【Lakebase】
Agentとアプリ向けのServerless Postgresです。

【Databricks Apps】
データとAIに接続したアプリをDatabricks上へ配置します。

Databricksの特徴は、分析とAIを別製品にしないことです。

同じ企業データを、BI、機械学習、生成AI、Agent、業務アプリが共有します。

第3章　創業史――Apache Sparkの研究者が作った企業

Databricksは2013年、カリフォルニア大学バークレー校AMPLabの研究者たちによって設立されました。

共同創業者にはAli Ghodsi、Matei Zaharia、Ion Stoica、Reynold Xin、Patrick Wendell、Andy Konwinski、Arsalan Tavakoliなどがいます。

彼らはApache Sparkの原作者です。

Sparkは、大規模データ処理を高速化し、Hadoop中心だったデータ基盤を変えました。

Databricksは、Sparkを商用クラウドで使いやすくする会社として始まりました。

その後、重要なオープンソース技術を次々に生み出します。

【Delta Lake】
データレイクへトランザクション、品質、履歴を加えます。

【MLflow】
機械学習の実験、モデル、評価、配布を管理します。

【Unity Catalog】
データとAIの権限・監査を統合します。

2023年、DatabricksはMosaicMLを約13億ドルで買収しました。

MosaicMLは、企業が独自LLMを効率的に学習・運用する技術を持っていました。

この買収を土台に、Mosaic AIが作られます。

2025年、Agent Bricksを発表。

2026年、Agent Bricks、Unity AI Gateway、Genie、Lakebase、Ontologyを統合し、企業Agentプラットフォームへ進みました。

第4章　Lakehouse――データレイクとデータウェアハウスを統合する

Databricksの中心概念がLakehouseです。

従来、企業には二つのデータ基盤がありました。

データウェアハウスは、整理された構造化データとBIに強い。

データレイクは、安価で大量の生データを保存できる。

しかし、別々に持つとデータコピー、運用、権限、品質が複雑になります。

Lakehouseは、データレイクの柔軟性とデータウェアハウスの信頼性を統合します。

オブジェクトストレージ上にデータを置き、Delta Lakeでトランザクション、Schema、履歴、品質を加えます。

同じデータを、SQL、Spark、Python、BI、機械学習、生成AIで利用します。

生成AI時代にLakehouseが重要な理由は、非構造化データです。

文書、画像、音声、ログ、コードを構造化データと一緒に扱えます。

顧客表と問い合わせメール。

製品表とマニュアルPDF。

設備データと保守記録。

これらを結びつけ、Agentへ渡せます。

Databricksは、企業の「AIに使えるデータ」を作る場所を握ろうとしています。

第5章　MosaicML買収とMosaic AI――モデル開発からAgent運用まで

Mosaic AIは、Databricksの生成AI基盤です。

MosaicML買収当初、焦点は独自LLMの学習でした。

企業が自社データでモデルを作る。

分散学習を効率化する。

コストを下げる。

現在のMosaic AIは、さらに広い範囲を扱います。

【Mosaic AI Training】
独自モデル、継続事前学習、Fine-tuningを行います。

【Foundation Model APIs】
Claude、Llama、OpenAI、Gemini、Qwen、Kimiなどを、共通の企業データとガバナンスの下で利用します。

Grokは2026年7月16日時点では「今後提供予定」の従量課金モデルであり、一般提供済みのモデルとは区別します。

【Model Serving】
自社モデルと外部モデルを本番配布します。

【Vector Search】
企業データをEmbedding化し、RAGへ使います。

【AI Functions】
SQLから分類、抽出、要約、生成AI処理を実行します。

【MLflow】
Prompt、Trace、評価、Feedback、モデルを管理します。

【Agent Framework / Agent Bricks】
Agentを構築・評価・配布します。

Databricksは、モデル開発会社から、企業AIライフサイクル全体の会社へ変わりました。

第6章　Unity Catalog――企業データAIのガバナンス基盤

Unity Catalogは、Databricksの最重要製品です。

企業AIでは、モデル性能だけでなく、権限と意味の管理が重要です。

誰が、どのデータを見られるか。

どのAgentが、どのToolを使えるか。

どのモデルへ、どの情報を送れるか。

回答に使ったデータは何か。

ログとLineageは残るか。

Unity Catalogは、これらを管理します。

対象は、Table、File、Volume、Model、Function、Feature、Dashboard、Notebook、Agent、App、MCP Serverへ広がっています。

Databricksによれば、Unity Catalogは1万4000を超える組織で利用されています。

一つのCatalogで、データとAI資産を管理することが重要です。

多くの企業では、データ権限とAI権限が別管理です。

その結果、Agentが利用者より広いデータへアクセスしたり、外部モデルへ機密情報を送ったりする危険があります。

Unity Catalogでは、利用者のIdentityと権限をAgentの操作まで引き継ぎます。

Lineageによって、データがどこから来て、どの処理を通り、どのDashboard、Model、Agentへ使われたかを追跡します。

6-1　Business Glossary、Domains、Metrics――データへ「意味」を加える

2026年のData + AI Summitでは、Unity Catalogに業務上の意味を持たせる機能が拡張されました。

【Business Glossary】

顧客、契約、売上、解約など、企業内で使う正式な業務用語を定義し、実データへ結びつけます。

2026年6月時点では、提供開始を予定するPreview機能として発表されています。

【Domains】

データとAI資産を、財務、営業、製造、物流などの業務領域ごとに整理します。

Agentへカタログ全体を渡すのではなく、必要な領域の文脈だけを渡せます。

DomainsはPublic Previewとして提供されています。

【Metrics】

売上、粗利、顧客数、在庫回転率などのKPIを、統治された再利用可能なオブジェクトとして一度定義します。

SQL、BI、API、Genie、Agentから同じ定義で利用できます。

この三つが、Genie Ontologyの土台になります。

Unity Catalogに業務の意味を正しく登録するほど、GenieとAgentの回答精度が上がる構造です。

6-2　外部データを移さずに統治する

企業データは、現実にはDatabricksの外にも大量にあります。

2026年の更新では、外部システムまで含むLineageが一般提供されました。

Databricks外部で行われた変換や利用関係も、標準的なAPIを通じてUnity Catalogへ取り込めます。

また、資産へ一意のアドレスを与えるCross-cloud、Cross-region構想も発表されました。

Cross-region Governanceは今後Preview提供予定で、Cross-cloudとCross-accountはその後に続く計画です。

Databricks管理下のDelta TableへSparkやFlinkなどの外部エンジンから接続する機能はPublic Previewです。

さらに、データだけでなく、Model、Agent、Notebook、DashboardなどのAI資産を共有するOpenSharingが、Linux Foundationのオープンプロジェクトとして発表されました。

Databricksの本音は、すべてのデータを物理的に移動させることではありません。

外部にあるデータとAI資産を、Unity Catalogから発見、統治、監査できる標準レイヤーになることです。

Databricksの強みは、AIガバナンスを後付けするのではなく、データガバナンスの延長として作ることです。

6-3　Governance HubとABAC――Agent時代の権限を細かくする

Unity Catalogは、資産を登録するCatalogから、企業全体の統治状態を監視する基盤へ進んでいます。

Governance HubはPrivate Previewです。

データ、AI、コスト、Performanceに関するリスクを一つの画面で確認し、優先順位を付けて改善します。

Attribute Based Access Controlでは、Tag、Model Provider、承認状態、地域などの属性を使ってAccess Policyを適用します。

行フィルタリングと列マスキングを含むABAC Policyは一般提供され、ModelへのAttribute Based GrantはBetaです。

今後は、利用者の部門や地域などのIdentity Attribute、Agent経由か人間操作かを判定するContext Attributeへ広がる計画です。

Agentが増えるほど、固定的なGroup権限だけでは管理しにくくなります。

「誰か」だけではなく、「どのAgentが、どの状況で、何をしようとしているか」を権限判断へ加えることが重要になります。

第7章　Agent Bricks――企業データで動くAI Agentの工場

Agent Bricksは、DatabricksのAgent基盤です。

2025年に発表され、2026年に本格拡張されました。

Databricksによれば、10万を超えるAgentが構築され、年間1000兆トークンを超えるAgent処理を行う規模へ成長しています。

本番導入先として、AstraZeneca、7-Eleven、Fox Corporation、Blockなどが挙がっています。

Agent Bricksの考え方は、Agentを一から手作業で作るのではなく、目的、企業データ、品質基準を与え、プラットフォームが構成と評価を最適化することです。

主な領域は次の通りです。

【Knowledge Assistant】

企業文書、構造化データ、検索を使う回答Agent。

【Information Extraction】

文書から項目、表、契約条件、属性を抽出します。

【Custom LLM / Custom Agents】

企業独自のタスクへモデルとAgentを最適化します。

【Multi-Agent Supervisor】

複数の専門Agentを統括します。

【Agent Framework】

LangGraph、OpenAI Agents SDK、カスタムPythonなどで作ったAgentを運用します。

Agent Bricksの重要な特徴は、自動評価です。

企業が自然言語で品質条件を指定する。

複数モデル、Prompt、検索設定を試す。

品質とコストのPareto最適を探す。

本番で利用者Feedbackを集め、改善する。

Agentを「一度作って終わり」ではなく、継続改善する製品として扱います。

2026年のSummitでは、Agent Bricks自体も外部エコシステムへ開かれました。

Claude Code SDK、LangGraph、Agno、CrewAI、OpenAI Agents SDKなどに対応し、Databricks Appsによる水平オートスケールも加わりました。

7-1　Agent Memory、Document Intelligence、Sandbox

Agentを本番で動かすには、推論ループ以外の基盤が必要です。

Databricksが2026年に強化したのが、Memory、文書処理、隔離実行です。

【Agent Memory Service】

Agentの会話履歴、セッション状態、長期コンテキストを管理します。

基盤にはLakebaseが使われ、セッションをまたいで情報を保持します。

複数Agent間での共有は将来計画であり、現在利用できる機能と区別する必要があります。

【Document Intelligence】

PDFなどの文書を解析するSQL関数群です。

ai_parse_document。

ai_extract。

ai_classify。

これらを使い、文書の構造化、項目抽出、分類をAgent Workflowへ組み込めます。

Document Intelligenceは一般提供されています。

【Databricks Sandbox】

AgentやCode Interpreterを、隔離された仮想環境で実行します。

Unity Catalogの権限を必要な範囲へ絞ったうえで、コード実行、Sub-agent、Agent Harness、検証作業を動かします。

Agentへ企業データとコード実行権限を与える場合、通常のNotebookと同じ環境で無制限に動かすべきではありません。

Sandbox、最小権限、人間承認、実行ログを組み合わせることが、本番運用の前提になります。

7-2　Omnigent――複数Agentを束ねるメタハーネス

Omnigentは、Apache 2.0で公開されたオープンソースのメタハーネスです。

オープンソース版は2026年6月時点でAlphaです。

背景には、企業Agentの分断があります。

Claude Code、Codex、独自Agent、LangGraphなどを使い始めると、文脈、ポリシー、予算、セッション、人間承認が環境ごとに分かれます。

Omnigentは、個々のAgentハーネスの上に立ち、統一APIで包みます。

異なるAgentを差し替え、組み合わせる。

共通の文脈とポリシーを与える。

コスト上限を設定する。

隔離されたSandboxで実行する。

実行中のAgentセッションを共有する。

必要な場面で人間承認を挟む。

DatabricksはOmnigentの管理版もAgent Bricksの構成要素として発表しています。ただし、2026年7月16日時点で、公式ブログ上に明確なGA・Beta表記は確認できません。本稿では、オープンソース版Alphaと、Databricksが発表した管理版を区別して扱います。

ここにDatabricksの一貫した思想があります。

Agent Frameworkが乱立しても、その上に統治レイヤーを置けば、企業データ、権限、評価、予算はDatabricksに残ります。

Databricksは、Agentの中核ループは仕事全体の一部にすぎず、実用化の大半はMemory、評価、文脈、統治、監視などの周辺基盤だと説明しています。

Agent Bricks、Omnigent、Unity AI Gateway、MLflow、Lakebaseは、この周辺基盤を一体化する製品群です。

第8章　Unity AI Gateway――モデル、Agent、MCP、コストを統制する

2026年、DatabricksはAI GatewayをUnity AI Gatewayへ進化させました。

これは、企業内のAI利用を通過させる制御点です。

対象は、外部LLM、自社モデル、Coding Agent、MCP Server、Tool、Genie、Custom Agent、Omnigentへ広がります。

主な機能は次の通りです。

モデルへのAccess Control。

API KeyとCredentialの集中管理。

Rate Limit。

予算とToken Spendの管理。

PII検出とSafety Guardrail。

Load Balancing。

Provider障害時のFallback。

Request / Response Logging。

Model、User、Teamごとの利用分析。

Promptと出力の品質監視。

MCP操作の監査。

Agent時代には、一人の社員が複数モデルと多数のToolを利用します。

各アプリが個別にAPI Keyとログを持てば、統制できません。

Unity AI Gatewayは、AI利用のFirewall、API Gateway、Cost Center、監査基盤を一つにします。

8-1　MCPを全社統制する

MCPは、Agentと企業システムを接続する標準として急速に広がっています。

しかし、MCP Serverへ接続するだけでは安全になりません。

どの利用者が、どのToolを使えるか。

読み取りだけか、書き込みも可能か。

どのCredentialを使うか。

操作履歴を残せるか。

費用上限を設定できるか。

これらを管理する必要があります。

Databricksは、Google Drive、Jira、Confluence、Slack、GitHub、SharePointなどに接続するMCP Servicesを提供しています。

外部のMCP ServerもUnity CatalogのSecurableとして登録でき、管理者はTool選択、Access、Credential、Service Policy、Audit Logを統制できます。

2026年7月16日時点で、外部MCP ServicesはBeta、Databricks Managed MCP ServersはPublic Previewです。

ここで重要なのは、書き込み権限の扱いです。

Databricks提供の組み込みMCP Servicesには、書き込み操作を遮断する組み込みService Policyが用意されています。

したがって、「読み取りと書き込みが既定で全面有効」という説明は正確ではありません。

外部MCP Serverを登録する場合も、管理者は公開するToolを限定し、Service Policyで許可、拒否、人間承認を設定できます。

導入時には、読み取りと書き込みを分離し、破壊的操作、機密フォルダ、コードPush、CRM更新などへ明示的な承認条件を設けることが前提になります。

Unity AI Gatewayでは、利用者・Team・Tool・Use Case単位の予算、Hard Spend Cap、Agent Trace、Smart Routing、Contextに応じたPolicyを組み合わせます。

Contextual Service PoliciesはBetaです。

Agentが個人情報へアクセスした後に外部公開を試みた場合は拒否し、社内送信は許可し、CRMやGitHubへの書き込みには人間承認を要求する、といった状態依存の制御を目指しています。

AI Gatewayの価値は、APIを一か所へ集めることではありません。

企業AIの「誰が、何を、どこまで、いくら使えるか」を実行時に統制することです。

8-2　LakewatchとPanther――セキュリティもAgentの仕事にする

Databricksは、この統治の考え方をサイバーセキュリティ市場へ広げています。

2026年3月24日、Agent型SIEMのLakewatchを発表しました。

発表時点ではPrivate Previewです。

Lakewatchは、企業のセキュリティログをLakehouseへ集約し、Agentが脅威の検知、調査、優先順位付け、対応支援を行う構想です。

一部の検知・調査機能にはAnthropic Claudeを使用します。

早期顧客として、Adobe、Dropbox、National Australia Bankなどが紹介されています。

基盤には、AntimatterとSiftD.aiの買収で得た技術が使われています。

2026年6月16日、Databricksはクラウドセキュリティ分析企業Panther Labsの買収合意を発表しました。

買収条件は公表されておらず、合意発表時点では通常の完了条件を残す取引として扱う必要があります。

Pantherは、大量のクラウド・セキュリティデータを分析し、検知ルールと調査ワークフローを提供します。

Databricksから見れば、SIEMは新市場であると同時に、Lakehouseの自然な用途です。

セキュリティログをLakehouseへ置く。

Unity Catalogで統治する。

LakewatchとPantherの技術で脅威を調べる。

Unity AI Gatewayで調査Agentの行動とコストを管理する。

守る側と守られる側の両方を、同じデータ・AI基盤へ載せる構図です。

2026年7月には、Genieの利用額もUnity AI GatewayのBudgetで追跡できるようになりました。

第9章　Genie One、Genie Agents、Genie Ontology――全社員へ企業コンテキストを届ける

Databricksの課題は、データエンジニアだけの製品に見えやすいことでした。

Genieは、一般社員へData Intelligenceを届ける製品です。

2026年6月、DatabricksはGenieを三つの中心製品へ整理しました。

9-1　Genie One

Genie Oneは、ビジネス利用者向けのAI Coworkerです。

自然言語で質問し、企業データ、指標、文書、メール、チャット、業務アプリを横断して情報を集めます。

分析結果を返すだけではありません。

スケジュールとAlertを作る。

文書を生成する。

業務Toolを操作する。

MCPを通じて外部システムへ接続する。

こうした行動まで扱います。

SlackとMicrosoft Teamsへ組み込まれ、iOSとAndroidアプリも提供されます。

既存のAIアシスタントから利用するためのGenie MCP Appも発表されました。

すべての回答は、元データのAccess ControlとUnity Catalogの権限を引き継ぎます。

9-2　Genie Agents

Genie Agentsは、旧Genie Spacesを自律Agentへ進化させた製品です。

Databricksによれば、顧客はこれまでに100万を超えるGenie Spacesを作成しています。

営業、財務、製造、物流など、業務領域ごとのAgentを、自然言語の指示から作れます。

構造化データだけでなく、文書、File、Knowledge Sourceも利用します。

MCP接続、定期実行、成果物生成、外部システムへの書き込みを組み合わせ、複数ステップの業務を進めます。

ただし、書き込みや重要判断には、最小権限、人間承認、監査ログが必要です。

9-3　Genie Ontology

Genie Ontologyは、企業の意味と関係を保持するLiving Context Graphです。

顧客とは何か。

売上の正式な定義は何か。

どのDashboardとQueryが信頼されているか。

製品、工場、在庫、契約、部門はどう結びつくか。

Ontologyは、Table、Query、Dashboard、Pipeline、文書、接続アプリから知識を抽出し、企業が実際にデータを使う方法を学びます。

Databricks公式は、PageRankに似た考え方で情報源のAuthorityを評価すると説明しています。

Webページ間のLinkではなく、定義の作成者、利用頻度、認定済み資産との結びつき、情報の新しさなどを組み合わせます。

Genie Ontologyは、LakehouseとUnity Catalogに加え、Google Drive、SharePoint、メール、Jira、Slack、Confluenceなどの接続Toolから企業コンテキストを取り込みます。

接続数の総数は公式ブログで明示されていないため、本稿では具体的な数字を断定しません。

特徴は、情報源のAuthorityを評価することです。

誰が定義したか。

どれだけ利用されているか。

認定済みデータと結びついているか。

情報が新しいか。

これらを使い、Agentが参照すべき情報源へ重みを付けます。

Databricksの社内評価では、実務的な企業データ分析28問に対し、Genie Ontologyを使ったGenieは初回回答で84.5%の正答率を記録しました。

比較対象の最も強い汎用Coding Agentは52.4%でした。

ただし、これはDatabricksによる社内ベンチマークであり、匿名化された比較対象と限定的な問題セットによる結果です。

第三者評価と同じように扱うべきではありません。

9-4　Genie Code

Genie Codeは、旧Databricks Assistantを発展させた開発者向けAgentです。

Notebook、SQL Editor、Pipeline、Jobでコード生成、デバッグ、最適化、Agent Modeを提供します。

重要なのは、単にコードを生成するのではなく、Unity Catalog、業務用語、既存Pipeline、権限を理解して作業することです。

Ali Ghodsi CEOがData + AI Summitで強調したのは、AIの問題は知能だけではなく、企業コンテキストの欠落だという点です。

Genie One、Agents、Ontology、Codeは、そのコンテキストを一般社員と開発者へ届ける製品群です。

第10章　Lakebase――Agent時代のServerless Postgres

AI Agentは、データを読むだけでは終わりません。

状態を保存する。

タスクを作る。

注文を更新する。

会話履歴を持つ。

顧客情報を書き換える。

この処理には、低遅延のトランザクションデータベースが必要です。

DatabricksはLakebaseを提供します。

Lakebaseは、PostgreSQL互換のFully Managed Serverless Databaseです。

2026年2月に一般提供されました。

Databricksは従来、分析、データエンジニアリング、機械学習に強い会社でした。

Lakebaseによって、業務アプリとAgentが使うOperational Dataまで扱います。

主な用途は次の通りです。

AgentのMemory。

Workflow State。

User Profile。

会話履歴。

注文、在庫、Ticket。

アプリ設定と権限情報。

低遅延のリアルタイム意思決定。

Lakebaseの価値は、Postgresを提供することだけではありません。

Lakehouseの分析データ。

Unity Catalogの権限。

Mosaic AIのModel。

Agent BricksのAgent。

Databricks Appsの業務アプリ。

これらの近くに、トランザクションデータベースを置くことです。

AgentがLakehouseから過去の顧客行動を分析し、Lakebaseから現在の注文状態を読み、承認後に業務データを書き換える構成が可能になります。

ただし、既存のOracle、SQL Server、PostgreSQLを一斉に置き換える製品ではありません。

当初の勝ち筋は、新しいAIアプリ、Agent、リアルタイム業務です。

企業は、分析用データと業務更新用データの責任分界、バックアップ、可用性、書き込み権限を明確にする必要があります。

10-1　ServerlessとBranching――Agentが安全に試すためのDatabase

Lakebaseは、サーバーレスのPostgreSQL互換Databaseとして、需要に応じた運用と開発環境の迅速な作成を支援します。

Branchingでは、Production環境から分岐した開発・検証用のDatabase環境を作り、Agentやアプリの変更を本番から隔離して試せます。

AI AgentがProductionに近い状態で処理を試し、問題があれば破棄する用途と相性があります。

ただし、Branchがあるから安全になるわけではありません。

個人情報のMasking。

ProductionへのWrite禁止。

承認後のMerge。

BackupとDisaster Recovery。

こうした運用ルールが必要です。

DatabricksはLakebaseを、既存Databaseの一括置換ではなく、AI AppとAgentから入る新しいOperational Databaseとして位置づけています。

第11章　MLflow、Model Serving、Vector Search――AI品質を継続改善する

企業AIが失敗する大きな理由は、品質を測れないことです。

回答が正しいか。

検索した文書は適切か。

Toolを正しく使ったか。

以前より改善したか。

利用者は満足したか。

MLflowは、機械学習の実験管理から、生成AI・Agentの評価基盤へ進化しました。

Traceで、Prompt、Model、Retrieval、Tool Call、Responseを記録します。

Evaluationで、正確性、安全性、Groundedness、Guidelineを測ります。

Review Appで、業務専門家からFeedbackを集めます。

Production Monitoringで、本番の品質変化を追います。

Model Servingは、独自モデルと外部モデルをEndpointとして提供します。

Vector Searchは、Delta Tableと同期し、企業データのEmbedding検索を作ります。

なお、2026年の公式ドキュメントでは、Vector SearchはAI Searchへ改称されています。従来のvector-search系のURLプレフィックスとScopeは引き続き利用できるため、本稿では旧称のVector Searchを併記します。

重要なのは、評価データ自体もUnity CatalogとDelta Tableで管理できることです。

どのモデルが優れているかを、公開ベンチマークではなく、自社業務データで比較できます。

企業AIでは、これが最も重要です。

第12章　マルチクラウドとオープンエコシステム――囲い込みを避ける戦略

Databricksは、AWS、Azure、Google Cloudで利用できます。

これは大きな特徴です。

Microsoft FabricはAzure中心。

Google BigQueryはGoogle Cloud中心。

AWSのデータサービスはAWS中心。

Databricksは、複数クラウドへ同じLakehouse思想を提供します。

完全に同一機能ではありませんが、企業はCloud Strategyに合わせて選べます。

また、Databricksはオープンソースを重視します。

Apache Spark。

Delta Lake。

MLflow。

Unity Catalogの一部。

OpenAPI、MCP、OpenTelemetry。

Icebergとの互換・相互運用。

モデルも一社へ固定しません。

OpenAI、Anthropic、Gemini、Qwen、Kimi、オープンモデルなどを、同じ企業データとガバナンスの下で利用します。

Databricksは、特定のモデル企業に賭けるのではなく、用途、品質、速度、価格に応じてモデルを切り替える中立的な制御層を狙っています。

2026年6月には、SpaceXとの提携を通じてGrokモデルをDatabricksへ提供する計画も発表しました。

ただし、提供予定のモデルと、すでに一般提供されているモデルは区別する必要があります。

DatabricksのRelease Notesでも、Grokは「今後提供予定」として案内されています。

Databricksの勝ち筋は、どのCloud、どのModelが勝っても、企業データとガバナンスがDatabricksに残ることです。

ただし、実際の計算はAWS、Azure、Google Cloud上で動きます。

Databricks自身もクラウド事業者へ依存しています。

第13章　資本力と成長――評価額1340億ドル、AI売上17億ドル超

Databricksは、世界最大級の非上場ソフトウェア企業です。

2026年2月、Databricksは約50億ドルの株式資金調達を完了し、評価額は1340億ドルとなりました。

同時に、約20億ドルの新たなDebt Capacityも確保しました。

この時点で、年間売上ランレートは54億ドル、前年同期比65%増。

AI製品の売上ランレートは14億ドルでした。

そして2026年6月16日、DatabricksはData + AI Summitで、年間売上ランレートが69億ドルへ達したと明かしました。

前年同期比80%超の成長です。

2月時点の54億ドルから、年換算した事業規模が15億ドル拡大した計算になります。

ただし、これは4か月間の実売上が15億ドル増えたという意味ではありません。

非上場企業が公表した異なる時点の年間換算ランレートを比較した数字です。

AI製品の売上ランレートも、2月の14億ドルから17億ドルへ伸びました。

これは全体の約4分の1にあたり、半年前の10億ドルから拡大しています。

伸びを支えるのは三つのエンジンです。

従来のSparkとデータエンジニアリング。

Databricks SQLの分析事業。

そして最も速く伸びるMosaic AIとAgent Bricksを中心としたAI事業。

ただし、明るい話だけではありません。

Ghodsi CEOはCNBCの取材に対し、粗利率は今後さらに下がると述べました。

理由は、Databricks自身のビジネスモデルにあります。

Ghodsi CEOは、Agentが従来の利用者より多くのQueryを生成し、プラットフォーム消費を増やす一方、外部モデルへの支払いも増える構造を説明しています。

つまり、Agentが増えるほど売上は増えるが、その裏でDatabricksは外部モデルへの支払いを増やさねばなりません。

売上成長と利益率が、同じ方向を向かない構造です。

つまりDatabricksは、「将来AIで稼ぐ会社」ではありません。

Mosaic AI、Agent Bricks、Model Serving、Genie、AI Gatewayなどが、すでに10億ドルを大きく超える事業になっています。

Databricksが巨額資金を必要とする理由は、単なる運転資金ではありません。

Neonを含む大型買収。

Agent、Database、Security分野の買収と統合。

GPUとクラウド計算容量の確保。

世界的な営業・導入支援体制。

従業員と初期投資家への流動性提供。

これらを同時に進めます。

2026年6月、Databricksが1650億〜1750億ドルの評価額で追加資金調達を協議していると報じられました。

しかし、2026年7月16日時点で、ラウンド完了を示す公式発表は確認できません。

したがって、現在の確定評価額は1340億ドルです。

Databricksは長くIPO候補とされています。

Ali Ghodsi CEOは2026年の上場に慎重な姿勢を示していますが、2027年上場が正式決定したわけではありません。

上場時期は、市場環境、追加調達、成長率、従業員・投資家の流動性需要によって変わります。

非上場のまま巨額調達を続ける利点は、四半期市場の圧力を避け、Agent、Database、Securityへ長期投資できることです。

一方、高い評価額は、高い売上成長と将来収益を前提とします。

Databricksの価値は、単なる売上倍率だけではありません。

企業データの中心に入り、AI利用が増えるほど、Data Processing、SQL、Model Serving、Vector Search、Lakebase、Gateway、Monitoringの利用が増える構造です。

第14章　競合比較――Snowflake、Microsoft、AWS、Googleとの違い

Snowflakeとの違い

Snowflakeは、クラウドデータウェアハウスとData Cloudで強い競合です。

SQL、データ共有、Marketplace、Cortex AI、SaaSとしての運用の簡潔さに強みがあります。

Databricksは、Spark、Python、大規模データエンジニアリング、機械学習、オープンフォーマット、Agent開発で強い。

両社は互いの領域へ進出し、LakehouseとData Cloudの境界は薄れています。

両社が共通して重視し始めたのが、企業データの意味です。

正式な売上指標は何か。

どのTableが認定済みか。

顧客、製品、契約、在庫はどう結びつくか。

この意味層がなければ、Agentは毎回ゼロからデータを探索し、誤った定義を使う可能性があります。

DatabricksはUnity Catalog、Metrics、Business Glossary、Genie Ontologyを通じて、この文脈をデータ・AIガバナンスへ統合します。

SnowflakeもCortex AIなどを通じて、自然言語分析と企業AIを強化しています。

規模比較には注意が必要です。

Snowflakeは上場企業として四半期ごとの売上、利益、顧客指標を開示します。

Databricksの69億ドルは、非上場企業が示した年間売上ランレートです。

会計期間と開示方法が異なるため、単純な売上額や時価総額だけで優劣を判断すべきではありません。

選定では、SQL中心か、Data EngineeringとAI開発中心か、既存Cloud、データ形式、開発人材、Agent計画、総所有コストを比較する必要があります。

Microsoftとの違い

MicrosoftはFabric、Azure AI、Power BI、Copilotを持ちます。

Office配布力ではMicrosoftが圧倒的です。

DatabricksはAzureの重要パートナーであると同時に、Fabricの競合でもあります。

AWSとの違い

AWSはS3、Redshift、SageMaker、Bedrock、AgentCoreを持ちます。

AWSはインフラとモデル市場で強い。

Databricksは、AWS上でも動き、企業データ・ML・Agentを一つの体験へまとめます。

Googleとの違い

GoogleはBigQuery、Vertex AI、Gemini、TPUを持ちます。

Databricksはマルチクラウドとオープンエコシステムで対抗します。

Palantirとの違い

PalantirはOntology、FDE、業務意思決定で強い。

Databricksはより開発者・データ基盤寄りです。

Genie Ontologyと顧客現場での導入支援を強化することで、Palantirが得意とする業務実装の領域へ近づいています。

Databricksの独自性は、データ基盤、ML開発、Agent、BI、Databaseを一つのプラットフォームへ集めることです。

第15章　弱点とリスク――複雑性、コスト、クラウド依存、IPO期待

Databricksにも弱点があります。

第一に、複雑性です。

Lakeflow、Delta、Unity Catalog、Mosaic AI、MLflow、Agent Bricks、Genie、Lakebaseを理解するには専門人材が必要です。

第二に、コストと利益率です。

Databricks公式は、Agent利用が拡大するとToken消費とAI支出が急増し得ると説明しています。

Unity AI Gatewayの統合Spend View、Hard Spend Cap、Smart Routingは、この問題へ対応する機能です。

利用額を可視化するだけでなく、予算到達時にRequestを停止し、Taskの難易度、品質、Costに応じてModelを振り分けます。

これはDatabricks自身の課題でもあります。

Ghodsi CEOは2026年6月、粗利率が今後さらに低下すると認めました。Agentがクエリを大量に生成し、その裏で外部モデルへの支払いが増えるためです。

売上が伸びるほど原価も膨らむ。

この構造は、IPO時の評価にも影響します。

顧客側にとっても、同じ問題が起きます。

DatabricksのDBU、Cloud Compute、Storage、Model APIを組み合わせると、料金が分かりにくくなります。

Agentが大量にToken、Query、Toolを使うと、予算管理が必要です。

第三に、データ整理の難しさです。

Unity Catalogを導入しても、元データが重複、欠損、古い、定義不一致なら、AIは正しくなりません。

第四に、Cloud Provider依存です。

Databricksはマルチクラウドですが、物理インフラはAWS、Azure、Googleに依存します。

第五に、Snowflake、Microsoft、AWS、Googleとの競争です。

巨大クラウドは、Databricks機能を自社サービスへ統合できます。

第六に、評価額です。

確定評価額1340億ドルと、報道上の1650億〜1750億ドルという交渉水準は、高い成長を前提とします。

成長が鈍れば、IPOや資金調達で厳しい評価を受けます。

第七に、Agent責任です。

Agentが誤ったデータ更新、分析、顧客対応を行った場合、Databricks、モデル企業、導入企業の責任分界が必要です。

第八に、オープンと囲い込みの矛盾です。

Databricksはオープンを掲げますが、Unity CatalogやPlatform固有機能へ深く依存すると移行は難しくなります。

第16章　日本企業がDatabricksから学ぶべきこと

日本企業がDatabricksから学ぶべきことは、七つあります。

第一に、AI導入の前にデータ基盤を統合することです。

PoCごとにデータをコピーすると、権限、品質、コストが崩れます。

第二に、データとAIを同じCatalogで管理することです。

Tableだけでなく、Model、Prompt、Agent、Tool、Evaluationを資産として管理します。

第三に、業務用語と指標を定義することです。

売上、顧客、在庫、利益の定義が部署ごとに違えば、GenieもAgentも混乱します。

第四に、公開ベンチマークではなく自社データで評価することです。

業務専門家のFeedbackをEvaluation Datasetへ蓄積します。

第五に、モデルを一社へ固定しないことです。

Unity AI Gatewayのような制御点を置き、品質、価格、障害に応じて切り替えます。

第六に、Agentへ最小権限を与えることです。

読む、書く、承認する、支払う権限を分けます。

第七に、データ人材と業務人材を同じチームにすることです。

Agentの品質は、データエンジニアだけでも、業務部門だけでも作れません。

Databricksの導入は、製品購入ではなく、企業データ運営モデルの改革です。

補章A　Databricks導入で最初に行うべき「データ製品化」

多くの企業は、Databricksを導入すると、既存データをすべてLakehouseへ移そうとします。

しかし、移行するだけではAI価値は生まれません。

重要なのは、データを「製品」として管理することです。

所有者は誰か。

利用目的は何か。

品質基準は何か。

更新頻度は何か。

機密区分は何か。

正しい指標は何か。

問題が起きたら誰が直すか。

これらを定義します。

たとえば「顧客データ製品」なら、顧客ID、契約、問い合わせ、購入、解約、同意状態を結びつけます。

「設備データ製品」なら、設備ID、Sensor、保守、故障、部品、作業員、Manualを結びつけます。

Unity CatalogのDomain、Tag、Lineage、Qualityを使い、業務部門が責任を持ちます。

Agentは、この整備されたデータ製品を使います。

データを無秩序なTableの集合として渡すと、Agentは同じ意味の列を混同し、古い情報を使い、誤った集計をします。

Databricksの導入効果は、Compute性能よりData Productの運営体制で決まります。

補章B　Agent BricksがPoC止まりを減らす理由

生成AIのPoCは、Demoでは成功します。

数十件の文書なら答えられる。

決められた質問なら動く。

開発者が横で調整すれば成功する。

本番では条件が変わります。

質問が曖昧になる。

文書が増える。

権限が異なる。

モデルが更新される。

外部APIが停止する。

利用者が想定外の操作を行う。

コストが膨らむ。

Agent Bricksの価値は、この本番問題へ対応することです。

品質基準を定義する。

複数モデルと構成を自動比較する。

Toolとデータ権限をUnity Catalogで管理する。

MLflow Traceで失敗を分析する。

業務専門家のFeedbackを評価データへ戻す。

AI GatewayでCostとFallbackを管理する。

Agentを作る機能は、LangChain、LangGraph、OpenAI SDKにもあります。

Databricksの差は、企業データ、評価、運用、ガバナンスが一つにつながることです。

PoCを本番へ移すとき、別の監視製品、権限製品、評価製品を組み合わせる必要が減ります。

補章C　製造業でのDatabricks活用――データとAI Agentを現場へつなぐ

日本の製造業は、Databricksと相性が良い領域です。

工場には、PLC、SCADA、MES、ERP、品質、保全、画像、作業日報、Manualがあります。

これらは別システムに分かれています。

Lakehouseへ集約すると、次のAgentを作れます。

設備異常の原因を調べるAgent。

過去の故障、Sensor波形、保守履歴、Manualを検索します。

品質不良を分析するAgent。

Lot、原料、設備条件、検査画像、作業者、環境データを結びつけます。

生産計画を支援するAgent。

受注、在庫、設備能力、納期、保全予定を使います。

技術伝承Agent。

熟練者の日報、会議、動画、Manualから回答します。

ただし、AgentがMESや設備へ直接書き込む場合は慎重さが必要です。

最初は読み取り専用。

次に提案。

人間承認後に実行。

十分な評価後に限定自動化。

この段階設計が必要です。

Databricksは、ITデータとOTデータを同じガバナンスへ置けますが、現場安全の責任は導入企業に残ります。

補章D　SnowflakeとDatabricksをどう選ぶか

DatabricksとSnowflakeは、最も比較される企業です。

単純に「どちらが優れているか」では決まりません。

SQL中心の分析、データ共有、SaaS的な運用の簡潔さを重視するなら、Snowflakeが向く場合があります。

大規模データエンジニアリング、Python、Spark、機械学習、独自モデル、Agent開発を重視するなら、Databricksが向く場合があります。

実際には両方を使う企業も多い。

その場合、データコピーと二重ガバナンスが問題になります。

選定時には、次を比較すべきです。

現在のCloud。

データ形式。

SQLとPythonの利用比率。

ML Engineerの人数。

AI Agentの計画。

リアルタイム要件。

既存BI。

総所有コスト。

データの持ち出し可能性。

Databricksを選ぶ理由は「AIに強そうだから」では不十分です。

自社がData EngineeringとAI Applicationを一つの基盤で運営する必要があるかで決めます。

補章E　日本企業向けDatabricks導入ロードマップ

第一段階は、Unity Catalogです。

既存のTable、File、Modelの所有者、権限、Lineageを整理します。

第二段階は、重要なData Productを三つ程度作ります。

顧客、製品、設備など、AI利用価値が高い領域を選びます。

第三段階は、Genie Agentです。

読み取り専用で、経営指標や業務質問へ答えさせます。

第四段階は、Knowledge AgentとExtractionです。

文書、PDF、画像をVector SearchとAgent Bricksへ接続します。

第五段階は、業務Toolです。

CRM、ERP、Ticket、Lakebaseへ接続し、人間承認付きで書き込みます。

第六段階は、AI Gatewayによる全社統制です。

モデル、予算、PII、MCP、Agent利用を一元管理します。

第七段階は、継続評価です。

MLflowへ失敗例と利用者Feedbackを蓄積し、月次で品質を改善します。

この順序なら、プラットフォームを導入しただけで利用が広がらない問題を避けやすくなります。

補章F　Databricksの収益モデル――AIが増えるほどDBU以外も広がる

Databricksの収益は、従来、Compute利用を示すDBUが中心でした。

データ処理、SQL、Job、Notebookが動くほど売上が増えます。

AI時代には、収益源が広がります。

Model Servingの推論。

Foundation Model API。

Vector Search。

Agent Bricks。

Unity AI Gateway。

Serverless SQL。

Lakebase。

Databricks Apps。

Marketplace。

企業がAgentを増やすほど、Tokenだけでなく、検索、Database、Logging、Evaluation、Storage、Computeが動きます。

この構造は強力です。

一つのAIアプリが成功すると、複数のDatabricksサービス利用が増えるからです。

一方、顧客から見ればCostが複雑になります。

Agent一件あたりの原価を把握するには、Model Token、SQL Query、Vector Search、Lakebase、Cloud Computeをまとめる必要があります。

Unity AI GatewayのBudget、System Table、Tag、Chargebackを使い、業務部門ごとに費用を可視化することが重要です。

Databricksが高い評価額を維持するには、AI製品売上17億ドル超をさらに伸ばしながら、顧客の総コストを合理化する必要があります。

結論――Databricksは企業データAIの覇者か

Databricksは、企業データAIの覇者候補です。

理由は、最強LLMを持つからではありません。

Sparkでデータを処理する。

Delta Lakeで信頼できる形に保存する。

Unity Catalogで権限とLineageを管理する。

Mosaic AIでモデルを作り、提供する。

Agent Bricksで企業Agentを構築する。

Unity AI Gatewayでモデル、MCP、Tool、コストを統制する。

Genieで一般社員へ届ける。

LakebaseでAgentの状態と業務データを書き戻す。

MLflowで品質を評価し続ける。

この閉じた循環を作れることが強みです。

2026年のDatabricks戦略は、三つの言葉に集約できます。

Choice。

複数のモデル、Agent Framework、Cloudを選べること。

Context。

企業データ、業務用語、権限、履歴をAgentへ正しく渡すこと。

Control。

予算、Tool、MCP、書き込み、個人情報、Agent Traceを統制すること。

Agent Bricks、Genie Ontology、Unity AI Gateway、Lakebaseは、この三つを一つの基盤へまとめるための製品です。

もう一つ重要なのは、一般提供、Beta、Private Preview、今後提供予定を区別することです。

DatabricksはData + AI Summitで非常に多くの製品を発表しました。

しかし、発表された機能がすべて同じ成熟度にあるわけではありません。

OmnigentのOpen-source版はAlpha、Managed版はBeta。

Contextual Service PoliciesはBeta。

Governance HubはPrivate Preview。

Grokは今後提供予定です。

企業は将来構想の魅力だけでなく、現在の提供地域、SLA、料金、Security、Supportを確認して導入判断する必要があります。

Databricksの勝ち筋は、どのLLMが勝っても成立します。

OpenAIを使っても。

Claudeを使っても。

Geminiを使っても。

GrokやMistralを使っても。

企業データ、権限、評価、AgentがDatabricks上にあれば、利用量はDatabricksの価値になります。

一方、勝利は保証されません。

Snowflakeは強い。

MicrosoftはOfficeとAzureを持つ。

AWSとGoogleは物理インフラを持つ。

製品は複雑で、コスト管理も難しい。

それでも、企業AIの本質が「自社データで正しく働くこと」なら、Databricksの位置は極めて強い。

Databricksは、AIモデルの王者ではありません。

企業データとAI Agentを結ぶOSの王者を狙う会社です。

次回予告――Cursor / Anysphereを読む

次回、第10回はCursor / Anysphereです。

Cursorは、AI IDEからAgent開発基盤へ進み、ソフトウェア開発の入口を握ろうとしています。

モデルを作らない企業が、なぜOpenAI、Anthropic、Google、Grokの価値を束ねられるのか。

開発者データ、Agent、IDE、企業契約はどこまで強いのか。

次回は、AI時代の開発OSを読み解きます。

主要参考リンク

出典対応表

  • 創業者、Apache Spark、Delta Lake、MLflow、Unity Catalogの系譜：Databricks公式

  • Agent Bricksの10万超のAgent、年間1000兆トークン超、Agent Memory、Document Intelligence、Sandbox、Grok提携：Databricks公式

  • Omnigent：オープンソース版はAlpha。管理版は発表済みだが、公式ブログ上で明確なGA・Beta表記は確認できない

  • Managed MCP Servers：Public Preview。外部MCP Services：Beta

  • Databricks提供MCP Services：組み込みService Policyで書き込み操作を遮断。外部MCPはTool選択とPolicyで制御

  • Unity Catalogの1万4000組織、Governance Hub、ABAC、Glossary、Domains、External Lineage、OpenSharing：Databricks公式

  • Unity AI GatewayのHard Spend Cap、Smart Routing、Contextual Service Policies、Agent Trace：Databricks公式

  • Genie OntologyのPageRank型Authority評価、84.5%対52.4%：Databricksの28問による社内評価。第三者ベンチマークではない

  • LakebaseのPostgreSQL互換Serverless Databaseと一般提供：Databricks公式

  • AI Searchは旧Vector Search。旧URL PrefixとScopeも継続利用可能：Databricks公式ドキュメント

  • Panther Labs：買収完了ではなく、2026年6月16日時点の買収合意

  • 2026年2月：評価額1340億ドル、約50億ドル調達、約20億ドルDebt、年間売上ランレート54億ドル、AI売上14億ドル

  • 2026年6月：年間売上ランレート69億ドル、前年同期比80%超。54億ドルとの差15億ドルは実売上差ではなくランレート差

  • AI製品売上ランレート17億ドル超：主要報道

  • 1650億〜1750億ドル評価の追加調達：交渉報道。2026年7月16日時点で完了発表なし

  • IPO時期：2027年上場は正式決定していない

ハッシュタグ

#生成AI
#Databricks
#MosaicAI
#Lakehouse
#AgentBricks
#UnityCatalog
#UnityAIGateway
#Genie
#GenieOntology
#Lakebase
#MLflow
#Omnigent
#Lakewatch
#企業AI
#データ基盤
#AIエージェント
#欧米生成AI2026

いいなと思ったら応援しよう！