Azure App Serviceの実践ガイド｜Webアプリのデプロイから運用まで完全解説

「自社のWebアプリをクラウドに移行したいけれど、サーバー構築の手間やインフラ管理の負担が心配」――そんな悩みを抱えるIT担当者やエンジニアにとって、Azure App Serviceは最適な選択肢の一つです。

Azure App Serviceは、MicrosoftのクラウドプラットフォームAzure上で提供されるPaaS（Platform as a Service）で、Webアプリケーションのホスティングに特化したマネージドサービスです。OSのパッチ適用やロードバランサーの設定といったインフラ管理をAzureに任せながら、開発者はアプリケーションのコードに集中できます。

この記事では、Azure App Serviceの基本概念から、料金プランの選び方、実際のデプロイ手順、CI/CDパイプラインの構築、そして本番運用で欠かせない監視・スケーリング設定まで、実務で使える知識を体系的に解説します。

Azure App Serviceとは？PaaSとしての位置づけと特徴

Azure App Serviceは、Webアプリケーション、RESTful API、モバイルバックエンドをホストするためのHTTPベースのマネージドサービスです。IaaS（Infrastructure as a Service）と異なり、仮想マシンの管理やOSの保守は不要です。

App Serviceが解決する課題

従来のオンプレミス環境やIaaSでWebアプリを運用する場合、以下のような課題がありました。

サーバーの構築と保守：OSのインストール、セキュリティパッチの適用、ミドルウェアの設定など、アプリケーション開発以外の作業に多くの時間を取られる
スケーリングの複雑さ：アクセス増加時にサーバーを追加する作業が手動で、対応が遅れるとサービス停止のリスクがある
デプロイの煩雑さ：FTPでファイルをアップロードする、SSHで接続してgit pullする、といった手作業が残りやすい
SSL/TLS証明書の管理：証明書の取得、設定、更新を手動で行う必要がある

Azure App Serviceを利用すると、これらの作業の大部分がプラットフォーム側で自動化されます。開発者はコードを書いてデプロイするだけで、本番環境のWebアプリが稼働します。

対応言語とフレームワーク

App Serviceは、以下の主要な言語・フレームワークをネイティブでサポートしています。

.NET / .NET Core：C#によるASP.NET Coreアプリ
Node.js：Express、Next.jsなどのJavaScriptフレームワーク
Python：Django、Flaskなどのフレームワーク
Java：Spring Boot、Tomcatベースのアプリ
PHP：Laravel、WordPressなど
Ruby：Ruby on Railsアプリ

また、カスタムコンテナ（Docker）をデプロイすることも可能なため、上記以外の言語やランタイムも利用できます。

料金プラン（App Service Plan）の選び方

Azure App Serviceの料金は、App Service Planと呼ばれるコンピューティングリソースの単位で決まります。プラン選びを間違えると、不要なコストが発生したり、パフォーマンスが不足したりするため、要件に合った選定が重要です。

各プランの比較

主要なプランは以下のとおりです。

Free / Shared（F1 / D1）

開発・検証用途向け
共有インフラ上で動作するため、本番利用には不向き
カスタムドメインはSharedから利用可能、SSL証明書はBasic以上
月額：無料〜約1,000円

Basic（B1 / B2 / B3）

小規模な本番環境向け
専用のコンピューティングインスタンスが割り当てられる
手動スケーリング（最大3インスタンス）に対応
月額：約8,000円〜

Standard（S1 / S2 / S3）

中規模の本番環境向け
自動スケーリング（最大10インスタンス）に対応
デプロイスロット、日次バックアップ、VNet統合が利用可能
月額：約12,000円〜

Premium v3（P1v3 / P2v3 / P3v3）

高トラフィックな本番環境向け
より高性能なCPU・メモリ、最大30インスタンスへの自動スケーリング
プライベートエンドポイント対応
月額：約15,000円〜

プラン選定の判断基準

プラン選定では、以下の観点を考慮します。

トラフィック量：月間PV数やAPI呼び出し回数から、必要なCPU・メモリを見積もる
可用性要件：SLAが必要ならBasic以上、自動スケーリングが必要ならStandard以上
デプロイ戦略：ブルーグリーンデプロイを行うならStandard以上（デプロイスロットが必要）
ネットワーク要件：VNet統合やプライベートエンドポイントが必要ならStandardまたはPremium

コストを最適化したい場合は、クラウドコスト削減の方法も参考にしてください。Azure Reservations（1年または3年の予約）を利用すると、従量課金に比べて最大55%の割引が適用されます。

App Serviceの作成とWebアプリのデプロイ手順

ここからは、Azure PortalとAzure CLIの両方を使ったApp Serviceの作成手順を解説します。

Azure CLIによる作成

Azure CLIを使うと、コマンドラインからリソースを一括作成できます。以下は、Node.jsアプリをデプロイする例です。

# リソースグループの作成
az group create --name rg-myapp-prod --location japaneast

# App Service Planの作成
az appservice plan create \
  --name plan-myapp-prod \
  --resource-group rg-myapp-prod \
  --sku S1 \
  --is-linux

# Web Appの作成
az webapp create \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --plan plan-myapp-prod \
  --runtime "NODE:20-lts"

リソースグループ名やApp名には、環境（prod / stg / dev）を含めた命名規則を統一しておくと、運用時の管理が容易になります。

GitHubからの直接デプロイ

Azure PortalのDeployment Center機能を使えば、GitHubリポジトリとApp Serviceを連携させ、pushをトリガーにした自動デプロイを構成できます。

Azure Portalで対象のApp Serviceを開く
左メニューの「デプロイメントセンター」をクリック
ソースとして「GitHub」を選択し、リポジトリとブランチを指定
ビルドプロバイダーとして「GitHub Actions」を選択
設定を保存すると、リポジトリにGitHub Actionsのワークフローファイルが自動生成される

この設定により、mainブランチへのpushをトリガーに、ビルドとデプロイが自動実行されます。

Azure CLIによるZipデプロイ

CI/CDパイプラインを使わず、手動でデプロイしたい場合はZipデプロイが便利です。

# アプリケーションをZipに圧縮
zip -r deploy.zip . -x "node_modules/*" ".git/*"

# Zipデプロイの実行
az webapp deploy \
  --resource-group rg-myapp-prod \
  --name myapp-prod-001 \
  --src-path deploy.zip \
  --type zip

Zipデプロイは、ビルド済みのアーティファクトをそのままデプロイするため、ビルド環境の差異によるトラブルを避けられます。

デプロイスロットを活用したブルーグリーンデプロイ

本番環境のダウンタイムをゼロにしてデプロイを行いたい場合、デプロイスロット機能が役立ちます。Standard以上のプランで利用可能です。

デプロイスロットの仕組み

デプロイスロットは、本番スロットとは別のURLを持つ独立した環境です。新しいバージョンのアプリケーションをステージングスロットにデプロイし、動作確認後に本番スロットと「スワップ」することで、ダウンタイムなしのデプロイを実現します。

# ステージングスロットの作成
az webapp deployment slot create \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --slot staging

# ステージングスロットへのデプロイ
az webapp deploy \
  --resource-group rg-myapp-prod \
  --name myapp-prod-001 \
  --slot staging \
  --src-path deploy.zip \
  --type zip

# スワップの実行
az webapp deployment slot swap \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --slot staging \
  --target-slot production

スロット固有の設定

環境変数（アプリケーション設定）には、「デプロイスロットの設定」というチェックボックスがあります。これを有効にすると、スワップ時にその設定値はスロットに固定され、入れ替わりません。

典型的な使い分けは以下のとおりです。

スロット固有にする設定：データベース接続文字列（本番とステージングでDBが異なる場合）、環境識別フラグ（ENVIRONMENT=production / staging）
スロット固有にしない設定：アプリケーションの機能フラグ、APIキーなど、環境に依存しない設定値

カスタムドメインとSSL/TLS証明書の設定

本番運用では、独自ドメインの設定とHTTPS化は必須です。App ServiceではApp Service マネージド証明書を使って無料でSSL/TLS証明書を取得・設定できます。

カスタムドメインの追加手順

DNSプロバイダーで、CNAMEレコードまたはAレコードをApp Serviceのデフォルトドメイン（myapp-prod-001.azurewebsites.net）に向ける
Azure Portalで「カスタムドメイン」メニューを開き、ドメインを追加
DNS検証が完了するまで待機（通常は数分〜数十分）

# Azure CLIでカスタムドメインを追加
az webapp config hostname add \
  --webapp-name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --hostname www.example.com

マネージド証明書の設定

App Serviceマネージド証明書は、Basic以上のプランで無料で利用できます。証明書の発行と更新はAzureが自動で行うため、運用の手間がかかりません。

# マネージド証明書の作成とバインド
az webapp config ssl create \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --hostname www.example.com

# HTTPSの強制（HTTPからHTTPSへのリダイレクト）
az webapp update \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --https-only true

--https-only trueを設定すると、HTTPでのアクセスが自動的にHTTPSにリダイレクトされます。セキュリティの観点から、本番環境では必ず有効にしましょう。

自動スケーリングの設定とパフォーマンス最適化

App ServiceのStandard以上のプランでは、CPU使用率やHTTPリクエスト数などのメトリクスに基づいて、インスタンス数を自動で増減させる自動スケーリングが利用できます。

自動スケーリングルールの設定

Azure PortalのApp Service Plan画面から「スケールアウト」を選び、ルールベースのスケーリングを構成します。

推奨される基本設定は以下のとおりです。

スケールアウト条件：CPU使用率が70%を超えた状態が5分間継続したら、インスタンスを1つ追加
スケールイン条件：CPU使用率が30%を下回った状態が10分間継続したら、インスタンスを1つ削減
インスタンス数の範囲：最小2、最大10（可用性を確保するため最小を2以上にする）

スケールイン条件をスケールアウト条件よりも緩やかに設定するのがポイントです。頻繁なスケールイン・スケールアウトの繰り返し（フラッピング）を防ぐためです。

パフォーマンス最適化のベストプラクティス

スケーリング以外にも、以下の設定でパフォーマンスを改善できます。

Always On：アイドル時にアプリがアンロードされるのを防ぐ（Basic以上で利用可能）
ARRアフィニティの無効化：ステートレスなアプリでは、セッションアフィニティを無効にすることでリクエストが均等に分散される
HTTP/2の有効化：多重化により、複数のリクエストを同時処理できる
ローカルキャッシュの有効化：アプリケーションのコンテンツをローカルディスクにキャッシュし、ストレージへのI/Oを削減

# Always Onの有効化
az webapp config set \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --always-on true

# ARRアフィニティの無効化
az webapp update \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --client-affinity-enabled false

# HTTP/2の有効化
az webapp config set \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --http20-enabled true

監視・ログ設定とトラブルシューティング

本番環境の安定運用には、適切な監視とログ設定が不可欠です。App ServiceはAzure MonitorおよびAzure Monitorの活用と連携して、アプリケーションの正常性を可視化できます。

Application Insightsの統合

Application Insightsは、アプリケーションのパフォーマンスと可用性を監視するためのAPM（Application Performance Management）サービスです。App Serviceとの統合は数クリックで完了します。

リクエストの応答時間：各エンドポイントの平均応答時間と95パーセンタイル
失敗したリクエスト：HTTPステータスコード別のエラー率
依存関係の呼び出し：データベースや外部APIへの呼び出し時間と成功率
例外の追跡：アプリケーション内で発生した例外のスタックトレース

診断ログの有効化

# アプリケーションログの有効化（ファイルシステムへの出力）
az webapp log config \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --application-logging filesystem \
  --level information

# ログのリアルタイムストリーミング
az webapp log tail \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod

az webapp log tailコマンドを使うと、ローカルのターミナルでリアルタイムにログを確認できます。デプロイ直後の動作確認やエラー調査に便利です。

ヘルスチェックの設定

ヘルスチェックを有効にすると、App Serviceが定期的に指定のパスにHTTPリクエストを送信し、アプリケーションの正常性を確認します。異常が検出されたインスタンスは自動的にトラフィックから除外されます。

# ヘルスチェックパスの設定
az webapp config set \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --generic-configurations '{"healthCheckPath": "/api/health"}'

ヘルスチェックエンドポイントでは、アプリケーション自体の状態だけでなく、データベースやキャッシュなどの依存サービスの接続状態も確認するように実装しましょう。

セキュリティとネットワーク設定のベストプラクティス

App Serviceを安全に運用するために、以下のセキュリティ設定を本番環境では必ず行いましょう。

認証・認可の設定

App Serviceには「Easy Auth」と呼ばれる組み込みの認証機能があります。Microsoft Entra ID（旧Azure AD）やGoogle、GitHubなどのIDプロバイダーを使って、コードを変更せずにアプリケーションに認証を追加できます。

社内向けアプリケーションの場合、Microsoft Entra IDと連携してSSO（シングルサインオン）を構成することで、ユーザーは社内アカウントでそのままログインできるようになります。

ネットワークセキュリティ

アクセス制限：特定のIPアドレスやVNetからのアクセスのみを許可するルールを設定する
VNet統合：App ServiceからAzure Virtual Network内のリソース（データベース、キャッシュなど）に安全にアクセスする
プライベートエンドポイント：App Serviceへのアクセスを完全にプライベートネットワーク内に制限する（Premium v3で利用可能）
マネージドID：接続文字列やAPIキーをアプリケーション設定に直接書く代わりに、マネージドIDを使ってAzureリソースに安全にアクセスする

# マネージドIDの有効化
az webapp identity assign \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod

# IPアドレスによるアクセス制限の追加
az webapp config access-restriction add \
  --name myapp-prod-001 \
  --resource-group rg-myapp-prod \
  --priority 100 \
  --rule-name "AllowOfficeIP" \
  --ip-address 203.0.113.0/24

インフラの構成管理を自動化したい場合は、TerraformによるIaC（Infrastructure as Code）の導入も検討してください。App Serviceの設定をコードとして管理することで、環境の再現性が高まり、設定ミスの防止にもつながります。