Azure SQL | The .NET Blog

NL2SQLはエージェント時代のSQLインジェクションだ

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

NL2SQLのピッチには完璧に聞こえるバージョンがあります：ユーザーが自然言語で質問し、エージェントがSQLを生成し、データが返ってくる。画面が少なく、クエリが少なく、コードが少ない。シンプル。

そして5分後にもっと考えます。

デモで誰も話さない問題

スキーマは物事を説明するように設計されていません。 不可解なテーブル名、一貫性のないカラム名、追加の述語なしでは意味的に無効な技術的に有効な関係 — これらはエンタープライズデータベースでは普通のことです。バグではなく、ビジネス変更の蓄積された歴史です。しかし、意図を伝えるように設計されていないスキーマから意図を推論するようにモデルに求めると、モデルは何があっても試みます。諦めません。最善のクエリを生成し、自信を持って結果を返します。

モデルは決定論的ではありません。 同じデータベースに同じ質問を2回して、異なるSQLを得るかもしれません。モデルは確率を計算しており、コンテキストのわずかな変化が異なる出力を生み出します。エージェントが常に正しいクエリを生成するという保証をテストで達成することはできません。

ユーザーレビューはスケールしません。 「実行前にすべてのクエリを確認するだけ」は安全に聞こえます。しかし、ユーザーがデータモデルとSQLの両方の専門家であることを前提としています — 自然言語インターフェースを必要としなかった人々まさにその人たちです。また、認知的過負荷と確認バイアスの新しいクラスをもたらし、クエリの複雑さに圧倒されたユーザーが無効なクエリを調査するのではなく承認します。

そしてインジェクションがあります。 従来のSQL開発では、パラメータ化がインジェクションを解決しました。ユーザー入力はSQLの構造ではなく、パラメータを埋めていたからです。NL2SQLでは、モデルがSQL自体を生成します。プロンプト、スキーマコンテキスト、会話履歴、取得されたデータすべてが実行されるものに影響します。誰かがモデルが生成するものを変えるプロンプトを作成した場合、それはインジェクションです — パラメータレベルではなく、クエリ生成レベルで。そしてテーブルの削除（明らか、回復可能）とは異なり、NL2SQLインジェクションは目に見えるエラーなしに誤った結果を返すクエリを生成します。ビジネス上の意思決定が間違ったデータに基づいてなされます。

SQL MCP Serverが実際に解決すること

ここで記事は最も実践的に有用な点を述べます。エージェントに任意のスキーマアクセスを与えて最善を望むのではなく、SQL MCP ServerはData API builderの上に構築された厳選されたAPIサーフェスを公開します。

違いは重要です：エージェントはSQLを生成しません。事前定義された結果形式を返す名前付きエンドポイントを呼び出します。SQLは開発者によって一度書かれ、決定論的です。エージェントの非決定論は任意のクエリを構築することではなく、どのエンドポイントを呼び出すかを選択することに制限されます。

これは従来のアプリモデルでのSQLインジェクションに対してパラメータ化が行ったこと — 信頼できない入力から任意のクエリを構築する能力を削除すること — に類似しています。

正しい質問

記事は「NL2SQLを決して使うな」とは言っていません。それは言います：どこで適用し、何を公開するかについて慎重に考えてください。スコープされたスキーマと読み取り専用アクセスを持つ制御された環境での探索的分析には、NL2SQLで問題ないかもしれません。ビジネス上の意思決定が結果に依存する本番システムには、厳選されたAPIレイヤーが大幅に安全です。

正直に言うと：いくつかの問題は、自然言語からSQLよりも名前付きエンドポイントの背後にある構造化されたクエリで解決する方が本当に優れています。SQL MCP Serverはエージェントインターフェースを完全に放棄することなく、そのオプションを提供します。

元の投稿: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL がエンベディングを生成できるようになりました — 純粋な T-SQL で、アプリ層不要

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

RAG パイプラインを構築したことがあれば、パイプライン税を知っているでしょう: データは SQL に存在しますが、エンベディングを生成するにはデータを抽出し、エンベディング API を呼び出し、バッチ処理とレート制限を処理し、ベクトル検索が可能な場所に結果を保存する必要があります。多くの場合、まったく異なるデータベースに。

Azure SQL は、現在一般提供されている 2 つの機能でその大部分を排除しました: CREATE EXTERNAL MODEL と AI_GENERATE_EMBEDDINGS。

何をするか

これら 2 つの T-SQL 機能は統合パイプラインとして機能します:

CREATE EXTERNAL MODEL — 外部 AI モデルエンドポイントを名前付きデータベースオブジェクトとして登録します。場所、API フォーマット、モデルタイプ、資格情報を一度設定します。どこでも再利用できます。

AI_GENERATE_EMBEDDINGS — 登録されたモデルを呼び出し、ベクトル値の JSON 配列を返すスカラー T-SQL 関数です。SELECT、INSERT、UPDATE、MERGE 文で動作します。

合わせて、SQL エンジンを離れることなくエンドツーエンドのエンベディングパイプラインを形成します。

完全なワークフロー

-- ステップ 1: エンベディングプロバイダーを一度登録する
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- ステップ 2: T-SQL でインラインにエンベディングを生成する
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- ステップ 3: ベクトル距離で検索する
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

これがパイプライン全体です: SQL のデータ、SQL で生成されたエンベディング、SQL での類似性検索。オーケストレーション層なし、ETL なし、別個のベクトルデータベースなし。

サポートされる API フォーマットとオプション

GA では、API_FORMAT は Azure OpenAI と OpenAI をサポートします。MODEL_TYPE は現在 EMBEDDINGS に固定されています。PARAMETERS JSON では、再試行回数を含むモデルレベルのデフォルトを設定できます:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

認証はデータベース資格情報を使用するため、シークレットはアプリケーションコードの外に保持されます。

.NET アプリケーションで何が可能になるか

既存の SQL データの上に AI 機能を構築する .NET 開発者にとって、これは重要です。以下は不要です:

エンベディング用に中間ストアにデータを抽出する
外部エンベディングパイプラインを管理する
別個のベクトルデータベースを設定する (フル機能のベクトルストアが必要な場合は Azure AI Search を使用できますが)
アプリケーションのデータアクセス層を変更する

既存の SQL アプリケーションに段階的にセマンティック検索を追加できます。すでにお持ちの同じ T-SQL ツールを使用して。

まとめ

SQL データに対する RAG パターンが劇的にシンプルになりました。AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL は、既存の SQL アプリケーションが新しいインフラを追加することなくベクトル検索機能を獲得できることを意味します。

両機能は本日、Azure SQL Database と Azure SQL Managed Instance で GA です。

元の投稿: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio は廃止されました：Azure SQL ワークフローを VS Code に移行する

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちら。

Azure Data Studio は 2025 年 2 月 6 日に廃止されました。サポートは 2026 年 2 月 28 日に終了します。推奨される代替ツールは MSSQL 拡張機能を備えた VS Code です。

インストールするもの

開始するために必要な 3 つのもの：

MSSQL 拡張機能 — VS Code Marketplace で「SQL Server (mssql)」を検索
SQL Database Projects 拡張機能 — コードとしてのスキーマ、ビルド検証、ガイド付き公開
.NET 8 SDK — ビルドシステムに必要。SDK が見つからないのは初回起動時の最も一般的な問題

ADS の接続と設定の移行

MSSQL 拡張機能には ADS Migration Toolkit が同梱されており、ガイド付きフローで一度きりの移行を処理します。保存された接続、接続グループ、設定、キーバインドがすべて自動的にインポートされます。

F5 のクセを取り戻す

ADS ユーザーはクエリ実行に F5 を使用します。MSSQL Database Management Keymap 拡張機能をインストールすると、F5 を含む ADS スタイルのキーバインドが復元されます。

SQL Database Projects：コードとしてのスキーマ

プロジェクトを右クリック → 公開 → ターゲットを設定 → 生成された T-SQL スクリプトを確認 → デプロイ。デプロイ前のスクリプトプレビューが主要な安全機能です。アイテムテンプレートはテーブル、ストアドプロシージャ、ビューのスタブを生成します。SSDT と同じワークフローです。

よくある問題：.sqlproj ファイルのターゲットプラットフォームの不一致は、プロジェクトが別の SQL Server バージョン用に作成された場合にビルドエラーを引き起こします。

Schema Compare と Schema Designer

拡張機能には Schema Compare（プロジェクトとデプロイ済みデータベースの差分）と Schema Designer（DDL を手書きせずに視覚的にスキーマを編集）も含まれています。

Microsoft Fabric 開発者向け

セットアップは同一ですが、VS Code で開く前に Fabric ポータルからデータベースを Git に接続することから始めてください。Microsoft には専用ガイドがあります：Azure Data Studio to VS Code — What it means for SQL database in Fabric developers。

まとめ

移行は手動での再構築ではなく、一度きりのガイド付きフローです。3 つのツールをインストールし、ADS Migration Toolkit を実行し、キーバインドを復元すれば、10 分以内に通常の作業に戻れます。

ステップバイステップのスクリーンショットと Fabric 固有のウォークスルーについては、完全な記事をご覧ください。

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 Server 2025 エージェント対応データベース：1つのエンジンでセキュリティ、バックアップ、MCP

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されています。オリジナル版はこちらをクリックしてください。

Aditya BadramrajuのPolyglot Taxシリーズを興味深く読んできました。パート4はシリーズを締めくくり、この架構を本番環境で信頼できるかどうかを実際に決める部分に取り組みます。

すべてのデータモデルに対する1つのセキュリティモデル

1つのRow-Level Securityポリシーがすべてのデータモデルをカバー。監査人への証明が1つで済む。

統一バックアップ = アトミックリカバリ

ポリグロットスタックでは、5つのデータベースのPoint-in-Timeリカバリを協調させることは一貫性の悪夢です。1つのデータベースなら、定義上アトミックです。

MCP統合：ハンドコードされたミドルウェア不要

SQL Server 2025はSQL MCPサーバーを直接サポート。エージェントはツールを呼び出し、エンジンが自動的にテナント分離とカラムマスキングを強制します。

オリジナルポスト（Aditya Badramraju著）: The Polyglot Tax – Part 4。

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