第6章構築したデータベースをローカルAIから利用する

この章のゴール

第5章では、出荷予定、明細、出荷先を分け、主キーと外部キーで関係をたどれるデータベースを完成させました。

この章では、そのデータベースをローカルAIから安全に利用します。ただし、AIへMySQLの操作を自由に任せるわけではありません。 AIは質問を検索条件へ変換し、あらかじめ許可された機能を選びます。実際の検索は仲介アプリが読み取り専用で行い、最後は人が結果を照合します。

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

構造化データの検索と文書RAGの違いを説明する
AI、仲介アプリ、MySQL、帳票雛形の役割を区別する
自然言語の質問が検索条件へ変換される過程を確認する
AIの回答を、検索結果とデータベースの値に照らして検証する
曖昧な質問や許可されていない操作への対応を確認する
DBの値を固定雛形へ差し込み、出荷指示書の下書きを確認する
自社でAIからDBを利用するときの安全策を整理する

120分のうち、約40分を仕組みと安全策、約20分を講師デモ、約45分を問い合わせと帳票の演習、約15分を確認と全体のまとめに使います。

本章の実習方式

この章では、講師持ち込みPCのローカルLLMを使用します。受講者がLLMや連携アプリを構築する演習ではありません。

本教材の初版作成時点では、次の範囲を実機で確認しています。

ローカルLLMが質問から許可済み機能を選択する
「明日」を固定した業務基準日時から正しい日付へ変換する
容器種別と状態を機能の引数へ設定する
保存済みのDB検索結果を受け取り、日本語で回答する
曖昧な質問では条件を確認する
更新・削除の依頼では許可された検索機能を実行しない
出荷予定番号を指定して帳票作成機能を選択する

MySQLとの実接続、完全なオフライン動作、教室内LANからの同時利用は、講師PCの最終環境で追加確認します。当日に実接続を利用できない場合も同じ学習を続けられるよう、保存済み検索結果と帳票見本を用意しています。

本章では次のファイルを使用します。

06-ai-data-dictionary.csv — AIへ渡す項目の意味
06-search-result-confirmed-can.json — 保存済みの検索結果
06-shipping-instruction-draft.html — 出荷指示書の下書き見本
06-local-ai-tool-demo.ps1 — 講師用の代替実演スクリプト

研修用の架空データだけを使用します。

実在する取引先、住所、商品、数量、業務資料を、許可なく研修環境や生成AIへ入力しないでください。

AIにデータベースを直接操作させない

「AIからデータベースを使う」と聞くと、AIがSQLを作り、 MySQLへ直接送信する姿を想像するかもしれません。しかし、生成されたSQLを無条件で実行すると、次の問題が起こります。

質問と異なる条件で検索する
必要以上の行や個人情報を取得する
実行に時間がかかるSQLを作る
更新や削除を誤って実行する
何を根拠に回答したか追跡できない

そこで、本章では許可済み機能を間に置きます。

図6-1。受講者はブラウザーの研修用画面から質問する。講師PC内の仲介アプリが、ローカルLLM、読み取り専用MySQL、固定帳票雛形を接続する。MySQLとLLMのAPIは受講者へ直接公開しない。 — **図6-1** 講師PC内で完結する実演環境。AIとDBの間に仲介アプリを置き、許可した処理だけを実行します。

各部分の役割を整理します。

部分	主な役割	行わないこと
研修用画面	質問、条件、結果、回答を表示	DBへ直接接続しない
ローカルLLM	質問を条件へ変換し、結果を説明	任意のSQLを直接実行しない
仲介アプリ	許可した機能と引数を検査して実行	未登録の処理を実行しない
MySQL	出荷予定を検索・集計する	AI用権限では更新しない
固定帳票雛形	DBの値を決めた位置へ表示する	数量や住所をAIに創作させない

AIへ許可する二つの機能

初版では、AIが選べる機能を次の二つに限定します。

機能名	目的	主な引数
`search_shipment_schedule`	出荷予定を検索・集計する	日付、取引先、分類、容器、状態、便
`prepare_shipping_instruction_draft`	一つの出荷予定から下書きを作る	出荷予定番号

機能名は「AIに何を許可したか」を表します。 AIが引数を決めた後、仲介アプリは値と種類を検査します。検索機能では、検査済みの値を固定したSQLのプレースホルダーへ設定します。

WHERE sp.shipment_date = ?
  AND pt.package_type_code = ?
  AND sp.shipment_status = ?

三つの?には、日付、容器種別コード、状態コードを別々に渡します。質問文をSQLの一部として連結しません。

構造化データ検索と文書RAGを区別する

本章の中心は、MySQLに保存された構造化データを検索するツール連携です。これを文書RAGそのものとして説明しません。

観点	本章のDB検索	文書RAG
主な対象	日付、状態、数量などの表	規程、手順書、議事録などの文書
探し方	列と条件を指定して検索・集計	質問に近い文書断片を検索
得意な問い	確定済みは何ケースか	梱包規程には何と書いてあるか
主な根拠	検索した行と集計値	取得した文書断片

例えば、次のように役割を組み合わせることはできます。

MySQL   ：明日出荷する商品、数量、出荷先
文書RAG：その取引先向けの梱包規程
AI      ：二つの根拠を基に、出荷準備を説明

ただし、本研修では文書RAGの構築、Embedding、ベクトルDBは扱いません。まず、業務データの意味と関係が明確なDBを作ることに集中します。

AIへ見せる項目を決める

テーブルが正規化されていても、すべての列をAIへ見せる必要はありません。本番環境では、AI向けの参照用ビューを用意し、利用目的に必要な項目だけを公開します。

本章の検索で使う項目は、次の四つのまとまりで考えます。

まとまり	代表的な項目	用途
出荷予定	予定番号、日付、状態、便	検索条件と予定の識別
取引先・出荷先	コード、名称	対象の絞り込みと表示
商品	コード、名称、分類、容器	商品条件の絞り込み
数量・時点	ケース数、入数、更新日時	集計、単位、鮮度の確認

住所と郵便番号は、通常の検索結果には含めません。帳票作成を許可したときだけ、仲介アプリが対象の出荷先を検索し、固定雛形へ直接差し込みます。

データ辞書がAIと人の共通説明になる

列名だけでは、shipment_statusの値や、case_quantityの単位までは分かりません。データ辞書に、意味、例、使い方を記録します。

例えば「缶飲料」は商品名の文字列検索ではなく、容器種別コードCANとして検索します。「確定済み」は状態コードCONFIRMEDです。この対応があるため、表記ゆれに頼らず条件を指定できます。

第6章のデータ辞書を開き、次の三項目を確認してください。

package_type_codeの「缶」のコード
case_quantityが表す単位
updated_atと出荷予定日の違い

質問から回答までを追跡する

AIの最終回答だけを見ても、条件や根拠が正しいか判断できません。研修用画面では、途中の情報も表示します。

図6-2。業務の質問、AIによる条件解釈、許可済み機能の選択、固定SQLでの検索、DB結果、AI回答、人による照合の順に処理する。機能、引数、件数、時刻も記録する。 — **図6-2** 質問から回答までの流れ。AIの文章だけでなく、解釈した条件とDBの結果を確認します。

重要なのは、AIが出荷予定を記憶していたのではないという点です。 AIは検索条件を作り、DBから返された結果を説明しています。

業務基準日時を固定する

研修では、業務上の現在日時を次の値に固定します。

2026年11月19日 16時00分

したがって、「明日」は2026年11月20日です。 PCの時計や、LLMが持つ日付の知識へ依存させません。

次の三つの日時は意味が異なります。

日時	意味	本章の例
出荷予定日	商品を出荷する日	2026-11-20
DB最終更新日時	レコードを最後に直した時刻	2026-11-19 14:05
帳票作成日時	下書きを作った時刻	2026-11-19 16:00

講師デモ1：出荷予定を質問する

研修用画面へ、次のように入力します。

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

ローカルLLMは、質問を次の条件へ変換します。

質問中の表現	解釈した値	根拠
明日	`2026-11-20`	固定した業務基準日時
缶飲料	`CAN`	容器種別コード
確定済み	`CONFIRMED`	出荷状態コード
何ケース	`case_quantity`の合計	データ辞書の単位

AIが選択する機能と引数は、次の形です。

{
  "name": "search_shipment_schedule",
  "arguments": {
    "shipment_date": "2026-11-20",
    "package_type_code": "CAN",
    "shipment_status": "CONFIRMED"
  }
}

第5章のサンプルデータで該当する明細は、次の3行です。

出荷予定番号	商品	ケース数	状態
SP20261120-001	みなとソーダ	12	CONFIRMED
SP20261120-004	しおかぜ茶	10	CONFIRMED
SP20261120-004	みなとソーダ	7	CONFIRMED

合計は次のとおりです。

12 + 10 + 7 = 29ケース

回答例は次のようになります。

2026年11月20日の缶飲料の確定済み出荷予定は、合計29ケースです。 3明細を集計しました。参照したデータの最終更新日時は、 2026年11月19日14時05分です。

回答の言い回しはモデルによって変わっても構いません。しかし、対象日、状態、数量、単位、参照時点は検索結果と一致する必要があります。

実接続を使えない場合は、保存済み検索結果を使用します。このJSONには、解釈した条件、該当行、合計、最終更新日時が含まれています。

曖昧な質問では、条件を補わず確認する

次の質問には、状態の指定がありません。

明日の出荷予定は何件ですか。

第5章のDBには、CONFIRMED、DRAFT、CANCELLEDが混在しています。さらに「何件」が出荷予定件数なのか、商品明細件数なのかも曖昧です。

AIが勝手に「確定済みだけ」「明細件数」と決めると、利用者が意図した集計と異なる可能性があります。この場合は、例えば次のように確認します。

対象の状態を指定してください。確定済み、仮登録、取消のどれを含めますか。また、出荷予定の件数と商品明細の件数のどちらを数えますか。

確認できるまでは検索しない、という動作も安全策の一つです。

DBにない意味を推測しない

「売上が多い商品を教えてください」と質問されても、本章のDBには売上金額や単価がありません。出荷ケース数を売上とみなしてはいけません。

正しい対応は、売上の定義と必要なデータがないことを伝えることです。 AIを使う前に項目の意味を定義する必要があるのは、このためです。

更新・削除は許可しない

次の依頼も試します。

明日の出荷予定をすべて削除してください。

本章でAIへ許可しているのは検索と帳票下書きだけです。削除機能は定義せず、AI用DBアカウントにも削除権限を与えません。

安全策を一層だけに頼らず、次のように重ねます。

AIへ削除機能を提示しない
仲介アプリが未登録機能を拒否する
MySQLアカウントを読み取り専用にする
実行した機能、引数、件数、時刻を記録する

講師デモ2：出荷指示書の下書きを作る

帳票を作るときは、対象を一意に決める必要があります。次のように出荷予定番号を指定します。

SP20261120-001の出荷指示書の下書きを作成してください。

AIは帳票の文章や数量を自由に作らず、次の機能を選びます。

{
  "name": "prepare_shipping_instruction_draft",
  "arguments": {
    "shipment_plan_no": "SP20261120-001"
  }
}

仲介アプリは、対象が存在すること、状態、明細、数量を確認します。住所はこの機能の中だけで取得し、AIの通常回答へ渡さず、帳票雛形の住所欄へ直接差し込みます。

対象データは次のとおりです。

項目	値
出荷予定	SP20261120-001、2026-11-20、午前便
取引先・出荷先	取引先A、東配送センター
明細1	PRD001 みなとソーダ、12ケース
明細2	PRD003 みなと天然水、20ケース
合計	32ケース

出荷指示書の下書き見本を開き、 DBの値と一致するか確認してください。

帳票には、必ず「研修用・下書き」と表示します。下書きを作ったことと、出荷を確定したことは別です。人が元データと照合し、業務上の承認を行うまで確定扱いにしません。

帳票の対象が複数ある場合

次の依頼は、そのままでは対象が一つに決まりません。

明日のA社向け出荷指示書を作成してください。

2026年11月20日の取引先Aには、午前便の確定済み予定と、午後便の仮登録予定があります。 AIは二つを勝手にまとめず、出荷予定番号、出荷先、状態、便の確認を求めます。

演習5：AIの検索と帳票を検証する

3～4人のグループで、質問者、条件確認者、DB結果確認者、記録者に分かれます。 3人の場合は、条件確認者と記録者を兼ねます。

研修用画面を利用できる場合は実際に質問します。利用できない場合は、保存済みJSONと帳票見本を使って同じ確認を行います。

課題1：質問を検索条件へ直す

次の質問を読み、検索前に決める条件を書き出してください。

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

記録する内容は、対象日、容器種別、状態、集計する列と単位です。

課題2：検索結果と回答を照合する

保存済みJSONを開き、次を確認してください。

解釈した条件が質問と一致しているか
3明細のケース数を合計すると29になるか
回答に対象日、状態、単位が書かれているか
DB最終更新日時と業務基準日時を混同していないか
通常検索の結果に住所が含まれていないか

課題3：曖昧さを見つける

次の二つの依頼について、そのまま実行できない理由と、利用者へ確認する質問を考えてください。

明日の出荷予定は何件ですか。
明日のA社向け出荷指示書を作成してください。

課題4：帳票下書きを確認する

帳票見本と、第5章のサンプルデータを照合します。

出荷予定番号、日付、状態、便
取引先、出荷先、住所
商品コード、商品名、ケース数
合計32ケース
DB最終更新日時と下書き作成日時
「研修用・下書き」の表示

最後に、確認者名と確認結果を記録してください。

演習5の確認例

課題1の条件は、日付2026-11-20、容器CAN、状態CONFIRMED、集計列case_quantity、単位「ケース」です。

課題2では、12 + 10 + 7 = 29となります。通常検索のJSONには出荷先名はありますが、郵便番号と住所はありません。

課題3の一つ目は、状態と「件」の数え方を確認します。二つ目は、取引先Aに複数の出荷予定があるため、出荷予定番号、出荷先、状態、便を確認します。

課題4では、SP20261120-001の2明細が12ケースと20ケースで、合計32ケースになっていることを確認します。 DB最終更新は9時10分、下書き作成は16時00分です。

情報管理と運用上の確認

ローカル環境にすれば、自動的に安全になるわけではありません。 PCの利用者、保存場所、ポート、ログ、削除方法を決める必要があります。

初版の実演では、次を守ります。

実在データを持ち込まず、架空データだけを使う
MySQLとLLMのAPIを受講者PCへ直接公開しない
受講者には研修用画面の許可済み機能だけを公開する
AI用MySQLアカウントを読み取り専用にする
通常検索から住所を除外する
取得件数に上限を設ける
機能、引数、SQL、件数、実行時刻を記録する
グループごとに質問履歴と帳票下書きを分離する
研修終了後に質問履歴、ログ、生成帳票を削除する
帳票は人が承認するまで下書きとして扱う

実際の業務へ導入する場合は、個人情報、機密区分、保存期間、監査、バックアップ、障害時の手順も、自社の規程に合わせて設計します。

AIが停止したときの代替手順

AIの起動やネットワークに時間を使い、DB設計の学習を止めないようにします。

保存済みJSONで、質問、条件、DB結果を確認する
29ケースの集計を手計算する
回答文に必要な日付、状態、単位、時点を整理する
帳票見本とDBの2明細を照合する
第5章のSQLで同じ値をWorkbenchから確認する

講師は必要に応じて、代替実演スクリプトを使用できます。このスクリプトはローカルLLMの機能選択と回答を確認するもので、 MySQLの代わりに同じフォルダーの保存済みJSONを返します。実接続の検証済み連携アプリと混同しないでください。

本番デモ前に講師が追加確認すること

本章の下書き時点で、ローカルLLMの機能選択と回答は確認済みです。一方、次の項目は最終的な講師PCと会場で確認します。

第5章のSQLをMySQLへ実行し、参照用ビューの値が一致すること
AI用アカウントでSELECTだけが実行できること
インターネットを切断しても質問と帳票作成が完了すること
教室LANから研修用画面だけへ接続できること
複数グループの結果が混在しないこと
応答時間が研修進行に支障を与えないこと
ログと帳票下書きを研修後に削除できること

これらを確認できない機能は、当日の必須演習にしません。保存済み結果を使う代替手順へ切り替えます。

まとめ：自社データをAIで使うまでのステップ

本研修では、AIの前にデータベースを設計しました。その順序には意味があります。

業務上の事実と用語を整理する
    ↓
テーブル、列、主キー、外部キーを設計する
    ↓
正規化して、意味と保存場所を明確にする
    ↓
SQLで検索・集計できることを確認する
    ↓
AI向けの参照範囲とデータ辞書を決める
    ↓
許可済み機能から読み取り専用で検索する
    ↓
検索結果、AI回答、帳票下書きを人が照合する

AIのために特別な業務DBを作るのではありません。業務のためにデータを正しく整えることで、検索、集計、再利用がしやすくなり、結果としてAIからも安全に利用しやすくなります。

自社で小さく始めるなら、次の順で進めます。

答えたい業務上の問いを一つ選ぶ
必要なデータと、その意味、単位、更新時点を確認する
SQLで正しい答えを取得できることを先に確認する
AIへ公開する列と許可する機能を最小限にする
架空データで正常、曖昧、禁止操作をテストする
人による照合と承認を処理へ組み込む
情報管理と運用手順を確認してから範囲を広げる

生成AIは、整理されていないデータの意味を自動的に正しく決めてくれるものではありません。データの意味、関係、権限、確認方法を人が設計することが、生成AI時代の自社データベースづくりの土台です。

第6章 構築したデータベースをローカルAIから利用する