Azure App Serviceの設定まとめ｜環境変数・接続文字列・ログ・カスタムドメイン/TLS

Azure

App Serviceにアプリをデプロイできたら、次は「設定（構成）」の番です。「環境変数ってどこに書くの？」「接続文字列は普通のアプリ設定と何が違う？」「独自ドメインでHTTPS化したい」——このあたりは、動くアプリを実務で使えるアプリにするために避けて通れません。

デプロイはできたけど、環境変数やログ、独自ドメインの設定をどこで触るのか、いつもあやふや…

この記事では、App Serviceの「設定（構成）」を実務目線で整理します。読み終えたときに、次の6つを自分の言葉で説明・実践できるようになることをゴールにしています。

  • アプリ設定（環境変数）を構成できる
  • 接続文字列を構成できる
  • スタックバージョンを設定できる
  • スタートアップコマンドを設定できる
  • アプリログ／Webサーバーログを有効化できる
  • カスタムドメイン／TLS証明書の概念を理解している

各セクションの最後に「これが説明できればOK」という自己チェックの目安を置いています。App Serviceの概要は第1回、デプロイ手順は第2回で解説しています。

アプリ設定（環境変数）を構成する

アプリの挙動を変える値（APIキー、モード切替、外部サービスのURLなど）をコードに直接書かず、外から注入する——これがアプリ設定です。

App Serviceのアプリ設定は、キー／値のペアとして登録され、アプリの実行時に「環境変数」として読み込まれます。

ポイントは「アプリ設定 ＝ 環境変数として渡される」という点です。コード側では、いつもどおり環境変数を読むだけ（Pythonなら os.environ["KEY"]、Node.jsなら process.env.KEY）。ローカル開発では .env ファイル、本番ではApp Serviceのアプリ設定、と置き場所を分けるだけでコードは共通にできます。

# CLIでアプリ設定（環境変数）を追加
az webapp config appsettings set \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --settings MY_MODE="production" API_BASE_URL="https://api.example.com"

ポータルなら「構成（Configuration）」→「アプリケーション設定」から同じことができます。設定を変更するとアプリは自動的に再起動し、新しい値が反映されます。

【ここが説明できればOK①】
アプリ設定にキー／値を追加し、アプリ内から環境変数として参照できることを確認できれば、このチェックはクリアです。

接続文字列を構成する

データベースなどへの接続情報は、アプリ設定とは別に用意された「接続文字列（Connection strings）」セクションで管理できます。

アプリ設定でも接続情報は渡せるのに、なんで専用の「接続文字列」欄があるの？

理由は、種別（SQLServer / MySQL / PostgreSQL / Custom など）を指定できる点にあります。特に.NET系では、種別に応じてフレームワークが接続文字列を適切に扱ってくれます。接続文字列も最終的には環境変数として渡されますが（プレフィックス付き）、「DB接続はここ」と役割を分けておくと構成が読みやすくなります。

# 接続文字列を登録（種別を指定）
az webapp config connection-string set \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --connection-string-type SQLAzure \
  --settings MyDb="Server=tcp:...;Database=...;..."

なお、接続文字列にパスワードを直書きするのはセキュリティ上避けたいところ。Key Vaultからシークレットを注入する方法や、そもそもパスワードを使わないマネージドID接続があり、これらは本シリーズ第5回「認証・ID」で詳しく解説します。

【ここが説明できればOK②】
接続文字列を構成セクションに登録し、種別（SQL等）を指定してアプリから利用できれば、このチェックはクリアです。

スタックバージョンを設定する

アプリを動かすランタイムのバージョン（例: Python 3.12、Node 20、.NET 8）は、後から変更できます。言語のマイナーバージョンを上げたい、逆に古いバージョンに固定したい、といった場面で使います。

# Linuxのスタック（ランタイム）を設定
az webapp config set \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --linux-fx-version "PYTHON|3.12"

ポータルなら「構成」→「全般設定」→「スタック設定」で選択できます。設定後はアプリを再起動して、意図したバージョンで動いているかを確認しましょう。

【ここが説明できればOK③】
ランタイムスタックのバージョン（例: Python 3.x）を構成し、反映されることを確認できれば、このチェックはクリアです。

スタートアップコマンドを設定する

特にLinuxのApp Serviceでは、アプリをどう起動するかを明示する必要がある場合があります。これがスタートアップコマンドです。たとえばPython（Flask/Django）なら、WSGIサーバーの gunicorn をどう呼ぶかを指定します。

# スタートアップコマンドを設定（gunicornで起動）
az webapp config set \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --startup-file "gunicorn --bind=0.0.0.0 --timeout 600 app:app"

「デプロイはできたのにアプリが起動しない（502エラーなど）」というトラブルの多くは、このスタートアップコマンドの指定漏れ・誤りが原因です。フレームワークやエントリーポイント（app:app の部分）に合わせて正しく設定しましょう。

【ここが説明できればOK④】
スタートアップコマンド（gunicorn等）を設定し、意図どおりにアプリが起動することを確認できれば、このチェックはクリアです。

アプリログ／Webサーバーログを有効化する

トラブルシューティングの生命線がログです。App Serviceでは、大きく2種類のログを有効化できます。

  • アプリケーションログ：アプリのコードが出力したログ（print / console.log / ロガー出力）
  • Webサーバーログ：HTTPリクエストのアクセスログ（どのURLに、いつ、どんなステータスで応答したか）
# ログを有効化
az webapp log config \
  --resource-group rg-appservice \
  --name my-webapp-001 \
  --application-logging filesystem \
  --web-server-logging filesystem

# リアルタイムでログを流し見る（ログストリーム）
az webapp log tail \
  --resource-group rg-appservice \
  --name my-webapp-001

az webapp log tail（またはポータルの「ログストリーム」）を使えば、出力をリアルタイムで確認できます。「デプロイしたけど動かない」ときは、まずここを見るのが鉄則です。なお、より本格的な監視（Application Insights / Log Analyticsへの集約）は本シリーズ第6回で扱います。

【ここが説明できればOK⑤】
アプリログとWebサーバーログを有効化し、ログストリームで出力を確認できれば、このチェックはクリアです。

カスタムドメイン／TLS証明書の概念

最後に、独自ドメインでの公開とHTTPS化です。App Serviceは既定で <名前>.azurewebsites.net というURLを持ちますが、実務では www.example.com のような自社ドメインで公開したいことがほとんどです。流れは大きく2ステップです。

【カスタムドメイン + HTTPS化の流れ】

① DNS検証
   独自ドメインの管理画面で DNSレコードを追加
   ├ CNAME:  www → my-webapp-001.azurewebsites.net
   └ TXT:    所有権確認用のレコード（asuid.〜）
        │ Azureが「本当にあなたのドメインか」を検証
        ▼
② TLS証明書でHTTPS化
   ├ App Serviceマネージド証明書（無料・自動更新）★手軽
   └ 持ち込み証明書 / Key Vault連携の証明書
        │
        ▼
   https://www.example.com で安全に公開

まずDNS検証：独自ドメインのDNSに CNAME（App ServiceのURLへ向ける）と TXT（所有権確認）レコードを追加し、そのドメインが本当に自分のものであることをAzureに証明します。

次にTLS証明書でHTTPS化：一番手軽なのは App Serviceマネージド証明書で、無料かつ自動更新のHTTPSを設定できます。より要件が厳しい場合は、持ち込み証明書やKey Vault連携の証明書も使えます（Key Vault連携は第5回で触れます）。

【ここが説明できればOK⑥】
「カスタムドメインのDNS検証（CNAME/TXT）と、App Serviceマネージド証明書によるHTTPS化の流れ」を説明できれば、このチェックはクリアです。

まとめ

今回はApp Serviceの「設定（構成）」を、実務でよく触る順に整理しました。

  • アプリ設定 は環境変数として注入される。コードは環境変数を読むだけ
  • 接続文字列 は種別を指定できる専用セクション（DB接続向け）
  • スタックバージョン／スタートアップコマンド でランタイムと起動方法を制御
  • ログ はアプリログ＋Webサーバーログを有効化し、ログストリームで確認
  • カスタムドメイン はDNS検証（CNAME/TXT）→マネージド証明書でHTTPS化

設定が整ったら、次は認証・ID——マネージドIDやKey Vault参照でシークレットを安全に扱う方法——に進みましょう。次回（第5回）で解説します。その前に、閉域ネットワーク（VNet統合・Private Endpoint）を扱う第4回もぜひ。

あわせて読みたい

タイトルとURLをコピーしました