Microsoft Foundry の Agent から MCP 経由で SQL Server を叩く

はじめに

2025年11月より「Azure AI Foundry」は「Microsoft Foundry」という名称に変更されました。
あわせてポータルも刷新され、ポータル上部のトグルから Microsoft Foundry (classic) / Microsoft Foundry (new) を切り替えて、新しい UI を試せるようになっています。

参考：Mcrosoft Foundry とは

今回は、Microsoft Foundry の最新 UI で Agent を作成し、Logic Apps を MCP サーバーとして登録しつつ、Azure SQL Server にクエリを投げる検証をやってみました。

最終的には、Agent のプレイグラウンドから

「XXX テーブルの一覧取得して」

とチャットすると、裏側で Logic Apps → SQL Server が動いて結果を返してくれる、という構成です。

本記事では、以下の流れでそのセットアップ方法をまとめます。

• Microsoft Foundry の最新 UI で Agent を作成
• Logic Apps を MCP サーバーとして登録（Custom Tool）
• Agent から SQL を叩く

1. Microsoft Foundry の最新 UI で Agent を作成

まずは Foundry の最新 UI で Agent を作成します。

• モデル：任意の GPT 系モデル（※今回は GPT-4.1-mini を利用）

2. Custom Tool（MCP）を登録

登録方法

• Agent の Tools メニューから追加
• 「SQL Server」を指定
• 「SQL クエリを実行する（V2）」アクションを設定
• MCP 設定情報 / サーバー、データベース情報を指定

ここで登録した Custom Tool が、後述の Logic Apps に HTTP でリクエストを投げる役割になります。

MCP で利用するアクションを選びます。

作成する MCP の情報を入力します。

ツール側で必要な情報を設定します。

• SQL Server 情報（サーバー名・DB 名）
• アクション実行に必要なパラメーター

今回は SQL クエリがパラメーターとして必要なので、モデルから渡される前提で設定します。

詳しい登録方法は以下の Microsoft Learn を参照ください。
Azure Logic Apps のコネクタ アクションによってサポートされる Foundry にエージェント ツールを追加する

3. Logic Apps 側で MCP 用のフローを確認

Custom Tool の作成が完了すると、Logic Apps （Standard プラン）が自動で作成されます。

ワークフローの中身がどうなっているか確認します。

HTTP トリガーで、SQL Server のアクションが実行される仕組みになっていることが分かります。

4. Agent に Tool の登録をする

Foundry に戻り Tools メニューを開くと、先ほど作成したツールが表示されます。

ツールの詳細を見ると、作成済みの Agent に登録することができます。
右上の「Use in an agent」から対象の Agent を指定します。

指定した Agent を開くと、 Tools に登録されます。

5. Agent の検証

ここまで準備ができたので、Agent のプレイグラウンドから実際に試してみます。

ユーザー: 注文の一覧を教えて

Tool 実行が必要な場合に承認を求められましたので、承認します。

Logic Apps → SQL Server で正しくクエリが実行され、Agent 側で結果が表示されました。

• Agent が Custom Tool（Logic Apps MCP）を呼び出す
• Logic Appsに query: "SELECT * FROM Orders" のようなリクエストが飛ぶ
• Logic Apps → SQL Server でクエリ実行
• 結果が Agent に戻り、テーブル形式などでレスポンスが返る

6. おまけ（トークン使用量を簡単に比較してみる）

Agent による回答後に、プレイグラウンドで消費したトークン数を確認できます。

今回のケースでは、Agent + MCP(Logic Apps) + SQL 構成で 1 回の問い合わせあたり 1171 トークンを消費していました。
これが「多いのか少ないのか」をざっくり把握するために、ツールを使わない場合との比較も簡単に行ってみました。

ツールなし構成での比較

比較用に、テーブル（十行程度）の中身を JSON にして、そのままシステムメッセージに埋め込み、まったく同じ質問を投げてみます。

システム：
以下は Orders テーブルの全データです。  
以降の質問には、このデータだけを使って回答してください。
[
  {
    "注文ID": 1,
    "顧客ID": 1,
    "注文日": "2025-07-05 10:15",
    "ステータス": "Paid",
    "メモ": "通常注文"
  },
  {
    "注文ID": 2,
    "顧客ID": 2,
    "注文日": "2025-07-12 14:22",
    "ステータス": "Shipped",
    "メモ": "ギフト包装"
  },
  ...
]

結果、ツールを利用した方法よりも、ツールなし構成の方がわずかにトークン消費は少ないという結果になりました。

なぜツール利用の方がトークンが多くなるのか

今回のような小さなテーブル（十行程度）では、以下のような理由で「ツールを使った構成の方が、むしろトークンが多い」という結果になることが多いと思います。

• Agent が内部的に
  • ツール呼び出しの説明
  • ツール実行ログ（どのツールをどの引数で呼ぶか）
  • ツールから返ってきた結果
    といったメタ情報をプロンプトとして扱うため、その分トークンが増える
• Logic Apps から返す JSON の構造がややリッチで、シンプルなテーブル JSON よりも若干トークン数が多くなりやすい

そのため、「小さなテーブルを 1 回だけ見る」という用途に限っていえば、

• ツールなしでテーブル全体をシステムメッセージに埋めてしまう
• そのまま LLM にフィルタや整形を任せる

というシンプル構成の方が、トークンだけを見ると有利になる場合があります。

それでもツール構成を選ぶ理由

一方で、実運用を考えると次のような観点があります。

• テーブル行数が増えるほど、テーブル全体を毎回プロンプトに載せるのは現実的ではない（プロンプト上限・コストともに厳しくなる）
• LLM は「取得結果の要約・整形・説明」に専念できるため、データ量が増えたときに スケールしやすい

このように、扱うデータ量に応じて「どこからツール構成が有利になりそうか」を意識した設計が肝になってくるかと思います。

7. まとめ

本記事では、Microsoft Foundry の最新 UI で Agent を作成し、Logic Apps を MCP サーバーとして登録して SQL Server にクエリを投げるまでの流れを紹介しました。

• Microsoft Foundry の Agent から Logic Apps MCP を呼び出す構成を簡単に作成できる
• アクションを使い分けることで、様々なシナリオに対応できそう

といった所感を得ることができました。