Azure App Serviceの「Configure an App Service app」を確認する目的は、単に設定画面の場所を知ることではありません。実務では、アプリ設定、接続文字列、Key Vault、デプロイスロット、Always On、TLS、Linux環境での環境変数名などを見直し、設定変更による再起動や本番反映ミスを防ぐことが重要です。2026年5月20日時点で確認するなら、結論としては「シークレットはKey VaultまたはマネージドID中心に整理し、App settingsとConnection stringsの差分、slot setting、Linuxのキー名変換、PowerShell更新時の上書きリスクを重点チェックする」のが最優先です。
なお、Microsoft Learnの該当ページ上では最終更新日が2026年4月13日と表示されています。GitHub履歴では2026年4月13日から4月15日にかけて、Freshness Editや画面文言・参照リンクの修正が行われています。大規模なサービス廃止や即時移行を求める内容というより、Azure App Serviceの共通設定を最新の管理画面・運用手順に合わせて再確認するための更新と捉えるのが現実的です。(Microsoft Learn)
Azure App ServiceのConfigure an App Service appで確認すべき結論
Azure App Serviceの「Configure an App Service app」は、Webアプリ、モバイルバックエンド、APIアプリの共通設定をまとめた公式ドキュメントです。対象はAzure Functionsではなく、App Service上で動く通常のWebアプリやAPIアプリです。(Microsoft Learn)
管理者・開発者がまず確認すべきポイントは次のとおりです。
| 確認項目 | 実務上の意味 | 優先度 |
|---|---|---|
| App settings | アプリに渡す環境変数。変更時にアプリ再起動が発生する | 高 |
| Connection strings | 主に.NET系で接続文字列として扱う設定。非.NETではApp settings利用を検討 | 高 |
| Key Vault references | シークレットをApp Service設定から分離して管理する | 高 |
| Deployment slot setting | 本番・ステージングで異なる値をスワップさせないための設定 | 高 |
| Linuxのキー名変換 | :や.を含む階層設定がそのまま使えないケースへの対応 | 高 |
| General settings | Always On、HTTPS Only、TLS、HTTP/2、WebSocketsなどの実行基盤設定 | 中〜高 |
| Path mappings / Default documents | Windows App Serviceで静的ファイルや仮想ディレクトリを扱う場合に影響 | 中 |
今回の更新内容を読むときは、「どの機能が新しく追加されたか」だけでなく、本番環境で設定変更を安全に反映できるかを軸に確認してください。App settingsの追加・削除・変更はアプリ再起動を引き起こすため、アクセスが多い本番アプリでは、メンテナンス時間帯、デプロイスロット、ヘルスチェックを組み合わせた運用が必要です。(Microsoft Learn)
主な変更点は画面文言と運用手順の整理
GitHub上の差分を見ると、今回の更新はサービス仕様を根本から変えるものではなく、画面操作や参照先リンク、表現の整理が中心です。たとえば、Default documentsでは「New document」ではなくリスト項目を追加してApplyする説明に変わり、Path mappingsでは「New virtual application or directory」から「Add virtual application or directory」へ、Handler mappingsでも「New handler mapping」から「Add handler mapping」へと画面上の操作名に近い表現へ整理されています。(GitHub)
| 変更・整理された箇所 | 管理者・開発者への影響 |
|---|---|
| App Service設定画面の文言整理 | 手順書や社内Runbookの画面名が古い場合、作業者が迷いやすい |
| Stack settingsの説明位置整理 | ランタイムやSDKバージョン確認をGeneral settingsだけで終わらせない |
| ConnectionStringType参照リンク修正 | PowerShellで接続文字列タイプを扱う運用手順の確認が必要 |
| Default documentsの追加手順修正 | Windows App Serviceで静的サイトや既定ページを使う場合に影響 |
| Path mappings / Handler mappingsの操作名修正 | Laravelなどサブディレクトリ起点のアプリ、IISハンドラー利用環境で確認が必要 |
特に注意したいのは、ドキュメントの画面文言が変わると、実際のAzure portal操作だけでなく、監査用の手順書、障害対応Runbook、新人向け運用資料、CI/CDの説明資料も古くなる点です。作業ミスは機能変更そのものより、「画面名が違う」「保存ボタンのタイミングを誤る」「Applyを押し忘れる」といった小さなズレから起こりやすくなります。
App settingsは環境変数として扱う。変更時の再起動に注意
Azure App ServiceのApp settingsは、アプリケーションコードに環境変数として渡されます。ASP.NETやASP.NET Coreでは、App Service側の設定値がWeb.configやappsettings.jsonの値を上書きします。これにより、ローカル開発では開発用設定、本番ではAzure側に設定した本番用シークレットを使い分けられます。(Microsoft Learn)
実務では、App settingsを次のように使い分けると管理しやすくなります。
| 設定の種類 | App settingsに置くべきか | 判断基準 |
|---|---|---|
| 環境名 | 置く | Production、Stagingなど環境ごとに変わる |
| APIエンドポイント | 置く | 環境やリージョンで接続先が変わる |
| 機能フラグ | 置く | コード変更なしで挙動を切り替えたい |
| DBパスワード | 原則Key Vault推奨 | App settingsでも保存時暗号化されるが、ローテーションや監査が必要 |
| ローカル開発用パスワード | 置かない | Azure本番設定と混同しやすい |
| 画像パスや固定文言 | 状況次第 | コードやCMS側で管理したほうが自然な場合もある |
App settingsの名前には、英字、数字、ピリオド、アンダースコアを使えます。Linuxアプリやカスタムコンテナーでは、ネストされたJSONキーを扱うときに:を__へ、.を_へ置き換える必要があります。たとえばApplicationInsights:InstrumentationKeyは、App Service上ではApplicationInsights__InstrumentationKeyとして設定します。(Microsoft Learn)
App settings変更前にやるべき手順
App settingsは「値を入れて終わり」ではありません。追加・変更・削除でアプリが再起動するため、本番では以下の順番で作業します。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 事前取得 | 現在のApp settingsをJSONで保存 | 変更前の値を残さず、ロールバックできない |
| 影響確認 | 再起動しても問題ない時間帯か確認 | ピーク時間帯に反映して初回アクセスが遅くなる |
| slot設定確認 | 本番とステージングで異なる値をslot settingにする | スワップ時に本番DBではなく検証DBを向いてしまう |
| 反映 | Azure portal、Azure CLI、PowerShellで更新 | PowerShellで全設定を上書きして既存設定を消す |
| 動作確認 | ヘルスチェック、ログ、依存サービス接続を確認 | 起動は成功しても外部API接続で失敗する |
Azure CLIで現在の設定を保存してから編集する例は次のとおりです。
az webapp config appsettings list \
--resource-group <resource-group-name> \
--name <app-name> > appsettings-before.json更新する場合は、変更対象だけでなく、スロット固有設定かどうかも確認してください。
az webapp config appsettings set \
--resource-group <resource-group-name> \
--name <app-name> \
--settings ENV_NAME="Production"PowerShellのSet-AzWebAppでApp settingsを設定する場合、指定した設定セットで全体が置き換わります。既存設定を保持したい場合は、Get-AzWebAppで現在値を取得し、追加・変更後に保存する流れが必要です。(Microsoft Learn)
Connection stringsは.NET中心。非.NETではApp settingsも検討する
Connection stringsは、データベースや外部サービスへの接続情報を管理するための設定です。ASP.NETやASP.NET Coreでは、App Service側のConnection stringsがWeb.config内のconnectionStringsを上書きします。(Microsoft Learn)
一方で、Node.js、Python、PHP、Javaなどの非.NETアプリでは、App settingsを使ったほうが扱いやすいケースがあります。公式ドキュメントでも、非.NET言語ではConnection stringsが特別な環境変数プレフィックスを持つため、必要がなければApp settingsを使う考え方が示されています。ただし、App Serviceのカスタムバックアップで特定のAzureデータベースをアプリと一緒にバックアップしたい場合は、Connection stringsとして設定する意味があります。(Microsoft Learn)
| 接続先タイプ | 環境変数プレフィックス |
|---|---|
| SQL Server | SQLCONNSTR_ |
| MySQL | MYSQLCONNSTR_ |
| Azure SQL | SQLAZURECONNSTR_ |
| Custom | CUSTOMCONNSTR_ |
| PostgreSQL | POSTGRESQLCONNSTR_ |
| Azure Service Bus | SERVICEBUSCONNSTR_ |
| Azure Event Hubs | EVENTHUBCONNSTR_ |
| Azure Cosmos DB | DOCDBCONNSTR_ |
| Redis cache | REDISCACHECONNSTR_ |
.NETアプリでPostgreSQL、Notification Hubs、Service Bus、Event Hubs、Azure Cosmos DB、Redis cacheを対象にする場合、既知の問題への回避策として接続文字列タイプをCustomにする説明があります。該当する環境では、単に「PostgreSQLだからPostgreSQLを選ぶ」と決めつけず、公式ドキュメントとアプリの構成プロバイダーの挙動を確認してください。(Microsoft Learn)
シークレット管理はKey VaultまたはマネージドIDを優先する
App settingsやConnection stringsは保存時に暗号化されますが、長期運用では「暗号化されているから十分」とは言い切れません。DBパスワード、APIキー、SASトークンなどは、ローテーション、アクセス制御、監査ログの観点からAzure Key Vault referencesを検討すべきです。(Microsoft Learn)
Key Vault referencesを使うと、アプリケーションコードは通常のApp settingsやConnection stringsと同じように値を参照できます。その一方で、シークレット本体はKey Vault側に分離されます。管理者がApp Serviceリソースを操作できても、Key Vaultのシークレットを直接読めないように権限分離できる点が実務上のメリットです。(Microsoft Learn)
| 管理方式 | 向いているケース | 注意点 |
|---|---|---|
| App settingsに直接保存 | 小規模、短期、低リスクな設定 | ローテーションや監査が弱くなりやすい |
| Key Vault references | 本番シークレット、監査が必要な環境 | マネージドIDとKey Vault権限設定が必要 |
| マネージドID接続 | Azure SQL、StorageなどEntra認証対応サービス | アプリコードや接続方式の変更が必要な場合がある |
可能であれば、接続文字列にユーザー名・パスワードを入れる方式から、マネージドIDを使った接続へ移行します。Microsoftの公式情報でも、クラウドアプリケーションでは「シークレットを持たない」構成がより安全な方向性として示されています。(Microsoft Learn)
Key Vault referencesで失敗しやすいポイント
Key Vault referencesは便利ですが、設定ミスも起こりやすい領域です。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| App Serviceからシークレットを読めない | マネージドIDにKey Vaultの読み取り権限がない | RBACならKey Vault Secrets User、アクセスポリシーならGet権限を付与 |
| スロットスワップ後に別環境のシークレットを参照 | Key Vault referencesをslot settingにしていない | 環境ごとにKey Vaultを分け、slot settingを有効化 |
| ローテーション後すぐ反映されない | App Serviceが参照値をキャッシュする | 反映タイミングを考慮し、必要に応じて構成変更や更新APIを使う |
| Private Endpoint付きKey Vaultに接続できない | App Service側のVNet経由ルーティング不足 | ネットワーク制限とVNet統合を合わせて確認 |
Key Vault referencesは、バージョンを指定しなければKey Vault上の最新バージョンを参照し、ローテーション後は一定時間内に更新されます。公式ドキュメントでは、App ServiceがKey Vault参照値をキャッシュし、24時間ごとに再取得すること、構成変更によりアプリ再起動と即時再取得が発生することが説明されています。(Microsoft Learn)
Deployment slotsを使う場合はslot settingを必ず確認する
Azure App ServiceのDeployment slotsは、Standard、Premium、Isolatedなどのプランで利用できる、本番とは別のライブ環境です。ステージングスロットにデプロイしてから本番とスワップすることで、変更内容を事前に検証し、ウォームアップ後に本番へ反映できます。(Microsoft Learn)
設定確認で重要なのは、「どの設定がスワップされるか」です。App settingsやConnection stringsはスワップ対象になり得ますが、slot settingとして固定できます。本番DBの接続情報、環境名、Key Vault参照、外部APIの本番キーなどは、原則としてslot settingにしておくべきです。(Microsoft Learn)
| 設定 | slot setting推奨度 | 理由 |
|---|---|---|
| 本番DB接続情報 | 高 | ステージングスロットへ流れると検証環境が本番DBへ接続する |
| Key Vault reference | 高 | 環境ごとのKey Vaultを参照させるため |
ENVIRONMENT / ASPNETCORE_ENVIRONMENT | 高 | ログ、挙動、エラー表示が変わる |
| 外部決済APIキー | 高 | 検証決済と本番決済の混同を防ぐ |
| ログ出力レベル | 中 | ステージングだけ詳細ログにする場合がある |
| 機能フラグ | ケース次第 | 本番反映時に一緒に切り替えたいかで判断 |
スワップ前には、Azure portalのSwapダイアログでSourceとTargetの設定差分を確認します。ミッションクリティカルなアプリでは、Swap with previewを使って、本番スロットの設定を適用した状態でステージング側を検証してから完了させる方法も有効です。(Microsoft Learn)
General settingsではAlways On、HTTPS、TLS、HTTP/2を見直す
General settingsでは、アプリの実行基盤に関わる重要な設定を確認できます。代表的な設定には、32-bit / 64-bit、FTP state、HTTP version、Web sockets、Always On、Session affinity、HTTPS Only、Minimum TLS version、Remote debugging、Incoming client certificatesなどがあります。(Microsoft Learn)
| 設定 | 推奨確認ポイント |
|---|---|
| Platform | Windowsアプリのみ。メモリや互換性の観点で32-bit / 64-bitを確認 |
| FTP state | 使わないなら無効化、使う場合もFTPSのみを検討 |
| HTTP version | HTTP/2を使う場合はTLS付きカスタムドメインも確認 |
| Web sockets | SignalRやsocket.ioなどリアルタイム通信で必要 |
| Always On | コールドスタートを避けたい本番アプリ、継続WebJobsで重要 |
| Session affinity | ステートレスアプリではOffを検討 |
| HTTPS Only | HTTPアクセスをHTTPSへリダイレクトしたい場合に有効 |
| Minimum TLS version | 組織のセキュリティ基準に合わせて確認 |
| Remote debugging | 必要時のみ。有効化後の放置を避ける |
| Client certificates | 相互TLSが必要なAPIで検討 |
Always Onが無効の場合、一定時間リクエストがないとアプリがアンロードされ、次のリクエストで待ち時間が発生する可能性があります。Always Onを有効にすると、フロントエンドロードバランサーがアプリルートへ定期的にGETリクエストを送り、アプリがアンロードされるのを防ぎます。継続WebJobsやcron式で実行されるWebJobsではAlways Onが必要です。(Microsoft Learn)
Windows App Service固有の設定も見落とさない
Default documents、Path mappings、Handler mappingsは、特にWindows App Serviceで確認が必要です。Default documentsはルートURLで表示される既定ファイルの順序を決める設定で、Windowsアプリ向けの設定です。ルーティングをアプリ側で処理するフレームワークでは不要な場合もあります。(Microsoft Learn)
Path mappingsは、Laravelのようにpublicディレクトリを公開ルートにしたい場合や、1つのリポジトリに複数アプリがある場合に使います。ただし、仮想ディレクトリを物理パスにマップする機能はWindowsアプリ向けです。(Microsoft Learn)
Handler mappingsは、IISのハンドラー設定をカスタマイズする機能です。特定の拡張子に対して独自のスクリプトプロセッサを割り当てるようなケースで使います。現在の一般的なApp Service運用では頻出ではありませんが、レガシーなPHP構成やIIS前提のアプリを移行している場合は確認しておくべきです。(Microsoft Learn)
管理者・開発者向けの確認チェックリスト
Azure App ServiceのConfigure an App Service appを読んだ後は、次の順番で現行環境を棚卸しすると、作業漏れを減らせます。
管理者が確認すること
| チェック項目 | 確認内容 |
|---|---|
| RBAC | App settingsやConnection stringsを見られるユーザーが適切か |
| シークレット | App settings直書きのパスワードをKey Vaultへ移せるか |
| TLS/HTTPS | HTTPS Only、Minimum TLS versionが組織基準に合っているか |
| FTP | 不要なFTPアクセスが残っていないか |
| Always On | 本番アプリやWebJobsで有効化が必要か |
| スロット設定 | 本番・ステージングで異なる値がslot settingになっているか |
ReaderロールだけではAzure portalでEnvironment variablesの該当セクションにアクセスできず、Owner、Contributor、Website Contributorなどの読み書き権限が必要です。権限設計では「設定を変更できる人」だけでなく、「シークレット値を表示できる人」も分けて考える必要があります。(Microsoft Learn)
開発者が確認すること
| チェック項目 | 確認内容 |
|---|---|
| 設定キー名 | Linuxで:や.を含むキーが正しく変換されているか |
| 設定優先順位 | App Service側の設定がappsettings.jsonやWeb.configを上書きする前提で実装しているか |
| 接続文字列 | 非.NETアプリでConnection stringsを無理に使っていないか |
| 起動時処理 | App settings変更による再起動後に正常起動できるか |
| ヘルスチェック | スワップ前後に確認できるエンドポイントがあるか |
| ログ | 設定ミス時に原因を追えるログが出るか |
開発者側で特に多いミスは、ローカルのappsettings.jsonに本番相当の設定を書き込むことです。App Serviceでは本番シークレットをAzure側に置き、ローカルには開発用の安全な値だけを置く構成にしましょう。
移行・展開時の安全な進め方
既存アプリの設定を見直す場合は、いきなり本番のEnvironment variablesを編集しないでください。次の流れで進めると安全です。
| フェーズ | 実施内容 |
|---|---|
| 棚卸し | App settings、Connection strings、General settings、Slot settingsをエクスポート |
| 分類 | シークレット、環境固有値、共通値、廃止予定値に分ける |
| 移行 | シークレットをKey Vault referencesまたはマネージドID接続へ移す |
| 検証 | ステージングスロットで起動、外部接続、ログ、認証を確認 |
| 反映 | Swap with previewまたは通常スワップで本番反映 |
| 監視 | 起動時間、HTTP 5xx、依存サービス接続、Key Vaultアクセスログを確認 |
| 記録 | Runbook、IaCテンプレート、CI/CD変数を更新 |
設定変更をIaCで管理している場合は、Azure portalでの手動変更とテンプレートの差分にも注意が必要です。ポータル上で修正した値が、次回のデプロイで古いARMテンプレート、Bicep、Terraform、GitHub Actions、Azure DevOps Pipelineの変数によって上書きされることがあります。特にApp settingsは「一時対応でポータル修正した値」が残りやすいため、変更後は必ず構成管理側にも反映してください。
すぐに取るべき次のアクション
Azure App Serviceの「Configure an App Service app」は、単なる設定項目の一覧ではなく、本番運用の安全性に直結する確認リストとして読むべきドキュメントです。特に重要なのは、App settings変更時の再起動、PowerShellによる全体上書き、Key Vault referencesの権限とキャッシュ、Deployment slotsのslot setting、Linuxでの環境変数名変換です。
まずは本番App Serviceで、次の3点から着手してください。
- App settingsとConnection stringsをエクスポートし、シークレット直書きの有無を確認する
- 本番・ステージングで異なる値がslot settingになっているか確認する
- Always On、HTTPS Only、Minimum TLS version、FTP stateを運用基準に照らして見直す
この3点を終えるだけでも、設定変更による障害、スワップ時の接続先ミス、シークレット管理の不備を大きく減らせます。
コメント