2026年6月12日に公式リポジトリへ反映された「Connect Azure Database for PostgreSQL to Microsoft Foundry Using MCP」は、Azure Database for PostgreSQLのデータをMicrosoft FoundryのAIエージェントから利用するための構成・設定手順をまとめた公式ガイドです。
結論として、今回の更新によって既存のAzure Database for PostgreSQLが自動変更されることはありません。利用する場合に限り、Azure Container AppsへMCPサーバーを展開し、Microsoft Entra ID認証とデータベース権限を設定します。
また、2026年6月12日の更新差分は、主にリンク、画像表示、文言、記事更新日の調整です。当該記事の差分には、強制移行、サービス廃止、料金改定、既存データベースの互換性変更は含まれていません。ページ上の最終更新日は2026年6月8日ですが、公式リポジトリへの反映日は2026年6月12日となっています。(GitHub)
2026年6月12日の変更点
今回の更新を、利用者への影響という観点で整理すると次のとおりです。
| 確認項目 | 変更内容・影響 |
|---|---|
| Azureサービスの仕様 | 当該記事の差分では大きな仕様変更なし |
| 既存のPostgreSQL環境 | 自動変更なし |
| MCP連携 | 利用者が明示的に構築する任意の構成 |
| 更新作業 | 既存利用者に必須の更新作業は記載なし |
| 移行期限 | 記載なし |
| 廃止期限 | 記載なし |
| 料金改定 | MCP連携専用の料金改定は記載なし |
| ドキュメント | 参照リンク、画像表示、表現などを更新 |
したがって、今回の情報を「Azure Database for PostgreSQLの新しい必須機能」や「すぐに対応が必要な破壊的変更」と捉える必要はありません。
一方で、Microsoft FoundryからPostgreSQLのデータを安全に参照したい組織にとっては、公式の構成例と権限設定を確認できる重要なガイドです。
Azure Database for PostgreSQLとMicrosoft FoundryのMCP連携とは
MCPはModel Context Protocolの略称です。AIエージェントが、外部のデータやツールを一定の形式で呼び出すための仕組みとして利用されます。
今回の構成では、Microsoft FoundryのAIエージェントがPostgreSQLへ直接接続するのではなく、Azure Container Apps上のMCPサーバーを経由します。
Microsoft FoundryのAIエージェント
↓ HTTPS／MCP
Azure Container Apps上のMCPサーバー
↓ Microsoft Entra ID認証
Azure Database for PostgreSQL公式構成では、Foundry側のマネージドIDとMCPサーバー側のマネージドIDを分けます。MCPサーバーにPostgreSQLのデータベースユーザーを対応付け、必要なテーブルだけにSELECT権限を付与します。(Microsoft Learn)
MCP連携でできること
主な利用例は次のとおりです。
| 機能 | 利用例 |
|---|---|
| 自然言語によるデータ照会 | 「今月の売上上位10商品を表示して」と質問する |
| スキーマの確認 | 利用可能なテーブルや列をAIエージェントが確認する |
| SQLによる集計 | 顧客数、平均単価、エラー件数などを集計する |
| ベクトル検索 | 埋め込みデータから意味の近い文書や商品を検索する |
| データ分析支援 | 集計結果を文章で要約し、傾向や異常を説明する |
たとえば、問い合わせ履歴をPostgreSQLに保存している場合、利用者がSQLを書かなくても、「過去30日で問い合わせが増えた製品はどれか」と質問できるようになります。
ただし、AIエージェントの回答が正しいとは限りません。重要な意思決定や更新処理へ利用する場合は、生成されたSQL、集計条件、対象期間を確認する運用が必要です。
誰に影響するのか
既存のAzure Database for PostgreSQL利用者全員が影響を受けるわけではありません。影響するのは、Microsoft FoundryとのMCP連携を導入する組織や担当者です。
| 対象者 | 主な影響 |
|---|---|
| 一般利用者 | MCP連携を導入しない限り影響なし |
| データベース管理者 | Entra ID認証、DBプリンシパル、SELECT権限の設定が必要 |
| AI開発者 | MCPサーバーの展開とFoundryエージェントへのツール追加が必要 |
| Azure管理者 | Container Apps、マネージドID、ロール割り当ての管理が必要 |
| セキュリティ担当者 | 公開範囲、データ権限、ログ、行レベルセキュリティの確認が必要 |
| コスト管理者 | Container Appsや生成AIモデルの追加費用を確認する必要あり |
現在の業務アプリケーションがPostgreSQLへ接続する方法や、データベースのスキーマを変更する必要はありません。MCP連携は、既存環境へ追加する別経路として構築します。
導入前に確認すべき条件
公式手順を進める前に、次の項目を確認します。
| 確認項目 | 判断基準 |
|---|---|
| PostgreSQL | Azure Database for PostgreSQL Flexible Serverを利用している |
| 認証 | Microsoft Entra ID認証を有効化できる |
| Foundry | 利用可能なMicrosoft Foundryプロジェクトがある |
| Azure権限 | Container Appsやロール割り当てを作成できる |
| Entra権限 | アプリ登録や必要な権限設定が可能 |
| 開発環境 | Azure CLI、Azure Developer CLI、.NETを利用できる |
| ネットワーク | MCPサーバーからPostgreSQLへ到達できる |
| データ分類 | AIエージェントへ公開してよいデータを特定している |
特に重要なのがネットワークです。公式サンプルはAzure Container Appsへ外部HTTPSエンドポイントを作成する構成です。PostgreSQLをプライベートアクセスだけで運用している場合は、Container AppsのVNet統合、名前解決、ルート、ファイアウォールを別途設計する必要があります。(GitHub)
MCP連携の設定手順
公式サンプルを使ってMCPサーバーを展開する
公式ガイドでは、Azure Developer CLIのazdを使用して必要なリソースを展開します。
git clone https://github.com/Azure-Samples/azure-postgres-mcp-demo.git
cd azure-postgres-mcp-demo
az login
azd auth login
azd env new
azd up展開前にサンプルのパラメータファイルを開き、少なくとも次のリソースIDを自分の環境に合わせて変更します。
postgresResourceIdaifProjectResourceId
展開後は、次のコマンドで接続設定に必要な値を確認できます。
azd env get-values主に使用するのは、Container AppsのURLとEntraアプリケーションのクライアントIDです。
この展開により、MCPサーバー用のContainer App、マネージドID、Entraアプリケーション、Azureロール割り当てなどが作成されます。MCPサーバーのマネージドIDには、PostgreSQLリソースに対するAzure RBACのReaderロールが割り当てられます。(Microsoft Learn)
PostgreSQLにマネージドIDを登録する
MCPサーバーのマネージドIDを、PostgreSQLのプリンシパルとして登録します。
この処理は、最初に既定のpostgresデータベースへ接続して実行します。
SELECT *
FROM pgaadauth_create_principal(
'<CONTAINER_APP_IDENTITY_NAME>',
false,
false
);Azure RBACのReaderロールだけでは、PostgreSQL内のテーブルを読み取れません。Azureリソースに対する権限と、データベース内部の権限は別々に設定する必要があります。
必要なテーブルだけにSELECT権限を付与する
対象データベースへ接続し、現在存在するテーブルへの読み取り権限を付与します。
GRANT SELECT ON ALL TABLES IN SCHEMA public
TO "<CONTAINER_APP_IDENTITY_NAME>";今後作成されるテーブルにも自動的に権限を付ける場合は、デフォルト権限を設定します。
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES
TO "<CONTAINER_APP_IDENTITY_NAME>";ALTER DEFAULT PRIVILEGESは、設定を実行したロールが今後作成するオブジェクトに適用されます。別のアプリケーション所有者がテーブルを作成する場合は、対象ロールを明示します。
ALTER DEFAULT PRIVILEGES
FOR ROLE app_owner
IN SCHEMA app
GRANT SELECT ON TABLES
TO "<CONTAINER_APP_IDENTITY_NAME>";独自スキーマを使用している場合は、テーブルのSELECT権限に加えて、スキーマのUSAGE権限も確認します。
GRANT USAGE ON SCHEMA app
TO "<CONTAINER_APP_IDENTITY_NAME>";
GRANT SELECT ON ALL TABLES IN SCHEMA app
TO "<CONTAINER_APP_IDENTITY_NAME>";デフォルト権限は既存テーブルには適用されないため、GRANT SELECT ON ALL TABLESと併用するのがポイントです。(PostgreSQL)
Microsoft FoundryへMCPツールを追加する
公式手順では、FoundryのエージェントへAzure Database for PostgreSQLのツールを追加します。
- Microsoft Foundryで対象プロジェクトを開く
- AIエージェントを作成する
- ツールの追加画面からカタログを開く
- Azure Database for PostgreSQLを選択する
- MCPサーバーのContainer App URLを指定する
- 認証方法にプロジェクトのマネージドIDを指定する
- EntraアプリケーションのクライアントIDを設定する
- エージェントへ利用対象のリソースグループやデータベースを指示する
エージェントの指示へ記載するリソースグループは、MCPサーバーではなくAzure Database for PostgreSQLが存在するリソースグループです。別のリソースグループへMCPサーバーを展開した場合に間違えやすいため注意してください。(Microsoft Learn)
セキュリティ上の注意点
MCP連携では、AIエージェントが自然言語からSQLを組み立てます。プロンプトに「このテーブルだけを使う」と書くだけでは、十分なアクセス制御になりません。
実際のセキュリティ境界は、PostgreSQLの権限、マネージドID、ネットワーク設定です。
専用ビューまたは専用スキーマを用意する
本番データベースの全テーブルへ一括でSELECT権限を付けるより、AIエージェント用のビューを作成する方が安全です。
たとえば顧客テーブルに氏名、メールアドレス、住所、売上区分が含まれていて、分析に必要なのが売上区分だけであれば、必要な列だけを含むビューを公開します。
CREATE VIEW ai_sales_summary AS
SELECT
sales_month,
product_category,
sales_amount
FROM sales_summary;MCPサーバーには、このビューだけを参照できる権限を与えます。
行レベルセキュリティも検討する
部署やテナントごとに閲覧可能な行を分ける必要がある場合は、PostgreSQLのRow-Level Securityを利用します。
ただし、RLSを設定しただけで安全になるわけではありません。MCPサーバーがどのロールとして接続するか、ビューの所有者権限がどのように適用されるかまでテストしてください。
公式ガイドでも、最小権限、専用データベースまたはスキーマ、RLS、機密性の低いデータを使った事前検証が推奨されています。(Microsoft Learn)
サンプル設定をそのまま本番利用しない
公式サンプルは、短時間で動作を確認するための参照実装です。2026年6月時点のサンプルには、次のような本番前に見直したい設定があります。
| 項目 | 確認すべき点 |
|---|---|
| コンテナイメージ | latestではなく、検証済みバージョンやダイジェストへの固定を検討する |
| 最小レプリカ数 | サンプルは1のため、未使用時にもアイドル料金が発生し得る |
| 外部Ingress | 接続元を制限し、必要に応じてプライベート化する |
| エージェント承認 | SDK例の自動承認設定を本番へそのまま適用しない |
| データ権限 | 全テーブルではなく、必要なビューやスキーマに限定する |
| ログ | クエリ内容に個人情報や機密情報を残さない |
公式サンプルでは、Container Appの最小レプリカ数が1、最大レプリカ数が3に設定されています。また、コンテナイメージにはlatestタグが指定されています。(GitHub)
料金はどこを確認すべきか
当該記事には、MCP連携そのものに対する専用の定額料金は記載されていません。一方で、構成する各Azureサービスの利用料は発生します。
| 費用項目 | 主な課金要因 |
|---|---|
| Azure Database for PostgreSQL | コンピューティング、ストレージ、バックアップ |
| Azure Container Apps | vCPU、メモリ、リクエスト、稼働時間 |
| Microsoft Foundry | 使用するモデル、トークン、接続ツール |
| Azure Monitor | Log Analyticsへのログ取り込み、保持期間 |
| ネットワーク | データ転送、Private Endpointなどの構成 |
Azure Container Appsは、割り当てたCPUとメモリ、リクエストなどに応じて課金されます。スケールをゼロにできる構成では未使用時のリソース料金を抑えられますが、公式サンプルは最小レプリカ数が1であるため、リクエストがない時間帯にもアイドル料金が発生する可能性があります。(Microsoft Azure)
Azure Database for PostgreSQLは、コンピューティング、プロビジョニング済みストレージ、使用したバックアップストレージなどが課金対象です。既存サーバーを使用する場合でも、MCP経由のクエリが増えることでCPUやIO負荷が上がり、上位構成への変更が必要になる可能性があります。(Microsoft Azure)
Microsoft Foundryの現行価格情報では、Foundryネイティブのエージェントを作成・実行すること自体に追加料金が発生しないケースでも、利用するAIモデルのトークンや外部ツール、関連サービスは個別に課金されます。導入前に、想定質問数、1回あたりのモデル使用量、Container Appsの常時稼働費用を試算してください。(aka.ms)
移行や更新作業は必要か
既存のAzure Database for PostgreSQL環境に対する必須移行はありません。
今回の公式情報に、次のような期限は記載されていません。
- MCP連携への移行期限
- 既存接続方式の廃止日
- PostgreSQLバージョンの強制更新日
- 既存アプリケーションの変更期限
すでに独自のMCPサーバーを運用している場合も、2026年6月12日のドキュメント更新だけを理由に再展開する必要はありません。ただし、公式サンプルとの差分として、マネージドID、最小権限、コンテナイメージ、ネットワーク、ログ設定を確認する価値はあります。
よくある失敗と確認方法
AzureのReaderロールだけで接続できると思ってしまう
Azure RBACのReaderは、PostgreSQLサーバーというAzureリソースを参照するための権限です。テーブルのデータを読み取る権限ではありません。
次の両方が必要です。
Azure側：マネージドIDへのロール割り当て
DB側：Entraプリンシパル作成とSELECT権限新しく作成したテーブルだけ参照できない
既存テーブルへGRANT SELECT ON ALL TABLESを実行しても、将来作成するテーブルには自動適用されません。
ALTER DEFAULT PRIVILEGESを追加し、実際にテーブルを作成する所有者ロールを正しく指定してください。
FoundryからMCPサーバーへ接続できない
次の順番で確認すると原因を切り分けやすくなります。
- Container Appが起動しているか
- MCPエンドポイントへHTTPSで到達できるか
- FoundryプロジェクトのマネージドIDが有効か
- EntraアプリケーションのクライアントIDが正しいか
- 必要なアプリケーションロールが割り当てられているか
- Container Appsのログに認証エラーが記録されていないか
PostgreSQLへの接続だけ失敗する
次の項目を確認します。
- PostgreSQLでEntra ID認証が有効か
- MCPサーバーのマネージドIDをプリンシパルとして登録したか
- プリンシパル名が同一テナント内で重複していないか
- PostgreSQLのファイアウォールやプライベートDNSが正しいか
- 対象データベースとスキーマへ権限を付与したか
公式ガイドでは、マネージドID名の重複、認証、ネットワーク、データベース権限、Container Appsのログが主な確認項目として案内されています。(Microsoft Learn)
導入判断と次に行うこと
今回の更新に対して、Azure Database for PostgreSQL利用者が緊急で行う作業はありません。MCP連携を利用しない場合は、既存環境をそのまま運用できます。
導入する場合は、次の順序で進めるのが安全です。
- AIエージェントへ公開する質問とデータを決める
- 機密性の低いテストデータで公式サンプルを展開する
- 専用ビューまたは専用スキーマへSELECT権限を限定する
- ネットワーク、マネージドID、ログを確認する
- Container Appsとモデル利用量の実測値から月額費用を試算する
- 誤ったSQLや想定外のデータ参照がないことを確認して本番へ移行する
特に、プロンプトだけでアクセス範囲を制御しないことが重要です。PostgreSQLの権限を最小化し、AIエージェントが参照できるデータをデータベース側で明確に制限したうえで導入してください。
コメント