aspire run --no-build や aspire start --no-build の起動が思ったより遅い、と感じている .NET Aspire 利用者に関係する更新です。2026年5月21日公開・更新の公式情報として扱われている GitHub 上の microsoft/aspire PR「Optimize no-build AppHost project inspection」では、AppHost プロジェクトの MSBuild メタデータ検査を重複実行しないようにし、成功した検査結果をディスクキャッシュへ保存する変更が行われています。PRはGitHub上で2026年5月20日に main へマージ済みと表示されています。(GitHub)
結論から言うと、これは GitHub の画面やリポジトリ設定が変わる更新ではなく、Microsoft Aspire CLI の AppHost 起動処理を高速化するための変更です。特に、GitHub Actions、Codespaces、開発端末、セルフホストランナーなどで Aspire の AppHost を --no-build 付きで繰り返し起動しているチームは、CLI バージョン、キャッシュ設定、CI の実行条件を確認しておく価値があります。
何が変わったのか
今回の変更は、.NET Aspire の AppHost プロジェクトを起動する前に行われる「プロジェクト情報の検査」を最適化するものです。
従来は、aspire run --no-build でビルドを省略している場合でも、AppHost の検証、互換性チェック、CLI バンドル関連の判定、ユーザーシークレットの処理などで、同じ AppHost プロジェクトに対する MSBuild メタデータ評価が複数回走る可能性がありました。PRの説明では、この重複評価を避けるため、AppHost メタデータ解決を一元化し、1つの CLI プロセス内ではプロジェクトを一度だけ評価するようにしたと説明されています。(GitHub)
加えて、成功した検査結果はプロジェクト入力に基づくディスクキャッシュへ保存され、次回以降の CLI 実行で再利用できるようになります。キャッシュキーには、プロジェクトパス、プロジェクトファイル、restore assets file、一般的な Directory.Build / Directory.Packages 系のインポート、global.json、キャッシュスキーマバージョンなど、MSBuild 評価結果に影響する入力が含まれます。(GitHub)
| 観点 | 変更前 | 変更後 |
|---|---|---|
| AppHost メタデータ検査 | 同じ AppHost に対して複数回 MSBuild 評価が走る可能性があった | CLI プロセス内で解決処理を一元化 |
| 2回目以降の起動 | 再度 MSBuild 評価が必要になりやすい | 成功した検査結果をディスクキャッシュから再利用可能 |
| キャッシュ削除 | AppHost 情報キャッシュ専用の説明は限定的 | aspire cache clear で AppHost 情報キャッシュも削除 |
| キャッシュ無効化 | 環境変数ではなく設定経由で制御 | aspire config set dotnetAppHostInfoCacheDisabled true で無効化可能 |
対象になる利用者
この更新の中心にいるのは、GitHub を使っているすべての開発者ではなく、GitHub 上の microsoft/aspire リポジトリで管理されている .NET Aspire CLI を使い、AppHost プロジェクトを起動している開発者や管理者です。
特に影響を受けやすいのは、次のようなケースです。
| 利用シーン | 影響 |
|---|---|
ローカル開発で aspire run --no-build をよく使う | 2回目以降の起動待ち時間が短くなる可能性がある |
aspire start --no-build で AppHost をバックグラウンド起動している | 起動前の検査時間が削減される可能性がある |
| GitHub Actions で AppHost を起動して統合テストを行う | キャッシュが残る実行環境では恩恵が出る可能性がある |
| Codespaces や Dev Container で同じ AppHost を繰り返し起動する | 開発セッション中の再起動が軽くなる可能性がある |
| Aspire CLI のテンプレートや社内標準手順を管理している | キャッシュ設定やトラブルシュート手順の更新が必要になる可能性がある |
一方で、通常の GitHub リポジトリ管理、Issue、Pull Request、GitHub Actions の基本設定、GitHub Pages、Dependabot などに直接影響する変更ではありません。GitHub の管理画面で新しい設定を有効化する必要もありません。
背景にあった課題
関連する Issue #17197 では、aspire start / aspire run が --no-build 付きでも、AppHost が利用可能になるまで数秒かかる問題が整理されていました。ローカルの起動プロファイルでは、--no-build パスで合計 8.12 秒かかり、そのうち AppHost 起動前の MSBuild プロジェクトメタデータ検査が合計約 1.88 秒を占めていたと説明されています。(GitHub)
Issue では、同じプロジェクトに対してメタデータクエリが2回実行され、さらに AspireUseCliBundle の確認用プローブも別途実行されていたことが示されています。つまり、--no-build を指定していても、「ビルドしない」だけであり、起動前に必要なプロジェクト解析までは完全には省略されていなかった、というのが実態です。(GitHub)
この点は実務上かなり重要です。--no-build は「起動前のすべての処理を省く」オプションではありません。あくまでビルドや復元をスキップするための指定であり、AppHost として妥当か、CLI がどのように扱うべきかを判断する検査は残ります。今回の変更は、その残る検査処理を減らす方向の改善です。
AppHost メタデータ解決が一元化された
今回のPRでは、新たに AppHostInfoResolver が導入され、AppHost プロジェクト情報の解決処理が集約されています。Copilot のレビュー概要にも、MSBuild 検査をインメモリでまとめ、必要に応じて成功結果をディスクへ永続化する変更として整理されています。(GitHub)
これにより、以下の処理が同じ AppHost 情報を使えるようになります。
- AppHost プロジェクトの検証
- 互換性チェック
- CLI バンドルへの引き渡し
- isolated user-secrets cloning
- AppHost 関連の起動前判定
開発者目線では、内部構造の変更に見えますが、体感としては「同じ AppHost を何度も起動するときの待ち時間が減る」方向の改善です。特に、変更がない状態で --no-build を繰り返すワークフローでは効果が出やすくなります。
ディスクキャッシュの仕組みと注意点
ディスクキャッシュは、成功した AppHost 検査結果を次回以降の CLI 実行で再利用するためのものです。PRでは、キャッシュ書き込みにランダムな一時ファイルと atomic replace を使い、MSBuild 評価中にプロジェクトが編集された場合でも古いメタデータを新しいキーへ書き込まないよう、公開前にキャッシュキーを再確認すると説明されています。(GitHub)
実務では、次のように理解するとよいでしょう。
| 項目 | 実務での見方 |
|---|---|
| キャッシュ対象 | AppHost の検査結果。アプリ本体のビルド成果物ではない |
| 効果が出やすい場面 | 同じ AppHost を、入力ファイル変更なしで繰り返し起動する場面 |
| 効果が出にくい場面 | 毎回クリーンな CI ランナーを使う、毎回プロジェクトファイルが変わる、通常ビルドの時間が支配的な場面 |
| 無効化方法 | Aspire CLI の config 経由で無効化 |
| 削除方法 | aspire cache clear で削除 |
ここで誤解しやすいのは、キャッシュが有効になっても --no-build の前提は変わらない点です。--no-build を使う場合、AppHost がすでにビルド済みであることや、実行に必要な成果物が揃っていることは引き続き重要です。AppHost 情報キャッシュは、古い DLL や不足した成果物を補完するものではありません。
パフォーマンス面で期待できる効果
PR内の検証では、更新通知を無効化した起動プロファイルで、ウォームディスクキャッシュ時に AppHost inspection MSBuild が 0 回となり、find_apphost が約 700ms から 23.7ms へ短縮された結果が示されています。また、CLI command minus 8s capture delay の値は、キャッシュ無効時 5.81 秒、コールドディスクキャッシュ 4.79 秒、ウォームディスクキャッシュ 3.81 秒とされています。(GitHub)
ただし、この数値をそのまま自社環境に当てはめるのは避けるべきです。実際の効果は、プロジェクト規模、MSBuild の設定、依存関係、端末性能、CI ランナーのキャッシュ保持状況によって変わります。
判断基準としては、次のように見ると実務的です。
| 状況 | 期待値 |
|---|---|
| 同じ AppHost をローカルで何度も起動する | 体感差が出る可能性が高い |
| セルフホスト GitHub Actions ランナーで同じワークスペースを使う | キャッシュが残れば効果が出る可能性がある |
| GitHub-hosted runner のように毎回クリーンな環境を使う | ウォームキャッシュ効果は限定的 |
| AppHost 起動後のリソース初期化が遅い | 今回の変更だけでは大きく改善しない可能性がある |
通常の aspire run でビルド時間が支配的 | --no-build 最適化の効果は見えにくい |
管理者・開発者が確認すべきポイント
Aspire CLI のバージョンと取り込み状況を確認する
PRは main にマージされていますが、利用中の Aspire CLI にこの変更が含まれているかは、実際に使っているリリースやインストールチャネル次第です。Issue #17197 には milestone として 13.4 が表示されていますが、実運用ではリリースノートやCLIバージョンを確認してから判断してください。(GitHub)
チームで確認すべきことは次の3つです。
- 開発端末、Codespaces、Dev Container、CI で使っている Aspire CLI のバージョン
aspireのインストール方法が固定バージョンか、チャネル追従か- GitHub Actions のワークフローで CLI を都度インストールしているか、キャッシュしているか
特に CI では、ローカルと同じバージョンを使っていると思い込まないことが重要です。バージョン差があると、ローカルでは速くなったのに Actions では変わらない、という状況が起きます。
--no-build の使い方を見直す
--no-build は、ビルド済みの AppHost を前提に起動する場面で有効です。たとえば、CI で先に dotnet build を実行し、その後に Aspire AppHost を起動してテストする場合には相性がよい指定です。
一方、ローカル開発でコード変更直後に --no-build を使うと、変更が反映されないまま起動する可能性があります。今回の変更は --no-build を安全にするものではなく、--no-build 時の起動前検査を効率化するものです。
CI では、次のように「ビルド」と「起動」を明確に分けるとトラブルを減らせます。
dotnet build ./src/MyApp.AppHost/MyApp.AppHost.csproj --configuration Release
aspire start \
--apphost ./src/MyApp.AppHost/MyApp.AppHost.csproj \
--no-build \
--non-interactiveテスト終了後に停止処理を入れる場合は、チームの運用に合わせて aspire stop を組み合わせます。Aspire CLI の概要では、aspire run は AppHost を開発モードで実行し、aspire start は AppHost をバックグラウンドで開始するコマンドとして説明されています。(Microsoft Learn)
キャッシュを無効化する設定を把握する
ディスクキャッシュは、必要に応じて次のコマンドで無効化できます。
aspire config set dotnetAppHostInfoCacheDisabled truePRでは、このトグルは環境変数ではなく、Aspire の config files / global config を通じて読み取られると説明されています。つまり、環境変数を追加しても無効化できるとは限りません。(GitHub)
Aspire CLI の config コマンドは、設定値の list、get、set、delete を扱うコマンドです。また、Aspire 13.2 以降では、プロジェクトスコープの設定にルートの aspire.config.json を優先し、ユーザースコープのグローバル既定値も扱えると説明されています。(Microsoft Learn)
実務では、次のように使い分けるのが安全です。
| 設定方針 | 適した場面 |
|---|---|
| 個人環境だけで無効化 | キャッシュ起因かどうかを一時的に切り分けたい |
| プロジェクト設定として無効化 | チーム全体で再現性を優先し、キャッシュを使わない方針にする |
| グローバル設定で無効化 | 開発者個人が複数リポジトリで一律に無効化したい |
| 無効化しない | 通常の開発・CIで速度を優先したい |
なお、PRではディスクキャッシュを無効化しても、1つの CLI 呼び出し内でのインメモリ coalescing は残ると説明されています。そのため、無効化したからといって完全に旧来の重複 MSBuild 検査へ戻るわけではありません。(GitHub)
トラブル時は aspire cache clear を試す
AppHost の検査結果がおかしい、設定変更後も挙動が変わらない、バージョン更新後に不自然な起動エラーが出る、といった場合は、まずキャッシュ削除を試すのが現実的です。
aspire cache clearPRでは、aspire cache clear によって AppHost info cache が削除されると説明されています。Aspire CLI の公式ドキュメントでも、aspire cache は Aspire CLI のディスクキャッシュを管理するコマンドであり、aspire cache clear はトラブルシュート、ディスク容量の解放、CLI更新後に新しいデータを確実に使う場合に役立つと説明されています。(GitHub)
ただし、aspire cache clear は AppHost 情報だけでなく、Aspire CLI が保持する他のキャッシュも削除する可能性があります。CI で実行する場合は、テンプレートや NuGet 関連の再取得により、次回実行が一時的に遅くなることも考慮してください。
GitHub Actions での確認ポイント
GitHub Actions で Aspire AppHost を使っている場合、今回の変更は「Actions の設定を必ず変えるべき」という話ではありません。まずは、どこに待ち時間があるかを測ることが先です。
確認すべきポイントは次のとおりです。
| 確認項目 | 見るべきこと |
|---|---|
| ランナー種別 | GitHub-hosted runner か、セルフホストランナーか |
| ワークスペースの扱い | 毎回クリーンか、キャッシュや作業ディレクトリが残るか |
| CLI インストール | 毎回インストールか、固定バージョンか、チャネル追従か |
| AppHost 起動方法 | aspire run か aspire start か、--no-build を使っているか |
| 事前ビルド | dotnet build が明示されているか |
| キャッシュ戦略 | Aspire CLI cache を残す必要があるか、毎回クリアする方針か |
GitHub-hosted runner のように毎回クリーンな環境では、ウォームディスクキャッシュの恩恵は限定的です。逆に、セルフホストランナーや開発用の Codespaces では、同じ AppHost を繰り返し起動するため、効果が見えやすくなります。
ただし、速度改善だけを目的に CI のキャッシュ設定を複雑にしすぎるのは避けるべきです。まずは現状の起動時間を測り、AppHost 検査がボトルネックになっている場合だけ、キャッシュ保持を検討するとよいでしょう。
移行作業は必要か
アプリケーションコードの移行は、基本的には不要です。今回の変更は Aspire CLI の内部処理に関するものであり、AppHost の C# コードやリソース定義を変更する必要はありません。
ただし、次のようなチームでは、手順書やCI設定の見直しをおすすめします。
| チームの状況 | 見直す内容 |
|---|---|
| Aspire CLI のバージョンを固定している | PRを含むバージョンへ上げるタイミングを決める |
--no-build を CI で使っている | 事前ビルドが確実に実行されているか確認する |
| キャッシュを毎回削除している | 起動速度を優先するなら削除頻度を見直す |
| 社内テンプレートを配布している | aspire cache clear とキャッシュ無効化手順を追記する |
| 独自の MSBuild props/targets で AppHost 情報を変えている | キャッシュ無効化やキャッシュクリアで挙動確認する |
特に注意したいのは、独自の MSBuild 設定を多用しているプロジェクトです。PRではキャッシュキーに、プロジェクトファイル、restore assets file、一般的な Directory.Build / Directory.Packages 系インポート、global.json などが含まれると説明されています。標準的な構成であれば問題になりにくい一方、生成ファイルや独自インポートで AppHost の評価結果を変える構成では、更新後にキャッシュの無効化タイミングを確認しておくと安心です。(GitHub)
切り分けに使える実用コマンド
更新前後の効果を見るなら、同じ条件で複数回起動して比較します。1回目はコールドキャッシュ、2回目以降はウォームキャッシュになりやすいため、最初の1回だけで判断しないことが重要です。
# AppHost を事前ビルド
dotnet build ./src/MyApp.AppHost/MyApp.AppHost.csproj
# キャッシュを削除してコールド状態を作る
aspire cache clear
# 1回目: コールドキャッシュで確認
time aspire start \
--apphost ./src/MyApp.AppHost/MyApp.AppHost.csproj \
--no-build \
--non-interactive
aspire stop --all --non-interactive
# 2回目: ウォームキャッシュで確認
time aspire start \
--apphost ./src/MyApp.AppHost/MyApp.AppHost.csproj \
--no-build \
--non-interactive
aspire stop --all --non-interactiveキャッシュが原因かどうかを切り分けたい場合は、一時的に無効化して比較します。
aspire config set dotnetAppHostInfoCacheDisabled true再び有効化したい場合は、設定方針に応じて false を設定するか、設定を削除します。
aspire config set dotnetAppHostInfoCacheDisabled falseチームで共有する手順書には、「キャッシュを消す」「キャッシュを無効化する」「CLIバージョンを確認する」の3つをセットで書いておくと、トラブル時の問い合わせを減らせます。
失敗しやすいポイント
--no-build を付ければ常に速くなると思い込む
--no-build はビルドを省略する指定です。ビルド済み成果物が古ければ、古い状態で起動します。今回の変更で AppHost 検査は軽くなりますが、アプリ本体のビルド整合性までは保証しません。
環境変数でキャッシュを無効化しようとする
PRでは、キャッシュ無効化トグルは環境変数ではなく Aspire config files / global config から読まれると説明されています。CI で環境変数だけを設定しても、期待した効果が出ない可能性があります。(GitHub)
キャッシュ削除を毎回入れてしまう
aspire cache clear はトラブルシュートには有効ですが、毎回実行するとディスクキャッシュの利点を消してしまいます。CI の先頭に無条件で入れるのではなく、問題が起きたときの切り分け手順として使うのが基本です。
GitHub の機能変更と誤解する
今回の情報は GitHub 上で公開・更新された公式PRに関する内容ですが、GitHub の管理画面、Pull Request の仕様、Actions のランナー仕様が変わる話ではありません。実体は Microsoft Aspire CLI の AppHost 検査最適化です。
今回の更新で取るべき行動
まず、自分たちのリポジトリで Aspire AppHost を使っているかを確認してください。使っていない場合、この更新による実務上の影響はほぼありません。
使っている場合は、次の順で確認すると無駄がありません。
| 優先度 | やること | 目的 |
|---|---|---|
| 高 | Aspire CLI のバージョンとリリース取り込み状況を確認する | 変更が実際に利用環境へ入っているか判断する |
| 高 | aspire run/start --no-build の利用有無を確認する | 影響範囲を絞る |
| 中 | コールドキャッシュとウォームキャッシュで起動時間を測る | 効果を実測する |
| 中 | CI のランナー種別とキャッシュ方針を確認する | Actions で効果が出るか判断する |
| 低 | キャッシュ無効化・削除手順を手順書に追記する | トラブルシュートを標準化する |
今回の「Optimize no-build AppHost project inspection」は、派手な新機能ではありません。しかし、--no-build を使って AppHost を何度も起動する開発現場では、待ち時間を少しずつ削る実用的な改善です。管理者は CLI バージョンと CI のキャッシュ方針を確認し、開発者は --no-build の前提とキャッシュの切り分け方法を押さえておくと、更新後の効果を安全に取り込めます。
コメント