💡 この記事の3行まとめ

AIに社内データを聞いて数字が合わないのは、 モデルの性能ではなく自社特有の前提（コンテキスト） が欠けているため。

意図的に罠を仕込んだデータに対しクエリ検証を実施。3つの定義層（コメント・Metric Views・エージェント指示） がそれぞれカバーする範囲と、矛盾時の挙動を検証した。

結論： 既存DBの変更が難しい以上、まずはカラムコメントによるメタデータの整備が不可欠。PoCの完了条件は、正解が出ることではなく複数回投げて答えが揃うこと。

この記事は誰向けか

この記事は、以下のように考えている方へ向けて書いています。

• 社内データにAIで質問できる状態を作りたい
• databricksを一度試したが、精度が出ずに止まっている
• Genieが返す数字が業務側の数値（経理など）と合わず、現場展開できていない

3つ目に心当たりがあれば、特に刺さる内容だと思います。

本記事では、実運用で必ず直面する「数字が合わない」問題に対し、どこから・どの順で・どこまでの範囲で 設定を追加すべきかを実測データをもとに解説します。

💡検証環境はDatabricks無料トライアル、期間は2026年8月です。 機能の提供状況はアップデートにより変わる可能性があります。

AIに足りないのは知能ではなくコンテキスト

Genieの概要とサミットのメッセージ

Databricks Genieは、自然言語の質問からSQLを自動生成し、データ集計やグラフ化を行う機能です。これにより、SQLを書けないビジネス部門でも自らデータにアクセスできるようになります。
（※詳しい仕様は公式ドキュメントでご確認ください。）

2026年6月のData + AI Summitでは、「AIにデータ業務を任せる」という方向性が示されました。その中で繰り返し強調されていたのが以下のメッセージです。

「AIに足りないのは知能ではなく、コンテキストである」

モデル自体の性能は十分に高く、不足しているのは「その企業独自の用語定義やデータの仕様」であるという指摘です。これは実際の検証でも明確に現れます。

検証：前提条件を与えずに質問した場合

検証用として、小売チェーンを想定した売上データ（4テーブル）を用意しました。
このデータをGenieに接続し、コンテキスト（定義）を何も与えずに質問してみます。

エリア別の売上を見せて

返ってきた結果は以下の通りです。

一見すると、何の問題もありません。関東が最も大きく、関西が続く。感覚とも一致します。

しかし正解はこうでした。

関東だけが627万円、上振れしています。

なぜこのズレに気づけないのか

原因は、

• テスト用のダミー店舗の売上が含まれていた
• 返品処理分を除外していない

によるものです。

ここでの問題は、出力された結果の大小関係に違和感がないため、経理などの正確な数値と突き合わせるまで誤りに気づけない点にあります。
この一見もっともらしい嘘が、AI導入を諦める大きな原因になります。
しかし、用意したデータ自体に欠損や誤りはありません。

「売上とは税抜であり、返品を含まず、テスト店舗は除外する」

という社内ルール（コンテキスト）が、AIに共有されていないことが原因です。

検証用データとメタデータの重要性

4つのテーブル

検証では、実務の社内DBでよく見られる構造を模したデータを使用しました。

実務で直面するデータの仕様

上記のデータには、意図的に以下の仕様を持たせています。

• 金額列の複数存在: amount_01（税抜）と amount_02（税込）が存在する。（名前からは判断できない）
• フラグ処理の必要性: flg_03 が返品フラグ。除外しないと売上が過大計上される。
• テストデータの混入: store_master.flg_01 がテスト店舗を示す。
• 欠損データの存在: 今年オープンの新店舗には前年データがない。

列名変更の限界とメタデータの役割

検証の初期段階では、列名を net_amount（税抜金額）や is_returned（返品フラグ）といった分かりやすい名前にしていました。すると、Genieは定義を与えなくても正しく税抜を選び、返品を除外しました。LLMが列名の文字列から意味を推論したためです。

しかし、長年稼働しデータを蓄積している実際のデータベースにおいて、テーブルやカラムの物理名をAIのために変更することは非現実的です。多くの基幹システムでは amount_01 のような記号的な名称が使われています。

この前提に立つと、「ユーザーが後から付与できるdescription（カラムコメント）によるメタデータの整備」が、AIの精度向上において極めて重要になります。

他の業界ではどうか

小売の例で書いていますが、構造はどの業界にも転用できます。

自社に置き換えて読んでいただければと思います。

Databricksには定義を書く場所が3つある

Databricksでは、このコンテキスト（メタデータやルール）を付与する場所が複数存在します。今回は以下の3つの層を用いて検証を行いました。

第1段：テーブル／カラムコメント

COMMENT ON COLUMN 等で、列に自由文で説明を付ける機能です。
用途： データの意味や「テスト店舗は除く」などの条件を言葉で伝える。

COMMENT ON COLUMN workspace.default.pos_sales.amount_01 IS
'税抜金額（円）。社内で「売上」と言う場合はこちらを指す';

第2段：Metric Views

指標の定義をYAMLで記述するセマンティックレイヤーです。ディメンションとメジャーを定義し、MEASURE() 構文で参照します。
用途： 粗利率など、複雑な計算式を機械的に強制する。

measures:
  - name: 粗利率
    expr: (SUM(...) - SUM(...)) / SUM(...) * 100

第3段：Genieエージェントの指示

Genieエージェントごとに、回答の前提ルールをプロンプトとして記述する領域です。
用途：「売上を聞かれたら必ず〇〇の指標を参照する」といった全体の方針を制御する。

全体像

それぞれの層は役割が異なり、設定したい内容によって適切な層を選ぶ必要があります。

これらの層に設定が重複した場合の優先度や、各層の具体的な効果について、次章の実測データで解説します。

段階的なクエリ検証（全６０回）

測り方

各定義層がどのようにGenieのSQL生成に影響を与えるかを確認するため、定義が何もない状態（ベースライン）から設定を積み上げ、同じ質問を投げる検証を行いました。

検証のステップ
本検証は、設定を一つずつ上乗せしていく積み上げ式で行っています。
また、レベル（L1〜L3）の数字は、「データ基盤に近い部分」から順に設定しています。

質問リスト

まぐれ当たりを排除するため、各条件で3回ずつ（5問 × 4段階 × 3回 = 合計60回）実行し、生成されたSQLのロジックを評価しました。

結果

⭕...数値が正解と一致し、使用した列と除外条件も正しい
△...数値は近いが、計算の経路に問題がある（単位の不整合など）
×...数値が誤っている、または回答できない

各条件で3回実行し、多数決で判定しています。
設定を追加するごとに回答精度は向上しますが、Q4（在庫回転）に関しては最終段階で逆に悪化する結果となりました。

各層で起きた事象を整理

第１段（カラムコメント）の効果と限界

ベースの状態ではテスト店舗や返品データがそのまま集計されていましたが、第１段でコメントを付与した結果、対象カラムが参照されたクエリにおいては、除外条件が正確に適用されるようになりました。

一方で、コメントだけでは防げないエラーも確認されました。Q2（粗利率）において、Genieが SUM(amount_01 * quantity) というSQLを生成しました。amount_01 にはすでに数量が加味された金額が入っているため、数量を二重に掛けてしまい、金額が異常値になるというロジックエラーです。

つまり、コメントは「どの列を使うか」「どの条件を除外するか」を伝えるのには有効ですが、「その列をどう演算するか」という計算式までは強制できないことが分かります。

第２段（Metric Views）による計算式の固定

上記のエラーに対し、第２段で粗利率を MEASURE として式で定義したところ、生成されるSQLの二重計上が解消され、3回とも正しいロジックで出力されるようになりました。
計算式をシステム側で固定することで、LLMが自己解釈で誤った演算を行う余地をなくすことができます。

しかし、Metric Viewを定義してもGenieが自発的にそれを使用するとは限りません。
単純な集計などでは生テーブルに直接クエリを投げる傾向が見られました。

第３段（エージェント指示）による誘導と副作用

そこで第３段として、エージェントの設定に

「粗利率・売上・原価を聞かれた場合は、生テーブルで再計算せず、必ず定義済みのMetric Viewを参照すること」

という指示を追加しました。これにより指定した指標の利用率が向上しました。

ただし、Q4（在庫回転）については指示を追加したことで結果が大きく崩れました。
在庫回転の計算には、売上テーブル（分子）と在庫テーブル（分母）の両方が必要です。
Genieがこれらを直接結合しようとした結果、行の掛け合わせ（Join Explosion）が発生し、本来132万円であるはずの特定カテゴリの売上原価が、約1億2,090万円として出力される事態となりました。

複数テーブルをまたぐ複雑な指標は、Genie上での定義だけでは処理しきれません。
事前に結合・集計済みのデータマートやビューを用意するなど、データモデリング側での根本的な対応が必要です。

マニュアルに書かれていないGenieの仕様と挙動

公式ドキュメントには明記されていないものの、実運用において設計の壁となる仕様を整理します。

各定義層の「守備範囲」と限界

定義層は万能ではなく、コントロールできる範囲が明確に分かれています。

※複数テーブルをまたぐ複雑な結合は、どの層でも制御しきれません（事前モデリングが必要）。

ここで最大の罠になるのが「複数テーブルの結合」です。
Q4（在庫回転）のように、売上テーブルと在庫テーブルをまたぐ処理をGenieに任せると、意図しない行の掛け合わせ（Join Explosion）が起きます。実際、設定を追加した最終段階でも売上原価がかなり膨張しました。
複雑な結合はGenie上で解決しようとせず、事前にデータマート側で済ませるのが鉄則です。

定義の競合時の優先順位

実運用で定義が複数箇所に重複・矛盾した場合Genieでは
一時的な上書きは「チャット指示」、恒久的なルールは「カラムコメント」が最優先されます。

Genieは、同じ定義が複数箇所で矛盾した場合、以下の優先順位で処理を行います。

1. チャット内の指示（例：「税抜で計算して」と直接打ち込む）
2. カラムコメント（データベースのメタデータ）
3. エージェント指示 / Metric Views

「カラムコメント＝税込」「エージェント指示＝税抜」と矛盾させた検証では、エージェント側の指示は無視され、すべて下位層である「カラムコメント（税込）」が出力されました。

しかし、そのチャット画面で直接「税抜を使って」とユーザーが指示すれば、コメントの設定を無視して即座に税抜で再計算されます。
ただし、このチャット指示の効果はそのチャットを閉じるまでです。新しいチャットを開くと、再びカラムコメント（税込）に引きずられます。

つまり、その場しのぎの修正はチャットの指示で足りますが、「組織全体の恒久的なルール」として定義を効かせたいなら、大元であるカラムコメントを直すしかないということです。UI（エージェント）の指示欄にいくらルールを書き連ねても、根っこのコメントが古ければGenieはそちらを優先してしまいます。

解釈のブラックボックス化

Genieの回答精度が上がる（あるいは矛盾を処理する）につれて、利用者が根拠を確認しづらくなるというトレードオフが存在します。

• 矛盾を黙って処理する: コメントと指示が矛盾している際、Genieは裏で両方を認識していますが、回答時には「どちらを採用したか」「なぜ選んだか」を一切言及せず、数値を断定します。
• 除外条件の説明が減る: Metric Viewsを用いた（正答率が高い）出力では、回答文に「返品を除外した」などの計算根拠の説明がほとんど出力されなくなりました。

「出力された数値が正しいこと」と「それが正しいとユーザーが確認できること」は別問題であり、運用上、利用者が検証する手がかりが減る点には注意が必要です。

クエリの「ブレ」は不足しているコンテキストのシグナル

同じ条件で同じ質問を3回実行した際、質問によって出力ロジックの再現性が大きく異なりました。

Q3は最初「既存店」の解釈が定まらず、結果が毎回大きく変動（+3.9% → +9.1% → −36.9%）しましたが、エージェント指示で既存店の定義を与えた途端に数値が完全に一致するようになりました。

💡 ブレを「検知の道具」として使う
テスト時に「投げるたびに答えがブレる質問」を見つけた場合、それはモデルの気まぐれではなく、その箇所にコンテキスト（定義）が不足しているという強力なシグナルです。ここを優先的に定義化することが、効率的な精度向上に繋がります。

現場目線のデータ整備とPoCの進め方

ここまでの検証結果を踏まえ、Databricks Genieを実業務に導入する際の実践的な進め方を提案します。

地道なデータ整備

「コメント（メタデータ）を追加すれば精度が上がる」と書くのは簡単ですが、実務において最もコストがかかるのはコンテキストをどこから探し出し、合意をとるかというプロセスそのものです。

既存のデータベースの多くは、設計当時のドキュメントが古くなっていたり、構築した担当者がすでに退職していたりします。
結果として、データエンジニアが過去のソースコードやダッシュボードのクエリを解読し、営業部門や経理部門にヒアリングを行って「うちの会社における『売上』や『既存店』の定義」を一つずつ言語化し、関係者間で合意形成を行う必要があります。

Genieを現場で使えるレベルに引き上げるための本体は、この業務知識の棚卸しと定義化にあります。

スモールスタートで検証範囲を絞る

この合意形成のコストは、対象とする指標やテーブルが増えるほど跳ね上がります。そのため、全社横断のデータに対して一度にGenieを導入しようとすると、定義のすり合わせだけでプロジェクトが頓挫します。

まずは答えたい問いから逆算して、検証スコープを小さく切ることが重要です。

推奨スコープ例: 1つの事業部、5つの主要指標、2週間程度の期間

💡初回に外すべきもの:
複数テーブルをまたぐ複雑な比率（在庫回転など）
これらはデータモデリング自体の見直しが必要になるため、第2フェーズ以降に回します。

PoCの完了条件は「ブレがなくなること」

Genie導入のPoCにおいて、「正解の数字が出た」ことを完了条件にするのは危険です。
検証で示した通り、LLMは解釈が定まっていない状態でもそれらしい数字を出力します。

評価の基準は、「対象の指標について3回質問を投げ、3回とも同じ集計ロジック（SQL）で結果が揃うこと」に置くべきです。
ブレがなくなるまでメタデータ（カラムコメント等）に業務要件を落とし込むことが、現場で信頼されるAI構築の第一歩となります。

おわりに

Databricks Genieは非常に強力なツールですが、万能ではありません。「自社の業務ロジック」というコンテキストを与え、正しくデータと向き合うことで初めて、自律的にデータを活用できる環境が実現します。

参考

• Genie One、Genie Agents、Genie Ontology のご紹介（Databricks公式ブログ）
• Databricks プレビューの管理
• Metric Views（公式ドキュメント）