.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 を検討という進め方が順当のようです。