AIアシスタントが社内のMySQLに直接問い合わせて答えを返す——そんな使い方が現実になりました。ただしこれは、LLM（Large Language Model：大規模言語モデル）に本番データへのアクセスを開くということでもあります。統制がないままつなげば、モデルは見せてはいけないデータを表に出したり、書き換えたりできてしまいます。

この記事は、AI連携の可否を判断する側に立つ方に向けて書いています。AIとMySQLを安全につなぐ行程は、何を触らせるかを決める段階から実際に何をしたかをモニタリングする段階まで続きます。ここではその流れを7つのステップに分けて整理しました。各ステップの末尾には、誰が実施して何をもって完了とみなすかを明記しています。

それでは見てみましょう。

ステップ1：MySQLのデータを棚卸しして分類する

セキュアなデータ連携は、データベースに何が入っていてそれがどのレベルの機密情報なのかを知るところから始まります。AIがMySQLに触れる前に、スキーマを棚卸しして分類しておきましょう。ここでの分類が、あとからマスキングや制限をかけられる範囲の目安になるからです。

データ分類とは、データを機密レベルでラベル付けする作業です。個人を特定できる情報（PII：Personally Identifiable Information）や社外に出せない業務記録を明示しておくことで、AIモデルに許可する範囲を正確に制御できます。個人情報保護法でいう要配慮個人情報にあたる列を先に洗い出しておくと、あとの審査で説明しやすくなります。

• すべてのスキーマとテーブルを棚卸しし、意図せずつながる経路をなくす

• 機微な列、とくにPIIや規制対象の項目にフラグを立てる

• 社外に出せないデータセットを、一般的なデータセットから分離する

ここで作った構造が、マスキング・RBAC（Role-Based Access Control：役割ベースアクセス制御）・AIエージェント向けの分割アクセスをどれだけ楽にかけられるかを決めます。スキーマ設計の可視化にはMySQL Workbench、テーブルと関連の図示にはLucidchartやDraw.ioが使えます。図が整っていればアクセス権のレビューは速く進み、スキーマが変わったときに意図しない露出が起きるリスクも下がります。

責任分界：担当はデータベース管理者です。分類表がセキュリティ部門のレビューを通れば完了とみなします。

ステップ2：MySQL側のセキュリティ設定を固める

データの地図ができたら、次はデータベース本体です。AIをつなぐ前に済ませます。すべての接続でTLS（Transport Layer Security）を強制し、保存時の暗号化を有効にし、MySQLとOSのパッチを最新に保ちます。

保存時の暗号化は、保管されたデータを暗号技術で守る仕組みです。物理ディスクが持ち出されても、鍵がなければ中身は読めません。

バックアップにも同じ手当てをします。暗号化して改ざんできない状態で保管し、リストアが本当に通るかを定期的に試しておきましょう。

責任分界：担当はインフラ／DB運用チームです。TLS強制と暗号化の設定値、そして直近のリストア試験の記録が残っていることが完了の条件になります。

ステップ3：最小権限とID管理はどう設計する？

固めたデータベースにも、誰が・何がつないでよいかというルールが要ります。最小権限とは、利用者やシステムに対して仕事に必要な最小限のアクセスだけを与える考え方です。ミスや侵害が起きたときの被害範囲を、そもそも狭くしておく発想です。

MySQLがAIアシスタントとやり取りを始める時点で、この原則を適用します。

• AIの業務ごとに用途を限定した専用のサービスアカウントを作る（rootや管理者アカウントは使い回さない）

• ホストやネットワーク単位でアクセス元を絞れるところは絞る

• 認証情報（クレデンシャル）はコードに書かず、専用のシークレットマネージャーに保管し、決めた周期でローテーションする

CData Connect AIを使う場合、各クエリを要求したユーザー自身のIDで実行し、MySQL側の既存の権限をそのまま継承させられます。新しい認証情報をあちこちに配らずに、アクセスのスコープを保てます。この「既存の権限を引き継ぐ」考え方はMySQLに限った話ではなく、PostgreSQLをChatGPTにセキュア接続するガバナンス設計でも、同じ組み立てを具体的な設定手順まで追って解説しています。

責任分界：担当はDB管理者と情報システム部門です。AI用アカウントの権限一覧とローテーション周期を文書に落とせていれば完了です。

ステップ4：MCPでAIのアクセスを仲介する

アカウントのスコープを絞っても、LLMに本番データを直接触らせる構成は余計なリスクを抱えます。ここで挟むのが仲介層です。

Model Context Protocol (MCP)は、AIモデルが外部のツールやデータソースを呼び出すための取り決めです。モデルが自分でSQLを組み立てて投げるのではなく、あらかじめ承認された機能を経由させます。そのやり取り全体にアクセス制御と監査をまとめてかけられるのが利点です。

MCPやこれに類するAIエージェント向けの枠組みは、モデルと生のデータベースの間に入ります。MySQLへの要求はすべて検証済みで監視下にある関数を通ります。1回の要求は次の3段階で進みます。

• モデルは、SQLではなく必要なデータを自然言葉で要求する

• MCPサーバーがその要求を自分のルールと突き合わせ、実行するかどうか・どう実行するかを決める

• 承認済みの定義された関数だけがMySQLに対して走り、結果も同じ経路で返る

すべての呼び出しがこの経路を通るので、モデルが何を求めて実際に何が走ったのかが記録として残ります。これは後述する社内審査で、そのまま使える材料になります。

CDataはMySQL向けのマネージドMCPサーバーを提供しています。認証・RBAC・監査ログを最初から備えた形で、統制されたアクセスを公開できます。なお、自前構築・公式MCP・マネージドのどれを選ぶかで迷っている段階であれば、MCP接続方式を3つの評価軸とセキュリティ8項目で比較した記事が判断材料になります。どの方式を選んでも、統制のかかったMCP層さえ確保できれば、AIに任せられる業務の幅は一気に広がります。実際に、ヘルスケア業界の専門商社では、MCP Serverを介してLLMに業務データへアクセスさせる形で、人手では追いつかなかった大量データの自動カテゴライズを実現しています（ヘルスケア業界の導入事例）。

責任分界：担当はデータ基盤チームです。モデルが直接SQLを実行できる経路が1つも残っていないと確認できた時点で完了になります。

ステップ5：安全な検索パターンをどう選ぶ？

安全な経路ができたら、次はAIが必要なデータをどう取ってくるかです。狙いは、業務データを余計に動かしたり露出させたりせずに、関連する文脈だけを渡すことにあります。

ベクトル埋め込み (エンベディング)は、テキストなどのデータを数値で表現したものです。モデルが意味の近さを比較できるようになり、セマンティック検索やRAG（検索拡張生成）を支えます。

安全側に倒すなら、2段階の検索が有効です。まずSQLの条件で、AIが見てよいレコードまで範囲を絞り込みます。そのうえで、絞り込んだ部分集合に対してベクトル類似検索をかけ、関連する文脈を取り出します。構造化された絞り込みと意味的な検索を組み合わせるこのやり方はハイブリッド検索と呼ばれ、結果の精度を保ちながら露出範囲を限定できます。

この処理をデータベースの中で完結させられるなら、データを外に出さずに済みます。MySQL 9.0以降はVECTOR型と類似度を測るDISTANCE()関数を備え、MySQL HeatWaveはデータベース内のベクトルストア・埋め込み生成・RAGまで持っています。

ただし国内では、オンプレミスでMySQL 5.7や8.0を動かし続けている環境も珍しくありません。この場合、ネイティブのベクトル機能は使えません。バージョンを上げる計画を立てる前に、次の順で考えてみましょう。

• まずSQLのフィルタだけで範囲を絞る設計にします。業務上の質問の多くは、期間・部門・取引先といった条件で十分に絞り込めます

• 意味検索が必要な部分だけを切り出し、外部のベクトルストアに置きます。その際、MySQLから持ち出す列は分類済みの安全な列に限定します

• ベクトル検索の導入は急ぎません。統制のかかった経路と権限設計のほうが、効果は先に出ます

責任分界：担当はデータ／基盤チームです。AIが到達しうるレコードの上限を、SQLの条件として書き出せれば完了です。

ステップ6：AIのデータベース操作を記録して見張る

AIがMySQLに問い合わせを始めたら、何をしているのかを継続して見える状態にしておく必要があります。

すべてのクエリとモデルが起点になった関数呼び出しについて、詳細な監査証跡を取ります。タイムスタンプとその裏にいるサービスアカウントまたは利用者をセットで残しましょう。

そのうえで異常を見ます。見慣れない時間帯のアクセス、想定を超えるクエリ件数、これまで出てこなかったクエリの種類がその兆候です。こうした兆候を拾う先として、SOC（Security Operations Center：セキュリティ運用センター）やSIEM（Security Information and Event Management：セキュリティ情報イベント管理）のツールがあります。

とはいえ、SOCやSIEMを自前で持っている企業ばかりではありません。持っていない場合は、MCPサーバー側の監査ログを日次で書き出し、しきい値を超えたクエリ件数だけを通知する——この程度の軽い仕組みから始められます。大事なのは、問題を外部から指摘される前に自分たちの記録で気付ける状態を作ることです。

規制の厳しい業種では、インシデント対応の訓練を回し、復旧計画を最新の状態に保っておきましょう。

責任分界：担当はセキュリティ部門と基盤チームです。任意の1日を選んで「誰が・いつ・何を問い合わせたか」を再現できれば完了とします。

ステップ7：検証とテストを運用サイクルに組み込む

統制は、スキーマの変更・新しいAI業務・変わっていくコンプライアンス要件に追いつかせる必要があります。テストを一度きりのイベントにせず、周期の決まった作業にしましょう。情報漏えいを探る敵対的テストを走らせ、ベクトルクエリのレイテンシを測り、データが増えるのに合わせてインデックスと保持ポリシーを見直します。

監査と保持期間のレビューは、自社が該当する社内システム監査規程に沿った形で記録に残しておきましょう。次のセクションで触れる社内審査も、追加の資料づくりなしで通しやすくなります。

責任分界：担当は上の表のとおり3部門にまたがります。3観点それぞれの直近の実施記録が、決めた頻度どおりに残っていれば完了です。

社内のセキュリティ審査で何を聞かれる？

日本企業でAI連携が止まるのは、技術的な穴が見つかったときよりも、情報システム部門やセキュリティ部門の審査、そして稟議の段階であることが多いのではないでしょうか。ここまでの7ステップは、そっくり審査資料に組み替えられます。

審査でよく問われるのは、次の4点です。

• 誰が承認したか——AI用サービスアカウントの権限一覧と、その承認者（ステップ3）

• AIはどこまで到達できるか——データ分類表と、AIに開放した範囲の対応表（ステップ1）

• 直接SQLを投げられないと言い切れるか——MCP経由の経路図と、承認済み関数の一覧（ステップ4）

• 事後に追跡できるか——監査ログの保持期間と、任意の日付を再現した実サンプル（ステップ6）

この4点に資料で答えられる状態を作っておけば、稟議の差し戻しはかなり減ります。逆に言えば、ステップ1〜7を実施していても記録として出せなければ、審査は通りません。設計と同じだけ、証跡の作り方に手間をかける価値があります。審査資料の前段として構成図を求められることも多いので、その場合はAI×MCPのリファレンスアーキテクチャを下敷きにすると、自社構成を描き起こす手間を減らせます。

MySQL以外のデータソースにどう広げる？

ここまでMySQLを題材にしてきましたが、7ステップを読み返すとMySQL固有の話はステップ2と、ステップ5の一部だけです。分類する、最小権限で渡す、仲介層を挟む、検索範囲を絞る、記録する、定期的に検証する——この骨格は、AIに社内データをつなぐときに共通して有効な設計原則です。

実際、日本企業がAIにつなぎたいデータはMySQLだけではありません。kintone、Excel、Salesforceといった業務システムに散らばった業務データのほうが、量としても切実さとしても上回るケースは多いはずです。データソースが変わっても、ステップ1の分類表とステップ3の権限設計は手を加えずに使い回せます。SaaS側は認証や権限モデルがデータベースと異なるため、その差分はAIエージェントをSaaSへ安全に接続する方法で個別に整理しています。

CData Connect AIは、複数のデータソースに対して同じ統制の枠組みを適用できます。MySQLで一度この7ステップを体系的に通しておけば、2つ目・3つ目のデータソースはずっと短い時間で審査を通せます。

よくある質問

AIとMySQLを安全につなぐ

CData Connect AIは、この記事で整理したなかでも一番面倒な部分を引き受けます。AIアシスタントとMySQLの間にノーコードで統制されたMCP層を置き、認証・RBAC・監査証跡を最初から備えた形でアクセスを公開できます。

Claude、ChatGPT、その他のアシスタント——どれを使っていても、接続は既存の権限のもとで行われます。ChatGPTを使う前提で具体的な構成と設定画面まで確認したい場合は、ChatGPTに社内MySQLを安全に参照させる手順も併せてご覧ください。まずは1つのMySQLデータソースから試してみてください。

CData Connect AIの無料トライアルを開始する