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

> Azure Container Appsが起動しない・落ちるときの診断と対処を体系化。リビジョンのFailed/Degraded、終了コード137（OOMKilled）、コンテナ即時終了、ヘルスプローブ失敗、イメージpull失敗、403/接続不可、DNS（168.63.129.16）、スケーラー到達不可までを、システムログのメッセージ別にMicrosoft Learn公式に忠実な手順で解説します。

- 公開日: 2026-06-26
- 著者: 友田 陽大
- タグ: Azure, Container Apps, トラブルシューティング, 可観測性, 信頼性, デバッグ, インフラ, コンテナ
- URL: https://tomodahinata.com/blog/azure-container-apps-troubleshooting-revision-failed-exit-code-137-probes-guide

## 要点

- まず『リビジョンとレプリカ』のRunning statusを見る。Failed/Degradedはデプロイ失敗のサイン。次にシステムログ（プラットフォーム事象）とアプリログ（stdout/stderr）を切り分けて読む
- 終了コード137＝OOMKilled（メモリ超過でカーネルがkill）。メモリ上限を上げるかリークを調査する。終了コード0の即時終了はentrypoint/CMDがサービスを起動できていない
- 『Provisioning/Processingのまま』『10分超でDegraded（Deployment Progress Deadline Exceeded. 0/1 replicas ready）』はほぼプローブ設定ミス。ターゲットポート一致と起動猶予を見直す
- イメージpull失敗の主因はタグ誤り・認証情報不足・AcrPullロール未付与・ネットワーク遮断。画像参照が変わったときだけpull検証が走る点に注意
- VNet統合時はDNSが要注意：カスタムDNSは未解決クエリを168.63.129.16へ転送し、login.microsoft.comとレジストリFQDNをブロックしない。Diagnose and solve problemsとLog streamが一次診断の入口

---

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

この記事は、Microsoft Learnの3つの公式トラブルシューティングガイド（[起動失敗](https://learn.microsoft.com/en-us/azure/container-apps/troubleshoot-container-start-failures)・[イメージpull失敗](https://learn.microsoft.com/en-us/azure/container-apps/troubleshoot-image-pull-failures)・[全体](https://learn.microsoft.com/en-us/azure/container-apps/troubleshooting)）に忠実に、**症状別の診断と対処**をまとめます。本番運用の前提知識は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) を参照してください。

---

## 診断の入口：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](https://learn.microsoft.com/en-us/azure/container-apps/troubleshoot-container-start-failures)）

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

| システムログのメッセージ | 意味 |
|----------------------|-----|
| `ErrImagePull` | イメージのpull失敗（不在・参照誤り・認証） |
| `Time-out` | 起動が長すぎる／コンテナ内の問題 |
| `ContainerCrashing` | コンテナが繰り返しクラッシュ |
| `ingress routes not ready` | Ingressルートが準備できずレプリカ失敗 |
| `Deployment Progress Deadline Exceeded. 0/1 replicas ready.` | 進捗期限超過。起動かヘルスチェックの問題 |
| `Requests return status 403` | アクセス拒否。ネットワーク構成の疑い |
| `Error fetching scaler metrics` | スケール信号源に到達できていない |

---

## 症状①：終了コード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](https://learn.microsoft.com/en-us/azure/container-apps/troubleshoot-container-start-failures)）

**対処**：

1. **メモリ上限を上げる**。ACAは[CPU/メモリが固定ペア](/blog/azure-container-apps-production-guide)（メモリ=vCPU×2）なので、メモリを増やすにはvCPUも上げることになる。
2. **メモリリークを調査**する。徐々に増えて137で落ちるなら、上限を上げても延命にしかならない。Azure Monitorのメトリクスでメモリ使用の傾き（steady climb）を見る。
3. **インメモリキャッシュをコンテナ外へ**。[「コンテナ内に状態を持たない」](/blog/azure-container-apps-production-guide)原則どおり、大きなキャッシュは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](https://learn.microsoft.com/en-us/azure/container-apps/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](https://learn.microsoft.com/en-us/azure/container-apps/troubleshooting)）

原因と対処：

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

参考：Ingress有効時の既定プローブ（[公式](https://learn.microsoft.com/en-us/azure/container-apps/troubleshooting)）。

| プロパティ | Startup | Readiness |
|----------|---------|-----------|
| プロトコル | TCP | TCP |
| ポート | Ingressターゲットポート | Ingressターゲットポート |
| Initial delay | 1秒 | 3秒 |
| Failure threshold | 240 | 48 |

---

## 症状④：イメージ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](https://learn.microsoft.com/en-us/azure/container-apps/troubleshoot-image-pull-failures)）

主因と対処：

| 原因 | 対処 |
|------|-----|
| **イメージ名／タグ誤り** | 正確な名前・タグを確認。`docker pull <IMAGE>`で手元検証 |
| **認証情報不足（プライベートレジストリ）** | 資格情報が正しく・期限切れでないか。**ACRなら`AcrPull`ロールがマネージドIDに付いているか** |
| **ネットワーク遮断** | 環境からレジストリFQDNへ到達できるか。DNS・NSG・ファイアウォールを確認 |
| **レート制限**（Docker Hub等） | 数分待つ。ACRなど十分なクォータのレジストリを使う |

> 重要な最適化の罠：`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設定を確認します（[ネットワーク設計](/blog/azure-container-apps-networking-vnet-private-endpoint-waf-egress-guide)）。

| 確認 | アクション |
|------|----------|
| Ingressは有効か | *Enabled*にチェック |
| 外部公開したいか | *Ingress Traffic*を*Accepting traffic from anywhere*に。HTTPを話さないなら*Limited to Container Apps Environment* |
| プロトコル | *Ingress type*がHTTP/TCPで正しいか |
| ターゲットポート | アプリの待受ポートと一致しているか |
| IP制限 | *IP Security Restrictions*でクライアントIPが拒否されていないか |

`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](https://learn.microsoft.com/en-us/azure/container-apps/troubleshoot-container-start-failures)）

VNet・DNS・ファイアウォール・スケールルールの認証（マネージドIDのロール付与）を確認します。スケール設計そのものは[KEDAオートスケールガイド](/blog/azure-container-apps-keda-autoscaling-scale-to-zero-event-driven-guide)へ。

---

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

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

> Azure recursive resolvers uses the IP address `168.63.129.16` to resolve requests.（— [troubleshooting](https://learn.microsoft.com/en-us/azure/container-apps/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が残っている**のが原因です。

```azurecli
# 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」エラーが出たら、**拡張機能が古い**だけのことが多い。

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

---

## 診断フロー（まとめ）

```text
起動しない / 落ちる
  ├─ 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行読む——それが最速の復旧です。

本番運用での障害対応・可観測性設計・再発防止のご相談は[お問い合わせ](/contact)へ。設計の全体像は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) をどうぞ。