---
title: "Azure Container Appsとは？料金の実額・Jobs・ExpressとApp Service・AKSの違い【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/3189/"
published: 2024-07-30
updated: 2026-10-28
categories: ["Azure"]
publisher: "株式会社一創"
---

# Azure Container Appsとは？料金の実額・Jobs・ExpressとApp Service・AKSの違い【2026年10月】

Azure Container Appsは、コンテナイメージを渡すだけでHTTPS付きのエンドポイントやバッチジョブとして動かせる、Azureのサーバーレスコンテナ基盤です。中ではKubernetesが動いていますが、利用者がクラスタやノードを扱うことはありません。アクセスが無い間はレプリカをゼロまで減らせるので、従量課金の無料枠に収まる規模なら費用は0円です。この記事では、2026年10月時点の単価で月額を円で試算したうえで、Container Apps Jobsの課金、2026年9月に一般提供が始まったContainer Apps Express、`az containerapp`での作成手順、App Service・AKS・Functionsとの選び分けまでを整理します。コンテナそのものの仕組みは[Dockerの内部構造を図解した記事](/tech/details/2661/)が前提になります。

## まとめ：Azure Container Appsの料金と選び方の要点

- **料金は秒単位の従量課金**。アクティブ時はvCPU 1秒あたり0.000024ドル、メモリ1GiB秒あたり0.000003ドル。毎月180,000 vCPU秒・360,000 GiB秒・200万リクエストまでは無料。
- **0.5 vCPU・1GiBのアプリなら、無料枠は月100時間分**。1日4時間だけ動くなら月約170円、24時間アクティブなら月約5,270円（1ドル約157.6円換算）。
- **Jobsはアクティブ単価だけで課金**され、リクエスト料金もアイドル料金もかからない。
- **環境を作らずに始めるならExpress**。2026年9月23日に一般提供となり、東日本・西日本でも使える。ただしJobs・Dapr・カスタムドメインなどは対象外。
- **常駐する1本のWebアプリならApp Service、Kubernetes APIを直接触るならAKS**。複数のコンテナをイベントで増減させ、アイドル時の費用を0に近づけたいときにContainer Appsを選ぶ。

## Azure Container Appsの基盤構成とKubernetes APIの制約

Container Appsは、Kubernetesを土台に、自動スケールのKEDA、サービス間通信やPub/SubのDapr、HTTPルーティングのEnvoyを組み合わせた実行基盤です。OSの更新やスケール処理、フェイルオーバーはプラットフォーム側が受け持ちます。[Microsoft Learnの概要](https://learn.microsoft.com/ja-jp/azure/container-apps/overview)が挙げる典型用途は、APIエンドポイント、バックグラウンド処理、イベント駆動の処理、マイクロサービスの4つです。

押さえておきたい制約は、**Kubernetes APIに直接アクセスできない**ことです。[Azureのコンテナ選択肢の比較ページ](https://learn.microsoft.com/en-us/azure/container-apps/compare-options)は、Kubernetes APIやコントロールプレーンが必要ならAKSを使うよう明記しています。kubectlやHelmチャート、独自のオペレーターをそのまま持ち込む前提なら、最初からContainer Appsは候補から外れます。

## 環境・アプリ・リビジョン・レプリカの関係

Container Appsは4つの単位で構成されます。**環境（Environment）**は1つ以上のアプリとジョブを囲む境界で、同じ環境のアプリは仮想ネットワークとログの出力先を共有します。その中に置く**コンテナアプリ**がサービスの単位で、コンテナイメージやスケールルールなど、リビジョンスコープの設定を変えてデプロイすると、不変のスナップショットである**リビジョン**ができます。実際に処理を担うのは**レプリカ**で、スケールルールに従ってこの数が増減します。

### 環境の種類：ワークロードプロファイル環境が既定

[環境のドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/environment)では、環境の種類は「ワークロードプロファイル環境（既定）」と「Consumption only環境（legacy）」の2つです。Azure CLI 2.91.0の`az containerapp env create`も`--enable-workload-profiles`の既定値が`True`になっています。ワークロードプロファイル環境なら、従量課金のアプリとDedicatedのアプリを同じ環境に同居させられます。

違いはレプリカの上限に出ます。[コンテナの割り当て要件](https://learn.microsoft.com/en-us/azure/container-apps/containers)によると、従量課金のCPUとメモリは0.25 vCPU・0.5GiBから4 vCPU・8GiBまで、常に1対2の組み合わせで指定します。Consumption only環境では2 vCPU・4GiBが上限です。古い記事の手順で作った環境だと、この上限に当たることがあります。

もう1つ、運用で見落としやすい規約があります。**アプリもジョブも動いていない状態が90日を超えた環境は自動で削除されます**（仮想ネットワークやAzure Policyの設定が原因で失敗状態のまま90日続いた場合も同じ）。2026年6月には、非アクティブな環境のアーカイブと、旧構成の環境をExpressへ移す通知メールについて[GitHubで告知](https://github.com/microsoft/azure-container-apps/issues/1772)が出ています。検証用の環境を放置しない運用にしておくのが安全です。

### リビジョンとトラフィック分割

[リビジョンのドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/revisions)によると、既定は**単一リビジョンモード**です。新しいリビジョンの準備ができるまで旧リビジョンを止めないので、通常のデプロイでダウンタイムは出ません。Blue/Greenやカナリアのように新旧へ割合で振り分けたいときは複数リビジョンモードに切り替え、ラベルとトラフィック分割を使います。非アクティブなリビジョンは既定で100個まで履歴に残ります。

## Azure Container Appsの料金：単価と月額の試算

課金はプランで決まります。秒単位で使った分だけ払う**従量課金（Consumption）**と、ワークロードプロファイルのインスタンス単位で払う**Dedicated**の2つです。単価は[Azure Container Appsの価格ページ](https://azure.microsoft.com/ja-jp/pricing/details/container-apps/)と、同じ値を返すAzure Retail Prices APIで確認できます。以下は2026年10月28日にAPIで取得した東日本リージョンの値です。

### 従量課金の単価と無料枠

| メーター                | ドル                                   | 円（東日本）       |
| ------------------- | ------------------------------------ | ------------ |
| vCPU（アクティブ）         | 0.000024/秒                           | 約0.0038/秒    |
| vCPU（アイドル）          | 0.000003/秒                           | 約0.0005/秒    |
| メモリ（アクティブ・アイドル共通）   | 0.000003/GiB秒                        | 約0.0005/GiB秒 |
| HTTPリクエスト           | 0.40/100万件                           | 63.02/100万件  |
| 無料枠（毎月・サブスクリプション単位） | 180,000 vCPU秒・360,000 GiB秒・200万リクエスト |              |

無料枠はアプリごとではなく**サブスクリプション単位**です。同じサブスクリプションで複数のアプリを動かすと、合算で枠を消費します。[課金のドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/billing)によれば、リクエスト料金の対象は環境の外から来たHTTPリクエストだけで、ヘルスプローブは数えません。

アイドル単価が適用されるのは、最小レプリカ数を1以上にしていて、その最小数まで縮んでいるときに限られます。さらに、そのレプリカがHTTPリクエストを処理しておらず、CPU使用が0.01 vCPU未満、受信が毎秒1,000バイト未満という条件をすべて満たす必要があります。レプリカ数が最小数を超えている間は、そのリビジョンで稼働するすべてのレプリカがアクティブ単価の対象です。サーバーレスGPUのアプリにはアイドル単価がありません。

### 月額の試算：ゼロスケール・最小1レプリカ・常時アクティブ

0.5 vCPU・1GiBのレプリカを最大1つ、30日間動かし、サブスクリプションの無料枠を全量使える場合のコンピューティング料金は次のとおりです。稼働時間には起動処理やスケールインまでの待機も含めます。円は価格APIの円建て単価から割り出した1ドル約157.6円で換算しています。

| 動かし方              | 課金対象の秒数                          | 月額                |
| ----------------- | -------------------------------- | ----------------- |
| ゼロスケール・1日4時間だけ稼働  | vCPU 36,000秒・メモリ72,000GiB秒       | 約1.08ドル（約170円）    |
| 最小1レプリカ・ほぼアイドル    | vCPU 1,116,000秒・メモリ2,232,000GiB秒 | 約10.04ドル（約1,580円） |
| 最小1レプリカ・24時間アクティブ | vCPU 1,116,000秒・メモリ2,232,000GiB秒 | 約33.48ドル（約5,270円） |

0.5 vCPU・1GiBなら、無料枠はvCPUでもメモリでもちょうど月100時間分です。1レプリカの総稼働時間が月100時間以内なら、他のアプリやジョブが無料枠を消費していない場合、コンピューティング料金は0円です。リクエスト料金や周辺リソースの料金は別にかかります。リクエストが月500万件あれば、超過の300万件ぶんとして約1.20ドル（約190円）が上乗せされます。

**この試算条件では、最小レプリカを1にして30日間ほぼアイドルで維持すると、月約1,580円の従量料金がかかります**。コールドスタートを避けたい理由が無いアプリは、最小レプリカを0にしておきます。なお、独自の仮想ネットワークを使う場合や、Log Analyticsなど他のAzureリソースを使う場合は、その料金が別にかかります。

### Dedicatedプランと管理料金

Dedicatedはアプリ単位ではなく、ワークロードプロファイルのインスタンス単位で課金されます。東日本の単価はvCPUが1時間0.057077ドル（8.9925円）、メモリが1GiB時間0.004978ドル（0.7843円）です。汎用のD4（4 vCPU・16GiB）を1台、730時間動かすと約224.8ドル（約35,400円）になります。プロファイルはD4〜D32の汎用、E4〜E32のメモリ最適化、A100のGPUなどから選びます。

注意したいのが管理料金です。価格ページは、Dedicatedプラン、プライベートエンドポイント、計画メンテナンスにそれぞれ時間単位の管理料金がかかり、**併用すると機能ごとに加算される**と記載しています。価格APIでは2026年9月1日付けで、この3つのメーターがそれぞれ1時間0.145ドル（東日本22.8447円）です。1つだけでも730時間で約105.9ドル（約16,700円）です。プライベートエンドポイントは従量課金プランのアプリでも使え、Dedicatedへの移行は要りませんが、この管理料金はプランにかかわらず発生します。安定して高い負荷が続くアプリでは、Dedicatedのほうが従量課金より安くなる場合があります。

## Container Apps Jobsの種類と料金

始まって終わる処理は、アプリではなく**Container Apps Jobs**で動かします。[ジョブのドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/jobs)が挙げるトリガーは次の3種類です。

- **Manual**：APIやCLIから必要なときに起動する（データ移行、オンデマンドの集計など）
- **Schedule**：cron式で定期実行する（夜間のレポート生成など）
- **Event**：KEDAのスケーラーでキューのメッセージなどを検知して起動する（Service Busのメッセージ処理、GitHub ActionsやAzure Pipelinesのセルフホストランナーなど）

料金は、実行中のレプリカに割り当てたvCPU秒とGiB秒を**アクティブ単価**で数えるだけです。完了すればリソースを使わないのでアイドル単価は無く、イングレスを持たないのでリクエスト料金もかかりません。たとえば0.5 vCPU・1GiBのジョブを毎日10分動かすと、月にvCPU 9,000秒・メモリ18,000GiB秒です。無料枠が残っていれば0円、枠を使い切った状態でも約0.27ドル（約43円）です。

設定で気を付けたいのは既定値です。Learnの例は`replicaTimeout`が1800秒、`replicaRetryLimit`が0、`parallelism`が1で、30分を超える処理は失敗扱いになり、再試行もしません。長いバッチでは`--replica-timeout`と`--replica-retry-limit`を明示します。権限にも落とし穴があります。Container Apps Jobs ContributorとOperatorの両ロールは`Microsoft.App/jobs/*/action`を含むので、ジョブのシークレットを平文で読めます。カスタムロールでは必要な操作だけを許可します。ただし、ジョブの起動権限でも実行テンプレートの上書きを通じてシークレットやマネージドIDを利用できるため、起動を許可する相手にもそれらを扱う権限を委ねられるか確認します。

次の例は、Azureへのログインとリソースグループ・環境の作成が済んでいる前提です。イメージ名は自分で用意したバッチ用イメージに置き換え、非公開ACRを使う場合は、pull権限を持つマネージドIDなどのレジストリ認証も設定してください。

```
az containerapp job create \
  --name nightly-report \
  --resource-group myResourceGroup \
  --environment my-environment \
  --trigger-type Schedule \
  --cron-expression "0 18 * * *" \
  --replica-timeout 3600 \
  --replica-retry-limit 1 \
  --parallelism 1 \
  --image myregistry.azurecr.io/report:1.0 \
  --cpu 0.5 --memory 1.0Gi
```

スケジュールジョブのcron式は協定世界時（UTC）で評価されるため、日本時間の午前3時に動かすには`0 18 * * *`と書きます。

## az containerappによるアプリの作成・公開手順

Azure CLIは2.91.0の時点で`az containerapp`をコアに含んでいます。以前の手順にある`az extension add --name containerapp`を実行すると「No stable version」の警告が出て、プレビュー版の拡張しか入りません。プレビュー機能を使わないなら拡張は不要です。

手元のソースから作る場合は`az containerapp up`を使います。次の例はアプリのソースがあるディレクトリで実行し、コンテナ内のHTTP待受ポートが8080であることを前提とします。異なる場合は`--target-port`を変更してください。リソースグループ、環境、Azure Container Registryまでまとめて作成し、Dockerfileがあればそれでビルドします（Dockerfileが無い場合のビルドパック・Oryxでの生成はプレビュー扱い）。

```
az login
az group create --name myResourceGroup --location japaneast

az containerapp up \
  --name my-container-app \
  --resource-group myResourceGroup \
  --location japaneast \
  --environment my-environment \
  --source . \
  --ingress external \
  --target-port 8080
```

次はソースからのデプロイとは別の例です。リソースグループと環境を用意し、直前の例を実行済みならアプリ名を別名に変更してください。レジストリにあるイメージから、リソース量やレプリカ数を指定して作る場合は`az containerapp create`を使います。

```
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 \
  --cpu 0.5 --memory 1.0Gi \
  --min-replicas 0 \
  --max-replicas 5
```

プライベートなレジストリを使う場合のイメージの置き場所と料金は、[Azure Container Registryの料金プランとpush手順の記事](/tech/details/15653/)にまとめています。テンプレートからインフラとアプリを一括で作るなら、[Azure Developer CLI（azd）のazd up](/tech/details/7635/)も選択肢です。

## 自動スケールの既定値とゼロスケールの条件

スケールの既定値は[スケーリングのドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/scale-app)にまとまっています。

| 項目                | 既定値           |
| ----------------- | ------------- |
| 最小レプリカ数           | 0（設定上限1,000）  |
| 最大レプリカ数           | 10（設定上限1,000） |
| HTTPの同時リクエスト閾値    | 10（15秒ごとに計算）  |
| KEDAのポーリング間隔      | 30秒           |
| 最後のレプリカを0にするまでの待機 | 300秒          |

ゼロまで縮められるのは、HTTP・TCP・KEDAのイベントスケーラーでスケールさせるアプリです。**CPUやメモリの負荷でスケールするアプリはゼロにできません**。最小レプリカ数が0で、スケールルールの条件とクールダウン期間を満たすとゼロに縮み、次のリクエストでイメージの取得とコンテナの起動が走るため、最初の応答が遅れます。業務時間の頭に遅延が出るのを避けたいなら、始業前にジョブでアプリを起こしておく方法を[コールドスタート対策のドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/cold-start)が挙げています。それでも足りなければ最小レプリカを1にしますが、上の試算条件では、30日間ほぼアイドルで維持しても月約1,580円の従量料金が発生します。

## Container Apps Express（2026年9月GA）でできること・できないこと

Container Apps Expressは、**環境を先に作らずにコンテナイメージからアプリを作れる**入り口です。2026年5月にプレビューが始まり、[2026年9月23日に一般提供](https://techcommunity.microsoft.com/blog/appsonazureblog/azure-container-apps-express-is-now-generally-available/4559101)になりました。告知では40を超えるリージョンに対応し、[Expressの概要ページ](https://learn.microsoft.com/ja-jp/azure/container-apps/express-overview)の一覧には東日本と西日本も入っています。料金は通常の従量課金と同じ秒単位で、ゼロスケールも既定です。管理はAzureポータルではなく専用の画面（containerapps.azure.com）で行います。

ただし、対応するのはHTTPのWebアプリとAPIに絞られています。概要ページの表では、Webアプリ・REST API・管理画面は対象、GPU・TCPサービス・ジョブ・サービス検出を使うマイクロサービスは対象外です。

| 区分   | Expressでの扱い                            |
| ---- | -------------------------------------- |
| 使える  | ゼロスケール、HTTPイングレス、IP制限、CORS、VNetへの送信    |
| 制限付き | マネージドIDはユーザー割り当てのみ、スケールはHTTP・CPU・メモリのみ |
| 使えない | Jobs、Dapr、サイドカー、カスタムドメイン、Key Vault参照   |
| 使えない | トラフィック分割、HTTP/2、TCP、ワークロードプロファイル       |

判断の目安ははっきりしています。**独自ドメインで公開する本番サービス、キューで動くワーカー、Daprでつなぐマイクロサービスは、通常のContainer Appsで作ります**。Expressが向くのは、azurecontainerapps.ioのドメインのままで構わない試作、社内向けのダッシュボード、AIエージェントのバックエンドのようなHTTPだけのアプリです。GitHubには、Expressでは標準の環境よりHTTPリクエストごとに約0.5秒遅いという[報告](https://github.com/microsoft/azure-container-apps/issues/1856)も2026年10月15日付けで出ており、応答時間に厳しいAPIは採用前に計測しておきます。

同じ2026年9月23日には、信頼できないコードをハードウェア分離のマイクロVMで動かす[Container Apps Sandboxes](https://learn.microsoft.com/en-us/azure/container-apps/sandboxes-overview)も一般提供になりました。Expressはこの基盤の上で動いています。AIエージェントにコードを実行させる用途はSandboxes、Webアプリの公開はExpressという分担です。

## App Service・AKS・Functionsとの違いと選び方

Azureでコンテナを動かすサービスは、どこまで自分で制御したいかと、アイドル時に費用を払うかどうかで分かれます。

| サービス                | 課金の単位           | ゼロスケール    | 向く用途                  |
| ------------------- | --------------- | --------- | --------------------- |
| Container Apps      | 秒単位（従量課金）       | 可         | 複数コンテナ・イベント処理・ジョブ     |
| App Service         | プランの時間単位        | 不可        | 常駐する1本のWebアプリ         |
| AKS                 | ノードのVM          | ノードは自分で設計 | Kubernetes APIを直接使う構成 |
| Functions           | 実行時間と回数（従量系プラン） | 可         | トリガー駆動の短い関数           |
| Container Instances | コンテナの秒単位        | 対象外       | 単発のコンテナ実行             |

### App Serviceとの違い：常駐課金かゼロスケールか

App ServiceはWebアプリのホスティングに最適化されたPaaSで、App Serviceプランを確保している時間に課金されます。価格APIで2026年10月28日に取得した東日本のBasic B1（Linux）は1時間2.9934円、730時間で約2,185円です。アクセスがゼロでもこの金額はかかります。Container Appsは、前述のとおりゼロスケールなら月数百円以下に収まる一方、最小1レプリカで常時アクティブにすると0.5 vCPUでも月5,000円を超えます。

つまり、**常に一定のアクセスがある1本のWebサイトはApp Service、アクセスに波があるAPIや複数のサービスに分かれた構成はContainer Apps**が費用面でも素直です。App ServiceのデプロイスロットはStandard以上のプランで利用でき、上で比較したBasic B1には含まれません。Container Appsではリビジョンとトラフィック分割によって段階的なリリースを行えます。プランごとの料金と容量は[Azure App Serviceの機能・料金・容量を解説した記事](/tech/details/15639/)で比較できます。

### AKSとの違い：Kubernetes APIへのアクセスと運用範囲

AKSはKubernetesをそのまま提供するので、DaemonSet、独自のオペレーター、CNIの選択、ノードの設定まで自由に扱えます。その代わり、ノードプールの設計やバージョンアップの計画は利用者の仕事です。Container AppsはKubernetes APIを公開しない代わりに、その運用を引き受けます。既存のマニフェストやHelmチャートの資産がある、またはクラスタ単位で細かく制御したいならAKSです。AKSの料金と始め方は[AKS（Azure Kubernetes Service）の解説記事](/tech/details/7272/)を参照してください。

### Functions・Container Instancesとの位置関係

Azure FunctionsはトリガーとバインディングでコードをつなぐFaaSで、Container Apps上でFunctionsをコンテナとして動かすこともできます。この構成には新旧2つの方式があり、旧方式（Functions on ACA V1）は[2027年9月30日に提供終了](https://github.com/microsoft/azure-container-apps/issues/1843)します。今から作るなら、`kind=functionapp`を指定したネイティブのコンテナアプリとして作るV2方式を選びます。Functions単体の料金と使い方は[Azure Functionsの料金と動かし方の記事](/tech/details/3171/)にあります。Azure Container Instancesは単一のコンテナグループを動かす下位の部品で、スケールやロードバランスは持ちません。提供終了が決まったAzure Spring Appsからの移行先としての位置付けは[Azure上のJava開発環境の現在地をまとめた記事](/column/details/2472/)で整理しています。

## セキュリティと運用：マネージドID・シークレット・ログの設定

他のAzureリソースへの認証は、接続文字列ではなく[マネージドID](https://learn.microsoft.com/en-us/azure/container-apps/managed-identity)で行います。システム割り当て（アプリと同時に削除される・1アプリに1つ）とユーザー割り当ての両方を使え、Key VaultやAzure SQL Database、Storageにトークンで接続できます。シークレットは値を直接書くこともできますが、[シークレット管理のドキュメント](https://learn.microsoft.com/en-us/azure/container-apps/manage-secrets)は本番ではKey Vaultの参照を使うよう求めています。

通信面では、環境を既存の仮想ネットワークに入れて内部だけに公開できるほか、環境内の通信をプラットフォーム管理の証明書でTLS暗号化するピアツーピア暗号化を有効にできます。APIを束ねて認可やレート制限をかけたい場合は、[Azure API Management](/tech/details/3162/)を前段に置く構成になります。

ログについては2026年8月に方針が変わりました。[GitHubの告知](https://github.com/microsoft/azure-container-apps/issues/1812)により、これまで既定だったLog Analyticsへの出力はlegacy扱いとなり、新しい構成ではAzure Monitorへの出力が推奨です。既存の環境は動き続けますが、`ContainerAppConsoleLogs_CL`や`ContainerAppSystemLogs_CL`を前提にしたクエリやアラートは移行時に見直しが要ります。Azure CLI 2.91.0の`--logs-destination`は今も既定が`log-analytics`なので、通常のワークロードプロファイル環境を新規作成する際は`azure-monitor`を明示し、診断設定で収集するログカテゴリと送信先も設定します。ExpressはAzure Monitorログ出力に対応していないため、この設定の対象外です。

## Container Appsを選ばないほうがよい場面

次の条件に当てはまるなら、Container Appsは選びません。

- **Kubernetesのリソースを直接扱う必要がある**：DaemonSet、CRDとオペレーター、ノードのカーネル設定が要る構成はAKSにする。
- **24時間ほぼ一定の負荷が続く単一のWebアプリ**：ゼロスケールの利点が消え、0.5 vCPUで月5,000円超の従量課金より、App Serviceのプランのほうが読みやすく安いことが多い。
- **コールドスタートを1回も許せないのに、最小レプリカの固定費は払いたくない**：この2つは両立しない。どちらを取るかを先に決める。
- **プライベートエンドポイントを付けたいだけの小さなアプリ**：管理料金だけで月約16,700円が加わる。

クラウド基盤の構成をどう組むかから相談したい場合は、[インフラ構築（AWS・Google Cloud・Azure）の支援](https://www.issoh.co.jp/service/system/aws/)で設計から対応しています。サービスをどこまで分割するかが決まっていないなら、先に[モノリスとマイクロサービスの違い](/column/details/2910/)を整理しておくと、Container Appsが必要かどうかの判断がぶれません。

## よくある質問

### Azure Container Appsは無料で使えますか？

従量課金には、サブスクリプションごとに毎月180,000 vCPU秒・360,000 GiB秒・200万リクエストの無料枠があります。0.5 vCPU・1GiBのアプリなら月100時間分です。ゼロスケールの検証用アプリなら0円で収まることもありますが、Log Analyticsや独自の仮想ネットワークなど他のリソースの料金は別にかかります。

### Azure Container Apps Jobsの料金はどう計算されますか？

実行中のレプリカに割り当てたvCPU秒とGiB秒を、アクティブ単価で数えます。アイドル単価とリクエスト料金はかかりません。0.5 vCPU・1GiBのジョブを毎日10分なら、無料枠を超えていても月約0.27ドルです。

### Azure Container AppsとApp Serviceの違いは何ですか？

App Serviceはプランを確保している時間に課金される常駐型のPaaSで、ゼロスケールはありません。Container Appsは秒単位の従量課金で、アクセスが無い間はゼロまで縮められます。常に一定のアクセスがある1本のWebアプリはApp Service、波のあるAPIや複数サービス構成はContainer Appsが向きます。

### Azure Container AppsとAKSの違いは何ですか？

AKSはKubernetes APIをそのまま使えるマネージドKubernetesで、ノードの設計や更新は利用者が担います。Container AppsはKubernetes APIを公開しない代わりに、クラスタの運用をすべてAzureが受け持ちます。kubectlやHelmの資産を使うならAKSです。

### Container Apps環境の作成は必須ですか？

通常のContainer Appsでは、アプリやジョブを置く前に環境を作ります（`az containerapp up`なら同時に作成されます）。2026年9月に一般提供になったExpressでは、ポータルから作る場合は環境を意識せずにアプリを作れます。CLIで作る場合は、Expressでも環境を自分で作ります。

## 関連記事

- [Azure App Serviceとは？機能・プラン別の料金と容量、作成手順を解説【2026年10月】](/tech/details/15639/)
- [AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】](/tech/details/7272/)
- [Azure Functionsとは？料金の実額とPythonで動かす手順をわかりやすく解説【2026年10月】](/tech/details/3171/)
- [Azure Container Registry（ACR）とは？料金プランの違いと月額・作成からpushまでの手順【2026年10月】](/tech/details/15653/)
- [Dockerの仕組みを図解：containerd・runc・namespaces・ネットワーク・Composeの内部を実測で解説](/tech/details/2661/)

---

出典: [Azure Container Appsとは？料金の実額・Jobs・ExpressとApp Service・AKSの違い【2026年10月】](<https://www.issoh.co.jp/tech/details/3189/>)（株式会社一創）
