Azure Container Apps × .NET Aspire の「Start Time」が更新されない／PowerShellで停止・起動できないときの決定版トラブルシューティング
.NET Aspire プロジェクトを azd（Azure Developer CLI）で何度も再デプロイしているのに、Aspire ダッシュボードの Start Time が古いまま変わらない。さらに PowerShell の Stop-AzContainerApp／Start-AzContainerApp が効かず、アプリの停止・起動ができない――本記事はこの2点を体系的に整理し、現場でそのまま使える確認手順、代替コマンド、根本理解、運用ベストプラクティスまでをまとめた実践的なガイドです。
目次
事象の要点
azdで Aspire 構成を複数回再デプロイしても、Aspire ダッシュボードの 「Start Time」 が更新されない。- PowerShell の
Stop-AzContainerApp -Name <app>でコンテナ アプリが停止・起動できない（応答が返らない、権限エラー、想定と異なる動作など）。
根本原因の理解：Aspire「Start Time」とリビジョンの関係
まず押さえるべきは、Azure Container Apps（以降 ACA）のリビジョンという概念です。azd deploy などの再デプロイは、同一アプリに新しいリビジョンを追加します（設定により Single/Multiple モード）。一般的な「再起動」ではなく、新しいテンプレートの世代を増やす動作です。
Aspire ダッシュボードの Start Time は多くのケースで、そのアプリ/サービスに最初に作成されたコンテナ インスタンスの開始時刻を表示します。つまり、再デプロイ（＝リビジョン追加）を繰り返しても「Start Time」は変わりません。実際の最新の起動タイミングを見たい場合は、アクティブなリビジョンの createdTime を参照するのが正解です。
最新の起動タイミングを正しく取得する（Azure CLI）
az containerapp revision list \
--name <app> \
--resource-group <rg> \
--query "[?properties.active==\`true\`].{Revision:name,StartTime:properties.createdTime}" \
-o table
アクティブ リビジョンが複数ある（Multiple モード）場合には、最も新しいリビジョンを 1 件に絞ります。
az containerapp revision list \
--name <app> \
--resource-group <rg> \
--query "max_by(@,&properties.createdTime).{Revision:name,StartTime:properties.createdTime}" \
-o table
補助的な確認：最新リビジョン名やレプリカの稼働
# アプリ全体の概要
az containerapp show \
--name <app> \
--resource-group <rg> \
--query "{LatestRevision:properties.latestRevisionName, Ingress:properties.configuration.ingress.external}"
# あるリビジョンのレプリカ一覧
az containerapp replica list
--name
--resource-group
--revision
# レプリカ詳細（イベントや状態）
az containerapp replica show
--name
--resource-group
--revision
--replica PowerShell がうまく動かないときの確実な対処
PowerShell の Stop-AzContainerApp／Start-AzContainerApp は便利ですが、モジュール バージョン、RBAC、サブスクリプション コンテキストなど、いくつかの前提を満たしていないと期待どおり動きません。焦らず切り分けましょう。
まずは Azure CLI で代替操作（最短・確実）
az login
az containerapp stop --name <app> --resource-group <rg>
az containerapp start --name <app> --resource-group <rg>
# どうしても止まらない個体がある場合
az containerapp restart --name <app> --resource-group <rg> </code></pre>
<p><code>restart</code> はランタイム再生成のため、<em>「停止→起動」がうまくいかない個体</em>に対しても実用的な回避策です。</p>
<h3>PowerShell が動かない典型原因とチェック方法</h3>
<table>
<thead>
<tr>
<th>症状</th>
<th>主な原因</th>
<th>確認コマンド</th>
<th>対処</th>
</tr>
</thead>
<tbody>
<tr>
<td>コマンドが見つからない／未定義</td>
<td><code>Az.ContainerApp</code> モジュールが古い</td>
<td><code>Get-Module -ListAvailable Az.ContainerApp</code></td>
<td><code>Update-Module Az</code> で更新。<br>※ <strong>2.0 以降</strong>で <code>Stop-AzContainerApp</code>/<code>Start-AzContainerApp</code> が利用可能</td>
</tr>
<tr>
<td>認可エラー（AuthorizationFailed）</td>
<td>RBAC 欠如（Contributor 未付与 など）</td>
<td><code>az role assignment list --assignee <your-oid or upn> --scope <rg-id></code></td>
<td>対象リソース グループに <strong>Contributor</strong> 以上、または適切な ACA ロールを付与</td>
</tr>
<tr>
<td>想定外のサブスクリプションに対して実行</td>
<td>コンテキストが違う</td>
<td><code>Get-AzContext</code> / <code>az account show</code></td>
<td><code>Set-AzContext -Subscription <id/name></code> で合わせる</td>
</tr>
<tr>
<td>Government/China クラウドで失敗</td>
<td>環境指定の不足</td>
<td>–</td>
<td><code>Connect-AzAccount -Environment AzureUSGovernment</code> 等、正しい環境でログイン</td>
</tr>
<tr>
<td>停止してもリクエストが流れる</td>
<td>Multiple モードで古いリビジョンがまだアクティブ</td>
<td><code>az containerapp revision list --query "[].{n:name,a:properties.active}"</code></td>
<td>不要なリビジョンを非アクティブ化／Single モードへ</td>
</tr>
<tr>
<td>コマンドは成功だが実際は止まらない</td>
<td>最小レプリカ数が > 0</td>
<td><code>az containerapp show --query "properties.template.scale.minReplicas"</code></td>
<td><code>az containerapp update --name <app> --resource-group <rg> --set "properties.template.scale.minReplicas=0"</code></td>
</tr>
</tbody>
</table>
<h3>PowerShell の基本コマンド例</h3>
<pre><code class="language-powershell"># ログイン＆サブスクリプション確認
Connect-AzAccount
Get-AzContext
# バージョン確認
Get-Module -ListAvailable Az.ContainerApp | Select-Object Name,Version
# 停止・起動（Az.ContainerApp 2.0+）
Stop-AzContainerApp -Name <app> -ResourceGroupName <rg>
Start-AzContainerApp -Name <app> -ResourceGroupName <rg>
# うまくいかない場合は CLI にフォールバック
az containerapp stop --name <app> --resource-group <rg>
az containerapp start --name <app> --resource-group <rg> </code></pre>
<h2>ツールを最新化して不具合を避ける</h2>
<pre><code class="language-powershell"># PowerShell（Az 全体を更新）
Update-Module Az
# 必要に応じて個別
Update-Module Az.Accounts
Update-Module Az.ContainerApp
</code></pre>
<pre><code># Azure CLI 本体
az upgrade
# Container Apps 拡張
az extension add -n containerapp --upgrade </code></pre>
<p>モジュール／拡張の古さが原因でコマンド未実装・互換性不整合が起こるケースは現場で非常に多いです。まずは最新化をルーチンにしましょう。</p>
<h2>「Start Time」表示を読み解くうえでの補足</h2>
<ul>
<li><strong>Start Time は初回のコンテナ起動時刻</strong>を指すため、リビジョンを重ねても更新されません。</li>
<li>最新の稼働状況は <strong>アクティブ リビジョンの <code>createdTime</code></strong> を確認するのが確実です。</li>
<li>ブラウザ キャッシュが影響して古い表示が残ることもあります。ハードリロードやキャッシュクリアで改善する場合があります。</li>
</ul>
<h2>再デプロイ時に起きていること（挙動の「見える化」）</h2>
<ol>
<li><code>azd deploy</code> はテンプレートの差分を適用し、ACA に新しい<strong>リビジョン</strong>を作成します。</li>
<li>Single モードなら既存トラフィックを新リビジョンへスイッチ。Multiple モードなら複数リビジョンが同時アクティブになり得ます。</li>
<li>ダッシュボードの <strong>Start Time</strong> は「最初に作成されたコンテナの開始時刻」のまま固定で見える場合があります。</li>
<li>実運用の把握には <strong>リビジョン視点</strong>（<code>createdTime</code>、レプリカの状態、トラフィック配分）で確認するのが正解です。</li>
</ol>
<h2>運用ベストプラクティス</h2>
<ul>
<li><strong>Single リビジョン モード</strong>の活用：トラフィックの切替が明確で、停止・起動の影響範囲が追いやすくなります。
<pre><code>az containerapp revision set-mode \
--name <app> \
--resource-group <rg> \
--mode Single
</code></pre>
</li>
<li><strong>最小レプリカ数（minReplicas）を 0 に設定</strong>しておく：コスト最適化と停止動作の明確化に有効。
<pre><code>az containerapp update \
--name <app> \
--resource-group <rg> \
--set "properties.template.scale.minReplicas=0"
</code></pre>
</li>
<li><strong>RBAC はリソース グループ単位</strong>で <em>Contributor</em> 以上を付与：運用のつまずきの多くは権限不足です。</li>
<li><strong>「停止→起動」に固執しない</strong>：困ったら <code>restart</code> を使う。<em>特定のレプリカの不整合</em>を一掃できます。
<pre><code>az containerapp restart --name <app> --resource-group <rg></code></pre>
</li>
<li><strong>デプロイ履歴は「リビジョン」で追う」</strong>：ロールバックや健全性確認もリビジョン中心で。</li>
</ul>
<h2>よくある誤解と正しい見方</h2>
<table>
<thead>
<tr>
<th>誤解</th>
<th>正しい見方</th>
<th>補足</th>
</tr>
</thead>
<tbody>
<tr>
<td>Start Time は「最新の起動時刻」</td>
<td>初回起動の時刻で固定的に見えることがある</td>
<td>最新はアクティブ リビジョンの <code>createdTime</code> を参照</td>
</tr>
<tr>
<td>停止できない＝コマンドの不具合</td>
<td>RBAC／コンテキスト／モジュールの古さが原因のことが多い</td>
<td>最初に CLI 代替で現象切り分けが有効</td>
</tr>
<tr>
<td>停止すれば完全に無停止</td>
<td>Multiple モードでは別リビジョンが生きている可能性</td>
<td>トラフィック配分とアクティブ状態を確認</td>
</tr>
</tbody>
</table>
<h2>現場でそのまま使える「ランブック」</h2>
<ol>
<li>Azure CLI と PowerShell モジュールを最新化（<code>az upgrade</code>／<code>Update-Module Az</code>）。</li>
<li><code>Get-AzContext</code>／<code>az account show</code> でサブスクリプション一致を確認。</li>
<li>RBAC を確認（対象リソース グループに Contributor 以上）。</li>
<li>ダッシュボードの表示が古い疑いがあればブラウザをハードリロード。</li>
<li>アクティブ リビジョンの <code>createdTime</code> を取得して「実際の最新起動」を把握。
<pre><code>az containerapp revision list \
--name <app> --resource-group <rg> \
--query "max_by(@,&properties.createdTime).{Revision:name,StartTime:properties.createdTime}" \
-o table
PowerShell で停止が効かない場合、まず CLI で停止/起動を実施。
az containerapp stop --name <app> --resource-group <rg>
az containerapp start --name <app> --resource-group <rg>動かないレプリカがある場合は restart。
az containerapp restart --name <app> --resource-group <rg>Multiple モードで不要なリビジョンが生きていないか確認し、必要に応じて Single へ。
az containerapp revision set-mode --name <app> --resource-group <rg> --mode Single最小レプリカ数（minReplicas）を 0 にし、停止動作を明確化。
それでも改善しない場合、リソース プロバイダーの操作履歴（アクティビティ ログ）やレプリカ イベントで原因追跡。
運用のためのスニペット集
最新アクティブ リビジョンの起動時刻を 1 行で取得（Bash）
az containerapp revision list \
--name <app> --resource-group <rg> \
--query "max_by(@,&properties.createdTime).properties.createdTime" -o tsv
最新リビジョン名を取得し、そのリビジョンだけを再起動
rev=$(az containerapp revision list \
--name <app> --resource-group <rg> \
--query "max_by(@,&properties.createdTime).name" -o tsv)
az containerapp revision restart
--name --resource-group
--revision $rev PowerShell：Az.ContainerApp 2.0+ で停止→起動
Stop-AzContainerApp -Name <app> -ResourceGroupName <rg>
Start-AzContainerApp -Name <app> -ResourceGroupName <rg>停止できないときの代替（スケール 0）
az containerapp update \
--name <app> --resource-group <rg> \
--set "properties.template.scale.minReplicas=0"
トラブルの再発防止チェックリスト
- CLI／PowerShell モジュール／拡張は最新か。
- サブスクリプションとテナントは合っているか。
- 対象リソース グループに Contributor 以上のロールがあるか。
- リビジョン モード（Single/Multiple）は目的に合っているか。
- minReplicas は 0（もしくは意図した値）か。
- ダッシュボードの Start Time ではなく、アクティブ リビジョンの
createdTimeで稼働を判断しているか。
FAQ
Q. Aspire ダッシュボードの Start Time が UTC でずれて見えます。 A. CLI が返す createdTime は UTC 基準です。ダッシュボードやローカルのタイムゾーン表示と食い違う場合があります。比較時はタイムゾーンを明示しましょう。 Q. 停止しているはずなのにアクセスできてしまいます。 A. Multiple モードで古いリビジョンがアクティブのまま、あるいはスロット的にトラフィックが残っている可能性があります。az containerapp revision list とトラフィック配分を確認してください。 Q. Stop/Start と Restart は何が違いますか？ A. Stop/Start はアプリ全体のライフサイクル操作、Restart はレプリカ/リビジョンの再生成に近い動作です。Stop/Start が失敗する場面でも Restart は効くことがあります。 Q. PowerShell と CLI のどちらを使うべき？ A. 自動化や運用標準に合わせれば良いですが、現象切り分けでは CLI の方がエラーメッセージが素直で、代替として有用です。
まとめ
「Start Time が更新されない」問題は不具合ではなく、表示の意味のギャップが原因であることがほとんどです。最新の稼働タイミングを掴むには、アクティブ リビジョンの createdTime を見る――これが正しい理解です。また、停止・起動の不調は多くがバージョン／RBAC／コンテキストに起因します。CLI での代替操作、restart の活用、Single モードと minReplicas の適正化を組み合わせれば、ほぼすべての現場で安定運用に近づけます。
実行コマンド早見表
| 目的 | コマンド |
|---|---|
| 最新の起動時刻（アクティブ リビジョン） | az containerapp revision list --name <app> --resource-group <rg> --query "max_by(@,&properties.createdTime).{Revision:name,StartTime:properties.createdTime}" -o table |
| 停止／起動（CLI） | az containerapp stop --name <app> --resource-group <rg> az containerapp start --name <app> --resource-group <rg> |
| 再起動（CLI） | az containerapp restart --name <app> --resource-group <rg> |
| 停止できない時の代替（スケール 0） | az containerapp update --name <app> --resource-group <rg> --set "properties.template.scale.minReplicas=0" |
| PowerShell で停止／起動 | Stop-AzContainerApp -Name <app> -ResourceGroupName <rg> Start-AzContainerApp -Name <app> -ResourceGroupName <rg> |
| リビジョン モードを Single に | az containerapp revision set-mode --name <app> --resource-group <rg> --mode Single |
| ツール更新 | Update-Module Az az upgrade az extension add -n containerapp --upgrade |
補足（細かな観点）
Stop-AzContainerApp/Start-AzContainerAppは Az.ContainerApp 2.0 以降で提供。まずはバージョン確認を。- Aspire ダッシュボードの表示が古い場合、ブラウザ キャッシュのクリアやハードリロードで改善することがあります。
- ヘルス プローブ／依存サイドカー（例：Dapr、OTEL、dotnet-monitor）の起動遅延が再デプロイ直後の稼働判断を難しくします。
replica showでイベントを確認すると原因に早く辿り着けます。 - ロールバックを多用する運用では、Single モード＋段階的トラフィック切替が障害波及を抑えやすいです。
以上で、Aspire ダッシュボードの Start Time と再デプロイの関係、そして PowerShell による停止・起動が効かない際の現実解（CLI 代替・restart・スケール 0・RBAC/コンテキストの見直し）を一通りカバーしました。この記事のコマンド群とランブックをチームの標準運用に組み込めば、トラブル発生時に迷う時間を大幅に削減できます。
コメント