第1章 生成AI時代のデータベース入門

この章のゴール

生成AIへ自社の情報を使わせるには、最初に「情報がどこにあり、どのような形で管理されているか」を整理する必要があります。 この章では、SQLを書く前に、データベースと生成AIの役割分担を確認します。

この章を終えると、次のことを説明できるようになります。

• データベース、DBMS、リレーショナルデータベースの違い
• テーブル、行、列が表すもの
• 表計算とデータベースの使い分け
• 文書RAGと、データベースを使う構造化データ検索の違い
• 一つの質問で、文書とデータベースの両方が必要になる場合
• AIから業務データを利用するときに、最初から考えるべき安全対策

研修では、説明と確認に約50分、章末演習と振り返りに約20分を使います。

なぜ生成AI時代にデータベースを学ぶのか

生成AIは、一般的な知識を使った説明や文章作成を得意とします。 しかし、社内だけにある商品情報、受注状況、在庫、出荷予定などを、自動的に知っているわけではありません。

たとえば、2026年11月19日に次のように質問するとします。

明日の缶飲料の出荷予定は何ケースですか。

この問いへ正しく答えるには、少なくとも次の情報が必要です。

• 「明日」が2026年11月20日であること
• どの商品が「缶飲料」に分類されるか
• 11月20日の出荷予定明細
• 数量の単位がケースであること
• 取消済みなど、集計から除外する予定状態
• データが最後に更新された日時

生成AIが自然な文章を作れても、これらの業務データが曖昧なら正しい答えにはなりません。 そこで、意味と関係を明確にしたデータベースを用意し、必要な値を検索してから回答へ使います。

図1-1 業務データを整えることが、AIから安全に利用するための出発点になります。

この研修が重視するのは、AIにSQLを作らせることだけではありません。 AIが参照する元データを、業務上正しい形に整えることです。

データベースとDBMS

データベースとは

データベースは、目的に応じて整理され、検索や更新を継続して行えるデータの集まりです。 単にファイルを一つ保存しただけではなく、どのデータを、どの項目で、どのような関係として管理するかが決められています。

飲料メーカーなら、次のようなデータが管理対象になります。

• 商品分類
• 容器種別
• 商品
• 取引先
• 出荷予定
• 出荷予定ごとの商品と数量

DBMSとは

DBMS（Database Management System）は、データベースを管理するソフトウェアです。 データの登録、検索、更新、削除だけでなく、ルールに合わないデータの登録を防いだり、利用者ごとに権限を分けたりします。

本研修で使用するMySQLはDBMSの一つです。 MySQL Workbenchは、MySQLへ接続し、SQLの入力やデータの確認を行うための操作ツールです。

用語	この研修での意味	例
データベース	整理されたデータの集まり	出荷予定管理データベース
DBMS	データベースを管理するソフトウェア	MySQL
操作ツール	DBMSへ接続して操作するための画面	MySQL Workbench
SQL	DBMSへ処理を指示するための言語	商品の登録、出荷予定の検索

リレーショナルデータベースの基本構造

MySQLは、リレーショナルデータベース管理システムです。 リレーショナルデータベースでは、データを複数のテーブルに分け、共通する値を使って関係付けます。

テーブル、行、列

テーブルは、同じ種類のデータを一定の項目でそろえて管理する単位です。

• テーブル：同じ種類のデータの集まり
• 行（レコード）：管理対象一件分のデータ
• 列（カラム）：一つの項目と、その意味
• 値：行と列が交わる位置に記録される具体的な内容

図1-2 一つの列には一貫した意味を持たせ、一つの行で一件の商品を表します。

図は、テーブル、行、列、値の関係を説明するための簡略例です。 実際のテーブル構成とテーブル間の関係は、業務ルールを確認しながら第2章以降で設計します。

たとえば、product_name列には常に商品名を入れます。 同じ列へ、ある行では商品名、別の行では容器名を入れると、検索する側は値の意味を判断できません。

AIから利用する場合も、この原則は変わりません。 「データの意味が明確であること」は、SQLを書きやすくするだけでなく、AIが質問を検索条件へ対応付けるためにも重要です。

テーブルを分け、関係を持たせる

業務データを一つの巨大な表へ詰め込むと、同じ商品名や取引先名を何度も入力することになります。 リレーショナルデータベースでは、商品、取引先、出荷予定などを役割ごとのテーブルへ分け、識別用の値で結びます。

テーブルの分け方、主キー、外部キー、1対多の関係は第2章で学びます。 第5章では、重複や更新時の矛盾を減らすため、第1正規形から第3正規形まで整理します。

表計算とデータベースを使い分ける

表計算とデータベースは、どちらも行と列を使うため、見た目が似ています。 しかし、得意とする用途が異なります。

観点	表計算	データベース
得意な用途	個人や小規模な集計、試算、見せ方の調整	継続的な登録、検索、共有、他システムからの利用
構造	セル単位で自由に入力・配置できる	列の意味やデータ型、テーブル間の関係を決める
計算・分析	式やグラフを画面上で素早く作れる	SQLで条件を指定し、繰り返し検索・集計できる
整合性	入力規則を作れるが、運用で崩れることがある	キーや制約によってDBMSがルールを確認できる
複数業務での利用	ファイルの複製や版違いが起きやすい	一つの管理対象を複数の処理から参照しやすい

表計算が悪いわけではありません。 その場で試算する、小さな一覧を人が確認する、結果をグラフにする、といった用途では表計算が便利です。

一方、複数の利用者やシステムが同じ商品や出荷予定を参照し、継続して更新するなら、 意味と関係を定義したデータベースが向いています。 データベースの検索結果を表計算へ出力し、分析や報告に使うこともできます。

AIが自社データを利用する二つの検索

生成AIへ外部の情報を渡して回答させる方法は一つではありません。 本研修では、文書を探す場合とデータベースの値を探す場合を区別します。

文書RAG

RAGはRetrieval-Augmented Generationの略で、日本語では検索拡張生成と呼ばれます。 一般的な文書RAGでは、規程、手順書、議事録、FAQなどから質問に関係する文章を検索し、 見つけた文章を生成AIへ渡して回答を作ります。

文書RAGは、次のような「文章の中に説明がある問い」に向いています。

• 出荷を取り消すときの承認手順は何か
• 缶飲料を保管するときの注意事項は何か
• 障害発生時に誰へ連絡するか

データベースを使う構造化データ検索

データベース検索は、列の意味が決められたデータから、日付、分類、状態などの条件に合う行を取り出します。 必要に応じて数量を合計し、その結果を生成AIへ渡します。

次のような「現在の値や件数を求める問い」に向いています。

• 2026年11月20日の缶飲料は何ケース出荷予定か
• 取引先別の出荷予定件数はいくつか
• 出荷予定が変更された商品はどれか

図1-3 対象と検索方法は異なりますが、検索した根拠を回答へ渡す点は共通します。

観点	構造化データ検索	文書RAG
主な情報源	MySQLなどの業務データベース	規程、手順書、議事録、FAQなど
情報の形	列の意味が定義された行と値	見出しや段落を持つ文章
検索の中心	日付、コード、状態、数量などの条件	質問と意味が近い文章
得意な回答	最新値、一覧、件数、合計	理由、手順、条件、背景説明
確認する根拠	検索条件、取得行、集計値、更新日時	参照文書、該当箇所、版、更新日

「データベースをAIから検索すること」を、すべて文書RAGと呼ぶわけではありません。 広い意味で、検索した情報を生成へ追加する仕組みとして共通点はありますが、 本研修では混乱を防ぐため、文書RAGと構造化データ検索を分けて説明します。

両方が必要な質問

一つの業務質問で、文書とデータベースの両方が必要になることもあります。

明日のA社向け出荷は何ケースですか。変更する場合の締切も教えてください。

この場合、出荷ケース数はデータベースから取得します。 変更締切は、取引契約や出荷手順書から確認します。 AIは二つの結果をまとめられますが、どちらを根拠にしたかを区別して示す必要があります。

整理されていないデータをAIへ渡すとどうなるか

生成AIを接続しても、元データの意味が曖昧なままでは問題は解決しません。

データの問題	AIから利用するときに起きること
quantityの単位が不明	120ケースなのか120本なのか判断できない
日付が「11/20」「20日」「明日」と混在	同じ日として安定して検索できない
「缶」「CAN」「350ml缶」と分類が揺れる	缶飲料の集計から一部が漏れる
取消済みの行が残り、状態列がない	出荷予定へ取消分を含めてしまう
同じ取引先情報が複数箇所にある	どの住所が最新か判断できない
更新日時がない	回答がいつの情報か説明できない

AIに細かな指示を増やす前に、データの意味、単位、分類、関係、更新方法を整える必要があります。 これが第2章以降で行うデータベース設計です。

情報管理を最初から考える

この研修の最終章では、講師PC上のローカルLLMとローカルMySQLを使用します。 データを外部のAIサービスへ送らない構成は、情報の外部送信を抑える方法の一つです。

ただし、ローカル環境であれば自動的に安全になるわけではありません。 少なくとも、次の点を設計に含めます。

• 研修では実在の顧客情報や個人情報を使わず、架空データだけを使用する
• AIには、回答に必要なテーブルやビューだけを公開する
• 初版では読み取り専用とし、AIから更新や削除をさせない
• 誰が、いつ、どの条件で検索したかを確認できるようにする
• 回答に検索条件、単位、基準日、更新日時を添える
• 帳票は下書きとして作り、登録・送信・印刷の前に人が確認する

権限や確認手順は第6章で具体化します。

演習：どの情報源を使うか

次の問いに答えるために使う主な情報源を、 A：データベース、B：文書RAG、C：両方から選んでください。

1. 明日の取引先別の出荷予定ケース数はいくつですか。
2. 出荷予定を取り消す場合、誰の承認が必要ですか。
3. 商品コードPRD001は、一ケースに何本入っていますか。
4. 先月、出荷遅延が増えた理由を会議議事録からまとめてください。
5. 明日の要冷蔵商品の出荷数量と、積み込み時の注意事項を教えてください。
6. A社向けの未出荷予定と、A社との契約上の納品時間帯を教えてください。

解答例と理由を確認する

問い	解答例	理由
1	A	日付と取引先を条件に数量を集計するため
2	B	承認手順は規程や手順書に文章で記載されるため
3	A	商品マスターの一ケース当たり本数を確認するため
4	B	遅延理由の記述を議事録から探して要約するため
5	C	出荷数量はDB、注意事項は商品取扱手順書から得るため
6	C	未出荷予定はDB、契約上の納品条件は契約文書から得るため

自社データへ置き換えて考える

自分の業務でAIへ質問できると便利なことを一つ挙げ、次を記入してください。

確認項目	記入内容
AIへ尋ねたい業務上の問い	例：明日の未処理依頼は部門別に何件あるか
必要な値	日付、部門、状態、件数など
現在の保存場所	表計算、業務システム、文書、メールなど
DBから取る情報
文書から取る情報
単位・基準日・状態の注意
回答後に人が確認すること

まだテーブル名やSQLを書く必要はありません。 「何を知りたいか」「どの情報源にあるか」「何を確認すべきか」を分けることが、この演習の目的です。

この章のまとめ

• データベースは、意味と関係を決めて継続的に利用するデータの集まりです。
• MySQLはDBMS、MySQL WorkbenchはMySQLを操作するためのツールです。
• リレーショナルデータベースは、行と列を持つ複数のテーブルを関係付けます。
• 表計算とデータベースには異なる得意分野があり、組み合わせて利用できます。
• 文書RAGは文章を、構造化データ検索は条件に合う値や集計結果を主に扱います。
• 整理されていないデータは、AIを接続しても意味や単位を正しく判断できません。
• ローカルAIでも、権限、記録、根拠表示、人による確認が必要です。

次章では、飲料メーカーの出荷予定表を題材に、 業務からテーブル、項目、主キー、外部キー、関係を見つけます。

第2章「業務データをテーブルとして設計する」へ進む