蓄積済みのMySQLデータをAIにつなぐには？ 工程データ分析の具体策（Text-to-SQL／MCP／MindsDB）

AIツール
2026.08.29

蓄積済みのMySQLデータを、どうAIにつなぐか

前回の記事では、工程データからムダ・ムラ・ムリを排除し、不良の早期発見や変化点調査につなげる姿を描きました（関連記事：AI時代のデータ分析をどうAIに任せるか？）。では現場の多くがすでに持っている「MySQLに蓄積された既存のデータ」を、どうAIに分析させるのか。ゼロからデータ基盤を作り直す必要はありません。既存のMySQLこそが、AI分析の入り口になります。

AIとMySQLをつなぐ3つの手段

MySQLのようなリレーショナルDBは、最終的に「SQLでデータを取り出す」仕組みです。AIに任せるとは、このSQLの生成と実行をAIが肩代わりすることです。主な手段は3つあります。

① Text-to-SQL：自然言語を直接SQLに変換する

「今週のラインAの不良率を教えて」と話しかけると、AIがそれをMySQL用のSQLに変換して実行するのがText-to-SQLです。NTTデータの解説では、LLMが「意味解析（自然言語理解）→スキーマ理解（業務用語とデータ構造の対応）→SQL構文生成」という3段階を経てクエリを作ると説明されています。ここで重要なのが、MySQL特有の書き方への対応です。例えば月を取り出す関数は、BigQueryならEXTRACT(MONTH FROM col)ですが、MySQLではMONTH(col)と書き方が異なります（Google Cloudの解説）。AIが接続先のDB種別を正しく理解していないと、動かないSQLを生成してしまいます。

現場ですぐ使える具体策として、オープンソースのChat2DB（MySQLやPostgreSQL等20種以上に対応、デスクトップ版もあり企業利用も視野）や、Text2SQL.ai（スキーマ情報を貼り付けるとSQLを生成、MySQL/PostgreSQL/BigQuery等に対応）といったツールがあります。既存MySQLの接続情報とテーブル定義を与えるだけで、現場の人が自然言語で問い合わせできるようになります。

② MCP：AIがDBスキーマを自ら確認してSQLを実行する

より本格的に、AIエージェントがMySQLと「会話できる」ようにするのがMCP（Model Context Protocol）です。Anthropicが提唱した、LLMと外部ツール・DBをつなぐ共通規格で、「AIにとってのUSB-C」と例えられます。AWS Labsが公開するMySQL MCP Serverや、GoogleのCloud SQL用MCPサーバーを介すれば、ClaudeやGemini CLIなどのクライアントが同じ手順でMySQLに接続できます。

仕組みは具体的です。ユーザーが「売上データを見せて」と言うと、AIはMCPのツールを使って「データセット一覧の取得→テーブルの特定→スキーマ（カラム名・型）の確認」というステップを自動で踏み、その上でSQLを組み立てて実行します（クラウドエースのBigQuery MCP解説が動作をわかりやすく示しています）。人間がテーブル構造を説明しなくても、AIが自分でスキーマを読んでクエリを発行するため、接続の手間が格段に下がります。

③ MindsDB：SQLの中で直接AIを動かす

「データを別のAI基盤へ移さず、MySQLの中でAIを動かしたい」場合は、MindsDBがあります。既存のSQL文法のまま、機械学習モデルの作成や予測、異常検知を呼び出せるプラットフォームです。データの移動（ETL）を行わず、「SQLを使ってデータベース内で直接AIを動かす」のが本質です（Qiitaの解説）。例えば「過去の工程データから不良の予兆を予測するモデル」を、MySQLの隣でSQLだけで作り、毎日のバッチで更新することも可能です。

RAGとの使い分け：数字はSQL、文書はRAG

ここで注意が必要なのが、「AIにつなぐ」といっても、すべてをRAG（ベクトル検索）でやるべきではないという点です。過去のトラブル事例や作業手順書といった「文書」をAIに読ませるならRAGが適していますが、工程データのような構造化データはSQLエージェントが正解です。NTT-TXの解説や、Autonomous DatabaseのSELECT AIのように、質問内容によって「SQLエージェント」か「RAGエージェント」かをルーターが自律選択する構成もあります。つまり、MySQLの数字にはMySQLの言葉（SQL）で聞くのが、精度と再現性の観点から最も確実です。

現状調査をAIにさせるために必要な「つなぎ」の仕組み

ツールを選んだら、次は「AIが正しく答えられる状態」に整えることです。NTTデータが指摘するように、Text-to-SQLで精度を上げるには次の工夫が不可欠です。

  • 用語辞書・シノニム管理：「売上」「販売額」「売上金額」を同一指標と解釈できるようにする
  • スキーマとメタデータの付与：テーブルやカラムの意味説明をAIに与え、「cat_id2=’Footwear’が靴を意味する」といった業務知識を理解させる
  • ガバナンス・権限管理：ユーザーの権限に応じて参照可能なテーブル・カラムを制御し、誤った集計や個人情報へのアクセスを防ぐ
  • プロンプト設計：どの前提でSQLを生成し、どの形式で返すかをあらかじめ指示する

これらは「AIにつなぐ」ための、現場側の準備作業です。とくに製造業では「ラインA」「工程3」といった現場用語と、DB上のカラム名のズレを辞書で埋めるだけで、現場の人が「工程3の昨日の停止時間」と聞くだけで正しい集計が返るようになります。

具体的な構成例：既存MySQL → AI分析のパターン

例えば、すでにPLCやMESのデータがMySQLの process_log テーブルに溜まっている工場を想定します。ここにAI分析をつなぐ最小構成は次の通りです。

  • データ層：既存MySQL（process_log等のテーブル、そのまま活用）
  • 接続層：MySQL MCP Server（AIがスキーマを自動認識してSQLを発行）
  • 対話層：Claude/Gemini等のLLMクライアント、またはChat2DB等のGUI
  • 出力層：生成されたSQLの実行結果を、ダッシュボードやレポートへ（NTTデータが示す「自然言語を起点とした可視化サイクル」）

この構成なら、新規サーバーの構築は不要。既存MySQLさえあれば、MCPサーバーを1つ立てるだけで、「昨日のラインごとの停止ロスはどこが一番大きい？」を自然言語で聞けるようになります。前回の記事で挙げた「朝イチ変化点レポート」も、この仕組みで毎朝自動生成できます。

ハルシネーションにどう備えるか

AIがSQLを書く以上、存在しないテーブルを参照したり、曖昧な質問に嘘の集計を返したり（ハルシネーション）するリスクはあります。Google Cloudの解説では、クエリの正しさをLLMで評価する「LLM-as-a-Judge」手法や、事実上保証された正解を得る手法に言及しています。現場レベルでは、「スキーマ情報を必ず与える」「権限で参照範囲を縛る」「重要な判断は人が最終確認する」という運用で十分カバーできます。AIの提案を鵜呑みにせず、根拠（どのSQLでどのデータから出したか）を表示させる透明性も、NTTデータが強調するポイントです。

セキュリティを懸念するなら「ローカルLLM」という選択肢も

ここまで挙げた手段（Text-to-SQLやMCP）は、クラウドのLLM（ChatGPT等）を使う前提で語られることが多いです。しかし製造現場の工程データには、不良率や歩留まり、設備の微細なパラメータといった、競合に知られたくない機密が含まれます。クラウド経由で分析させる場合、それらのデータが外部のAPIへ送信されることになり、セキュリティや秘密保持の観点から懸念を抱く現場は少なくありません。

その場合の解決策がローカルLLM（オンプレミスの自社サーバーやPCで動かすAI）です。データを自社ネットワークの外に出さずに分析できるため、機密を守りながらAI活用が可能です。前回の記事で取り上げたMac mini M6やM5 Proも、まさにこの用途に適したローカルAIマシンです（関連記事：AIエージェント向けMac mini M6とM5 Proを実データで考察）。自社工場のMySQLと同じネットワークに置いたMac miniにLLMを動かし、MCPでMySQLとつなぐ構成にすれば、工程データは一切外部に出ずに、自然言語分析が実現します。

ただしローカルLLMにはトレードオフがあります。前回の記事で確認した通り、M6はメモリ上限が32GB、M5 Proでも64GBであり、載せられるモデルの大きさ（70Bクラス等）に制約があります。トークン速度（tok/s）もクラウドのRTX 5090環境ほどは出ません（ただし7B〜30Bクラスのモデルなら実用上十分な速度）。「どこまでのモデルで、どの精度の分析まで任せるか」を、セキュリティ要件と照らし合わせて決めるのが現実的です。機密度が高い工程データほどローカルLLM、そうでない集計・可視化はクラウドLLM、という使い分けもあります。

まとめ

工程データをAIに任せる第一歩は、データを新しく集めることではなく、すでにMySQLにあるデータをAIにつなぐことです。手段は3つ。現場の人が自然言語で聞くText-to-SQL、AIが自らスキーマを読んでSQLを実行するMCP、SQLの中で直接AIを動かすMindsDB。数字の分析はRAGではなくSQLエージェントに任せ、用語辞書や権限管理で「つなぎ」を整えることで、現場用語で問いかけるだけの分析環境が手に入ります。

前回の「工程データで工程を最適化する」という目的は、この接続層があって初めて動き出します（関連記事：AI時代のデータ分析をどうAIに任せるか？）。既存のMySQLをそのまま活かし、MCP一本でAIとつなぐ。それが、中小製造業でも今日から始められる、もっとも現実的な第一歩です。

出典・参考

あわせて読みたい

コメント

タイトルとURLをコピーしました