.NET で Web API を作るとき、いつものように dotnet new webapi でプロジェクトを作る人が多いと思います。

でも最近、dotnet aspire という新しい選択肢が出てきて、「これって何？」「普通の Web API と何が違うの？」と気になったので調べてみました。

Aspire はマイクロサービスやクラウドを念頭においたもので、そのための機能が用意されているようです。ただ、構成もやることも増えるので、学習コストが高くなります。

従来の Web API プロジェクトと Aspire を使った API 開発を実際に比べてみて、どんなところが違うかをまとめてみました。

そもそも Aspire とは

dotnet aspire は、.NET 8 から登場した新しいアプリケーションモデルで、マイクロサービスや分散システムを簡単に構築・管理できることを目的としています。
名前の由来は「分散アプリを '目指す（aspire）'」という意味合いです。

Aspire での API サーバーのプロジェクト作成方法は？

aspire-webapi テンプレートを使って API プロジェクトを作成します。

プロジェクト名がMyAspireApiの場合

dotnet new aspire-webapi -n MyAspireApi

プロジェクトのディレクトリツリーは次のような感じです。

MyAspireApi/
├── MyAspireApi.sln
├── MyAspireApi.AppHost/         ← 全体構成と依存サービス
├── MyAspireApi.WebApi/          ← 実際のAPIロジック（ASP.NET Core）
└── MyAspireApi.Components/      ← 共有コード（モデル・サービスなど）

Web API と Aspire API との違い

概要比較

項目	通常の Web API	Aspire API
コマンド	`dotnet new webapi`	`dotnet new aspire-webapi`
構成	単一プロジェクト or 単純な構成	複数プロジェクト（AppHost + サービス）
クラウド対応	手動で追加（Docker/K8s等）	初めからクラウドネイティブ前提
サービス登録	`builder.Services.AddXxx()`	Aspire の `AppHost` で依存関係を定義
実行管理	`dotnet run` 単体	`dotnet run` で複数サービス一括起動
Daprなど	手動導入	Aspire AppHostから連携しやすい
観測性	監視・トレースは手動構築	OpenTelemetry, Dashboard 付き
主な用途	単体API、業務アプリ、社内APIなど	マイクロサービス構成、SaaS、分散システム

開発時の比較

比較項目	通常の Web API	Aspire
セットアップの簡単さ	非常に簡単：単一プロジェクトで完結	やや難しい：複数プロジェクトが生成される
構成の理解コスト	低い：APIだけに集中できる	中〜高：AppHost, コンポーネント分離の理解が必要
依存関係の管理	DI とサービス登録で完結	AppHost側で構成し、APIから参照するモデル
開発中の確認のしやすさ	シンプル：`dotnet run` 一発起動	Aspireダッシュボードあり、ただし複数起動に注意
追加サービスの連携（DB, Redisなど）	自分でDockerやパッケージを用意	Aspire内で `apphost.AddRedis(...)` 等で連携容易
制約（自由度）	高い（自由にプロジェクト構成できる）	やや制限あり（推奨構成に従う必要がある）
学習コスト	初学者でもすぐに始められる	.NETの中級者以上向け（AppHostやオーケストレーションの理解が必要）
クラウド対応（将来性）	Docker/K8s 対応は手動構築	Aspire内に初めから整備済み、スケール想定向き

Aspire API 開発の特徴

AppHost プロジェクトでサービスを束ねて一括管理できる
分散トレーシング、ログ収集、メトリクスが初期構成に組み込み済み（OpenTelemetry）
Redis、PostgreSQL、Zipkinなどを開発時に簡単に使える（dotnet aspire run で起動）
複数のAPIやWorkerを統一して起動できる

まとめ

どちらが優れているというよりも、目的や開発規模に応じて選ぶべき、という感じでしょうか。
まずは従来の構成で始めてみて、サービスの成長に合わせて Aspire を検討という進め方が順当のようです。