every Tech Blog

株式会社エブリーのTech Blogです。

トップ > AI > Databricks Genieで現場で使えるAI分析基盤を育てる

Databricks Genieで現場で使えるAI分析基盤を育てる

AI Databricks LLM データ

はじめに

こんにちは。株式会社エブリーの開発1部の村上です。
弊社ではClaudeを非エンジニアも含めた全社に展開しており、業務のあらゆる場面で生成AIの活用を推進しています。

弊社のデータ基盤は、昨年TreasureDataとDatabricksを併用していた構成からDatabricksに統一しました。（この移行の話は今週の 「第3回 Youは何しにDatabricksへ！？」 で「データ基盤をTreasureData + DatabricksからDatabricksへ統一する話」として弊社のデータエンジニアの吉田がお話しする予定なので、ぜひご参加ください。）基盤が統一されたことで、次のステップとして見据えているのが「AIを活用したデータの民主化」です。

AIの進歩によって、ずっと掲げてきたこのテーマがいよいよ現実味を帯びてきました。MCP経由で社内のデータを取得し、AIと対話しながら分析を進め、今までにないインサイトを得る。そんな世界がすぐそこまで来ています。

一方で、「AIを使えばデータが簡単に出せる」ことと「現場で信頼して意思決定に使えるレベルの分析ができる」 こととの間には、まだまだ大きな壁があります。

AIはとても賢いですが、私たちの会社のこと、事業のこと、プロダクトのことを詳細には知りません。そのため、聞きたいことをそのまま質問してもその意図を正確に理解できず、全く違うデータを返してしまったり、生成するクエリが微妙に間違っていて正しいデータが出せなかったりします。結果として「使い物にならない」となってしまうわけです。

今回は、そんな状態からどのように進めていくことで「現場で使えるAI分析基盤」を作れるのか、Databricks環境で試行錯誤している話をします。

Databricks Genieとは

こうした課題を解決するためにDatabricksが提供しているのがGenieです。Genieは自然言語でデータに対して質問すると、SQLを自動生成して結果を返してくれるインターフェースです。

docs.databricks.com

ただし、これは単にDatabricks上でLLMを呼び出してSQLを書かせるだけのものではありません。LLMの限界を理解した上で、自分たちの組織専用にチューニングできるように設計されているのがGenieの本質です。

Genie Space — 目的特化の分析空間

Genieでは「Genie Space」という単位でデータの分析空間を作ります。会社にはさまざまな部門があり、それぞれが見たいデータや使う用語は異なります。Spaceではそのそれぞれに適したコンテキストを設定できるようになっており、登録するテーブルを指定することで必要なデータだけにアクセスさせることができます。

たとえば営業チーム向けのSpaceにはSalesforceのデータを、ECチーム向けのSpaceには注文・顧客データを登録するといった具合です。1つのSpaceに登録できるテーブルは最大30件で、むやみに広げるのではなく、そのSpaceが答えるべき質問の範囲に絞ることが推奨されています。

Knowledge Store — AIのためのコンテキストを整える仕組み

各Genie Spaceには「Knowledge Store」と呼ばれるコンテキストをチューニングする機能が備わっています。これがGenieを組織専用に育てていくための中核です。Knowledge Storeには以下の要素があります。

  • Metadata: テーブルやカラムの説明文、同義語、不要カラムの非表示。GenieがSQLを組み立てるための基礎知識
  • Prompt Matching: カラムの実際のデータ値をGenieに事前認識させ、ユーザーの言葉とデータ値のマッチング精度を上げる
  • Joins: テーブル間の結合条件を定義。Genieが複数テーブルをまたぐクエリを正しく書けるようにする
  • SQL Expressions: Filter（条件定義）、Measure（指標の計算式）、Dimension（グルーピング定義）をSQLで直接登録
  • Example SQL: よくある質問に対する正解SQLをテンプレートとして登録
  • General Instructions: テキストでの補足指示

ここからは、実際にSpaceを作ってKnowledge Storeを育てていく過程を、実際に行なった試行錯誤とともに解説していきます。

まずは何もチューニングせずに聞いてみる

まずやったのは、最小限の設定だけでGenie Spaceを作って、いきなり質問してみることです。テーブルにはカラムコメント（日本語の説明文）を付与済みで、General Instructions（テキストの指示文）にはビジネスコンテキストを3行だけ書きました。

これはECサービスのデータが格納されているスペースです。
ECカートからのトランザクションデータを元に、事業KPIを分析します。
日本語で回答してください。

この状態でいくつかの質問を投げてみた結果がこちらです。

質問 Genieの挙動 正誤
先月のGMVは？ キャンセル・返品済みの注文も含めて集計 ❌
先月の割引額は？ 割引関連の3カラムのうち1つだけで集計 ❌
先月の定期購入のGMVは？ データ値を英語で推測し、0件ヒット ❌
先月の1人あたり月間購入金額は？ 分子に使うべき指標を別の指標と混同 ❌
先月のキャリア決済のGMVは？ 一部の決済方法を集計から漏らした ❌

5問中、正解はゼロ。しかし、間違い方には共通するパターンがあります。

ビジネスルールを知らない
「KPI集計時にはキャンセル・返品を除外する」というルールをGenieは知りません。そのためフィルタなしで集計してしまいます。

言葉の定義が曖昧
「割引」と聞かれたとき、discountというカラム名だけを見てそれだけで完結したと判断しました。実際には複数のカラムを合算する必要があるのですが、ビジネスの定義を知らなければわかりません。

データの中身を知らない
受注種別カラムには「定期受注」「通常受注」という日本語の値が入っているのに、Genieは英語の 'subscription' で推測して何もヒットしませんでした。

似た指標を区別できない
税込の総額と税抜の売上高を混同したり、決済方法のグルーピングが期待と一致しなかったり。似た概念が複数存在する領域で間違いが起きやすいことがわかりました。

AIは知らないことを推測で埋めようとします。それ自体は賢い振る舞いですが、ビジネスでは「もっともらしい間違い」が一番危険です。ここから「AIに正しく教えていく」プロセスが始まります。

AIにデータを活用できるようにするためのステップ

先述のKnowledge Storeの機能を使い、実際に設定を追加してはテストし、間違えたらまた設定を足すという繰り返しで精度を上げていった過程を紹介します。

1. メタデータ整備 — まずAIにデータの地図を渡す

Genieがテーブル構造やカラムの意味を理解できなければ、そもそもSQLを正しく組み立てることさえできません。個人でClaudeを使うなら自分専用のテーブル定義書を作ってコンテキストに含めればいいですが、組織で複数人が使う場合にはスケールしません。

そこで重要になるのが、DatabricksのUnity Catalogでのメタデータ管理です。

テーブル・カラムの説明文

Unity Catalogではテーブルやカラムに対してCOMMENTを付与できます。

COMMENT ON COLUMN orders.subtotal IS '小計（税抜商品売上）。定期割引適用済み';
COMMENT ON COLUMN orders.total IS '注文合計（税込）。GMV計算に使用';
COMMENT ON COLUMN orders.revenue IS '売上高（subtotal + deliv_fee + charge）。税抜合計';

カラムの説明は「何が入っているか」だけでなく「何に使うか」「何と違うか」まで書くと、Genieの精度が大きく変わります。特に似た概念のカラムが複数ある場合（GMV / 売上高 / 商品売上など）は、区別を明示することが重要です。

Genie Space上の同義語

ユーザーはいつも同じ言い方で質問するとは限りません。「UU」「ユニーク顧客数」「月間ユーザー数」はすべて同じ指標を指しています。Genie SpaceのMetadata設定でカラムに同義語を登録しておくことで、こうした表記揺れを吸収できます。

Prompt Matching

Genieにはカラムの実際のデータ値を事前に認識させる機能があります。

  • Format Assistance: カラムからサンプルデータを取得して、どんな値が入っているかをGenieに学習させる
  • Entity Matching: カテゴリカラムのユニーク値をリスト化して保存し、ユーザーの言葉と実際のデータ値をマッチさせる

たとえば先ほどの「定期購入のGMV」問題。これは受注種別カラムの値が日本語であることをGenieが知らず、英語で推測してしまったことが原因でした。Prompt Matchingを有効にすることで、Genieは実際のデータ値を事前に把握した状態で質問に答えられるようになります。

ただし、Prompt Matchingは値を「見せる」機能であり、「使わせる」保証はありません。あくまで補助的な役割です。確実にビジネスロジックを定義するには、次のステップが必要です。

2. SQL Expressionでビジネスロジックを定義する

自然言語での質問には、データ上の定義とのギャップが必ず存在します。ユーザーが「売上」と言ったとき、それがGMV（税込総額）なのか売上高（税抜）なのか商品売上（商品のみ）なのかは、ビジネスの文脈を知らなければ判断できません。

Genie SpaceのKnowledge Storeでは、SQL ExpressionとしてこのビジネスロジックをSQLで直接定義できます。SQL Expressionには3つの種類があります。

Filter — 条件の定義

「有効注文のみで集計する」というビジネスルールをFilterとして定義します。

名前 SQL 同義語 Instructions
有効注文 orders.state NOT IN ('canceled', 'returned') 有効注文, KPI対象 GMV・売上・注文数など金額や数量を集計するクエリでは必ず適用すること。キャンセル分析時のみ適用しない

Filterを設定する前は集計に不要なデータが含まれていましたが、設定後は正しい値が返るようになりました。

Measure — 指標の定義

ビジネスで使うKPIの計算式をMeasureとして定義します。

名前 SQL 同義語 Instructions
割引額 SUM(orders.subscription_discount + orders.discount + orders.point) 割引額, 割引合計, 値引き 定期割引 + クーポン割引 + ポイント利用の合計

設定前は割引に関連するカラムのうち1つだけが使われていましたが、設定後は3カラムの合算で正しい値を返すようになりました。

同様に、「1人あたり月間購入金額」もMeasureで定義することで、分子と分母に使う指標が正しく固定され、安定して正確な結果が得られるようになりました。

Dimension — グルーピングの定義

データ上は複数種類ある決済方法を、ビジネスで見たいグループにまとめるDimensionを定義します。

CASE 
  WHEN orders.payment_method IN ('ドコモ払い','au決済','ソフトバンク払い') THEN 'キャリア決済'
  WHEN orders.payment_method = 'クレジットカード' THEN 'クレジットカード'
  WHEN orders.payment_method LIKE '後払い%' THEN '後払い'
  ELSE orders.payment_method 
END

Dimensionを定義する前は、Genieが毎回自力でCASE WHENを書いていたため、聞き方によってグルーピングが変わるリスクがありました。定義後は「決済グループ別のGMVは？」と聞くだけで毎回同じロジックが適用されます。

3. Example SQLで信頼性を引き上げる

SQL Expressionが「部品」だとすると、Example SQLは「完成品の見本」です。よくある質問パターンに対する正解SQLを丸ごと登録しておくことで、Genieはそのテンプレートを参考にSQLを生成します。

Example SQLの設定で重要なポイントが3つあります。

1. タイトルはユーザーが実際に聞く質問文にする

Genieはタイトルとユーザーの質問をマッチングしています。「定期購入GMVクエリ」ではなく「先月の定期購入のGMVは？」と書くことで、マッチング精度が上がります。

2. Usage Guidanceでいつ使うかを明示する

「定期購入のGMV」「定期のGMV」「サブスクのGMV」と聞かれたとき、のように具体的な発動条件を書きます。

3. 全Example SQLに共通のフィルタパターンを含める

これが最も効果的でした。すべてのExample SQLに有効注文フィルタを含めておいたところ、Example SQLに直接マッチしない新しい質問に対しても、Genieが同じフィルタパターンを自然に適用するようになりました。Example SQLはGenieにとって「スタイルテンプレート」としても機能するのです。

-- タイトル: 定期購入のGMVは？
SELECT SUM(orders.total) AS gmv
FROM orders
WHERE orders.kind = '定期受注'
  AND orders.state NOT IN ('canceled', 'returned')
  AND fct_orders.order_date >= :start_date
  AND fct_orders.order_date < :end_date

Example SQLをパラメータ化すると、そのクエリがそのまま使われた場合に応答に「Trusted」ラベルが付きます。これはGenieが検証済みのクエリをそのまま実行したことを示すもので、結果の信頼性をユーザーに保証する仕組みです。

究極的には、レビュー済みのクエリが使われるのが一番精度が高く、出力が安心できます。Trustedラベルがどんどんつくようになれば、ユーザーがデータを疑う回数は極端に減っていきます。

General Instructionsは最後の手段

ここまでの3ステップで、大半の課題は解決します。General Instructionsには何を書いたかというと、最終的にこれだけです。

これはECサービスのデータが格納されているスペースです。
ECカートからのトランザクションデータを元に、事業KPIを分析します。
日本語で回答してください。

たった3行。なぜこれだけでいいのかというと、テキストの自然言語指示はGenieの行動を強制する力が最も弱いからです。

Genieは複合AIシステムであり、単一のLLMではありません。テーブルのメタデータ、SQL Expression、Example SQL、サンプル値、チャット履歴など、周辺のあらゆる情報を総合的に参照してSQLを生成します。多くの場合、General Instructionsに書きたいことは、SQL ExpressionやExample SQLでより堅牢に定義できます。

実際、当初はGeneral Instructionsに「KPI集計時はキャンセル・返品を除外すること」と書いていましたが、それだけでは適用されないケースがありました。SQL ExpressionのFilterとして定義し、さらにExample SQLのパターンで学習させることで、ようやく安定して適用されるようになりました。

Databricksの公式ドキュメントでも「instructionsは他の方法で対応できない場合の最終手段」と明記されています。

Knowledge Storeを育てた結果

ここまでの設定を積み重ねた結果、冒頭で全問不正解だった質問に対して、すべて正しい値を返せるようになりました。

対策したのは以下のようなシンプルな設定の積み重ねです。

  • SQL Expression: Filter、Measure、Dimensionの定義
  • Example SQL: よくある質問パターンの正解SQLを登録
  • Prompt Matching: カテゴリカラムの値を認識させる

一つひとつは小さな設定ですが、それぞれが特定の間違いパターンに対応しており、積み重なることでGenieの応答精度は着実に向上していきます。

育てたGenie Spaceを組織で活用する

Genie Spaceをある程度チューニングしたら、次はそれを組織で活用して育てるフェーズです。

Genie MCP — ClaudeからGenieを直接使う

DatabricksのManaged MCP Serverを使えば、Genie SpaceごとにMCPエンドポイントを作成できます。

https://<workspace>/api/2.0/mcp/genie/<genie_space_id>

これをClaude.aiのConnectorに登録すると、普段使いのClaudeから直接Genieに質問できるようになります。ユーザーはDatabricksの操作を覚える必要がなく、いつも使っているClaudeで自然言語で質問するだけです。裏側でGenieがKnowledge Storeを参照しながら正確なSQLを生成し、結果を返します。

弊社ではClaudeを全社展開しているため、各部門のGenie Spaceを作ってそれぞれのMCPをClaudeに登録すれば、非エンジニアでも自分の部門のデータに自然言語でアクセスできる環境が作れます。

Monitoringで改善サイクルを回す

Genie SpaceのMonitoringタブでは、ユーザーが実際に投げた質問と応答を確認できます。うまく答えられなかった質問は、Benchmarkに追加し、Knowledge Storeの設定を改善し、再度評価する。このループをチームで地道に回していくことが、Genie Spaceの精度を継続的に向上させる鍵です。

おわりに

AIが自社データを"わかる"ようになるには、一度の設定では終わりません。使って、間違いを見つけて、設定を足して、テストする。その繰り返しです。

改善は地道ですが、これをやり切った組織とそうでない組織では、プロダクト改善のスピードや事業成長のスピードに取り戻せないほどの差が生まれてくると考えています。

AIの進化によって、データ分析の主役はSQLを書けるエンジニアから、事業を深く理解しているビジネスメンバーへとシフトしていきます。そのとき、AIが正しく答えてくれるための「土台」を整えておくことが、データ基盤をみるエンジニアの役割の一つだと思っています。私たちの組織ではこれを全社を巻き込んで主導していきたいと思っています。

エブリーでは一緒に働く仲間を募集中です！
エンジニアブログをきっかけに少しでも興味も持っていただけたら、まずはカジュアルに面談しましょう！