Azure Container Appsとは?特徴・料金・デプロイ手順とAKS・App Serviceの違い
Azure Container Appsは、Kubernetesの構築や運用を表に出さずにコンテナをサーバーレスで動かせるMicrosoft Azureのマネージドサービスです。クラスタの管理は不要で、トラフィックが無いときはレプリカをゼロまで縮小し、動いた分だけ課金されます。Dockerの仕組みを押さえていれば、そのイメージをほぼそのまま本番環境へ載せられます。この記事では、定義と構成要素、az CLIでのデプロイ手順、従量課金の料金体系、KEDAによる自動スケール、Container Apps Jobs、そしてAKS・App Service・Functionsとの使い分けまでを、検索でよく問われる順に整理します。
まとめ:Azure Container Appsの要点
- 正体はサーバーレスコンテナ基盤。KubernetesとKEDA・Dapr・Envoyの上に構築され、その運用はAzureが肩代わりする。
- ゼロスケール+従量課金。毎月180,000 vCPU秒・360,000 GiB秒・200万リクエストまで無料枠があり、アイドル時は割安なアイドル料金になる。
- デプロイは
az containerapp upで最短一発。ソースやイメージから環境ごと作成できる。 - スケールはKEDAベース。HTTP同時実行数やキュー長など70超のスケーラーでイベント駆動に増減する。
- 用途で使い分ける。細かいKubernetes制御が要るならAKS、単純なWebアプリだけならApp Service、常駐しない一括処理はContainer Apps Jobsが合う。
以下、それぞれの根拠と具体的な手順・数値を見ていきます。
Azure Container Appsとは(サーバーレスコンテナの実行基盤)
Azure Container Appsは、コンテナ化したアプリケーションを実行するためのフルマネージドなサーバーレス基盤です。内部ではKubernetesが動いていますが、ノードやコントロールプレーンといったクラスタ要素は一切見えず、利用者はコンテナイメージとスケール条件を指定するだけで済みます。HTTPで公開するWeb API、常駐するバックグラウンド処理、イベントで起動する非同期ワーカーなど、Kubernetesを直接触るほどの制御は要らないが単一コンテナ以上の運用がほしい領域を主な対象とします。
自動スケールにはKEDA、サービス間通信やステート管理にはDapr、HTTPルーティング基盤にはEnvoyといったオープンソースが組み込まれており、これらのバージョン追従やパッチ適用はプラットフォーム側で管理されます。利用者はアプリのコードとコンテナに集中でき、インフラの保守作業から解放される点が本質的な利点です。
環境・アプリ・リビジョンの構成(主要コンポーネント)
Azure Container Appsは3つの階層で構成されます。まず土台となるのが環境(Environment)で、同じ環境に置いたコンテナアプリはネットワーク境界とログ集約先(Log Analytics)を共有します。マイクロサービスのように相互通信するアプリ群は同一環境にまとめるのが基本です。
その中に置くコンテナアプリ(Container App)が1つのサービス単位で、デプロイのたびにリビジョン(Revision)という不変のスナップショットが作られます。旧リビジョンを残したままトラフィックを新旧へ配分できるため、Blue-Greenやカナリアリリースを追加ツールなしで実現できます。実際に処理を行うコンテナの実行単位がレプリカ(Replica)で、負荷に応じてこのレプリカ数が増減します。「container apps 環境 作成」で最初につまずくのはこの環境とアプリの関係で、環境を先に作ってからその中へアプリをデプロイする、と押さえておくと迷いません。
デプロイ手順(az containerappで最短公開)
もっとも手早いのはAzure CLIのaz containerapp upで、環境の作成からイメージのビルド・デプロイまでを一括で行えます。ローカルのソースコードから起こす場合は次のとおりです。
az login
az extension add --name containerapp --upgrade
az group create --name myResourceGroup --location japaneast
az containerapp up \
--name my-container-app \
--resource-group myResourceGroup \
--location japaneast \
--environment my-environment \
--source .
既存のコンテナイメージから、公開範囲やポートを明示して作成したい場合はaz containerapp createを使います。--ingress externalで外部公開、--target-portでコンテナの受信ポートを指定します。
az containerapp create \
--name my-container-app \
--resource-group myResourceGroup \
--environment my-environment \
--image mcr.microsoft.com/k8se/quickstart:latest \
--target-port 80 \
--ingress external \
--min-replicas 0 \
--max-replicas 5
ポータルやBicep、GitHub Actionsからのデプロイにも対応しますが、動作確認や初回検証はCLIが最短です。--min-replicas 0を指定すればアクセスが無い間はゼロまで縮み、課金を抑えられます。
料金モデル(従量課金の無料枠とDedicatedプラン)
プランは従量課金(Consumption)とDedicatedの2種類です。従量課金はサーバーレスで、割り当てたリソース量(vCPU秒・GiB秒)と受信HTTPリクエスト数に対して課金され、レプリカがゼロなら実行コストはかかりません。毎月最初の180,000 vCPU秒・360,000 GiB秒・200万リクエストが無料枠として提供されるため、小規模な検証や低トラフィックのアプリは無償の範囲に収まることも珍しくありません。最小レプリカを1以上にして常駐させた場合、レプリカがアイドル状態のときは割安な「アイドル料金」で計算されます(ゼロまで縮んでいる間の実行課金はかかりません)。1レプリカあたり最大4 vCPU・8 GiBまで使えます。
| 項目 | 従量課金 | Dedicated |
|---|---|---|
| 課金単位 | vCPU秒・GiB秒・リクエスト | ワークロードプロファイルのインスタンス |
| ゼロスケール | 可 | 可(プロファイル内アプリ) |
| 専有ハードウェア | 不可 | 可(分離・GPU選択可) |
| 向くケース | 変動負荷・低トラフィック | 安定した大規模・特殊コンピュート |
Dedicatedはワークロードプロファイル単位で専有ハードウェアを確保し、コンピュートの分離やGPU、コストの予測可能性が必要なときに選びます。安定して高いスループットが続くなら、従量課金よりDedicatedのほうが割安になる場合があります。単価は改定されるため、正確な金額は必ず公式の価格ページで確認してください。
KEDAによる自動スケール(ゼロスケールとイベント駆動)
Azure Container Appsの自動スケールはKEDA(Kubernetes Event-driven Autoscaling)を基盤にしており、CPUやメモリだけでなく外部イベントを起点にレプリカ数を増減できます。HTTPアプリなら同時実行リクエスト数、非同期処理ならService Busやストレージキューのメッセージ数、Kafkaのラグなど、70を超えるスケーラーから条件を選べます。最小レプリカを0にすればトラフィックが無い間はゼロまで縮み、キューにメッセージが積まれた瞬間に必要数だけ起動する、という動きが標準で実現します。
スケールルールは--min-replicas・--max-replicasと、KEDAスケーラーの定義で制御します。自動生成されたルールで意図しないスケールが起きる場合は、KEDAルールを手動で明示して調整します。ゼロスケールはコスト削減に有効な一方、久しぶりのアクセスでレプリカを起動するコールドスタートが発生するため、レイテンシが厳しいAPIでは最小レプリカを1以上に保つ判断も必要です。
Container Apps Jobs(バッチ・イベント駆動ジョブ)
常駐するサービスではなく、始まって終わる処理にはContainer Apps Jobsを使います。ジョブは、任意のタイミングで動かす手動実行、cron式で回すスケジュール実行、キューにメッセージが届いたときに起動するイベント駆動実行の3種類のトリガーに対応します。日次のバッチ集計、データ移行、キュー消費型のワーカーなどが典型的な用途です。
ジョブも従量課金で、実行に使ったvCPU秒・GiB秒に対してのみ課金されるため、動いていない時間のコストはかかりません。「azure container apps jobs 料金」で調べる際も、常駐アプリと同じ従量課金の考え方(実行分だけ)が適用されると理解しておけば見積もりを外しません。
AKS・App Service・Functionsとの違い(選定基準)
Azureのコンテナ・アプリ実行サービスは複数あり、制御の細かさと運用負荷のトレードオフで選び分けます。
| サービス | 抽象度 | ゼロスケール | 向く用途 |
|---|---|---|---|
| Container Apps | 高(K8s隠蔽) | 可 | マイクロサービス・イベント処理 |
| AKS | 低(K8s直接) | 要設定 | 細かい制御・既存K8s資産 |
| App Service | 高(PaaS) | 不可 | 常駐Webアプリ・単一サイト |
| Functions | 最高(FaaS) | 可 | 短命なイベント関数 |
| Container Instances | 中(単一実行) | — | 単発コンテナ・下位基盤 |
Kubernetesのマニフェストやオペレーターを直接扱いたい、既存のK8s資産があるならAKSです。逆にクラスタを一切運用したくなく、複数コンテナ・イベント駆動・ゼロスケールがほしいならContainer Appsが素直です。App Serviceは1つの常駐Webアプリを手早く載せるPaaSで、ゼロスケールやKEDAのイベント駆動は守備範囲外です。Functionsは関数単位の短命な処理に特化しますが、近年はContainer Apps上でFunctionsをホスティングする構成も選べます。Azure Container Instances(ACI)は単一コンテナを動かす下位サービスで、Ingressやリビジョン、自動スケールは持ちません。モノリスとマイクロサービスの違いを踏まえてサービス分割の粒度が決まっていると、この選定はぶれにくくなります。
セキュリティと運用(マネージドID・シークレット・ネットワーク)
認証情報をコードに埋め込まずに他のAzureリソースへアクセスするには、マネージドIDを割り当てます。これでキーの発行・失効管理から解放され、ロールベースアクセス制御(RBAC)で権限を絞れます。接続文字列やAPIキーはアプリのシークレットとして保存し、環境変数として参照させるか、Azure Key Vaultと連携させます。
ネットワーク面では、環境をカスタム仮想ネットワーク(VNet)に統合して内部限定の公開にしたり、Ingressで外部・内部の到達範囲を制御したりできます。Daprを有効にするとサービス間通信をmTLSで暗号化でき、「azureコンテナセキュリティ」で問われる通信の保護とアクセス管理を、アプリ側のコードを大きく変えずに担保できます。同じAzure上でAPIを束ねて公開・認可したい場合は、Azure API Managementを前段に置く構成も検討に値します。
導入前に確認したい向かないケースと2026年の最新機能
便利な反面、Azure Container Appsが最適でない場面もはっきりしています。ノードのカスタムカーネル設定、DaemonSetやカスタムオペレーター、特定のCNI構成といったKubernetesの低レイヤを細かく制御したいワークロードはAKSを選ぶべきです。また、常時高負荷で安定的にレプリカが張り付くようなアプリは、従量課金よりDedicatedプランや他サービスのほうがコスト効率で上回ることがあり、ゼロスケールの恩恵は薄くなります。単純に1枚の静的サイトや1つのWebアプリを載せるだけなら、Azure Static Web AppsやApp Serviceのほうが構成はシンプルです。ゼロスケール前提のAPIでコールドスタートのレイテンシが許容できない場合も、最小レプリカを1以上に固定するかApp Serviceを検討します。
機能面の進化も速く、2026年時点ではContainer Apps上でのネイティブなAzure Functionsホスティング、AI推論向けのサーバーレスGPU、無料のマネージドTLS証明書、起動を高速化するContainer Apps Sandboxesなどが順次提供されています。GPUソフトウェアスタックの更新ではCUDA互換性の検証が求められるなど、実行環境の前提が変わることもあるため、本番採用前の最新仕様は公式ドキュメントで確認してください。
よくある質問
Azure Container AppsとAKSの違いは何ですか?
AKSはKubernetesクラスタをそのまま管理・制御でき自由度が高い反面、ノードやアップグレードの運用負荷を負います。Container Appsはそのクラスタ運用をAzureが肩代わりするサーバーレス版で、細かいKubernetes制御が不要なマイクロサービスやイベント処理に向きます。
Azure Container AppsとApp Serviceの違いは何ですか?
App Serviceは常駐するWebアプリ向けのPaaSで、ゼロスケールやKEDAのイベント駆動は基本的に扱いません。App Serviceの仕組みや料金プランは、Azure App Serviceとは何かを解説した記事で詳しく確認できます。Container Appsは複数コンテナ・イベント駆動・ゼロ課金のスケールに対応し、非同期ワーカーやマイクロサービス構成に適します。
Azure Container Appsは無料で使えますか?
従量課金プランには毎月180,000 vCPU秒・360,000 GiB秒・200万リクエストの無料枠があり、低トラフィックの検証用途ならこの範囲に収まることがあります。無料枠を超えた分と、環境に付随する他リソース(ストレージやログ等)の料金は別途発生します。
Container Apps Jobsの料金はどう計算されますか?
ジョブは実行に使ったvCPU秒・GiB秒に対してのみ課金される従量課金で、動いていない時間のコストはかかりません。手動・スケジュール・イベント駆動のいずれのトリガーでも、この実行分課金の考え方は共通です。
Container Apps環境(Environment)とは何ですか?
複数のコンテナアプリをまとめて配置する境界で、同一環境のアプリはネットワークとログ集約先を共有します。相互通信するマイクロサービス群は同じ環境にまとめ、その中へ個々のアプリをデプロイするのが基本構成です。