はじめに
最近のアプリ開発では、ローカルでデバッグをしようとするだけでも複数のアプリケーションやミドルウェアを立ち上げる必要があることがあります。フロントエンドを起動して、バックエンドの Web API を起動して、さらにクラウドのリソースの代わりになるエミュレーターや Redis のコンテナーなどを起動して、ようやくデバッグが出来るといった感じです。
そういうときに Aspire を使うと、AppHost を起動するだけで必要なものが一通り立ち上がるのでとても便利です。この記事では、個人的に Aspire のどういうところが好きなのかを書いていこうと思います。
Aspire は以前は .NET Aspire と呼ばれていました。最近リブランディングして .NET だけのものではないという感じになっています。そのため、この記事では基本的に Aspire と書いていきます。
公式ドキュメントは以下になります。
今回は手元に小さなサンプルを作って、それを動かした画面も載せていきます。Visual Studio 2026 の「新しいプロジェクトの作成」で Aspire を検索し、Aspire スターター アプリ (ASP.NET Core/Blazor) を選んで作成しました。ソリューション名は AspireLab にしています。
作成時の追加オプションで Redis を使うかどうかを選べるので、今回はオフにしました。その後、作成された AspireLab.AppHost プロジェクトを F5 で起動します。
AppHost を起動するだけで全部立ち上がる
Aspire の便利なところとして最初に思いつくのは、AppHost を起動するだけでアプリケーション全体を立ち上げられるところです。AppHost にはアプリ全体の構成を C# で書くことが出来ます。例えば、このフロントエンドと、このバックエンドと、Cosmos DB のエミュレーターと、Redis のコンテナーを使うといった構成を書いておくようなイメージです。
今回のサンプルだと AppHost は以下のようになっています。
var builder = DistributedApplication.CreateBuilder(args);
var apiService = builder.AddProject<Projects.AspireLab_ApiService>("apiservice")
.WithHttpHealthCheck("/health");
builder.AddProject<Projects.AspireLab_Web>("webfrontend")
.WithExternalHttpEndpoints()
.WithHttpHealthCheck("/health")
.WithReference(apiService)
.WaitFor(apiService);
builder.Build().Run();
ちなみに AppHost は C# だけでなく、TypeScript で書く方法も用意されています。現時点ではプレビュー機能ですし、自分は普段 C# を使うことが多いので今すぐ使う機会はあまりなさそうですが、TypeScript や Node.js を中心に触っている人には面白そうです。興味がある人は以下の公式ドキュメントを見ながら試してみるとよさそうです。
そして AppHost を起動すると、そこに書かれているものがまとめて起動します。Blazor のフロントエンド、ASP.NET Core の Web API、Azure Cosmos DB のエミュレーター、キャッシュ用の Redis のコンテナーといった構成でも、Visual Studio 2026 で AppHost を F5 で起動すれば一通り起動します。接続文字列なども Aspire 側で構成してくれるので、アプリケーション側で開発時の接続先を細かく切り替えるようなコードを書かなくてもよくなります。
Visual Studio にはマルチスタートアッププロジェクトの機能もありますが、対象のプロジェクトや順番を正しく設定する必要があります。また、Redis や Azure Cosmos DB のエミュレーターのような外部リソースは別途準備する必要があります。Aspire の場合は、AppHost にアプリケーション全体の構成や依存関係を書いておけば、Visual Studio 2026 で AppHost を F5 で起動するだけで、フロントエンドやバックエンド、必要なコンテナーやエミュレーターをまとめて立ち上げられます。WaitFor のように依存先が準備できるまで待つ設定も AppHost 側に書けるので、起動順や周辺リソースの扱いを 1 か所に寄せられるのが便利だと思っています。
実際に起動すると Aspire Dashboard では以下のように apiservice と webfrontend が Running になります。
apiservice と webfrontend の 2 つが起動していて、それぞれの URL も Dashboard から確認出来ます。
今までは、複数のプロジェクトの起動設定を整えたり、Docker のコンテナーを手で起動したり、エミュレーターを別途起動したりしていたものが、AppHost を起動するだけで済むようになります。起動手順を毎回考えなくてよくなるのは楽ですし、チームに新しい人が入ってきたときにも「リポジトリを clone して AppHost を起動してください」で済むのは良いと思います。
Aspire Dashboard でログやトレースを見られる
AppHost を起動すると Aspire Dashboard も一緒に立ち上がります。このダッシュボードがあるのも、個人的に Aspire の好きなところです。
Aspire Dashboard では OpenTelemetry を使って収集された構造化ログ、分散トレース、メトリクスを見ることが出来ます。Aspire の Service Defaults を使っていると OpenTelemetry まわりの設定も入るので、AppHost から起動したときに Dashboard でログやトレースを見られるという流れになります。
Service Defaults の OpenTelemetry まわりを抜粋すると以下のような感じです。細かい設定を毎回各プロジェクトに書かなくてよいのは楽です。
public static TBuilder ConfigureOpenTelemetry<TBuilder>(this TBuilder builder)
where TBuilder : IHostApplicationBuilder
{
builder.Logging.AddOpenTelemetry(logging =>
{
logging.IncludeFormattedMessage = true;
logging.IncludeScopes = true;
});
builder.Services.AddOpenTelemetry()
.WithMetrics(metrics =>
{
metrics.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation()
.AddRuntimeInstrumentation();
})
.WithTracing(tracing =>
{
tracing.AddSource(builder.Environment.ApplicationName)
.AddAspNetCoreInstrumentation()
.AddHttpClientInstrumentation();
});
builder.AddOpenTelemetryExporters();
return builder;
}
複数のサービスを起動していると、それぞれのログが別々のターミナルに出力されて、エラーを探すだけでも面倒なことがあります。Aspire Dashboard を使うと、各サービスのログを 1 つの画面から横断的に確認出来ます。
特に便利なのは分散トレースです。フロントエンドから Web API を呼び出して、その Web API からさらに別のサービスやデータベースを呼び出すような構成の場合、どこで例外が出たのかを追うのが大変なことがあります。Aspire Dashboard では、リクエスト単位でどのサービスを通って、どこで時間がかかって、どこで例外が出たのかを見ることが出来ます。
今回のサンプルでは Weather ページを開くと webfrontend から apiservice にアクセスします。Dashboard のトレースを見ると、webfrontend: GET /weather の中に apiservice が含まれていることが分かります。
webfrontend のリクエストの中に apiservice の呼び出しが含まれていることが画面から分かるのは、ローカルで動作確認をしているときにも便利です。
ローカル開発環境で OpenTelemetry の収集先や可視化の仕組みを自前で用意しようとすると、それなりに手間がかかります。OTLP のエンドポイントを用意して、Collector を起動して、ログやトレースを見るためのツールも用意して、という感じです。Aspire では AppHost を起動するだけで、そのあたりが最初から使える状態になるので非常に便利です。
ダッシュボード自体の詳しい話は公式ドキュメントを見るのが早いです。
Aspire のログやトレースを AI から見に行ける
AI と一緒にアプリケーションを開発するうえで便利だと思っているのが、MCP サーバー経由で Aspire のリソース情報やログ、トレースを AI から参照出来るところです。今まで Dashboard で人間が見ていた情報を、GitHub Copilot などの AI クライアントからも見に行けるようになります。
例えばアプリを動かしていて例外が出たときに、今まではログを探してエラー内容をコピーして、AI に貼り付けて原因を聞くといったことをしていました。AppHost が起動していて Aspire MCP server が AI クライアントに設定されていれば、AI に「Aspire のトレースを見て原因を調べて」と伝えるだけで、AI がトレースや関連するログを確認してくれます。
Dashboard の右上にある MCP Server のボタンを押すと、手元の環境では以下のように設定方法が表示されました。バージョンによって案内されるコマンドは変わる可能性がありますが、Dashboard から MCP server の設定に辿れるのは分かりやすいです。
手元のバージョンではスクリーンショットのように aspire mcp init が表示されましたが、現在の公式ドキュメントでは aspire agent init で MCP server や skill file の設定を行う流れになっています。そのため、この記事では aspire agent init を使う例を載せています。
aspire agent init
自分でログをコピーして AI に渡す必要がなくなり、AI が今動いているアプリケーションの状態を直接見に行けるようになります。ログを探してコピーする手間が減るだけでも、原因調査の最初の一歩が楽になります。
詳しくは公式ドキュメントを参照してください。
AI に「AppHost を起動して」と言うだけでよい
AI と一緒に開発をしているときにも Aspire は便利です。
AI にアプリケーションを起動してもらう場合、通常は起動手順をそれなりに細かく伝える必要があります。このプロジェクトを起動して、次にこちらのプロジェクトを別ターミナルで起動して、Docker でこのコンテナーを起動して、といった内容です。手順を AGENTS.md などに書いておくことも出来ますが、それでも手順が複雑だと AI が間違えることがあります。
Aspire を使っている場合は、基本的に「AppHost を起動して」で済みます。AppHost が起動すれば必要なアプリケーションやリソースが立ち上がるので、AI に伝える内容もシンプルになります。
今回のサンプルでも、起動する対象は AppHost だけです。
aspire agent init を実行すると、対応している各 AI 環境向けに skill file と MCP server の設定ファイルをセットアップしてくれます。今回のサンプルで実際に全環境・全 skill を指定して実行してみると以下のような出力になりました。
aspire agent init --skill-locations all --skills all
エージェント環境を検出しています...
✅ Installed aspire skill (.agents/skills/aspire).
✅ Installed aspireify skill (.agents/skills/aspireify).
✅ Installed dotnet-inspect skill (.agents/skills/dotnet-inspect).
✅ Installed aspire skill (.claude/skills/aspire).
✅ Installed aspireify skill (.claude/skills/aspireify).
✅ Installed dotnet-inspect skill (.claude/skills/dotnet-inspect).
✅ Installed aspire skill (.github/skills/aspire).
✅ Installed aspireify skill (.github/skills/aspireify).
✅ Installed dotnet-inspect skill (.github/skills/dotnet-inspect).
✅ Installed aspire skill (.opencode/skill/aspire).
✅ Installed aspireify skill (.opencode/skill/aspireify).
✅ Installed dotnet-inspect skill (.opencode/skill/dotnet-inspect).
Installing Playwright CLI...
✅ Installed Playwright CLI.
✅ Aspire MCP サーバーを使用するようにVS Codeを構成する
✅ エージェント環境の構成が完了しました。
各 AI 環境向けのディレクトリに skill file が配置されます。Aspire CLI の使い方だけでなく、NuGet パッケージの API サーフェスを調べる dotnet-inspect skill や、ブラウザー操作テスト用の Playwright CLI skill も一緒にインストールされます。VS Code 向けには .vscode/mcp.json も生成されて、MCP server の設定も済んだ状態になります。
1 コマンドでここまで揃うのは正直ありがたいと思っています。skill file が入ることで AI が Aspire のプロジェクトとして認識しやすくなり、「AppHost を起動して」という指示も通りやすくなります。Playwright CLI skill については次のセクションで触れますが、動作確認まで AI に任せやすくなるという点でも、セットアップしておいて損はないと思います。
Playwright CLI と組み合わせると動作確認も AI に任せられる
AppHost でアプリケーションを起動出来て、Aspire Dashboard 経由でトレースも確認出来るようになると、次は画面の動作確認も AI にやってもらいたくなります。
Playwright CLI と AI を組み合わせると、AI にブラウザーを操作してもらうことが出来ます。Aspire で立ち上げたフロントエンドの画面を開いて、ボタンを押したり、フォームに入力したりして、想定した動きになっているかを確認してもらうといった使い方です。
今回のサンプルでは、Web アプリ側は WeatherApiClient で apiservice を呼び出しています。Playwright CLI の skill file が入っていれば、AI に「Weather ページを開いて、API から返ってきたデータが表示されているか確認して」と伝えるだけで、ブラウザーを操作して確認してくれます。AppHost から起動したアプリの URL を自分で探したり、Playwright のコマンドを自分で調べて書いたりする必要はありません。
実際に AI に確認してもらった画面は以下のようになります。ちゃんと Web アプリから API のデータが表示されています。
同じような用途で使えるものとして、Google が公開している chrome-devtools-mcp もあります。これは Chrome DevTools for Agents というもので、Chrome DevTools を介してブラウザーを操作したり観測したりするための MCP サーバーです。
自分は今のところ Playwright CLI を使うことが多いですが、Chrome DevTools を使って詳しく見たい場合には chrome-devtools-mcp も選択肢になると思います。
Aspire と Playwright CLI などを組み合わせることで、アプリケーションの起動、画面の動作確認、エラー時のトレース確認といった流れを AI に任せやすくなります。AI にアプリの起動方法を毎回細かく説明しなくてもよくなるので、自分としては気に入っています。
まとめ
ということで、Aspire の好きなところを書いてみました。
個人的には、ローカル開発で必要なものをまとめて起動出来るところと、OpenTelemetry ベースでアプリケーション全体の状態を見られるところが、Aspire の便利なところだと思っています。さらに、MCP サーバー経由でログやトレースを AI から参照出来るようになったことで、AI と一緒に開発するときの体験も良くなっていると思います。
アプリケーションの起動方法を説明するのではなく、AppHost を起動してもらえばよいというのはシンプルで良いです。Playwright CLI などと組み合わせると動作確認もお願いしやすいので、自分にとってはとても便利なものです。
それでは、良い Aspire ライフを！
Discussion