Data-Api-Builder | The .NET Blog

SQL MCP ServerをAzure App Serviceで動かす — コンテナ不要

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらからご覧いただけます。

正直に言うと、チュートリアルで「コンテナが必要」という言葉を見るたびに少しため息が出ます。コンテナは素晴らしいのですが、チームにコンテナ戦略がない場合、シンプルに見えた機能が予期しないオーケストレーションの複雑さに阻まれることになります。

だからこそ、これは注目に値します。SQL MCP ServerがAzure App Serviceで動作するようになりました — DockerもKubernetesも不要で、MCP、REST、GraphQLを通じてSQLデータベースを公開する同じData API Builder（DAB）の設定ファイルだけで動きます。

SQL MCP Serverとは？

まだご存知でない方への簡単な説明です。SQL MCP ServerはAIエージェントとSQLデータベースの間に位置します。エージェントにデータベースへの直接アクセスを与える（これはひどいアイデアです）代わりに、テーブルやビューを権限が定義されたエンティティという抽象化レイヤーとして公開します。

Data API Builder上に構築されており、1つの設定ファイルがMCP と REST と GraphQLを同時に管理します。エージェントはMCPエンドポイントと通信し、従来のアプリケーションはRESTまたはGraphQLと通信します。同じ設定、同じランタイム、異なるインターフェース。

これは本当に便利です。2つの別々なAPIレイヤーを管理する必要がありません。

コンテナの問題（と解決策）

SQL MCP Serverの元のデプロイモデルはコンテナでした。多くのチームではうまく機能しますが、すべてのチームではありません。多くの.NETチームはAzure App ServiceやVMに標準化しています。SQLエンドポイントを公開するためだけにコンテナランタイムを必要とするのは、誰も求めていない摩擦を生み出します。

新しいウォークスルーではコンテナを完全にスキップする方法を示しています。すべてdab startコマンドで動作し、標準の.NET 8 Webプロセスとして App Serviceにホストされます。

# Data API Builderをインストール
dotnet tool install microsoft.dataapibuilder --prerelease -g

# 設定を初期化
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# エンティティを追加
dab add products --source dbo.products --permissions "authenticated:*"

# App Service認証プロバイダーを設定
dab configure --runtime.host.authentication.provider AppService

# サーバーを起動
dab start

この時点で、/mcpでMCP、同じプロセスからRESTとGraphQLが利用可能になり、コンテナは一切不要です。

共有APIキーなしの認証

これが私が最も評価する部分です。App Serviceにデプロイする際、Microsoft Entra IDを認証プロバイダーとして設定します。設定ファイルに共有シークレットを埋め込む必要はなく、APIキーをローテーションする必要もありません。

接続文字列はApp Serviceの環境変数に保持され（dab-config.jsonには含まれません）、MCPエンドポイントはプラットフォーム認証で保護されます。Azure AIのワークロードでEntra IDにすでに対応している場合、これは自然に統合されます。

ローカル開発ではSimulatorモードとSTIOトランスポートに切り替えます。デプロイ前にAppServiceモードに戻します。クリーンで明示的な設定です。

App Serviceへのデプロイ

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

その後、チームがすでに使用しているコードデプロイ方法でDABプロジェクトをデプロイします。重要なポイント：これはコードのデプロイであり、コンテナのデプロイではありません。

.NET開発者にとって重要な理由

.NETでAIエージェントを構築している場合、エージェントはいずれデータベースと通信する必要があります。SQL MCP Serverは、生の接続文字列を公開したりカスタムAPIレイヤーを書いたりすることなく、それを行う構造化された方法を提供します。

完全なウォークスルーは元のブログ記事とGitHubのサンプルリポジトリでご確認ください。

まとめ

App Service上のSQL MCP Serverは、コンテナ戦略なしにエージェントに構造化されたSQLデータアクセスを提供したい.NETチームにとって、実用的な選択肢です。ぜひ試してみてください — エージェントはクリーンなAPIサーフェスを高く評価するでしょう。

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の規範的アプローチです。始めるには完全な記事とドキュメントをご覧ください。