翻訳者ノート
こんにちは!コンテンツチームの加藤です。
SQL ServerにAIツールを繋ぐたびに、専用のパイプラインを一から組んでいませんか?この記事では、Connect AIのマネージドMCPエンドポイント一つで、Claude・ChatGPT・Copilot Studioなど複数のAIツールを同じ方法でSQL Serverに接続する仕組みを解説しています。リンクサーバー経由でT-SQL側から外部データを取り込む方法も紹介しているので、既存のレポーティングロジックを活かしたいチームにも参考になるはずです。 |
モデルの性能が向上する一方で、企業のAIプロジェクトは依然としてその基盤となるデータ層で足踏み状態にあります。SQL Serverには数十年にわたる運用履歴が蓄積されています。しかし、そのために特別に構築されたパイプラインがなければ、AIツールはこのデータにアクセスできません。 CData Connect AIは、マネージド型Model Context Protocol(MCP)プラットフォームとしてこのギャップを解消します。単一のガバナンス管理されたエンドポイントを通じて、AIアシスタントやエージェントにSQL Serverやその他数百のエンタープライズシステムへの認証済みリアルタイムアクセスを提供します。
Model Context Protocol(MCP)は、Anthropic社が開発したオープンスタンダードです。アシスタントがアクセスする必要のあるデータソースごとに個別の統合を構築するのではなく、AIアプリケーションを構造化システムに直接接続することを目的としています。
SQL ServerのAIデータ統合を検討しているチームにとって、何よりもまず理解すべきメカニズムはこれです。つまり、1つのMCPエンドポイントが本来なら各AIツールごとに必要となる個別のコネクタに取って代わるのです。 Claude、ChatGPT、Microsoft Copilot Studio、n8n といったツールはすべて、Connect AI を通じて同じ方法で SQL Server にアクセスします。
新しいデータソースがオンラインになるにつれて、この接続は他のデータ資産全体にも拡張されていきます。 こうした「1つのエンドポイントで複数システムを扱う」設計が、AIエージェントにどこまでの自律性を委ねるべきかという判断にも関わってきます。その判断基準は自律性のスペクトラムのどこにいても、AIエージェントに必要な条件で詳しく整理しています。
SQL ServerでAIを使うには何が必要?
SQL ServerをAIアクセスに対応させるのに、大規模な開発プロジェクトは必要ありません。セットアップ手順は以下の4つのステップで構成されています(対象はオンプレミスのSQL Server、Azure SQL Database、Azure SQL Managed Instanceのいずれも含みます)。
CData Connect AIに登録します。
ダッシュボードにアクセスします。
[データソース] ページから SQL Server をデータソースとして追加します。
接続用アカウントに必要な環境と権限を確認します。
AIツールが実際にどのデータにアクセスできるかは、この4番目のステップで決まるため、権限設定は慎重に確認しておく必要があります。Connect AIは、接続時に指定された認証情報(クレデンシャル)を使用してSQL Serverへの認証を行います。そのため、AIツールからのアクセスは、そのアカウントがすでにクエリを実行できる範囲内に自動的に制限されます。
接続が確立されると、Connect AI は SQL Server と他のすべての接続済みデータソースを、標準化された SQL レイヤーを通じて公開します。これにより、LLM は各システムのネイティブ API を学習する必要がなく、同じ構文で CRM やデータベースにクエリを実行できるようになります。
SQL ServerとAIの連携方法は?
「AIをSQL Serverに接続する」という言葉は、実際には2つの異なるアーキテクチャを指しており、どちらを選択するかは、どのシステムが推論を行うかによって決まります。
AIファースト:AIツール(Claude、ChatGPT、Copilot Studio、またはMCP互換のエージェントフレームワーク)が、Connect AIの単一のMCPエンドポイントに接続します。他の接続済みデータソースと同様に、SQL Serverへ直接クエリを実行する形です。
これは、現在のほとんどの SQL Server MCP サーバー構成の基盤となっているパターンで、SQL Server 自体に変更を加える必要はありません。 同じAIファーストの発想は、SalesforceのようなSaaSデータをClaude Codeから直接操作するケースにも当てはまります。実装イメージはClaude CodeとMCPでSalesforceアプリケーションを構築する方法で確認できます。
SQL Serverファースト:SQL Serverが、Connect AIの仮想SQL Serverエンドポイントを指すリンクサーバーを通じて外部データを取得する形です。AIやML呼び出しを含む既存のT-SQLワークフローは、その統合された結果に対してそのまま実行されます。 これは、T-SQL にレポート作成やスコアリングロジックがすでに組み込まれており、SQL Server がネイティブに保持していないデータにアクセスする必要があるチームに最適です。
MCPでAIツールをSQL Serverに接続するには?
Connect AI に SQL Server がデータソースとして追加されると、MCP 互換のクライアントはすべて、https://mcp.cloud.cdata.com/mcp という同じ URL を通じて SQL Server にアクセスできます。認証方法はクライアントによって異なりますが、Connect AI は OAuth と基本認証の両方をサポートしています。基本認証では、Connect AI のユーザー ID と、[設定] ページから生成されたパーソナルアクセストークン (PAT) を使用します。 PATは静的で取り消し可能な認証情報です。統合ごとに個別のPATを発行しておけば、トークンが侵害された場合でも被害をそのスコープ内の単一接続に抑えられます。
その1つのURLの背後では、Connect AIのMCPサーバーが、データの発見とクエリ、スキーマの検索、クエリ実行という一連の固定ツールセットを提供します。具体的には、以下のようなツールが標準で公開されます。
list-data-sources:Connect AIに接続済みのデータソース(SQL Serverを含む)を一覧表示する
discover-schema:指定したデータソースのテーブルおよびカラム構造を取得する
execute-query:SQLクエリを実行し、結果セットを返す
get-query-results:非同期実行したクエリの結果を取得する
AIツールがどのデータソースにアクセスする場合でも、手順は同一です。 Connect AI を通じて SQL Server へのクエリ方法を学習した AI ツールは、Salesforce、OData フィード、またはその他の接続されたデータソースに対しても、同様の方法でクエリを実行する方法をすでに習得しています。
外部データをSQL Serverに取り込むには?
T-SQL 内で処理を行う必要があるワークフローの場合、Connect AI は tds.cdata.com のポート 14333 でも仮想 SQL Server エンドポイントを公開しており、任意の SQL Server クライアントがこれをリンクサーバーとして登録できます。登録されると、外部データソースはリモート SQL Server インスタンスと同様に SQL Server 内に表示されます。
SQL Server Management Studio (SSMS) でリンクサーバーを作成するには:
オブジェクト エクスプローラーでサーバー ノードを展開し、「リンクされたサーバー」を右クリックして、「新しいリンクされたサーバー」を選択します。
[その他のデータソース] を選択し、プロバイダーとして [SQL Server Native Client 11.0] を選択します。
[データ ソース] を [tds.cdata.com,14333] に設定します。
[カタログ] に、公開したい Connect AI 接続の名前(例: ADP1)を設定します。
[セキュリティ] ページで、[このセキュリティ コンテキストを使用して実行する] を選択し、リモート ログインに Connect AI のメールアドレスを、パスワードに PAT を入力します。
リンクされたサーバーが登録されると、クエリの実行は他のリモート SQL Server インスタンスへのクエリと同様になり、4 部構成の命名規則が使用されます。
SELECT * FROM [ConnectAI].[ADP1].[ADP].[Employees]
CDataは、この接続を純粋なSQL Serverインターフェースとして説明しています。レプリケーションやコピーを維持するカスタム同期ジョブを用意しなくても、SQL Serverはあたかもローカルテーブルのように外部データをクエリできる、という意味です。 1 つの SQL Server インスタンスは、接続されたすべてのデータソース(ADP、OData フィード、CRM)に対してリンクサーバーを登録できます。それぞれを同じ T-SQL 構文でクエリでき、実際にローカルにあるテーブルと結合することも可能です。 CRMデータをMCP経由で別のデータベースに連携させる考え方は、Claude CodeとMCPを使ったSalesforceからMySQLへの連携方法でも同様のパターンとして紹介しています。

SQL ServerでAIモデルを実行する方法は?
SQL Server 内で外部データにアクセスできるようになったため、次のステップはモデル自体をどこで実行するかを決定することです。SQL Server には、T-SQL 内で R や Python をインラインで実行するストアドプロシージャ「sp_execute_external_script」が用意されています。これにより、モデル呼び出しとレポート用クエリを、手動で同期を維持しなければならない 2 つのシステムではなく、同じプロシージャ内に収めることが可能になります。
方法 | 最適な用途 |
sp_execute_external_script | ストアドプロシージャ内で、クエリ結果に対して R または Python を直接インラインで実行する |
Azure ML パイプライン | スケジュールに従って実行する必要があるモデル、または単一のクエリを超える規模で実行する必要があるモデル |
Connect AI 経由の MCP | 中間スクリプトを一切介さずにSQL Serverのデータにアクセスする必要があるAIツール |
MCPの仕組みは他の2つとは構造的に異なります。SQL Server内部でスクリプトを実行するのではなく、AIツールがConnect AIを介してSQL Serverに直接クエリを実行するため、SQL Server側ではAIモデルの存在を認識する必要が一切ありません。既存のT-SQLロジックを拡張するのではなく、新しいAIワークフローを構築するチームにとっては、通常、これがよりシンプルな出発点となります。
既製・カスタムAIモデルはどう使い分ける?
カスタムモデルから始めるのは、通常、間違った第一歩です。Azure OpenAI や Microsoft Copilot Studio などの既成モデルを利用すれば、チームが担当すべきセットアップ作業を削減でき、AI アシスタントが実稼働中の SQL Server データに基づいてほぼ即座に質問への回答を開始できるようになります。
カスタムモデルへの移行は、主に次の3つの要因のいずれかで引き起こされる傾向があります。
1つ目は、データが十分に特定化され、汎用モデルでは有用な回答が得られなくなった場合。2つ目は、ユースケースに既成モデルでは表現できないロジックが必要な場合。3つ目は、クエリのボリュームが大きく、共有サービスよりも専用のAPI呼び出しの方が現実的になる場合です。
いずれも、最初からカスタムモデルを構築すべき理由にはなりません。むしろ、カスタムモデルへ移行できる経路をあらかじめ確保しておくべき理由といえます。 BIツールやETL、ノーコードプラットフォームにAI機能を組み込みたい場合は、AIを活用してBI、ETL、EAI、ノーコードプラットフォームの統合を加速する方法も判断材料になります。
AI導入の拡張・管理はどう行う?
AIとSQL Serverにおけるスケーリングの問題は、通常、モデルそのものに関するものではありません。それは、2つ目のチーム、3つ目のデータソース、あるいは10番目のAIエージェントが登場した際に何が起こるかという問題です。Connect AIにおける新しいデータソースの追加はすべて、すでに説明したのと同じセットアップ手順に従うため、1つ追加しても新しい統合パターンを必要としません。
ガバナンスこそが、その拡張が負担に転じるのを防ぐものです。Connect AIの権限およびアクセス制御は、人間ユーザーと同様にAIエージェントにも適用されます。そのため管理者は、どのエージェントがどのデータソースにクエリを実行しているかを確認し、それに応じてアクセスを制限できます。人間・AI双方を網羅する監査証跡も記録されます。
なお、CDataのデータ連携製品群はGartner® Magic Quadrant™に継続的に評価されており、エンタープライズ品質の信頼性が第三者機関によっても認められています。 データソース数、モデル数、同時稼働するエージェント数が増えても、チーム全体でインフラを変更する必要はありません。1つのSQL Serverインスタンスと1つのAIアシスタントで機能していた接続レイヤーは、10個のインスタンスやエージェントをサポートする規模になっても変わらず使えます。
安全なAI連携のベストプラクティスは?
監査に耐えうる導入と、知らぬ間にリスクを蓄積してしまう導入とを分けるのは、いくつかの習慣です。
すべての場所で1つの認証情報を再利用するのではなく、接続するサービスごとに個別のPATを生成します。
その場しのぎの権限変更ではなく、Connect AIに組み込まれたガバナンスツールを使用して使用状況を監視し、アクセスを制限する。
可能な限りノーコードまたは事前構築済みモデルの設定から始め、ユースケースで必要とされる場合にのみ複雑さを追加する。
すべてのAIモデルのアクセスポイントを文書化し、問題が発生した時だけでなく、定められたスケジュールに従って定期的に見直す。
本番環境のSQL Serverデータに対するAI駆動のクエリは、そのデータにアクセスする他のビジネスインテリジェンスプロセスと同様に、厳格なセキュリティ審査を受ける必要があります。これを特別なケースとして扱い、他の場所では適用されているアクセスレビューから除外してしまうと、後々ガバナンスの欠陥が露呈することになります。
実際に、あるエンタープライズIT部門では、Connect AIの導入により、AIツールごとに個別のコネクタを保守する運用負荷がなくなり、新しいデータソースを追加してAIエージェントからアクセス可能にするまでの時間を数日から数時間に短縮できたと報告しています。
AIツールからSQL Serverへのクエリ実行を開始
実際のやり取りはシンプルです。SQL Serverが接続済みであれば、Claudeに次のように尋ねるだけでクエリが実行されます。
プロンプト例 | Claudeの応答 |
「先月、地域別の売上合計が最も高かった上位5件を教えて」 | Connect AIのMCPツールでSQL Serverのスキーマを確認し、該当するクエリを組み立てて実行、結果を表形式で回答 |
AIをSQL Serverに接続するために、アシスタントがアクセスするデータソース一つひとつにETLやレプリケーション、カスタムコネクタを用意する必要はありません。必要なのは、AIツールの実行前にアクセス権限を確認し、リアルタイムクエリを処理する、ガバナンスが適用された単一のエンドポイントだけです。 CData Connect AIは、SQL Serverをはじめ数百の業務データソースに向けて、チーム全体で使えるこのエンドポイントを提供し、既存システムに紐づいた権限をそのまま維持します。
CData Connect AI を詳しく見る
SQL Serverのデータを今すぐAIエージェントで活用
Connect AIは14日間の無料トライアルを提供しています。今すぐトライアルをスタートして、AIツールとSQL Serverのリアルタイム連携をお試しください。
無料トライアルをスタート