見出し画像

Databricks Data + AI Summit 2026を読む

香川友志

AGIは来ている。だが、企業ではまだ働いていない

Databricksが描く「コンテキストOS」の正体

はじめに

「AGIはもう来ている」

Databricks CEOのAli Ghodsi氏は、Data + AI Summit 2026の基調講演でそう語りました。

しかし、今回の本質は「AGIが来たかどうか」という抽象論ではありません。

本当に重要なのは、次の問いです。

なぜ、これほど賢いAIが登場しているのに、企業の仕事はまだ大きく変わっていないのか。

GPT、Claude、Gemini、DeepSeek、Qwen。

モデル性能競争は続いています。

しかし企業の現場で起きている本当の問題は、もはやモデルの賢さだけではありません。

企業固有の文脈、つまりContextを、どうAIに渡すのか。
そして、そのContextをどう安全に貯め、管理し、更新し続けるのか。

Databricksは今回、その答えとして、

「コンテキストOS」

とも呼べるアーキテクチャを提示しました。

本記事では、Data + AI Summit 2026で発表された内容を整理しながら、

  • Databricksは何を発表したのか

  • なぜ「Context」が企業AIの中核になるのか

  • そのContextはどう貯め、どう管理するのか

  • Genie Ontology、Unity Catalog、AI Gateway、Lakebaseは何を担うのか

  • 日本企業はここから何を学ぶべきか

を解説します。

目次

  1. Data + AI Summit 2026とは何のイベントか

  2. そもそもDatabricksとは

  3. 誰が登壇したのか

  4. 今年のキーメッセージ

  5. なぜ企業ではAIがまだ働けないのか

  6. Genie One

  7. Genie Agents

  8. Genie Ontology

  9. コンテキストとは何か

  10. コンテキストはどう貯めるのか

  11. コンテキストはどう管理するのか

  12. Lakebase / LTAP

  13. Lakehouse//RT

  14. Genie Code / Agent Bricks

  15. CustomerLake

  16. Databricksは何を狙っているのか

  17. これはAI業務OSの話である

  18. Physical AIとの共通点

  19. 日本企業への示唆

  20. 企業はAIモデルを買うだけでは勝てない

  21. Databricks発表の冷静な見方

  22. まとめ

  23. おわりに

この記事の結論

今回のData + AI Summit 2026は、単なるDatabricksの新製品発表会ではありませんでした。

一言で言えば、

AI競争の中心が「モデル」から「企業コンテキスト」へ移ったことを示すイベント

です。

モデルは買えます。
GPUも買えます。
クラウドも借りられます。

しかし、自社の業務知識、判断基準、顧客理解、現場の例外処理、失敗履歴は買えません。

これからの企業AI競争は、

誰が一番深く、自社の文脈をAIに渡せるか

で決まります。

Databricksは、その「企業の記憶」を貯め、管理し、AIエージェントに安全に渡す基盤を作ろうとしている。

これが今回のイベントの本質です。

Databricksの年次イベント「Data + AI Summit 2026」が、2026年6月15日から18日まで、米サンフランシスコのMoscone Centerで開催されました。

Data + AI Summitは、Databricksが主催するデータ、分析、AI領域の大型カンファレンスです。2026年は3万人以上の参加者がサンフランシスコに集まると発表され、公式サイトでは160カ国以上のデータ・AIコミュニティを対象にした世界最大級のデータ・AIイベントとして位置づけられています。

今年のテーマは、単なるLLMの性能競争ではありませんでした。

むしろ、今年のDatabricksが強く打ち出したのは、

「AGIはもう来ている。だが、仕事ではまだ来ていない」

という見方です。

Databricksの共同創業者兼CEOであるAli Ghodsi氏は、基調講演で「AGIはすでにここにある。我々はそう考えている」と述べました。

そのうえで、彼の主張はこうです。

AIはもはや知能の問題を抱えているわけではない。すでに十分に賢い。問題は、その賢さがまだ組織の仕事の中に入っていないことだ。

報道では、この日の講演の論点は「AIには知能の問題ではなく、コンテキストの問題がある」と要約されています。

これは非常に重要な指摘です。

ここ数年、私たちはGPT、Claude、Gemini、Llama、DeepSeek、Qwenなど、モデルの進化ばかりを追いかけてきました。

もちろん、モデルの進化は今後も続きます。

しかし企業の現場で見ると、すでに問題は「モデルが賢くないこと」ではなくなりつつあります。

問題は、賢いモデルに、

  • 自社のデータ

  • 自社の業務ルール

  • 自社のKPI定義

  • 自社の顧客理解

  • 自社の権限体系

  • 自社の過去の判断

  • 自社の失敗と改善履歴

をどう渡すかです。

つまり、勝負は「モデル」から「コンテキスト」へ移っています。

そして今回のData + AI Summit 2026は、Databricksがこの企業コンテキストの中核を取りに来たイベントだった、と見るべきです。

各章の要点

  • 第1章〜第2章：Data + AI Summit 2026の位置づけと、Databricksという会社の背景を整理します。

  • 第3章〜第4章：Ali Ghodsi氏の「AGIは来ているが、仕事ではまだ来ていない」というメッセージを読み解きます。

  • 第5章〜第7章：Genie One、Genie Agents、Genie Ontologyという今回の中核発表を整理します。

  • 第8章〜第10章：企業コンテキストとは何か、どう貯めるのか、どう管理するのかを詳しく解説します。

  • 第11章〜第14章：Lakebase、LTAP、Lakehouse//RT、Genie Code、Agent Bricks、CustomerLakeの役割を整理します。

  • 第15章〜第21章：Databricksの狙い、日本企業への示唆、Physical AIとの共通点、コンテキスト資本主義への移行を考えます。

1. Data + AI Summit 2026とは何のイベントか

Data + AI Summitは、Databricksが毎年開催するデータ・AI領域の大型イベントです。

Databricksは、Apache Spark、Delta Lake、MLflowなどのオープンソース技術を背景に、データレイクとデータウェアハウスを統合する「Lakehouse」という考え方を広めてきた企業です。

そもそもDatabricksとは

ここで、Databricksという会社そのものを簡単に整理しておきます。

Databricksは2013年に創業した、米サンフランシスコ拠点のソフトウェア企業です。

創業者は7人。

Ali Ghodsi、Ion Stoica、Matei Zaharia、Patrick Wendell、Reynold Xin、Andy Konwinski、Arsalan Tavakoli-Shirajiです。

いずれも、カリフォルニア大学バークレー校の研究室「AMPLab」で、オープンソースの分散処理エンジンApache Sparkを生んだ研究者たちです。

Sparkは、2009年にMatei Zaharia氏が中心となって開発しました。

大量のデータをメモリ上で高速に処理する仕組みで、当時主流だったHadoop MapReduceの限界を超えるものでした。

この技術を商用化するために生まれたのがDatabricksです。

経営体制にも触れておきます。

初代CEOはIon Stoica氏で、2016年からはAli Ghodsi氏がCEOを務めています。

Stoica氏は現在エグゼクティブ・チェアマン、Zaharia氏はCTO、Xin氏はチーフアーキテクトとして、創業者が今も経営の中心にいます。

では、何をしている会社か。

一言でいえば、データとAIを一つの基盤で扱うクラウドプラットフォームを提供する会社です。

中心にあるのが「レイクハウス（Lakehouse）」という考え方です。

整ったデータを扱うデータウェアハウスと、雑多なデータをためるデータレイク。

この二つを一つに統合する設計思想です。

その上で、データエンジニアリング、分析、機械学習、そしてAIエージェントまでを動かせるようにしています。

支えているのは、自社が主導するオープンソース技術です。

Apache Sparkに加え、データレイクに信頼性を与えるDelta Lake、機械学習の開発・運用を管理するMLflow、データとAI資産を統制するUnity Catalogなどがあります。

動作環境は、AWS、Microsoft Azure、Google Cloudの主要3クラウドにまたがります。

近年は、買収したMosaicMLの技術を取り込み、生成AIまで含む「Data Intelligence Platform」へと進化しました。

さらに今では、OpenAI、Anthropic、Google Geminiといった基盤モデルを、自社の安全な領域の中から呼び出せるAIインフラ事業者でもあります。

顧客基盤も大きい。

世界で2万を超える組織が利用し、Fortune 500企業の約70%が使っているとされています。

主な競合は、Snowflakeなどのデータプラットフォーム企業です。

つまりDatabricksは、「Sparkを生んだ研究者たちが作った、データとAIの統合基盤の会社」です。

この背景を押さえると、今回のSummitで企業コンテキストを取りに来た意味が、より分かりやすくなります。

もともとは、データエンジニア、データサイエンティスト、MLエンジニア、アナリスト向けの色が強いイベントでした。

しかし2026年のイベントでは、かなり性格が変わっています。

もはや単なるデータ基盤のイベントではありません。

今年は、企業の中でAIエージェントを本番運用するための総合イベントになっています。

公式発表では、800以上のブレイクアウトセッション、25以上のハンズオン研修・認定コース、OpenAIとの共同ハッカソン、Anthropic、Cognition、CrewAI、Glean、LangChain、LlamaIndex、Lovable、OpenAI、ReplitなどのAI企業によるセッションも予定されていました。

つまり、Databricksは「データ基盤企業」から、「企業AIエージェント基盤企業」へと自社の位置づけを広げようとしています。

2. 誰が登壇したのか

公式発表で名前が出ていた主な登壇者は以下です。

Databricks側

  • Ali Ghodsi
    Databricks共同創業者兼CEO

  • Matei Zaharia
    Databricks共同創業者。Apache Spark、MLflowなどに関わる中心人物

  • Arsalan Tavakoli-Shiraji
    Databricks共同創業者

  • Reynold Xin
    Databricks共同創業者。Spark SQL、Databricks Runtimeなどに深く関わる人物

Databricks側の登壇は、単なる企業説明ではなく、創業者たちが直接、Databricksの次のアーキテクチャを説明する場になっていました。

ゲスト登壇者

  • Satya Nadella
    Microsoft会長兼CEO。事前収録のfireside chatとして登壇

  • Greg Brockman
    OpenAI共同創業者、President兼Chairman

  • Magesh Bagavathi
    PepsiCo Global Chief Data and AI Officer

この登壇者構成が意味しているのは明確です。

Databricksは、OpenAIやMicrosoftと競合するというより、企業の中でそれらのAIを安全に使うための「データとガバナンスの土台」を押さえようとしています。

Microsoftは業務アプリの入口を持っています。
OpenAIはAIモデルとエージェント体験を持っています。
Databricksは、その背後にある企業データとコンテキストを握ろうとしている。

この三者の関係を見ると、AI時代の企業システムの構図がかなり見えてきます。

3. 今年のキーメッセージ

AGIは来ている。ただ、仕事ではまだ来ていない

今回のイベントで最も象徴的だったのが、Ali Ghodsi氏のメッセージです。

AGIはすでにここにある。
しかし、それはまだ企業の仕事の中には入っていない。

これは「AGI」という言葉の定義次第で賛否が分かれる表現です。

OpenAIやDeepMindが語るような、あらゆる領域で人間を超える超知能という意味なら、まだ来ていないという人も多いでしょう。

しかしDatabricksが言いたいのは、そこではありません。

Databricksの主張は、

現在のAIモデルは、企業の多くの知的作業を支援・自動化するには、すでに十分に賢い。

ということです。

足りないのは知能ではない。

足りないのは、企業の中でAIを働かせるための以下の4つです。

  • Context
    会社の文脈

  • Cost
    トークンコスト、推論コスト、運用コスト

  • Control
    権限、監査、実行制御、リスク管理

  • Choice
    モデル選択の自由、ベンダーロックイン回避

この4つが揃わない限り、AIは「賢いチャットボット」から「企業で働くAI社員」にはなれません。

4. なぜ企業ではAIがまだ働けないのか

多くの企業は、すでにChatGPTやClaudeを試しています。

議事録作成、文章要約、メール文作成、アイデア出し、簡単なコード生成、調査補助。

このレベルでは、AIはかなり使えます。

しかし、企業の中核業務に入ろうとすると急に難しくなります。

なぜか。

理由は明確です。

AIはその会社のことを知らないからです。

たとえば、営業部門でAIにこう聞いたとします。

「今月、なぜ西日本エリアの粗利率が下がったのか？」

この質問に正しく答えるには、単に売上データだけでは足りません。

必要なのは、

  • 商品別の粗利率

  • 顧客別の取引条件

  • キャンペーン施策

  • 返品・値引きの扱い

  • 物流費の変動

  • 営業担当者のメモ

  • 競合状況

  • 過去の類似事例

  • 社内で使っている粗利の定義

  • どのダッシュボードが正式なのか

です。

一般的なLLMは、この会社固有の前提を知りません。

そして知らない部分を、もっともらしく推測してしまいます。

これが幻覚です。

企業AIにおける幻覚は、単にモデルが間違うから起きるのではありません。

多くの場合、AIに渡すべき文脈が不足しているから起きます。

Databricksが今回強調しているのは、まさにここです。

5. 発表① Genie One

ビジネス部門向けAIコワーカー

今年の大きな発表の一つが「Genie One」です。

Genie Oneは、Databricksが発表したビジネスユーザー向けのAIコワーカーです。

従来のDatabricks Genieは、会話型の分析アシスタントに近い存在でした。
つまり、データに質問し、自然言語で答えを得るための仕組みです。

しかしGenie Oneは、それを大きく拡張しています。

Genie Oneは、マーケティング、営業、財務、経営企画などのビジネス部門が、自社データに基づいて質問し、洞察を得て、さらに次の業務アクションへ進めるためのAIです。

Databricksの説明では、Genie OneはSlack、Microsoft Teams、モバイルアプリ、MCP対応アシスタント体験、Gmail、Teamsなどと接続し、データから洞察を出すだけでなく、業務ツールをまたいでアクションを実行できる方向に進んでいます。

これはかなり重要です。

AIの企業導入は、これまで「知りたいことを聞く」段階でした。

しかしこれからは、

「調べる」
「判断する」
「資料を作る」
「関係者に通知する」
「次の作業を予約する」
「システムに書き込む」

までが一つの流れになります。

Genie Oneは、この流れをDatabricksのデータ基盤上で実現しようとするものです。

なお提供形態について。

Databricksの案内では、Genie One、Genie Agents、Genie Codeは今回いずれも正式提供（GA）になりました。

後述するGenie App BuilderとGenie ZeroOpsは、Summit直後にプライベートプレビューへ入る予定とされています。

課金は座席ベースではありません。

1ユーザーあたり毎月最大10ドル分の無料利用枠が付与され、実際に使った分だけ支払う従量モデルです。日本円換算は為替で変動するため、本文ではドル表記に留めます。

6. 発表② Genie Agents

プロンプトから業務エージェントを作る

Genie Agentsは、特定業務に特化したAIエージェントを作る仕組みです。

Databricksは、Genie Agentsを「一つのプロンプトから、自律的なエージェントを作る仕組み」と説明しています。

特徴は、構造化データと非構造化データの両方を扱えることです。

構造化データとは、テーブル、データベース、売上データ、在庫データなどです。

非構造化データとは、ドキュメント、PDF、議事録、チャット、メール、チケット、社内Wikiなどです。

企業の業務は、実際にはこの両方で成り立っています。

営業担当者は、CRMの数値だけで判断しているわけではありません。
顧客とのメール、商談メモ、提案書、過去のトラブル、競合情報も見ています。

財務部門も、会計データだけでなく、契約書、稟議書、経営会議資料、予算方針を見ています。

Genie Agentsは、こうした複数の情報源をまたいで、業務に特化したエージェントを作るための仕組みです。

ここで大事なのは、AIエージェントが単なるチャットではなくなることです。

エージェントは、スケジュール実行、文書作成、MCPツール実行、外部システムへの書き込みまで行う可能性があります。

だからこそ、次に説明するガバナンスが重要になります。

ここで合わせて触れておきたいのが、同時に発表されたGenie App Builderです。

これは、Genie Agentsの上に業務アプリを作るための、ローコード／自然言語ベースのアプリ生成環境です。

Databricksはこれを、ビジネスアプリを自然言語で素早く組み立てる体験として打ち出しています。

自然言語でやりたいことを説明すると、Lakehouseのデータに基づいたアプリが生成される。

実行基盤はDatabricks Appsで、認証や権限、接続情報は自動的に扱われます。

エージェントを作るGenie Agentsと、その上にアプリを組むGenie App Builder。

いずれもUnity Catalogのガバナンス下に置かれる、という点が共通しています。

7. 発表③ Genie Ontology

企業コンテキストを貯める中核

今回、最も重要な発表が「Genie Ontology」です。

DatabricksはGenie Ontologyを、企業の文脈を自動で蓄積する「living context graph」と説明しています。

日本語で言えば、

企業の業務知識を蓄積する、生きたコンテキストグラフ

です。

これは単なるRAGではありません。

RAGは、検索して関連文書をLLMに渡す仕組みです。

しかしGenie Ontologyが目指しているのは、もっと深いものです。

企業内にある、

  • テーブル

  • クエリ

  • ダッシュボード

  • データパイプライン

  • 業務アプリ

  • 文書

  • Wiki

  • チケット

  • チャット

  • メール

などから、業務概念と関係性を抽出し、企業の知識グラフとして整理する。

そして、AIエージェントが質問やタスクに答えるときに、

「どこを見るべきか」
「何を信頼すべきか」
「どの定義が正しいか」
「誰に見せてよいか」
「どの情報は古いか」
「どの行動は許可されるか」

を判断できるようにする。

ここが、今回のイベントの核心です。

8. コンテキストとは何か

ここでいう「コンテキスト」は、単なる長いプロンプトではありません。

企業AIにおけるコンテキストとは、

会社の業務知識、データ定義、判断基準、権限、関係性、履歴を、AIが使える形にしたもの

です。

具体的には以下です。

1. 業務用語

「売上」とは何か。
「粗利」とは何か。
「有効顧客」とは何か。
「解約」とは何か。
「在庫」とは何か。
「リード」とは何か。

同じ言葉でも、会社や部門によって定義が違います。

2. KPI定義

月次売上は受注ベースなのか、出荷ベースなのか、請求ベースなのか。
返品は控除するのか。
税抜か税込か。
キャンセルはいつ反映するのか。

この定義が曖昧なままAIに聞くと、AIは間違います。

3. データの所在

どのテーブルに何が入っているのか。
どのカラムが正式なのか。
どのダッシュボードを見るべきなのか。
どのデータは古いのか。

4. 業務ルール

どの顧客には特別条件があるのか。
どの仕入先は例外処理が必要なのか。
どの工程では人間の承認が必要なのか。
どの金額以上は自動処理してはいけないのか。

5. 権限

誰がどのデータを見てよいのか。
誰が書き込みできるのか。
AIエージェントがどのツールを実行できるのか。
どの外部モデルにデータを送ってよいのか。

6. 判断履歴

過去にどんな判断をしたのか。
なぜその判断をしたのか。
どんな失敗があったのか。
どの改善策が有効だったのか。

つまりコンテキストとは、会社の脳内地図です。

9. コンテキストはどう貯めるのか

では、Databricksはこのコンテキストをどう貯めようとしているのでしょうか。

ここが今回の記事の一番重要な部分です。

Databricksの答えは、

人間がゼロから手入力するのではなく、企業活動の痕跡から自動的に貯める

というものです。

これは非常に現実的です。

多くの企業では、業務知識をきれいに整理する余裕がありません。

社内Wikiは古い。
業務マニュアルは更新されていない。
KPI定義は人によって違う。
SQLを書いた人しか意味が分からない。
ダッシュボードは増えすぎて、どれが正しいか分からない。

この状態で「AI用に全部ドキュメント化しましょう」と言っても、ほとんどの企業はできません。

Databricksは、すでに企業内に存在するデータ利用の痕跡から、コンテキストを自動抽出しようとしています。

9-1. Unity Catalogから貯める

まず基礎になるのがUnity Catalogです。

Unity Catalogは、Databricksのデータ・AI資産のガバナンス層です。

ここでは、

  • テーブル

  • カラム

  • ビュー

  • モデル

  • ファイル

  • 権限

  • リネージ

  • 利用履歴

などを管理します。

企業コンテキストを作るには、まず「どんなデータ資産があるのか」を把握しなければなりません。

どのテーブルがどこから来ているのか。
どのパイプラインで作られたのか。
誰が使っているのか。
どのカラムがよく参照されているのか。
どのデータが正式なものなのか。

Unity Catalogは、この基礎台帳になります。

Databricksは2026年のUnity Catalogアップデートで、AI資産やアプリケーションまで含めた共有・ガバナンスを強化しています。特にGenie Sharingにより、Genie Agentsを組織間で共有する方向も示されています。

つまりUnity Catalogは、単なるデータカタログではなく、AIエージェント時代の企業資産カタログへ進化しています。

今回はもう一つ、OpenSharingという発表もありました。

これは、データだけでなくAI資産まで安全に共有するための、オープンなプロトコルです。

Delta Sharingの後継にあたり、エージェントのスキル、AIモデル、非構造化データの共有まで対象にしています。

Linux Foundationのプロジェクトとして提供され、エージェントスキル、AIモデル、非構造化データを組織やプラットフォームをまたいで安全に共有するための標準として案内されています。MCPやA2Aのようなエージェント接続標準とは競合というより補完関係に近く、OpenSharingは「共有・流通」のレイヤーを担うものと見ると分かりやすいです。

コンテキストやエージェントを、組織や企業をまたいで安全にやり取りする。

その土台を、特定ベンダーに閉じない形で作ろうとしている、という位置づけです。

9-2. SQLとダッシュボードから貯める

企業の業務知識は、実はSQLやダッシュボードの中に大量に埋まっています。

たとえば、ある会社の「月次売上」という指標は、社内Wikiではなく、BIダッシュボードのSQLにしか正確な定義が書かれていないことがあります。

実際の現場では、

「この数字は山田さんが作ったダッシュボードを見ればいい」
「経営会議ではこのSQLの定義を使っている」
「営業部は別の定義で見ている」
「古いダッシュボードはまだ残っているが、もう使っていない」

ということがよくあります。

Genie Ontologyは、テーブル、クエリ、ダッシュボード、パイプラインから知識の断片を抽出します。

つまり、

  • どのKPIがどのSQLで計算されているか

  • どのダッシュボードがよく使われているか

  • どのデータが経営判断に使われているか

  • どの指標がどの部署で重要なのか

を学習していく。

ここが非常に大きい。

AIに正しい答えを出させるには、単にデータを検索するだけでは足りません。

「会社で実際に使われている定義」を理解する必要があります。

ここに直接効くのが、Unity Catalog上のMetrics／Metric Viewsです。

Metricsは、

売上、解約率、アクティブユーザー、利益率といったKPIを、一度だけガバナンスされた再利用可能なオブジェクトとして定義する仕組みです。

そして、その定義をSQL、ダッシュボード、BIツール、API、エージェントから一貫して呼び出せるようにします。

つまり「正式なKPI定義」をプラットフォーム側に持たせる仕組みです。

これはこの記事の文脈そのものです。

KPI定義がバラバラだとAIは間違える。

だから定義を一カ所に固定する。

そういう発想です。

9-3. パイプラインとリネージから貯める

データの意味は、データそのものだけでは分かりません。

どこから来たのか。
どう変換されたのか。
どの処理を経て、最終的なテーブルになったのか。

これが分からなければ、AIはデータの信頼性を判断できません。

たとえば、売上テーブルに異常値があったとします。

その原因は、営業入力のミスかもしれません。
ETLパイプラインの失敗かもしれません。
上流システムの仕様変更かもしれません。
為替レートの取り込み失敗かもしれません。

このとき、AIエージェントが原因を調べるには、データリネージが必要です。

Genie ZeroOpsは、このリネージを使って、パイプライン、ジョブ、テーブル、MLモデルを監視し、異常の原因分析や修正提案を行う方向を示しています。

つまり、コンテキストは「業務知識」だけではありません。

データがどう作られ、どう壊れ、どう修復されるかという運用知識もコンテキストです。

9-4. ドキュメント、チャット、メールから貯める

企業の文脈は、データベースの中だけにはありません。

むしろ重要な文脈は、以下のような場所にあります。

  • SharePoint

  • Google Drive

  • Slack

  • Microsoft Teams

  • Gmail

  • 社内Wiki

  • PDF

  • 議事録

  • チケット管理システム

  • 顧客とのやり取り

DatabricksはGenie Oneで、Gmail、Slack、Teamsなどの業務ツールとの接続を示しています。

これは、AIが企業データだけでなく、業務の会話や文書まで文脈として扱う方向に進んでいることを意味します。

たとえば営業会議で、

「A社は値引きではなく納期対応が重要」
「B社は前回トラブルがあったため、提案前に品質保証部の確認が必要」
「C社は来期予算が遅れている」

という会話があったとします。

この情報は、データベースには入りません。

しかし営業判断には極めて重要です。

AIが企業で働くには、このような非構造化の文脈も必要になります。

9-5. 利用頻度と権威で重みづけする

コンテキストを集めるだけでは不十分です。

企業内には、矛盾した情報が大量にあります。

同じ「売上」でも、営業部、経理部、経営企画部で定義が違うことがあります。
同じ顧客情報でも、CRM、Excel、メール、営業メモで内容が違うことがあります。
同じKPIでも、古いダッシュボードと新しいダッシュボードが共存していることがあります。

AIがこれらを全部同じ重みで扱うと、間違えます。

そこでGenie Ontologyは、情報源の権威を評価します。

Databricksは、PageRankに似た考え方で、

  • その定義はどこから来たのか

  • 作成者は誰か

  • どれだけ使われているか

  • 認証済み資産とどれだけ結びついているか

  • 情報は新しいか

  • どの部署が利用しているか

を見て、信頼できる情報を重みづけすると説明しています。

これは企業AIにおいて非常に重要です。

なぜなら、AIにとって一番難しいのは「情報を探すこと」ではなく、「どの情報を信じるか」だからです。

10. コンテキストはどう管理するのか

次に、貯めたコンテキストをどう管理するのか。

ここでDatabricksが重視しているのが、

  • Unity Catalog

  • Unity AI Gateway

  • ソースネイティブACL

  • MCP管理

  • コスト管理

  • 監査ログ

  • ZeroOps

です。

10-1. Unity Catalogで管理する

Unity Catalogは、コンテキスト管理の土台です。

ここでデータ資産、AI資産、権限、リネージを一元管理します。

AIエージェントがデータを読むとき、誰でも何でも読めるわけではありません。

人事情報、財務情報、契約情報、顧客個人情報、医療情報などは、権限管理が不可欠です。

Genie Oneでは、回答ごとにソース側のACLまたはUnity Catalogの権限が適用されると説明されています。

つまり、AIが社内データを使う場合でも、

「その人が見てよい情報だけを使う」

という原則が適用されます。

ここがなければ、企業AIは本番導入できません。

10-2. Unity AI Gatewayで管理する

Unity AI Gatewayは、AI利用の制御層です。

ここでは、

  • どのモデルを使うか

  • どのMCPツールを使わせるか

  • どの外部システムへアクセスさせるか

  • トークン利用量をどう制限するか

  • コスト上限をどう設定するか

  • 実行ログをどう残すか

を管理します。

AIエージェント時代には、ここが非常に重要になります。

なぜなら、AIは単に読むだけではなく、実行するからです。

たとえば、

  • メールを送る

  • チケットを作る

  • 顧客情報を更新する

  • 注文データを書き換える

  • 広告キャンペーンを変更する

  • 在庫発注を行う

こうした処理をAIが行う場合、必ず制御が必要です。

人間でも権限が必要なのに、AIだけ自由に動かしてよいはずがありません。

Unity AI Gatewayは、AIに「何をさせるか」ではなく、「何をさせないか」を決める層です。

10-3. MCPを管理する

今回の発表で重要なのは、MCPへの言及です。

MCPは、AIエージェントが外部ツールやデータソースに接続するための共通インターフェースとして急速に広がっています。

しかし企業利用では、MCPは便利であると同時に危険でもあります。

AIがMCP経由で社内DB、SaaS、ファイル、メール、カレンダー、業務アプリに接続するなら、そこには必ずガバナンスが必要です。

どのMCPサーバーを許可するのか。
どのツールを実行できるのか。
読み取りだけなのか、書き込みも許可するのか。
実行ログはどこに残すのか。
外部モデルにどこまで情報を渡すのか。

Databricksは、MCP、ツール、コストをUnity AI Gatewayで管理する方針を示しています。

これは、AIエージェント本番運用で避けて通れないテーマです。

10-4. コストを管理する

エージェント時代には、トークンコストが問題になります。

人間が1回質問するだけなら、コストは大したことがないかもしれません。

しかしAIエージェントは違います。

エージェントは、

  1. 情報を探す

  2. ツールを呼ぶ

  3. 結果を読む

  4. もう一度考える

  5. 別のデータを探す

  6. さらに別のツールを呼ぶ

  7. 最終回答を作る

というように、何度もモデルを呼び出します。

これを多数の社員が使えば、コストは一気に膨らみます。

DatabricksがContextだけでなくCostを強調している理由はここです。

Genie Ontologyは、AIがどこを見るべきか、何を信じるべきかを事前に整理することで、無駄な探索を減らします。

つまり、コンテキスト管理は精度向上だけでなく、トークンコスト削減にも直結します。

10-5. ZeroOpsで運用を管理する

Genie ZeroOpsは、データ基盤やAI基盤の運用を自動化するエージェントです。

AIエージェントが企業内で増えると、データパイプライン、モデル、ジョブ、ダッシュボード、アプリも増えます。

すると、必ず壊れます。

データが遅れる。
ETLが失敗する。
モデル精度が落ちる。
ダッシュボードが古くなる。
上流テーブルの変更で下流が壊れる。
本番エージェントが間違ったデータを見に行く。

このとき、運用を人間だけで支えるのは難しくなります。

ZeroOpsは、メトリクス、イベント、ログ、リネージを見て、異常検知、原因分析、修正提案を行う方向を示しています。

つまり、コンテキストを貯めるだけでなく、壊れたコンテキストを修復する仕組みも必要になるということです。

11. Lakebase / LTAP

AIエージェント時代の運用データベース

Databricksは今回、LakebaseとLTAPも強く打ち出しました。

LTAPとは、Lake Transactional/Analytical Processingの略です。

従来、企業システムでは、

  • OLTP
    業務トランザクション処理

  • OLAP
    分析処理

が分かれていました。

業務システムのDBと、分析用データウェアハウスは別物でした。

しかしAIエージェント時代には、この分離が問題になります。

AIエージェントは、分析だけでなく行動します。

顧客データを見る。
在庫を見る。
注文状態を見る。
チケットを作る。
業務アプリを更新する。
アクションの結果をまた分析する。

このため、分析データと業務トランザクションデータをもっと近づける必要があります。

Lakebaseは、Databricksが示したサーバーレスPostgresベースの運用データベースであり、Lakehouseと連携することで、AIエージェント向けのリアルタイムな状態管理、アプリ開発、業務処理を支える狙いがあります。

これは、AIエージェントの「短期記憶」や「業務状態」を置く場所にもなり得ます。

今回のLTAPの考え方を、もう少し具体的に補足します。

従来、LakebaseとLakehouseはストレージ層を共有しつつ、それぞれが自分の形式でデータのコピーを持っていました。

LTAPはこのギャップを埋めます。

Lakebaseのデータを、LakehouseとDelta・Icebergという同じオープン形式でUnity Catalogに直接書き込む。

これにより、業務・分析・ストリーミングのデータが、レイク上の単一コピーに統合されます。

ETLパイプラインも、レプリカも、同期処理も不要にすることが狙いです。

Ghodsi氏は「40年間、OLTPとOLAPは分離されてきた。我々は初めて、その統合の鍵を解いたと考えている」と述べたと報じられています。

Lakebase自体も拡張されました。

Databricksの発表によれば、Lakebaseはすでに数千の顧客に使われ、1日あたり1200万回のデータベース起動を処理しているとされます。

新たにGit風のブランチとスナップショットが加わり、本番データに影響を与えずに安全な検証ができるようになりました。

クロスクラウド・クロスリージョンの災害復旧にも対応しています。

12. Lakehouse//RT

リアルタイム化しないとAI社員は働けない

DatabricksはLakehouse//RTも発表しました。

これは、Lakehouse上でリアルタイム分析を実現するための仕組みです。

AIエージェントが本番業務に入ると、古いデータでは困ります。

たとえば、

  • 今の在庫

  • 今の売上

  • 今の顧客ステータス

  • 今の広告効果

  • 今の製造ライン状況

  • 今の配送状況

を見なければ、正しい判断ができません。

人間のレポートなら、前日集計でも許されることがあります。

しかしAIエージェントが業務アクションを実行するなら、リアルタイム性が必要になります。

Lakehouse//RTは、この問題に対するDatabricksの回答です。

中核には、Reydenという新しい計算エンジンが置かれています。

Databricksによれば、小規模なら10ミリ秒、大規模でも100ミリ秒未満の応答を、数万の同時利用に対して実現するとされます。

既存のリアルタイム配信基盤と比べて、最大16倍速いという主張です。

ガバナンスされたDelta・Iceberg上のデータに、別の配信システムを立てずに直接アクセスできる。

提供状況は発表時点でベータです。既存のLakehouse利用者が、別のリアルタイム配信基盤を新たに構築せずに利用できる方向で案内されています。

13. Genie Code

データ・ML開発にもAIエージェントを入れる

Databricksは、Genie Codeのアップデートも発表しました。

Genie Codeは、Databricks上のデータ・ML開発を支援する専門エージェントです。

公式ブログでは、DatabricksのGenie製品群は過去1年で10倍以上に成長し、90%のDatabricks顧客に使われていると説明されています。

Genie Codeは、ノートブック、SQL、Lakeflowパイプライン、ダッシュボード、ジョブ、モデル、Serving Endpoint、Unity Catalog資産などをまたいで、開発、デバッグ、改善を支援します。

ここでも重要なのはコンテキストです。

一般的なコーディングエージェントは、チームの過去の実験、評価基準、特徴量設計、ビジネス指標を知りません。

だから、もっともらしいコードは書けても、その会社のML開発パターンに合うとは限りません。

Genie Codeは、Genie Ontologyを通じて、チームがどのように特徴量を作り、モデルを評価し、候補を比較しているかを学ぶ方向を示しています。

ここでも、モデル単体ではなく「チーム固有の開発コンテキスト」が重要になっています。

開発者向けの基盤：Agent Bricks

Genie Codeがデータ・ML開発者向けのエージェントだとすれば、その隣で大きく扱われたのがAgent Bricksです。

Agent Bricksは、昨年のSummitで発表された、企業向けエージェントを構築するための開発者プラットフォームです。

今年はこれが、本格的なエージェント基盤へと拡張されました。

Databricksによれば、これまでに10万以上のエージェントが構築され、年間1000兆トークン以上を処理しているとされます。

拡張の要点は、使えるフレームワークやハーネスの選択肢が広がったことです。

報道や案内では、Claude Code SDK、LangGraph、Agno、CrewAI、OpenAI Agent SDKなどに対応し、Databricks Apps上で水平スケールできるとされています。

モデルもOpenAI、Anthropic、Gemini、Qwen、Kimi、Grokなど、独自・オープン双方から選べます。

文脈はMCP経由でUnity Catalogに接続して取得し、エージェントのメモリはLakebaseに置く。

つまりAgent Bricksは、後で述べる「AI業務OS」のエージェント層を、開発者が自由に組み立てるための場所です。

ビジネス部門にはGenie One。

開発者にはAgent BricksとGenie Code。

その両方を、同じガバナンスとコンテキストの上に乗せる、という構図です。

14. CustomerLake

マーケティング領域への展開

Azure Databricksの発表では、CustomerLakeも紹介されています。

これは、Lakehouseに組み込まれたAgentic CDP、つまり顧客データ基盤です。

従来のCDPは、顧客データを統合してセグメント配信やマーケティング施策に使うものでした。

しかしAgentic CDPでは、AIエージェントが顧客プロファイルを作り、キャンペーンを設計し、パーソナライズを行う方向に進みます。

ここでも、企業コンテキストが重要です。

顧客の購買履歴だけでなく、

  • 営業接点

  • サポート履歴

  • Web行動

  • キャンペーン反応

  • 在庫状況

  • 価格戦略

  • ブランド方針

  • コンプライアンス

まで含めて判断する必要があるからです。

15. Databricksは何を狙っているのか

今回の発表を一言で言えば、Databricksは「企業AIのコンテキストOS」を狙っています。

OpenAIはモデルを作る。
Anthropicは安全なエージェント体験を作る。
Googleは検索、クラウド、Geminiを持つ。
MicrosoftはOffice、Teams、Copilot、Azureを持つ。
Snowflakeはデータクラウドを持つ。
Databricksは、Lakehouse、Unity Catalog、Genie Ontology、AI Gatewayを使って、企業のデータと文脈の中心を取りに来ている。

これが非常に大きい。

AI時代には、モデルは乗り換え可能になります。

今日GPTを使っても、明日Claudeを使っても、来年Geminiを使ってもよい。

しかし、自社のコンテキストは乗り換えできません。

自社の業務知識、自社のデータ定義、自社の判断履歴、自社の顧客理解、自社の現場ノウハウは、外から買えません。

Databricksは、そこを押さえようとしているのです。

上場をにらんだ発表でもある

今回のSummitには、もう一つの顔があります。

それは、上場をにらんだ投資家向けのショーケースだったという点です。

Databricksは2025年12月のシリーズLで、評価額1340億ドル（約21.4兆円、1ドル160円換算）を付けました。

一部報道では、さらに1650億〜1750億ドル規模の評価額をにらんだ新たな資金調達交渉も伝えられています。ただし、これは確定発表ではなく報道ベースの観測です。

背景には、強い業績があります。

報道では、年間換算売上は約54億ドル（約8,600億円）に達し、前年比65%で伸びているとされます。

うちAI製品の売上はおよそ14億ドル（約2,240億円）で、全体の約26%を占めると報じられています。

2025年にはフリーキャッシュフローも黒字化したとされます。

また、2026年後半にSECへS-1を提出する可能性があるとも報じられています。ただし、これもDatabricksが正式に日程を発表したものではありません。

もし実現すれば、エンタープライズソフトウェア史上でも最大級のIPOになる可能性があります。

ただしGhodsi氏自身は、上場時期には慎重です。

報道では、2026年は上場に「ひどい年だ」と述べたとされ、一方で経営陣は「いつかやる。急いではいない」と語っています。

つまり、今回の製品発表の一つひとつは、顧客向けであると同時に、公開市場の投資家へのメッセージでもあったわけです。

LakebaseやAgent Bricks、Genieといった製品群は、直近の70億ドル超（約1.12兆円）の資金調達の使い道として名前が挙がっていた領域でもあります。

成長を示す材料として、Lakebaseは初期の同時期比較でDatabricksのデータウェアハウス製品より速いペースで売上成長している、とDatabricks自身も説明しています。

16. これは「AI業務OS」の話である

私は今回のDatabricksの発表を、単なるデータ基盤の進化ではなく、AI業務OSの話として見るべきだと思います。

AI業務OSとは、企業の仕事をAIが支援・実行するための基盤です。

必要なのは、以下の層です。

1. データ層

売上、在庫、顧客、会計、製造、物流などのデータ。

2. コンテキスト層

KPI定義、業務ルール、社内用語、判断基準、権限、過去の履歴。

3. エージェント層

営業エージェント、財務エージェント、マーケティングエージェント、データエンジニアリングエージェント、運用エージェント。

4. ガバナンス層

権限、監査、コスト、モデル選択、MCP制御、ログ管理。

5. 実行層

メール送信、チケット作成、DB更新、レポート生成、ワークフロー実行。

今回Databricksが発表した製品群は、このAI業務OSの各層を埋めに来ています。

  • Lakebase
    実行・状態管理

  • Lakehouse//RT
    リアルタイムデータ

  • Unity Catalog
    データ・AI資産管理

  • Genie Ontology
    コンテキスト層

  • Genie One
    ビジネスユーザー向けAIコワーカー

  • Genie Agents
    業務別エージェント

  • Genie Code
    データ・ML開発エージェント

  • Genie App Builder
    業務アプリのローコード生成

  • Agent Bricks
    開発者向けエージェント構築基盤

  • Genie ZeroOps
    運用エージェント

  • Unity AI Gateway
    ガバナンス・コスト・MCP制御

つまり、Databricksは「AIを企業で働かせるためのOS」を作ろうとしているのです。

17. Physical AIとの共通点

この話は、フィジカルAIやヒューマノイドロボットにもつながります。

ロボットも同じです。

ロボットの頭脳が賢くなっても、現場で動くにはコンテキストが必要です。

工場であれば、

  • 工程表

  • 作業手順

  • 安全ルール

  • 設備配置

  • 部品表

  • 在庫

  • MES

  • ERP

  • WMS

  • PLC

  • 現場の暗黙知

  • 作業員の癖

  • 過去のトラブル

が必要です。

介護現場なら、

  • 利用者ごとの身体状態

  • 禁忌事項

  • 服薬情報

  • ケアプラン

  • 家族との関係

  • 施設ルール

  • 緊急時対応

が必要です。

つまり、ロボットもAIエージェントも同じです。

賢いモデルだけでは働けない。
現場コンテキストがなければ仕事にならない。

Databricksのイベントは、企業データの話に見えますが、本質的にはフィジカルAI時代にも直結しています。

18. 日本企業への示唆

日本企業にとって、今回の発表はかなり重要です。

日本企業はよく、

「うちの業務は特殊だからAI化できない」
「現場の暗黙知が多い」
「データが散らばっている」
「基幹システムが古い」
「部門ごとに数字の定義が違う」
「Excelが多すぎる」

と言います。

しかしAI時代には、これは弱点であると同時に資産でもあります。

なぜなら、それこそが企業コンテキストだからです。

問題は、それをAIが使える形で貯めていないことです。

今後、日本企業がやるべきことは、いきなり巨大なAI導入プロジェクトを始めることではないと思います。

まずやるべきは、以下です。

1. KPI定義を整理する

売上、粗利、在庫、顧客、リード、解約など、重要指標の定義を明確にする。

2. 正式なデータソースを決める

どのテーブル、どのダッシュボード、どのシステムを正とするのかを決める。

3. 権限を整理する

誰が何を見られるのか。
AIが何を読んでよいのか。
何を実行してよいのか。

4. 業務ルールを残す

会議、チャット、メール、マニュアル、稟議、トラブル対応履歴を、AIが読める形にする。

5. 失敗を資産化する

AI時代に重要なのは、成功事例だけではありません。

むしろ、失敗、例外、判断ミス、修正履歴こそが重要です。

19. 企業は「AIモデル」を買うだけでは勝てない

これから多くの企業がAIツールを導入します。

ChatGPT Enterprise。
Claude for Enterprise。
Microsoft Copilot。
Gemini for Workspace。
各種AIエージェントツール。

しかし、ツールを入れただけでは差はつきません。

なぜなら、同じツールは競合も使えるからです。

本当に差がつくのは、

自社のコンテキストをどれだけ深く、正しく、継続的に蓄積できるか

です。

モデルは外から買える。
GPUもクラウドも外から借りられる。
SaaSも導入できる。

しかし、自社の仕事の文脈は外から買えません。

それは日々の仕事の中でしか蓄積できない。

だからこそ、AI時代の企業競争は「コンテキスト資本主義」になっていくと思います。

20. Databricks発表の冷静な見方

もちろん、今回の発表をそのまま鵜呑みにする必要はありません。

冷静に見るべき点もあります。

まず、Genie One、Genie Agents、Genie Ontologyは非常に魅力的ですが、実際の企業でどこまで機能するかは、データ品質、権限設計、既存システムとの接続、社内運用体制に大きく依存します。

特に日本企業では、データがSaaS、オンプレ、Excel、紙、個人PC、部門サーバーに散らばっているケースが多い。

その状態で、すぐに「自動で文脈グラフができます」とはならないでしょう。

また、コンテキストを自動で集めるほど、ガバナンスは難しくなります。

AIが便利になるほど、情報漏洩、誤実行、権限逸脱、コスト暴走のリスクも増えます。

だからこそ、DatabricksがUnity CatalogやUnity AI Gatewayを前面に出しているのだと思います。

今回の発表は夢物語ではありません。

しかし、導入には相当なデータ整備と運用設計が必要です。

ここを見誤ると、また「AI PoCだけで終わる」ことになります。

興味深いのは、Ghodsi氏自身がAI投資の過熱に慎重な発言をしていることです。

報道によれば、彼はAIから大きな価値が生まれることは確信しつつも、データセンターやエネルギーへの巨額投資をそれが正当化できるかは分からない、少し先走っているのではないかと懸念している、という趣旨を語っています。

最も強気であるべき当事者が、ここまで冷静に語っている。

この温度感も、今回のSummitを読むうえで押さえておきたい点です。

21. まとめ

モデルの時代から、コンテキストの時代へ

Data + AI Summit 2026の本質は、AGI到来の宣言ではありません。

本質は、

AGIを企業の中で働かせるには、企業コンテキストをどう貯め、どう管理し、どう安全に渡すかが勝負になる

という宣言です。

Databricksはその答えとして、

  • Genie One

  • Genie Agents

  • Genie App Builder

  • Genie Ontology

  • Unity Catalog

  • Unity AI Gateway

  • Agent Bricks

  • LTAP / Lakebase

  • Lakehouse//RT

  • Genie ZeroOps

  • Genie Code

  • CustomerLake

を並べてきました。

これは単なる新機能発表ではありません。

AI時代の企業システムの再設計です。

これからの企業AIの競争は、モデルの賢さだけでは決まりません。

決めるのは、

誰が一番深く、自社の文脈をAIに渡せるか

です。

そして、その文脈を貯める場所、管理する仕組み、権限を守る基盤を押さえた企業が、AI時代の本当の主導権を握ることになります。

Databricks Data + AI Summit 2026は、その転換点を示したイベントだったと思います。

おわりに

私は今回のDatabricksの発表を見て、

AI競争の中心は、モデルからコンテキストへ移った

と改めて感じました。

モデルは買えます。
GPUも買えます。
クラウドも借りられます。

しかし、

  • 現場の知識

  • 判断基準

  • 業務ルール

  • 失敗履歴

  • 顧客理解

  • 顧客ごとの例外

  • 部門ごとのKPI定義

  • 現場でしか分からない暗黙知

は買えません。

これらをどう蓄積し、AIに渡していくか。

それが今後の企業競争力になるでしょう。

Databricksは、その「企業の記憶」を管理するプラットフォームになろうとしている。

今回のData + AI Summit 2026は、その方向性を強く示したイベントだったと思います。

そしてこの話は、データ基盤だけの話ではありません。

AIエージェント、AI社員、Physical AI、ヒューマノイドロボット、製造現場の自動化、介護現場の支援。

すべてに共通するのは、

賢いAIだけでは仕事にならない。
仕事をするには、その現場のコンテキストが必要である。

ということです。

だからこそ、これからの日本企業に必要なのは、AIツールを入れることだけではありません。

自社の文脈を、AIが使える形で蓄積すること。

そこから本当のAX、AI Transformationが始まるのだと思います。

参考リンク

ハッシュタグ

#Databricks
#DataAISummit2026
#AGI
#AIAgent
#GenieOne
#GenieAgents
#GenieOntology
#Lakebase
#LakehouseRT
#UnityCatalog
#MCP
#AI業務OS
#コンテキストOS
#コンテキスト資本主義
#生成AI
#企業AI
#AX
#DX
#PhysicalAI
#ヒューマノイド

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