AzureがMCPアプリ向けFluent APIを導入　Azure Functionsで開発障壁が下がる理由

Azure の MCP アプリを C# と Azure Functions で作るとき、面倒なのは UI そのものよりも「MCP のお作法」です。2026年4月7日に Microsoft が Azure SDK Blog で紹介した MCP アプリ向け Fluent API は、既存の MCP ツールを AsMcpApp で app 化し、WithView WithPermissions WithCsp などで UI とセキュリティ設定を宣言的に足せるようにする更新です。結果として ui:// リソースや UI 用 metadata の配線を自前で抱える必要が減り、Azure 上の MCP アプリ開発は以前より入りやすくなりました。

ただし、ここでいう Fluent API は Azure Functions 向けの Microsoft.Azure.Functions.Worker.Extensions.Mcp に追加された preview 機能で、対象は C# の isolated worker です。つまり「Azure の MCP アプリ全体に一律で効く新標準」ではなく、「Azure Functions ベースの .NET MCP ツールを UI 付きの MCP App に広げやすくする機能」と理解するとズレません。

Azure の MCP アプリ向け Fluent API とは何か

MCP は Model Context Protocol の略で、MCP Apps はテキストだけではなく対話的な UI を返せる MCP サーバーを指します。Azure Functions の MCP extension は tool trigger と resource trigger を組み合わせてその仕組みを提供しており、今回の Fluent API はその app 構成部分を fluent に書きやすくしたものです。

重要なのは、「MCP Apps を新しく作れるようになった」よりも「MCP 仕様の暗黙知を毎回追わなくてよくなった」点です。公式ブログでも、Fluent API の目的は MCP spec の詳細を抽象化し、開発者がプロトコルの細部を知らなくても app を構築しやすくすることだと説明されています。

なぜ開発の障壁が下がるのか

つまずきやすい壁	Fluent API でどう変わるか	実務での意味
`ui://` リソース、専用 MIME type、UI 用 metadata の整合を手で合わせる必要がある	`AsMcpApp()` が app 用 resource と metadata 配線を自動化する	「ツールは動くのに UI が出ない」実装ミスを減らしやすい
既存ツールを UI 付きアプリに広げると構成が散らかりやすい	`ConfigureMcpTool()` で既存 tool を選び、app 設定だけ足せる	小さく試してから段階的に広げやすい
権限や CSP の設計が後回しになりやすい	`WithPermissions()` と `WithCsp()` に集約できる	セキュリティレビューを早い段階で回しやすい
HTML / CSS / JS / 画像の配置や配信が面倒	`WithView()`、埋め込み resource、`WithStaticAssets()` が使える	デプロイ形態に合わせやすい
UI だけの tool までモデルに見せてしまう	`WithVisibility()` で Model / App の露出を制御できる	不要な tool 露出を抑えやすい

※表は、Microsoft の公式ブログで説明された Fluent API の自動配線と、Learn にある従来の resource trigger 実装例をもとに整理しています。

本質は、コードが少し短くなることではありません。ui://、text/html;profile=mcp-app、_meta.ui のような「知らないと作れない暗黙知」が API に吸収され、AsMcpApp という意図の分かる形で表に出てきたことが大きいのです。これは初学者に優しいだけでなく、レビュー担当者にとっても「何を app 化し、どんな権限を与えているか」が読み取りやすくなる効果があります。

従来より何が簡単になったのか

従来の Azure Functions ベースの MCP App では、UI 側に ui://... の resource endpoint を定義し、text/html;profile=mcp-app を返し、さらに UI 表示用 metadata を付ける必要がありました。tool 側にも app 用 metadata が必要で、この整合がずれると「関数は動くのに UI が出ない」状態になりやすい構造でした。Fluent API は resource の自動生成、正しい MIME type の設定、tool と view を結ぶ metadata 注入までまとめて扱います。

実装イメージは、次のようにかなり素直です。

builder.ConfigureMcpTool("ReportViewer")
    .AsMcpApp(app => app
        .WithView("assets/report.html")
        .WithTitle("売上レポート")
        .WithPermissions(McpAppPermissions.ClipboardRead)
        .WithCsp(csp => csp.ConnectTo("https://api.contoso.com")));

この構成なら既存の tool に app 用の view とセキュリティ設定を足していけばよく、ConfigureMcpTool() に渡す名前は [McpToolTrigger] で登録した tool 名と一致させます。必要に応じて WithStaticAssets() や WithVisibility() を追加すれば、UI 付きアプリとして段階的に整えていけます。

実装で押さえるべき設定ポイント

View と静的アセット

WithView() は HTML の置き場所を決める設定で、ファイル指定だけでなく McpViewSource.FromEmbeddedResource() にも対応しています。配布物を 1 つの成果物に寄せたい社内ツールでは埋め込み resource が扱いやすく、クライアント UI に見える名称は WithTitle() で調整できます。状態保持が絡むなら WithDomain() で cookie や storage のスコープ hint も指定できます。

publish 後の配置でつまずかないコツ

ファイル指定の view は出力ディレクトリ基準です。ローカルでは見えていた HTML が Azure 上で見つからないときは、publish 出力にそのファイルが入っていないケースが多いので、まずそこを確認するのが近道です。CSS や JS、画像は WithStaticAssets() で配信できますが、.map ファイルは内部パスや実装詳細の漏えいを避けるため既定では除外されます。

権限と CSP

WithPermissions() はクライアント環境で app に許す操作を明示する API です。公開時点の公式ブログではクリップボード読み書きが例示されており、考え方は「必要になったら足す」ではなく「最小権限から始める」です。

外部 API や WebSocket へ接続するなら ConnectTo() を使います。UI は表示されてもデータ取得だけ失敗する場合、この許可漏れが原因になりやすいです。
CDN から画像や JS/CSS を読むなら LoadResourcesFrom() を使います。許可先は広く取りすぎず、必要な origin だけに絞るほうが安全です。
iframe 埋め込みが必要なら AllowFrame()、<base> を使うなら AllowBaseUri() を検討します。

既定の CSP は制限が強めで、WithCsp() は複数回呼び出すと許可 origin が累積します。共通基盤と機能別設定を分けたいチームでは、この設計はかなり扱いやすいポイントです。

visibility で「モデルに見せるか」を決める

WithVisibility() は見落とされやすい設定です。既定では tool は model と app の両方に見えるため、UI を表示するためだけの tool まで LLM に公開したくない場合は McpVisibility.App に寄せたほうが安全です。これは「動くかどうか」より「余計な tool を見せないか」の問題なので、ローカル動作確認の段階では気づきにくいポイントでもあります。

楽になるのは配線であって UI 設計ではない

Fluent API で簡単になるのは、MCP App として成立させるための配線です。HTML の構造、スタイル、クライアント側の振る舞い、業務ロジックそのものは引き続きアプリ側の責任で、そこまで自動化されるわけではありません。公式ブログでも、markup・styling・client-side behavior は引き続き開発者が自由に設計すると説明されています。

Azure Functions Fluent API が向くケース

この Fluent API が特に刺さるのは、すでに Azure Functions で MCP tool を持っているチームです。Microsoft Learn のホスティング比較でも、Azure Functions は各 tool が独立していてステートレス、イベント駆動、従量課金、Foundry Agent Service 連携が必要なケースに向くと整理されています。逆に、任意言語やコンテナ前提なら Container Apps、既存の web アプリに MCP endpoint を足すなら App Service のほうが素直なことがあります。

前提	向きやすい選択
既存の C# / isolated worker の Functions MCP tool を育てたい	Azure Functions + Fluent API
各 tool が独立・ステートレスで、従量課金やイベント駆動と相性がいい	Azure Functions
既存の Web アプリに MCP endpoint を追加したい	App Service
任意言語、コンテナ、マイクロサービス前提で組みたい	Container Apps
Kubernetes の制御を強く求める	AKS

※サービス選択は Learn のホスティングガイドをもとに整理しています。

UI 付きの MCP App は対話的に使われるぶん、体感速度の悪化がそのまま UX に響きます。Learn のガイドでも、インタラクティブなクライアントには cold start を抑えられる Azure Functions Premium プランが推奨されています。

導入時の実践チェックリスト

まずは 1 つの read-only tool から始めます。いきなり全面移行するより、検索結果一覧や社内レポートのように副作用の少ない UI から app 化したほうが検証しやすいです。
開発ブランチで Microsoft.Azure.Functions.Worker.Extensions.Mcp の preview を試し、C# isolated worker が前提になっているかを確認します。
AsMcpApp() で 1 つの tool に WithView() と WithTitle() を付け、まずは最小 UI で表示まで通します。
権限は最小構成、CSP は必要な origin だけで始めます。あとから追加するほうが、原因切り分けもレビューも楽です。
UI 専用の tool は WithVisibility(McpVisibility.App) を検討し、静的アセットは publish 後の配置まで含めて確認します。
認証は Fluent API と別レイヤーで設計します。Azure 上の Functions MCP endpoint は通常 /runtime/webhooks/mcp で、既定では mcp_extension の system key が必要です。Microsoft Entra ID を使う Functions の built-in auth を有効にするなら、webhookAuthorizationLevel を Anonymous にして key ベース認証を外す構成が案内されています。
本番候補のクライアントで応答時間を測ります。対話型クライアントでは cold start の影響が大きいので、必要に応じて Premium プランを前提に評価したほうが判断を誤りにくいです。

失敗しやすいポイント

preview なのに一気に全面移行することです。今回の Fluent API は preview 提供なので、まずは限定導入で API 変更の影響を見たほうが安全です。
WithPermissions() や WithCsp() を設定しただけで endpoint 保護まで済んだと思うことです。これらは app の実行権限と UI 側の読み込み制御であって、Functions endpoint の認証・認可とは別です。
default visibility のまま UI 専用 tool を model に見せることです。ローカルでは問題が出なくても、実運用では tool 選択候補を無駄に増やす原因になります。
source map や静的アセットの扱いを雑にすることです。特に本番での .map 公開は慎重に判断すべきです。
Consumption 前提の体感で本番 UX を判断することです。UI を伴う MCP App では初回遅延がそのまま評価を下げるので、想定クライアントに近い条件で測るべきです。

まとめ

今回の Azure の MCP アプリ向け Fluent API は、MCP App 開発からフロントエンド実装を消す機能ではありません。価値が大きいのは、ui:// リソース、MIME type、metadata、visibility、権限、CSP といった「MCP アプリを成立させるための配線」を Azure Functions 側に寄せられることです。すでに Azure Functions で MCP tool を持っているなら、まずは 1 つの小さな tool を AsMcpApp() で app 化し、View・権限・CSP・認証・ホスティングプランを最小構成で固めるのが、最も失敗しにくい進め方です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

AzureがMCPアプリ向けFluent APIを導入　Azure Functionsで開発障壁が下がる理由

Azure の MCP アプリ向け Fluent API とは何か

なぜ開発の障壁が下がるのか

従来より何が簡単になったのか