Azure Container Appsとは？できること・App Service/AKSとの選び分け・Terraform構築まで徹底解説

コンテナでアプリを動かしたいけれど、「AKS（Kubernetes）はちょっと大げさかも…」と感じたことはありませんか？

と悩んでいるエンジニアの方も多いのではないでしょうか。

そのモヤモヤに応えてくれるのが、今回紹介する Azure Container Apps（コンテナー アプリ） です。

Azure Container Apps（以下ACA）は、Kubernetesの複雑さを隠しつつ、コンテナを手軽に動かせるフルマネージドのサービスです。ノードの管理も、YAMLの山と格闘する必要もありません。それでいて、ゼロへのスケールイン（＝アイドル時は料金ゼロ）やマイクロサービス構成にも対応できる、非常にバランスの良い選択肢です。

この記事では、Azure Container Appsの基本概念から、できること・使いどころ、App ServiceやAKSとの選び分け、そしてTerraform（IaC）による構築のポイントまで、実務目線でわかりやすく解説します。

読み終わるころには、「このワークロードはACAで行こう」と自信を持って判断できるようになっているはずです。

Azure Container Apps とは？

Azure Container Appsとは、サーバーレスでコンテナを実行できるフルマネージドサービスです。裏側ではKubernetesが動いていますが、その運用（コントロールプレーンやノードの管理）はすべてAzureが肩代わりしてくれます。私たちは「動かしたいコンテナイメージ」と「どう動かしたいか」を指定するだけで済みます。

例えるなら、こういうイメージです。

• AKS（自前でKubernetes）：自分でキッチンを一式借りて、火加減も食材の仕入れも全部やる「本格レストラン」。自由度は最高だが、運用の手間も最大。
• Container Apps：食材（コンテナ）を渡せば、調理場の管理は全部やってくれる「シェアキッチン」。自分は料理（アプリ）に集中できる。
• App Service：メニュー（対応言語・ランタイム）が決まっている「定食屋」。手軽だがコンテナの自由度はACAに一歩譲る。

ACAの裏側では、Kubernetes に加えて、オープンソースのイベント駆動オートスケーラー KEDA、サービスメッシュの Dapr、L7ルーティングの Envoy といった実績あるOSS群が組み合わさっています。これらの難しい部分を全部隠して、いいとこ取りだけを使わせてくれるのがACAの本質です。

Azure Container Apps でできること

ACAが得意とすることを、実務でよく使う機能に絞って整理します。

1. ゼロへのスケール（Scale to Zero）

ACA最大の魅力がこれです。アクセスが無いときはレプリカ数を0まで減らし、その間の課金を止められます。アクセスが来た瞬間に自動で起動するので、常時起動していないバッチ処理や、アクセスがまばらな社内ツール、検証環境などでコストを大幅に削減できます。

2. イベント駆動のオートスケール（KEDA）

HTTPリクエスト数はもちろん、Service Busのキュー溜まり具合やCPU/メモリ使用率など、さまざまなトリガーでレプリカ数を自動増減できます。「キューにメッセージが溜まったらワーカーを増やす」といった処理が、YAMLを書かずに設定だけで実現できます。

3. リビジョンによる安全なリリース

ACAはデプロイのたびにリビジョンという不変のスナップショットを作ります。新旧リビジョンにトラフィックを「80%：20%」のように配分できるため、Blue-Greenデプロイやカナリアリリースが標準機能で実現できます。問題があればトラフィックを旧リビジョンに戻すだけで即ロールバックできます。

4. マイクロサービス連携（Dapr）

Daprを有効にすると、サービス間通信・状態管理・Pub/Subといったマイクロサービスに必要な機能を、アプリのコードを汚さずに利用できます。複数のコンテナアプリを組み合わせて1つのシステムを作る、といった構成に向いています。

5. HTTPS標準対応と組み込みIngress

Ingress（Envoyベース）が組み込まれており、有効化するだけで https://<アプリ名>.<環境名>.<リージョン>.azurecontainerapps.io のような公開URLと証明書が自動で払い出されます。ロードバランサーや証明書の準備に頭を悩ませる必要がありません。

App Service・AKSとの選び分け

ここが実務で一番悩むポイントであり、この記事の核心です。3つのサービスをコンテナ実行という観点で比較すると、次のようになります。

観点	App Service	Container Apps	AKS
運用の手間	小	小〜中	大
コンテナの自由度	中	高	最高
ゼロへのスケール	不可	可	工夫が必要
Kubernetes知識	不要	ほぼ不要	必須
マイクロサービス	△	◎（Dapr）	◎
向くケース	単一Webアプリ	コンテナ／API／バッチ	大規模・高度な制御

ざっくりした判断軸はこうです。

• とにかく手軽に1つのWebアプリを公開したい → App Service
• コンテナで動かしたい／API・バッチ・マイクロサービスを、Kubernetesを学ばずに運用したい → Container Apps
• 細かなネットワーク制御やカスタムオペレーター、既存のKubernetes資産をフル活用したい → AKS

Container Apps の構成要素を押さえる

構築の前に、ACAの登場人物を整理しておきましょう。ここを理解しておくと、この後のコードがすっと頭に入ります。

• Container Apps 環境（Environment）：複数のコンテナアプリを載せる「土台」。同じ環境内のアプリは仮想ネットワークを共有し、相互に通信できます。Log Analyticsワークスペースと紐づき、ログもここに集約されます。マンションでいう「建物」にあたります。
• Container App：実際に動くアプリ本体。1つ以上のコンテナで構成されます。建物の中の「各部屋」です。
• リビジョン（Revision）：Container Appの不変のバージョン。デプロイのたびに作られ、トラフィック配分の単位になります。
• レプリカ（Replica）：リビジョンの実行インスタンス。スケールによって0〜Nの範囲で自動増減します。

構築のポイント：Azure CLIとTerraformで作る

実際に手を動かして作ってみます。まずは手軽なAzure CLIで、続いて再現性の高いTerraform（IaC）で構築します。

Azure CLIでサクッと作る

まず拡張機能とリソースプロバイダーを準備します。ACAは containerapp 拡張が必要です。

# 拡張機能の追加とプロバイダー登録
az extension add --name containerapp --upgrade
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights

# リソースグループ作成
az group create --name rg-aca-demo --location japaneast

次に「環境」を作り、その中にコンテナアプリをデプロイします。ここではサンプルとして公式のhello-worldイメージを使います。

# Container Apps 環境（土台）を作成
az containerapp env create \
  --name aca-env-demo \
  --resource-group rg-aca-demo \
  --location japaneast

# コンテナアプリをデプロイ
az containerapp create \
  --name app-hello \
  --resource-group rg-aca-demo \
  --environment aca-env-demo \
  --image mcr.microsoft.com/k8se/quickstart:latest \
  --target-port 80 \
  --ingress external \
  --min-replicas 0 \
  --max-replicas 3 \
  --query properties.configuration.ingress.fqdn

主なオプションを補足します。

• --target-port 80：コンテナがリッスンしているポート。イメージに合わせて指定します。
• --ingress external：インターネットに公開します。社内だけなら internal にします。
• --min-replicas 0：ここを 0 にすることでゼロへのスケール（アイドル時は課金ゼロ）が有効になります。
• --max-replicas 3：負荷に応じて最大3レプリカまで自動で増えます。
• 最後の --query ...ingress.fqdn：払い出された公開URL（FQDN）を出力します。ここにブラウザでアクセスすれば動作確認できます。

Terraformで再現性高く作る（IaC）

実務では手打ちのCLIではなく、コードで管理（IaC）して再現性を担保したいところです。同じ構成をTerraformで書くと次のようになります。環境・アプリ・ログ基盤を一括で定義でき、マルチクラウドでも同じ書き味で管理できるのがTerraformの強みです。

# main.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.100"
    }
  }
}

provider "azurerm" {
  features {}
}

variable "location" {
  default = "japaneast"
}

resource "azurerm_resource_group" "this" {
  name     = "rg-aca-demo"
  location = var.location
}

# ログ集約先（Log Analytics）
resource "azurerm_log_analytics_workspace" "this" {
  name                = "law-aca-demo"
  location            = azurerm_resource_group.this.location
  resource_group_name = azurerm_resource_group.this.name
  sku                 = "PerGB2018"
  retention_in_days   = 30
}

# Container Apps 環境（土台）
resource "azurerm_container_app_environment" "this" {
  name                       = "aca-env-demo"
  location                   = azurerm_resource_group.this.location
  resource_group_name        = azurerm_resource_group.this.name
  log_analytics_workspace_id = azurerm_log_analytics_workspace.this.id
}

# コンテナアプリ本体
resource "azurerm_container_app" "this" {
  name                         = "app-hello"
  resource_group_name          = azurerm_resource_group.this.name
  container_app_environment_id = azurerm_container_app_environment.this.id
  revision_mode                = "Single"

  template {
    min_replicas = 0
    max_replicas = 3

    container {
      name   = "app-hello"
      image  = "mcr.microsoft.com/k8se/quickstart:latest"
      cpu    = 0.5
      memory = "1Gi"
    }

    http_scale_rule {
      name                = "http-rule"
      concurrent_requests = 50
    }
  }

  ingress {
    external_enabled = true
    target_port      = 80
    traffic_weight {
      latest_revision = true
      percentage      = 100
    }
  }
}

output "fqdn" {
  value = azurerm_container_app.this.latest_revision_fqdn
}

あとはお馴染みの流れでデプロイします。

terraform init
terraform plan
terraform apply

Terraformのポイントを補足します。

• 依存関係は参照で自動解決：ログ基盤 → 環境 → アプリの順序は、azurerm_container_app_environment.this.id のように参照を書くだけでTerraformが正しく組み立ててくれます。depends_on を明示しなくても大丈夫です。
• http_scale_rule：オートスケールの条件を宣言します。例では「1レプリカあたり同時50リクエストを超えたら増やす」設定です。
• revision_mode = "Single"：常に最新リビジョンへ100%流す構成。カナリアをやりたい場合は Multiple にして traffic_weight を複数定義します。
• 再現性とマルチクラウド：このコードをGit管理し、CI/CD（GitHub ActionsやAzure DevOps）から terraform apply を流せば、検証・本番を同じ構成で何度でも作り直せます。AWS/GCPと同じツールチェーンで統一管理できるのもTerraformならではの利点です。

つまずきやすいポイント

実際に触ってみると引っかかりやすい点をまとめておきます。

• プロバイダー登録を忘れる：Microsoft.App を登録していないと環境作成でエラーになります。最初に az provider register を実行しておきましょう。
• ゼロスケール時の初回アクセスが遅い（コールドスタート）：レプリカ0から起動するため、久しぶりのアクセスは数秒待たされます。常時応答が必要なら --min-replicas 1 にします。ここはコストとレイテンシのトレードオフです。
• ポート指定ミス：--target-port がコンテナの実リッスンポートと違うと、公開URLにアクセスしても繋がりません。イメージの仕様を必ず確認しましょう。
• プライベートなACRのイメージを使う場合：認証情報（レジストリのユーザー／パスワード、またはマネージドID）の設定が必要です。パブリックイメージのように --image だけでは引けません。

料金の考え方

ACAの課金は、基本的に「使ったリソース（vCPU秒・メモリGB秒）とリクエスト数」に対する従量課金です。ポイントは、レプリカが0のときは（従量課金部分の）料金が発生しないこと。アクセスがまばらなワークロードほど、AKSやApp Serviceの常時起動よりコストを抑えやすくなります。毎月一定の無料枠も用意されているため、検証や小規模用途なら実質無料で始められるケースも多いです。

まとめ

この記事では、Azure Container Appsの概要から使いどころ、他サービスとの選び分け、Terraformでの構築まで見てきました。

• Container Apps：Kubernetesの複雑さを隠し、サーバーレスでコンテナを動かせるフルマネージドサービス。
• ゼロへのスケール：アイドル時は課金ゼロ。まばらなアクセスのワークロードに強い。
• 選び分け：単一WebアプリはApp Service、コンテナ／API／バッチはContainer Apps、高度な制御が要るならAKS。
• IaC：環境・アプリ・ログ基盤をTerraformで一括定義すれば、再現性の高い運用ができる。

「コンテナは使いたいけど、Kubernetesはやりすぎ」——そんなときの第一候補として、ぜひACAを引き出しに入れておいてください。まずはこの記事のCLIコマンドをコピペして、公開URLが払い出される感覚を掴むのがおすすめです。

あわせて読みたい：

• 【図解】Azure Kubernetes Service（AKS）とは？基本概念をどこよりも分かりやすく解説
• 【AKS実践】ACRの自作イメージをNamespaceで整理してデプロイする
• Application Gateway の概要を初心者向けに徹底解説！