はじめに
2026年6月15日~18日サンフランシスコ・バーチャルにて開催されるDatabricks社主催の年間最大規模のカンファレンスイベント、「Databricks Data＋AI Summit 2026」（DAIS）が開催されました。
本記事はDAIS2026 Vibe Your Data Model, Supercharge Your Genie で発表された、AIエージェントによるデータモデリングについてのセッションレポートになります。
本記事はDatabricks公式発表を元にした非公式の日本語要約であり、すべての著作権・知的財産権はDatabricksに帰属します。
本記事で扱う 「Genie」 は、Databricksの AI/BIにおける自然言語データ分析機能 を指します。
実際の利用単位としての Genie Space を含む文脈で扱っています。以降は簡潔のため 「Genie」 と表記します。
忙しい方用
- Genieの効果を上げるには、データモデルとセマンティック層を整えることが重要。
- Databricksの「Vibe Data Modeling」は、AIエージェントを使って業界知識や自社文脈を反映したデータモデルのたたき台を高速生成するアプローチ。
- 生成されたモデルは、人間がレビューしながらフィードバックを重ねることで、MVM（最小構成）からECM（拡張構成）へ段階的に育てていく。
- Genieの強化には、Metric Viewsでメジャー・ディメンション・指標定義を明示することが有効で、プロンプトだけで頑張るより高精度になりやすい。
- データモデル整備はBIだけでなく、PII管理やUnity Catalogを含むガバナンス基盤としても重要。
概要
「Vibe Your Data Model, Supercharge Your Genie」のセッションでは、Databricksにおけるデータモデリングと、AI/BI Genie活用の関係が紹介されていました。
このセッションで特に印象に残ったメッセージは、これです。
Genieを賢くしたいなら、プロンプトや指示文を増やす前に、まずデータモデルを整える必要がある。
生成AIや自然言語インターフェースを使うと、つい「AIにうまく説明すれば何とかなる」と考えがちです。
しかし、元になるデータの構造や業務上の意味が曖昧なままだと、AIも曖昧な答えしか返せません。
本セッションでは、AIエージェントを使ってデータモデル作成を高速化する Vibe Data Modeling と、その成果を Genie や Metric Views にどうつなげるかが語られていました。
この記事では、セッション内容をもとに、以下の観点で整理します。
- なぜAI時代にデータモデリングが重要なのか
- Vibe Data Modelingとは何か
- 人間とAIでデータモデルをどう育てるのか
- Genieの精度向上にMetric Viewsがなぜ効くのか
- データモデルがガバナンスにもつながる理由
なぜ今、データモデリングなのか
セッションの冒頭で強調されていたのは、「データモデリングは大変だ」という話です。
ただし、難しいのはテーブル定義や主キー・外部キーを作る作業そのものだけではありません。
本当に大変なのは、業務部門と会話し、用語の意味を揃え、組織内でバラバラに使われている概念を整理することです。
たとえば、ある部門では「顧客」と呼んでいるものを、別の部門では「取引先」と呼んでいるかもしれません。
また、買収やシステム統合を経た企業では、同じ意味のデータが複数のシステムに存在していたり、逆に同じ名前の項目が部門ごとに違う意味で使われていたりします。
この状態でBIレポートを作ると、当然ながら品質は下がります。
そして、これはGenieのような自然言語によるデータ分析機能でも同じです。
質の悪いデータモデルの上にレポートを作れば、質の悪いレポートができます。
質の悪いデータモデルの上にGenieを載せれば、質の悪いGenie体験になります。
セッションでは、次のような印象的な表現がありました。
良いデータモデルは、10,000トークン分の価値がある。
AIに毎回長い説明を渡すよりも、データの構造そのものに業務文脈を埋め込んだ方が強い、という話だと理解しました。
たとえば、Genieに毎回以下のような説明をするのは大変です。
- このテーブルとこのテーブルはこのキーでJOINする
- 売上はこのカラムではなく、こちらの計算式を使う
- 利益率はこの定義で計算する
- このカラムは業務上「顧客ランク」を意味する
- この値は部署によって呼び方が違う
こうした情報は、プロンプトに押し込むよりも、データモデルやセマンティック層に定義しておくべきものです。
Vibe Data Modelingとは何か
今回のセッションで中心になっていたのが Vibe Data Modeling です。
これは、企業や業界の説明をAIエージェントに与えることで、エンティティ、属性、リレーションシップを生成し、データモデルのたたき台を作るアプローチです。
単にLLMに「データモデルを作って」と依頼するだけではありません。
背景には、データモデリングの経験則をルール化したワークフローがあります。セッションでは、数百のルールと構造化されたエージェントワークフローによって、業界理解、初期設計、レビュー、補完、再レビューを繰り返すと説明されていました。
生成されるモデルには、大きく2つのスコープがあります。
| モデル | 意味 | 位置づけ |
|---|---|---|
| MVM | Minimum Viable Model | 最小限の業務機能をカバーするモデル |
| ECM | Expanded Coverage Model | より広範囲をカバーする包括的なモデル |
MVMはPoCや初期導入に向いた、軽量なモデルです。
一方、ECMはより広い業務領域をカバーするモデルです。
重要なのは、MVMも単なる薄いサンプルではないという点です。業務概念、属性、リレーションシップ、主キー、外部キーなどを持つ、実用を意識したモデルとして扱われていました。
業界モデルをそのまま使うのではなく、自社向けに進化させる
セッションでは、鉱業企業の事例が紹介されていました。
その企業では、長年事業を行っていたにもかかわらず、全社共通のSilverレイヤーに相当するデータモデルが十分に整っていなかったそうです。
背景には、買収や組織ごとのシステム運用がありました。
これはかなり現実的な話だと思います。
企業が成長すると、業務部門ごとにシステムが分かれます。さらに買収が重なると、似たようなデータが別々の名前・別々の構造で存在するようになります。
その状態から、いきなり全社共通のデータモデルを作るのはかなり大変です。
そこでVibe Data Modelingが使われます。
まず「鉱業」という業界モデルを起点にします。
そこには、採掘、素材、設備、物流、活動、顧客など、業界に特有のエンティティや関係性が含まれます。
ただし、汎用的な業界モデルはあくまで出発点です。
実際の企業には、その会社固有の業務プロセス、組織構造、用語、内部ドキュメントがあります。
デモでは、業界モデルに対して自社固有の説明を追加し、それをAIエージェントに渡すことで、v1のモデルからv2のモデルを生成していました。
生成後は、以下のような差分を確認できます。
- どのドメインが変更されたか
- どのテーブルが追加されたか
- どのフィールドが追加・変更されたか
- どの関係性が調整されたか
つまり、AIがいきなり最終成果物を出すというより、初期モデルを高速に作り、人間がレビューし、フィードバックを与え、次のバージョンへ進化させる流れです。
Human-in-the-loopのデータモデリング
このセッションで良かったのは、AIエージェントを「人間の代替」としてではなく、「データモデリングの反復を速くする仕組み」として扱っていた点です。
データモデリングでは、最初から完璧なモデルを作ることはほぼ不可能です。
業務部門と話し、レビューし、指摘を受け、修正し、またレビューする。
この反復が必要になります。
デモアプリでは、モデルを可視化し、ドメインやテーブル単位で確認し、アノテーションを付け、レビュー済みかどうかを管理できるようになっていました。
たとえば、物流ドメインが十分に表現されていなければ、その箇所にフィードバックを付けます。
そのフィードバックを次のVibe、つまり次のモデル生成時の指示として取り込むことができます。
この流れにより、従来は数週間かかっていた議論や修正が、数時間単位に短縮される可能性があります。
セッションでは、数百エンティティを持つモデルの新バージョン生成に数時間かかったという話もありました。
もちろん、その後のレビューや調整は必要です。
しかし、ゼロから手作業で関係性を追いかける作業とは大きく違います。
AIは完成品を出す魔法の箱ではなく、データモデリングの初速と反復速度を上げる存在として使うのが現実的だと感じました。
Genieを強化する鍵は、Metric Viewsとセマンティクス
セッション後半では、Genieをどう強化するかという話に移りました。
Genieは、自然言語でデータに質問できる強力な機能です。
ただし、何でもGenieへの指示文だけで解決しようとすると限界があります。
たとえば、以下のような情報をすべてGenieの指示に書き込もうとすると、すぐに複雑になります。
- どのテーブルをどう結合するか
- 売上や利益率などの指標をどう計算するか
- どのカラムがディメンションなのか
- どの粒度で集計すべきか
- 業務用語と物理カラム名の対応
- 使ってはいけないテーブル
- 推奨される計算方法
これらは、本来であればデータモデルやセマンティック層で定義されるべき情報です。
そこで重要になるのが Metric Views です。
Metric Viewsを使うと、メジャー、ディメンション、結合関係、ビジネス上の定義をあらかじめ定義できます。
つまり、Genieに毎回「この指標はこう計算してください」と説明するのではなく、データ側に意味を持たせることができます。
プロンプトで頑張るより、データ側に意味を持たせる
セッションでは、Genieの精度改善に関する顧客事例も紹介されていました。
一方のアプローチでは、Genieへの指示や調整を何度も重ねることで、回答精度が段階的に改善していました。
例として、以下のような改善サイクルが示されていました。
38% → 46% → 85% → 93%
これは、プロンプトや指示文を調整しながら精度を上げていく方法です。
一方で、Metric Viewsを導入したアプローチでは、同じく93%程度の精度に一気に到達した例が紹介されていました。
メッセージは明確です。
Genieの品質改善は、プロンプトチューニングだけの問題ではない。
むしろ、データモデルとセマンティック定義の問題である。
LLMのコンテキストウィンドウは有限です。
その貴重な領域を、毎回のJOIN条件や指標定義の説明で埋めるのではなく、より高度なビジネスロジックや例外処理に使うべきです。
JOIN、メジャー、ディメンション、業務用語、同義語、表示名などは、できる限り構造化された形でデータ側に持たせる。
これがGenieを「信頼できる分析体験」に近づけるための重要な考え方だと感じました。
ガバナンスにも効く
Vibe Data Modelingの話で面白かったのは、PIIなどのタグ付けにも触れられていた点です。
モデル生成やレビューの過程で、「PIIが適切にタグ付けされていない」という気づきがあれば、新しいルールとして追加し、モデル全体に反映できます。
これは単なるドキュメント整備ではありません。
分類タグや権限管理、Unity Catalog上でのガバナンス設計、さらにはGenieでの解釈にもつながっていきます。
データモデルは、BIのためだけのものではありません。
AI、ガバナンス、セキュリティの土台にもなっていくのだと感じました。
まとめ
このセッションを一言でまとめるなら、次のようになります。
AI時代のデータ活用では、データモデルがますます重要になる。
Genieのような自然言語インターフェースが進化すると、ユーザーはSQLを書かずにデータへアクセスできるようになります。
しかし、その裏側で業務概念や指標定義が曖昧なままだと、AIは正しく答えられません。
だからこそ、以下の流れが重要になります。
- 業界モデルを出発点にする
- 自社固有の業務文脈を追加する
- AIエージェントでモデルの案を高速に生成する
- 人間がレビューし、フィードバックする
- Metric Viewsなどのセマンティック層に業務定義を反映する
- Genieがより正確にデータを解釈できるようにする
AIにすべてを説明するのではなく、AIを使ってデータそのものに意味を持たせる。
これが、今回の「Vibe Your Data Model, Supercharge Your Genie」で一番大きな学びでした。
お知らせ
ナレッジコミュニケーションでは、Databricks Data + AI Summit 2026 開催に伴い、日本語でのウェビナーや現地レポートを公開しております！
ナレッジコミュニケーション DAIS2026 特設サイト
DAIS2026で発表された注目テーマ、関連セッション、実務での活用ポイントを継続的に発信する特設ページです。
イベント情報の整理・社内共有にもご活用いただけます。
Databricks 導入支援サービスサイト
Databricksの導入検討から活用定着まで、課題に応じた支援メニューをご紹介しています。
「何から着手すべきか相談したい」という段階でも、お気軽にご覧ください。