サンフランシスコで開催された Databricks Data + AI Summit 2026 に、出張として現地参加させてもらった。自分のログとして残しておく。キーノートと主要発表のまとめと、データエンジニアとして考えたことを書いていく。
今年のテーマは「Let's make it real」。賢くなったAIを企業の実データと業務につないで実際に動かそう、という主題だった。その中で Databricks が狙っていたのは、データの置き場そのものではなく、その上で意味・ガバナンス・AI利用をまとめて管理する層だと感じた。
1. 概要
- 会期: 2026年6月15〜18日（サンフランシスコ・Moscone Center、ハイブリッド開催）
- 規模: 現地参加3万人超（前年比約1.5倍）、150カ国以上、800を超えるセッション
- 日本からの参加: 400名超
- 全体テーマ: 「Let's make it real」
2. キーノートの主張: 課題は「知能」ではなく「文脈」
Ali Ghodsi のキーノートは、次のような流れだった。
- AIの知能はもう十分高い。 いまのAIエージェントは人類の難関ベンチマークの半分を解く。知能レベルは足りている。
- でも組織には浸透していない。 多くの人が「人間並みに何でもこなすAIはまだ先だ」と感じるのは、単発のチャットボット利用に留まっていて、無数のエージェントが自律的に働くビジョンが組織に届いていないから。賢いのに業務システムやデータから切り離された「部屋に閉じ込められた人工脳」のような状態になっている。
- 足りないのは知能ではなく「文脈（コンテキスト）」。 企業固有のデータやプロセスをAIに与えれば動くはず。ただ、それを安全かつ低コストで与えるのが難しい。
- だから、自社のデータ基盤の上でエージェントを自由かつ安全に働かせる「Agentic System of Record」を作ろう、と提案していた。
3. 「4つのC」と主要発表
「Agentic System of Record」を実現するために解くべき課題を 4つのC に整理し、それぞれに新機能を当ててきた。土台となる Choice から、ガバナンスの Control、コストの Cost、そして文脈を供給する Context へと積み上げていく構成になっている。4つのCの枠に収まらない発表は末尾の「その他の主要発表」にまとめた。
① Choice: ロックインを避け、オープンな基盤に全データを集める
特定のモデルやシステムに縛られず、あらゆるデータをオープンな基盤に集約する。
- Lakeflow：100以上のシステムと接続するデータ取り込み（≒ Fivetran / Airbyte 系のマネージドな取り込み・連携）
- Zerobus：アプリやIoTのイベントを Kafka を挟まず直接 Delta に書き込むストリーミング取り込み（≒ Kafka / Kinesis を置き換える。ただし送り先をレイクハウス1つに絞った単一シンク型）
- Iceberg と Delta の完全統合：競合してきた2大テーブルフォーマットの相互運用（Iceberg=Snowflake/AWS陣営、Delta=Databricks陣営。その壁をなくす）
- Reyden（Lakehouse//RT）：ミリ秒級の超低遅延分析エンジン（≒ ClickHouse / Apache Druid / Apache Pinot のリアルタイム分析を、専用DBなしでレイクハウス上で）
- Lakebase：PostgreSQL ベースのトランザクション処理。買収した Neon が基盤（≒ Aurora / AlloyDB 系のマネージドPostgres、Snowflake Unistore に対抗するOLTP）
② Control: エージェントを安全に動かすガバナンス
AIエージェントがセキュリティポリシーを守って動くよう一元管理する。
- Unity Catalog の拡張：AIモデルや非構造化データも含めた全資産を管理（≒ データカタログ/ガバナンス。AWS Glue Data Catalog / Collibra / Alation / Snowflake Horizon の領域）
- Open Sharing：AIモデルやエージェントそのものを社内外で安全に共有（既存の Delta Sharing の考え方を AIモデル/エージェントまで広げたもの）
③ Cost: エージェントの「コスト暴走」を防ぐ
エージェントが自律的に動き回ることで膨らむコストを抑える。
- Unity AI Gateway：組織内の全AI利用を単一画面で可視化し、予算管理や上限設定ができる（≒ LiteLLM / Portkey / Cloudflare AI Gateway 系の LLMゲートウェイ）
④ Context: 全データを知識グラフ化してAIに供給
安全な土台の上で、企業のあらゆるデータを自動で知識グラフ化してAIに渡す。
- Genie Ontology：Lakehouse だけでなく Google Drive や SharePoint なども読み込み、オントロジー（概念の関係）を自動構築
- これを基盤に動くエージェント群: Genie One（全チーム向けの汎用AIコワーカー）、Genie Agents（自律型）、Genie Code（開発・データサイエンス）、Genie ZeroOps（障害の自動検知・修正）。自然言語でデータに問い合わせるBIという点では Snowflake Cortex Analyst / ThoughtSpot に近い
その他の主要発表
- LTAP（Lake Transactional Analytical Processing）：取引処理用のDB（OLTP）から分析システムへデータを移すために普通は必要な CDC（変更分を逐次取り込むパイプライン）を不要にする技術。バックグラウンドでデータを自動的に分析向けの保存形式（列指向）へ変換し、運用と分析を1つのシステムで両立する（≒ HTAP。Snowflake Unistore / SingleStore / TiDB と同じ「取引と分析を1つに」路線）。
- LakeWatch：サイバー攻撃を自動調査するセキュリティ・レイクハウス（≒ Splunk / Microsoft Sentinel 系の SIEM をレイクハウス上で。買収を発表した Panther Labs がこの文脈）。
- CustomerLake：1対1の継続的なマーケティングを自動化するエージェント型アプリ（≒ CDP。Segment / Salesforce Data Cloud / Treasure Data に相当）。
- OpenAI とのパートナーシップ：OpenAI プレジデント Greg Brockman が登壇。AIの指数関数的進化と、ソフトウェア開発を変える「Codex」を Databricks 環境から容易に使えることを強調。
4. 考察: これから問われること
ここから先は、Summit を踏まえた自分の考えを書く。Catalog Federation や Genie Ontology に象徴されるように、データは各クラウドに分散したままでも、Databricks は上の層を揃えにいっていると思っている。これを実務に引きつけると何が問われるか、論点を絞って書いてみる。
4-1. 上位レイヤーを統合する基盤として見る
今回の発表で見えたのは、Databricks が「物理的に1か所へ集める」ことより、置き場は分散したままその上のカタログ・権限・ガバナンス・メトリクス定義・文脈・AI実行管理を統合する方に狙いを絞っていたことだった。Catalog Federation で外部データを扱い、Delta と Iceberg の相互運用も進めているのがその表れだと思う。使うなら、取り込みはA・変換はB・カタログはC…と機能単位で最適化するより、上位レイヤーをある程度まとめて寄せた方がいいと思う。
もう一つ、基盤を使う相手が人だけでなくAIエージェントにも広がる変化がある。人間のアナリストは定義が多少曖昧でも補正して読めるが、エージェントは補正しないまま、それらしい答えを出して実行まで進めてしまう。だから権限がエージェント単位で効くこと、KPIの定義がエージェントにも解釈できる形になっていること、データの依存関係がたどれることが要る。そしてこれは一度作って終わりではなく、定義が変わるたび保ち続けるメンテ作業になりそうだと思った。
4-2. KPIは「数字」でなく「意味」ごと渡す
必要なのはKPIの意味ごと共有する仕組みだ。事業上の定義・含める/除外する対象・データオーナー・使ってよい意思決定の範囲までをセットにした「契約」として扱うべきだと思った。文脈が一番落ちやすいのは、データを生む現場側と、全社でKPIを集約して見る横断側が分かれている組織だ（この分離自体、どんな組織にもあるとは限らない）。そういう組織では「KPIを共有する」だけだと数字は渡せても文脈は付いてこない。同じ「アクティブユーザー」でも定義次第で意味は変わり、ここがないまま集約すると比較できないものを比べてしまう。エージェントは忖度しない読み手なので、誤った文脈のままそれらしい分析を返す恐れもある。
この「意味ごと共有する」責任は2つに分けられる。事業上何を意味するかに責任を持つ意味の持ち主と、それを全社で扱える型・ルール・カタログに落とす型の持ち主だ。線引きは組織によるが、目安は次の2パターンだ。
- 現場と横断が分かれている組織: 生む側が意味を、集約側が型を持ち、データエンジニア/データアナリスト/アナリティクスエンジニアが間で橋渡しする
- 両方を同じチームが兼ねる組織: 2つの役割が同じ人に乗る。この場合は定義や文脈が個人の記憶に閉じないようにする工夫が要る
どの組織でも避けたいのは「意味を知っている人に都度聞けばいい」という運用にしてしまうことだ。都度確認に依存すると担当が変わるたびに品質が揺れる。
4-3. データエンジニア/データアナリスト/アナリティクスエンジニアの役割変化: 実装から文脈設計へ
データエンジニア/データアナリスト/アナリティクスエンジニアは「データを作る人」から、事業とデータとAIの間にある『正しさ』を設計する人へ役割を広げていくのだと思う。パイプラインを組む・SQLを書く作業自体は Lakeflow や Genie Code のようなツールに支援される割合が増え、速く作れることでは差がつきにくくなるからだ。代わりに人間側に残る価値は、「何を指標として定義するか」「AIに渡してよい文脈か」を判断できることに移る。
4-4. まとめ: 問われるのは文脈・責任・運用の設計
Databricks は保存先・計算基盤にとどまらず、その上の管理層を統合し、使う相手も人からエージェントに広げにきている。ただしツールを入れれば解決ではなく、KPI定義や現場の文脈は自動では揃わない。本当に問われるのは文脈・責任・運用をどう設計するかで、現場が持つ事業文脈を横断側の経営KPIへ劣化させずに渡せる設計をどう作るかが肝だと思う。
おわりに
3万人が集まる規模感も、テーマが「Let's make it real」に振り切っていたことも、AIが実務に入る段階に来ていることを実感させる Summit だった。持ち帰ったテーマは、エージェントが読み手になる前提でデータ基盤と文脈をどう設計するか。ここは日々の仕事で試しながら考えていきたい。機会があれば来年も参加したい。
