Text-to-SQLが製造データで間違える典型パターン
Text-to-SQLは、自然言語の質問をLLMがSQLに変換し、データベースに問い合わせて結果を返す仕組みです。汎用の業務データでは便利ですが、MESのデータでは次のような誤りが起きやすくなります。
- 不良率の分母を「投入数」にするか「完成数」にするかで部門の定義が違うのに、AIがどちらかを勝手に選ぶ
- 再作業（手直し）を経て良品になったロットを、不良として数えるかどうかが曖昧
- 品番の改番前後を別品番として集計し、前年比較が壊れる
- 「ライン3」がMESでは設備IDやワークセンターのコードで管理されており、名前とコードの対応をAIが推測で埋める
- 夜勤の実績を日付で切るとき、稼働日の境界（例えば朝8時）を暦日の0時と取り違える
いずれもSQLとしては正しく実行され、エラーも出ません。数字だけが静かにずれるので、利用者が気づきにくいのが最大の問題です。
前提1：テーブルと項目に「意味」を付ける
MESのテーブル名や列名は、パッケージ固有の略号や内部コードであることが多く、LLMは名前から意味を推測するしかありません。最初にやるべきことは、質問によく出る指標と項目について、意味の定義を文書化することです。
| 定義すべき項目 | 例 |
|---|---|
| 指標の計算式 | 工程内不良率＝工程で不良判定された数÷その工程の投入数 |
| 時間の区切り | 稼働日は8:00〜翌7:59、週は月曜始まり |
| 名称とコードの対応 | 「ライン3」＝ワークセンター WC-0303 |
| 除外条件 | 試作オーダー・テストロットは集計から除く |
| 品番の同一性 | 改番前後の品番は対応表で同一品番として扱う |
ISA-95の階層で言えば、MESが持つL3の情報（材料・設備・物理資産・人員）に、業務上の意味を重ねる作業です。この定義はLLMのプロンプトに埋め込むだけでなく、次のビュー設計の仕様書にもなります。
前提2：生テーブルではなく分析用ビューにつなぐ
LLMに見せるのは、MESのトランザクションテーブルではなく、指標の定義をあらかじめ反映した分析用のビュー（またはデータウェアハウスの集計テーブル）にします。
ビューを挟むと、LLMが考える範囲が「どのビューのどの列を、どの条件で絞るか」に縮みます。計算式の解釈を毎回LLMに任せる構成に比べ、誤りの入り込む余地が大きく減ります。MESとAIをつなぐ方式の比較はMESとAIをつなぐ3方式で扱っています。
Microsoftの「Factory Operations Agent」も、LLMが自然言語の質問を解釈し、セマンティックグラフ（意味のつながりを持つデータモデル）を通じてMES・QMS・サプライチェーンのデータを取得する構成をとっています。製品として提供される仕組みでも、意味層を挟む考え方は同じです。
前提3：権限は「読み取り専用・ビュー単位」で切る
Text-to-SQLの接続ユーザーには、分析用ビューへのSELECT権限だけを与えます。INSERT・UPDATE・DELETEの権限を持つユーザーでつなぐと、プロンプトの工夫だけでは更新系のSQLを防げません。
権限設計で決めておくことは次の3点です。
- 接続ユーザーは読み取り専用にし、MESの本番DBではなくレプリカや分析用DBに向ける
- 原価・人事評価・顧客名など機密度の高い列は、ビューの段階で除外するか、利用者の権限に応じてビューを分ける
- 重いクエリで本番に負荷をかけないよう、タイムアウトと結果件数の上限を設定する
前提4：回答を検算できる形で返す
Text-to-SQLの回答には、数字だけでなく、生成したSQL、使ったビュー、集計条件（期間・除外条件）を必ず添えます。利用者が「この数字は何を数えたものか」を確認できなければ、会議資料にそのまま貼られて誤りが広がります。
導入時の検算は、既存の日報・月報の数字との突合が最も確実です。
- 過去3か月分の月次不良率・稼働率を、Text-to-SQLの回答と既存帳票で比べる
- 現場がよく聞く質問30〜50問を集め、正解SQLを人が書いて答え合わせをする
- 一致しなかった質問は、意味定義かビューのどちらに原因があるかを切り分けて直す
質問セットを使った評価の進め方は社内文書RAGの評価方法と同じ考え方で組めます。生成AIの回答で数値を扱うときの一般原則は数値・規格値を間違えさせない5つの設計にまとめています。
よくある質問
LLMの性能が上がればビューの整備は不要になりますか
不要にはなりません。誤集計の原因の多くはSQLの書き方ではなく、不良率の分母や稼働日の区切りといった社内定義が文書化されていないことにあります。定義はモデルの性能では補えないため、意味層の整備は残ります。
BIツールの自然言語検索とText-to-SQLは何が違いますか
BIツールの自然言語機能は、BI側で定義済みのデータモデルの上で動くため、本記事の前提2を満たした構成に近いものです。すでにBIのデータモデルが整っているなら、そちらを入口にするのが早道です。
現場のオペレーターにも使わせてよいですか
読み取り専用で、回答に集計条件が表示される構成なら、利用者を広げても大きな事故は起きにくくなります。ただし、回答をもとに設備条件を変えるなどの判断は、従来どおり責任者の確認を経る運用にしてください。
この記事に出てくる用語
AIは「データ基盤」で決まる
PoCは成功したのに本番で止まる。原因の多くはモデルではなく、MESと設備データの側にある 全130本
- MESとAIの関係：ロット・作業指示・品質判定がAIの精度を決める理由
- 製造業AIが本番で止まる7つの理由：PoCは成功したのにラインに載らない構造
- 製造業のAI-OCR：紙の検査記録・点検表・ミルシートをデータ化する手順
- データ基盤の段階的導入ロードマップ：ユースケースから逆算する8ステップ
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
