レイクハウスにおけるデータモデリングの再定義：Vibe Data Modelingのご紹介

データモデリングにおける課題

すべての分析スタックにおいて、Silverレイヤーは成功か失敗かを分ける場所です。BIやダッシュボードはGoldからデータを読み込み、GoldはSilverから構築されます。Silverレイヤーのモデルは、すべての分析担当者、データサイエンティスト、そしてBIツールが依存する基盤です。Silverが乱雑で、ガバナンスが効いておらず、重複だらけであれば、それより上のすべての処理がより難しく、遅く、コストがかかるものになります。

そこに到達することが、常に課題となっていました。多くの組織は、Silverモデルをゼロから手作業で構築するのに6ヶ月から3年を費やすか、一般的な業界テンプレート（保険向けのACORD、ヘルスケア向けのFHIR、小売向けのARTS、通信向けのTM Forum SIDなど）を購入し、それをトリミング、名前変更、再配線するのに9〜12ヶ月を費やしています。テンプレートは業界全体の平均値にすぎません。通常、関連性があるのは20〜40%程度であり、特定のビジネス向けに構築されたものではありません。どちらの方法も、現代のデータプロダクトを迅速にリリースしなければならないスピードに追いつくことはできません。

本日、Vibe Data Modelingを発表します

Vibe Data Modelingは、ビジネスに関するプレーンな英語の記述を、完全にガバナンスが効いたデプロイ可能なSilverレイヤーのデータモデルへと変換する、マルチモデルLLMエージェントです。単一のノートブックとして提供され、4つのウィジェット、1回の実行で、Unity Catalogに完全にデプロイされたモデルが作成されます。出力結果が気に入らない場合は、思い通りになるまでプレーンな英語で「調整（vibe）」することができます。

• 数ヶ月ではなく数時間：2時間未満でデプロイ可能なMinimum Viable Model（最小限の実用的なモデル）を構築し、半日でExpanded Coverage Model（拡張カバレッジモデル）を構築できます。
• 自社に100%適合：業界の平均値ではなく、自社独自の用語、部門、ドメインを使用します。
• 構造的に信頼可能：251の強制可能なルール、2つのアーキテクトによるレビュー、およびリリース前にモデルを検証するエージェントループを備えています。
• Unity Catalogへのネイティブデプロイ：スキーマ、テーブル、外部キー、分類タグ、メトリックビュー、RDFSオントロジー、DBMLダイアグラム、サンプルデータがまとめて生成され、バージョン管理されます。

ユーザーの指示（vibe）が最優先されます

エージェント全体を支配する原則はただ1つ、「ユーザーの言うことが最優先される」ということです。ウィジェット、model_vibes、またはビジネスの説明における明示的な指示は、パイプライン内のすべてのヒューリスティクス、スコアリング式、ゲート、およびLLMの意見よりも優先されます。「正確に10個のドメイン」と指定した場合、階層分類器が11個目を追加することはできません。

指示（vibe）がデータモデルになる仕組み

4つのウィジェットの裏で、エージェントは4つのステージでパイプラインを実行します。入力を理解し、モデルをトップダウンで設計し、リレーションシップとメトリックで接続してから、デプロイします。各ステージは次のステージが始まる前に検証されるため、問題のないステージのみが先に進みます。内部的には、マルチモデルアンサンブルとなっています。大規模な思考（thinker）モデルが推論とレビューを担当し、大規模なワーカー（worker）モデルが大量のプロダクトと属性を生成し、より小規模なモデルがドメイン、タグ付け、サンプルデータを処理し、評価（judge）モデルが単一の評価基準に基づいて競合する提案をスコアリングします。構成は自己修復し、パフォーマンスの低下したモデルを降格させ、正常に戻ったら復帰させます。

モデルの構成方法

すべてのモデルは、上から順に、組織（organization）、部門（divisions）、ドメイン（domains）、サブドメイン（subdomains）、プロダクト（products）、属性（attributes）という同じ形状に従います。最上位には、ほぼすべての組織が共有する3つの部門があります。Operations（業務内容）、Business（サービスの対象）、Corporate（働き方）です。OperationsとBusinessがコアであり、Corporateはそれを支える補助的な役割を果たします。ドメインとは、明確な概念のセットを所有する境界づけられたコンテキストです。プロダクトとは、ドメインエキスパートが認識できる実際のビジネス概念（請求書、注文など）であり、配管（plumbing）や分析のためのものではありません。そして、すべての属性には存在理由が必要です。

単一の信頼できる情報源（Single Source of Truth）とクリーンなグラフ

モデルの一貫性を維持するために2つの構造的保証があり、その両方が強制されます。単一の信頼できる情報源とは、1つの概念を所有するプロダクトが厳密に1つだけ存在することを意味します。例えば、顧客は customer.customer で一度だけ定義され、他はすべて外部キーによってそれを参照します。また、リレーションシップは有向非巡回グラフ（DAG）を形成します。外部キーは子から親を指し、循環することはなく、孤立するプロダクトも存在しません。キーが配置されると、冗長な列は正規化によって排除されます。

信頼性を担保するルール

エージェントは、20のグループにわたる251のルールを強制します。構造的なルールは、実際のモデルディクショナリを読み取る決定論的なゲートであるため、判定が覆ることはありません。これらはモデルの構築時と、デプロイされたモデルに対するインストールゲート時の両方で実行されます。実行時に報告される品質スコアは、LLMの自己評価ではなく、モデル自体から計算されます。

エージェントループ：生成、検証、異なるアプローチでの再試行

1回限りのLLMの処理が最終結果として信頼されることはありません。ループは1つの具体的な試みを生成し、決定論的なゲートと静的解析に対して検証します。失敗した場合は、同じことを繰り返すのではなく戦略を変更します。満たされていない要件や構造的な残差（非正規化されたキー、クロスドメインの重複、リンクされていない外部キーや循環する外部キー）は、サンドボックス化された修復ステップに送られ、再び検証を通過します。単調ガード（monotonic guard）は、モデルを悪化させる処理を元に戻すため、モデルは改善するか現状を維持するかのどちらかになります。

指示（vibe）の検証方法

反復処理を行う際、リクエストは構造化された検証要件（VREQs）にパースされます。これらはそれぞれ、個別にチェック可能なディレクティブです。各要件はサンドボックス化されたミューテーターによって適用され、可能な限り決定論的に独立して検証されます。ゲートは、変更が行われたかどうかをLLMに尋ねるのではなく、実際のモデルと物理的な Unity Catalog を読み取ります。実行結果として準拠スコアが報告され、検証されなかったものは静かに破棄されるのではなく、再度キューに入れられます。

2つのアーキテクトゲート

ルールは機械的な誤りを検出し、アーキテクトゲートは構造的に不適切な部分を検出します。ドメインアーキテクト（Domain Architect）は各ドメインを個別にレビューし、グローバルアーキテクト（Global Architect）はモデル全体をレビューして、クロスドメインの重複、単一の信頼できる情報源への違反、および構造的な整合性をチェックします。検出された問題は自動的に適用され、適用済み（landed）、後退（regressed）、またはブロック（blocked）として追跡されます。レビューは問題がなくなるまで最大8回再実行されます。

1回の実行で得られるもの

• すべてのドメイン、プロダクト、属性、外部キー、分類タグを含む論理モデル（model.json）。
• Unity Catalogへの物理デプロイ：スキーマ、テーブル、外部キー（情報用）、分類タグ。
• Unity Catalogのメトリックビュー：プロダクトに対する再利用可能なKPI定義。AI/BIダッシュボードやGenieですぐに使用できます。
• セマンティックツールやAIエージェント向けのRDFSオントロジー、および dbdiagram.io 用の DBML ファイル。
• 同じモデルに対して生成された合成サンプルデータ、完全なパイプラインログ、および推奨される改善案を含む next_vibes ファイル。

model.json：単一の信頼できる情報源

エージェントが生成するものはすべて、1つのアーティファクトである model.json から派生します。物理的なデプロイ、オントロジー、DBML ダイアグラム、メトリックビュー、サンプルデータ、ドキュメント、そして next_vibes の提案はすべて、ここから生成されます。二重に作成されるものはないため、論理モデルとすべてのダウンストリームのアーティファクトが乖離することはありません。

Unity Catalog に配置されるもの

デプロイカタログを設定すると、ドメインはスキーマに、プロダクトは Delta テーブルに、属性は列になります。外部キーは情報制約として適用され、分類タグ（PII、用語集、プロベナンス）は構築時に適用され、その上にメトリックビューが配置されます。

2つのスコープ：MVM と ECM

ほとんどのチームは最初からすべてのドメインを必要とするわけではないため、エージェントは同じエンジンから2つのスコープを生成します。Minimum Viable Model（MVM）は、最初に構築される無駄のないコアです。Expanded Coverage Model（ECM）は、ビジネス全体を完全にカバーします。どちらを構築することも、ECM を MVM に縮小することも、MVM を ECM に拡大することも可能です。縮小は LLM のガイドに従って行われるため、コアプロダクトが保護されます。

フィットするまで調整する

洗練（リファインメント）こそが、Vibe Data Modeling の真骨頂です。v1 がベースモデルであり、横道にそれることなく前進するように進化します。バージョンが上書きされることはなく、すべてのイテレーションは監査可能で、元の状態に戻すことができます。変更には3つのインテントモードがあります。サージカル（ここだけを修正）、ホリスティック（全体に適用）、ジェネレーティブ（新しいものを生成）の3つで、すべて同じルールとレビューの下で行われます。

1つのエージェント、6つのオペレーション

同じノートブックで、最初のモデルを構築する以上のことができます。オペレーションウィジェットで6つのオペレーションのいずれかを選択します。これらはすべて、同じルール、アーキテクトゲート、エージェントループを共有しています。

バージョンを調整（vibe）する方法（VOV）

既存のバージョンを調整するには、「vibe modeling of version」オペレーションを選択し、ベースとなるバージョンを指定して、変更内容をプレーンな英語で記述します（または next_vibes.txt から提案を貼り付けます）。エージェントはこれらを VREQ に解析し、そのバージョンの上でパイプラインを再実行して、新しい番号のバージョンを書き込みます。開始元のバージョンは変更されません。

1つの論理モデル、複数の物理レイアウト

論理モデルは1つのアーティファクトであり、物理レイアウトは単一のウィジェットで制御される別の決定事項です。同じモデルを、1つのカタログ、部門ごとのカタログ、またはドメインごとのカタログとしてレンダリングできます。ガバナンスの状況が変わった場合は、別の規約に再デプロイします。論理モデルは変更されません。

業界テンプレートだけでは不十分な理由

汎用テンプレートを支持する理由は、常に「有利なスタートを切れること」でした。しかし、苦労して学んだ現実は、そのスタートダッシュのために、適合や名前変更に9〜12か月ものコストがかかるということです。テンプレートはあるセクターの平均的なモデルであり、その構造上、どの企業の実際のビジネスにも合致しません。Vibe Data Modeling は、お客様独自の用語、部門、ドメインを使用したモデルを数時間で生成し、他のすべてのモデルと同じルールで検証します。

エージェントで構築されたモデルの例

業界を問わない同じエージェントが、非常に異なるセクターにわたってビジネス全体の Expanded Coverage Model を作成しており、それぞれが業界で認められた標準を参照しています。以下の件数は、オープンソースリポジトリで公開されているリファレンスモデルの数です。

今すぐ利用可能

リファレンス実装は、agent/dbx_vibe_modelling_agent.ipynb にある単一の Databricks ノートブックです。4つのコアウィジェットに入力して実行するだけで、その他はすべて業界のデフォルト値が適用されます。

具体的な出発点として、製造モデルの生成に使用したプロンプトと、それを洗練させるために送信した最初のプレーンな英語の調整（vibe）を以下に示します。

• リファレンスリポジトリ（github.com/databricks-industry-solutions/lakehouse-industry-data-models）：エージェントノートブック、オーケストレーター、テストハーネス、40以上のオープンソースリファレンスモデル、および設計、統合、クオリティゲート、ルールカタログをカバーするガイド。
• The Vibe Data Modeling ホワイトペーパー：すべてのパイプラインステージの完全な技術解説、完全なルールカタログ、アーキテクトレビュー方法論、およびアンサンブルアーキテクチャ。

チームが Silver レイヤーのプロジェクトをリリースできずに何ヶ月も抱え込んでいる場合、これは実際にリリースするための最も近道です。ビジネスをプレーンな英語で記述し、モデルを取得し、フィットするまでイテレーションを繰り返し、本番環境に投入します。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事