AnyDigiAnyDigi
技術

セマンティック層 vs ピュアRAG: 業務分析にはなぜSQLが必要か

この記事でわかること

  • RAG（Retrieval-Augmented Generation）が業務分析で破綻する理由
  • 「文章で答える」と「数字で答える」のあいだにある根本的な違い
  • セマンティック層が果たしている役割
  • AnyDigi の AI Lab デモで採用した実装の判断

RAG が崩れる瞬間

ベクトルDBにドキュメントを入れて、関連する箇所を検索して、LLM に渡して答えさせる。RAG の基本パターンだ。

これでデモは動く。社内文書の検索や、ヘルプ記事の要約くらいなら十分に使える。

崩れるのは、業務の 数字 を答えさせようとした瞬間だ。

「先月の関東エリアの売上は？」「直近3ヶ月で離脱率が悪化した顧客セグメントは？」「主力商品Aの在庫回転日数の推移は？」

こういう質問を、RAG はまともに答えられない。

理由はシンプルで、数字の答えは 文書のどこかに書かれているわけではない からだ。

答えはクエリの結果として生成される

業務の数字は、トランザクションテーブルや集計テーブルに対して SQL を実行した結果 として現れる。

  • 「先月の関東エリアの売上」 → SELECT SUM(amount) FROM orders WHERE region = '関東' AND month = '2026-04'
  • 「離脱率が悪化したセグメント」 → 顧客テーブル × 行動ログテーブルの集計クエリ

RAG が文字列を引っ張ってくる方式では、ここに到達できない。引っ張ってくるべき "答え" がそもそもどのドキュメントにも書かれていないからだ。

ここで必要になるのが、自然言語の問いを データ構造を理解した正確な SQL に変換する仕組み ――いわゆるセマンティック層だ。

セマンティック層がやっていること

セマンティック層を一言でいうと、「業務の語彙」と「データベースのスキーマ」のあいだに翻訳辞書を置く仕組みだ。

業務側は「関東エリア」と言う。データベース側では region_code IN ('13','11','12','14','08','09','10','03') だったりする。「離脱率」と言われても、定義は会社によって違う（90日無アクセス？解約申請？最終購入から180日？）。

セマンティック層がないと、LLM は毎回これらの対応を 推測 することになる。スキーマを直接渡しても、業務語との対応はほぼ知らない。だから生成される SQL は、構文としては動いても、業務的には間違っている。

セマンティック層がやっているのは、ざっくり以下:

  • 業務語と物理カラムの対応表を持つ
  • 集計の単位（メトリクス）を定義する（売上 = SUM(amount * (1 - tax_rate)) など）
  • ディメンション（切り口）の継承関係を持つ（関東 ⊂ 都道府県 ⊂ エリア）
  • 権限・除外条件をクエリに自動で挟む

この上で LLM が SQL を組み立てると、業務的に意味のある答えが返ってくる確率が一気に上がる。

AI Lab デモで採用した判断

AI Lab デモ（lab.anydigi.co.jp/demo）では、毎日 RSS で集めたニュースを「経営者・マネージャー・個人事業主・企画担当」の4つの立場で分析している。ここで扱うデータは数値もテキストも混在している。

実装で意識したのは、「文章で答える問い」と「数字で答える問い」をパイプラインの中で分岐させる ことだ。

  • カテゴリ抽出やテーマの言語化 → 通常の LLM プロンプト（テキスト処理）
  • 「件数」「割合」「期間比較」 → セマンティック層を経由した SQL 実行

この分岐をしないと、毎回 LLM が「とりあえずそれっぽい数字」を生成してしまう。AI が hallucinate する一番気持ち悪いパターンだ。

セマンティック層の実体は、TypeScript で書いた小さな対応表 + クエリビルダー + LLM のプロンプトテンプレートで、ライブラリを使わずに自作している。Cube や dbt Semantic Layer のような既存ツールも検討したが、AI Lab の規模では自作のほうが軽く、かつ AI 側からの問い合わせフォーマットを自由に決められる利点があった。

やってみた結果

セマンティック層を入れる前と後で、同じ問いに対する回答品質を1ヶ月運用して比較した。

数字を含む問いの正答率は、ピュア RAG 構成（スキーマ全文を LLM に渡してその場で SQL を書かせる）では体感5割程度。セマンティック層を経由したものは9割を超えた。

体感、という表現にしているのは、自動評価が難しい領域だからだ。SQL の構文が正しくても結果が業務的に間違っていることがあるし、その逆もある。最終的には人間が結果を確認する必要があった。この評価方法そのものについては、別の記事で書く。

ただ、運用していて確信したのは、「LLM に賢くなってもらう」より「LLM が触る世界を整える」ほうが効く、ということだ。スキーマと業務語の対応をきちんと書いてから AI に渡す。シンプルだが、ここをサボると上に何を載せても崩れる。

私たち AnyDigi は、社内データを AI で活用したい企業向けに、こうしたセマンティック層を含めた基盤の設計・実装を行っています。「ChatGPT に質問しても、業務の数字は返ってこない」という壁にぶつかっている方は、AI業務システム開発 のページもご覧ください。

← ブログ一覧に戻る