Databricksとは？データ/AI基盤の見方と導入論点を整理

Databricksは、データ基盤、アプリ向け Postgres、自然言語 BI、agentic workflow を一つの platform に寄せようとしている会社です。

Databricks を理解するときに先に見るべきなのは、private-company metrics や market rumor ではなく、Lakehouse / Unity Catalog / Lakebase / Genie / Genie Code がそれぞれ誰の仕事をどこまで一枚に寄せるのかです。

本記事では、公式 product page、docs、pricing、release notes、company press release を起点に、導入判断に効く論点から Databricks を整理します。

---

この記事でわかること

1. Databricksとは何か: Lakehouse と Data Intelligence Platform をどう捉えるか
2. 主要 surface: Lakebase / Genie / Genie Code / agent building をどう読み分けるか
3. 課金の見方: pricing page、calculator、予算管理の確認点
4. Snowflakeとの使い分け: analytics 中心か、engineering と AI まで寄せるか
5. historical section の読み方: corporate event や product launch をどこまで現在形で扱うべきか

---

基本情報

---

Lakehouseとは何か——「両方のいいとこ取り」の革命

企業が抱えていた2つの「データ地獄」

2010年代、企業のデータチームは2つの選択を迫られていました。どちらを選んでも、別の地獄が待っていました。

Data Warehouse（Snowflake等）を選ぶと:

高速なSQLクエリが可能。BIツールとの連携も簡単。しかし、構造化データしか扱えない。機械学習には向かない。そして、とにかく高い。

Data Lake（Hadoop等）を選ぶと:

非構造化データも保存可能。機械学習にも使える。コストも安い。しかし、クエリ性能が低い。データ品質の管理が困難。「データ沼」 と呼ばれるほど、混沌としていました。

結果、多くの企業は両方を併用することになります。Data WarehouseとData Lakeを別々に運用し、データを行き来させる。コストは2倍。運用の複雑さも2倍。

Lakehouse——「なぜ両方必要なのか？」への回答

Databricksが提唱したLakehouse（レイクハウス） は、この問いに対する根本的な回答でした。

「Data Warehouseの性能と、Data Lakeの柔軟性を、1つのシステムで実現すればいい」

技術的には、Delta Lakeというストレージレイヤーがこれを可能にしました。

Delta Lakeの3つの革新:

• ACID対応: 銀行システム並みの信頼性をData Lakeに
• スキーマ管理: 「データ沼」を「データ湖」に変える
• タイムトラベル: 過去のデータ状態に自由にアクセス

これは単なる技術的な改善ではありません。データアーキテクチャの哲学の転換でした。

---

Ali Ghodsi：24時間の亡命からDatabricks共同創業へ

5歳の少年が見た「空爆」

1979年、イスラム革命がイランを揺るがしていました。その混乱の中、1977年に生まれたAli Ghodsiは幼少期を過ごします。

両親は医師でした。そして、政治的反体制派でした。

1984年、イラン・イラク戦争の最中。テヘランは空爆にさらされていました。

5歳の少年にとって、それは理解を超えた恐怖でした。

そしてある日、イラン政府から通告が届きます。「24時間以内に国外へ出ろ」。

家族は着の身着のまま、スウェーデンへ亡命しました。

上流階級から下層階級へ——「福祉に頼る生活」

スウェーデンに逃れたGhodsi一家を待っていたのは、過酷な現実でした。

イランで医師だった両親は、スウェーデンで医師免許が認められませんでした。一家は学生寮を転々とし、福祉に頼る生活を強いられます。

ストックホルム郊外のBagarmossen（バーガモッセン）で育ったGhodsi。そこには常に「我々と彼ら」という感覚がありました。

しかし、その疎外感が、彼を駆り立てました。

「分散システム」への執着——難民経験からの学び

Ghodsiはコンピュータサイエンスに没頭しました。KTH Royal Institute of Technology（スウェーデン王立工科大学）で博士号を取得。専門は分散システム——複数のコンピュータを協調させる技術です。

なぜ分散システムだったのか？

24時間で祖国を追われた経験。すべてを失った経験。それが、「分散して冗長性を持つ」という技術哲学に昇華されていたのです。

UCバークレーでの運命的な出会い

2009年、GhodsiはUCバークレーのAMPLabに客員研究員として参加します。

そこで彼は、後にDatabricksを共同創業する6人の研究者と出会いました。中でもMatei Zahariaは、Apache Sparkの主要開発者でした。

Sparkは革命的でした。Hadoopの100倍高速なデータ処理。しかし、企業での導入は進みませんでした。

「Berkeleyのヒッピー」と呼ばれて

2009年から2012年まで、AMPLabチームはSparkを企業に売り込みました。結果は、完全な無視。

しかし、Ghodsiは諦めませんでした。誰も採用しないなら、自分たちで会社を作るしかない。

「絶望からの起業」——2013年、7人はDatabricksを創業します。

オープンソースへのコミットメント——「信頼ゼロ」からの教訓

Databricksの戦略で特筆すべきは、オープンソースへの徹底したコミットメントです。

Apache Spark、Delta Lake、MLflow——Databricksの中核技術はすべてオープンソース。競合も使える。なぜ、そんなことをするのか？

難民として「信頼ゼロ」からスタートした経験。自分を証明しなければならないという切迫感。それが、「まず与える」というオープンソース戦略に繋がっていたのです。

Ghodsiが語る「次の賭け」

Ghodsi の最近のメッセージを読むと、Databricks が次に広げたいのは 3 つの面です。

1. アプリ向けデータベース: Lakebase で Lakehouse の外に置かれがちだった OLTP を取り込む
2. 自然言語の業務面: Genie で business user がデータを扱う入口を広げる
3. agentic workflow: Genie Code や agent building surface で multi-step task を platform 内に残す

ここで重要なのは、会社の目標値そのものよりも、analytics platform から data-and-AI operating layer へ広げたいという投資順序です。直近の company press release でも、資金の使い道は Lakebase、Genie、AI research、strategic acquisition、employee liquidity に置かれていました。

---

プロダクトの見方——Lakehouse / database / BI / agentic tooling

主要 surface をどう切り分けるか

Databricks の product map は変化が速いため、keynote で聞いた名称より docs 上の現在名を優先して読む方が安全です。

Lakebase——OLTP を Lakehouse 側へ寄せる試み

Lakebase は Databricks が database layer を自社 platform に取り込むための surface です。公式 release notes を追うと、次のように段階的に広がっています。

• 2025年6月の AWS release notes では、Lakebase は managed PostgreSQL OLTP database として Public Preview
• 2026年1月の AWS release notes では、Lakebase が GA になり、Autoscaling と Provisioned が単一 UI に統合
• 2026年3月の docs では、新規 instance が Autoscaling project として順次作られ、既存 Provisioned instance はそのまま維持される

公式 product page と docs から読み取れる Lakebase の特徴は次の通りです。

重要なのは、「もう使えるらしい」ではなく、自分の workspace でどの Lakebase surface が有効かを docs と admin 権限で確認することです。

Genie / Genie Code / Knowledge Assistant——agentic surface は名前ごとに用途が違う

この周辺は naming change が特に速い領域です。2026年3月の release notes では、Databricks Assistant が Genie Code に改名され、Agent Bricks page は Databricks AI capabilities 全体を束ねる umbrella page に拡張されたと案内されています。

そのため、本稿では docs 上の現行 surface 名で整理します。

いま Databricks を見るなら、「Agent Bricks という単独 product がある」と理解するより、Genie spaces、Genie Code、Knowledge Assistant のような複数 surface に agentic capability が散っていると捉える方が実態に近いです。

historical section：MosaicML / Tabular / DBRX は「その時点の勝負どころ」として読む

• MosaicML買収: Databricks が AI 開発面を強化する転換点。現行 docs では Mosaic AI や model serving の文脈で吸収されている
• Tabular買収: Delta Lake だけでなく Iceberg 文脈でも主導権を取りにいくシグナル
• DBRX公開: 研究・モデル戦略のスナップショット。古い benchmark 表をそのまま現行モデル選定に使うのは危険

DBRX のような model release は、当時の product strategy を読む資料としては有用ですが、現時点の best model を決める資料にはしない方がよいです。モデル選定は current docs、hosted-model availability、自前 evaluation に寄せてください。

---

価格の見方——DBU表より pricing 導線を確認する

公式 pricing page で Databricks がまず示しているのは、次の 3 点です。

1. Pay as you go: upfront cost なし、per-second granularity で使った分だけ課金
2. Committed Use Contracts: usage commitment に応じた割引
3. Cloud 別 price list: SKU group と list price を cloud ごとに確認する

加えて、公式 page では Azure Databricks の pricing は Microsoft 側が設定すると明記されています。つまり、古い blog post の DBU 単価表だけを見ても、今の見積もりにはなりません。

実務では、Databricks の月額は大きく次の束に分かれます。

• platform service: SQL、jobs、model serving、Lakebase、AI/BI などの surface 利用
• cloud infra: storage、network、serverless / compute、GPU
• data movement: sync、egress、external source 連携
• operational mistakes: idle resource、oversized warehouse、unbounded experiment

先に決めるべきコスト管理の質問

1. どの workload を serverless に寄せ、どれを classic / dedicated で管理するか
2. 予算監視を account / workspace / project のどこで持つか
3. Lakebase、model serving、vector search、AI/BI のどの surface を本番対象にするか
4. usage dashboard と budget policy を誰が見るか

---

Snowflakeとの使い分け——設計思想で分ける

Databricks と Snowflake はしばしば同じ box に入れられますが、導入判断では「どちらが勝ちか」よりも中心 workload が何かで切り分ける方が有効です。

Databricks が向いているケース

• Spark / Python / MLflow / Unity Catalog を中心に据える
• analytics と app / agent state を近づけたい
• 非構造化データ、ETL、feature store、model serving を同じ governance に寄せたい
• engineering team が権限、cost、pipeline を明示的に設計できる

Snowflake が向いているケース

• BI と SQL analytics が主役
• data engineer より analyst / business user の比重が高い
• warehouse experience のシンプルさを優先したい
• application database は別 stack に置いて問題ない

両社を併用する企業も多いですが、比率や優位性の数字は時期によって変わります。ワークロードの中心を見て選ぶのが一番ぶれません。

---

企業スナップショットは dated note として読む

private company の指標は、上場企業の四半期決算のように読むと誤解しやすいです。Databricks の company snapshot は、その時点のメッセージと投資の方向を読む材料として扱うのが適切です。

2026年2月9日の company press release では、Databricks は次の数字を掲げていました。

• $5.4B revenue run-rate 超、前年比 65% 超成長
• $7B 超の資金調達枠（約 $5B equity at $134B valuation と約 $2B の debt capacity）
• AI products の $1.4B revenue run-rate 超
• 20,000 以上の組織と Fortune 500 の 60% 超

これらは、Databricks が「analytics company」よりも data + AI company として自己定義していることを示す数字です。一方で、監査済み quarterly filing ではないため、vendor-stated snapshot として扱う方が安全です。

歴史を見るなら、この 4 点で十分

1. 2013年創業: Spark 商用化から出発
2. Delta Lake / Unity Catalog: lakehouse と governance の中核を整備
3. MosaicML / Tabular: AI と open table format を広げる買収
4. 2026年の資金調達: Lakebase、Genie、AI research に資金を振る意思表示

---

導入事例をどう読むか

Comcast——「使える platform か」を見る

Databricks の Comcast customer story は、単なる logo list ではなく、compute footprint と開発運用の負荷をどう減らしたかに焦点があります。こうした事例を見るときは、次の順で読むと有効です。

1. どの data source を統合したのか
2. Lakehouse / SQL / ML のどこを使ったのか
3. 既存基盤より何の運用が減ったのか

Shell——グローバル data 統合と運用系 AI

Shell の story は、散らばった operational data を統合し、AI/ML を現場寄りのユースケースへ載せる例として読むとよいです。Databricks の強みは、データ統合だけでなく、その後の ML / app / dashboard まで同じ platform の文脈で話せることにあります。

日本企業の検討では event list より prerequisite を見る

イベント登壇社名や partner award は参考になりますが、それだけで導入難易度は分かりません。日本で重要なのは、次の prerequisite です。

• 利用 cloud と region で必要な surface が出ているか
• Unity Catalog と権限設計が先にできるか
• serverless 予算管理と data residency 要件を満たせるか
• partner に任せる範囲と内製する範囲を切り分けられるか

---

注意点と限界

1. cost governance は platform の外ではなく中で起きる

Databricks の bill は compute だけではありません。Lakebase、model serving、AI/BI、connector、serverless など surface ごとに費用構造が違うため、導入初期から budget owner を置く必要があります。

2. surface 名と availability が速く変わる

Agent Bricks、Knowledge Assistant、Genie Code のように、名称も UI も短期間で変わります。release notes と docs を追わずに「去年の説明資料」で導入判断するとズレやすいです。

3. workspace / region 差分が大きい

Lakebase rollout、Knowledge Assistant の supported region、partner-powered AI の in-country routing は一律ではありません。global product page を読んだだけで判断しない方が安全です。

4. SQL-only の BI team には重いことがある

Databricks は強力ですが、その分 Unity Catalog、Spark、pipeline、cost の設計が必要です。analytics だけを最短で回したい team には、より狭い warehouse product の方が合う場合があります。

5. vendor narrative と benchmark を分ける

Databricks も競合も、自社に有利な benchmark や比較資料を出します。実運用で見るべきなのは、自社 data、team skill、governance、budget で回るかどうかです。

---

今後を見る論点

IPO時期を当てるより、公開シグナルを見る

Databricks の IPO 時期を blog が断定的に予想しても、実務上の価値は高くありません。見るべきシグナルは次の 3 つです。

1. public filing の有無
2. Lakebase / Genie / Genie Code の release notes
3. 資金の使い道に関する company message

今回参照した official materials では、Databricks は private 資金を Lakebase、Genie、AI research、strategic acquisition、employee liquidity に振ると説明していました。つまり、当面は product expansion と optionality の確保 が主目的で、公開市場入りの時期自体は management choice に残していると読むのが自然です。

---

日本で検討するときの確認点

1. region と cloud を先に固定する

Lakebase、Knowledge Assistant、Genie Code の agentic capability は cloud と region で差があります。日本拠点で使う場合でも、workspace をどの cloud / region に置くかで選べる surface が変わります。

2. data residency は feature ごとに確認する

2026年3月の AWS release notes では、日本を含む一部の国で、Genie Code chat / cell actions、Genie、AI-generated comments、AI/BI dashboards に対して in-country routing が案内されました。一方で、すべての AI capability が同じ条件で使えるわけではありません。

3. docs の日本語化と運用の現実を分ける

Databricks docs site 自体は日本語ナビゲーションを提供していますが、深い機能説明や notebook / API の実務は英語ドキュメント前提になりやすいです。チーム内で英語 docs を読める運用を用意した方が安全です。

4. Unity Catalog を後回しにしない

Genie、Knowledge Assistant、Lakebase 連携、governance を活かすには Unity Catalog が前提になる場面が多くあります。PoC の段階から catalog、権限、lineage を意識しておかないと、後で platform の強みを出しにくくなります。

---

よくある質問（FAQ）

Q: Databricksとは何ですか？一言で説明すると？

A: Databricks は、Lakehouse を核に analytics、data engineering、AI、application database、自然言語 BI を同じ platform 上で扱おうとする data + AI 企業です。

Q: Databricksの料金はどう見ればよいですか？

A: まず official pricing page で pay-as-you-go、committed use、cloud 別 price list を確認してください。次に calculator と usage dashboard を前提に、自社 workload の budget owner を決めるのが実務的です。

Q: DatabricksとSnowflakeの違いは？

A: Databricks は engineering / ML / agentic workflow まで寄せたいときに強く、Snowflake は SQL analytics をシンプルに回したいときに強い傾向があります。優劣より workload center の違いで選ぶ方が正確です。

Q: Lakebaseとは何ですか？

A: Lakebase は Databricks の Postgres surface です。Lakehouse に近い位置で transactional workload を扱えるのが特徴ですが、workspace ごとに rollout と available feature を確認してください。

Q: Genie と Genie Code は何が違いますか？

A: Genie は主に business user 向けの自然言語 BI、Genie Code は notebooks / SQL / jobs / file editor で使う context-aware assistant です。さらに、documents を元に citation 付き Q&A agent を作る surface として Knowledge Assistant があります。

Q: DatabricksのIPOはいつですか？

A: 本稿で参照した official materials では、Databricks は private funding と product investment を強調しており、public filing の具体時期は示していません。IPO の噂より public filing をシグナルとして見る方が確実です。

Q: 日本で使うときの注意点は？

A: region / data residency / Unity Catalog prerequisite / docs 言語運用の 4 点を先に決めることです。特に AI surface は機能ごとに availability が異なります。

---

関連記事

---

参考リソース

Ali Ghodsiの人生

• Ali Ghodsi: Being an outsider in Sweden gave me the drive to succeed
• Refugee Ali Ghodsi Builds Billion Dollar Empire Brick by Brick
• Databricks CEO Ali Ghodsi says his company will be worth $1 trillion

Databricks公式

• Databricks公式サイト
• Databricks press release: Databricks Grows >65% YoY, Surpasses $5.4 Billion Revenue Run-Rate
• Pricing
• Lakebase
• What is a Genie space
• Use Genie Code
• Use Genie Code for pipeline development
• Use Knowledge Assistant to create a high-quality chatbot over your documents
• January 2026 release notes
• March 2026 release notes
• Autoscaling by default
• Customer Story: Comcast
• Customer Story: Shell

MosaicML・Tabular買収

• Behind the scenes of Databricks' $1.3 billion MosaicML deal
• Databricks acquires Tabular to build a common data lakehouse standard

競合・評価

• Snowflake vs. Databricks | Snowflake公式
• Databricks docs site

---

本記事はネクサフローのAI研究シリーズの一部です。