Databricks Data + AI Summit 2026 最速レポート 最終日
参加セッションまとめ

みなさんこんにちは。DATUM STUDIO の田中 です。

Data + AI Summit 2026最終日の本日は、ここまで私が参加したセッションの内容をダイジェストでお届けします。

Build and Deploy Databricks Projects Using Automation Bundles and ZeroOps

関連 Databricks製品： DABs（Declarative Automation Bundles）, ZeroOps

最近自身が関わった案件において、Declarative Automation Bundles（以下、DABsと呼称）を活用してコード管理を行う機会があったので、さらにDABsを深堀したいと思い、このセッションに参加しました。

セッションでは、DABsによるDatabricksリソースのコードによる管理という話もあったのですが、どちらかというと新しく登場したZeroOpsへの言及が多くありました。

具体的には、デプロイしたデータパイプラインのZeroOpsによる修正とDABsの統合がトピックになっています。

ZeroOpsは、データパイプライン自体がエラーで失敗したときはもちろん、扱うデータに品質ドリフトなど異常が起きていたらそれも検知し、トリアージします。

さらに、本番データと同じデータを扱った上で修正を実装し、Pull Requestにするまで自動で行う、といった特徴があらためて紹介されていました。

機能面を聞くと、とても便利そうなZeroOpsですが、活用するには準備が必要です。

その準備として紹介されていたのが、下記の3点になります。

1. 1．DABsによるコード管理
2. 2．Genie Ontologyなどを活用したメタデータ管理
3. 3．ベストプラクティスへの追従

セッションでは特に、1番目のDABsによる構成のコード管理についての説明に時間が割かれていました。

DABsでは、YAMLを使って構成を管理します。もし、誰かがWeb UIからジョブやノートブックの修正を行って変更しても、DABsのYAMLが追従して書き変わっている様子が実演され、個人的にはDatabricksのgit統合機能を利用することが前提条件とされすぎているとは思うものの、たしかに便利そうだと感じました。

Migrating from Oracle to Databricks Lakehouse

関連 Databricks製品：Lakebridge, Genie Code, AI / BI Dashboard

最近似たようなOracleからの移行案件に関わりそうだったので、自分の案件の参考になるかもと思って登録してみました。

Oracleのように長年使われているデータベース製品からDatabricksへの移行を、計画・実施する際の考え方について解説されたセッションです。

計画においては、段階的に進めることの重要性が説かれていました。

特に、移行を必要とするユースケースの特定や移行の重要度の設定をしながら、フェーズに分けて進めるやり方が推奨されていました。

なお、計画移行の考え方については、講演内で紹介されていたこちらの記事も参考になるので、気になる方はご覧ください。

Navigating Your Migration to Databricks: Architectures and Strategic Approaches

https://www.databricks.com/blog/navigating-your-migration-databricks-architectures-and-strategic-approaches

実際に、移行を進めるにあたっては、

• ・ETLファースト
• ・BIファースト
  

の2つのやり方が提示され、それぞれにおいて活用できるDatabricks製品の紹介がされました。

前者では、OracleなどのDDLをDatabricksのDDLに変換するLakebridgeおよび、ETLパイプラインの書き換えとしてGenie Codeが、後者ではBIの参照先としてOracleのテーブルをLakehouse Federationを通じてクエリできるようにし、 AI / BIダッシュボードに接続する、という構成が紹介されていました。

あらためてこのように構造化してアプローチを整理したことはなかったので、いい機会になりました。

Agentic Admins: Managing Databricks @Databricks

関連 Databricks製品：Genie

企業においてAgentの活用を考える際、どうしても適切なコントロール、アドミンといった要素が顔を出してきます。そのあたりについてDatabricksがどう考えているのかを知りたかったので、このセッションに参加しました。

正直、そのあたりについては空振りという感じで、このセッションの核心は、「人間のアテンション（判断力）こそが、拡張不可能な唯一の経営リソースである」という共通認識を持つことの重要性を伝える点にありました。

AIエージェントの浸透によって、承認や確認といったタスクが急増する中、チームは「人間が真に注力すべき領域はどこか」という課題に向き合いました。

導き出されたポイントは、次の3点です。

1. （1）LLMに対してスキーマやドキュメントといった適切な文脈を確実に提供すること（グラウンディング）。
2. （2）エージェントにはスキルを用意することで挙動の再現性を高め、スキルの精度はテストによって検証・担保すること。
3. （3）人間が単なる承認作業の担当者から脱却し、「ワークフロー全体の設計および統治」を担う存在へとシフトすることです。

こうして確保されたアテンションを、次なる自動化フェーズへと投資することで、組織にポジティブな循環が生まれます。大きな変革も、まずは目の前の小さな問いかけから始まる、という呼びかけで締めくくられました。

ZeroETL Was Just the Start: Operational Databases belong in the Medallion Architecture

関連 Databricks製品：LTAP

なんとなくの気持ちで参加したのですが、とても学びの多いセッションでした。

LTAPについて、その意図から設計までを30分で話せるだけ話す、という感じのセッションでした。

そもそも、OLTPとOLAPの間のデータ連携は従来、Debezium → Kafka → Flinkや逆方向のReverse ETLなど、複雑なパイプラインに依存しており、遅延・二重管理・本番ワークロードへの影響が課題となっていました。

Databricks LTAPはこの問題を「パイプ改善」ではなく「データベース自体の再設計」で解決するアプローチを取る、とセッションでは説明がされていました。

OLTPをLakehouseと同一のObject Store（Iceberg / Delta）上に構築することでストレージを共有し、SparkがPostgresコンピュートを介さず直接データを書き込む「Direct Write」により、500GBのバルクロードを数時間から2分に短縮しました。

Gold TableからLakebaseへの同期（Sync Tables）も2クリックで完結し、16億行を10分で処理した実績もあるとの内容が語られていました。

Change Data Feedによりリアルタイムパイプラインや監査ログも構成でき、メダリオンアーキテクチャのBronze（入口）とGold → サーブ（出口）の両端にOLTPを統合できる点が最大の特徴です。

個人的には、DatabricksによるNeonの買収発表後、自社製品ポートフォリオに組み入れた後どのように展開するのかがずっと気になっていました。

このようにLTAPという方向で改めてOLTPとOLAPを統合させていく方針が明示され、その中でどのような仕組みが動いているのかを深く知ることができたので、とても満足度が高いセッションでした。

The Friday Afternoon Incident – Branching Beyond Code

関連 Databricks製品：Lakebase

データパイプラインを扱ううえでは、バグなどソフトウェアの問題に加えて、データ品質ドリフトなど、データの問題も避けては通れません。

そうした運用における知見を何か得られないかと思い、参加しました（セッション名を見てなんだか面白そう、と思ったのもあります）。

このセッションでは、LakebaseのData Branching機能について取り上げられました。

本番環境のデータをエージェントに操作させるのは、意図しない変更が入ってしまうリスクがあります。一方で、エージェントに本番データを与えることで、より本番環境に即した修正・変更を行わせたいというニーズもあります。

ここで登場するのが、LakebaseのData Branching機能です。

これによりGitのブランチやフックと併せて、本番データもブランチとして分岐させて持たせる仕組みを整えることができます。言い換えると、エージェントや開発者は本番データと同じ内容を、決して本番データそのものを意図せず編集してしまうことを避けながら扱えるということです。

なお、ブランチ間のスキーマ差分確認機能により、開発者同士の変更の競合は事前に検知できるそうです。

加えて注目すべき点として、本番への「マージボタン」はあえて提供していないという設計思想が紹介されました。

これは、本番環境を誤操作から守るための責任ある判断であり、代わりにCI / CDパイプラインや既存のマイグレーションツールとの連携を推奨する旨について話されていました。

本番データそのものではなくコピーを使うことで、コーディングエージェントや開発者に必要なコンテキストを与えるというのは、基調講演で示されたDatabricksの方向性とも一致していると感じました。個人的にこの機能は非常に気になるので、ぜひ自分でも試してみたいと思いました。

From Oracle Cloud to a Governed Lakehouse: Real-Time Streaming With Spark Declarative Pipelines

関連 Databricks製品：Spark Declarative Pipeline, 

Migrating from Oracle to Databricks Lakehouseと同じ理由で参加しました。

こちらのセッションでは、Databricksのユーザー企業およびDatabricksのFDE（Forward Deployed Engineer）が行った、OCI上に構築されたレガシープラットフォームから Databricks（AWS）へ移行するプロジェクトでの知見を紹介されていました。

対象となったのは、イタリアを中心に展開するスポーツベッティング・オンラインゲームの複数ブランドを支えるデータ基盤で、1.5テラバイト / 日のデータを処理していました。プラットフォームとしては機能していたものの、コストや運用負荷の観点からDatabricksへの移行を決断したとのことです。

移行にあたっては、まず「フロントエンドから移行するか、基盤から固めるか」という方針の選択がありました。このプロジェクトでは、既存ジョブ間の依存関係グラフを構築し、57の独立したコンテナ単位に分解するというアプローチを採用しました。「1つの巨大なモノリス移行」ではなく「小さな独立した移行タスクのポートフォリオ」として扱うことで、並行実行や進捗管理がしやすくなったと語られており、同様の課題を抱えるチームにとって参考になる視点です。

一方で、本番投入後には予期せぬ障害も発生しています。特定のシルバーレイヤーへの書き込みが5分のSLAを大きく超えて15〜50分かかるという問題が起き、Databricksの製品エンジニアリングチームと連携しながらブロードキャストジョブのサイズ調整やPhoton（動的パーティショニング）の有効化などでチューニングしたとのことです。

「うまくいった話」だけでなくこうした障害対応のプロセスが共有されていたのは、実践的な知見として特に価値がありました。

最終的な成果として、以下が報告されていました。

• ・運用コストの40%削減
• ・ブロンズ → シルバーレイヤーのパイプラインで96%のパフォーマンス改善
• ・200以上あったSpark ジョブを3つのSpark Declarative Pipelineに集約

数字としての成果もさることながら、依存関係の可視化による移行単位の分解や、本番障害を可観測性ダッシュボードで早期検知して対応した体制など、プロセス面での意思決定が成果を支えていたと感じられるセッションでした。

Under the Hood: Scalable Ingestion Strategies for Databases, Applications, and File Sources

関連 Databricks製品：Lakeflow Connect, DABs(Declarative Automation Bundles), Genie

こちらもDABsについての話が聞きたくて登録したセッションになりますが、結果的には Lakeflow Connectについてよく知るいい機会になりました。

架空のサッカーチームを題材にして、Lakeflow ConnectとDABsの組み合わせによって、サイロ化したデータソースからDatabricksにデータを集約する様子を実演するセッションでした。

Lakeflow Connectの機能紹介の中では、最近プレビュー段階で利用できるようになった機能として「増分取得（Incremental Ingestion）」や、Salesforce をソースとしたときの数々の新機能「算出フィールド（Formula Fields）」の変更に対する追従、「mTLSによる通信（ロールフィルタリング）」、コミュニティコネクタによって公式がカバーしていないソースに対するLakeflow Connect を使ったデータ連携ができることが取り上げられていました。

また、どのデータ連携方法やデータベースとの接続方法を選択するかについて考慮するときに考えるべきポイントとして、「Change Data Capture（CDC）を使った差分データ更新を行うか、クエリによって取得したデータが欲しいのか」「Classic / Private Link / Reverse SSH というネットワーク接続方式の3択のどれが自らのユースケースに最適なのか」といったポイントが紹介されていました。

デモではより具体的に、SQL Serverを通したChange Trackingによるデータ連携の様子と、Reverse SSHを利用したオンプレミス環境下のOracleからのデータ連携について、DABsを活用しつつコードで管理されたLakeflow Connectによるパイプラインが実際にデプロイされ、取り込んだデータをGenieから活用するところまで実演されました。

Why Data-Intelligent Agents Win: A Side-by-Side Benchmark

関連 Databricks製品：Unity Catalog

エージェントに対して整えられたデータを提供できるような仕組みこそが、エージェント活用のカギであることを伝えるセッションでした。

Claude Codeに代表されるAIエージェントやフロンティアモデルでできることは拡大し続けていますが、すべてをそうしたエージェントやモデルに都度実行させるべきなのでしょうか、という問いかけからこのセッションは始まりました。

LLM にテーブルやInformation Schemaを確認させるSQLを用意させて実行させて結果を確認してから答えを出させるのではなく、metric viewなど整えられたレイヤーを参照して目当ての情報に早く正確にたどり着けるような道筋を整えるべきだ、という論に進みました。

また、データが整えられていれば、LLMがそれを参照でき、それによってより少ないトークン消費、より短い処理時間、さらには（トークン消費と処理時間の削減による）消費金額の削減が見込め、必ずしもClaude Opusのような大きなモデルではなくHaikuなどより軽量なモデルでもOpusレベルでタスクを充分実行できるようになる様子について説明されていました。

こうしたハーネスエンジニアリングの取り組みは、日々知見が更新されているので変化が激しい分野ではありますが、継続的にキャッチアップしながら取り入れていきたいと思いました。

まとめ

かなり駆け足になりましたが、私が参加したセッションのまとめをお届けしました。

Databricks Data ＋ AI Summitの基調講演でも示されていた

1. 1．OLTPとOLAPのすべてがDatabricksの統一されたプラットフォームで動くようになる
2. 2．「コンテキスト」「コスト」「コントロール」「チョイス」をキーワードにした新機能・新製品
   

といった方向性が各セッションからも観察でき、今回のData ＋ AI Summit参加は非常に有意義な機会でした。

これ以外にもたくさんのセッションが開催されており、満席で泣く泣く参加を諦めたセッションがいくつもあります。

また、各セッションの後にはスピーカーに質問できる時間があり、そこで私もいくつか質問させてもらいました。親切にしていただいたスピーカーの皆さまにあらためて感謝いたします。

次回参加されるみなさんも、気になるセッションがあればぜひ飛び込んでみてください！

ここまで4日分の記事をお読みいただき、ありがとうございました。