Azure Functions が MCP リソース トリガーをサポートするようになり、Azure Functions 上の MCP サーバーは、これまでの「ツールを呼び出せる」だけでなく、「参照用リソースを公開できる」基盤になりました。2026年4月7日に公開・更新された Microsoft の案内では、静的・動的ファイル、アプリケーション メタデータ、HTML ベースの MCP App UI まで Azure Functions から直接公開できると説明されています。つまり今回の更新の本質は、エージェント ワークフローに操作だけでなく文脈と UIを足せるようになったことです。 (Microsoft)
この記事では、Azure Functions の MCP リソース トリガーで何が変わるのか、既存のツール トリガーと何が違うのか、どんなユースケースで効くのか、導入時にどこでつまずきやすいのかを、実務目線で整理します。Azure Functions MCP 拡張機能は MCP Apps もサポートしており、ツール トリガーとリソース トリガーを組み合わせることで、プレーンテキストではなく対話型 UI を返せます。 (Microsoft Learn)
Azure Functions の MCP リソース トリガー対応で何が変わったか
今回の発表は「Azure Functions に新しいバインドが 1 つ増えた」で終わる話ではありません。Azure Updates の掲載内容では、Azure Functions 上でホストした MCP サーバーからリソースを直接公開できるようになり、ツールに加えて、より豊かな文脈、対話的な体験、構造化データを提供できるとされています。発表文では、この機能は Python、TypeScript、.NET、Java 向けの Azure Functions MCP 拡張機能で利用できると案内されています。なお、掲載日は 2026年4月7日で、リリースコミュニケーションでは General Availability の可用性欄が 2026年3月になっています。 (Microsoft)
編集者目線で言い換えると、Azure Functions が「エージェントに何かを実行させる場所」から、「エージェントに何を読ませ、どう見せるかまで設計できる場所」に広がった、という理解がいちばんしっくりきます。リソース トリガーは、ツール トリガーを置き換える機能ではなく、ツールだけでは表現しづらかった文脈や UI を補う機能です。 (Microsoft)
ツール トリガーとの違いを先に整理する
| 観点 | MCP ツール トリガー | MCP リソース トリガー |
|---|---|---|
| 主な役割 | クライアントからの呼び出しで処理を実行する | クライアントが読むための情報や UI を公開する |
| 典型例 | 保存、検索、API 実行、業務操作 | README、API 仕様、DB スキーマ、HTML ウィジェット |
| クライアント側の使い方 | 「実行する」ために呼ぶ | 「参照する」「表示する」ために読む |
| 返すもの | 実行結果 | テキストまたはバイナリのリソース |
要するに、ツールが「何かをさせる」窓口なら、リソースは「何を読むか、何を見せるか」の窓口です。公式ドキュメントでも、ツール トリガーは特定タスクの実行、リソース トリガーはファイル内容・データベース スキーマ・API ドキュメントなどの参照情報の公開として説明されています。 (Microsoft Learn)
MCP リソース トリガーがエージェント ワークフローに追加するもの
文脈をツールの返り値から切り離せる
一番大きい変化は、エージェントに渡す文脈を、ツールの返り値とは別の正式なチャネルで公開できることです。公式ドキュメントでは、リソースとしてファイル内容、データベース スキーマ、API ドキュメントなどを扱えるとされ、リリース文では静的・動的ファイルやアプリケーション メタデータも例に挙げられています。社内向けエージェントで考えると、API 利用ガイド、権限ルール、運用手順書、画面仕様の断片などをリソースとして切り出しやすくなります。 (Microsoft Learn)
この分離は地味ですが効きます。今までは「まず説明を読ませたい情報」までツールの応答に詰め込みがちでしたが、リソース トリガーがあると、アクション実行と文脈供給の責務を分けやすくなります。リリース文がいう「ツールに加えて構造化データを提供できる」という表現は、まさにこの整理と相性が良いです。 (Microsoft)
MCP Apps の UI を Azure Functions から返せる
実務インパクトが大きいのは、MCP Apps を作りやすくなる点です。公式例では ui://weather/index.html のような UI リソースを公開し、ツール側のメタデータで resourceUri を指すと、MCP ホストがそのリソースを取得して描画します。Azure Functions MCP 拡張機能の MCP Apps は、そもそもテキストではなくリッチで対話型の UI を返すサーバーとして案内されています。 (Microsoft Learn)
これは、エージェントの出力を「文章だけ」で終わらせたくない場面で効きます。たとえば、一覧表、ステータス パネル、確認用の簡易ウィジェット、承認前のプレビューなどを、ツール実行に連動して見せる構成が取りやすくなります。特に、Azure Functions をすでに使っているチームなら、別サービスを増やさずに UI 付きの MCP 体験を試せるのが魅力です。 (Microsoft Learn)
リソースの発見と再利用がしやすくなる
リソースは関数アプリ起動時に MCP サーバーへ登録され、クライアントは resources/list で URI、名前、説明、MIME タイプ、サイズ、メタデータを確認し、resources/read で必要なものを読みます。返り値はテキストだけでなくバイナリも扱えるため、設計次第でより幅広い情報をリソース化できます。 (Microsoft Learn)
この仕様の良さは、「使える情報源が何か」をクライアントが機械的に見つけやすいことです。ツール説明の長文化でなんとかするより、公開する情報を URI ベースのリソースとして整理したほうが、後から増えたときも破綻しにくくなります。 (Microsoft Learn)
セッションごとの出し分けを組み込みやすい
ResourceInvocationContext には URI、SessionId、Transport の情報が入り、公式ドキュメントも SessionId を使ってセッション別の状態管理やロジック適用ができると説明しています。つまり、同じ「ダッシュボード」リソースでも、利用者や操作中の流れに応じて返す内容を変える設計がしやすい、ということです。後半は実装上の推論ですが、セッション ID をリソース処理に渡せる点は、エージェント ワークフローにとってかなり扱いやすい土台です。 (Microsoft Learn)
どんなチームが早めに試すべきか
早めに試す価値が高いケース
- すでに Azure Functions で MCP ツールを公開していて、仕様書や補足情報をツール応答に詰め込みたくない。
- テキストだけの応答ではなく、MCP Apps として UI 付きの結果を返したい。
- Azure Functions ベースの実装のまま、エージェント向けの文脈供給まで広げたい。
優先度がそこまで高くないケース
- 現在の用途が単純なツール実行だけで完結し、追加の参照情報や UI が不要。
- すでに公式 MCP SDK でサーバーを作っていて、まずは Azure Functions 上でそのままホストしたい。公式チュートリアルでは、この系統はセルフホステッド サーバーとして別ルートで案内され、現時点ではプレビューです。 (Microsoft)
判断のコツはシンプルです。操作の自動化を増やしたいならツール トリガー中心、文脈や UIを増やしたいならリソース トリガーを組み合わせる、という考え方でほぼ迷いません。 (Microsoft Learn)
導入の最短手順
- 前提条件を先に確認する
Azure Functions MCP 拡張機能を前提に進めます。公式ドキュメントでは、PowerShell アプリは現時点で未対応、C# は分離ワーカー モデルのみ対応です。記事執筆時点の公式ドキュメントでは、ローカル実行に Azure Functions Core Tools 4.0.7030 以降が必要で、言語ごとの最低パッケージ バージョンも定義されています。 (Microsoft Learn) - 最初の 1 リソースを決める
いきなり大量のリソースを増やすより、README、API 仕様、DB スキーマ、あるいは簡単な HTML 断片など、まず 1 つに絞るのが無難です。実装時は URI、resourceName、description、MIME タイプ、メタデータをきちんと設計します。 (Microsoft Learn) - UI が必要ならツールから
resourceUriを参照する
ただの参照情報ならリソース単体で十分ですが、ツール実行結果と一緒に UI を出したいなら、ツール側メタデータからリソースを指す構成が有効です。公式例もこの組み合わせを前提にしています。 (Microsoft Learn) - 接続は Streamable HTTP を第一候補にする
Azure Functions MCP 拡張機能の接続エンドポイントは Streamable HTTP が/runtime/webhooks/mcp、SSE が/runtime/webhooks/mcp/sseです。公式ドキュメントでは、新しいプロトコル バージョンで SSE は非推奨方向とされているため、クライアント要件がない限り Streamable HTTP から始めるほうが安全です。Azure 上では既定でmcp_extensionシステム キーが必要になり、VS Code の GitHub Copilot 向けmcp.json例も公式ドキュメントにあります。必要に応じてhost.jsonの認証レベルや組み込み認証も併せて検討します。 (Microsoft Learn) - 公式クイックスタートで最短検証する
Microsoft Learn には、Azure Functions でカスタム リモート MCP サーバーを作るクイックスタートと、MCP Apps を作るクイックスタートが用意されています。新規検証なら、これらのテンプレートから入るのがいちばん速いです。 (Microsoft Learn)
実装前に見落としやすい注意点
- SSE を前提に設計しない
新しいプロトコル バージョンでは SSE が非推奨方向です。加えて、SSE を使う場合はAzureWebJobsStorageの Queue 依存と権限も絡むため、特別な事情がなければ Streamable HTTP を選ぶほうが無難です。 (Microsoft Learn) - Azure 上で 401 が出たら、まずキー設定を疑う
リモート エンドポイントは既定でmcp_extensionシステム キーが必要です。x-functions-keyヘッダーまたはcodeクエリ パラメーターを付けないと 401 になります。 (Microsoft Learn) resourceNameだけで満足しない
クライアントはresources/listの URI、説明、MIME タイプ、メタデータを見て使い方を判断します。名前だけ整えても、見つけやすさや表示品質は上がりません。特に UI 系は MIME タイプとメタデータが雑だと価値が出にくいです。 (Microsoft Learn)- 言語制約を後回しにしない
C# の分離ワーカー制約、PowerShell 未対応は、設計の後半で気づくと戻りが大きいポイントです。既存の関数アプリに足す場合ほど、最初に確認しておくべきです。 (Microsoft Learn)
次にやるべきこと
最初の一歩としておすすめなのは、既存の MCP ツール 1 本に対して、README・API 仕様・簡単な HTML ウィジェットのどれか 1 つをリソースとして足すことです。これだけで、Azure Functions の MCP リソース トリガー対応が持つ価値、つまり「操作だけのサーバー」から「操作 + 文脈 + UI のサーバー」への変化を体感できます。新規で始めるなら、公式クイックスタートでローカル環境を作り、resources/list にリソースが載ること、必要ならクライアント側で表示できることまで確認すれば十分です。 (Microsoft)
コメント