Databricks Data + AI Summit 2026 最速レポート 最終日
データ品質・データベース開発の最前線

こんにちは！DATUM STUDIOの井田です。
現在参加中のData + AI Summit 2026から、現地レポートをお届けします。今回は私が参加した2つのセッションをまとめてご紹介します。

• ・セッション1：
  「Databricks Apps: A Magic Wand for Driving Data Quality Adoption and Observability」（Scribd）
• ・セッション2：
  「Enabling Evolutionary Database Development with Database Branching」（Databricks × Thoughtworks）

セッション1：Databricks Apps: A Magic Wand for Driving Data Quality Adoption and Observability ― データ品質の採用とオブザーバビリティを推進するための魔法の杖

登壇したのはScribdのTrinity Xia（Senior Software Engineer）さんとRyan Freitas（Principal Architect）さんです。

Scribdは2007年創業の米国企業で、電子書籍・オーディオブック・ドキュメントの定額制サブスクリプションサービスを提供しているデジタルコンテンツプラットフォームです。 

発表の核心メッセージは、下記のとおりでした。

「チェックそのものは難しくないが、人々に使ってもらうことが最も難しい。そしてこの考え方こそ、プラットフォームチームがスキップしてしまいがちな部分である。」

以下、詳細をご説明します。

旧システムの課題：YAMLベースのアプローチの限界

移行前のシステムはYAMLファイルに品質ルールを記述し、夜間Sparkジョブで実行、失敗時はSlack通知、という構成でした。仕組みとしては機能していましたが、あまり使われていませんでした。

主な理由は次の3つです。

1. 1.YAMLの記法が複雑で、プラットフォームチームに依頼しなければチェックを追加できなかった
2. 2.1つのチェックを試すだけのために、Sparkタスクをフルで起動する必要があった
3. 3.Slackアラートが多すぎて、誰も見なくなった

※YAMLは後述するUIアプリの導入後も廃止されておらず、GitHubのPRベースでルール管理をしたい上級ユーザー向けに引き続き提供されています。エンジニアから非エンジニアまで、役割に応じてUIアプリとYAMLを使い分けられる設計になっています。

改善方法：Databricks AppsでUIを作る

前述した課題を踏まえて、Databricks Appsを使って自社UIアプリを内製したとのことです。下記の3つの機能を1画面で完結させるというコンセプトです。

• ・ルール管理：
  Unity Catalogからテーブルを直接選択して、ルールを作成・編集できる
• ・テスト：
  ワンクリックで即座に実行して、結果を確認できる（夜間ジョブを待たなくてよい）
• ・履歴トレンドの可視化：
  チームまたはテーブル単位で、データ品質チェックの通過率の推移をグラフで確認できる

通知内容も改善されました。失敗時のSlack通知に、失敗の詳細情報とDatabricksノートブックへのリンクを記載し、原因調査を即座に開始できるようになりました。

結果：1ヶ月でデータ品質チェック件数が、22件から400件以上に増加

アプリをリリースした結果は、明確に数字に現れています。

それまでYAMLで管理できる一部のメンバーしかチェックを登録できず、登録数は22件にとどまっていました。しかしUIができたことで誰でも自分でチェックを登録できるようになり、月間400件以上に増加しました。

感想

セッションの中で、印象的な一文がありました。

「Same engine. The only thing that changed was who could use it.」

訳：エンジンは変わっていない。変わったのは、誰が使えるかだけ

誰に使ってもらいたいか、どうすれば使ってもらえるのか、ユーザーを起点とした設計の仕方を考えさせられるセッションでした。

セッション2：Enabling Evolutionary Database Development with Database Branching ― データベースブランチングによるEvolutionary Database Designの実現

登壇されたのは、DatabricksのKevin Hartmanさんと、Thoughtworksのデータベースリファクタリングの第一人者Pramod Sadalageさんです。

Pramod氏は、アジャイルコミュニティのリーダーとして知られるMartin Fowler氏と「NoSQL Distilled」を共著し、2006年にはScott Ambler氏との共著で「Refactoring Databases: Evolutionary Database Design」を執筆しています。

Evolutionary Database Designとは何か

「コードはGitで管理してプルリクエストを経由してデプロイするのに、なぜデータベースだけ誰かが直接変更スクリプトを流すのか」というのがこのセッションの問いです。

Evolutionary Database Designとは、ビジネスの要件や優先順位が変わるたびに、アプリケーションのコードと同じようにデータベースのスキーマも少しずつ更新・改善していく考え方です。 

この考え方は、次の3つの柱で構成されています。

1. 1.Continuous Evolution（継続的な進化）：
   要件が変わっても、既存の機能を壊すことなく柔軟に対応できること。
2. 2.Database-as-Code（コードとしてのデータベース管理）：
   データベースへのすべての変更をバージョン管理し、アプリケーションコードと一緒に管理すること。
3. 3.The 2026 Shift（2026年の転換点）： 
   LakebaseのCopy-on-writeブランチングにより、本番環境と同等のデータベースインスタンスを数秒で作れるようになったこと。

現在のデータベース開発の課題

現状のデータベース開発には、3つの構造的な問題があります。

1. 1.Contention & Bottlenecks：
   共有開発環境で複数人が同時に作業するため、誰かがスキーマを変更すると他のメンバーのコードが壊れる
2. 2.Unreliable Substitutes：
   モックやDockerコンテナで回避しようとするが、モックは本番の実態を反映しない
3. 3.DBA Toil & Gatekeeping：
   すべての変更がデータベース管理者（DBA）を経由するため、開発速度のボトルネックになる。DBA自身も週20時間以上を設計ではなく、運用作業に費やすことになる

Lakebaseが開発フローを変える

これらの課題を解決するのが、Lakebaseです。

Lakebaseのブランチング機能を使うと、CLIから自分専用のデータベース環境を瞬時に作成できます。障害復旧やセキュリティの仕組みも最初から組み込まれているため、開発者が個別に設定する必要がありません。

デモではVS Code / Cursor向けの “Lakebase SCM Extension” プラグインが紹介されました。このプラグインを使うと、コードとデータベースの変更を一緒に管理できます。開発フローは次の6ステップです。

1. 1.Scaffold（環境構築）
2. 2.Claim（ブランチ紐付け）
3. 3.Implement Change（コードとDB変更）
4. 4.Open PR（レビュー依頼）
5. 5.Review（自動チェック）
6. 6.Merge（本番反映）

感想

スキーマ変更等のたびに既存コードへの影響を考慮し、慎重に変更を進めてきた経験があるからこそ、データベースをコードと同じようにブランチで管理できる世界への期待感は大きいです。

2026年6月18日時点では、日本リージョンでのLakebaseの提供はまだ始まっていませんが、使えるようになった時に真っ先に試してみたい機能の1つになりました。

最後に

新機能の発表や活用法がたくさん共有された、盛りだくさんのSummitでした。
今後の技術検証を楽しみにしながら、帰国の途につきます。
ご関心を持たれた機能については、ぜひ公式ドキュメントもご参照いただければと思います。
現地発信レポート、ここまでお読みいただきありがとうございました！

おまけ

最終日夕方の会場の様子です。
活気のあった会場も人がまばらになり、寂しさを感じました。
気分を高揚させる凝った会場デザインが、来年はどのようなものになるのか楽しみです。