# Azure Container Apps vs AKS vs App Service vs Functions vs ACI：Azureコンテナ基盤の選定ガイド

> Azureでコンテナ／アプリを動かす5つの選択肢——Container Apps・AKS・App Service・Functions・Container Instances——を、運用負荷・スケール・コスト・ロックインの観点で徹底比較。公式の位置づけに忠実に、どの要件でどれを選ぶかを意思決定フローと実例で解説します。

- 公開日: 2026-06-26
- 著者: 友田 陽大
- タグ: Azure, Container Apps, AKS, アーキテクチャ設計, コンテナ, サーバーレス, 技術選定, コスト最適化
- URL: https://tomodahinata.com/blog/azure-container-apps-vs-aks-app-service-functions-aci-decision-guide

## 要点

- 公式の位置づけは明快：汎用コンテナ／マイクロサービス／ジョブを『K8s運用なしで』動かすならContainer Apps、Kubernetes APIと制御面が要るならAKS、Web中心ならApp Service、関数モデルならFunctions、低レベルな単発コンテナならACI
- Container AppsはKubernetes・KEDA・Dapr・Envoyの上に建つが『Kubernetes APIは直接公開しない』。この割り切りが運用負荷を消す価値であり、CRD/Operator/DaemonSetが要るならAKSへ降りる
- 意思決定の軸は4つ：①Kubernetes APIが要るか ②Web専用か汎用コンテナか ③関数モデルが合うか ④スケール・証明書・リビジョンを自前で組みたくないか。迷ったらContainer Appsが既定解
- AWS経験者の対応表：ACA≈Fargate/App Runner、AKS≈EKS、ACI≈ECS単発タスク、Functions≈Lambda。クラウドが変わっても選定の軸は同型

---

「Azureでアプリを動かしたい。でも Container Apps・AKS・App Service・Functions・Container Instances……どれを選べばいいの？」——Azureのコンテナ／アプリ基盤は選択肢が多く、ここで止まる人がとても多い。**選定を間違えると、運用負荷もコストも数倍変わります**。

この記事は、[Microsoft Learnの公式比較ドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)に忠実に、5つの選択肢を**運用負荷・スケール・コスト・ロックイン**の軸で整理し、「どの要件でどれを選ぶか」を意思決定フローで示します。私はAWSで[サーバーレスコンテナ（Fargate）を本番運用](/blog/aws-ecs-fargate-production-guide)し、[221本のAPIを持つB2B SaaS](/case-studies/lumber-industry-dx)を運用してきました。その経験から言えるのは、**選定の軸はクラウドが変わっても同型**だということ。Azure Container Apps自体の本番運用は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) を参照してください。

---

## 結論：30秒で選ぶ

| あなたの要件 | 選ぶべき |
|------------|---------|
| 汎用コンテナ・マイクロサービス・ジョブを**K8s運用なし**で動かす | **Azure Container Apps** |
| **Kubernetes API・制御面**に直接アクセスしたい（CRD/Operator/DaemonSet） | **Azure Kubernetes Service (AKS)** |
| **Webサイト・WebAPI**中心（コードでもコンテナでも） | **Azure App Service** |
| **関数モデル**（トリガー＋バインディング）が合う | **Azure Functions** |
| スケール/LB/証明書を**自前で組む**低レベルな単発コンテナ | **Azure Container Instances (ACI)** |

> **迷ったら Azure Container Apps**。公式も `many teams prefer to start building container microservices with Azure Container Apps.` と述べています（[compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）。サーバー管理という最大のコスト（人件費）を消せるからです。

---

## 5つの選択肢：公式の位置づけ

### Azure Container Apps — サーバーレスのコンテナ／マイクロサービス基盤

> Azure Container Apps enables you to build serverless microservices and jobs based on containers.（— [compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）

特徴は、**Kubernetes・Dapr・KEDA・Envoyの上に建てられている**こと。サービス検出・トラフィック分割・イベント駆動スケール（ゼロスケール含む）・ジョブ・Azure Functions実行までをマネージドで提供します。そして決定的な割り切り——

> Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs. If you require access to the Kubernetes APIs and control plane, you should use Azure Kubernetes Service.

**Kubernetes APIを直接公開しない**。これは制約ではなく**価値**です。kubectlもCRDもHelmも要らない。Kubernetesの運用知識ゼロでも、Kubernetesのベストプラクティスに基づいたマネージド体験が得られる。

### Azure Kubernetes Service (AKS) — フルマネージドKubernetes

`AKS supports direct access to the Kubernetes API and can run any Kubernetes workload.`（[compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）。2つのモデルがあります。

- **AKS Standard**：クラスタは自分のサブスクリプションにあり、構成・運用は自分の責任。
- **AKS Automatic**：ノード管理・スケール・セキュリティ既定・アップグレードをAzureが事前構成・管理する、よりハンズオフな本番対応モデル。

**Kubernetesの制御面そのものが必要なら**——CRDでカスタムリソースを定義したい、Operatorを動かしたい、各ノードに1つ常駐させる`DaemonSet`が要る、特定のCNI/ストレージドライバを使いたい——AKSが正解です。

### Azure App Service — Webアプリ向けPaaS

`Azure App Service provides fully managed hosting for web applications including websites and web APIs.`（[compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）。コードでもコンテナでもデプロイでき、**Webアプリに最適化**されています。「単一のWebアプリ／APIを最短で公開したい」「マイクロサービスの群れではない」なら、App Serviceが最も素直。

### Azure Functions — サーバーレスFaaS

`Azure Functions is a serverless Functions-as-a-Service (FaaS) solution. It's optimized for running event-driven applications using the functions programming model.`（[compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）。トリガー（HTTP・キュー・タイマー）とバインディング（入出力を宣言的に接続）が生産性の核。**「イベントで関数を起動し、データソースにバインドする」**モデルが合うならFunctions。なお、**Azure FunctionsはContainer Apps環境上でも実行できます**（両者は排他ではない）。

### Azure Container Instances (ACI) — 低レベルな単発コンテナ

`It can be thought of as a lower-level "building block" option compared to Container Apps.`（[compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）。スケール・ロードバランシング・証明書は**提供されません**。

> For example, to scale to five container instances, you create five distinct container instances.（— [compare-options](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)）

「5インスタンスにしたければ5個を自分で作る」レベルの素材です。CI/CDのエフェメラルな処理、他サービス（AKSの仮想ノード等）から呼ぶ部品として使うのが定石。**アプリ運用の概念を自前で組みたい**ときだけACI。

---

## 比較表：4つの軸で並べる

| 軸 | Container Apps | AKS | App Service | Functions | ACI |
|----|:-:|:-:|:-:|:-:|:-:|
| **運用負荷** | 低（マネージド） | 高（K8s運用） | 低 | 低 | 中 |
| **K8s API** | ✕（隠蔽） | ◎（直接） | ✕ | ✕ | ✕ |
| **ゼロスケール** | ◎（HTTP/イベント） | △（KEDA自前導入） | △（プラン依存） | ◎ | ✕（単発） |
| **イベント駆動** | ◎（KEDA内蔵） | △（自前） | △ | ◎（トリガー） | ✕ |
| **マイクロサービス** | ◎（Dapr/サービス検出） | ◎（自由） | △ | △ | ✕ |
| **Web最適化** | ○ | ○ | ◎ | △ | △ |
| **証明書/LB自動** | ◎ | △（Ingress構築） | ◎ | ◎ | ✕ |
| **GPU** | ◎（サーバーレスGPU） | ◎ | ✕ | △ | ◎ |
| **学習コスト** | 低 | 高 | 低 | 中 | 低 |

---

## 意思決定フロー

```text
Q1. Kubernetes API・制御面（CRD/Operator/DaemonSet/独自CNI）が必要？
    └ YES → AKS（制御面が要るならここ一択）

Q2. 単一のWebサイト/WebAPIで、マイクロサービス群ではない？
    └ YES → App Service（Web最適化で最短）

Q3. 「イベントで起動する関数」モデルが素直に合う？
    └ YES → Azure Functions（トリガー＋バインディング）
       ※ Functions on Container Apps で ACA 環境に載せる選択肢もある

Q4. スケール/LB/証明書を自前で組みたい低レベルな単発処理？
    └ YES → ACI（CI/CDのエフェメラル処理など）

Q5. それ以外（汎用コンテナ・マイクロサービス・ジョブ・イベント駆動）
    └ → Azure Container Apps（既定解）
```

---

## 現場の判断軸：公式表に載らない3つの観点

### ① 運用負荷＝最大の隠れコスト

スタートアップや一人開発で、**AKSの運用（ノードのアップグレード、CNI/Ingress/証明書管理、CVE対応）に人を割けるか**——多くの場合、答えはNoです。AKSは強力ですが、運用に専任が要る。Container Appsは「Kubernetesの良さをマネージドで」得られるぶん、**少人数で本番品質を出すのに向く**。AKS Automaticはその差を縮めますが、それでも「制御面を握る＝責任を負う」点は変わりません。

> **指針**：Kubernetes APIが要る明確な理由が無いなら、Container Appsから始める。足りなくなったらAKSへ降りればいい（コンテナイメージはそのまま動く）。逆方向の「最初からAKSで作り込む」は、YAGNI違反になりがちです。

### ② ゼロスケールとコスト

間欠・低トラフィックなワークロード（社内ツール、Webhook受け口、不定期API）は、**Container Appsのゼロスケール＋無料枠**で原価が劇的に下がります（毎月18万vCPU秒・36万GiB秒・200万リクエストが無料）。App ServiceやAKSは「最低1インスタンスを常時起動」が現実的で、暇な時間も課金され続けます。**コストが意思決定に効く案件では、ここが分かれ目**になります。詳細は [コスト設計の章](/blog/azure-container-apps-production-guide)（本番運用ガイド）へ。

### ③ マイクロサービスならDaprとサービス検出

複数サービスが相互通信するマイクロサービス構成なら、Container Appsの**Dapr（サービス呼び出し・Pub/Sub・状態管理）とDNSベースのサービス検出**が効きます。AKSでも同じことはできますが、Service Mesh（Istio/Linkerd）の導入・運用が要る。Container Appsは**同じ環境内でアプリ名で呼べる**ので、認知負荷が低い。

---

## AWS経験者のための対応表

クラウドが変わっても、選定の軸は同型です。

| 役割 | AWS | Azure |
|------|-----|-------|
| サーバーレス・コンテナ | ECS on Fargate / App Runner | **Azure Container Apps** |
| マネージドKubernetes | EKS / EKS Auto Mode | AKS / AKS Automatic |
| Web向けPaaS | Elastic Beanstalk / App Runner | App Service |
| FaaS（関数） | Lambda | Azure Functions |
| 低レベル単発コンテナ | ECS RunTask / Fargate task | Azure Container Instances |

AWSで「迷ったらFargate」だったのと同じく、Azureでは「迷ったらContainer Apps」。ACA と Fargate の踏み込んだ違い（ゼロスケール・サーバーレスGPU・Spot・分離粒度）は、[Azure Container Apps vs AWS ECS on Fargate 徹底比較](/blog/azure-container-apps-vs-aws-ecs-fargate-serverless-container-comparison-guide) にまとめました。

---

## よくある誤解

- **「マイクロサービスならAKS一択」** → 違います。Kubernetes APIが要らないなら、Container AppsのほうがDapr/サービス検出/トラフィック分割が標準装備で速い。
- **「Container Appsは小規模専用」** → 違います。Dedicatedプロファイルで`D32`（32 vCPU/128 GiB）まで、最大1,000レプリカ。本番規模に耐えます。
- **「App ServiceとContainer Appsは同じ」** → 違います。App ServiceはWebアプリ最適化、Container Appsは汎用コンテナ＋イベント駆動＋ジョブ。マイクロサービスやキュー駆動ワーカーはContainer Appsの領分。
- **「FunctionsかContainer Appsか」は排他** → 違います。**Functions on Container Apps**で、関数をACA環境に載せられます。

---

## まとめ：制御面が要らないなら、迷わずContainer Apps

Azureのコンテナ／アプリ基盤は、**「Kubernetesの制御面が必要か」**で大きく二分されます。必要ならAKS、不要なら——汎用コンテナ・マイクロサービス・イベント駆動・ジョブなら——**Container Apps**が既定解です。Web専用ならApp Service、関数モデルならFunctions、低レベル単発ならACI。

選定で大事なのは「最も高機能なもの」ではなく「**要件に対して運用負荷が最小のもの**」を選ぶこと。一人×生成AIで速く・安く・安全に作るなら、まずContainer Appsで動かし、本当に制御面が要る部分だけAKSへ——という段階的な設計が、技術的負債を生みません。

Azureコンテナ基盤の選定から本番構築・AWSからの移行まで、ご相談は[お問い合わせ](/contact)へ。本番運用の詳細は [Azure Container Apps 本番運用ガイド](/blog/azure-container-apps-production-guide) をどうぞ。