Azure AI Foundry エージェントを社内APIや独自業務ロジックにつなぎたいなら、今回の発表はかなり実務的です。Microsoft は 2026年4月8日、Azure Functions でホストしたカスタム MCP サーバーを Foundry エージェントに接続する方法を Azure SDK Blog で公開しました。結論から言うと、既存の MCP ツールを作り直さずに Azure AI Foundry エージェントへ持ち込めるのが今回のポイントです。Azure Functions 側はスケーラブルなホスティング、組み込み認証、サーバーレス課金を使え、Foundry 側は MCP ツールとしてそのまま接続できます。(Microsoft for Developers)
この記事では、Azure AI Foundry エージェントと Azure Functions をどう組み合わせればよいか、どの認証方式を選ぶべきか、実装時にハマりやすい設定ミスまでを、実務目線で整理します。先に要点だけ言うと、共有権限で使う業務ツールなら Microsoft Entra、ユーザーごとの権限を残したいなら OAuth identity passthrough、まず疎通確認をしたい段階なら Key-based が考えやすい選択です。(Microsoft Learn)
Azure AI Foundry エージェントで今回できるようになったこと
今回の発表で重要なのは、Azure Functions 上のリモート MCP サーバーを、Foundry エージェントの「別の利用者」として接続できるようになったことです。つまり、VS Code や Visual Studio、Cursor などで使っている既存の MCP サーバーがあれば、それをエージェント向けに作り直す必要はありません。Foundry プロジェクト、モデル、エージェントが用意できていれば、同じツール群を Azure AI Foundry 側でも再利用できます。(Microsoft for Developers)
MCP は、AI エージェントが外部ツールやデータソースとやり取りするためのオープン標準です。Azure Functions をホスト先にすると、MCP サーバーがリモートエンドポイントとして動き、エージェントはそのエンドポイントに接続してツールを検出・呼び出します。必要に応じて Azure API Center に登録し、組織のツールカタログとして共有することもできます。(Microsoft Learn)
Azure AI Foundry エージェントと Azure Functions の接続イメージ
構成はシンプルです。Azure Functions 側に MCP サーバーを置き、Foundry エージェントがそのエンドポイントへ接続し、Function 側で内部 API やデータベース、既存システムを呼び出して結果を返します。ポイントは、エージェント本体と業務ロジックを分離できることです。ツールを個別に開発、テスト、デプロイしやすくなり、複数のエージェントやアプリで同じツールを再利用しやすくなります。(Microsoft Learn)
新規構築なら MCP 拡張サーバー
Azure Functions で新しく作るなら、Azure Functions MCP 拡張機能を使う方法が第一候補です。Functions の仕組みに沿ってツールやリソースを公開でき、Functions 言語で実装しやすいのが強みです。注意点として、MCP 拡張機能は PowerShell アプリをサポートせず、C# は分離ワーカーモデルのみがサポート対象です。(Microsoft Learn)
既存実装を持ち込むならセルフホスト
すでに標準 MCP SDK で作ったサーバーがあるなら、Azure Functions 上でセルフホストする選択肢もあります。既存の MCP 実装をそのまま生かしやすい一方で、公式ドキュメントではこのホスティング方式は現時点でプレビューです。新規構築なら拡張機能、既存資産の移行ならセルフホスト、と考えると判断しやすいです。(Microsoft Learn)
Azure AI Foundry エージェントで Azure Functions + MCP を選ぶべきケース
公式ドキュメントを実務向けに言い換えると、Azure Functions + MCP が効くのは次のようなケースです。(Microsoft Learn)
- 複数のエージェントやアプリで同じ業務ツールを使い回したい
- エージェント本体と業務ロジックを分離したい
- 特定ランタイム、外部ライブラリ、レガシーシステム連携を使いたい
- 多段のデータ変換や重めの処理をエージェント外に逃がしたい
- 同期応答は MCP、長時間処理は別の Azure Functions ワークフローへ切り分けたい
逆に、単純でステートレスな処理ならエージェント内の関数呼び出しでも十分です。一方、リアルタイム性が低く、長時間実行や再試行が前提の処理なら、キュー ストレージ ベースの Azure Functions ツールのほうが自然です。公式の比較でも、MCP サーバーは同期的な即時応答向け、キュー型は非同期ワークフロー向けと整理されています。(Microsoft Learn)
Azure AI Foundry エージェントに接続する認証方式の選び方
認証方式は「誰の権限でツールを呼ぶか」を先に決めると迷いません。(Microsoft Learn)
Key-based を選ぶ場面
Key-based は、Functions の HTTP エンドポイントで既定の認証方式です。まず接続が通るか確認したい検証段階や、Microsoft Entra を使わないサーバーには向いています。ただし、本番での運用は Entra や OAuth より弱くなりやすいので、長期運用前提なら早めに見直したほうが安全です。(Microsoft Learn)
Microsoft Entra を選ぶ場面
共有された権限で社内ツールを呼ぶなら、Microsoft Entra が本命です。Azure Functions を使った接続ガイドでは、Functions 側の Entra 認証は現時点で Project Managed Identity がサポート対象です。たとえば「全員が同じ権限で問い合わせる在庫照会」「共通のサービス権限で読む社内DB参照」などに向いています。(Microsoft Learn)
OAuth identity passthrough を選ぶ場面
ユーザーごとの権限やコンテキストをそのまま残したいなら、OAuth identity passthrough です。初回利用時には Foundry が同意リンクを出し、ユーザーがサインインと同意を完了すると、そのユーザー資格情報でツールを呼び出せます。各ユーザーの予定表、個人CRMレコード、担当者ごとに見える情報が違う業務ツールなどは、この方式が合います。なお、少なくともプロジェクトの Azure AI User ロールが必要で、ユーザーの Entra テナントは Foundry プロジェクトと同一である必要があります。(Microsoft Learn)
Unauthenticated を選んでよい場面
認証なしは、公開情報だけを返す読み取り専用ツールか、閉じた開発環境での一時的な検証に限るのが無難です。公式ドキュメントでも、誰でも到達できる状態になるため、本番での利用はかなり慎重に扱うべきだとされています。(Microsoft Learn)
Azure AI Foundry エージェントへ Azure Functions のMCPツールをつなぐ手順
- まず、Azure Functions 上に MCP サーバーを用意します。既存のサーバーがあるならそれを使えばよく、ゼロから始めるなら Microsoft は Python、TypeScript、.NET、Java のサンプルを案内しています。少なくとも Python、.NET、Java の Learn サンプルでは、ローカル実行から
azd upによる Azure 展開まで説明されています。(Microsoft for Developers) - 次に、MCP エンドポイント URL を確認します。MCP 拡張サーバーなら既定のエンドポイントは
https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp、セルフホストなら既定でhttps://<FUNCTION_APP_NAME>.azurewebsites.net/mcpです。ここを取り違えると、接続はほぼ確実に失敗します。(Microsoft Learn) - Key-based 以外の認証に切り替えるなら、Functions 側の既定キー認証を外します。MCP 拡張サーバーとセルフホストで設定名が違うので注意してください。Key-based のまま使うなら、この変更は不要です。(Microsoft Learn)
# MCP 拡張サーバー
AzureFunctionsJobHost__extensions__mcp__system__webhookAuthorizationLevel=Anonymous
# セルフホスト サーバー
AzureFunctionsJobHost__customHandler__http__DefaultAuthorizationLevel=anonymous- 認証方式に応じて資格情報を集めます。Key-based なら、MCP 拡張サーバーは
mcp_extensionの system key、セルフホストはdefaultの host key を使います。Microsoft Entra を使うなら、Function App のユーザー割り当てマネージド ID を Foundry プロジェクトに接続し、その Client ID を Function App 側の許可されたクライアント アプリケーションへ追加し、さらに Entra アプリ登録の Application ID URI を控えます。OAuth identity passthrough を使うなら、Client ID、Client secret、Auth URL、Token URL、Refresh URL、Scopes を揃えます。(Microsoft Learn) - Foundry ポータルでエージェントを開き、Build タブから対象エージェントを選び、Playground の Tools から Add を選択します。続いて Custom から Model Context Protocol (MCP) を作成し、エンドポイントと認証情報を入力して Connect、最後に Save です。OAuth identity passthrough の場合は、接続作成後に表示される Redirect URL を Entra アプリ登録へ戻って追加する作業も必要です。(Microsoft Learn)
- 保存できたら、Agent Builder やテストチャットで、MCP ツールが必要になるプロンプトを投げて動作確認します。失敗した場合は Foundry 側だけでなく、Azure Portal で Function App のログも見て、エンドポイント到達と内部API呼び出しのどこで落ちているかを切り分けるのが早道です。(Microsoft for Developers)
運用で差がつく設計ポイント
ツールは全部見せない
MCP サーバーをつないだら、まず allowed_tools で許可リストを作る発想を持つべきです。特に社内向けサーバーは、便利だからといって全ツールをそのまま公開すると、エージェントの権限が広がりすぎます。Foundry のベストプラクティスでも、allowed_tools を優先し、必要なツールだけに絞ることが推奨されています。(Microsoft Learn)
書き込み系ツールは承認を残す
require_approval の既定値は always です。読み取り専用なら緩めてもよいですが、更新、削除、申請送信のような書き込み系は、承認前提で運用したほうが安全です。SDK や REST で実装する場合、承認が必要な呼び出しは mcp_approval_request として返るので、ツール名や引数を確認したうえで mcp_approval_response を返す流れになります。(Microsoft Learn)
認証情報はプロジェクト接続に寄せる
Foundry Agent Service では、API キーやベアラー トークンなどの認証情報をプロジェクト接続へ保存できます。SDK や REST で認証付き MCP サーバーを使うなら project_connection_id を持たせ、認証不要のサーバーだけ省略するのが基本です。シークレットをコードへ直書きしない、という原則も合わせて守ったほうが安全です。(Microsoft Learn)
MCP 用トークンをそのまま下流サービスへ流さない
App Service Authentication の公式ガイドでは、MCP サーバー認証用のトークンを、そのまま下流の API や別サービスへ転送する設計は避けるように注意しています。下流呼び出しが必要なら、オンビハーフオブ フローや明示的な委任で別トークンを取得する設計にしたほうが安全です。(Microsoft Learn)
組織全体で再利用するなら Azure API Center も有効
複数チームで同じ MCP サーバーを使うなら、Azure API Center に登録して組織のツールカタログ化しておくと、発見性とガバナンスが上がります。登録は必須ではありませんが、社内標準ツールとして配布したいときにはかなり相性が良い選択です。(Microsoft Learn)
失敗しやすいポイント
- MCP 拡張サーバーの
/runtime/webhooks/mcpと、セルフホストの/mcpを取り違える。URL が合っていても、パスが違うだけで接続に失敗します。(Microsoft Learn) - Entra や OAuth に切り替えたのに、Functions 側の既定キー認証を残したままにする。401/403 の原因になりやすい典型例です。(Microsoft Learn)
- OAuth identity passthrough で Redirect URL を Entra アプリ登録へ戻し忘れる。さらに、同一テナント条件や Azure AI User ロール要件を見落とすと、動いたり動かなかったりする状態になりがちです。(Microsoft Learn)
- MCP サーバー用の Entra アプリ登録を、別のアプリケーション部品と使い回す。公式ガイドは、MCP サーバー用に固有の登録を使うよう案内しています。(Microsoft Learn)
allowed_toolsに指定したツール名が、実際にサーバーが公開している名前と一致していない。接続自体は成功しても、期待したツールが呼ばれません。(Microsoft Learn)- Foundry 側の設定だけを見て終わる。問題が起きたら Function App のログまで見に行き、到達性、認証、下流API権限のどこで落ちたかを切り分けるほうが早いです。(Microsoft Learn)
次にやること
最短で成果を出すなら、まずは読み取り専用のツールを 1 本だけ Azure Functions に載せ、Azure AI Foundry エージェントへ接続して疎通確認するのが安全です。共有権限で十分なら Project Managed Identity、検証だけなら Key-based で始め、そのあと allowed_tools で公開範囲を絞り、書き込み系ツールだけ承認を残します。ユーザーごとの権限が必要になった段階で OAuth identity passthrough へ進む順番にすると、手戻りが少なくなります。(Microsoft Learn)
コメント