毎年恒例になりつつありますが、今年も Ignite 2025 で Azure でも特に PaaS / Serverless 領域でのアップデートが多く発表されたので、特に自分が気になる点を中心にまとめておきます。
最近では App Service などを含めて Azure Application Platform と呼ばれていますが、Ignite 2025 でのアップデートは以下でまとめられています。
個人的には API Management 関連のアップデートが多いと感じています。Premium v2 が GA していたり、A2A や MCP といった AI 関連機能がさらに追加されているのが特徴的です。
今回メインとなる App Service 関連のアップデートですが、以下のようになかなかの量があります。Azure Functions と Container Apps は AI 関連の機能が相変わらず多めです。
ここから先は各サービスごとに気になるアップデートを細かく見ていきます。
App Service
これまで通り App Service は順当なアップデートが行われていますが、今回は Managed Instance が一番大きなアップデートとなります。それ以外には .NET Aspire のサポートや App Service on Linux での Log stream 改善や、言語バージョンのアップデートなどが中心です。
まだ機能はリリースされていませんが、2026 年には Linux での Outbound IPv6 サポートや Private Endpoint のカスタムドメインサポートなどが予定されているようなので期待です。ASEv3 も今後アップデートが行われていくようです。
Managed Instance が Public Preview
今回のメインとなる App Service の Managed Instance が Public Preview として公開されました。そもそも App Service は Managed だろと突っ込みたくはなるのですが、立ち位置としては昔懐かしの Cloud Services のようにスクリプトによって VM のカスタマイズが行えるオプションという感じです。
カスタマイズ用のスクリプトをデプロイしたり、レジストリキーを変更するといった処理が Cloud Services の時よりも安全に行えるようになっています。Bastion 経由での RDP にも対応しているところが更に Cloud Services っぽいです。
ASEv3 でも良いのではという気はしますが、GAC やアプリケーションのインストールが行える点が Managed Instance の特徴です。Windows Containers でも同様のことは行えましたが、直接 VM に対して構成を行う点が大きく異なっています。
個人的にはあまり積極的に使うサービスではなく、あくまでもオンプレの VM からの移行時に役立つサービスだと認識しています。
Async Scaling が Public Preview
これまでの App Service のスケーリングは実際にインスタンスを確保し終わるまでブロッキングを行っていたようで、一時的なキャパシティ不足の時にはスケーリングに失敗するといった挙動になっていたようです。
今回の Async Scaling では名前の通り非同期でスケーリング処理を行うため、インスタンスの確保が完了するまで待つのではなく、バックグラウンドで指定された台数まで増やすといった処理になるようです。
このような動作によって、最近のキャパシティ不足でのスケーリング失敗を回避できるようになるようです。元々非同期でスケーリングしてると思っていたので、個人的にはこちらの挙動の方がしっくりきます。
Custom Error Pages が GA
App Service の前段にいるリバースプロキシが YARP に置き換えられた時にプレビューとなったカスタムエラーページですが、ようやく GA となりました。App Service がシステムで返すエラーページをカスタマイズ出来るため、懐かしさすらあるデザインのページをユーザーに見せないように出来ます。
Terraform などの IaC ツールとの相性がイマイチ悪そうという思っているので、個人的にはあまり使わないかも知れませんが、ブランディングという観点では設定しておいて損はないでしょう。
Azure Functions
ここ最近は AI をターゲットにしたアップデートが多かった Azure Functions ですが、今回も AI をターゲットにしてはいますが MCP と Durable Functions 関連がメインとなっていて、なかなか魅力的なアップデートとなっています。
Durable Functions の基盤となっている Durable Task Framework の適用範囲が Agent Framework にも広がり、更に実行を支えるための Durable Task Scheduler も GA したことで Serverless Agent の本番運用の準備が整ったという印象です。
今後も Azure Functions の重要性が高まることを感じさせるアップデートという印象です。
MCP Trigger / Binding が GA
今年で一番の機能だと思っている Azure Functions の MCP Trigger / Binding ですが、GA したことで安心して本番向けにも使えるようになりましたし、C# 以外の言語でも Streamable HTTP を使えるようになったので扱いやすくなっています。
MCP サーバーを Flex Consumption 上で Self hosting する機能は Preview ですが、個人的には Container Apps などでホストした方が良いのではという気持ちがあります。
GA 後もこの MCP 拡張は開発が積極的に行われていて、最新のコミットでは enum のサポートや MCP Tool の実行結果として画像などを返せるようになっています。
Authentication で OAuth 2.0 PRM サポートが Public Preview
既に以下の記事で書きましたが、App Service Authentication で OAuth 2.0 の Protected Resource Metadata に対応したので、MCP クライアントが自動的に認証を行って安全に MCP Tool を使えるようになりました。
現時点の Entra ID は Dynamic Client Registration に対応していないので、手動で Entra ID にアプリケーション登録が必要ですが、Visual Studio Code では Entra ID でログインして安全に利用できることを確認済みです。
Flex Consumption で Rolling Update が Public Preview
既に Flex Consumption は GA していますが、これまでダウンタイム無しのデプロイでよく使われていた Deployment Slot に対応していなかったため、運用で悩んでいたケースもあると思います。今回のアップデートで Rolling Update に対応したので Deployment Slot を使わずとも安全にデプロイ出来るようになりました。
これまでの挙動となる Recreate と Rolling Update の違いは公式ドキュメントが分かりやすいので、必ずこちらを確認してから設定するか検討してください。
設定から Rolling Update を選択すると、次からのアプリケーションデプロイ時にインスタンスが順次アップデートされるため、古いコードと新しいコードが同時に動作するタイミングが発生します。処理に互換性が無い場合は問題となる可能性が高いので慎重に選択してください。
Durable Task Extension for Microsoft Agent Framework が Public Preview
個人的に Serverless で AI Agent を実行する際の決定版だと思っている、Durable Task Extension for Microsoft Agent Framework が公開されました。名前の通り Durability を Agent Framework に追加する拡張ですが、長時間実行される AI Agent を確実に実行することや、途中で人間が介入する処理を実装出来ます。
これまでも Durable Functions の Activity を使って同じような処理を書いてきましたが、Agent Framework に強く統合されている点が大きく異なります。Agent Framework については深く書きませんが、Function Calling と MCP Tools を実装の中心に置くことによってよってかなり洗練されています。
Durable Task Scheduler の Dedicated が GA / Consumption が Public Preview
Durable Functions は非常に便利な機能なのですが、標準のストレージ実装では Observability が若干弱かったり、パフォーマンス面で上限があまり高くないというのが弱点でしたが、高性能かつモニタリングも充実している Durable Task Scheduler の Dedicated がついに GA しました。
コストは Azure Storage や Netherite を使っていた時よりは正直上がりますが、Task Hub で複数運用も出来るのでトータルコストは十分下げる余地がありますし、非常に使い勝手の良いダッシュボードが付いているので、本番運用時でも安心して利用できます。
今回 Dedicated が GA したタイミングで待望の Consumption が Public Preview として公開されました。まだ Azure Portal からはデプロイ出来ないようですが、1 アクション当たりの完全従量課金となっているため、小規模なワークロードや開発環境などで非常に便利に扱えるはずです。
課金の単位となっているアクションがあまりイメージが付かないと思いますが、以下のドキュメントで非常にわかりやすく説明されているので、Consumption を使う場合には必ずチェックしておいてください。
ざっくり計算で 1 カ月に 16 万アクション以上使う場合には Dedicated の方がお得になるようでした。本番で利用する際には事前にある程度見積もってから Tier を選択してください。
Container Apps
例によって AI 関連の機能が前面に打ち出されてますが、個人的にはプラットフォームとしてのアップデートがしっかりと行われているのが印象的です。Serverless GPU のリージョン拡張や Confidential Computing が Public Preview など AI 関連という感じですね。
恐らく Azure Functions でもサポートされていると思いますが、Container Apps で Durable Task Scheduler のサポートが GA となっているのも大きいです。スケーリング周りでの対応だと思いますが、これでゼロスケールまでの対応が行えるかと。
Dynamic Session の MCP サポートが Public Preview
Container Apps の基盤を利用して LLM が生成したコードを安全に実行可能な Dynamic Session ですが、組み込みの MCP エンドポイントが Public Preview となったので既存の AI アプリケーションに組み込みやすくなりました。デプロイ時に設定する必要がありそうですが、Dynamic Session は MCP 経由で使うのがベストでしたので手間が省けます。
独自のアプリケーションで Python のコードを実行して、その結果を更に LLM に返すことが出来るので LLM が苦手とする計算や集計といった処理を確実に行えるようになります。これはかなり便利な機能なので、積極的に組み込んでいきたいです。
Premium Ingress が GA
標準の Ingress はプラットフォーム側のリソースを使っている関係でパフォーマンスには限界がありましたが、Premium Ingress では独自の Workload Profile 上でホストできるようになるため性能を大きく上げることが可能です。
かなりのハイパースケールな環境が対象になるかと思いますが、標準の Ingress に足を引っ張られる可能性が無くなるので、大規模なアプリケーションでも安心して使いやすくなりますね。
Rule-based Routing が GA
リクエストのパスや FQDN によってどの Container App にルーティングを行うか定義出来る Rule-based Routing も GA です。Front Door や Application Gateway を使ってパスベースのルーティングを行っているケースでは、Rule-based Routing に切り替えた方がシンプルかつ柔軟に定義できる可能性があります。
FQDN によってルーティング先の Container App を切り替えられるので、マルチテナントのアプリケーションを実現する際に便利に使えるかと思います。
Flexible Workload Profile が Public Preview
Container App Environment には Consumption と Workload Profile の 2 つが用意されていますが、3 つ目の Flexible Workload Profile が Public Preview となりました。Workload Profile のようにインスタンスサイズを事前に定義して確保するのではなく、Consumption と同じ使い勝手で専用プールで動作し VNET を定義出来るようになります。
Consumption よりメモリの上限は増えていますが、Workload Profile のように大きなリソースを確保することは出来ません。Azure Functions と同じように Consumption を使っている場合は Flexible Workload Profile を使う方が追加のコストは乗ってきますがメリットが多いはずです。
Deployment labels が Public Preview
これまで Container Apps の Revision mode は Multiple が CI/CD のシナリオでは非常に使いにくいと思っていましたが、今回 Deployment labels が Public Preview となったので App Service などの Deployment Slot に近い形で扱えるようになりました。Deployment mode を Deployment labels に変更すると Azure Portal の表示も大きく変わるので最初は戸惑いそうです。
まだ試せていませんが、事前に Deployment label を作成しておいて、ルーティングを変更できる仕組みになっているので、使い勝手としても Deployment Slot に非常に近いのではないかと思っています。
既に公式の GitHub Action では特定の Deployment label に対してデプロイする機能をサポートしているようなので、簡単に試せる環境にはなっています。
Deployment Slot のように Swap ではなく Redirect label という機能になっていて、ルーティングを変更する仕組みのようなので、デプロイ時のフローについてはもう少し検討する必要がありそうです。
