【Microsoft Azure】.NET 10 のプレビューが App Service で利用可能になったので試してみた

こんにちは、MS開発部の渋谷です。

皆さんはAzure App Serviceというサービスはご存知でしょうか。Azure App Serviceは、Microsoftが提供するフルマネージドのPlatform-as-a-Service (PaaS) であり、Webアプリケーション、モバイルバックエンド、RESTful APIの構築、デプロイ、スケーリングを目的に利用することが多いと思います。

そんなApp Serviceですが、一番大きな価値として「コンテナ化せずに」アプリケーションをスケーラブルなPaaS基盤で実行できることが挙げられると思います。特に、開発者が基盤となるインフラストラクチャ（オペレーティングシステム、Webサーバー、ロードバランサーなど）の管理から解放され、アプリケーションコードの開発という本質的な業務に集中できるところが良いところでしょう。

---

App Serviceはその特徴から、コンテナ化していないコードベースを利用する場合が非常に多いと思われますが、そこで気になるのは基盤側でサポートしているランタイムとそのバージョンです。

今回は8月下旬に.NET 10の対応がプレビューで開始しましたので、その内容を速報的にお伝えできればと存じます。

 

App Serviceについておさらい

概要

App Serviceの文脈におけるPaaSとは、Microsoftが仮想マシン、オペレーティングシステム、セキュリティパッチ、Webサーバーソフトウェア（IISなど）を含む、基盤となるインフラ全体を管理することを意味します 。このモデルがもたらす直接的な利点は、運用オーバーヘッドの大幅な削減です。サーバー管理タスクが不要になることで、開発チームはインフラの維持管理ではなく、ビジネス価値を直接生み出す生産的な活動に集中できるようになります 。

App Serviceを効果的に利用するためには、App ServiceそのものとApp Serviceプランの違いを明確に理解することが極めて重要です。App Serviceとは、アプリケーションのインスタンス、つまりコード、構成、そしてエンドポイント（URL）を指します 。

一方、App Serviceプランは、1つまたは複数のApp Serviceが実行される、基盤となる一連のコンピューティングリソース（CPU、メモリ、ストレージ）を定義するものです。これは、仮想マシンやサーバー群に例えることができます 。

この二つの関係性は、コスト最適化とパフォーマンス管理の鍵となります。複数のApp Serviceを単一のApp Serviceプラン上で実行することで、リソースを共有し、コストを削減できます 。これは、特に小規模なアプリケーションを多数運用する場合に有効な戦略です。逆に、特定のアプリケーションのパフォーマンスを安定させるためには、そのアプリケーションを専用のプランに分離することも可能です 。

言語と開発に便利な機能

App Serviceは、.NET、.NET Core、Java、Python、PHP、Node.js、Rubyなど、非常に幅広いプログラミング言語をネイティブでサポートしています 。開発者は「ランタイムスタック」と呼ばれる定義済みの実行環境から特定のバージョンを選択でき、これにより環境構築が迅速かつ容易になります 。

また、デプロイメントスロットは、App Serviceの最も強力な機能の一つです。これは、それぞれが独自のホスト名を持つ、アプリケーションのライブかつ独立したインスタンスです 。主なユースケースは、アプリケーションの新しいバージョンを「ステージング」スロットにデプロイすることです。これにより、本番環境のユーザーに影響を与えることなく、本番同様の環境で最終的なテストと検証を行うことができます 。

検証が完了すると、「スワップ」操作を実行します。これは、本番トラフィックをステージングスロットに瞬時にリダイレクトするアトミックなアクションであり、ステージングが新たな本番環境となります。このプロセスにより、デプロイ中のダウンタイムがゼロになり、問題が発生した場合は再度スワップするだけで即座にロールバックが可能です 。

さらに、トラフィックルーティング機能を使えば、本番トラフィックの一部（例：10%）をステージングスロットに流すことができます。これは、A/Bテストやカナリアリリースといった高度なデプロイ戦略を実現します 。この機能は、単なる技術的なデプロイツールにとどまらず、ビジネス上の意思決定を支援する戦略的ツールとしての価値を持ちます。新機能のビジネスインパクト（コンバージョン率など）を実ユーザーで検証し、データに基づいたリリース判断を可能にすることで、デプロイのリスクを管理された反復的なプロセスへと変革します。

このような機能をコンテナ化することなくマネージドサービスで利用できる点がApp Serviceの特徴であり、強みでもあります。

 

そこで、ここからは最新のプレビュー版.NETである.NET 10をマネージドサービスであるApp Serviceで実行してみたいと思います。

.NET 10アプリをApp Serviceで動かしてみる

環境整備

まずは.NET 10 SDKのインストールをします。2025年8月下旬現在、こちらのURLから最新の.NET 10のSDKがダウンロード可能です。ご自身のプラットフォームにあったバージョンをインストールしてください。

次に、Visual StudioかVS CodeでApp Serviceにデプロイするアプリケーションを作成します。（ここではVS Codeをつかって進めていきます）今回はASP.NET Core BlazorをApp Serviceにデプロイしたいので、VS Codeの拡張機能である「C# DevKit」をインストールします。拡張機能のインストールが終わりましたら、コマンドパレットを開いて「.NET New Project」を選択し、Blazor Web Appを作成します。

 

プロジェクトが作成されましたら、Home.razorを開き、簡単に.NETのバージョンを確認するコードを書き、Azureへのデプロイを行います。

 

ちなみに、.NET 10で作成されたテンプレートには、しっかり以前までの.NETのバージョンでは含まれていなかった「ReconnectModal.razor」が含まれています。詳細は公式ドキュメントをご確認ください。

Azure App Serviceの準備とデプロイ

実際に、Azure ポータルからApp Serviceを作成する際には、ランタイムの選択を「.NET 10(LTS)(プレビュー)」を選択するだけでOKです。特にそのほかWebサーバーやランタイムのインストールは必要ありません。すべてApp Service側でマネージドで管理してくれていますので、あとはこのままデプロイをするだけです。

 

App Serviceのデプロイが完了しましたら、VS Code の画面に戻り、Blazorのアプリをデプロイしましょう。App Service のデプロイ方法にはいくつか種類があり、GitHub Actionsを活用したCI/CDパイプラインを組んでデプロイすることが非常に一般的ですが、今回はZIPデプロイを活用します。（本番環境では、先述のデプロイスロットの機能を使うことを強く推奨します。）

 

VS CodeのAzure拡張機能をインストールし、先ほどApp Serviceをデプロイしたサブスクリプションへの適切な権限を持っているアカウントでログインすると、上記画像のように簡単にApp Serviceへデプロイが可能になります。

デプロイが完了しましたら、App Serviceにアクセスし、先ほど作成したBlazorアプリが表示されているかを確認してください。今回は非常にシンプルなアプリケーションをデプロイしましたが、ここからCI/CDパイプラインを組んでアジャイル的にアプリケーションをアップデートしていくといったことも可能です。

まとめ

今回はプレビュー版で.NET 10が利用可能になったApp Serviceを実際に試してみました。Azureの歴史の中でもかなり長く続いているサービスですが、最近はPremium v4 SKUも登場し、引き続き長く使っていけるサービスになっていると感じます。特にApp Serviceはコンテナ化しないアプリケーションをマネージドサービスで実行する基盤としては非常に便利で、今回のように.NETの最新バージョンもいち早く対応することで、より幅広いユースケースで使っていけると信じています。