Aspire 9.5 の新機能: .NET 8/9対応やAI強化、Azure連携など最新アップデート総まとめ

Aspire 9.5 の新機能: .NET 8/9対応やAI強化、Azure連携など最新アップデート総まとめ

.NET Aspireは、マイクロサービスを含む分散アプリケーションを統合的に開発・デプロイするためのオープンソースフレームワークです。複数のサービスやコンテナ、依存関係を単一のモデルで記述し、ローカル開発からデバッグ、クラウドへのデプロイまで一貫した体験を提供します。最新バージョンであるAspire 9.5はマイナーアップデートに位置付けられ、.NET 8.0 (LTS)や.NET 9.0 (STS)への対応に加え、次期メジャーである.NET 10のリリース候補版にも対応しました。Aspireは.NET本体のリリースとは独立した頻度で更新されており、今回の9.5でも開発者のフィードバックを取り入れたさまざまな機能強化が行われています。

Aspire 9.5で注目すべき新要素としては、コマンドラインツール (CLI) におけるプロジェクト自動アップデート機能の追加、Azureへの展開力を高めるAzure Container App Jobsサポート、ダッシュボード上での生成AIビジュアライザーによるAIテレメトリの可視化、Single-File AppHost（単一ファイルプロジェクト）機能のプレビュー提供などが挙げられます。また、OpenAIサービスやAzure AIへの統合強化、Dev Tunnels対応、YARPプロキシでの静的ファイル配信対応など、クラウドネイティブ開発を支援する多彩な改善が含まれています。さらにCLIやランタイムの最適化により、パッケージ解決の高速化やログ出力の洗練化などパフォーマンス面の向上も図られています。

Aspire 9.5 へのアップグレード: 移行の手順とaspire updateコマンドによる自動更新

Aspire 9.5へのアップグレードは比較的簡単に行えます。既存のプロジェクトを9.5対応にする基本手順は次の通りです。

1. Aspire CLIを最新版 (v9.5) にアップデートします。
2. AppHostプロジェクトファイル（例: MyApp.AppHost.csproj）内のSDK参照をAspire.AppHost.Sdk 9.5.1に変更します。
3. プロジェクトで利用しているAspire関連のNuGetパッケージを最新バージョンに更新します。
4. dotnet new install Aspire.ProjectTemplatesコマンドを実行し、Aspireのプロジェクトテンプレートを最新版にインストールします。

上記の手順により、Aspire 9.5の環境へ移行できます。また、Aspire 9.5ではプレビュー機能としてaspire updateコマンドが導入されました。これは既存プロジェクトをスキャンして古いパッケージやテンプレートを検出し、自動的に安全なバージョンへアップグレードするCLIコマンドです。aspire updateは安定版だけでなく開発版へのアップデートにも対応しており、対話的に確認しながらプロジェクトファイルやNuGet設定を更新します。ただしプレビュー段階のため、実行前にバージョン管理でプロジェクトをバックアップし、更新内容を確認することが推奨されています。

Azure Container App Jobs のサポート: スケジュール実行可能なバッチジョブ展開機能の追加

従来、Azure Container Appsは常駐型のアプリケーション実行に用いられてきましたが、新たにAzure Container App Jobsという仕組みが加わり、短時間で終了するバッチ処理や定期実行タスクをコンテナで実行できるようになりました。Aspire 9.5ではこのContainer App Jobsに対する包括的なサポートが追加され、バックグラウンドジョブとしてプロジェクトをAzure上にデプロイできるようになっています。これにより、データ処理やETL、バッチジョブ、スケジュールメンテナンスといった「期間限定で実行し完了する」ワークロードを、Azure Container Apps環境下で手軽に扱えるようになります。

Aspireからジョブをデプロイするには、コード上でコンテナ化したいサービスを定義した際にPublishAsAzureContainerAppJob拡張メソッドを利用します。これを指定すると、そのリソースはAzure上で手動起動のジョブとしてデプロイされます。また、スケジュール実行したい場合にはPublishAsScheduledAzureContainerAppJobメソッドでCRON形式のスケジュールを指定可能です。例えば毎日深夜に実行するバッチ処理をジョブとしてデプロイするといったシナリオが実現できます。Container App Jobsのサポート追加により、従来の常駐サービスに加えてスケジュールやイベントトリガーで動くタスクもAspireで一元的に管理でき、クラウドでの高度なジョブ実行シナリオに対応しました。

高度なデプロイ シナリオへの対応: Aspire CLIによるAzure自動デプロイと柔軟なタグ設定機能の強化

Aspire 9.5では、Azureへのデプロイ操作も大幅に簡素化されています。新たにCLIに統合されたaspire deployコマンドを使うことで、Azure上へのリソースプロビジョニングからアプリの配置までを自動化できるようになりました。このコマンドは、内部で依存関係に基づくデプロイ計画（ResourceDeploymentGraph）を構築し、リソースの作成順序を自動的に調整して最大限に並列化します。例えばデータベースやストレージなどの基盤リソース→アプリケーション本体の順に正しくプロビジョニングされるため、デプロイ失敗を減らせます。またデプロイ実行中に必要な設定値（接続文字列やシークレットなど）がある場合は対話的に入力を促し、AppHostのインタラクションシステムと統合された形で値を取得します。コンテナイメージのビルドやレジストリへのプッシュ、Azure Container Appsへのデプロイまで一括して処理され、進行状況とエラーもリアルタイムに出力されるため、クラウドへのデプロイ作業がワンコマンドで完結します。

さらに、Aspire 9.5ではデプロイ時のコンテナイメージのタグ設定を動的に行う仕組みも強化されています。新たな拡張メソッドWithDeploymentImageTagにより、各サービスのイメージタグを環境やビルド情報に応じて柔軟に生成可能です。例えば環境名を含めてprod-1.0.0やstaging-20231015といったタグを自動付与したり、外部のバージョンサービスから取得したビルド番号を組み込むこともできます。複数のコンテナサービス間で共通のバージョンタグを付けることも可能で、事前に生成した共有バージョン文字列を用いてフロントエンドとバックエンドで一致するタグ名を設定する、といったシナリオにも対応します。これらの機能により、複雑なデプロイ要件がある分散アプリケーションでも、Aspireが自動で環境別設定やバージョン管理を適用し、デプロイ作業の柔軟性と信頼性が向上しました。

互換性を壊す変更 (Breaking Changes): Aspire 9.5移行で注意すべき変更点まとめ

Aspire 9.5では下位バージョンからのアップグレード時にコードの修正が必要となる互換性破壊の変更（ブレイキングチェンジ）がいくつか導入されています。開発者は以下の点に留意してプロジェクトを更新する必要があります。主な変更点として、コンテナのホスト名解決方法の修正、リソースのライフサイクル管理仕様の変更、通知メッセージAPIの名称変更などがあり、それぞれ既存コードに影響を及ぼします。次に、その詳細と対応策を解説します。

コンテナホスト名解決ロジックの変更点

複数コンテナ間の通信設定に関する挙動が変更されています。特に、WithEnvironmentを用いてコンテナ環境にサービスを追加する際、これまでは内部エンドポイントのホスト名が常にlocalhostに解決されていましたが、Aspire 9.5以降はコンテナの実ホスト名が適切に解決されるようになりました。この変更により、分散環境でサービス間を接続する際のホスト指定が正しく行われますが、既存のコードでlocalhostを前提としてハードコーディングしていた場合には修正が必要です。コンテナ内でのサービス検出がより正確になる一方、古い挙動に依存していた構成は更新後に接続できなくなる可能性があるため注意してください。

リソースのライフサイクル操作に関する変更

一部のリソース種別がアプリケーションのライフサイクル管理に含まれるようになりました。具体的には、ParameterResourceやConnectionStringResource、GitHubモデルリソースなどは、9.5から内部的に「起動・実行中」の状態を持ち、他のサービス同様にWaitForによる待機やライフサイクルイベントへの参加が行われます。以前のバージョンではこれらリソースは実行対象外（IResourceWithoutLifetimeとしてライフサイクル管理から除外）でしたが、9.5では起動順序や依存関係の一部として扱われるよう変更されました。このため、該当リソースを利用している場合、明示的な待機処理を追加したり、依存するサービス側でこれらが利用可能になるタイミングを考慮する必要があります。

通知メッセージの名称変更に伴う影響

UI上の通知機能に使用されていた名称やAPIにも変更が発生しています。従来、通知バーに相当するコンポーネントはMessageBarという名前で提供されていましたが、Aspire 9.5では新しい通知システムの導入に伴い、このMessageBarが別の名前に改められました。このリネームにより、該当クラスやメソッド名が変更されているため、9.4以前のコードでMessageBarにアクセスしている箇所はコンパイルエラーとなります。プロジェクト内のUI通知処理について、新しいAPI名（ドキュメント参照）に置き換える修正が必要です。

InteractionInput API の変更: Nameプロパティ必須化に伴う実装修正時の注意点

Aspire 9.5では、対話型のパラメータ入力を扱うInteractionInput APIにも変更が加えられました。パラメータ入力フォームの各項目にユニークな名前を付けることで、後続の処理を型安全に扱えるようにするためです。具体的には、InteractionInput定義時にNameプロパティの指定が必須となり、代わりにLabel（表示名）はオプション扱いに変わりました。これまではLabelのみで定義できていましたが、今後はコード上で各入力項目に一意なNameを付ける必要があります。この変更により、対話型入力の識別と処理が一層明確化され、複数入力を扱う際のコード保守性が向上します。

Nameプロパティ必須化の背景と目的

Nameプロパティ必須化の背景には、入力値の処理をより厳密かつ便利にする目的があります。各入力に開発者が一意な識別子（Name）を割り当てることで、実行時に結果をInteractionInputCollectionとして受け取った際にresult.Value["項目名"]のように名前でアクセスできるようになります。これにより、複数の入力を扱う対話処理であっても、名前をキーに安全に値を取り出せ、型チェックも強化されます。また、内部的にはフォーム入力のシリアライズ処理が改善され、対話型UIとバックエンド処理との連携がスムーズになるという利点もあります。

既存コードへの影響と移行の対処方法

この変更に伴い、Aspire 9.4以前からプロジェクトをアップグレードする際は、InteractionInputを生成しているコードを確認する必要があります。例えば、以前は次のように記述していたコード:

var input = new InteractionInput { Label = "Database Password", InputType = InputType.SecretText, Required = true };

このコードは9.5ではコンパイルエラーとなります。代わりにNameプロパティを追加した以下のような記述に修正してください。

var input = new InteractionInput { Name = "database_password", // 一意な識別子を指定 Label = "Database Password", // ラベルは省略可（指定しない場合Nameが表示に使われる） InputType = InputType.SecretText, Required = true };

Nameには半角英数字などで任意の識別子を設定できます（UIに表示されるラベル名とは別に内部IDとして使われます）。Labelを省略した場合はNameの値がそのまま表示用ラベルとして使用されます。Nameプロパティを適切に付与することで、対話フォームの結果をコードから扱いやすくなり、フォームと処理ロジックの連携が強化されます。

CLIの更新コマンドと自動アップデート機能: Aspire 9.5で導入されたアップグレード支援

Aspire CLIには開発者の利便性を高める新機能が追加されました。その目玉がプロジェクト更新用の新コマンドであるaspire updateです。従来はNuGetパッケージやSDKバージョンを手動で確認・更新する必要がありましたが、Aspire 9.5ではaspire updateコマンドを実行するだけでCLIがプロジェクト内のAspire関連パッケージをスキャンし、古いものを検出して最新互換バージョンへアップグレードしてくれます。結果として、ライブラリ更新の手間が大幅に削減され、プロジェクトを常に最新の状態に保ちやすくなりました。

aspire updateコマンドの概要と自動更新の仕組み

aspire updateコマンドは、AppHostプロジェクトや関連するクライアントライブラリのバージョンをまとめて更新するためのツールです。コマンドを実行すると、現在使用しているAspire SDKやパッケージのバージョンをチェックし、新しいバージョンが存在する場合にアップデート候補として一覧表示します。ユーザーが確認を承認すれば、プロジェクトファイル（.csproj）やNuGet.config、集中管理されたパッケージバージョン定義などを自動的に書き換えて最新の依存関係に更新します。アップデート適用前には変更点が対話形式で提示されるため、不意のバージョン飛びを防止できます。aspire updateはまだプレビュー段階のため、今後仕様変更の可能性がありますが、将来的にはワンクリックで安全にプロジェクト全体を最新化できる強力な手段となるでしょう。

安定版・開発版を選択可能なチャンネル対応アップデート

このアップデート機能はチャンネル対応である点も特徴です。Aspireでは安定版 (Stable) だけでなく、最新機能を含むデイリービルド版 (Daily) やカスタムビルドにも切り替えて試すことができます。aspire updateコマンド実行時にチャンネルを指定することで、更新先を例えば安定版9.5.x系ではなく開発版のビルドに合わせる、といった運用も可能です。これにより、新機能の早期検証が必要なケースや独自に拡張されたAspireビルドを使いたい場合でも、CLI上で柔軟にアップデートできます。また、同様のチャンネル指定機能はaspire addコマンド（パッケージ追加）にも導入されており、パッケージ追加時に安定版以外のバージョンを選択して導入することも容易になりました。総じて、Aspire 9.5のCLIはプロジェクトのメンテナンス性を高め、最新技術の取り込みをスムーズにする方向で強化されています。

ダッシュボードのAIビジュアライザーと監視機能拡充: LLMテレメトリ可視化とOpenTelemetry対応による分散トレース強化

Aspireが提供するダッシュボード（Webベースの管理画面）も、バージョン9.5で機能拡張が行われました。特に、生成AI（大規模言語モデル）の統合に対応した新しいAIビジュアライザーと、分散アプリケーションのログ監視性を高める改良が注目ポイントです。ダッシュボード全体のUI/機能が強化され、複雑なシステムの監視・分析が以前より容易になっています。

生成AIビジュアライザーでLLMテレメトリを可視化

Aspire 9.5のダッシュボードにはGenerative AI Visualizer（生成AIビジュアライザー）が新たに組み込まれました。これは、アプリケーション内でLLM（大規模言語モデル）を利用した処理を行っている場合に、そのやり取りの詳細を可視化するためのツールです。具体的には、AIモデルへのプロンプト（入力）やそれに対するモデルからの応答を時系列で収集し、ダッシュボード上で一覧・分析できるようにします。OpenTelemetryの最新仕様に沿った形でテレメトリデータが整理されており、開発者はプロンプト内容や応答結果、所要時間などを確認しながらモデルの動作を理解できます。これにより、AIを組み込んだ機能のチューニングやトラブルシューティングが容易になりました。たとえば、チャットボットの応答精度を改善する際に、実際にユーザーから送信された質問（プロンプト）とAIの回答を振り返り、問題のある箇所を特定するといったことが可能です。

統合ログ表示と分散トレース機能の強化

複数のサービスから成る分散アプリケーションでは、システム全体のログやトレースを横断的に把握することが重要です。Aspire 9.5ではダッシュボード上で複数リソースのログを統合表示できるようになり、コンテナAとコンテナBのログを1つのビューでまとめて確認するといったことが容易になりました。フィルタ機能も強化され、サービス名や相関IDでログを絞り込んで、あるリクエストが各サービス間をどう流れたかを追跡できます。また、分散トレースの表示UIも改良され、個々のトレースイベントの詳細をより見やすく検証できるようになりました。これらの改善はOpenTelemetryをはじめとする業界標準のテレメトリ仕様を取り入れたもので、Aspire上で収集したデータを他の監視ツールと連携することも容易になります。

さらに、ダッシュボード／ホスティング周りの細かな改良点として、リバースプロキシ配下でのヘッダー転送設定 (Forwarded Headers) のサポートや、コンテナ実行時の通知機能（起動／停止イベントの可視化）、トレースのフィルタリング精度向上などが挙げられます。これらにより、実運用環境に近い形でAspireダッシュボードを利用でき、複雑なネットワーク構成下でも正確にアプリケーションの状態を監視できるようになっています。

Single-File AppHost機能（プレビュー）: 単一ファイルのプロジェクトで軽量アプリを構築

Aspire 9.5では、AppHostプロジェクトを単一ファイルで記述できるSingle-File AppHost機能がプレビュー公開されました。従来、Aspireで分散アプリケーションを作成する場合、各マイクロサービスごとに個別のプロジェクトを作成し、それらをソリューションでまとめる形が一般的でした。一方、新しく導入されたSingle-File AppHostを使うと、ひとつのC#ソースファイル内に分散アプリ全体の構成を完結させることができます。小規模なサービス群やプロトタイプ作成時に、プロジェクトファイルや複数のプロジェクトセットアップを省略できるため、迅速に開発を開始できるのがメリットです。もちろん、規模が大きい場合や必要に応じて従来通り複数プロジェクトに分けることも可能ですが、選択肢として単一プロジェクトで完結するモデルが追加された形です。

単一ファイルAppHostのメリットとユースケース

Single-File AppHostでは、アプリのエントリポイントから各リソースの定義までを1ファイル内に記述できます。例えば以下のように、ビルダーを作成して複数のサービスやリソースをbuilder.AddProject等で登録し、最後にbuilder.Build().Run()するシンプルなコードだけで基本的な分散アプリを構築できます。

var builder = DistributedApplication.CreateBuilder(args); builder.AddProject("api"); builder.AddProject("worker"); builder.AddRedis("cache"); builder.Build().Run();

このように、ボイラープレートとなるプロジェクト定義を減らし、スモールスタートのサービス開発や検証用の簡易アプリ作成に役立ちます。学習目的でAspireの構造を試す際にも、一つのファイルだけで完結するため手軽です。

Single-File AppHostプレビュー機能の有効化方法

Single-File AppHostは現在プレビュー段階の機能であり、既定では無効化されています。利用するには、.NET SDK 10.0.100 RC1以降をインストールした上で、Aspire CLIで以下の設定を有効にします。

aspire config set features.singlefileAppHostEnabled true

上記コマンドでシングルファイル機能のフラグをオンにすると、Aspireのaspire newコマンド実行時に「Single-File AppHost (Experimental)」というテンプレートが選択できるようになります。このテンプレートを使用すると、従来の.csprojファイルを持たないC#ファイル単独のプロジェクトが作成されます。なお、Single-File AppHost機能を有効化するとAspireが要求する.NET SDKの最低バージョンが引き上げられる点に注意が必要です（プレビュー機能のため、現時点では.NET 10 SDKが必要）。将来的な.NETのファイルベース実行シナリオに先駆けた実験的機能となりますが、興味のある場合はぜひ試してみてください。

分散アプリケーションの構築支援とパフォーマンス向上: リソース管理改善やログ統合による開発生産性アップ

Aspire 9.5では上記の大きな新機能に加えて、既存機能の改善やパフォーマンス最適化によって開発体験を向上させています。分散アプリケーションの信頼性と効率性を高める様々なアップデートが含まれており、開発者にとって日々の作業がより円滑になるよう支援されています。また、内部機能の改良やツールの最適化により、開発生産性の底上げも図られています。

サービス起動順とヘルスチェックによる信頼性向上

まず、リソース管理面ではライフサイクルフックとヘルスチェックの拡充があります。Aspire 9.5では各リソースに対してスタートアップ、レディネス、リブネスの各プローブ（起動時・稼働確認用のチェック）を設定できるようになりました。これにより、サービス間の起動順序の制御がよりきめ細かく行えます。たとえば、データベースが準備完了してからWebアプリが接続を開始するといったシナリオを、レディネスプローブの設定によって保証できます。各リソースが正常に開始されたことを確認しながら次のリソースを起動することで、依存関係のある分散システムでもスムーズに立ち上がり、エラー発生を防ぐことができます。また、実行中のサービスに対しても定期的にリブネスプローブでヘルスチェックを行えるため、異常が検知された場合に自動再起動するなど障害への対処も容易になります。これらの仕組みによって、Aspireが扱うクラウドネイティブアプリの信頼性が一段と向上しました。

開発ツールの高速化などパフォーマンス改善

開発者向けのツールやCLIにも多くのパフォーマンス改善が取り入れられています。特に、パッケージ管理やコマンド実行周りで顕著です。Aspire CLIでは、パッケージ検索結果のキャッシュ機能が追加され、aspire add等で同じパッケージを繰り返し検索する際の待ち時間が短縮されました。また、デバッグ出力やステータスメッセージの整理により、コマンド実行時のコンソールログが簡潔になっています。これにより、ビルドやデプロイの進行状況を把握しやすくなり、問題発生時の原因特定も迅速化されます。さらに、Aspire内部の依存関係解決処理が最適化され、同一プロジェクトでの反復的なビルド・実行を行う場合に処理時間が短縮されています。

そのほか、Azure Dev Tunnelsとの統合によりローカルサービスの公開が容易になったことや、新しいテンプレートの追加によるプロジェクト作成の選択肢拡大など、細かな改善点も多数あります。総合的に見て、Aspire 9.5は新機能の追加だけでなく、開発・運用両面での使い勝手と性能を底上げするアップデートとなっています。これらの改善によって、.NET開発者はより快適に分散システムの構築と管理が行えるようになるでしょう。