Azure Container Apps トラブルシューティング：リビジョンFailed/Degraded・終了コード137・プローブ・イメージpull失敗の診断と対処

「デプロイしたのにアプリが起動しない」「動いていたのに突然落ちる」——本番運用で必ず直面する場面です。Azure Container Apps（ACA）は、症状から原因へたどる道筋が公式に整理されています。勘で再デプロイを繰り返すより、ログのメッセージを1つ読むほうが速い。

この記事は、Microsoft Learnの3つの公式トラブルシューティングガイド（起動失敗・イメージpull失敗・全体）に忠実に、症状別の診断と対処をまとめます。本番運用の前提知識は Azure Container Apps 本番運用ガイド を参照してください。

診断の入口：3つのツール

何が起きても、まずこの3つを見ます。

1. リビジョンとレプリカのRunning status（ポータル → Application → Revisions and replica）。FailedやDegradedならデプロイ失敗。
2. Log stream（ポータル → Monitoring → Log stream、Logsではない）。Console（アプリのstdout/stderr）とSystem（プラットフォーム事象）を切り替えて読む。
3. Diagnose and solve problems（設定不要の対話的診断。Availability and Performanceカテゴリなど）。

If the Log stream page says This revision is scaled to zero., select the Go to Revision Management button. Deploy a new revision scaled to a minimum replica count of 1.——ゼロスケール中はログが出ません。最小レプリカ1で再デプロイしてから観察します。

システムログ vs アプリログ

There are two kinds of logs, system and application logs. System logs show Azure Container Apps' platform activities, where application logs show what is logged to stdout and stderror.（— troubleshoot-container-start-failures）

切り分けが肝です。「プラットフォームが起動に失敗した（system）」のか「アプリが例外で落ちた（application）」のか。まずシステムログのメッセージを確認します。

症状①：終了コード137（OOMKilled）

最も多い「突然落ちる」原因がこれです。終了コード137＝メモリ超過でLinuxカーネルのOOM killerに殺された。

The Container Apps runtime can kill container that runs out of memory or CPU resources. Check system logs for out of memory (OOM) errors or throttling.（— troubleshoot-container-start-failures）

対処：

1. メモリ上限を上げる。ACAはCPU/メモリが固定ペア（メモリ=vCPU×2）なので、メモリを増やすにはvCPUも上げることになる。
2. メモリリークを調査する。徐々に増えて137で落ちるなら、上限を上げても延命にしかならない。Azure Monitorのメトリクスでメモリ使用の傾き（steady climb）を見る。
3. インメモリキャッシュをコンテナ外へ。「コンテナ内に状態を持たない」原則どおり、大きなキャッシュはRedisへ逃がす。

公式の指針：If an app tends to experience out of memory errors or get killed, increase its memory limit or investigate memory leaks in the application.

症状②：コンテナが即時終了する（exit code 0 / 非ゼロ）

起動した直後に終わる。原因は2系統です。

非ゼロ終了＝アプリのクラッシュ

If the container exited with a nonzero exit code, then an unhandled exception or error in your application code is often the problem.（— troubleshoot-container-start-failures）

未処理例外・依存欠落・設定ミス。アプリログでクラッシュ直前の例外を読む。docker run --rm <IMAGE>でローカル再現するのが最短です。

exit code 0 の即時終了＝entrypoint/CMD

If you overwrote the startup command or if your Dockerfile's entrypoint isn't launching the app correctly, the container could start and then immediately exit.

起動コマンドがサービスを起動せず終わっている。Node.jsならCMDがサーバーを起動しているか、Pythonなら常駐プロセスになっているかを確認。ポータルのEdit containerでcommand/argsを修正できます。

症状③：Provisioning/Processingのまま、またはDegraded

「いつまでも起動完了しない」「10分超でDegraded」は、ほぼプローブの設定ミスです。

Revision is degraded: A new revision takes more than 10 minutes to provision. It finally has a Provision status of Provisioned, but a Running status of Degraded. The Running status tooltip reads Details: Deployment Progress Deadline Exceeded. 0/1 replicas ready.（— troubleshooting）

原因と対処：

1. ターゲットポート不一致。ヘルスプローブ（TCP）のポートが、アプリの待受ポート＝Ingressターゲットポートと一致しているか。これが最頻出。
2. 起動が遅い（Java/JVM等）。initialDelaySecondsを伸ばす。既定のstartupプローブはfailureThreshold: 240（猶予240秒）だが、それでも足りないならプローブをカスタムする。
3. HTTPを話さないワーカーにHTTPプローブが付いている。Ingressを無効（または内部）にして、不要なHTTPプローブを外す。

参考：Ingress有効時の既定プローブ（公式）。

症状④：イメージpull失敗（ErrImagePull）

An image pull failure occurs when the Azure platform is unable to download (or pull) the container image that the application requires.（— troubleshoot-image-pull-failures）

主因と対処：

重要な最適化の罠：Image pull validation is only performed when the container image reference changes during an update. When you update your container app with the same image reference, the validation process is skipped.——同じイメージ参照での更新はpull検証がスキップされます。再検証したいなら、タグを変えて更新します（だからlatestの上書きは禁物）。

症状⑤：エンドポイントに繋がらない / 403

アプリは動いているのに外から繋がらない。Ingress設定を確認します（ネットワーク設計）。

403はネットワーク構成（IP制限・内部公開の誤り）を疑います。

症状⑥：スケールしない（Error fetching scaler metrics）

「キューが溜まっているのにレプリカが増えない」。システムログにError fetching scaler metricsが出ていれば、スケールの信号源（DB・Event Hub・別アプリ）に到達できていないサインです。

Ensure that your application can connect to the source of your scaling signal.（— troubleshoot-container-start-failures）

VNet・DNS・ファイアウォール・スケールルールの認証（マネージドIDのロール付与）を確認します。スケール設計そのものはKEDAオートスケールガイドへ。

横断的な原因：DNSとネットワーク

VNet統合環境のトラブルは、かなりの割合がDNSです。

Azure recursive resolvers uses the IP address 168.63.129.16 to resolve requests.（— troubleshooting）

• カスタムDNSを使うなら、未解決クエリを168.63.129.16へ転送。
• NSG／ファイアウォールで**168.63.129.16をブロックしない**。
• マネージドID利用時は**login.microsoft.com（または<REGION>.login.microsoft.com）への到達性**を確保。
• プライベートレジストリのFQDNを名前解決・到達できること。

UDR＋Firewallでegressを締めている環境では、これらを許可リストに入れ忘れると「イメージpull失敗」「スケーラー到達不可」「トークン取得失敗」が連鎖的に起きます。

環境を削除できない（ScheduledForDelete）

VNet統合環境がprovisioningState: ScheduledForDeleteのまま消えない——関連VNetが残っているのが原因です。

# 1) 環境が使うサブネット/VNetを特定
az containerapp env show --resource-group <RG> --name <ENV>   # infrastructureSubnetId を確認
# 2) VNetを手動削除 → 3) 環境を削除
az network vnet delete --resource-group <RG> --name <VNET>
az containerapp env delete --resource-group <RG> --name <ENV> --yes

CLIで「パラメータが無い」と言われたら

az containerappで謎の「missing parameters」エラーが出たら、拡張機能が古いだけのことが多い。

az extension add --name containerapp --upgrade
# プレビュー機能を使うなら
az extension add --name containerapp --upgrade --allow-preview true

診断フロー（まとめ）

起動しない / 落ちる
  ├─ Revisions and replica の Running status を見る
  │    Failed/Degraded → デプロイ失敗
  ├─ System log のメッセージで切り分け
  │    ErrImagePull        → 症状④（イメージpull）
  │    ContainerCrashing   → 症状②（exit code / アプリログ）
  │    Deadline Exceeded   → 症状③（プローブ／ポート）
  │    403                 → 症状⑤（Ingress/ネットワーク）
  │    scaler metrics      → 症状⑥（信号源到達／DNS）
  ├─ Application log で例外を読む（stdout/stderr）
  ├─ docker run --rm <IMAGE> でローカル再現
  └─ Diagnose and solve problems で対話的に絞る

まとめ

ACAのトラブルは、症状 → システムログのメッセージ → 原因という道筋が公式に整っています。覚えておくべき急所は——137はOOM、exit 0即時終了はentrypoint、Provisioningのまま／Degradedはプローブ＆ポート、ErrImagePullはタグ・AcrPull・ネットワーク、繋がらない/403はIngress、スケールしない＋VNetはDNS。勘で再デプロイを繰り返す前に、ログを1行読む——それが最速の復旧です。

本番運用での障害対応・可観測性設計・再発防止のご相談はお問い合わせへ。設計の全体像は Azure Container Apps 本番運用ガイド をどうぞ。