Azure App ServiceはMicrosoft AzureのフルマネージドなPaaS（Platform as a Service）で、WebアプリやAPI、コンテナをサーバーの構築・運用なしにデプロイして動かせます。実装で最初に押さえるのは、計算リソースの単位であるApp Service Plan、Free〜Isolated v2という価格レベルの段階、デプロイスロットによる無停止リリースの3点です。この記事では、価格レベルが料金と性能をどう左右するか、az CLIでの作成とスワップの手順、Static Web Apps・Container Apps・AKSとの違い、採用と見送りの判断基準までを、2026年9月時点の公式ドキュメントを一次情報として整理します。
まとめ：Azure App Serviceの要点と採用判断の分岐
Azure App Serviceは、WindowsとLinuxの両方で動くマネージドなWebアプリ実行基盤です。OSやミドルウェアのパッチ、負荷分散、スケーリングをプラットフォーム側が引き受けるため、実装者はアプリのコードとデプロイに集中できます。動く土台はApp Service Planという計算リソースの単位で、そのプランの価格レベル（Free〜Isolated v2）を選ぶ判断が、料金・性能・使える機能を同時に決める分岐点です。Microsoft Learnのプラン解説では、価格レベルが共有コンピューティング（Free、Shared）・専用コンピューティング（Basic〜PremiumV4）・Isolated（IsolatedV2）の3カテゴリに整理されています。
採用が合理的なのは、Webアプリ・APIを短期間で公開し、サーバー管理を持たずにマネージドへ寄せたい場合です。逆に、静的サイト中心ならStatic Web Apps、コンテナを細かく動かすならContainer Apps、Kubernetesの全機能が要るならAKSが向きます。どの基盤を組むべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。
Azure App Serviceの仕組みとApp Service Planの関係
App Serviceを理解する起点は、アプリ本体（Web App）と、その実行基盤（App Service Plan）を分けて考えることです。この2つの関係を押さえると、料金もスケーリングも一本の筋で読めます。
フルマネージドなPaaSとしてのApp Serviceの立ち位置
App Serviceは、Webアプリのホスティングに必要なOS・言語ランタイム・Webサーバー・負荷分散をまとめて提供するPaaSです。仮想マシン（Azure VM）を自分で立ててミドルウェアを入れる方式と違い、インフラの保守はAzure側が担い、実装者はコードのデプロイと設定に専念できます。対象はサーバーサイドで動く動的なWebアプリケーション、REST API、そしてコンテナ化したアプリ（Web App for Containers）です。
App Service Planが確保する計算リソースと課金の単位
アプリが実際に動くのは、App Service Planが確保する仮想マシン群の上です。プランはリージョン・OS・価格レベル（SKU）・インスタンス数を持つ単位で、1つのプランに複数のアプリを同居させられます。公式ドキュメントは「同じプラン内に置いたアプリは専用リソースを互いに共有する」と明記しており、専用になるのはアプリ単位ではなくプラン単位です。小さなアプリを1プランに集約すればコストを圧縮でき、負荷の高いアプリは専用プランに分ける自由度がここにあります。
縦方向のスケールアップと横方向のスケールアウトという性能調整の軸
性能の調整には2つの方向があります。スケールアップは価格レベルを上げてvCPUやメモリを増やす縦方向の強化、スケールアウトはインスタンス数を足す水平方向です。自動スケールが使えるのはStandard以上で、FreeとSharedはスケールアウトできません。この2軸の組み合わせが、コストと応答性を両立させる基本になります。
Azure CLIでプランとWebアプリを作成して動かすまでの手順
最小構成なら、リソースグループ・プラン・アプリの3つを作るだけで公開まで届きます。ランタイム文字列は環境で増減するため、list-runtimes の出力から選んで指定してください。
# リソースグループとApp Serviceプランを作る（Linux・Premium v4）
az group create --name rg-appsvc-demo --location japaneast
az appservice plan create \
--resource-group rg-appsvc-demo \
--name plan-appsvc-demo \
--sku P1V4 \
--is-linux
# 指定できるランタイム文字列を確認してから webapp を作る
az webapp list-runtimes --os linux
az webapp create \
--resource-group rg-appsvc-demo \
--plan plan-appsvc-demo \
--name app-appsvc-demo \
--runtime "$RUNTIME"
ここで --sku に指定した値がそのまま価格レベルになります。プランを作り直さずに層を変えるときは az appservice plan update でSKUを差し替えます。
Free・Standard・Premium v4・Isolated v2という価格レベル
App Serviceの費用と使える機能は、価格レベルの選択でほぼ決まります。層が上がるほど機能が解放され、単価も上がる構造です。設計段階でここを取り違えると、動いてから性能不足やコスト超過に直面します。
各プラン層が担う役割と、段階的に解放されていく機能の違いの整理
2026年9月時点の主な価格レベルと、公式のサービス上限表に載っている実数を並べると次のようになります。
| 層 | 主な用途 | スロット数 | 最大インスタンス |
|---|---|---|---|
| Free / Shared | 試用・お試し | なし | 1（共有） |
| Basic | 開発・検証 | なし | 3 |
| Standard | 小〜中規模の本番 | 5 | 10 |
| Premium v2〜v4 | 高負荷の本番 | 20 | 30 |
| Isolated v2 | 閉域・分離要件 | 20 | 100 |
FreeとSharedはプラットフォームを試す段階向けで、自動スケールもデプロイスロットも持ちません。Basicは開発・検証向けで、ここから専用インスタンスになります。Standardは小〜中規模の本番向けで、自動スケール・日次バックアップ・カスタムドメインとTLS証明書がそろう層です。Premiumは高負荷向け、Isolated v2はApp Service Environment上で専用の仮想ネットワークに隔離され、ネットワーク分離の要件に対応します。SLAはBasic以上で99.95%です。
Premium v4で入れ替わった価格レベルと移行前に見る条件
公式の価格レベル一覧にはPremiumV4が加わっており、Premium v4の構成手順では、より速いプロセッサ・NVMeローカルストレージ・メモリ拡張型のサイズが示されています。メモリとコアの比率は以前の層の最大2倍で、少ないインスタンス数で同じ負荷をさばける設計です。--sku に指定できるのはP0V4〜P3V4と、メモリ拡張型のP1mV4〜P5mV4を合わせた9種類です。
ただし移行前に見るべき条件が3つあります。第一に、Premium v4はWindowsコンテナーでは使えません。第二に、安定した送信IPアドレスを持たず、ARMやCLIの outboundIpAddresses は空文字列を返します。固定の送信IPが要件ならNATゲートウェイ統合を併用してください。第三に、対応リージョンが限られており、日本では日本東（Japan East）が一覧に含まれる一方で日本西は含まれていません。
# 目的のリージョンでSKUが使えるかを事前に確認する（CLI 2.73.0以降）
az appservice list-locations --linux-workers-enabled --sku P1V4
# Premium v4 では送信IPが空文字で返る（固定IP前提の設計は破綻する）
az webapp show \
--resource-group rg-appsvc-demo \
--name app-appsvc-demo \
--query outboundIpAddresses -o tsv
プラン単位の固定費が月々の全体コストを決めるという基本の考え方
課金はプラン単位の固定費が主軸で、待機中もインスタンスを確保している限りコストが発生します。従量ではないため、必要な性能ちょうどの層を選び、複数の小規模アプリを1プランに集約し、負荷変動には自動スケールで台数を増減させる、という三点がコスト設計の勘所です。恒常負荷が読める場合は予約容量で単価を下げられます。リージョン別の単価はApp Serviceの価格ページで確認してください。デプロイスロットやカスタムドメインの構成そのものには追加料金がかからない一方、IPベースのTLS接続は時間単位で課金されます。
価格レベルごとのスケールアウト台数とストレージ容量を上限表で確かめる
上限表には台数以外の枠も載っています。ストレージ枠はFreeが1GB、Basicが10GB、Standardが50GB、Premiumが250GB、Isolatedが1TB（利用可能なクォータは999GB）です。バックアップはBasic・Standardが2時間ごと（1日最大12回）、Premium・Isolatedが1時間ごと（1日最大50回）に分かれます。アプリのログやコンテナレジストリ（ACR）から引くイメージのサイズもこの枠を消費するため、層を下げる判断では台数だけでなく容量側も突き合わせてください。
デプロイスロットによる無停止リリースと対応ランタイム・連携機能
App Serviceを実装で選ぶ決め手は、無停止リリースと連携機能の手厚さです。ここが仮想マシン運用との差になります。
デプロイスロットのスワップ操作による無停止リリースを実現する仕組み
Standard以上では、本番とは別の「デプロイスロット」に新バージョンを先に配置し、温めてから本番と入れ替える（スワップ）方式を取れます。公式のステージング環境の手順によると、スワップはターゲットスロットの設定をソーススロットへ当てて再起動し、全インスタンスがウォームアップを終えてからルーティング規則を切り替える多段の操作です。ターゲット側は最後まで稼働したままなので、失敗しても本番は落ちません。問題が出たら同じ2つをもう一度スワップすれば即座に戻せます。スロット自体は追加料金なしで使えます。
az webappコマンドでスロットを作成してスワップを実行する
スワップは一気に実行せず、第1フェーズで止めて本番設定を当てた状態を検証してから完了させる進め方が安全です。取り消しは --action reset で行えます。
# ステージングスロットを作る
az webapp deployment slot create \
--resource-group rg-appsvc-demo \
--name app-appsvc-demo \
--slot staging
# 第1フェーズだけ実行し、本番設定を当てた状態で検証する
az webapp deployment slot swap \
--resource-group rg-appsvc-demo \
--name app-appsvc-demo \
--slot staging --target-slot production --action preview
# 検証が通ったらスワップを完了する（戻すときは --action reset）
az webapp deployment slot swap \
--resource-group rg-appsvc-demo \
--name app-appsvc-demo \
--slot staging --target-slot production --action swap
ソーススロットのどれか1台でも再起動に失敗すると、変更は巻き戻されて操作が止まります。ウォームアップのHTTP要求は1回90秒待って最大5回再試行し、すべてタイムアウトすると操作は中断されます。なお、いずれかのスロットでサイト認証が有効なときは、プレビュー付きスワップを使えません。
スワップで入れ替わる設定とスロットに固定される設定の切り分け
スワップ事故の大半は、入れ替わる設定と残る設定の取り違えから起きます。公式ドキュメントの分類は次のとおりです。
| 区分 | 代表的な設定 |
|---|---|
| 入れ替わる | 言語ランタイムの版・アプリ設定 |
| 入れ替わる | 接続文字列・ハンドラーマッピング |
| スロットに残る | カスタムドメイン・TLS設定 |
| スロットに残る | スケール設定・IP制限・常時オン |
| スロットに残る | マネージドID・仮想ネットワーク統合 |
アプリ設定は既定で入れ替わるため、環境ごとに変えたい値は --slot-settings でスロットに固定します。ウォームアップのping先と合格ステータスもアプリ設定で制御できます。
# ウォームアップのping先と合格ステータスを指定する
az webapp config appsettings set \
--resource-group rg-appsvc-demo \
--name app-appsvc-demo --slot staging \
--settings WEBSITE_SWAP_WARMUP_PING_PATH=/healthz \
WEBSITE_SWAP_WARMUP_PING_STATUSES=200,204
# 環境ごとに変える値はスロットへ固定して入れ替えない
az webapp config appsettings set \
--resource-group rg-appsvc-demo \
--name app-appsvc-demo --slot staging \
--settings APP_ENV=staging --slot-settings APP_ENV
組み込みで提供される対応ランタイムとコンテナ実行への対応範囲
App Serviceは、.NET・Java・Node.js・Python・PHP・Ruby（Linux）といった主要言語のランタイムを組み込みで提供します。さらにWeb App for Containersを使えば、独自のDockerイメージをそのままデプロイでき、既製ランタイムに収まらない構成にも届きます。言語ランタイムの版はプラットフォーム側で保守されるため、ミドルウェアの更新負担を抱えずに済む形です。なお自動スワップはLinux上のWebアプリとWeb App for Containersで未対応なので、コンテナ運用ではCI側からスワップを叩く設計にしてください。
認証・ネットワーク・監視まわりでそろう標準的な連携機能の数々
運用に効く機能も標準装備です。App Service認証（Easy Auth）を使えば、Microsoft Entra IDの仕組みを解説した記事で扱うIDプロバイダーによるサインインを、コードを書かずに前段へ差し込めます。仮想ネットワーク統合とプライベートエンドポイントで閉域接続を組め、マネージドIDとKey Vaultによるシークレット管理を合わせれば接続先の資格情報をコードから排除できます。監視はApplication Insightsの仕組みを解説した記事で扱う機能とApp Service作成時から連携でき、応答時間や例外の可視化まで届く設計です。GitHub ActionsやAzure Pipelinesからの継続的デプロイも標準で組み込めます。
Static Web Apps・Container Apps・AKSとの違い
App ServiceはAzure内の似たホスティングサービスと混同されやすい領域です。それぞれの守備範囲を押さえると、単独で使うか組み合わせるかの判断がつきます。
Static Web Appsとの違いは静的配信か動的処理かで分かれる
Static Web Appsは、フロントエンドの静的コンテンツ配信とAzure FunctionsによるAPIを組み合わせるJAMstack向けのサービスです。対してApp Serviceが対象にするのは、サーバーサイドで動く動的なWebアプリケーション全般です。フロントがReactやVueで、APIも軽量なサーバーレスで足りるならAzure Static Web Appsの料金と特性を解説した記事で扱う構成が向き、常時稼働のサーバーサイド処理やデータベース連携が中心ならApp Serviceが適します。料金差の比較検討でよく並べられる2サービスですが、狙う用途がそもそも異なります。
Container AppsやAKSとの違いはマネージドの度合いにある
コンテナを動かす選択肢はApp Serviceだけではありません。Azure Container Appsとは何かを解説した記事で扱うサービスは、マイクロサービスやイベント駆動のコンテナをKEDAでゼロまで縮退させながら動かす基盤で、複数サービスの分散構成に向きます。さらに細かくKubernetesの全機能を握りたいならAKS（Azure Kubernetes Service）の始め方を解説した記事のクラスタ運用が候補です。App Serviceは、単一のWebアプリを最小の運用で動かすマネージドPaaSという位置づけです。運用の自由度と引き換えに管理負荷が増える順に、App Service→Container Apps→AKSと並べて捉えると選定しやすくなります。
Azure App Serviceを採用すべき場面と見送るべき場面
ここからは判断です。App Serviceは万能の基盤ではなく、向く用途と向かない用途が分かれます。要件から逆算し、条件付きで採否を言い切ります。
App Serviceの採用が第一候補として合理的になる主なケースの条件
次のいずれかに該当するなら、App Serviceが第一候補になります。
- サーバーサイドのWebアプリやAPIを、インフラ運用を持たず短期間で公開したい
- デプロイスロットのスワップで、無停止のリリースとロールバックを回したい
- 認証・TLS・自動スケール・監視をプラットフォーム標準で手早くそろえたい
- 既製ランタイムか単一のコンテナで動く構成で、クラスタ管理を避けたい
いずれもマネージド運用の強みが効く領域です。サーバー保守の人手を割けない現場なら、Freeで試作して本番でStandard以上へ引き上げる進め方が実装のハードルを下げます。
App Serviceを選ぶべきでない場面と代わりに選ぶ移行先の判断
一方で、次の要件にはApp Serviceを選びません。ここを混同すると設計が破綻します。第一に、静的サイト中心でサーバーサイド処理が薄いなら、常時稼働のプラン費用が割高で、Static Web Appsの領分です。第二に、多数のマイクロサービスをイベント駆動でゼロ縮退させたいなら、Container Appsが適します。第三に、サービスメッシュや独自のスケジューリングが要る大規模基盤なら、AKSのクラスタ運用を選ぶべきです。第四に、待機時間が長く実行が散発的な軽量処理だけなら、常時課金のApp Serviceより従量課金で動くAzure Functionsのほうが費用面で有利になります。
送信IP・自動スワップ・リージョンで詰まりやすい実装前の確認
設計レビューで拾い切れずに実装後へ持ち越されやすい制約が3つあります。1つ目は送信IPです。Premium v4は固定の送信IPを返さないため、接続先で許可リストを組む要件があるならNATゲートウェイを前提に置きます。2つ目は自動スワップの対象外で、Linux上のWebアプリとWeb App for ContainersはCI側から明示的にスワップを実行する形です。3つ目はリージョン差で、価格レベルによって使える場所が違うため、az appservice list-locations の結果を設計時に確認してください。COMコンポーネントやMSIインストーラーに依存するレガシーなWindowsアプリ向けにはManaged Instanceという選択肢もありますが、Pv4／Pmv4限定・Windowsのみ・日本リージョン未対応（2026年9月時点）という条件が付きます。
受託開発におけるクラウド基盤の設計相談と外注先の選定における勘所
実際のシステムでは、App Service単体ではなくデータベース・ストレージ・認証基盤・監視を役割ごとに組み合わせる構成が普通です。どのアプリをどの価格レベルに載せ、どこを閉域にし、どのスロット構成でリリースするかは、負荷・可用性要件・月次コストのトレードオフで決まり、運用開始後のプラン変更やIsolatedへの移行には相応の手間が伴います。Azureを含むクラウド基盤の構築・移行の相談では、ホスティング方式の選定を含めた設計から実装・運用までを一貫して支援できます。
よくある質問
Azure App Serviceの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。
Azure App ServiceとStatic Web Appsはどう違いますか？
対象とする用途が異なります。App Serviceはサーバーサイドで動く動的なWebアプリやAPIを常時稼働で動かすPaaSです。Static Web Appsは静的なフロントエンドの配信とFunctionsによる軽量APIを組む構成に向きます。データベース連携やサーバーサイドレンダリングが中心ならApp Serviceを選びます。
App Service Planとは何ですか？
アプリが動く計算リソースの単位です。リージョン・OS・価格レベル・インスタンス数を持ち、1つのプランに複数のアプリを同居させられます。課金はアプリ単位ではなくプラン単位で発生するため、小規模なアプリを集約してコストを抑える設計が取れます。
デプロイスロットは何に使いますか？
無停止のリリースとロールバックのために使う仕組みです。本番とは別のスロットに新バージョンを先に配置して動作を確認し、スワップで入れ替えることで、ダウンタイムをほぼ出さずに切り替えられます。問題があれば同じ2つをもう一度スワップして戻せるため、ブルーグリーンデプロイの土台になります。スロット数は公式の上限表でStandardが5、PremiumとIsolatedが20です。
料金はどのプランを選べばよいですか？
用途で分かれます。試作はFree／Shared、開発・検証はBasic、小〜中規模の本番はStandard、恒常的に高負荷がかかる本番はPremium、ネットワーク分離が要る場合はIsolated v2が目安です。課金はプラン単位の固定費が主軸で待機中もかかるため、必要な性能ちょうどの層を選び、複数アプリの集約と自動スケール、恒常負荷なら予約割引でコストを詰めます。
コンテナで動かすこともできますか？
できます。Web App for Containersを使えば、独自に用意したDockerイメージをそのままデプロイできます。既製の言語ランタイムに収まらない構成に向く方式です。ただし多数のコンテナを独立にスケールさせるならContainer Apps、Kubernetesの全機能が要るならAKSが適します。なおPremium v4はWindowsコンテナーに未対応です。
Premium v3とPremium v4はどちらを選ぶべきですか？
対象リージョンでPremium v4が使えるなら、新規はv4から検討してかまいません。メモリとコアの比率が最大2倍になり、同じ負荷を少ない台数でさばける設計だからです。ただしv4は固定の送信IPを返さず、Windowsコンテナーにも未対応です。許可リストやWindowsコンテナーの要件があるなら、NATゲートウェイの併用かv3の継続を選びます。
関連記事
- Azure Static Web Appsの料金｜Freeと有料Standardの違い・費用を実額で解説【2026年版】：静的サイト側の対応物として、用途の違いを読み比べられます。
- Azure Container Appsとは？特徴・料金・デプロイ手順とAKS・App Serviceの違い：コンテナ実行の選択肢として設計思想を対比できます。
- AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】：Kubernetes運用との管理負荷の違いを押さえられます。
- Application Insightsとは？機能・料金・導入手順とLog Analyticsとの違い【2026年版】：組み合わせる監視の仕組みを確認できます。
- Azure Virtual Machinesとは？仕組み・VMシリーズ・料金モデルと可用性設計を実装者目線で解説：IaaSで動かす場合の運用負荷と比較できます。
