AIに社内データを触らせる前に読むDB設計・SQLの本｜RAGとText-to-SQLの土台を作る4冊

社内データをLLMに繋ぐ案件は、たいてい同じところで止まります。RAGに入れる文書の元テーブルが正規化されておらず、同じ顧客が3つの表記で入っている。Text-to-SQLを試したら、列名がflg_1やamt_ttlのような略号ばかりで、モデルが意味を推測しきれない。BIツール連携までこぎ着けても、「今月の売上」の定義が部署ごとに違って数字が合わない。どれもモデルを差し替えても解決しない種類の問題です。この記事では、AIに社内データを触らせる前に押さえておきたいDB設計・SQL・データ基盤の実在書籍を4冊、扱う範囲と扱っていない範囲まで含めて紹介します。なお本記事は書籍紹介であり広告を含みます。価格・版・在庫・目次は変わるため、最新は各公式・書誌ページでご確認ください。

なぜLLMの話なのに、DB設計の本なのか#

社内データ活用の相談は、入口が「どのモデルを使うか」であることが多いのですが、実際に手を動かすと論点が移動します。よく出会う詰まり方は次の3つです。

1つ目は、RAGのデータソース側です。文書だけでなく基幹データベースの中身をテキスト化して埋め込む構成はよくありますが、元のテーブルが1つの列にカンマ区切りで複数の値を持っていたり、同じ意味のマスタが2つ並存していたりすると、生成される文章が最初から矛盾します。検索側をどれだけ磨いても、根拠として渡す文章が壊れていれば回答は安定しません。

2つ目は、Text-to-SQLです。自然言語からSQLを生成する機能は各社のデータ基盤製品に載りましたが、精度はスキーマの表現力に強く依存します。Snowflakeのドキュメントは、ビジネスユーザーが「gross revenue」と呼ぶ概念がデータベース上ではamt_ttl_pre_dscという列名で格納されている、といった食い違いを、意味定義の層が必要になる理由として挙げています。列名とテーブル名しか手がかりがない状態は、人間のアナリストにとっても難しい問題です。

3つ目は、集計定義です。dbtのドキュメントは、複数のアナリストが同じデータに対して別々のクエリを書くことが混乱と不整合の原因になると述べ、メトリクスをYAMLで定義してバージョン管理下に置く方法を示しています。定義が一箇所に集まっていない環境では、LLMが生成したSQLが正しいのかどうかを判定する基準そのものがありません。

Text-to-SQLの現在地を数字で見ておく#

期待値を揃えるために、公開ベンチマークの状況にも触れておきます。BIRD-SQLは、95個の大規模データベース(合計33.4GB)と12,751件の質問・SQLペアで構成され、37以上の専門領域をカバーするText-to-SQLのベンチマークです。公式サイトによれば、データエンジニアとデータベース専攻の学生による人間の実行精度は92.96%とされています。一方で公開リーダーボード上位のシステムでも実行精度は80%前後にとどまっており、人間との差は残っています。

BIRDが難しい理由として公式サイトが挙げているのが、そのまま実務の話でもあります。実世界のデータベースの値は標準的でない形式のまま保持されていること(dirty values)、「ローン契約ではアカウント種別がOWNERである必要がある」といった業務知識がないと正しいSQLに到達できないこと(external knowledge)、そして正しいだけでなく効率的なSQLが求められること。整っていないデータベースに自然言語で問い合わせるのは、モデルの言語能力とは別の難しさがあるということです。

ベンチマークの読み方や、評価セット・セマンティックレイヤ・権限制御をどの順で用意するかは別記事で詳しく扱っています。ここでは「本を読む前に押さえておく前提」として、精度が頭打ちになる理由だけ共有できていれば十分です。

症状と、対応する本の対応表#

書店の棚で迷わないように、症状ベースで対応づけておきます。

上から順に、この記事で紹介する4冊が対応します。全部を読む必要はありません。いま出ている症状に近い1冊を選んで読み切るほうが、結果的に早く進みます。

1. 設計の型を手に入れる(達人に学ぶDB設計徹底指南書 第2版)#

最初の1冊は、リレーショナルデータベースの論理設計・物理設計を体系的に扱う定番書の改訂版です。翔泳社から2024年8月28日に刊行、著者はミック、A5判392ページ。出版社ページによれば、初版の構成を活かしつつ内容を最新化し、クラウドにも対応できるようにした版とされています。

構成は、論理設計と物理設計の関係(第2章)、論理設計と正規化(第3章)、ER図(第4章)、論理設計とパフォーマンス(第5章)、データベースとパフォーマンス(第6章)と進み、第7章で論理設計のアンチパターン、第8章でグレーノウハウ、第9章でRDBにおける木構造の扱いへ入ります。

LLM実務の立場から見ると、第7章と第8章の価値が高いと考えられます。第7章では非スカラ値、ダブルミーニング、単一参照テーブル、テーブル分割、不適切なキー、ダブルマスタ、ゾンビマートと多段マートが扱われます。RAGのソースを作るときに「同じ顧客なのに複数レコードある」「この列は文脈によって意味が変わる」といった現象に出会ったら、まさにこの章の話です。第8章の代理キー、列持ちテーブル、アドホックな集計キー、多段ビュー、データクレンジングも、既存スキーマを読み解くときの語彙になります。

扱っていない範囲も書いておきます。この本はRDBの設計書であり、LLM・RAG・ベクトル検索は主題ではありません。また特定製品(PostgreSQLやMySQL、クラウドDWH)の運用手順書でもないため、実際のDDLやパラメータは各製品のドキュメントを併読することになります。ETLやワークフロー設計といったデータ基盤側の話題も別の本の領域です。

達人に学ぶDB設計徹底指南書 第2版(翔泳社)

広告

著者: ミック / 出版社: 翔泳社 / 2024年8月28日刊行 / A5判392ページ。論理設計と物理設計、正規化、ER図、パフォーマンスとのトレードオフを体系的に扱い、第7章で論理設計のアンチパターン(非スカラ値・ダブルミーニング・ダブルマスタなど)、第8章でグレーノウハウ(代理キー・列持ちテーブル・多段ビューなど)を解説します。既存スキーマの問題点を言語化したい人に向いています。LLMやRAG、特定製品の運用手順、ETL設計は主題ではありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

2. やってはいけない形を名前で覚える(SQLアンチパターン 第2版)#

2冊目は、データベース設計とSQLの失敗パターンを名前付きで整理した書籍の改訂版です。原著者はBill Karwin、監訳が和田卓人、訳が児島修。オライリー・ジャパンから2025年7月11日発行、印刷版400ページ。原書はSQL Antipatterns, Volume 1です。出版社ページによれば、第2版では内容を大幅に改訂し、新規書き下ろしの章と15のミニ・アンチパターンが加わっています。

構成は5部27章。第I部の論理設計では、ジェイウォーク(カンマ区切りのリストを1列に格納する)、ナイーブツリー、IDリクワイアド、キーレスエントリ(外部キー嫌い)、EAV、ポリモーフィック関連、マルチカラムアトリビュート、メタデータトリブルが並びます。第II部は物理設計(ラウンディングエラー、サーティワンフレーバー、ファントムファイル、インデックスショットガン)、第III部はクエリ(フィア・オブ・ジ・アンノウン、アンビギュアスグループ、ランダムセレクション、プアマンズ・サーチエンジン、スパゲッティクエリ、インプリシットカラム)、第IV部はアプリケーション開発(リーダブルパスワード、SQLインジェクションなど)、第V部は外部キーのミニ・アンチパターンです。

LLMに社内データを触らせる文脈で、とくに読む価値が高いのは第I部と第III部でしょう。ジェイウォーク、EAV、ポリモーフィック関連は、いずれも「スキーマを見ても何が入っているか分からない」状態を作る設計で、Text-to-SQLが最も苦手とする形です。第III部のフィア・オブ・ジ・アンノウン(NULLと3値論理)とアンビギュアスグループ(GROUP BYと選択列の関係)は、生成されたSQLをレビューするときに間違いを見抜く目になります。ミニ・アンチパターンの「NOT IN (NULL)」などは、レビューの現場でそのまま使えるチェック項目です。

一方で、この本はDB設計の入門書ではありません。正規化理論を一から学ぶ構成ではなく、「ある程度書ける人が、やりがちな失敗を体系的に潰す」ための本です。データ基盤の層構造や組織論も範囲外で、LLMとの組み合わせについても当然ながら扱いません。なお日本語版付録として、奥野幹也氏による書き下ろしのアンチパターン「砂の城」がPDFで公開されています。原著にはない日本語版だけの追加コンテンツで、本文の試し読みではありませんが、無料で読める1本として押さえておくとよいでしょう。

SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策(オライリー・ジャパン)

広告

著者: Bill Karwin / 監訳: 和田卓人 / 訳: 児島修 / 出版社: オライリー・ジャパン / 2025年7月11日発行 / 印刷版400ページ。論理設計・物理設計・クエリ・アプリケーション開発の5部27章に加え、15のミニ・アンチパターンを収録します。ジェイウォーク、EAV、ポリモーフィック関連、NULLの扱いなど、Text-to-SQLが苦手とする構造を名前で判別できるようになります。正規化を一から学ぶ入門書ではなく、データ基盤の層構造やLLM関連の話題は扱いません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

3. SQLを読める・直せる水準にする(達人に学ぶSQL徹底指南書 第2版)#

3冊目は、SQLの書き方と考え方を初級から一段引き上げる書籍です。翔泳社から2018年10月11日刊行、著者はミック、A5判368ページ。副題が「初級者で終わりたくないあなたへ」で、初版から10年ぶりの改訂にあたりウィンドウ関数を全面的に採用した版とされています。

第1部「魔法のSQL」には、CASE式、ウィンドウ関数、自己結合、3値論理とNULL、EXISTS述語、HAVING句、外部結合、集合演算、数列の扱い、SQLを速くする方法、SQLプログラミング作法といった章が並びます。第2部はリレーショナルデータベースの世界として、理論寄りの話題が続きます。

LLM実務での使いどころは、生成されたSQLのレビューです。エージェントにSQLを書かせる運用では、返ってきたクエリが意図どおりかを人間が判断できないと、そもそも本番データに向けられません。ウィンドウ関数を使った集計、外部結合の落とし穴、NULLが絡む比較の挙動あたりは、レビュー時に最も判断を誤りやすい部分です。ここを自力で読めるかどうかが、Text-to-SQLを検証環境から出せるかどうかの分かれ目になります。

扱っていない範囲は明確です。DB設計そのもの(正規化やER図)は1冊目の担当で、この本の主題ではありません。刊行が2018年のため、クラウドDWH固有の関数や機能、LLM関連の話題は当然ながら含まれません。また標準SQL準拠の解説が中心で、特定製品の実行計画チューニングを詳細に追う本でもありません。SQLをまったく書いたことがない段階なら、この本の前に入門書を1冊挟むほうがスムーズです。

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ(翔泳社)

広告

著者: ミック / 出版社: 翔泳社 / 2018年10月11日刊行 / A5判368ページ。CASE式、ウィンドウ関数、自己結合、3値論理とNULL、EXISTS述語、HAVING句、集合演算などを扱い、第2部でリレーショナルデータベースの理論に踏み込みます。LLMが生成したSQLをレビューできる水準を目指す人に向いています。DB設計そのものは扱わず、刊行年の関係でクラウドDWH固有機能やLLM関連の話題は含まれません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4. 基盤と運用の側から見る(実践的データ基盤への処方箋)#

4冊目は、データ基盤を「データ・システム・ヒト」の3面から扱う書籍です。技術評論社から2021年12月11日刊行、著者はゆずたそ(横山翔)、渡部徹太郎、伊藤徹郎の3名、A5判224ページ。節ごとに独立して読める構成で、全体で40節が並びます。

第1章「データ活用のためのデータ整備」では、データソースからユースケースまでの流れとCRUD表の作成、データソースの品質管理、ERD作成による現場把握、マスタ・共通ID・履歴の整備、データレイク層・データウェアハウス層・データマート層の役割分担、メタデータによる調査コストの削減、データスチュワードの役割設定などが扱われます。第2章「データ基盤システムのつくり方」は収集方法(ファイル、API、SQL、更新ログ経由のCDCなど)、ETL製品の選定、分析用DBの選び方、ワークフローエンジンの導入判断へ進みます。第3章「データ分析の組織」は組織構造(集権型・分権型・ハイブリッド型)、職種と役割、セキュリティポリシー、IAMによる権限設定、運用ルールのドキュメント化、データとツールの棚卸、監査を扱います。

「集計定義が人によって違う」問題に直接効くのは第1章です。データウェアハウス層で共通指標を管理する、メタデータを整備して調査コストを下げる、データスチュワードという役割を置く。この3点は、LLMに社内データを触らせる前段の整備そのものです。第3章の権限設計と棚卸も、AIエージェントにデータアクセス権を与える設計を考えるときの下敷きになります。

限界も正直に書いておきます。刊行は2021年で、生成AIやLLM、セマンティックレイヤー製品の現況は当然ながら扱っていません。SQLの書き方や正規化理論の詳細も範囲外です。また各節が簡潔にまとまっている代わりに、個別の実装手順は書かれていないため、実際に構築する段では各製品のドキュメントが必要になります。この本の役割は、何を整備すべきかの見取り図を与えることだと考えるのが実態に近いはずです。

実践的データ基盤への処方箋 ビジネス価値創出のためのデータ・システム・ヒトのノウハウ(技術評論社)

広告

著者: ゆずたそ(横山翔)、渡部徹太郎、伊藤徹郎 / 出版社: 技術評論社 / 2021年12月11日刊行 / A5判224ページ。データ整備(CRUD表、マスタ・共通ID・履歴、レイク/DWH/マートの層構造、メタデータ、データスチュワード)、基盤システムの作り方(収集方式、ETL、分析用DB、ワークフローエンジン)、組織とセキュリティ(権限設計、運用ルール、棚卸、監査)を40節で扱います。集計定義のばらつきや権限設計に悩む人向けです。SQLの書き方や正規化理論の詳細、生成AI関連の話題は扱いません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4冊の使い分けと、読む順序#

役割と刊行時期をまとめます。刊行時期は「LLM以後の話題をどこまで含むか」の目安になりますが、この4冊はいずれもLLMを主題にしていません。土台のほうを扱う本だと理解して選んでください。

順序としては、次のどちらかを想定すると迷いにくいはずです。既存の社内データベースにLLMを繋ぐ立場なら、2冊目(アンチパターン)から入って現状を診断し、必要に応じて1冊目(設計)へ戻り、3冊目(SQL)でレビュー力を上げ、最後に4冊目(基盤)で整備の見取り図を得る流れです。逆に、これからデータ基盤を作る立場なら、4冊目で全体像を掴んでから1冊目、2冊目、3冊目と細部へ降りるほうが効率的でしょう。

本を読まずに済ませられる部分#

4冊すべてが必要になるケースは、実際にはそう多くありません。切り分けておきます。

まず、スキーマを変更できない立場なら、設計論を深く読む優先度は下がります。基幹システムのテーブルに手を入れられない状況で正規化理論を学んでも、当面できることは増えません。この場合に効くのは、参照専用のビューを用意して分かりやすい列名を付ける、列コメントやテーブルコメントを埋める、業務用語と列名の対応表を作る、といった上に載せる整備です。ここは書籍ではなく、使っているデータベース製品のドキュメントと社内の合意形成で進む部分です。

次に、SQLを自分で書く必要がない立場なら、3冊目の優先度は下がります。ただし「生成されたSQLをレビューしない」のと「レビューできる人がチームにいない」のは別の話です。後者の状態でText-to-SQLを本番に出すのは避けたほうが安全で、その場合はレビューできる人を確保するか、集計結果を人が検算できる範囲に用途を限定することになります。

逆に、書籍でしか得にくいのは、名前の付いた語彙と、判断の順序です。「これはEAVだから、この列の意味はデータを見ないと分からない」「ダブルマスタになっているので、どちらを正にするか決めないと集計は合わない」といった診断は、一度言語化できるようになると議論の速度が変わります。断片的な記事の寄せ集めでは、この語彙が揃いにくいのが実情です。

本記事に記載した書名・著者・訳者・監訳者・出版社・刊行日・ページ数・判型・ISBN・目次は、各出版社の公式書誌ページ(frontmatterのsources)で確認できた範囲の情報です。版・価格・在庫・目次は改定されるため、購入前に各公式ページで最新情報をご確認ください。各書籍の「扱っていない範囲」の記述は、公開されている目次と出版社の内容紹介から判断できる範囲の整理で、本文全体を網羅的に検証したものではありません。BIRD-SQLの規模・人間の実行精度・リーダーボードの状況は公式サイトに基づく2026年8月時点の内容で、更新されます。

読んだ内容をLLM実務に落とす最初の一歩#

読み終えてすぐスキーマを作り替えようとすると、たいてい途中で止まります。診断から入り、変更コストの小さいところから順に手を付けるのが現実的です。

この順序は、4冊目が示す「メタデータで調査コストを下げる」「共通指標を管理する」という考え方と、2冊目が与えるアンチパターンの診断能力を、LLM実務の文脈に置き換えたものです。設計変更は最もコストが高い打ち手なので、最後に回すのが妥当だと考えられます。

よくある質問#

まとめ#

社内データをLLMに繋ぐ取り組みで効き目が出にくいとき、原因はモデルの選択よりもデータ側にあることが少なくありません。1列に複数の値が入っていないか、同じ実体のマスタが二重化していないか、列名から意味が読み取れるか、指標の定義が一箇所に集まっているか。どれもLLM以前から議論されてきた論点で、書籍で体系的に学べる領域です。

今回紹介した4冊は守備範囲が異なります。設計の型を与える本、失敗パターンに名前を付ける本、SQLを読める水準に引き上げる本、基盤と組織の見取り図を与える本。いずれも「これを読めばAIがデータを正しく扱える」種類の本ではなく、何が壊れているかを自分で診断できるようにする本だと捉えるのが実態に近いはずです。まずは対象テーブルを絞って診断し、評価セットを20件作るところから始めてみてください。測れるようになると、次に読むべき1冊も自然に決まります。