本記事は Microsoft Learn の「Webアプリの設定を構成する」というモジュールをまとめたものである。
アプリケーション設定の構成
App Service におけるアプリ設定は、アプリケーションコードに環境変数として注入される動的な変数。ソースコードを書き換えることなく、実行環境に応じた設定の切り替えや機密情報の管理を可能にする。
動作原理と挙動
-
注入メカニズム:Linux アプリやカスタムコンテナーの場合、内部的に
--envフラグを用いてコンテナー内に環境変数が設定される - 再起動のトリガー:設定の追加、削除、編集を行うと、変更を反映させるためにアプリの再起動が自動で実行される
- セキュリティ:すべてのアプリ設定は保存時に暗号化(保存時の暗号化)され、安全に保護される
開発環境と本番環境の切り分け
- 設定のオーバーライド:App Service 上の値は、ローカルの appsettings.json や Web.config よりも優先される
- コードの共通化:ローカル開発時はローカルの設定ファイルを参照し、Azure デプロイ後は App Service の設定を参照するため、環境ごとにコードを書き分ける必要がない
- 機密情報の分離:ローカルパスワードは手元のファイルに、本番用シークレットは Azure 上に保存することで、セキュリティリスクを最小化できる
設定のルールとアクセス方法
- 命名規則:使用可能な文字は、英数字、ピリオド(.)、アンダースコア(_)のみ
- エスケープ:特殊文字を含む値は、ターゲット OS(Windows/Linux)の仕様に合わせて適切にエスケープする必要がある
設定の追加と編集
App Service の管理画面から新しい環境変数を定義し、その変数がデプロイスロット間での入れ替え(スワップ)の対象になるかどうかを制御できる。
設定の追加手順
- 新規作成:[環境変数] 画面の [アプリケーションの設定] タブにある [+ 追加] ボタンから新しい設定項目を作成する
- 入力項目:「名前」と「値」を入力し、必要に応じてスロット設定の有無を選択する
デプロイスロット設定(スロット固有設定)
-
スワップ制御:デプロイスロット(例:Staging と Production)を入れ替える際、設定値をスロットと一緒に移動させるか、そのスロットに固定するかを選択可能
-
「デプロイスロット設定」のチェック:
- チェックあり(固定):設定はそのスロットに固有のものとなる。スワップしても値は移動せず、そのスロットに残り続ける(例:接続先データベースの切り替え防止)
- チェックなし(スワップ可能):スワップ時に設定値も一緒に移動する。本番環境に反映させたい新しい構成値などに適している
接続文字列の構成
App Service では、データベースへの接続情報を「環境変数」として管理できる。これにより、ソースコードの中にパスワードなどを直接書かずに済む。
設定のルール
- 上書き機能:App Service 上で設定した値は、コード内の設定ファイル(Web.config など)の値よりも優先(オーバーライド)される
- 基本は「アプリ設定」を推奨:ASP.NET 以外の言語(Python, Node.js, Go など)を使う場合は、特殊な形式を避けるため、通常の「アプリ設定」を使うのが一般的
実行時の仕組み(環境変数への変換)
設定した接続文字列は、実行時に「種類」に応じたプレフィックス(接頭辞)が付いた環境変数に自動変換される。
| 種類 (Type) | 付加されるプレフィックス | 例 |
|---|---|---|
| SQL Server | SQLCONNSTR_ | SQLCONNSTR_MyDb |
| MySQL | MYSQLCONNSTR_ | MYSQLCONNSTR_MyDb |
| PostgreSQL | POSTGRESQLCONNSTR_ | POSTGRESQLCONNSTR_MyDb |
| カスタム | CUSTOMCONNSTR_ | CUSTOMCONNSTR_MyDb |
JSON による一括管理
複数の接続文字列を定義する場合、以下の形式の JSON 配列を用いて一括編集が可能。
-
name:接続文字列の識別名 -
value:接続文字列本体 -
type:データベースの種類(SQLServer, MySQL 等) -
slotSetting:スロット固有設定にするかどうかの真偽値
[
{
"name": "name-1",
"value": "conn-string-1",
"type": "SQLServer",
"slotSetting": false
},
{
"name": "name-2",
"value": "conn-string-2",
"type": "PostgreSQL",
"slotSetting": false
},
...
]
カスタムコンテナーの環境変数を構成する
自分で作成したコンテナを App Service で動かす際、外部から設定値(環境変数)を渡すことができる。
設定のポイント
- 自動挿入:Azure ポータルや CLI で設定した「アプリ設定」は、コンテナー起動時に自動的に環境変数としてプロセスに注入される
-
コマンドでの設定方法
-
Bash (Azure CLI):
az webapp config appsettings setコマンドを使用
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings key1=value1 key2=value2-
PowerShell:
Set-AzWebAppコマンドを使用
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"} -
Bash (Azure CLI):
-
確認方法:アプリ実行中、特定の管理用URL(
https://<アプリ名>.scm.azurewebsites.net/Env)にアクセスすると、現在適用されている環境変数の一覧を確認できる
全般設定の構成
Azure portal の [構成] > [全般設定] では、アプリの動作基盤に関する重要な設定を行える。一部の機能は有料プラン(Basic 以上など)へのアップグレードが必要。
1. 実行環境の設定
-
スタック設定:使用する言語(Python, Node.js 等)や SDK のバージョンを指定。Linux やコンテナーでは起動コマンドの設定も可能

-
プラットフォームビット数:32bit または 64bit を選択(Windows 専用)
2. 通信・プロトコルの設定
- HTTPS のみ:すべての通信を HTTPS に強制リダイレクト
- 最小 TLS バージョン:セキュリティ向上のため、古い TLS 接続を拒否
- HTTP バージョン:最新の HTTP/2 を有効化可能
- Web Socket:リアルタイム通信(チャット等)が必要な場合にオンにする
- FTP の状態:セキュリティのため FTP を無効化、または暗号化された FTPS のみに制限
3. アプリの挙動制御
-
常時接続 (Always On):
- 役割:20 分間アクセスがないとアプリが「休止」するのを防ぐ
- メリット:休止からの復帰(コールドスタート)による遅延を解消
- 必須条件:継続的に動く Web ジョブなどには必須
- ARR アフィニティ:同じユーザーを同じサーバーに固定して接続する設定。ステートレス(サーバーを固定しなくて良い)な設計なら「オフ」が推奨
4. 認証・デバッグ
- 着信クライアント証明書:証明書による厳格な相互認証を要求
- デバッグ:一時的にリモートデバッグを許可(48時間後に自動オフ)
パスマッピングを構成する
パスのマッピングは、特定のURLパスとサーバー上の実ディレクトリを紐付けたり、拡張子ごとに処理プログラムを指定するハンドラー設定を行う場所である。これにより、一つのサイト内でパスごとに異なるフォルダを割り当てて管理できるが、設定できる項目は使用しているOSの種類によって異なる。
Windows アプリのパスとハンドラー設定
Windows 版 App Service では、ファイルの種類に応じた処理プログラムの指定や、URL とフォルダの紐付けを細かくカスタマイズできる。
1. ハンドラーマッピング(処理プログラムの指定)
特定の拡張子(例:.php)に対して、どのプログラム(スクリプトプロセッサ)で実行するかを定義する。
- 拡張子:対象とするファイル形式
- スクリプトプロセッサ:実行ファイルの絶対パス。アプリのルートは D:\home\site\wwwroot と指定する
- 引数:実行時に渡すオプション設定
「.html という URL(外見)を維持したまま、中身を PHP (動的プログラム)として実行させる」といった、SEO 対策やレガシーシステムの移行に伴う特殊な実行環境の構築に利用される。
2. 仮想アプリケーションとディレクトリ
既定のルート(/)以外の場所にアプリを配置したり、1つのサイト内で複数のフォルダを使い分けたりする設定。
-
物理パス:
D:\homeを起点とした実際のフォルダ場所を指定 - アプリケーション化:単なる「フォルダ(ディレクトリ)」として扱うか、独立した「Web アプリケーション」として動作させるかを選択できる
ハンドラーマッピングは、リクエストされたファイルをどう処理するかをサーバーに教える設定。
静的ファイルはそのまま返し、.php などのプログラムファイルは指定した実行プログラムで動かして結果を返す。そのために「対象拡張子」と「実行プログラムの場所」を登録する。
カスタムストレージのマウント設定
Linux アプリやコンテナー(Windows/Linux 両方)では、外部の Azure ストレージをアプリ内のフォルダとして接続(マウント)できる。
設定項目
- 名前:管理用の表示名
-
構成オプション:
- 基本:通常の接続
- 詳細:ネットワーク制限(プライベートエンドポイント等)や Key Vault を使う場合
-
ストレージの種類:
- Azure Files:読み書き可能。Windows コンテナーはこれのみ対応
- Azure BLOB:読み取り専用
- マウントパス:コンテナー内のどこ(絶対パス)に表示させるか
- デプロイスロットの設定:本番とテスト環境で設定を共有するか固定するかを選択
メリット
- データの永続化:コンテナーを再起動・更新しても、マウントしたストレージ内のデータは消えずに残る
- 大容量データの共有:複数のアプリやインスタンスから同じファイルを共有して読み書きできる
診断ログの有効化
App Service にはトラブルシューティングに役立つ複数のログ機能がある。種類によって保存場所や対応OSが異なる。
1. アプリケーションログ(Windows / Linux)
- 内容:アプリのコード(Python, Node.js 等)が書き出すログ
- レベル:重要度(エラー、警告、情報など)ごとに分類される
- 場所:ファイルシステムや Azure Storage(BLOB)
2. Web サーバーログ(Windows のみ)
- 内容:HTTPリクエストの生データ(誰が、いつ、どこにアクセスしたか)
- 詳細:メソッド、URI、IPアドレス、応答コード、ユーザーエージェント等。
3. 詳細なエラーメッセージ(Windows のみ)
- 内容:400番以上のエラー時に生成される HTML 形式のエラー画面
- 用途:ブラウザに直接出せない詳細なエラー情報を、サーバー側に保存して確認できる
4. 失敗した要求トレース(Windows のみ)
- 内容:IIS(サーバー)のどの部品で処理が滞ったかの詳細
- 形式:フォルダごとに XML ファイルが生成される
5. デプロイログ(Windows / Linux)
- 内容:アプリのデプロイ(公開作業)が失敗した際の原因調査用
- 特徴:設定不要で自動的に記録される
アプリケーションのログ記録を有効にする (Windows)
Azure portal の [監視] > [App Service ログ] から設定を行う。
1. 保存先の選択
用途に合わせて2種類の保存先を使い分ける。
-
ファイルシステム(一時的)
- リアルタイムのデバッグ用
- 12時間で自動的にオフになるため、消し忘れの心配がない
-
Blob ストレージ(長期的)
- 監査や長期保存用
- 別途「Azure Storage」のコンテナー設定が必要。
2. ログレベルの設定
取得する情報の細かさを選択する。下のレベルほど、上のレベルの内容をすべて含む。
- エラー:重大な問題のみ
- 警告:異常の兆候も含む
- 情報:標準的な動作記録(おすすめ)
- 詳細:デバッグ用の全メッセージ(データ量が増えるため注意)
アプリケーションのログ記録を有効にする (Linux/コンテナー)
Linux アプリやコンテナー環境では、[App Service ログ] メニューから「ファイルシステム」への出力を設定する。
設定項目
- アプリケーションログ記録:「ファイルシステム」をオンにする
- クォータ (MB):ログ保存に使用する最大ディスク容量を指定。上限に達すると古いものから削除される
- リテンション期間 (日):ログを保持する日数を指定。期限を過ぎたデータは自動で消去される
Windows 版との違い
- 自動オフがない:Windows 版のファイルシステムログのように「12時間で自動オフ」にはならないため、容量管理(クォータ設定)が重要
- 保存場所:アプリケーションの標準出力(STDOUT)や標準エラー出力(STDERR)の内容がここに記録される
Web サーバーのログ記録を有効にする
アクセス状況(誰がどこにアクセスしたか)を記録する設定。
1. 保存先の選択
- ファイルシステム:App Service 内部に保存。手軽に確認できる
- ストレージ (Blob):大容量・長期間の保存向き。別途 Azure Storage が必要
2. 保存期間の設定
- リテンション期間 (日):ログを何日間保持するかを指定。期限が過ぎると自動削除される
コードでログメッセージを追加する
Azure側でログを「有効」にしても、アプリのコード内で出力命令を書かなければ中身は空のままになる。言語ごとの標準的な書き方は以下の通り。
1. ASP.NET (古いフレームワーク)
-
System.Diagnostics.Traceクラスを使用
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
2. ASP.NET Core (現在の主流)
- 標準のログ機能に「Azure 用の設定」を追加する
builder.Logging.AddAzureWebAppDiagnostics();
3. Python
- 標準の logging ライブラリだけでなく、OpenTelemetry(オープンテレメトリ)という仕組みを使って Azure Monitor へ送信する設定が必要
ログを Azure Monitor に送信する
App Service 内に一時保存するだけでなく、外部の監視専用サービスへログを転送・集約する仕組み。
設定の概要
- 設定場所:[監視] > [診断設定] から追加
-
主な転送先:
- Log Analytics ワークスペース:高度なクエリ分析や可視化が可能(最も一般的)
- ストレージアカウント:長期保管(アーカイブ)用
- Event Hubs:外部ツールへのリアルタイム連携用
転送できる主なログカテゴリ
- AppServiceHTTPLogs:Web サーバーのアクセスログ(誰がアクセスしたか)
- AppServiceConsoleLogs:アプリの標準出力・標準エラー出力(プログラムの動作記録)
- AppServiceAppLogs:アプリケーションコードが出力したメッセージ
メリット
- 統合管理:複数のアプリやリソースのログを一箇所でまとめて検索できる
- 長期分析:App Service 標準の保存期間を超えた分析や、ダッシュボード化が可能
ログのストリーミング
ログがファイルに書き出されるのを待たず、今まさに起きていることをリアルタイムで画面に流して監視する機能。
動作の条件
- 事前準備:監視したいログの種類(アプリケーションログ等)をあらかじめ「有効」にしておく必要がある
-
対象:
/home/LogFiles(Windows はD:\home\LogFiles)内にある .txt, .log, .htm ファイルに書き込まれた内容がストリーミングされる
実行方法
- Azure portal:アプリメニューの [ログ ストリーム] を選択するだけでブラウザ上に表示される
- Azure CLI (Cloud Shell またはローカル):
az webapp log tail --name appname --resource-group myResourceGroup
注意点
- 一時的な確認用:開発中のデバッグや障害時の即時確認に向いている
- 環境による制限:一部の Linux プランでは Cloud Shell で動かない場合があり、その際はローカルの CLI を使用する
ログファイルのダウンロード方法
App Service の内部(ファイルシステム)に保存されたログは、専用の URL から一括でダウンロードできる。
ダウンロードの手順
ブラウザのアドレスバーに以下の URL を入力すると、ログ一式が ZIP 形式で保存される。
-
Linux / コンテナーアプリ:
https://<アプリ名>.scm.azurewebsites.net/api/logs/docker/zip -
Windows アプリ:
https://<アプリ名>.scm.azurewebsites.net/api/logs/zip
含まれる内容
-
基本データ:
/home/LogFilesディレクトリ内にあるすべてのログ - Linux / コンテナーの場合:Docker ホスト自体のログと、コンテナー内の出力ログ(stdout/stderr)の両方が含まれる
- スケールアウト(複数台)構成:複数のインスタンスで動かしている場合、すべてのインスタンスのログがセットで入る
注意点
Azure Storage (Blob) の場合:ストレージに保存したログは上記の URL では落とせない。Azure Storage Explorer 等のクライアントツールが必要
- 認証:ダウンロードには Azure へのログイン権限が必要
セキュリティ証明書を構成する
App Service では、サイトの SSL/TLS 化(HTTPS)や外部リソースへの接続に使用する証明書を柔軟に管理できる。
証明書の保管ルール
- Web スペース単位で共有:アップロードした証明書は「リソースグループ + リージョン」の組み合わせごとに保管される
- 再利用可能:同じリソースグループ・リージョン内であれば、他のアプリからもその証明書を流用できる
証明書追加の 5 つのオプション
| オプション | 特徴・用途 |
|---|---|
| 無料マネージド証明書 | 無料で簡単。Azure が自動更新。カスタムドメインを HTTPS 化するだけなら最適。 |
| App Service 証明書 | 購入型。Azure が管理しつつ、外部へエクスポートも可能な柔軟な証明書。 |
| Key Vault からインポート | 証明書を Azure Key Vault で一元管理し、そのまま App Service で利用。 |
| プライベート証明書アップロード | 外部で購入済みの PFX などをアップロードして利用。 |
| パブリック証明書アップロード | サイト保護ではなく、アプリから外部リソースへ安全に接続する際の認証用。 |
パブリック証明書は公的に認められた認証局(CA)が厳格な審査を経て発行する。プライベート証明書は組織が独自に発行する。
プライベート証明書の要件
自分で用意した証明書(持ち込み)を App Service で使うには、以下の技術仕様を満たしている必要がある。なお、Azure 提供の「マネージド証明書」や「App Service 証明書」はこれらを自動でクリアしている。
ファイル形式と暗号化
- 形式:パスワード保護された PFX ファイルであること
- 暗号化方式:Triple DES を使用してエクスポートされていること
- 鍵の長さ:2,048 ビット以上の秘密キーを含むこと
証明書の構成内容
- 完全なチェーン:中間証明書およびルート証明書がすべて含まれていること
- 用途の指定:拡張鍵使用(EKU)に「サーバー認証(OID = 1.3.6.1.5.5.7.3.1)」が含まれていること
- 信頼性:信頼された証明機関(CA)によって署名されていること
無料のマネージド証明書の作成
Azure が発行から更新まで全てを代行する、カスタムドメイン用の無料 SSL 証明書。
利用条件
- 価格プラン:Basic、Standard、Premium、Isolated のいずれかであること(Free/Shared は不可)
- 自動管理:6ヶ月ごとに発行され、有効期限の 45 日前に自動更新される
主な制限事項
無料である代わりに、以下の制約がある
-
ワイルドカード不可:
*.example.comのような一括保護はできない - エクスポート不可:証明書を取り出して他のサーバーで使うことはできない
- 環境制限:App Service Environment (ASE) やプライベート DNS では利用できない
- ドメイン名:英数字、ハイフン、ドットのみ使用可能で、長さは 64 文字以内
- 用途:クライアント証明書としての利用はサポート対象外
App Service 証明書をインポートする
Azure を通じて有料の「App Service 証明書」を購入すると、発行から運用までの複雑な工程を Azure が一括代行する。
Azure が自動管理する主なタスク
- 購入と発行:証明書プロバイダーとのやり取りを代行
- ドメイン検証:そのドメインの所有者であることの確認作業を自動化
- 保管:セキュアな Azure Key Vault で安全に保持
- 更新と同期:有効期限の更新管理と、アプリへの最新版の自動反映を継続的に実施
既存の App Service 証明書がある場合
- インポート::既存の証明書を App Service に取り込んで利用可能
- 柔軟な操作: 更新や再発行(キー更新)に加え、他の場所で使うためのエクスポートも管理画面から行える











