概要
社内データにAIで答えさせる仕組みを作るとき、「とりあえずすべてRAGに入れる」という方針で始めるケースがよく見られます。マニュアルや議事録はそれで答えられるようになりますが、「先月の品種別の不良率は？」と聞くと、もっともらしいが合っていない数字が返ってきます。逆に、すべてをデータベースに入れてSQLで答えさせようとすると、「前回と同じ症状の故障事例は？」という質問に答えられません。
原因は、データと質問の性質に合わない経路を使っていることにあります。AIが社内データを参照する経路には、大きく分けて SQL（LLMがSQLを書き、データベースが計算する） と RAG（文書を意味で検索し、根拠となる断片をLLMに渡す） の2つがあります。どちらか一方に寄せるのではなく、データの性質で振り分け、必要なら1つの質問の中で両方を使う のが基本です。
データの性質ごとの判断軸、質問の型ごとの振り分け、両方を連鎖させる設計、取込の段階での振り分け方を順に解説します。
2つの経路は何が違うのか
SQL：LLMは式を書き、計算はデータベースが行う
SQL経路では、LLMはテーブルの列定義を見て「どう計算するか」をSQLとして書き、実際の集計はデータベースが行います。LLMが数字そのものを生成するわけではないため、合計・件数・平均といった値は正確です。データベースの今の状態を読むので、在庫やステータスのように刻々と変わる値もその場の最新値で答えられます。
一方で、SQLは「似ているもの」を探すのが苦手です。LIKE '%異音%' のような文字列一致では、「ガタつき」「振動が大きい」と書かれた事例を拾えません。
RAG：文書を意味で探し、根拠の断片を渡す
RAG経路では、文書をチャンク（断片）に分けてベクトル化しておき、質問に意味の近いチャンクを探してLLMに渡します。表現が違っても内容が近ければ見つかるため、マニュアル・議事録・設計書・過去事例のような長文の検索に向いています。
ただし、RAGが渡すのは 質問に近い数件の断片 です。全件を読んで足し合わせるわけではないため、集計には使えません。表のデータをRAGに入れて「合計は？」と聞くと、たまたま検索に当たった数行をもとにLLMが計算することになり、結果は近似にしかなりません。また、取り込んだ時点の内容で検索するため、元データが変わったら取り込み直す必要があります。
判断軸：データの性質で振り分ける
どちらの経路を使うかは、データと質問の性質で決まります。
| データ・質問の性質 | SQL | RAG | 例 |
|---|---|---|---|
| 構造化・テーブル形式 | ◎ | △ | 売上、顧客マスタ、在庫、センサー時系列、勤怠 |
| 非構造化・長文 | △ | ◎ | マニュアル、議事録、設計書、メール本文、過去事例 |
| 集計が必要（SUM・COUNT・AVG） | ◎ | × | 月次売上、品種別不良率、エリア別契約数 |
| 類似性の検索（「似たもの」） | × | ◎ | 同じ症状の故障事例、似たクレーム |
| 最新値が必要 | ◎（常に最新） | △（再取込が必要） | 在庫、ステータス、稼働状況 |
| 件数が非常に多い | ◎ | △（埋め込みのコスト） | 大量の取引明細、ログ |
| 正確性が必須（金額・数量） | ◎ | ×（近似） | 売上集計、原価計算、見積もり |
| 意味の理解が必要 | △（LLMがSQLを書く） | ◎ | 「解約リスクのありそうな顧客」 |
| 元データの構造が変わる | ◎（スキーマ変更で即対応） | △（再チャンクが必要） | 日次で更新される集計表 |
判断に迷ったときは、次の2つを確認します。
- 答えに正確な数字が必要か：必要ならSQLです。RAGの答えは検索に当たった範囲での近似です。
- 探したいものは「条件に合う行」か「内容が近い文章」か：前者はSQL、後者はRAGです。
質問の型で見る振り分け
利用者が実際に投げる質問で考えると、振り分けはより具体的になります。
| 利用者の質問 | 適した経路 |
|---|---|
| 「先月のトップ顧客は？」 | SQL（SUM＋GROUP BY） |
| 「在庫はいくつある？」 | SQL |
| 「先月の不良率を品種別に」 | SQL（集計＋グラフ） |
| 「○○社との過去の案件はあった？」 | RAG（案件資料・議事録） |
| 「APIの仕様書を見せて」 | RAG（技術文書） |
| 「似たクレームを調べて」 | RAG |
| 「解約しそうな顧客は？」 | SQL（条件抽出）＋LLMの判断 |
| 「設備に故障の予兆はある？」 | SQL（センサー時系列）→ RAG（過去事例）の連鎖 |
最後の2つのように、1つの質問の中で両方の経路が必要になるものがあります。これを最初から想定しておくことが、両方の経路を持つ理由です。
両方が要る質問：連鎖させて答える
製造業の予知保全の例
「設備に故障の予兆はある？」という質問には、次の順で答えるのが自然です。
- SQL：センサー時系列から、直近7日間で閾値を外れた値や傾向の変化を抽出する
- RAG：見つかった症状（例：「主軸温度の上昇と振動の増加」）をもとに、過去の故障事例と修理手順を検索する
- LLM：数値の事実と過去の事例をあわせて、点検の優先度と手順を提案する
SQLだけでは「その症状が過去に何を意味したか」が分からず、RAGだけでは「今どの設備で異常が起きているか」が分かりません。連鎖させることで、事実は表から、解釈と手順は文書から という役割分担になります。
業務別の構成例
同じ考え方は他の業務にも当てはまります。
顧客サポート 取込: 過去の問い合わせ・製品仕様書 → RAG / 顧客マスタ → データベース 回答: RAGで過去事例を検索 + SQLで顧客の契約状況を参照 + 必要ならチケットを起票 営業支援 取込: 商談データ → データベース / 提案資料・議事録 → RAG 回答: SQLで「今月の見込み」を集計 + RAGで「過去の類似案件の提案」を検索 予知保全 取込: 設備ログ → データベース（時系列） / 故障事例・修理マニュアル → RAG 回答: SQLで異常パターンを抽出 + RAGで類似症状の修理手順を検索 + 作業指示を登録
いずれの構成でも、LLMには両方の道具を渡し、質問に応じてどちらを使うかを選ばせます。どちらを先に呼ぶかを人が固定的に決めるのではなく、道具の説明（「集計にはこちら」「文書の検索にはこちら」）を明確にしておくのがポイントです。
取込の段階で振り分ける
使い分けは質問のときだけでなく、データを取り込む段階から始まります。データソースを見て、次のように判定します。
データソースを見る ├ テーブル形式か？（CSV・DB・APIのレスポンス） │ → データベースに入れる（SQL経路） ├ 長文の文書か？（PDF・Word・Markdown・社内Wiki） │ → ナレッジに取り込む（RAG経路） ├ 両方を含むか？（構造化データ＋添付文書） │ → 両方に入れ、AIが道具を使い分ける └ 今この瞬間の値が要るか？（現在の在庫・ステータス） → どちらにも入れず、業務システムのAPIを直接呼ぶ
「両方を含む」データは製造業で特に多く見られます。不具合報告であれば、発生日・品番・工程・件数は表に、現象の説明・原因の考察・対策の文章はナレッジに入れます。品番や発生日をRAGのメタデータとして持たせておけば、文書の検索を条件で絞り込むこともできます。
「SQLの結果をRAGに入れる」場合の注意
SQLの集計結果を文書としてRAGに入れたい場面もあります。たとえば「月次の品質会議で使った集計表」を、議事録と並べて検索できるようにしたい場合です。この場合、ナレッジに入るのは 取り込んだ時点の結果 です。元データが更新されても、ナレッジ側の数字は変わりません。
DigitalBaseでも、SQL画面で表示中の結果をナレッジに取り込めますが、自動では取り込み直さない設計にしています。クエリを直すたびに入れ直すと、ナレッジの中身が意図せず変わってしまうためです。最新の数字を聞きたいときは、チャットからデータセットやSQL接続を直接読ませます。AIがSQLを使うときは、既定の権限モードではSELECTのような読み取りは自動で実行し、更新を伴う文は利用者の承認を求める、という権限の段階を分けています。
よくある失敗と回避策
- 明細表をRAGに入れて集計させる → 集計が必要な表はデータベースに入れ、SQLで答えさせる
- 文書の検索をSQLのLIKEで済ませる → 表現の揺れを拾えないため、文書はRAGに入れる
- RAGに入れた数字を「最新」として答える → スナップショットであることを出典に明示し、最新値はSQLかAPIで取る
- AIに更新系のSQLまで自由に実行させる → 読み取りと更新で権限を分け、更新は承認を挟む
- どちらの道具を使うかの説明がない → 道具の説明に「集計」「文書検索」の用途を書き分ける
導入の進め方
- データの棚卸し：データベース・SaaS・ファイル・APIなど、データソースを一覧にする
- 性質の判定：各ソースが構造化か、非構造化か、リアルタイム性が必要かを判定する
- 経路の振り分け：SQL・RAG・APIの直接呼び出しのどれにするかを決める
- 取込フローの構築：データベースへのロード、ナレッジへの取込を定期処理として固定する
- AIに渡す道具の設定：質問の範囲に合わせて、データセット・ナレッジ・API連携を選ぶ
- 試行と調整：実際の質問で、どの道具が呼ばれたか・答えが正しいかを確認する
まとめ
社内データに答えるAIでは、SQLとRAGのどちらか一方で済ませようとすると、必ず答えられない質問が残ります。
- SQL：集計・最新値・金額や数量など、正確さが必要な答えに使う
- RAG：マニュアル・議事録・過去事例など、内容の近さで探す答えに使う
- 両方：予知保全のように、事実を表から取り出し、解釈と手順を文書から引く質問では連鎖させる
- どちらにも入れない：今この瞬間の値は、業務システムのAPIを直接呼ぶ
経路の振り分けは、データを取り込む段階から始まります。データの棚卸しで性質を判定し、それぞれに合った経路に入れておくことで、AIは質問に応じて適切な道具を選べるようになります。