SQL MCP Serverは、Azure SQLをAIエージェントから安全に扱うための新しい選択肢です。結論から言うと、これは「AIに自由なSQLを書かせる仕組み」ではなく、Data API builderの設定、権限、エンティティ定義を使って、AIエージェントに決められたデータ操作だけを実行させる仕組みです。
Azure SQLの管理者や開発者がまず確認すべき点は、Data API builderのバージョン、公開するテーブル・ビュー・ストアドプロシージャ、RBAC、認証、接続文字列の扱い、そして本番環境で無効化すべきDMLツールです。特に、既存のData API builder構成を使っている環境では「MCPでどのエンティティが見えるか」を必ず点検してください。
SQL MCP Serverとは何か
SQL MCP Serverは、Model Context Protocol、つまりMCPを使って、AIエージェントがSQLデータベースと対話できるようにするData API builderの機能です。Microsoft Learnでは、SQL MCP Serverを「Data API builder上に構築され、エージェントアプリケーション向けに決定論的で安全な、本番対応のデータベース操作を提供するもの」と説明しています。(Microsoft Learn)
ここで重要なのは、SQL MCP ServerがAzure SQLのデータベースを直接AIに開放するわけではない点です。Data API builderのdab-config.jsonで、接続先、公開するテーブル・ビュー・ストアドプロシージャ、各ロールの権限を定義し、その設定をもとにMCPツールが生成されます。Microsoft Learnによると、SQL MCP ServerはData API builder 1.7以降に含まれ、ローカル実行にもセルフホストにも対応します。(Microsoft Learn)
たとえば、Azure SQL上にProductsテーブルがあっても、SQL MCP Serverに見せたい場合はData API builder側でエンティティとして追加し、読み取り・作成・更新・削除のどれを許可するかを明示します。AIエージェントはAzure SQLへ直接SQLを投げるのではなく、read_recordsやupdate_recordのようなMCPツールを通じて操作します。
Azure SQL利用者にとっての主な変更点
SQL MCP Serverの公式情報で特に注目すべき変更は、AIエージェント連携がRESTやGraphQLと同じData API builderの設定モデルに統合されることです。Data API builderはもともとSQL Server、Azure SQL、Azure Cosmos DB、PostgreSQL、MySQLなどに対してREST・GraphQL APIを生成する構成ベースのエンジンで、1.7以降ではMCPも同じ機能群に加わっています。(Microsoft Learn)
| 変更点 | Azure SQL環境への影響 | 確認すべきこと |
|---|---|---|
| MCPエンドポイントがData API builder構成から生成される | REST、GraphQL、MCPで権限設計をそろえやすい | dab-config.jsonで公開エンティティと権限を確認する |
| NL2SQLではなくDABの抽象化レイヤーを使う | AIが自由形式のSQLを生成するリスクを抑えやすい | ビューやストアドプロシージャで業務上安全な操作に絞る |
| DMLツールでCRUDや集計を扱う | AIエージェントにデータ操作を任せられる範囲が明確になる | 本番ではdelete-recordなどを無効化するか判断する |
| フィールドやパラメーター説明が重要になる | 説明不足だとAIが列名や値を推測しやすい | エンティティ、列、ストアドプロシージャ引数に説明を付ける |
| 認証が受信・送信の2系統になる | クライアント認証とAzure SQL接続認証を分けて設計する必要がある | Entra ID、マネージドID、ゲートウェイ要否を確認する |
Microsoft Learnでは、SQL MCP ServerはData API builderのエンティティ抽象化、RBAC、キャッシュ、テレメトリを利用し、REST、GraphQL、MCPで同じ設定を基盤にすると説明されています。(Microsoft Learn)
SQL MCP ServerはNL2SQLではない
SQL MCP Serverを検討するときに誤解しやすいのが、「自然言語からSQLを生成するNL2SQLツール」と同じものだと考えることです。公式情報では、SQL MCP Serverは意図的にNL2SQLをサポートしない場合があると説明されています。理由は、モデルが非決定的であり、複雑なSQLほど微妙な誤りを生みやすいからです。(Microsoft Learn)
実務上は、この設計のほうが本番環境に向いています。たとえば、営業担当が「在庫が少ない商品を教えて」とAIに尋ねた場合、AIが勝手に複雑なJOINや未検証のSQLを作るのではなく、事前に定義されたProductsビューやLowStockProductsビューをread_recordsで読む形にできます。
判断基準は次の通りです。
| やりたいこと | 推奨される設計 |
|---|---|
| 単純な一覧取得、条件検索 | テーブルまたはビューをエンティティ化し、read_recordsを許可する |
| 複雑なJOINや業務ロジックを含む検索 | Azure SQL側にビューまたはストアドプロシージャを作り、DABで公開する |
| データ更新 | 対象エンティティと更新可能フィールドを絞り、ロール単位でupdateを許可する |
| スキーマ変更 | SQL MCP Serverではなく、通常のDB変更管理やMSSQL拡張機能、CI/CDで扱う |
SQL MCP ServerはDML、つまり既存テーブルやビューのデータ作成・読み取り・更新・削除、ストアドプロシージャ実行を中心に設計されています。DDL、つまりテーブル作成やスキーマ変更のための仕組みではありません。(Microsoft Learn)
利用できるDMLツールとバージョン差分
SQL MCP ServerがAIエージェントに公開する主なDMLツールは、describe_entities、create_record、read_records、update_record、delete_record、execute_entity、aggregate_recordsです。これらはData API builderのRBAC、エンティティ権限、ポリシーに従って動作します。(Microsoft Learn)
| ツール | 主な用途 | 本番環境での注意点 |
|---|---|---|
describe_entities | 現在のロールで利用できるエンティティや操作を返す | 説明文が不足するとAIが意図を誤解しやすい |
read_records | テーブル・ビューの検索、フィルター、並べ替え、ページング | キャッシュ、件数制限、対象列の制御を確認する |
create_record | 新規行の作成 | 入力制約と作成権限を最小化する |
update_record | 既存行の更新 | 主キー、更新可能フィールド、行レベル制約を確認する |
delete_record | 既存行の削除 | 本番では無効化を検討する |
execute_entity | ストアドプロシージャ実行 | 引数説明、実行権限、冪等性を確認する |
aggregate_records | count、sum、avg、min、maxなどの集計 | 1.7.xでは利用不可。2.0 preview以降の機能として扱う |
公式ドキュメントでは、aggregate_recordsはData API builder 1.7.xでは利用できず、2.0 preview以降で利用できるとされています。また、集計クエリにはquery-timeoutを設定でき、長時間実行によるリソース消費を抑える用途があります。(Microsoft Learn)
本番環境では、すべてのツールをそのまま有効にするのではなく、業務目的に合わせて絞ることが重要です。たとえば、社内FAQエージェントが商品在庫を答えるだけなら、read_recordsと必要に応じてaggregate_recordsだけで十分です。create_record、update_record、delete_recordを有効にする理由がなければ無効化したほうが安全です。
{
"runtime": {
"mcp": {
"enabled": true,
"path": "/mcp",
"dml-tools": {
"describe-entities": true,
"create-record": false,
"read-records": true,
"update-record": false,
"delete-record": false,
"execute-entity": true,
"aggregate-records": {
"enabled": true,
"query-timeout": 30
}
}
}
}
}公式ドキュメントでは、ランタイムレベルでツールを無効化すると、エンティティ権限やロール設定に関係なく、そのツールはAIエージェントから見えず、呼び出せないと説明されています。(Microsoft Learn)
既存のData API builder利用者が確認すべき移行ポイント
すでにAzure SQL向けにData API builderを使っている場合、SQL MCP Serverの導入はゼロから作り直す話ではありません。公式ドキュメントでは、既存のData API builder構成が動作している場合、1.7以降へアップグレードすると追加手順なしでSQL MCP Serverが動作すると説明されています。(Microsoft Learn)
ただし、これは「そのまま本番公開してよい」という意味ではありません。既存APIでは問題なかった構成でも、AIエージェントがMCPツールとして使うと影響範囲が変わります。
確認すべき順序は次の通りです。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| バージョン確認 | DAB 1.7以上か、2.0 previewを使うのか | preview機能を本番前提で組み込む |
| エンティティ棚卸し | MCPに見せるテーブル・ビュー・SPを決める | 内部管理用テーブルまで見せてしまう |
| 権限確認 | anonymous、authenticated、独自ロールの操作範囲を確認 | anonymous:*を検証用のまま残す |
| フィールド制御 | コスト、個人情報、内部メモなどを除外する | RESTで使っていた公開範囲をMCPにも流用する |
| DMLツール制御 | 削除、更新、集計、SP実行の要否を判断 | 全ツール有効のまま本番化する |
| 監視 | ログ、Application Insights、OpenTelemetryを確認 | AIエージェントの操作を追跡できない |
特にData API builder 2.0 previewでは、カスタムMCPツール、OBOユーザー委任認証、Unauthenticatedプロバイダー、ロール継承、MCP実行のOpenTelemetryトレースなどが追加・強化されています。一方で、2.0はpublic previewであり、一部機能は正式提供前に変更される可能性があるため、本番採用時は安定版とpreview機能を分けて評価する必要があります。(Microsoft Learn)
エンティティ説明とフィールド説明は必須レベルで整備する
SQL MCP Serverでは、AIエージェントがdescribe_entitiesを使って、利用可能なエンティティ、フィールド、操作を把握します。公式ドキュメントは、フィールド名や説明がない場合、エージェントが列名を誤って推測する可能性があると警告しています。(Microsoft Learn)
単にProductID、Status、Typeのような列名を見せるだけでは不十分です。AIにとっては、その値が何を意味するのか、どの単位なのか、どの値が有効なのかが重要です。
| 悪い説明 | 良い説明 |
|---|---|
Statusの説明が「ステータス」 | 注文状態。使用可能な値: Pending, Approved, Shipped, Cancelled |
UnitPriceの説明が「価格」 | 商品単価。通貨はJPY。税込価格 |
CreatedAtの説明が空 | レコード作成日時。UTC、ISO 8601形式 |
Environmentの説明が「環境」 | デプロイ環境。使用可能な値: Prod, Dev, Test, UAT |
Microsoft Learnでは、説明文はツール発見、クエリ精度、パラメーター利用、フィールド選択の改善に役立つとされています。特に固定値を持つ列では、説明に有効な値を明記することで、AIが似ているが誤った値を作るリスクを減らせます。(Microsoft Learn)
dab update Products \
--fields.name Category \
--fields.description "商品カテゴリ。使用可能な値: Electronics, Furniture, Office Supplies, Appliances"
dab update Products \
--fields.name UnitPrice \
--fields.description "商品単価。通貨はJPY。税込価格"実務では、スキーマ定義書やER図にある説明をそのまま流用するのではなく、AIが判断に使える表現に直すことが重要です。「DB担当者に分かる説明」ではなく、「業務担当者の質問をAIが正しくデータ操作へ変換できる説明」にしてください。
認証は「受信」と「送信」を分けて設計する
SQL MCP Serverの認証は、クライアントからSQL MCP Serverへの受信認証と、SQL MCP ServerからAzure SQLへの送信認証に分けて考えます。Microsoft Learnでも、Microsoft AI FoundryエージェントやカスタムMCPクライアントを接続する場合、この2方向の認証設計が必要だと説明されています。(Microsoft Learn)
| 認証の方向 | 何を守るか | 推奨される確認事項 |
|---|---|---|
| 受信認証 | AIエージェントやMCPクライアントが/mcpを呼ぶ権限 | Microsoft Entra ID、JWT、App Service認証、ゲートウェイの要否 |
| 送信認証 | SQL MCP ServerがAzure SQLへ接続する権限 | マネージドID、接続文字列、SQLユーザー、最小権限 |
| ゲートウェイ認証 | APIキーなどJWT以外の方式を前段で扱う | Azure API Managementなどの利用 |
| 複数クライアント | 同じMCPエンドポイントを複数のエージェントが使う | 認証方式が合わない場合はインスタンス分離 |
Azure環境では、SQL MCP ServerからAzure SQLへの接続にマネージドIDを使う設計が有力です。公式ドキュメントでは、Azure SQL向けにManaged Service Identitiesをサポートし、接続文字列にAuthentication=Active Directory Managed Identityを指定する例が示されています。(Microsoft Learn)
Server=tcp:<server>.database.windows.net,1433;
Initial Catalog=<database>;
Authentication=Active Directory Managed Identity;ユーザー割り当てマネージドIDを使う場合は、接続文字列にクライアントIDを含めます。
Server=tcp:<server>.database.windows.net,1433;
Initial Catalog=<database>;
Authentication=Active Directory Managed Identity;
User Id=<uami-client-id>;接続文字列をdab-config.jsonに直書きするのは避けてください。公式ドキュメントでも、@env()を使ってシークレットを構成ファイルから除外する方法が推奨されています。(Microsoft Learn)
{
"data-source": {
"database-type": "mssql",
"connection-string": "@env('SQL_CONNECTION_STRING')"
}
}Azure Container AppsとApp Serviceのどちらに展開するか
SQL MCP ServerはData API builderとして動作するため、Azure上ではAzure Container AppsやAzure App Serviceなどに展開できます。Data API builderの展開オプションには、Azure App Service、Azure Container Apps、Azure Container Instances、Azure Kubernetes Serviceなどが含まれます。(Microsoft Learn)
| 展開先 | 向いているケース | 注意点 |
|---|---|---|
| Azure Container Apps | コンテナベースでスケールさせたい、環境分離したい | ingress、シークレット、レプリカ数、Azure SQLファイアウォールを確認 |
| Azure App Service | コンテナを管理せずコードベースで運用したい | startup script、アプリ設定、App Service認証の有効化を確認 |
| AKS | 既存のKubernetes運用基盤がある | 運用負荷、Secret管理、ヘルスプローブを設計する |
| ローカル実行 | 検証、VS Code、MCP Inspectorでの確認 | 本番と認証・権限差分が出やすい |
Azure Container Appsのクイックスタートでは、dab-config.jsonを含むカスタムイメージをAzure Container Registryでビルドし、Container Appsへデプロイする流れが示されています。デプロイ時にはMSSQL_CONNECTION_STRINGをシークレット参照として渡し、/healthで正常性を確認します。(Microsoft Learn)
App Serviceの場合は、コンテナイメージを管理せずにDABをデプロイでき、TLS、カスタムドメイン、スケーリング、監視、Microsoft Entra認証を利用できます。公式手順では、dab-config.json、.config/dotnet-tools.json、startup.shをZIPデプロイし、App Serviceのアプリ設定に接続文字列を入れる流れが示されています。(Microsoft Learn)
本番環境では、まず次の3点を満たす構成を選んでください。
| 本番要件 | 確認ポイント |
|---|---|
| 外部公開範囲 | /mcpをインターネット公開するのか、社内・VNet内に閉じるのか |
| ID管理 | Entra ID、マネージドID、API Management、App Service認証の組み合わせ |
| 監視と追跡 | Application Insights、Log Analytics、OpenTelemetry、/healthの監視 |
SQL MCP ServerとAzure MCP Serverを混同しない
Azure SQL関連のMCP情報では、「SQL MCP Server」と「Azure MCP ServerのAzure SQL Database用ツール」が混同されがちです。両者は目的が違います。
| 名称 | 主な目的 | 操作対象 |
|---|---|---|
| SQL MCP Server | AIエージェントがデータベース内のデータを安全に操作する | テーブル、ビュー、ストアドプロシージャなどのデータ面 |
| Azure MCP ServerのAzure SQL Database用ツール | 自然言語でAzure SQL Databaseリソースを管理する | データベース作成、削除、更新、一覧表示、ファイアウォール規則などのAzureリソース面 |
Microsoft LearnのAzure SQL Database用Azure MCP Serverツールは、自然言語プロンプトでデータベースの作成、削除、更新、一覧表示などのAzure SQL Databaseリソース管理を行うものとして説明されています。これは、SQL MCP ServerのようにData API builderのエンティティを通じて業務データを操作する仕組みとは役割が異なります。(Microsoft Learn)
管理者の判断としては、次のように分けると安全です。
| やりたいこと | 使う候補 |
|---|---|
| Azure SQL Databaseを作成・削除・スケール変更したい | Azure MCP ServerのAzure SQL Database用ツール |
| Azure SQL内の商品、注文、顧客データをAIエージェントから検索・更新したい | SQL MCP Server |
| 本番の業務データ操作をロールとフィールド単位で制御したい | SQL MCP Server |
| Azureリソース操作を自然言語で補助したい | Azure MCP Server |
管理者・開発者向けの導入チェックリスト
SQL MCP ServerをAzure SQL環境へ導入する前に、次のチェックを行ってください。
| 項目 | 確認内容 |
|---|---|
| バージョン | Data API builder 1.7以上か。2.0 preview機能を使う場合は本番影響を評価したか |
| エンティティ | MCPに公開するテーブル、ビュー、ストアドプロシージャを最小限にしたか |
| 権限 | anonymous:*を検証用のまま残していないか |
| フィールド制御 | 個人情報、原価、内部メモ、監査ログなどを除外したか |
| DMLツール | delete-record、update-record、execute-entityを本当に許可する必要があるか |
| 説明文 | エンティティ、列、パラメーターに業務的な説明と有効値を付けたか |
| 認証 | 受信認証とAzure SQLへの送信認証を分けて設計したか |
| シークレット | 接続文字列を@env()、Key Vault、アプリ設定などで外出ししたか |
| ネットワーク | Azure SQLファイアウォール、Private Link、Container Apps/App Serviceの到達性を確認したか |
| 監視 | /health、ログ、Application Insights、OpenTelemetryで操作を追跡できるか |
| 検証 | describe_entitiesとlist_toolsで、AIに見える範囲を確認したか |
よくある失敗と回避策
失敗: AIに見せるエンティティが広すぎる
検証時にanonymous:*で追加したエンティティをそのまま残すと、AIエージェントが想定以上の操作を実行できる可能性があります。まず読み取り専用のビューから始め、更新や削除は業務上必要な場合だけ許可してください。
失敗: 説明文が不足してAIが列や値を推測する
Status、Type、Codeのような列は、説明なしではAIが意味を取り違えやすい項目です。固定値、通貨、日時形式、nullの意味、業務ルールを説明に含めると、誤操作のリスクを下げられます。
失敗: 複雑なJOINをread_recordsに期待する
公式ドキュメントでは、read_recordsは単一のテーブルまたはビュー向けで、JOINはサポートされないと説明されています。複雑な問い合わせはビューまたはストアドプロシージャに閉じ込め、SQL MCP Serverからは安全なエンティティとして公開するのが現実的です。(Microsoft Learn)
失敗: 認証方式の違うクライアントを1つのMCPエンドポイントに集約する
SQL MCP Serverの受信認証はインスタンスごとに設定されます。公式ドキュメントでは、異なる受信認証方式が必要な場合、異なるruntime.host.authentication設定を持つ複数のSQL MCP Serverインスタンスを実行する方法が示されています。(Microsoft Learn)
まず何から始めるべきか
Azure SQLでSQL MCP Serverを検証するなら、最初の一歩は「読み取り専用のビューを1つ公開する」ことです。いきなり既存テーブル全体や更新系ストアドプロシージャを公開するのではなく、AIエージェントに答えさせたい業務質問を1つ選び、そのためのビュー、説明文、読み取り権限だけを作ります。
推奨する初期構成は次の通りです。
| 初期検証の設定 | 内容 |
|---|---|
| 対象データ | Azure SQL上の読み取り専用ビュー |
| 権限 | authenticated:readまたは検証用の最小権限 |
| DMLツール | describe-entitiesとread-records中心 |
| 認証 | ローカル検証後、Entra IDまたはApp Service認証へ移行 |
| 接続 | @env()で接続文字列を外出し |
| 監視 | /health、ログ、Application Insightsを確認 |
SQL MCP Serverは、Azure SQLをAIエージェントから扱うための強力な入口になります。ただし、安全性はツール自体ではなく、Data API builderのエンティティ設計、RBAC、認証、説明文、展開構成で決まります。まずは読み取り専用・小さな範囲で検証し、describe_entitiesでAIに見える世界を確認してから、更新やストアドプロシージャ実行へ段階的に広げるのが安全です。
コメント