Databases | The .NET Blog

SQL MCP Server — AIエージェントにデータベースアクセスを与える正しい方法

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

正直に言いましょう：今日利用可能なほとんどのデータベースMCPサーバーは恐ろしいものです。自然言語のクエリを受け取り、その場でSQLを生成し、本番データに対して実行します。何がうまくいかないでしょうか？（全部です。全部うまくいかない可能性があります。）

Azure SQLチームがSQL MCP Serverを発表しましたが、根本的に異なるアプローチを取っています。Data API builder（DAB）2.0の機能として構築され、AIエージェントに構造化された決定的なデータベース操作アクセスを提供します — NL2SQLなし、スキーマの公開なし、そしてすべてのステップで完全なRBAC付き。

なぜNL2SQLを使わないのか？

これが最も興味深い設計判断です。モデルは決定的ではなく、複雑なクエリは微妙なエラーを生み出す可能性が最も高いです。ユーザーがAIに生成してほしいと思う正にそのクエリが、非決定的に生成された場合に最も精査が必要なものでもあります。

代わりに、SQL MCP ServerはNL2DABアプローチを使用します。エージェントはData API builderのエンティティ抽象化レイヤーと組み込みのクエリビルダーで作業し、正確で整形されたT-SQLを決定的に生成します。ユーザーにとっては同じ結果ですが、幻覚されたJOINや偶発的なデータ漏洩のリスクがありません。

7つのツール、700ではなく

SQL MCP Serverは、データベースのサイズに関係なく、正確に7つのDMLツールを公開します：

describe_entities — 利用可能なエンティティと操作を発見
create_record — 行を挿入
read_records — テーブルとビューをクエリ
update_record — 行を変更
delete_record — 行を削除
execute_entity — ストアドプロシージャを実行
aggregate_records — 集計クエリ

これは賢明です。コンテキストウィンドウはエージェントの思考空間だからです。何百ものツール定義で氾濫させると、推論のための空間が減ります。7つの固定ツールは、エージェントをナビゲーションではなく思考に集中させ続けます。

各ツールは個別に有効化・無効化できます：

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

3つのコマンドで開始

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

これでCustomersテーブルを公開するSQL MCP Serverが稼働します。エンティティ抽象化レイヤーにより、名前やカラムにエイリアスを設定し、ロールごとにフィールドを制限し、エージェントが見るものを正確に制御できます — 内部スキーマの詳細を公開することなく。

セキュリティストーリーは堅実

ここがData API builderの成熟さが活きるところです：

あらゆるレイヤーでRBAC — 各エンティティがどのロールが読み取り、作成、更新、削除できるか、どのフィールドが表示されるかを定義
Azure Key Vault統合 — 接続文字列とシークレットを安全に管理
Microsoft Entra + カスタムOAuth — 本番グレードの認証
Content Security Policy — エージェントは生のSQLではなく、制御されたコントラクトを通じてやり取り

スキーマの抽象化は特に重要です。内部テーブル名やカラム名はエージェントに露出しません。AI対話に意味のあるエンティティ、エイリアス、説明を定義します — データベースのERD図ではなく。

マルチデータベースとマルチプロトコル

SQL MCP ServerはMicrosoft SQL、PostgreSQL、Azure Cosmos DB、MySQLをサポートします。そしてDABの機能であるため、同じ設定からREST、GraphQL、MCPのエンドポイントを同時に取得できます。同じエンティティ定義、同じRBACルール、同じセキュリティ — 3つのプロトコルすべてで。

DAB 2.0の自動設定は、データベースを検査して設定を動的に構築することもできます。迅速なプロトタイピングのために抽象化を減らしても良い場合に便利です。

私の見解

これがAIエージェント向けのエンタープライズデータベースアクセスのあるべき姿です。「ねぇLLM、SQLを書いてプロダクションにYOLO」ではなく。代わりに：明確に定義されたエンティティレイヤー、決定的なクエリ生成、各ステップでのRBAC、キャッシュ、モニタリング、テレメトリ。最高の意味で退屈です。

.NET開発者にとって、統合ストーリーはクリーンです — DABは.NETツールで、MCP Serverはコンテナとして動作し、ほとんどの人がすでに使っているAzure SQLで機能します。データアクセスが必要なAIエージェントを構築しているなら、ここから始めましょう。

まとめ

SQL MCP Serverは無料、オープンソースで、どこでも動作します。AIエージェントに安全なデータベースアクセスを提供するためのMicrosoftの規範的アプローチです。始めるには完全な記事とドキュメントをご覧ください。

SQL MCP Server、SSMS の Copilot、AI エージェント付き Database Hub：SQLCon 2026 で本当に重要なこと

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft がアトランタの FabCon と併催で SQLCon 2026 をキックオフしました。内容盛りだくさんです。元の発表はコスト削減プランからエンタープライズコンプライアンス機能まで全部カバーしていますが、エンタープライズ価格のスライドは飛ばして、Azure SQL と AI で開発している人にとって本当に重要な部分にフォーカスします。

SQL MCP Server がパブリックプレビューに

これが僕にとってのヘッドラインです。Azure SQL Database Hyperscale に SQL MCP Server のパブリックプレビューが追加され、Model Context Protocol を使って SQL データを AI エージェントや Copilot にセキュアに接続できるようになりました。

MCP の波を追いかけている人なら — 正直、今は見逃すほうが難しいですよね — これは大きなニュースです。データベースからのコンテキストを AI エージェントに渡すためにカスタムデータパイプラインを構築する代わりに、SQL データを直接公開するための標準化されたプロトコルが手に入ります。エージェントがライブのデータベース情報をクエリし、推論し、アクションを起こせるようになります。

Semantic Kernel や Microsoft Agent Framework で AI エージェントを構築している人にとって、これはクリーンな統合パスを開きます。エージェントが在庫を確認する必要がある？顧客レコードを検索する？注文を検証する？MCP がシナリオごとにカスタムのデータ取得コードを書かなくても、構造化されたやり方を提供してくれます。

SSMS 22 の GitHub Copilot が GA に

SQL Server Management Studio を使っている人 — 正直に言うと、ほとんどの人がまだ使っていますよね — GitHub Copilot が SSMS 22 で正式に一般提供になりました。VS Code や Visual Studio で使っているのと同じ Copilot 体験が T-SQL で使えます。

実用的な価値はシンプルです：クエリの作成、ストアドプロシージャのリファクタリング、パフォーマンス問題のトラブルシューティング、管理タスクのためのチャットベースのアシスタンス。コンセプトとしては革命的ではないですが、SSMS の中にあるということは、データベース作業で AI の助けを得るためだけに別のエディタにコンテキストスイッチする必要がないということです。

ベクトルインデックスが本格的にアップグレード

Azure SQL Database のベクトルインデックスが高速化・高機能化し、insert、update、delete の完全サポートが追加されました。つまり、ベクトルデータがリアルタイムで最新の状態を保てます — バッチ再インデックスは不要です。

新機能はこちら：

量子化 でインデックスサイズを縮小（精度の大きな損失なし）
イテレーティブフィルタリング でより精密な結果
クエリオプティマイザーとの緊密な統合 で予測可能なパフォーマンス

Azure SQL をベクトルストアとして Retrieval-Augmented Generation (RAG) を行っている場合、これらの改善は直接的に役立ちます。リレーショナルデータと同じデータベースにベクトルを保持できるので、別のベクトルデータベースを運用するよりもアーキテクチャが大幅にシンプルになります。

同じベクトルの改善は Fabric の SQL Database でも利用可能です。どちらも同じ SQL エンジンで動いているからです。

Fabric の Database Hub：エージェント型管理

これはもう少し将来を見据えた話ですが、面白いです。Microsoft は Microsoft Fabric の Database Hub（早期アクセス）を発表しました。Azure SQL、Cosmos DB、PostgreSQL、MySQL、SQL Server via Arc を一元的に管理できるビューを提供します。

面白いのは統一ビューだけではなく、エージェント型の管理アプローチです。AI エージェントがデータベース環境を継続的に監視し、何が変わったかを示し、なぜそれが重要かを説明し、次に何をすべきかを提案します。エージェントが下調べをして、あなたが判断を下す human-in-the-loop モデルです。

複数のデータベースを管理しているチームにとって、これは運用ノイズを本当に減らせる可能性があります。ポータル間を行き来してメトリクスを手動で確認する代わりに、エージェントがシグナルを届けてくれます。

.NET 開発者にとっての意味

これらの発表をつなぐ共通のテーマは明確です：Microsoft はデータベーススタックのあらゆるレイヤーに AI エージェントを組み込んでいます。ギミックとしてではなく、実用的なツールレイヤーとして。

Azure SQL をバックエンドにした .NET アプリを構築しているなら、僕が実際にやることはこれです：

SQL MCP Server を試す — AI エージェントを構築しているなら。カスタムの配管なしでエージェントにデータベースアクセスを与える最もクリーンな方法です。
SSMS で Copilot を有効にする — まだなら。日常の SQL 作業のための無料の生産性アップです。
ベクトルインデックスを調べる — RAG をやっていて現在別のベクトルストアを運用しているなら。Azure SQL に統合すれば、管理するサービスが一つ減ります。

まとめ

完全な発表にはもっとあります — コスト削減プラン、移行アシスタント、コンプライアンス機能 — でも開発者向けのストーリーは MCP Server、ベクトルの改善、エージェント型管理レイヤーにあります。これらが変えるのは、予算の立て方ではなく、構築の仕方です。

完全な全体像は Shireesh Thota の完全な発表をチェックしてください。新しい管理体験を試したい場合は Database Hub の早期アクセスにサインアップしてください。