「Azureでアプリを動かしたい。でも Container Apps・AKS・App Service・Functions・Container Instances……どれを選べばいいの？」——Azureのコンテナ／アプリ基盤は選択肢が多く、ここで止まる人がとても多い。選定を間違えると、運用負荷もコストも数倍変わります。
この記事は、Microsoft Learnの公式比較ドキュメントに忠実に、5つの選択肢を運用負荷・スケール・コスト・ロックインの軸で整理し、「どの要件でどれを選ぶか」を意思決定フローで示します。私はAWSでサーバーレスコンテナ（Fargate）を本番運用し、221本のAPIを持つB2B SaaSを運用してきました。その経験から言えるのは、選定の軸はクラウドが変わっても同型だということ。Azure Container Apps自体の本番運用は Azure Container Apps 本番運用ガイド を参照してください。
結論：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）。サーバー管理という最大のコスト（人件費）を消せるからです。
5つの選択肢：公式の位置づけ
Azure Container Apps — サーバーレスのコンテナ／マイクロサービス基盤
Azure Container Apps enables you to build serverless microservices and jobs based on containers.（— 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）。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）。コードでもコンテナでもデプロイでき、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）。トリガー（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）。スケール・ロードバランシング・証明書は提供されません。
For example, to scale to five container instances, you create five distinct container instances.（— 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） | ◎ | ✕ | △ | ◎ |
| 学習コスト | 低 | 高 | 低 | 中 | 低 |
意思決定フロー
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インスタンスを常時起動」が現実的で、暇な時間も課金され続けます。コストが意思決定に効く案件では、ここが分かれ目になります。詳細は コスト設計の章（本番運用ガイド）へ。
③ マイクロサービスなら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 徹底比較 にまとめました。
よくある誤解
- 「マイクロサービスなら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からの移行まで、ご相談はお問い合わせへ。本番運用の詳細は Azure Container Apps 本番運用ガイド をどうぞ。