10月7日、Databricksが「AI-powered analytics: Building data visualizations with natural language vs. SQL」と題した記事を公開した。この記事では、自然言語クエリによるデータビジュアライゼーションがSQLと比べてどのように機能するか、そして信頼性の高い回答を生成するために何が必要かについて詳しく紹介されている。
なぜ10年経っても「自然言語でデータ分析」は現場に根付かなかったのか
自然言語によるデータクエリ（NL-to-SQL）は10年以上前から存在する技術だ。初期の研究事例は2010年代前半にさかのぼり、その後もさまざまなツールが登場してきた。それでもなぜ、現場で使い物にならなかったのか。
Databricksでビジネスインテリジェンス・アナリティクス製品のプロダクトマーケティングを統括するRichard Tomlinsonはその理由をこう述べる。「LLMがボトルネックだったのではない。コンテキストがなかったのだ」。
初期のNL-to-SQLは、言語をスキーマに変換する問題として扱っていた。単語をカラムにマッピングし、クエリを生成してチャートを返す。単純な検索なら機能するが、エンタープライズの複雑なデータには歯が立たない。現実のビジネスデータには、チーム間で定義が食い違う指標、テーブル間の曖昧なJOIN、メタデータではなく「人の頭の中にある」業務ルールが存在する。モデルが改善されても、生のテーブル名やカラムヘッダーから意味を推測するしかなく、同じ質問を2回投げると2つの異なる回答が返ってくるという問題が解消されなかった。
Tomlinsonが「変わったのはモデルの性能だけではない」と指摘するのは、この点だ。言語モデルの下にガバナンスされたセマンティックレイヤー（意味的文脈を管理する層）を設ける必要があると認識されたことが本質的な変化だという。このレイヤーが「このチームにとっての"revenue"は何か」「財務年度はいつ始まるか」「どのフィルターを常に適用すべきか」をAIエージェントに伝える。
信頼できる回答を全ユーザーに届けるための3条件
自然言語クエリは誰でも質問できるようにする。しかし「行動に移せるほど信頼できる回答」を返すことが本当に難しい部分だとTomlinsonは言う。そのためには次の3つが必要だ。
- データそのものがガバナンスされていること — カテゴリが一貫しており、重複レコードがなく、細かいアクセス制御によって各ユーザーが見られるものだけを見られる状態。
- データの意味が機械可読な形で明示されていること — 指標の定義、業務用語、主キー・外部キーの関係、認定済みのデータソースがUnity Catalogのようなシステムに登録されており、AIエージェントがクエリ時に参照できる状態。
- トレーサビリティ（追跡可能性）があること — AIが生成した回答を、それを生み出した定義・ソース・権限まで遡れること。「何を言ったか」だけでなく「なぜそう言ったか」をユーザーが確認できる。
この3条件を基盤として設計されたのが**Genie One**だ。Genie OneはDatabricksが提供する自然言語分析プラットフォームで、セマンティックレイヤー・ガバナンス・会話状態管理を統合した製品として位置付けられている。
セマンティックグラウンディングとは何か
セマンティックグラウンディングとは、AIエージェントの質問解釈を、カラム名から意味を推測させるのではなく、組織の実際の業務定義・関係・ルールに紐付けるプロセスだ。
具体的には、SQL生成の前の段階で、エージェントはすでに以下を把握している。
- 「net revenue」はどの計算式を使うか
- マーケティングのサマリーテーブルではなく、認定された財務テーブルを参照すること
- 財務四半期は2月始まりであること
- リテンション指標から無料トライアルユーザーを除外すること
Databricksでは**Genie Ontology**がこのコンテキストレイヤーを提供する。明示的にモデル化された知識（指標ビュー、認定済みソースなど）に加え、ダッシュボード・クエリ・ノートブック等の実際の利用履歴から自動的に学習したコンテキストも統合する。
学習された各コンテキスト片は「Ontology Snippet」と呼ばれ、ソース・利用頻度・鮮度・認定ステータスに基づく権威スコアを持つ。クエリ時には関連性と権威の両軸で競合するスニペットを評価・解決し、そのユーザーが参照を許可されたコンテキストだけを提供する。
会話の文脈を保持し続ける仕組み
「先四半期の売上は？」→「それを地域別に分解して」という連続した質問で、「それ」が何を指すかを理解し続けることが会話型分析における最大の技術的課題の一つだ。多くのNL-to-SQLシステムがここで失敗するとTomlinsonは指摘する。
Genieはスレッド内の会話状態を保持し、テーブル・カラムのメタデータ、エージェント編集者からの指示、過去の会話の文脈をすべて次の質問の解釈に反映する。曖昧なフォローアップがあれば、推測せずに確認を求める。また過去の会話を参照して（「先四半期のARRについて話したとき…あれを地域別にドリルダウンしよう」）、ユーザーが画面を離れることなくその文脈を引き継げる。
会話が長くなってもセマンティックグラウンディングにより「revenue」の定義は1ターン目と5ターン目で変わらない。また、関連するコンテキストを選択的に使うことで、コンテキストウィンドウを無駄に圧迫して生じる「ドリフト（回答のブレ）」を防いでいる。
既存ツールへの統合と権限の扱い
DatabricksはGenie統合の手段を複数提供している。
- Genie Conversation API — 自社アプリ、チャットボット、エージェントフレームワークに自然言語データクエリを組み込める
- Genie One MCPサーバー — Claude、ChatGPT、Microsoft Copilot、Cursorといった既存のAIアシスタントからGenieを使える。Databricks外でも同じ業務定義・データ権限が適用される
外部統合に推奨される認証パターンはOBO（on-behalf-of）OAuthだ。外部アシスタントがユーザーの代理として動作し、Genieがそのユーザーの権限をリクエストごとに適用する。同じチャットボットに同じ質問をした2人のユーザーが、それぞれ自分が参照を許可されたデータに基づく回答を受け取る仕組みで、ユーザーごとの特別な設定は不要だ。
詳細はAI-powered analytics: Building data visualizations with natural language vs. SQLを参照していただきたい。
