技術コラム

HOME
ニュース
技術コラム
Azure Container Apps の料金を抑える設定｜使わない間は止めるか、常時起動にするかの判断基準

2026-01-19 / 最終更新日時 : 2026-09-29 musashi 技術コラム

Azure Container Apps の料金を抑える設定｜使わない間は止めるか、常時起動にするかの判断基準

min-replicas を0にすれば待機中は無料、1にすれば常時課金。この理解のままだと、0のほうが高くつく構成を作ってしまうことがあります。

最小レプリカ数が0のとき、動いているレプリカはすべて通常の料金です。低い「アイドル料金」が適用されるのは、最小レプリカ数を1以上にしたときだけです。数分おきに外形監視が届くアプリは0に戻らず、0を選んだつもりで1台を通常の料金のまま動かし続けることになります。

Azure Container Apps を使っている方の多くは、「使われていない間は0台まで縮小し、料金がかからない」という仕組みはご存じだと思います。ただ、料金が実際にどう決まるかを確かめてから min-replicas を決めているケースは多くありません。弊社は、音声系のアプリや社内向けのツールを Azure Container Apps で運用する中で、0と1を用途ごとに使い分けてきました。この記事では、課金の仕組みを原文に沿って整理したうえで、0と1を分ける判断の軸と、0を選ぶときに見落としやすい落とし穴を解説します。

min-replicas とは
「迷ったら1にしておけばよいのでは？」への答え
0にしても、0に戻らないケース
1にしても、通常の料金になるケース
0と1を分ける判断の軸
0を選ぶときの落とし穴
周辺の設定でつまずく点
弊社の支援
よくあるご質問

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

min-replicas とは

Azure Container Apps は、アプリの実行単位であるレプリカの数を、スケールのルールに従って自動で増減させます。min-replicas（最小レプリカ数）は、その下限です。既定値は0で、スケールのルールを定義しない場合は、HTTP の要求数に応じて0台から10台の間で増減する既定のルールが適用されます。

設定	既定値	意味
最小レプリカ数（min-replicas）	0	0なら、使われていない間は0台まで縮小する。1以上なら、その台数が常に動く
最大レプリカ数（max-replicas）	10	負荷が増えたときに増やす上限
既定のスケールルール	HTTP（0〜10台）	ルールを定義しない場合に適用される

Microsoft Learn は、「リビジョンのインスタンスが常に動いている状態にしたい場合は、最小レプリカ数を1以上に設定します」と説明しています。なお、スケールの設定はリビジョンの単位で持つ設定なので、min-replicas を変えると新しいリビジョンが作られます。

「迷ったら1にしておけばよいのでは？」への答え

min-replicas の話をすると、「1台分の料金は小さいのだから、迷ったら1にしておけばよい」「逆に、料金を抑えたいなら全部0にすればよい」という意見がよく出ます。どちらも半分だけ正しく、料金は「0か1か」だけでは決まりません。Learn の料金の説明から、次の3つが読み取れます。

状態	料金	原文の趣旨
0台に縮小している	かからない	レプリカが0のとき、リソースの使用料金は発生しない
最小レプリカ数（1以上）で待機している	アイドル料金（低い）	最小レプリカ数が0より大きく、その台数まで縮小していて、アイドルの条件をすべて満たすとき
最小レプリカ数を超えて動いている	通常の料金	最小を超えて増えたとき、動いているレプリカはすべて通常の料金

見落とされやすいのは3行目です。最小レプリカ数が0のアプリで1台が動いていれば、それは「最小を超えて動いている」状態なので、通常の料金になります。アイドル料金は、最小レプリカ数を1以上にしたときにしか適用されません。つまり、0を選んだアプリが何かの理由で0に戻らないと、1を選んで待機させるより高くつきます。

一方で、1にしても常にアイドル料金になるとは限りません。どちらの場合も、料金を左右するのは「アプリが本当に止まっていられるか」です。次の2章で、それぞれの落とし穴を説明します。

0にしても、0に戻らないケース

Learn のスケール動作の表では、最後のイベントから最小レプリカ数まで縮小するまでの待機時間（cool down period）は300秒です。要求が途切れてから約5分は、レプリカが動いたまま残ります。

外形監視の間隔が、縮小の待機時間より短い

死活監視のために、外部のサービスや Azure Monitor の可用性テストから数分おきにアプリへ要求を送っていると、待機時間が過ぎる前に次の要求が届きます。この場合、アプリは一度も0台に戻らず、通常の料金で動き続けます。0を選んだ意味がなくなるうえに、1を選んで待機させるより高くつきます。

0を選ぶなら、外形監視の間隔を縮小の待機時間より長くするか、監視は失敗率などのテレメトリで行い、アプリを起こす監視はやめるのが筋です。逆に、止まっていてほしくないから監視で起こしている、という状態なら、最初から1にするべきです。

同じ環境のほかのアプリや、利用者の画面が呼び続けている

画面が数十秒おきに状態を取りに来る作りや、別のアプリから定期的に呼ばれる作りでも、同じことが起きます。0にしたアプリが実際に0台まで縮小しているかは、ポータルのレプリカ数のメトリックで、夜間や休日の推移を一度確かめておくと確実です。

1にしても、通常の料金になるケース

最小レプリカ数を1にしたとき、アイドル料金になるのは、レプリカが「アイドル」と判定されている間だけです。Learn は、次の条件をすべて満たすときにアイドルとみなすと書いています。

レプリカ内のすべてのコンテナーが起動し、動いている
HTTP の要求を処理していない
CPU の使用量が 0.01 vCPU 未満
受信しているネットワークの通信が毎秒 1,000 バイト未満

このうち3と4は、思ったより簡単に外れます。アプリの中で定期的に処理を回すタイマー、接続を保つための定期的な通信、ログの大量出力などがあると、利用者がいない時間でもアイドルと判定されません。WebSocket の接続を張ったままにしておく画面が開きっぱなしになっている場合も、通信の量によっては同じです。

1にしたアプリが実際にアイドル料金になっているかは、コスト分析で使用量の内訳を見ると確かめられます。想定より通常の料金が多ければ、アプリの中で止まっていない処理がないかを疑います。

0と1を分ける判断の軸

ここまでのとおり、料金の差は「0か1か」より「本当に止まっていられるか」で決まります。そのうえで0と1を分ける本当の軸は、料金ではなく「起動を待つ時間を許容できるか」です。0台から起動するときは、コンテナーイメージの取得とアプリの起動を待つ時間が必ず生じます。弊社は次の3つの問いで決めています。

応答に期限があるイベントを受けるなら、1以上

代表的なのが電話の着信です。Azure Communication Services で電話を受ける構成では、着信は Event Grid の IncomingCall イベントとしてアプリへ届き、アプリが応答の API を呼ぶことで通話がつながります。Learn は、この着信について「着信が鳴るのは30秒だけで、それを過ぎてから応答しても効果はありません」と書いています。

イベントを受けてから起動を始めていては、この30秒の中に起動の時間を挟むことになります。起動が遅れれば、着信は応答されないまま終わります。弊社では、電話を受けるアプリは最小レプリカ数を1にしています。これがこの構成で唯一、常にかかる料金になりますが、ここは削れない費用と割り切っています。同じ考え方は、外部のサービスから期限付きの通知を受ける Webhook の受け口にも当てはまります。

（2026年9月更新）

補足：Microsoft は2026年9月、Azure Communication Services の単体での提供を2028年9月30日で終了すると発表しました。Azure Communication Services で取得する電話番号や Direct Routing は提供終了の対象で、Call Automation は Microsoft Teams と連携する用途に限定される予定です。着信を30秒以内に受ける必要があるという考え方は変わりませんが、影響と対応策はAzure Communication Services の提供終了で何が変わるかで解説しています。

「開いた瞬間に使える」ことが要るなら、1＋端末側のキャッシュ

現場で思い立ったときにすぐ使うツールは、開いてから画面が出るまでの数秒が使われなくなる理由になります。弊社がブラウザで動く音声翻訳のツールを作ったときは、最小レプリカ数を1にしてサーバー側を常に起こしておき、あわせて Service Worker で画面の部品を端末にキャッシュしました。開いた瞬間に画面が出て、話し始める頃にはサーバーの準備ができている、という体感を作るには、サーバー側だけでなく端末側の工夫も組み合わせるのが効果的です。

アプリの中にタイマーを持つなら、1か、ジョブへ分ける

「指定した時刻に処理を始める」ような機能をアプリの中のタイマーで作ると、0台に縮小している間はタイマーも止まります。最小レプリカ数を1にすれば動きますが、定期的な処理は Container Apps のジョブ（スケジュール実行）へ分けるほうが、アプリ本体を0にできて筋がよい構成です。

どれにも当たらなければ、0

社内向けのデモ、検証環境、たまにしか使わない管理画面などは、最初の1回に起動を待つ時間を許容できるので、0が向いています。弊社でも、お客様向けの検証に使うアプリは普段は0にしておき、実際に試験するときだけ1に上げ、終わったら0に戻す運用をしています。上げたまま戻し忘れると料金がかかり続けるので、戻すところまでを手順に含めておきます。

用途	最小レプリカ数	理由
電話の着信など、応答に期限があるイベントの受け口	1以上	起動を待つ時間を期限の中に挟めない
開いた瞬間に使えることが期待される画面	1＋端末側のキャッシュ	数秒の待ちが使われなくなる理由になる
アプリの中にタイマーや常駐の処理がある	1、またはジョブへ分けて0	0台の間はタイマーも止まる
キューのメッセージを処理するバックグラウンドの処理	0（カスタムのスケールルール）	メッセージが来たときだけ起動すればよい
社内向けのデモ、検証環境、管理画面	0	最初の1回の待ちを許容できる

0を選ぶときの落とし穴

0を選ぶと決めたら、次の2つを確かめておきます。どちらも、気づいたときにはアプリが動かなくなっている種類の落とし穴です。

イングレスを無効にすると、起動する手段がなくなる

既定のスケールルールは HTTP の要求数で起動します。Learn は、「イングレスを無効にして、最小レプリカ数もカスタムのスケールルールも定義しないと、アプリは0台に縮小し、再び起動する手段がなくなります」と警告しています。外部からの要求を受けないバックグラウンドの処理を0で動かすなら、キューなどを見るカスタムのスケールルールを必ず定義します。

環境が90日間アイドルのままだと、自動で削除される

Learn は、Container Apps の環境について、「環境がアイドルの状態（動いているアプリやジョブがない状態）が90日を超えて続くと、自動的に削除される」という方針を示しています。検証用の環境にあるアプリをすべて0にしたまま長期間放置すると、この条件に当たるおそれがあります。久しぶりに使おうとしたら環境ごと無くなっていた、とならないよう、長く使わない検証環境はコードから作り直せる状態にしておくか、定期的に動かす運用にします。

周辺の設定でつまずく点

min-replicas とあわせて、公開の設定で弊社がつまずいた点、判断を誤りやすい点をまとめます。

カスタムドメインは「追加」してから「バインド」する

独自のドメイン名で公開する手順は、DNS にレコードを登録したうえで、①アプリにホスト名を追加し、②証明書を用意してバインドする、の2段階です。Learn の手順もこの順です。弊社では、①を飛ばして②のバインドだけを実行し、「環境にカスタムのホスト名が必要」という趣旨のエラーで止まったことがあります。

Azure CLI　—　①ホスト名を追加し、②マネージド証明書を発行してバインドする

az containerapp hostname add \
  --resource-group <リソースグループ名> \
  --name <アプリ名> \
  --hostname <ドメイン名>

az containerapp hostname bind \
  --resource-group <リソースグループ名> \
  --name <アプリ名> \
  --hostname <ドメイン名> \
  --environment <環境名> \
  --validation-method CNAME

サブドメインの場合、DNS には、アプリに生成されたドメイン名を直接指す CNAME レコードと、所有権を確かめるための asuid. で始まる TXT レコードを登録します。Learn は、CNAME を別の名前を経由して指すと、証明書の発行と更新が妨げられると注意しています。

マネージド証明書は無料で、自動で更新される

Container Apps が発行するマネージド証明書は無料で、要件を満たしている限り自動で更新されます。要件は、HTTP のイングレスを有効にして公開の経路から到達できること、サブドメインなら上の CNAME、ルートのドメインなら A レコードを登録していること、などです。証明書の期限切れを管理する手間がなくなるので、特別な理由がなければマネージド証明書を使います。

WebSocket は、既定の設定のままで通る

音声を扱うアプリでは WebSocket を使うことが多く、「特別な設定が要るのでは」と迷いがちです。Container Apps の HTTP のイングレスは WebSocket に対応しており、通信方式の設定（transport）は既定の auto のままで使えます。弊社の音声系のアプリも、この既定の設定で動かしています。

環境の分け方は、料金ではなく境界で決める

「環境を共有すれば料金を抑えられる」と考えがちですが、Consumption プランだけで使う場合、環境そのものに料金はかかりません。ワークロードプロファイルの環境でも、Dedicated のプロファイルを使わない限り、環境全体にかかるプランの管理料金は発生しません。同じ環境のアプリは、仮想ネットワークとログの送り先を共有します。環境を分けるかどうかは、料金ではなく、ネットワークを分けたいか、ログを分けたいか、検証と本番を分けたいか、で決めます。

min-replicas の決め方のまとめ

最小レプリカ数が0のとき、動いているレプリカはすべて通常の料金で、アイドル料金は1以上のときだけ
0でも、外形監視や定期的な呼び出しが縮小の待機時間（300秒）より短い間隔で届けば0に戻らない
1でも、アイドルの4条件を外れる処理があれば通常の料金になる
判断の軸は料金より「起動を待つ時間を許容できるか」。電話の着信のように期限があるなら1以上
0を選ぶなら、起動の手段と、環境の90日の自動削除を確かめる

弊社の支援

弊社は、お客様専用のAI基盤やアプリを Azure 上に構築する形で、AIの業務活用を支援しています。Azure Container Apps は、音声のように常時の接続を扱うアプリから、たまにしか使わない社内ツールまで、1つの基盤で運用できる選択肢です。その分、アプリごとに最小レプリカ数の考え方が変わります。

弊社では、構築の段階で用途ごとの最小レプリカ数と、その理由、確かめ方までを決めてお渡しすることを重視しています。サーバーレスで動かす場合の別の選択肢として、Azure Functions Flex Consumption のデプロイと運用もあわせてご覧ください。

よくあるご質問

こちらをクリックして「よくある質問」を表示

min-replicas を0にすれば、料金はかからないのですか？

0台に縮小している間は、リソースの使用料金はかかりません。ただし、要求が届いて動いている間はすべて通常の料金です。外形監視などで数分おきに要求が届くと0台に戻らず、通常の料金のまま動き続けるため、最小レプリカ数を1にして待機させるより高くなることがあります。

アイドル料金は、どういうときに適用されますか？

最小レプリカ数を1以上にし、その台数まで縮小している状態で、レプリカがアイドルと判定されている間です。すべてのコンテナーが起動して動いていること、HTTP の要求を処理していないこと、CPU の使用量が 0.01 vCPU 未満であること、受信の通信が毎秒 1,000 バイト未満であることを、すべて満たす必要があります。

0台からの起動には、どのくらい時間がかかりますか？

コンテナーイメージの大きさ、レジストリーの場所、アプリの起動処理によって変わるため、一概には言えません。イメージを小さくする、アプリと同じリージョンのレジストリーを使う、起動時の重い処理を避けると短くできます。期限のある処理を受けるアプリでは、短くする工夫より、最小レプリカ数を1にするほうが確実です。

min-replicas を変えると、アプリは再起動しますか？

スケールの設定はリビジョンの単位の設定なので、変えると新しいリビジョンが作られます。単一リビジョンのモードでは新しいリビジョンに切り替わるため、試験のために一時的に1へ上げる場合も、この点を踏まえて作業の時間帯を選びます。

WebSocket を使うアプリで、特別な設定は必要ですか？

HTTP のイングレスは WebSocket に対応しており、通信方式の設定は既定の auto のままで使えます。なお、WebSocket の接続を張ったままにしていると、通信の量によってはアイドルと判定されず、最小レプリカ数が1でも通常の料金になることがあります。

Container Apps の環境を1つにまとめると、料金は安くなりますか？

Consumption プランだけで使う場合、環境そのものに料金はかからないため、まとめても料金はほとんど変わりません。Dedicated のワークロードプロファイルを使う場合は、環境全体に固定のプラン管理料金がかかるので、まとめる意味があります。環境を分けるかどうかは、ネットワークやログ、検証と本番の境界で決めることをお勧めします。

Azure Container Apps を選ぶか、Azure Functions や App Service で動かすかは、応答の速さの要件や処理の性質によって変わります。現在の構成や使い方をお聞かせいただければ、ホスティングの選び方から最小レプリカ数の決め方、監視の設計まで、設計案をご提案します。お問い合わせよりお気軽にご相談ください。