Azure Functions のアプリケーション設定のリファレンス

関数アプリのアプリケーション設定には、その関数アプリのすべての関数に影響する構成オプションが含まれています。 これらの設定は、環境変数としてアクセスされます。 この記事では、関数アプリで使用できるアプリケーション設定の一覧を紹介します。

関数アプリの設定は、いくつかの方法で追加、更新、削除できます。

• Azure portal を使用する方法
• Azure CLI を使用する方法
• Azure PowerShell を使用する方法

関数アプリの設定に変更を加えるためには、関数アプリを再起動する必要があります。

この記事の例で、接続文字列の値は、読みやすくするために切り詰められています。

アプリ設定に関する考慮事項

アプリ設定を使用する場合は、次の考慮事項に注意する必要があります。

• 関数アプリの設定に変更を加えるためには、関数アプリを再起動する必要があります。

• 設定名では、二重アンダースコア (__) とセミコロン (:) は予約値と見なされます。 二重アンダースコアは Windows と Linux の両方で階層区切り記号として解釈され、コロンは Linux でのみ同じように解釈されます。 たとえば、設定 AzureFunctionsWebHost__hostid=somehost_123456 は次の JSON オブジェクトとして解釈されます。

  "AzureFunctionsWebHost": {
      "hostid": "somehost_123456"
  }
  

  この記事では、両方のオペレーティング システムでサポートされているため、二重アンダースコアのみを使用します。 マネージド ID 接続をサポートする設定のほとんどでは、二重アンダースコアを使用します。

• Functions がローカルで実行される場合、アプリ設定は local.settings.json の Values コレクションで指定します。

• host.json ファイルと local.settings.json ファイルには、他の関数アプリ構成オプションもあります。

• アプリケーション設定を使用して、host.json ファイル自体を変更することなく、host.json 設定値をオーバーライドできます。 これは、特定の環境の特定の host.json 設定を構成または変更する必要がある場合に便利です。 これにより、プロジェクトを再発行しなくても、host.json 設定を変更できます。 詳細については、host.json のリファレンスに関する記事をご覧ください。

• この記事では、関数アプリに最も関連した設定について説明します。 Azure Functions は App Service 上で実行されるため、その他のアプリケーション設定もサポートされます。 詳細については、「Azure App Service の環境変数とアプリ設定」を参照してください。

• また、一部のシナリオでは、「App Service サイトの設定」で説明されている設定も操作する必要があります。

• 読み取り専用の App Service アプリケーション設定を変更すると、関数アプリが応答しない状態になる可能性があります。

• ARM テンプレートを含め、REST API を使用してアプリケーション設定を更新するときは、注意深く行ってください。 これらの API は既存のアプリケーション設定を置き換えるので、REST API または ARM テンプレートを使用して設定を追加または変更するときには、既存のすべての設定を含める必要があります。 可能な場合は、Azure CLI または Azure PowerShell を使用して、プログラムでアプリケーション設定を操作します。 詳細については、アプリケーション設定の操作に関する記事を参照してください。

APPINSIGHTS_INSTRUMENTATIONKEY

Application Insights のインストルメンテーション キー。 APPINSIGHTS_INSTRUMENTATIONKEY と APPLICATIONINSIGHTS_CONNECTION_STRING の両方を使用することはできません。 可能な場合は、APPLICATIONINSIGHTS_CONNECTION_STRING を使用します。 Application Insights がソブリン クラウドで実行されている場合は、APPLICATIONINSIGHTS_CONNECTION_STRING を使用する必要があります。 詳細については、Azure Functions で監視を構成する方法に関するページを参照してください。

Key	値の例
APPINSIGHTS_INSTRUMENTATIONKEY	55555555-af77-484b-9032-64f83bb83bb

APPINSIGHTS_INSTRUMENTATIONKEY と APPLICATIONINSIGHTS_CONNECTION_STRING の両方を使用することはできません。 APPLICATIONINSIGHTS_CONNECTION_STRING を使用することをお勧めします。

Note

インストルメンテーション キーのインジェストのサポートは、2025 年 3 月 31 日に終了します。 インストルメンテーション キーのインジェストは引き続き機能しますが、この機能の更新プログラムやサポートは提供されなくなります。 接続文字列に移行することで、新機能をご利用いただけます。

APPLICATIONINSIGHTS_CONNECTION_STRING

Application Insights の接続文字列。 APPINSIGHTS_INSTRUMENTATIONKEY と APPLICATIONINSIGHTS_CONNECTION_STRING の両方を使用することはできません。 すべての場合に APPLICATIONINSIGHTS_CONNECTION_STRING を使用することが推奨されますが、次の場合には必須です。

• お使いの関数アプリで接続文字列を使用した追加のカスタマイズ サポートが必要な場合。
• カスタム エンドポイントを必要とするソブリン クラウドで Application Insights インスタンスが実行されている場合。

詳細については、接続文字列に関するページを参照してください。

Key	値の例
APPLICATIONINSIGHTS_CONNECTION_STRING	InstrumentationKey=...

AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL

重要

Azure Functions プロキシは、Azure Functions ランタイムのバージョン 1.x から 3.x 用のレガシ機能です。 バージョン 4.x でのレガシ サポートの詳細については、Functions プロキシに関する記事を参照してください。

既定では、Functions プロキシは、ショートカットを使用して、同じ関数アプリ内の関数にプロキシから直接 API 呼び出しを送信します。 新しい HTTP 要求を作成する代わりに、このショートカットが使用されます。 この設定を使用すると、そのショートカット動作を無効にすることができます。

Key	値	説明
AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL	true	ローカル関数アプリ内の関数を指すバックエンド URL を使用した呼び出しは、その関数に直接送信されません。 代わりに、要求は、関数アプリの HTTP フロントエンドに戻されます。
AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL	false	ローカル関数アプリ内の関数を指すバックエンド URL を使用した呼び出しは、その関数に直接転送されます。 既定値は false です。

AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES

重要

Azure Functions プロキシは、Azure Functions ランタイムのバージョン 1.x から 3.x 用のレガシ機能です。 バージョン 4.x でのレガシ サポートの詳細については、Functions プロキシに関する記事を参照してください。

この設定は、文字 %2F がバックエンド URL に挿入されたときに、これをルート パラメーターでスラッシュとしてデコードするかどうかを制御します。

キー	値	説明
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES	true	エンコードされたスラッシュを含むルート パラメーターがデコードされます。
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES	false	すべてのルート パラメーターは変更されずに渡されます。これは既定の動作です。

たとえば、myfunction.com ドメインの関数アプリ用の proxies.json ファイルを考えてみます。

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "root": {
            "matchCondition": {
                "route": "/{*all}"
            },
            "backendUri": "example.com/{all}"
        }
    }
}

AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES が true に設定されている場合、URL example.com/api%2ftest は example.com/api/test に解決されます。 既定では、URL は example.com/test%2fapi のまま変更されません。 詳細については、Functions プロキシに関するページを参照してください。

AZURE_FUNCTIONS_ENVIRONMENT

Azure で実行するときに、関数アプリのランタイムホスティング環境を構成します。 この値は初期化中に読み取られ、ランタイムでは次の値のみが受け入れられます。

Value	説明
Production	ログ記録と完全なパフォーマンスの最適化が削減された運用環境を表します。 これは、AZURE_FUNCTIONS_ENVIRONMENT が設定されていないか、サポートされていない値に設定されている場合の既定値です。
Staging	ステージング スロットで実行されている場合など、ステージング環境を表します。
Development	開発環境では、より詳細なログやその他の低下したパフォーマンスの最適化がサポートされます。 Azure Functions Core Tools では、ローカル コンピューターでの実行時に AZURE_FUNCTIONS_ENVIRONMENT が Development に設定されます。 local.settings.json ファイルでは、この設定をオーバーライドできません。

Azure のランタイム環境を Production 以外のものに変更する必要がある場合は、ASPNETCORE_ENVIRONMENT の代わりにこの設定を使用します。 詳細については、環境別の起動のクラスとメソッドに関する記事を参照してください。

この設定は、Functions ランタイムのバージョン 1.x では使用できません。

AzureFunctionsJobHost__*

Functions ランタイムのバージョン 2.x 以降では、現在の環境の host.json 設定をアプリケーション設定でオーバーライドできます。 これらのオーバーライドは、AzureFunctionsJobHost__path__to__setting という名前のアプリケーション設定として表されます。 詳細については、「host.json 値をオーバーライドする」を参照してください。

AzureFunctionsWebHost__hostid

特定の関数アプリのホスト ID を設定します。これは、一意の ID にする必要があります。 この設定は、自動的に生成された、アプリのホスト ID 値をオーバーライドします。 この設定は、同じストレージ アカウントを共有する関数アプリ間でホスト ID の競合を防ぐ必要がある場合にのみ使用します。

ホスト ID は次の要件を満たしている必要があります。

• 1 から 32 文字であること
• 小文字、数字、ダッシュのみを含むこと
• 先頭または末尾がダッシュではないこと
• 連続するダッシュを含まないこと

ID を生成する簡単な方法は、GUID を取得し、ダッシュを除外し、小文字化することです。たとえば、GUID 1835D7B5-5C98-4790-815D-072CC94C6F71 を値 1835d7b55c984790815d072cc94c6f71 に変換します。

Key	値の例
AzureFunctionsWebHost__hostid	myuniquefunctionappname123456789

詳細については、「ホスト ID に関する考慮事項」を参照してください。

AzureWebJobsDashboard

この設定は非推奨であり、Azure Functions ランタイムのバージョン 1.x で実行している場合にのみサポートされます。

ログの保存と、それらをポータルの [モニター] タブに表示する、オプションのストレージ アカウントの接続文字列です。 このストレージ アカウントは、blob、キュー、およびテーブルをサポートする汎用的なものである必要があります。 詳しくは、「ストレージ アカウントの要件」をご覧ください。

Key	値の例
AzureWebJobsDashboard	DefaultEndpointsProtocol=https;AccountName=...

AzureWebJobsDisableHomepage

値 true を指定すると、関数アプリのルート URL 用に表示される既定のランディング ページが無効になります。 既定値は false です。

Key	値の例
AzureWebJobsDisableHomepage	true

このアプリ設定を省略するか、false に設定した場合、URL <functionappname>.azurewebsites.net の応答に対し、次の例のようなものが表示されます。

AzureWebJobsDotNetReleaseCompilation

true は、.NET コードのコンパイルにリリース モードを使用することを意味し、false は、デバッグ モードを使用することを意味します。 既定値は true です。

Key	値の例
AzureWebJobsDotNetReleaseCompilation	true

AzureWebJobsFeatureFlags

有効にするベータ機能のコンマ区切りの一覧です。 これらのフラグで有効となるベータ機能は本番には適しませんが、公開前の実験的な使用には有効にすることができます。

Key	値の例
AzureWebJobsFeatureFlags	feature1,feature2,EnableProxies

この一覧に EnableProxies を追加すると、Azure API Management への移行を計画中に Functions ランタイムのバージョン 4.x でプロキシを再度有効にすることができます。 詳細については、「Functions v4.x でプロキシを再度有効にする」を参照してください。

AzureWebJobsKubernetesSecretName

キーを格納するために使用される Kubernetes Secrets リソースを示します。 Kubernetes での実行時にのみサポートされます。 この設定では、AzureWebJobsSecretStorageType を kubernetes に設定する必要があります。 AzureWebJobsKubernetesSecretName が設定されていない場合、リポジトリは読み取り専用と見なされます。 この場合は、デプロイの前に値を生成する必要があります。 Kubernetes にデプロイすると、Azure Functions Core Tools によって値が自動的に生成されます。

Key	値の例
AzureWebJobsKubernetesSecretName	<SECRETS_RESOURCE>

詳細については、「シークレット リポジトリ」を参照してください。

AzureWebJobsSecretStorageKeyVaultClientId

キーが格納されているコンテナーへのアクセスに使用するユーザー割り当てマネージド ID またはアプリ登録のクライアント ID。 この設定では、AzureWebJobsSecretStorageType を keyvault に設定する必要があります。 バージョン 4.x 以降のバージョンの Functions ランタイムでサポートされています。

Key	値の例
AzureWebJobsSecretStorageKeyVaultClientId	<CLIENT_ID>

詳細については、「シークレット リポジトリ」を参照してください。

AzureWebJobsSecretStorageKeyVaultClientSecret

キーが格納されているコンテナーへのアクセスに使用するユーザー割り当てマネージド ID またはアプリ登録のクライアント ID のシークレット。 この設定では、AzureWebJobsSecretStorageType を keyvault に設定する必要があります。 バージョン 4.x 以降のバージョンの Functions ランタイムでサポートされています。

Key	値の例
AzureWebJobsSecretStorageKeyVaultClientSecret	<CLIENT_SECRET>

詳細については、「シークレット リポジトリ」を参照してください。

AzureWebJobsSecretStorageKeyVaultName

キーを格納するために使用されるキー コンテナー インスタンスの名前。 この設定は、Functions ランタイムのバージョン 3.x でのみサポートされています。 バージョン 4.x の場合は、代わりに AzureWebJobsSecretStorageKeyVaultUri を使用します。 この設定では、AzureWebJobsSecretStorageType を keyvault に設定する必要があります。

コンテナーには、ホスティング リソースのシステム割り当てマネージド ID に対応するアクセス ポリシーが必要です。 アクセス ポリシーでは、Get、Set、List、Delete というシークレットのアクセス許可を、その ID に付与することを必要としています。
関数をローカルで実行する場合は、開発者 ID が使用され、設定は local.settings.json ファイル に含まれている必要があります。

Key	値の例
AzureWebJobsSecretStorageKeyVaultName	<VAULT_NAME>

詳細については、「シークレット リポジトリ」を参照してください。

AzureWebJobsSecretStorageKeyVaultTenantId

キーが格納されているコンテナーへのアクセスに使用されるアプリ登録のテナント ID。 この設定では、AzureWebJobsSecretStorageType を keyvault に設定する必要があります。 バージョン 4.x 以降のバージョンの Functions ランタイムでサポートされています。 詳細については、「シークレット リポジトリ」を参照してください。

Key	値の例
AzureWebJobsSecretStorageKeyVaultTenantId	<TENANT_ID>

AzureWebJobsSecretStorageKeyVaultUri

キーを格納するために使用されるキー コンテナー インスタンスのURI。 バージョン 4.x 以降のバージョンの Functions ランタイムでサポートされています。 キーの格納にキー コンテナー インスタンスを使用する場合は、この設定をお勧めします。 この設定では、AzureWebJobsSecretStorageType を keyvault に設定する必要があります。

AzureWebJobsSecretStorageKeyVaultUri の値は、https:// を含む、[Key Vault overview](Key Vault の概要) タブに表示されている、[Vault URI](コンテナー URI) の完全な値である必要があります。

コンテナーには、ホスティング リソースのシステム割り当てマネージド ID に対応するアクセス ポリシーが必要です。 アクセス ポリシーでは、Get、Set、List、Delete というシークレットのアクセス許可を、その ID に付与することを必要としています。
関数をローカルで実行する場合は、開発者 ID が使用され、設定は local.settings.json ファイル に含まれている必要があります。

Key	値の例
AzureWebJobsSecretStorageKeyVaultUri	https://<VAULT_NAME>.vault.azure.net

詳細については、「Azure Functions の Key Vault 参照を使用する」を参照してください。

AzureWebJobsSecretStorageSas

キーの格納に使用される 2番目のストレージ アカウントの Blob Storage SAS URL。 既定では、Functions は AzureWebJobsStorage に設定されたアカウントを使用します。 このシークレット ストレージ オプションを使用する場合は、AzureWebJobsSecretStorageType が明示的に設定されていないこと、または、blob に設定されていることを確認してください。 詳細については、「シークレット リポジトリ」を参照してください。

Key	値の例
AzureWebJobsSecretStorageSas	<BLOB_SAS_URL>

AzureWebJobsSecretStorageType

キーの保存に使用するリポジトリまたはプロバイダーを指定します。 キーは、常に関数アプリに固有のシークレットを使用して、格納される前に暗号化されます。

キー	値	説明
AzureWebJobsSecretStorageType	blob	キーは、AzureWebJobsStorage 設定によって指定されたアカウントの Blob Storage コンテナーに格納されます。 AzureWebJobsSecretStorageType が設定されていない場合の既定の動作は BLOB ストレージです。 別のストレージ アカウントを指定するには、AzureWebJobsSecretStorageSas 設定を使用して、2 番目のストレージ アカウントの SAS URL を指定します。
AzureWebJobsSecretStorageType	files	キーは、ファイル システムに保存されます。 これは、Functions v1.x の既定の動作です。
AzureWebJobsSecretStorageType	keyvault	キーは、AzureWebJobsSecretStorageKeyVaultName によって設定されるキー コンテナー インスタンスに格納されます。
AzureWebJobsSecretStorageType	kubernetes	Kubernetes で Functions ランタイムを実行する場合にのみサポートされます。 AzureWebJobsKubernetesSecretName が設定されていない場合、リポジトリは読み取り専用と見なされます。 この場合は、デプロイの前に値を生成する必要があります。 Kubernetes にデプロイすると、Azure Functions Core Tools によって値が自動的に生成されます。

詳細については、「シークレット リポジトリ」を参照してください。

AzureWebJobsStorage

Functions ランタイムで通常の操作に使用する Azure Storage アカウントに接続文字列を指定します。 Functions によるこのストレージ アカウントの使用としては、キー管理、タイマー トリガー管理、Event Hubs チェックポイントなどがあります。 このストレージ アカウントは、blob、キュー、およびテーブルをサポートする汎用的なものである必要があります。 詳細については、「ストレージ アカウントの要件」をご覧ください。

キー	値の例
AzureWebJobsStorage	DefaultEndpointsProtocol=https;AccountName=...

接続文字列の代わりに、このストレージ アカウントに ID ベースの接続を使用できます。 詳細については、「ID を使用するホスト ストレージへの接続」を参照してください。

AzureWebJobsStorage__accountName

ID ベースのストレージ接続を使用する場合は、AzureWebJobsStorage で接続文字列を使用する代わりに、ストレージ アカウントのアカウント名を設定します。 この構文は AzureWebJobsStorage に固有であり、他の ID ベースの接続には使用できません。

キー	サンプルの値
AzureWebJobsStorage__accountName	<STORAGE_ACCOUNT_NAME>

ソブリン クラウドの場合、またはカスタム DNS を使用する場合は、代わりにサービス固有の AzureWebJobsStorage__*ServiceUri 設定を使用する必要があります。

AzureWebJobsStorage__blobServiceUri

ID ベースのストレージ接続を使用する場合は、ストレージ アカウントの BLOB サービスのデータ プレーン URI を設定します。

キー	サンプルの値
AzureWebJobsStorage__blobServiceUri	https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net

ソブリン クラウドでは、またはカスタム DNS を使用する場合は、AzureWebJobsStorage__accountName の代わりにこの設定を使用します。 詳細については、「ID を使用するホスト ストレージへの接続」を参照してください。

AzureWebJobsStorage__queueServiceUri

ID ベースのストレージ接続を使用する場合は、ストレージ アカウントのキュー サービスのデータ プレーン URI を設定します。

キー	サンプルの値
AzureWebJobsStorage__queueServiceUri	https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net

ソブリン クラウドでは、またはカスタム DNS を使用する場合は、AzureWebJobsStorage__accountName の代わりにこの設定を使用します。 詳細については、「ID を使用するホスト ストレージへの接続」を参照してください。

AzureWebJobsStorage__tableServiceUri

ID ベースのストレージ接続を使用する場合は、ストレージ アカウントのテーブル サービスのデータ プレーン URI を設定します。

キー	サンプルの値
AzureWebJobsStorage__tableServiceUri	https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net

ソブリン クラウドでは、またはカスタム DNS を使用する場合は、AzureWebJobsStorage__accountName の代わりにこの設定を使用します。 詳細については、「ID を使用するホスト ストレージへの接続」を参照してください。

AzureWebJobs_TypeScriptPath

Typescript で使用されるコンパイラへのパスです。 必要に応じて、既定値はオーバーライドできます。

Key	値の例
AzureWebJobs_TypeScriptPath	%HOME%\typescript

DOCKER_REGISTRY_SERVER_PASSWORD

プライベート コンテナー レジストリへのアクセスに使用するパスワードを示します。 この設定は、プライベート コンテナー レジストリからコンテナー化された関数アプリをデプロイする場合にのみ必要です。 詳細については、「Azure App Service の環境変数とアプリ設定」を参照してください。

DOCKER_REGISTRY_SERVER_URL

プライベート コンテナー レジストリの URL を示します。 この設定は、プライベート コンテナー レジストリからコンテナー化された関数アプリをデプロイする場合にのみ必要です。 詳細については、「Azure App Service の環境変数とアプリ設定」を参照してください。

DOCKER_REGISTRY_SERVER_USERNAME

プライベート コンテナー レジストリへのアクセスに使用するアカウントを示します。 この設定は、プライベート コンテナー レジストリからコンテナー化された関数アプリをデプロイする場合にのみ必要です。 詳細については、「Azure App Service の環境変数とアプリ設定」を参照してください。

DOCKER_SHM_SIZE

Python ワーカーが共有メモリを使用している場合の共有メモリのサイズ (バイト単位) を設定します。 詳細については、「共有メモリ」を参照してください。

Key	値の例
DOCKER_SHM_SIZE	268435456

上記の値は、最大 256 MB の共有メモリ サイズを設定します。

FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED を 1 に設定する必要があります。

ENABLE_ORYX_BUILD

デプロイ中に Oryx ビルド システム を使用するかどうかを示します。 Linux へのリモート ビルド デプロイを実行する場合は、ENABLE_ORYX_BUILD を true に設定する必要があります。 詳細については、「リモート ビルド」を参照してください。

Key	値の例
ENABLE_ORYX_BUILD	true

FUNCTION_APP_EDIT_MODE

Azure portal で関数アプリを編集できるかどうかを示します。 有効値は readwrite または readonly です。

Key	値の例
FUNCTION_APP_EDIT_MODE	readonly

この値は、関数アプリの言語スタックとデプロイの状態に基づいてランタイムによって設定されます。 詳細については、「Azure portal での開発の制限事項」をご覧ください。

FUNCTIONS_EXTENSION_VERSION

関数アプリをホストする Functions ランタイムのバージョンです。 メジャー バージョンにチルダ (~) が付いている場合は、そのメジャー バージョンの最新バージョンを使用することを意味します (例: ~3)。 同じメジャー バージョンの新しいバージョンが使用できる場合、それらは関数アプリに自動的にインストールされます。 特定のバージョンにアプリを固定するには、完全なバージョン番号 (例: 3.0.12345) を使用します。 既定値は ~3 です。 ~1 の値は、アプリをバージョン 1.x のランタイムに固定します。 詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」をご覧ください。 値が ~4 の場合、ランタイムのバージョン 4.x でアプリが実行されます。

キー	値の例
FUNCTIONS_EXTENSION_VERSION	~4

次のランタイムのメジャー バージョン値がサポートされています。

値	ランタイム ターゲット	解説
~4	4.x	推奨
~3	3.x	サポートされていません
~2	2.x	サポートされていません
~1	1.x	サポートは 2026 年 9 月 14 日に終了します

FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR

このアプリ設定は、Node.js アプリで破壊的変更を有効にする一時的な手段であり、Node.js v18 以前の場合、これによりエントリ ポイントのエラーがトラブルシューティングしやすくなります。 true を使用することを強くお勧めします。特に、エントリ ポイント ファイルを常に使用するプログラミング モデル v4 アプリではそう言えます。 破壊的変更なしの動作 (false) の場合、エントリ ポイントのエラーは無視され、Application Insights にログされません。

Node.js v20 以降では、このアプリ設定には何の効果もなく、破壊的変更の動作は常に有効になります。

Node.js v18 以前では、このアプリ設定を使用することができ、既定の動作はエラーの発生がモデル v4 関数の登録より先か後かによって異なります。

• エラーのスローが先だった場合 (たとえば、モデル v3 を使用している場合、またはエントリ ポイント ファイルが存在しない場合)、既定の動作は false と一致します。
• エラーのスローが後だった場合 (たとえば、重複するモデル v4 関数を登録しようとする場合)、既定の動作は true と一致します。

キー	値	説明
FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR	true	エントリ ポイントのエラーが発生するとブロックされ、Application Insights にログされます。
FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR	false	エントリ ポイントのエラーは無視され、Application Insights にログされません。

FUNCTIONS_V2_COMPATIBILITY_MODE

重要

この設定はサポートされなくなりました。 もともとは、v2.x ランタイムを対象とするアプリを、まだサポートされている間に代わりに v3.x ランタイムで実行できるようにするための短期的な回避策を有効にするために提供されていました。 バージョン 1.x で実行されるレガシ アプリを除き、すべての関数アプリはバージョン 4.x の Functions ランタイム (FUNCTIONS_EXTENSION_VERSION=~4) で実行する必要があります。 詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」をご覧ください。

FUNCTIONS_REQUEST_BODY_SIZE_LIMIT

HTTP エンドポイントに送信される要求の本文サイズの既定の制限をオーバーライドします。 この値はバイト単位で指定し、既定の最大要求サイズは 104857600 バイトです。

Key	値の例
FUNCTIONS_REQUEST_BODY_SIZE_LIMIT	250000000

FUNCTIONS_WORKER_PROCESS_COUNT

言語ワーカー プロセスの最大数を指定します。既定値は 1 です。 許容される最大値は 10 です。 関数呼び出しは、言語ワーカー プロセス間で均等に分散されます。 言語ワーカー プロセスは、FUNCTIONS_WORKER_PROCESS_COUNT によって設定されたカウントに達するまで、10 秒ごとに生成されます。 複数の言語ワーカー プロセスの使用は、スケーリングと同じではありません。 CPU にバインドされた呼び出しと I/O にバインドされた呼び出しがワークロードに混在している場合は、この設定を使用することを検討してください。 この設定は、プロセス (FUNCTIONS_WORKER_RUNTIME=dotnet) で実行されている .NET を除くすべての言語ランタイムに適用されます。

Key	値の例
FUNCTIONS_WORKER_PROCESS_COUNT	2

FUNCTIONS_WORKER_RUNTIME

関数アプリで読み込むワーカー ランタイムの言語または言語スタック。 これは、アプリケーションで使用されている言語に対応します (たとえば、python)。 Azure Functions Runtime のバージョン 2.x 以降では、特定の関数アプリでサポートできる言語は 1 つだけです。

Key	値の例
FUNCTIONS_WORKER_RUNTIME	node

有効な値:

Value	言語/言語スタック
dotnet	C# (クラス ライブラリ) C# (スクリプト)
dotnet-isolated	C# (分離ワーカー プロセス)
java	Java
node	JavaScript TypeScript
powershell	PowerShell
python	Python
custom	その他

FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED

この設定を使用すると、Python ワーカーが共有メモリを使用してスループットを向上できます。 Python 関数アプリがメモリのボトルネックに達すると、共有メモリが有効になります。

Key	値の例
FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED	1

この設定を有効にした場合、DOCKER_SHM_SIZE の設定を使用して共有メモリ サイズを設定できます。 詳細については、「共有メモリ」を参照してください。

JAVA_OPTS

Premium プランまたは Dedicated プランで実行する場合に、Java 関数を実行するために使用される Java 仮想マシン (JVM) をカスタマイズするために使用します。 従量課金プランで実行している場合は、代わりに languageWorkers__java__arguments を使用してください。 詳細については、「JVM のカスタマイズ」を参照してください。

languageWorkers__java__arguments

従量課金プランで実行する場合に、Java 関数を実行するために使用される Java 仮想マシン (JVM) をカスタマイズするために使用します。 この設定によって、従量課金プランで実行される Java 関数のコールド スタート時間が長くなります。 Premium プランまたは Dedicated プランの場合は、代わりに JAVA_OPTS を使用してください。 詳細については、「JVM のカスタマイズ」を参照してください。

MDMaxBackgroundUpgradePeriod

PowerShell 関数アプリの管理対象の依存関係のバックグラウンド更新期間を制御します。既定値は 7.00:00:00 (毎週) です。

各 PowerShell ワーカー プロセスは、そのプロセスの開始時に PowerShell ギャラリーでモジュールのアップグレードのチェックを開始し、その後は MDMaxBackgroundUpgradePeriod ごとにチェックします。 PowerShell ギャラリーで利用可能になった新しいモジュール バージョンは、ファイル システムにインストールされ、PowerShell ワーカーが使用できるになります。 この値を小さくすると、関数アプリは新しいモジュール バージョンを早く取得できますが、アプリ リソースの使用量 (ネットワーク I/O、CPU、ストレージ) も増加します。 この値を大きくすると、アプリ リソースの使用量は減少しますが、アプリへの新しいモジュール バージョンの配信も遅くなる可能性があります。

キー	値の例
MDMaxBackgroundUpgradePeriod	7.00:00:00

詳細については、「依存関係の管理」を参照してください。

MDNewSnapshotCheckPeriod

管理対象の依存関係のアップグレードがインストールされているかどうかを各 PowerShell ワーカーが確認する頻度を指定します。 既定の頻度は 01:00:00 (毎時) です。

新しいモジュール バージョンがファイル システムにインストールされたら、すべての PowerShell ワーカー プロセスを再起動する必要があります。 PowerShell ワーカーを再起動すると、現在の関数の実行が中断される可能性があるため、アプリの可用性がその影響を受けます。 すべての PowerShell ワーカー プロセスが再起動されるまで、関数呼び出しでは、前のモジュール バージョンまたは新しいモジュール バージョンのいずれかが使用される可能性があります。 すべての PowerShell ワーカーの再起動は MDNewSnapshotCheckPeriod 以内に完了します。

各 MDNewSnapshotCheckPeriod 内で、PowerShell ワーカーにより、管理対象の依存関係のアップグレードがインストールされているかどうかが確認されます。 アップグレードがインストールされると、再起動が開始されます。 この値を大きくすると、再起動による中断の頻度は減少します。 ただし、大きくすることにより、関数呼び出しで古いまたは新しいモジュール バージョンが非決定的に使用される可能性がある期間が長くなる恐れもあります。

キー	値の例
MDNewSnapshotCheckPeriod	01:00:00

詳細については、「依存関係の管理」を参照してください。

MDMinBackgroundUpgradePeriod

管理対象の依存関係のアップグレードに関する前回のチェックの後、別のアップグレード チェックが開始されるまでの期間。既定値は 1.00:00:00 (毎日) です。

ワーカーの頻繁な再起動によってモジュールのアップグレードが過剰にならないように、任意のワーカーで直近 MDMinBackgroundUpgradePeriod 以内にモジュールのアップグレード確認が開始されているときは、その確認は行われません。

Key	値の例
MDMinBackgroundUpgradePeriod	1.00:00:00

詳細については、「依存関係の管理」を参照してください。

PIP_INDEX_URL

この設定を使用すると、Python Package Index のベース URL (既定では https://pypi.org/simple) をオーバーライドできます。 この設定は、カスタム依存関係を使用してリモート ビルドを実行する必要がある場合に使用します。 これらのカスタム依存関係は、PEP 503 (単純なリポジトリ API) に準拠しているパッケージ インデックス リポジトリ、または同じ形式に従うローカル ディレクトリに入れることができます。

Key	値の例
PIP_INDEX_URL	http://my.custom.package.repo/simple

詳細は、--index-url については pip ドキュメントを、カスタム依存関係の使用については Python 開発者リファレンスを参照してください。

PIP_EXTRA_INDEX_URL

この設定の値は、--index-url に加えて使用する、Python アプリのカスタム パッケージの追加のインデックス URL を示します。 この設定は、追加のパッケージ インデックスにあるカスタム依存関係を使用してリモート ビルドを実行する必要がある場合に使用します。 --index-url と同じ規則に従う必要があります。

Key	値の例
PIP_EXTRA_INDEX_URL	http://my.custom.package.repo/simple

詳細は、--extra-index-url については pip ドキュメントを、カスタム依存関係については Python 開発者リファレンスを参照してください。

プロジェクト

[継続的デプロイ] 設定。Kudu デプロイ サービスに対して、デプロイ可能なプロジェクトの場所を接続されたリポジトリ内のフォルダーに指示します。

キー	値の例
プロジェクト	WebProject/WebProject.csproj

PYTHON_ISOLATE_WORKER_DEPENDENCIES

この構成は Python 関数アプリに固有です。 モジュール読み込み順序の優先順位を定義します。 既定では、この値は 0 に設定されます。

キー	値	説明
PYTHON_ISOLATE_WORKER_DEPENDENCIES	0	Python ライブラリを内部 Python worker の依存関係から読み込むことを優先します。これが既定の動作です。 requirements.txt で定義されているサードパーティ ライブラリはシャドウされる場合があります。
PYTHON_ISOLATE_WORKER_DEPENDENCIES	1	Python ライブラリを requirements.txt で定義されているアプリケーションのパッケージから読み込むことを優先します。 これにより、ライブラリが内部 Python ワーカーのライブラリと衝突することがなくなります。

PYTHON_ENABLE_DEBUG_LOGGING

Python 関数アプリでデバッグ レベルのログ記録を有効にします。 1 の値を指定すると、デバッグ レベルのログ記録が有効になります。 この設定がないか、値が 0 である場合、情報以上のレベルのログのみが Python ワーカーから Functions ホストに送信されます。 この設定は、Python 関数の実行をデバッグまたはトレースするときに使用します。

Python 関数をデバッグするとき、必要に応じて、host.json ファイルでデバッグまたはトレース ログ レベルも設定してください。 詳しくは、Azure Functions で監視を構成する方法に関するページを参照してください。

PYTHON_ENABLE_WORKER_EXTENSIONS

この構成は Python 関数アプリに固有です。 これを 1 に設定することで、ワーカーは requirements.txt で定義されている 1で読み込みが可能になります。 これにより、関数アプリはサードパーティ製パッケージによって提供される新機能にアクセスできます。 また、アプリでの関数の読み込みと呼び出しの動作が変更される場合もあります。 選択する拡張機能は、それを使用するとリスクが生じるので、信頼できるものであることを確認してください。 Azure Functions は、あらゆる拡張機能に対して明示的な保証をしません。 拡張機能の使い方については、拡張機能のマニュアル ページまたは readme ドキュメントを参照してください。既定では、この値は 0 に設定されます。

キー	値	説明
PYTHON_ENABLE_WORKER_EXTENSIONS	0	Python ワーカー拡張機能を無効にします。
PYTHON_ENABLE_WORKER_EXTENSIONS	1	Python ワーカーが requirements.txt から拡張機能を読み込めるようにします。

PYTHON_THREADPOOL_THREAD_COUNT

関数呼び出しを実行するために Python 言語ワーカーによって使用されるスレッドの最大数を指定します。Python バージョン 3.8 以前では、既定値 1 を使用します。 Python バージョン 3.9 以降では、値は None に設定されます。 この設定は、実行中に設定されるスレッドの数を保証するものではありません。 この設定により、Python では、スレッドの数を指定された値に増やすことができます。 この設定は、Python 関数アプリにのみ適用されます。 また、この設定は、コルーチンではなく、同期関数の呼び出しに適用されます。

Key	値の例	最大値
PYTHON_THREADPOOL_THREAD_COUNT	2	32

SCALE_CONTROLLER_LOGGING_ENABLED

"この設定は現在プレビューの段階です。 "

この設定は、Azure Functions スケール コントローラーからのログ記録を制御します。 詳細については、スケール コントローラーのログに関するセクションを参照してください。

Key	値の例
SCALE_CONTROLLER_LOGGING_ENABLED	AppInsights:Verbose

このキーの値は <DESTINATION>:<VERBOSITY> の形式で指定されます。これは次のように定義されます。

プロパティ	説明
<DESTINATION>	ログの送信先。 有効な値は AppInsights と Blob です。 AppInsights を使用する場合は、関数アプリで Application Insights が有効になっていることを確認してください。 宛先を Blob に設定すると、AzureWebJobsStorage アプリケーション設定で設定されている既定のストレージ アカウントの azure-functions-scale-controller という名前の BLOB コンテナーにログが作成されます。
<VERBOSITY>	ログ記録のレベルを指定します。 サポートされている値は、None、Warning、および Verbose です。 Verbose に設定すると、スケール コントローラーは、すべてのワーカー数の変更の理由と、それらの決定の要因となるトリガーに関する情報をログに記録します。 詳細ログには、トリガー警告と、スケール コントローラーの実行前と実行後にトリガーによって使用されたハッシュが含まれます。

ヒント

スケール コントローラーのログを有効にしたままにすると、関数アプリの監視にかかる可能性のあるコストに影響することに注意してください。 スケール コントローラーの動作を理解するのに十分なデータを収集するまでログ記録を有効にし、その後は無効にすることを検討してください。

SCM_DO_BUILD_DURING_DEPLOYMENT

デプロイ中のリモート ビルドの動作を制御します。 SCM_DO_BUILD_DURING_DEPLOYMENT が true に設定されている場合、プロジェクトはデプロイ中にリモートでビルドされます。

Key	値の例
SCM_DO_BUILD_DURING_DEPLOYMENT	true

SCM_LOGSTREAM_TIMEOUT

ストリーミング ログに接続されているときのタイムアウトを秒単位で制御します。 既定値は 7,200 (2 時間) です。

Key	値の例
SCM_LOGSTREAM_TIMEOUT	1800

上記のサンプル値 1800 では、タイムアウトが 30 分に設定されます。 詳しくは、「Azure Functions で実行ログのストリーミングを有効にする」をご覧ください。

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

イベント ドリブン スケーリング プランに関数アプリのコードと構成が格納されているストレージ アカウントの接続文字列です。 詳細については、「ストレージ アカウント接続の設定」を参照してください。

キー	値の例
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING	DefaultEndpointsProtocol=https;AccountName=...

この設定は、Windows と Linux の両方で実行されている従量課金と Elastic Premium のプランのアプリに必須です。 Functions によって動的にスケーリングされない Dedicated プランのアプリには必須ではありません。

この設定を変更または削除すると、関数アプリが起動しなくなることがあります。 詳細については、こちらのトラブルシューティング記事を参照してください。

Azure Files では、ファイル共有にアクセスするときにマネージド ID を使用することはできません。 詳細については、Azure Files でサポートされている認証シナリオに関する記事を参照してください。

WEBSITE_CONTENTOVERVNET

1 の値を指定すると、ストレージ アカウントを仮想ネットワークに制限している場合に、関数アプリをスケーリングできます。 ストレージ アカウントを仮想ネットワークに制限する場合は、この設定を有効にする必要があります。 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING を使用する場合にのみ必須です。 詳細については、「ストレージ アカウントを仮想ネットワークに制限する」を参照してください。

Key	値の例
WEBSITE_CONTENTOVERVNET	1

Premium および Dedicated (App Service) プラン (Standard 以上) でサポートされています。 従量課金プランで実行している場合はサポートされません。

WEBSITE_CONTENTSHARE

関数アプリのコードと構成ファイルを保存するために Functions で使用するファイル共有の名前。 このコンテンツは、イベント ドリブン スケーリング プランで必要です。 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING で使用されます。 既定は、関数アプリ名で始まる、ランタイムによって生成される一意文字列です。 詳細については、「ストレージ アカウント接続の設定」を参照してください。

キー	値の例
WEBSITE_CONTENTSHARE	functionapp091999e2

この設定は、Windows と Linux の両方で従量課金と Premium のプランのアプリに必須です。 Functions によって動的にスケーリングされない Dedicated プランのアプリには必須ではありません。

共有は、関数アプリの作成時に作成されます。 この設定を変更または削除すると、関数アプリが起動しなくなることがあります。 詳細については、こちらのトラブルシューティング記事を参照してください。

デプロイ時に Azure Resource Manager (ARM) テンプレートまたは Bicep ファイルを使用して関数アプリを作成する場合は、次の考慮事項が適用されます。

• メインの関数アプリまたはスロット内の任意のアプリに WEBSITE_CONTENTSHARE 値を設定しない場合、一意の共有値が自動的に生成されます。 WEBSITE_CONTENTSHARE を設定しないことは、ARM テンプレートのデプロイでお勧めしている方法です。
• WEBSITE_CONTENTSHARE 値を事前定義の値に設定する必要があるシナリオが存在します。たとえば、セキュリティで保護されたストレージ アカウントを仮想ネットワークで使用する場合などです。 この場合、メインの関数アプリと各デプロイ スロットのアプリに異なる固有の共有名を設定する必要があります。 仮想ネットワークによってセキュリティ保護されたストレージ アカウントの場合は、自動デプロイの一部として共有自体も作成する必要があります。 詳細については、セキュリティで保護されたデプロイに関する記事を参照してください。
• WEBSITE_CONTENTSHARE はスロット設定にしないでください。
• WEBSITE_CONTENTSHARE を指定する場合、値は共有名に関するこちらのガイダンスに従っている必要があります。

WEBSITE_DNS_SERVER

IP アドレスの解決時にアプリによって使用される DNS サーバーを設定します。 この設定は、Azure DNS Private Zones やプライベート エンドポイントなど、特定のネットワーク機能を使用する場合に必要になることがよくあります。

Key	値の例
WEBSITE_DNS_SERVER	168.63.129.16

WEBSITE_ENABLE_BROTLI_ENCODING

圧縮のために既定の gzip 圧縮ではなく、Brotli エンコーディングが使用されるかどうかを制御します。 WEBSITE_ENABLE_BROTLI_ENCODING が 1 に設定されている場合は Brotli エンコーディングが使用され、それ以外の場合は gzip エンコーディングが使用されます。

WEBSITE_FUNCTIONS_ARMCACHE_ENABLED

Azure Resource Manager (ARM) テンプレートを使用して関数アプリをデプロイするときにキャッシュを無効にします。

Key	値の例
WEBSITE_FUNCTIONS_ARMCACHE_ENABLED	0

WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT

アプリがスケールアウトできる最大のインスタンス数です。 既定は無制限です。

重要

この設定は、プレビューの段階です。 スケールアウトの制限に推奨される、関数で最大にスケールアウトするためのアプリ プロパティが追加されています。

Key	値の例
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT	5

WEBSITE_NODE_DEFAULT_VERSION

Windows のみ。 Windows で関数アプリを実行するときに使用する Node.js のバージョンを設定します。 チルダ (~) を使用して、ランタイムがターゲット メジャー バージョンの利用可能な最新バージョンを使用するようにする必要があります。 たとえば、~18 に設定すると、Node.js 18 の最新バージョンが使用されます。 メジャー バージョンがチルダ付きで対象になっている場合は、マイナー バージョンを手動で更新する必要はありません。

Key	値の例
WEBSITE_NODE_DEFAULT_VERSION	~18

WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS

Premium プランで実行されている関数アプリでスロットのスワップを実行すると、アプリで使用されている専用ストレージ アカウントがネットワーク制限されている場合にスワップが失敗することがあります。 この失敗は、Functions と App Service が共有する従来のアプリケーション ログ機能が原因です。 この設定を行うと、その従来のログ機能がオーバーライドされ、スワップを実行できるようになります。

キー	値の例
WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS	0

0 の値を持つ WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS をすべてのスロットに追加して、従来の診断設定によってスワップがブロックされないようにします。 また、この設定と値を、 デプロイ スロット (sticky) 設定として、運用スロットのみに追加することもできます。

WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS

既定では、関数アプリのバージョン設定は各スロットに固有です。 この設定は、デプロイ スロットを使用して関数をアップグレードするときに使用されます。 これにより、スワップ後にバージョンが変更されるために発生する予期しない動作を防ぐことができます。 運用環境とスロットで 0 に設定して、すべてのバージョン設定もスワップされるようにします。 詳細については、「スロットを使用したアップグレード」を参照してください。

Key	値の例
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS	0

WEBSITE_RUN_FROM_PACKAGE

ローカルにマウントすることも、外部 URL にデプロイすることもできるパッケージ ファイルから関数アプリを実行できるようにします。

キー	値の例
WEBSITE_RUN_FROM_PACKAGE	1

有効な値は、外部デプロイ パッケージ ファイルの場所に解決される URL、または 1 です。 1 に設定した場合、パッケージは d:\home\data\SitePackages フォルダーに存在する必要があります。 WEBSITE_RUN_FROM_PACKAGE を有効にして zip デプロイを使用すると、パッケージは自動的にこの場所にアップロードされます。 プレビューでは、この設定は WEBSITE_RUN_FROM_ZIP という名前でした。 詳細については、パッケージ ファイルからの関数の実行に関するページを参照してください。

外部パッケージ URL からデプロイする場合は、トリガーを手動で同期する必要もあります。 詳細については、「同期のトリガー」を参照してください。

WEBSITE_SKIP_CONTENTSHARE_VALIDATION

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING と WEBSITE_CONTENTSHARE 設定には、アプリを適切に起動できることを確認する追加の検証チェックがあります。 ネットワークの制約やその他の制限要因により、関数アプリがダウンストリームのストレージ アカウントまたは Key Vault を適切に呼び出せない場合、アプリケーション設定の作成は失敗します。 WEBSITE_SKIP_CONTENTSHARE_VALIDATION が 1 に設定されている場合、検証チェックはスキップされます。それ以外の場合、値は既定の 0 になり、検証が実行されます。

キー	値の例
WEBSITE_SKIP_CONTENTSHARE_VALIDATION	1

検証がスキップされ、なおかつ接続文字列またはコンテンツ共有が無効である場合、アプリは正常に開始できません。 この場合、関数は HTTP 500 エラーを返します。 詳細については、「"Azure Functions Runtime に到達できない" エラーのトラブルシューティング」を参照してください

WEBSITE_SLOT_NAME

読み取り専用です。 現在のデプロイ スロットの名前。 運用スロットの名前は Production です。

Key	値の例
WEBSITE_SLOT_NAME	Production

WEBSITE_TIME_ZONE

関数アプリのタイムゾーンを設定できます。

Key	OS	値の例
WEBSITE_TIME_ZONE	Windows	Eastern Standard Time
WEBSITE_TIME_ZONE	Linux	America/New_York

CRON 式で使用する既定のタイム ゾーンは、協定世界時 (UTC) です。 別のタイム ゾーンに基づく CRON 式を使うには、Function App 用に WEBSITE_TIME_ZONE という名前のアプリ設定を作成します。

この設定の値は、関数アプリを実行するオペレーティング システムとプランによって異なります。

オペレーティング システム	プラン	値
Windows	すべて	Windows コマンド tzutil.exe /L によって指定された各ペアの 2 行目に指定されているように、この値を目的のタイム ゾーンの名前に設定します。
Linux	Premium 専用	この値を、tz データベースに関するページに示されている目的のタイム ゾーンの名前に設定します。

Note

従量課金プランで Linux 上で実行している場合、WEBSITE_TIME_ZONE と TZ は現在サポートされていません。 この場合、WEBSITE_TIME_ZONE または TZ を設定すると、SSL 関連の問題が発生し、メトリックによってアプリの動作が停止する可能性があります。

たとえば、米国の東部標準時 (Eastern Standard Time (Windows) または America/New_York (Linux)) では現在、標準時では UTC-05:00、夏時間では UTC-04:00 を使用します。 タイマー トリガーが毎日東部標準時の午前 10 時に発生するように設定するには、関数アプリのアプリ設定を WEBSITE_TIME_ZONE という名前で作成し、その値を Eastern Standard Time (Windows) または America/New_York (Linux) に設定して、次の NCRONTAB 式を使用します。

"0 0 10 * * *"

WEBSITE_TIME_ZONE を使用すると、夏時間などの特定のタイムゾーンでの時間変更や標準時での変更に対応するように、時刻が調整されます。

WEBSITE_USE_PLACEHOLDER

従量課金プランで実行するときに、特定のコールド スタート最適化を使用するかどうかを示します。 従量課金プランでコールド スタート最適化を無効にするには、0 に設定します。

Key	値の例
WEBSITE_USE_PLACEHOLDER	1

WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED

従量課金プランで .NET 分離ワーカー プロセス関数を実行するときに、特定のコールド スタート最適化を使用するかどうかを示します。 従量課金プランでコールド スタート最適化を無効にするには、0 に設定します。

Key	サンプルの値
WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED	1

WEBSITE_VNET_ROUTE_ALL

重要

WEBSITE_VNET_ROUTE_ALL は、レガシ アプリ設定で、vnetRouteAllEnabled サイト設定に置き換わりました。

アプリからのすべての送信トラフィックが仮想ネットワーク経由でルーティングされるかどうかを示します。 設定値が 1 の場合は、すべてのトラフィックが仮想ネットワーク経由でルーティングされることを示します。 リージョンでの仮想ネットワーク統合の機能を使用する場合は、この設定が必要です。 また、仮想ネットワーク NAT ゲートウェイを使用して静的な送信 IP アドレスを定義する場合にも使用されます。

Key	値の例
WEBSITE_VNET_ROUTE_ALL	1

WEBSITES_ENABLE_APP_SERVICE_STORAGE

/home ディレクトリがスケーリングされたインスタンス間で共有されているかどうかを示します。既定値は true です。 これは、関数アプリをコンテナーにデプロイするときに false に設定する必要があります。 d

App Service サイトの設定

一部の構成は、言語バージョンなど、サイト設定として App Service レベルで維持する必要があります。 これらの設定は、REST API を使用するか、Azure CLI または Azure PowerShell を使用して、ポータル内で管理されます。 ランタイム言語、OS、バージョンに応じて必要になる可能性があるサイト設定を次に示します。

alwaysOn

専用 (App Service) プランで実行されている関数アプリでは、関数ランタイムは、数分間非アクティブになるとアイドル状態になります。この時点では、関数をウェイクアップさせるのは HTTP トリガーへの要求のみです。 HTTP トリガー以外の関数 (タイマー トリガーを含む) が正しく実行されるようにするには、alwaysOn サイト設定を true の値に設定して、関数アプリに対して Always On を有効にします。

linuxFxVersion

Linux で実行されている関数アプリの場合は、linuxFxVersion は言語固有のワーカー プロセスの言語とバージョンを示します。 この情報は、関数アプリを実行するためにインストールされている特定の Linux コンテナー イメージを決定するために、FUNCTIONS_EXTENSION_VERSION とともに使用されます。 この設定は、事前定義済みの値またはカスタム イメージ URI に設定できます。

この値は、Linux 関数アプリを作成するときに設定されます。 ARM テンプレートと Bicep のデプロイ、特定のアップグレード シナリオで設定する必要がある場合があります。

有効な linuxFxVersion 値

次の Azure CLI コマンドを使用して、サポートされている Functions ランタイム バージョン別の現在の linuxFxVersion の値の表を表示できます。

az functionapp list-runtimes --os linux --query "[].{stack:join(' ', [runtime, version]), LinuxFxVersion:linux_fx_version, SupportedFunctionsVersions:to_string(supported_functions_versions[])}" --output table

以前のコマンドでは、Azure CLI のバージョン 2.40 にアップグレードする必要があります。

カスタム イメージ

関数アプリ用に独自のカスタム Linux コンテナーを作成して保守する場合、linuxFxVersion 値は次の例のように、代わりに DOCKER|<IMAGE_URI> の形式になります。

linuxFxVersion = "DOCKER|contoso.com/azurefunctionsimage:v1.0.0"

これは、デプロイされたコンテナーのレジストリ ソースを示します。 詳細については、「コンテナーと Azure Functions を使用する」を参照してください。

重要

独自のコンテナーを作成する場合は、コンテナーの基本イメージを、サポートされている最新の基本イメージに更新しておく必要があります。 Azure Functions でサポートされている基本イメージは言語固有であり、Azure Functions 基本イメージ リポジトリにあります。

Functions チームは、これらの基本イメージの毎月の更新プログラムを公開できるよう取り組んでいます。 通常の更新プログラムには、Functions ランタイムと言語の両方について、最新のマイナー バージョンの更新プログラムとセキュリティ修正プログラムが含まれます。 最新の基本イメージからコンテナーを定期的に更新し、コンテナーの更新されたバージョンを再デプロイする必要があります。

netFrameworkVersion

C# 関数用の .NET の特定のバージョンを設定します。 詳細については、「Azure で関数アプリを更新する」を参照してください。

powerShellVersion

関数を実行する PowerShell の特定のバージョンを設定します。 詳細については、「PowerShell のバージョンの変更」を参照してください。

ローカルで実行する場合は、代わりに local.settings.json ファイルの FUNCTIONS_WORKER_RUNTIME_VERSION 設定を使用します。

vnetrouteallenabled

アプリからのすべての送信トラフィックが仮想ネットワーク経由でルーティングされるかどうかを示します。 設定値が 1 の場合は、すべてのトラフィックが仮想ネットワーク経由でルーティングされることを示します。 リージョンでの仮想ネットワーク統合の機能を使用する場合は、この設定が必要です。 また、仮想ネットワーク NAT ゲートウェイを使用して静的な送信 IP アドレスを定義する場合にも使用されます。 詳細については、「アプリケーションのルーティングを構成する」を参照してください。

このサイト設定は、従来の WEBSITE_VNET_ROUTE_ALL 設定に置き換わるものです。

次のステップ

アプリケーション設定の更新方法

host.json ファイルの構成設定を参照する

App Service アプリの他のアプリ設定を参照する