dbtとセマンティックレイヤーで、LLMに「正しい数字」を答えさせる

「先月の新規ユーザーのうち、有料転換した割合は？」。この質問をLLMに投げて、正しい答えが返ってくる会社はまだ少数です。返ってくるのは、それらしいSQLと、それらしい数字。検算すると合っていない。原因はLLMの能力ではなく、「新規ユーザー」と「有料転換」の定義が、どこにもコードとして存在しないことにあります。

生のテーブルをLLMに渡してはいけない

よくある構成は、LLMにデータベースのスキーマを見せ、自由にSQLを書かせるものです。これは、入社初日の人に生のテーブルを渡して「売上を出して」と頼むのと同じです。テーブルには、テスト用のダミー行、キャンセル済みの注文、二重に登録されたユーザーが混ざっています。それを知らなければ、人でもLLMでも間違えます。

定義をdbtのモデルにする

解決策は、LLMに渡す前に、指標の定義を確定させることです。私たちはdbtを使います。

• stg_ 層で、ソースのテーブルからテスト行やキャンセルを除き、型とタイムゾーンを揃える
• int_ / fct_ 層で、「注文」「ユーザー」といった業務上の単位に整える
• metrics として、「新規ユーザー数」「有料転換率」の計算式を定義する

この時点で、指標は人が読めるSQLとして存在し、バージョン管理され、テストで守られています。BIもこの定義を参照します。LLMにも、同じ定義を参照させます。

セマンティックレイヤーが果たす役割

セマンティックレイヤーは、「指標の名前」と「その計算方法」を対応づける層です。LLMには生のSQLを書かせず、「有料転換率を、先月、新規ユーザーで」という指標・期間・条件の組み合わせを選ばせます。実際のSQLはセマンティックレイヤーが生成します。LLMの仕事は「どの指標を、どの条件で」を理解することに絞られ、計算そのものは定義済みのロジックが担います。

この設計にすると、三つのことが起きます。答えが毎回同じになる。BIの数字と一致する。間違えたときに、定義を直せば全部が直る。

メタデータが精度を決める

もう一つ効くのが、テーブルと指標の説明文です。dbtの description に、「このテーブルにはテスト注文が含まれない」「有料転換は初回課金日で判定する」といった注意書きを残しておくと、LLMはそれを読んで指標を選びます。人向けに書いたドキュメントが、そのままAIの精度を上げる。ここが、データ基盤とAI活用がつながる一番分かりやすい場所です。

まとめ

LLMに正しい数字を答えさせる道筋は、モデルの調整ではなく、定義の整備にあります。dbtで指標をコードにし、セマンティックレイヤーで指標を選ばせ、メタデータで判断材料を渡す。この三点が揃った基盤は、AIが「安心して読める」状態になっています。私たちが「AIが本当に使えるデータ基盤」と呼んでいるのは、この状態のことです。