Azure Functions ランタイム バージョンの概要

Azure Functions は現在、2 つのバージョンのランタイム ホストをサポートしています。 次の表は、現在サポートされているランタイム バージョン、サポート レベル、使うべきタイミングについての詳細を示しています。

この記事では、サポートされているバージョン間のいくつかの相違点、各バージョンの作成方法、関数が実行されるバージョンの変更方法について詳細に説明します。

サポートのレベル

次の 2 つのレベルのサポートがあります。

• 一般公開 (GA) - 完全にサポートされ、運用環境用に承認されています。
• プレビュー - まだサポートされていませんが、今後 GA 状態に達すると想定されています。

Languages

関数アプリ内のすべての関数は、同じ言語を共有する必要があります。 アプリを作成するときに、関数アプリで関数の言語を選びます。 関数アプリの言語は FUNCTIONS_WORKER_RUNTIME 設定に保持され、既存の関数がある場合は変更できません。

必ず、記事の上部にある任意の開発言語を選択してください。

言語サポートに対する計画的な変更については、Azureロードマップの更新を参照してください。

以前にサポートされていたバージョンの Functions ランタイムの言語バージョンについては、「廃止されたランタイム バージョン」を参照してください。

特定のバージョンで実行する

Azureで発行されたアプリによって使用される Functions ランタイムのバージョンは、FUNCTIONS_EXTENSION_VERSION アプリケーション設定によって決まります。 場合によっては、特定の言語に対して、他の設定が適用される場合があります。

既定では、Azure ポータル、Azure CLI、または Visual Studio ツールから作成された関数アプリは、バージョン 4.x に設定されます。 このバージョンは必要に応じて変更できます。 ランタイムのバージョンを 1.x にダウングレードできるのは、関数アプリを作成してから関数を追加するまでの間のみです。 より新しいメジャー バージョンへの更新は、既存の関数が含まれているアプリでも許可されます。

既存の関数アプリを移行する

アプリに既存の関数があるときは、以降のメジャー ランタイム バージョンに移行する前に予防措置を講じる必要があります。 次の記事では、言語固有の破壊的変更などの、メジャー バージョン間の破壊的変更について詳しく説明します。 既存の関数アプリを正常に移行するための段階的な手順も提供されます。

• ランタイム バージョン 3.x からバージョン 4.x に移行する
• ランタイム バージョン 1.x からバージョン 4.x に移行する

Azure でのアプリのバージョンの変更

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

特定のマイナー バージョンに固定する

最新のメジャー バージョンで実行しているときに関数アプリで発生する可能性がある問題を解決するには、アプリを特定のマイナー バージョンに一時的にピン留めする必要があります。 固定により、最新のメジャー バージョンでアプリが正しく実行されるようになります。 マイナー バージョンにピン留めする方法は、Windowsと Linux で異なります。 詳細については、「Azure Functions のランタイムバージョンをターゲットにする方法」を参照してください。

古いマイナー バージョンは、定期的に Functions から削除されます。 特定の古いマイナー バージョンの削除など、Azure Functionsリリースに関する最新のニュースについては、Azure App Service のお知らせを監視します。

拡張機能の最小バージョン

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

廃止されたバージョン

これらのバージョンの Functions ランタイムは、2022 年 12 月 13 日に延長サポート終了に達しました。

完全なサポートを受けるには、できるだけ早く、アプリをバージョン 4.x に移行する必要があります。 言語固有の移行手順の完全なセットについては、「Migrate apps to Azure Functions version 4.x を参照してください。

バージョン 2.x と 3.x を使用しているアプリは、引き続き CI/CD DevOps パイプラインから関数アプリを作成してデプロイすることができ、既存のアプリはすべて破壊的変更を生じさせることなく引き続き実行されます。 ただし、アプリは、新機能、セキュリティ パッチ、パフォーマンス最適化の対象にはなりません。 関連するサービス サポートは、アプリをバージョン 4.x にアップグレードした後にのみ受けることができます。

コア依存関係であった .NET Core 3.1 のサポートが終了したため、バージョン 2.x と 3.x はサポートされなくなりました。 この要件は、Azure Functions でサポートされているすべての language に影響します。

ローカルで開発されたアプリケーションのバージョン

関数アプリを次のように更新し、ターゲット バージョンをローカルで変更できます。

Visual Studio ランタイム バージョン

Visual Studioでは、プロジェクトの作成時にランタイム バージョンを選択します。 Visual Studio用のAzure Functions ツールでは、2 つの主要なランタイム バージョンがサポートされています。 デバッグ時と公開時には、プロジェクトの設定に基づいて正しいバージョンが使用されます。 バージョン設定は、次のプロパティの .csproj ファイルで定義されます。

<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

<TargetFramework>net48</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>

Visual Studio CodeとAzure Functions Core Tools

Azure Functions Core Tools はコマンド ライン開発に使用され、Visual Studio Codeの Azure Functions 拡張機能でも使用されます。 詳細については、「 Azure Functions Core Tools のインストールを参照してください。

Visual Studio Code開発では、インストールされているツールのバージョンと一致するように、azureFunctions.projectRuntimeのユーザー設定を更新する必要がある場合もあります。 この設定で、関数アプリの作成時に使用されるテンプレートと言語も更新されます。

バインド

バージョン 2.x 以降では、ランタイムは新しい binding extensibility model を使用します。このモデルには、次の利点があります。

• Microsoft 以外のバインド拡張機能のサポート。

• ランタイムとバインドの分離。 この変更により、バインド拡張を個別にバージョン管理したり、解放したりできます。 たとえば、基になる SDK の新しいバージョンに依存する拡張のバージョンにアップグレードするよう選択できます。

• より軽量な実行環境。ここでは、使用中のバインドのみがランタイムによって識別され、読み込まれます。

HTTP とタイマーのトリガーを除き、すべてのバインドを関数アプリ プロジェクトに明示的に追加するか、ポータルで登録する必要があります。 詳細については、「Azure Functions バインディング式パターンを参照してください。

次の表は、Azure Functions ランタイムのメジャー バージョンでサポートされているバインディングを示しています。

1. HTTP とタイマーを除くすべてのバインディングを登録します。 Azure Functions バインド拡張機能の登録を参照してください。 Functions ランタイムのバージョン 1.x を使用する場合、この手順は必要ありません。
2. 2026 年 9 月 14 日にAzure Functions ランタイムのバージョン 1.x のサポートが終了。 完全なサポートのためにアプリをバージョン 4.x に移行します。
3. トリガーは従量課金プランではサポートされていません。 このバインドの種類には 、ランタイム 駆動型のトリガーが必要です。
4. このバインドの種類は、Kubernetes、Azure IoT Edge、およびその他のセルフホステッド モードでのみサポートされます。

関数アプリのタイムアウト期間

host.jsonプロジェクト ファイルの プロパティは、関数アプリの関数のタイムアウト期間を設定します。 このプロパティは、関数の実行に特に適用されます。 トリガーが関数の実行を開始した後、関数はタイムアウト期間内に戻るか応答する必要があります。 実行がこの期間を超えると、タイムアウト エラーが発生し、言語ワーカー プロセスが再起動します。 インプロセスで実行されている C# アプリの場合、ホスト プロセス自体が再起動します。 タイムアウトとその後のプロセスの再起動を回避するには、 堅牢な関数を記述することが重要です。 詳細については、「Improve Azure Functionsのパフォーマンスと信頼性を参照してください。

次の表は、特定のプランの既定値と最大値 (分) を示しています。

1. 関数アプリのタイムアウト設定に関係なく、HTTP によってトリガーされる関数が要求に応答するのにかかる最大時間は 230 秒です。 この制限は、Azure Load Balancer の 既定のアイドル タイムアウトが原因で発生します。 処理時間を長くするには、Durable Functions非同期パターンまたはを使用して実際の作業を定義し、即時応答を返すようにすることを検討してください。
2. 実行タイムアウトの最長期間は適用されません。 ただし、関数の実行に与えられる猶予期間は、Flex 従量課金プランと Premium プランの場合、スケールイン中は 60 分であり、プラットフォームの更新中は 10 分の猶予期間が与えられます。
3. App Service プランが Always On に設定されている必要があります。 プラットフォームの更新中は 10 分の猶予期間が与えられます。
4. Functions ホスト ランタイムのバージョン 1.x の既定のタイムアウトは 無制限です。
5. 最小レプリカ数が 0 に設定されている場合、既定のタイムアウトはアプリで使われている特定のトリガーによって異なります。

これらの値は、Azure Functions ホスト プロセスが開始され、正常に実行されることを前提としています。 言語固有のワーカー プロセスも開始するには、最大 60 秒のタイムアウトがあります。 ワーカー プロセスのスタートアップ タイムアウトは現在構成できません。

関連コンテンツ

詳細については、次のリソースを参照してください。

• Core Tools を使用して Azure Functions をローカルで開発する
• Azure Functions のランタイムバージョンをターゲットにする方法
• リリースノート