次の方法で共有


Azure Functions バージョン 1.x からバージョン 4.x にアプリを移行する

重要

Azure Functions ランタイムのバージョン 1.x では、Java はサポートされていません。 Java アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。 バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions ランタイムのバージョン 1.x では、TypeScript はサポートされていません。 TypeScript アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。 バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions ランタイムのバージョン 1.x では、PowerShell はサポートされていません。 PowerShell アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。 バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions ランタイムのバージョン 1.x では、Python はサポートされていません。 Python アプリをバージョン 3.x からバージョン 4.x に移行することを検討している場合はこちらを参照してください。 バージョン 1.x の関数アプリを移行する場合は、上の C# または JavaScript のいずれかを選んでください。

重要

Azure Functions Runtime のバージョン 1.x のサポートは 2026 年 9 月 14 日に終了します。 この記事の手順に従って、アプリをバージョン 4.x に移行することを強くお勧めします。

この記事では、Functions ランタイムのバージョン 4.x で実行するように関数アプリを安全に移行するプロセスについて説明します。 プロジェクトの移行手順は言語に依存するため、記事の上部にあるセレクターから開発言語を選択してください。

Azure Stack Hub でバージョン 1.x のランタイムを実行している場合は、最初に 「Azure Stack Hub の考慮事項」 を参照してください。

移行する関数アプリを特定する

次の PowerShell スクリプトを使用して、現在バージョン 1.x を対象とするサブスクリプション内の関数アプリの一覧を生成します。

$Subscription = '<YOUR SUBSCRIPTION ID>' 

Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*1*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

ターゲットの .NET バージョンを選択する

Functions ランタイムのバージョン 1.x では、C# 関数アプリは .NET Framework をターゲットとします。

関数アプリを移行すると、.NET のターゲット バージョンを選択できます。 C# プロジェクトを Functions バージョン 4.x でサポートされている次のいずれかのバージョンの .NET に更新できます。

.NET バージョン .NET 公式サポート ポリシー のリリースの種類 Functions プロセス モデル1、2
.NET 9 STS (2026 年 5 月 12 日にサポート終了) 分離ワーカー モデル
.NET 8 LTS (2026 年 11 月 10 日にサポート終了) 分離ワーカー モデル
インプロセス モデル2
.NET Framework 4.8 ポリシーを参照 分離ワーカー モデル

1分離ワーカー モデルでは、.NET の長期サポート (LTS) と標準期間サポート (STS) の各バージョンと、.NET Framework がサポートされます。 インプロセス モデルでは、.NET の LTS リリースのみがサポートされます (.NET 8 で終了)。 2 つのプロセス モデル間の完全な機能の比較については、インプロセスと分離ワーカー プロセスの .NET Azure Functions の違いに関するページを参照してください。

2 インプロセス モデルのサポートは、2026 年 11 月 10 日に終了します。 詳細については、こちらのサポートに関するお知らせを参照してください。 完全なサポートを受け続けるには、分離ワーカー モデルにアプリを移行する必要があります。

ヒント

アプリが .NET Framework でのみ使用できるライブラリまたは API に依存していない限り、分離ワーカー モデルで .NET 8 に更新することをお勧めします。 バージョン 1.x の多くのアプリでは、それらが作成されたときに使用可能だったため、.NET Framework のみをターゲットとしています。 より新しいバージョンの .NET では追加の機能を使用できます。アプリで依存関係を理由とした .NET Framework の維持が強制されない場合は、最新のバージョンをターゲットにする必要があります。 .NET 8 は、.NET から最長のサポート期間を持つ完全にリリースされたバージョンです。

インプロセス モデルを代わりに使用することもできますが、回避できる場合は推奨されません。 インプロセス モデルの場合は、サポートは 2026 年 11 月 10 日に終了するため、その前に分離ワーカー モデルに移行する必要があります。 バージョン 4.x に移行する際にこれを行うことで、必要な作業の合計を減らすことができます。また、分離ワーカー モデルは、将来のバージョンの .NET をより簡単にターゲットにできるなど、アプリにさらなるベネフィットをもたらします。 分離ワーカー モデルに移行する場合は、.NET アップグレード アシスタントで必要なコード変更の多くを自動的に処理することもできます。

このガイドでは、.NET 9 の具体的な例については説明しません。 このバージョンを対象にする必要がある場合は、.NET 8 の分離ワーカー モデルの例を応用できます。

移行を準備する

まだ実行していない場合は、Azure PowerShell を使用して、現在の Azure サブスクリプションで移行する必要があるアプリの一覧を特定します。

Functions ランタイムのバージョン 4.x にアプリを移行する前に、次のタスクを実行する必要があります。

  1. バージョン 1.x の後に加えられた動作の変更一覧を確認します。 バージョン 1.x からバージョン 4.x に移行すると、バインディングにも影響する可能性があります。
  2. ローカル プロジェクトを移行する」の手順を完了してローカル プロジェクトをバージョン 4.x に移行します。
  3. プロジェクトを移行したら、Azure Functions Core Tools のバージョン 4.x を使用して、アプリをローカルで完全にテストします。
  4. Azure の関数アプリを新しいバージョンに更新します。 ダウンタイムを最小限に抑える必要がある場合は、ステージング スロットを使用して、新しいランタイム バージョンで移行したアプリを Azure でテストおよび検証することを検討してください。 その後、更新されたバージョン設定を使用してアプリを運用スロットにデプロイできます。 詳細については、「スロットを使用した更新」を参照してください。
  5. 移行したプロジェクトを更新された関数アプリに発行します。

Visual Studio を使用してバージョン 4.x プロジェクトを下位バージョンの既存の関数アプリに発行する場合は、デプロイ時に Visual Studio で関数アプリをバージョン 4.x に更新するように求められます。 この更新では、「スロットなしの更新」で定義されているのと同じプロセスが使用されます。

ローカル プロジェクトを移行する

以下のセクションでは、Functions バージョン 4.x でサポートされる .NET のいずれかのバージョンで実行するために、C# プロジェクト ファイルに加える必要がある更新について説明します。 記載されている更新は、ほとんどのプロジェクトに共通するものです。 特にカスタム NuGet パッケージを使っている場合、この記事に記載されていない更新がプロジェクト コードに必要になる場合があります。

C# 関数アプリを Functions ランタイムのバージョン 1.x からバージョン 4.x に移行するには、プロジェクト コードを変更する必要があります。 これらの変更の多くは、C# 言語と .NET API が変更された結果によるものです。

.NET のターゲット バージョンと目的のプロセス モデル (インプロセスまたは分離ワーカー プロセス) に一致するタブを選択します。

ヒント

分離ワーカー モデルを使用して LTS または STS バージョンの .NET に移行する場合は、.NET アップグレード アシスタント を使用して、次のセクションで説明する多くの変更を自動的に行うことができます。

プロジェクト ファイル

次の例は、バージョン 1.x で動作する .csproj プロジェクト ファイルです。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AzureFunctionsVersion>v1</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Functions バージョン 4.x で実行するようにこの XML ファイルを更新するには、次のいずれかの手順に従います。

以下の手順はローカル C# プロジェクトを想定しています。代わりに C# スクリプト (.csx ファイル) がアプリで使用されている場合、プロジェクト モデルに変換してから続行してください。

.csproj XML プロジェクト ファイルには、次の変更を加える必要があります。

  1. PropertyGroup の値を設定します。TargetFramework から net8.0

  2. PropertyGroup の値を設定します。AzureFunctionsVersion から v4

  3. 次の OutputType 要素を PropertyGroup に追加します。

    <OutputType>Exe</OutputType>
    
  4. ItemGroup で。PackageReference リストで、Microsoft.NET.Sdk.Functions へのパッケージ参照を次の参照に置き換えます。

      <FrameworkReference Include="Microsoft.AspNetCore.App" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
      <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
      <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    

    Microsoft.Azure.WebJobs.* 名前空間内の他のパッケージへの参照を書き留めます。 これらのパッケージは後の手順で置き換えます。

  5. 次の新しい ItemGroup を追加します。

    <ItemGroup>
      <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
    </ItemGroup>
    

これらの変更を行うと、更新されたプロジェクトは次の例のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

パッケージと名前空間の変更

移行先のモデルに基づいて、アプリケーションが参照するパッケージを更新または変更する必要がある場合があります。 ターゲット パッケージを採用する場合は、using ステートメントの名前空間と参照する一部の型を更新する必要がある場合があります。 これらの名前空間の変更が using ステートメントに及ぼす影響については、この記事で後ほど紹介する HTTP トリガー テンプレートの例で確認できます。

まだ更新していない場合、次に示すものの最新の安定バージョンを参照するようにプロジェクトを更新します。

アプリが使用するトリガーとバインドによっては、アプリは別のパッケージ セットを参照する必要がある場合があります。 次の表に、最も一般的に使用されるいくつかの拡張機能の置換を示します。

シナリオ パッケージ参照の変更
タイマー トリガー 追加
Microsoft.Azure.Functions.Worker.Extensions.Timer
Storage のバインド Replace
Microsoft.Azure.WebJobs.Extensions.Storage
with
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Microsoft.Azure.Functions.Worker.Extensions.Tables
BLOB のバインド 次の
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
キューのバインド 次の
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
テーブルのバインド 次の
Microsoft.Azure.WebJobs.Extensions.Tables
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Tables
Cosmos DB のバインド 次の
Microsoft.Azure.WebJobs.Extensions.CosmosDB
および/または
Microsoft.Azure.WebJobs.Extensions.DocumentDB
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Service Bus のバインド 次の
Microsoft.Azure.WebJobs.Extensions.ServiceBus
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs のバインド 次の
Microsoft.Azure.WebJobs.Extensions.EventHubs
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Event Grid のバインド 次の
Microsoft.Azure.WebJobs.Extensions.EventGrid
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
SignalR Service のバインド 次の
Microsoft.Azure.WebJobs.Extensions.SignalRService
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions 次の
Microsoft.Azure.WebJobs.Extensions.DurableTask
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Durable Functions
(SQL ストレージ プロバイダー)
次の
Microsoft.DurableTask.SqlServer.AzureFunctions
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Durable Functions
(Netherite ストレージ プロバイダー)
次の
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid のバインド 次の
Microsoft.Azure.WebJobs.Extensions.SendGrid
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Kafka のバインド 次の
Microsoft.Azure.WebJobs.Extensions.Kafka
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.Kafka
RabbitMQ のバインド 次の
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
への参照を、次の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
依存関係の挿入
とスタートアップ構成
次への参照を削除します
Microsoft.Azure.Functions.Extensions
(分離ワーカー モデルでは、この機能が既定で提供されます)

検討するべき拡張機能の全一覧については、「サポートされているバインド」を参照し、分離プロセス モデルの完全なインストール手順については、各拡張機能のドキュメントを参照してください。 対象としているすべてのパッケージの最新の安定バージョンをインストールするようにしてください。

ヒント

このプロセス中に拡張機能のバージョンを変更するとき、場合によっては、host.json ファイルの更新も必要になります。 使用する各拡張機能のドキュメントを必ず読んでください。 たとえば、Service Bus 拡張機能では、バージョン 4.x と 5.x の間で構造に破壊的変更があります。 詳しくは、「Azure Functions の Azure Service Bus バインド」をご覧ください。

分離ワーカー モデル アプリケーションでは Microsoft.Azure.WebJobs.* 名前空間や Microsoft.Azure.Functions.Extensions 内のどのパッケージも参照するべきではありません。 これらへの参照が何か残っている場合は、それらを削除する必要があります。

ヒント

アプリは、トリガーとバインドの一部として、またはスタンドアロンの依存関係として、Azure SDK の種類にも依存している場合があります。 この機会を利用して、これらも同様に更新する必要があります。 Functions 拡張機能の最新バージョンは、Azure SDK for .NET (ほとんどすべてのパッケージの形式は Azure.* です) の最新バージョンで動作します。

Notification HubsMobile Apps のバインディングは、ランタイムのバージョン 1.x でのみサポートされています。 ランタイムのバージョン 4.x にアップグレードする場合は、SDK を使ってこれらのサービスを直接操作するために、これらのバインディングを削除する必要があります。

Program.cs ファイル

ほとんどの場合、移行するには、次の program.cs ファイルをプロジェクトに追加する必要があります。

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services => {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

この例には、パフォーマンスを向上させ、アプリで HTTP トリガーを使用するときに使い慣れたプログラミング モデルを提供するための ASP.NET Core 統合が含まれています。 HTTP トリガーを使用しない場合は、ConfigureFunctionsWebApplication の呼び出しを ConfigureFunctionsWorkerDefaults の呼び出しに置き換えることができます。 それによって、プロジェクト ファイルから Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore への参照を削除できます。 ただし、最適なパフォーマンスを得るためには、他のトリガー タイプを持つ関数の場合でも、ASP.NET Core への FrameworkReference を保持するべきです。

Program.cs ファイルで置換されるファイルに FunctionsStartup 属性がある場合は、通常は Startup.cs ファイルです。 FunctionsStartup コードが IFunctionsHostBuilder.Services を参照する場所で、代わりに HostBuilder.ConfigureServices() メソッド内のステートメントを Program.cs に追加できます。 Program.cs の操作については、分離ワーカー モデル ガイドの「スタートアップと構成」をご覧ください。

上記の既定の Program.cs の例には、分離ワーカー モデル用の Application Insights 統合のセットアップが含まれます。 実際の Program.cs の中で、プロジェクト内のコードから受け取るログに適用する必要があるログのフィルター処理も構成する必要があります。 分離ワーカー モデルにおいて、host.json ファイルが制御するのは、Functions ホスト ランタイムによって生成されたイベントだけです。 Program.cs でフィルター規則を構成しない場合、テレメトリのさまざまなカテゴリに対して異なるログ レベルが表示される場合があります。

HostBuilder の一部としてカスタム構成ソースを登録することはできますが、これらが適用されるのも同様にプロジェクト内のコードに対してだけであることに注意してください。 トリガーとバインドの構成はプラットフォームでも必要であり、これは、アプリケーション設定Key Vault 参照、または App Configuration 参照機能を通して提供する必要があります。

既存の FunctionsStartup から Program.cs ファイルへすべてを移動すると、FunctionsStartup 属性と、それが適用されていたクラスを削除できます。

host.json ファイル

host.json ファイルの設定は、ローカルと Azure のいずれでも、関数アプリ レベルで適用されます。 バージョン 1.x では、host.json ファイルは空であるか、関数アプリ内のすべての関数に適用されるいくつかの設定が含まれています。 詳細については、「Host.json v1」を参照してください。 host.json ファイルに設定値がある場合は、変更点がないか、host.json v2 の形式を確認します。

バージョン 4.x 上で実行するには、host.json ファイルに "version": "2.0" を追加する必要があります。 また、次の例のように、構成に logging を追加することを検討してください。

{
    "version": "2.0",
    "logging": {
        "applicationInsights": {
            "samplingSettings": {
                "isEnabled": true,
                "excludedTypes": "Request"
            },
            "enableLiveMetricsFilters": true
        }
    }
}

host.json ファイルが制御するのは、Functions ホスト ランタイムからのログだけであり、分離ワーカー モデルでは、これらのログの一部はアプリケーションから直接取得されるため、より詳細な制御が可能になります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。

local.settings.json ファイル

local.settings.json ファイルは、ローカルで実行している場合にのみ使用されます。 詳細については、「ローカル設定ファイル」を参照してください。 バージョン 1.x では、local.settings.json ファイルの必須の値は次の 2 つのみです。

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
    }
}

バージョン 4.x に移行するときは、local.settings.json ファイルに少なくとも次の要素が含まれていることを確認します。

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Note

インプロセスの実行から分離ワーカー プロセスでの実行に移行する場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet-isolated" に変更する必要があります。

クラス名の変更

一部のキー クラスは、バージョン 1.x からバージョン 4.x で名前が変更されました。 これらの変更は、.NET API の変更、またはインプロセスと分離 worker プロセスの違いのいずれかの結果によるものです。 次の表は、移行するときに変更される可能性がある、Functions によって使用されている主要な .NET クラスを示しています。

バージョン 1.x .NET 8
FunctionName (属性) Function (属性)
TraceWriter ILogger<T>ILogger
HttpRequestMessage HttpRequestDataHttpRequest (ASP.NET Core 統合を使用)
HttpResponseMessage HttpResponseDataIActionResult (ASP.NET Core 統合の使用)

バインドにクラス名の違いがある場合もあります。 詳細については、特定のバインドの参照記事を参照してください。

その他のコード変更

このセクションでは、移行を行う際に考慮する必要があるその他のコード変更について説明します。 これらの変更はすべてのアプリケーションで必要なわけではありませんが、シナリオに関連があるかどうかを評価する必要があります。 バージョン 1.x 以降の動作変更で、プロジェクトに加える必要があるその他の変更がないかをご確認ください。

JSON シリアル化

既定では、分離ワーカー モデルは JSON シリアル化に System.Text.Json を使用します。 シリアライザー オプションをカスタマイズしたり、JSON.NET (Newtonsoft.Json) に切り替えたりするには、こちらの手順を参照してください。

Application Insights のログ レベルとフィルター処理

ログは、Functions ホスト ランタイムとプロジェクト内のコードの両方から Application Insights に送信できます。 host.json では、ホスト ログの規則を構成できますが、コードからのログを制御するには、Program.cs の一部としてフィルター規則を構成する必要があります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。

HTTP トリガー テンプレート

バージョン 1.x とバージョン 4.x の間のコード変更のほとんどは、HTTP トリガー関数に見られます。 バージョン 1.x の HTTP トリガー テンプレートは、次の例のようになります。

using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static async Task<HttpResponseMessage> 
            Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", 
            Route = null)]HttpRequestMessage req, TraceWriter log)
        {
            log.Info("C# HTTP trigger function processed a request.");

            // parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            if (name == null)
            {
                // Get request body
                dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;
            }

            return name == null
                ? req.CreateResponse(HttpStatusCode.BadRequest, 
                    "Please pass a name on the query string or in the request body")
                : req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
        }
    }
}

バージョン 4.x の HTTP トリガー テンプレートは、次の例のようになります。

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

        public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
        {
            _logger = logger;
        }

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

プロジェクトを Azure Functions 4.x に更新するには、次の手順に従います。

  1. Azure Functions Core Tools のローカル インストールをバージョン 4.x に更新します。

  2. バージョン 4.x でサポートされている Node.js バージョンのいずれかに移動します。

  3. host.json に versionextensionBundle の両方の要素を追加し、次の例のようにします。

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

    バージョン 1.x の後では、バインディングは外部パッケージとして維持されるため、extensionBundle 要素は必須です。 詳細については、拡張機能のバンドルに関する記事を参照してください。

  4. local.settings.json ファイルを更新して、少なくとも次の要素が含まれるようにします。

    {
        "IsEncrypted": false,
        "Values": {
            "AzureWebJobsStorage": "UseDevelopmentStorage=true",
            "FUNCTIONS_WORKER_RUNTIME": "node"
        }
    }
    

    AzureWebJobsStorage 設定は、Azurite ストレージ エミュレーターまたは実際の Azure Storage アカウントのいずれかにすることができます。 詳細については、ローカル ストレージ エミュレーターに関するページを参照してください。

Azure で関数アプリを更新する

移行したプロジェクトを発行する前に、Azure の関数アプリ ホストのランタイムをバージョン 4.x に更新する必要があります。 Functions ホストで使用されるランタイム バージョンは FUNCTIONS_EXTENSION_VERSION アプリケーション設定によって制御されますが、場合によっては他の設定も更新する必要があります。 コードの変更もアプリケーション設定の変更も、関数アプリを再起動する必要があります。

最も簡単な方法は、スロットなしで更新してから、アプリ プロジェクトを再発行することです。 また、スロットを使用して更新することで、アプリのダウンタイムを最小限に抑え、ロールバックを簡略化することもできます。

スロットなしで更新する

v4.x に更新する最も簡単な方法は、Azure の関数アプリで FUNCTIONS_EXTENSION_VERSION アプリケーション設定を ~4 に設定することです。 スロットがあるサイトでは、別の手順に従う必要があります。

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

別の設定も必要ですが、これは Windows と Linux とで異なります。

Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。

az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。

この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。

これで、バージョン 4.x で実行するように移行されたアプリ プロジェクトを再発行できるようになりました。

スロットを使って更新する

デプロイ スロットの使用は、関数アプリを以前のバージョンから v4.x ランタイムに更新するのに適しています。 ステージング スロットを使用すると、ステージング スロットの新しいランタイム バージョンでアプリを実行し、検証後に運用環境に切り替えることができます。 スロットは、更新中のダウンタイムを最小限に抑える方法も提供します。 ダウンタイムを最小限に抑える必要がある場合は、「最小ダウンタイムの更新」の手順に従ってください。

更新されたスロットでアプリを確認したら、アプリと新しいバージョンの設定を運用環境に入れ替えられます。 この入れ替えには、運用スロットでの WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 の設定が必要です。 この設定をどのように追加するかで、更新に必要なダウンタイムの量に影響します。

標準的な更新

スロット対応関数アプリが完全再起動のダウンタイムを処理できる場合は、運用スロットで WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を直接更新できます。 運用スロットでこの設定を直接変更すると、可用性に影響する再起動が発生するため、トラフィックが減少した時点でこの変更を行うことを検討してください。 その後、ステージング スロットから更新されたバージョンに入れ替えできます。

現在、Update-AzFunctionAppSetting PowerShell コマンドレットはスロットをサポートしていません。 Azure CLI または Azure portal を使用する必要があります。

  1. 運用スロットに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を設定するには、次のコマンドを使用します。

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> 
    

    この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。 このコマンドを実行すると、運用スロットで実行されているアプリが再起動します。

  2. ステージング スロットにも WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS を設定するには、次のコマンドを使用します。

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  3. 次のコマンドを使用して、FUNCTIONS_EXTENSION_VERSION を変更し、ステージング スロットを新しいランタイム バージョンに更新します。

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  4. Windows では、Functions ランタイムのバージョン 4.x には .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 .NET 6 でランタイムを実行できるように、次のコマンドを使用します。

    Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
    

    .NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。

    この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。

  5. コード プロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージング スロットにデプロイします。

  6. 入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。

  7. 更新されたステージング スロットを運用環境と入れ替えるには、次のコマンドを使用します。

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    

最小ダウンタイムの更新

運用アプリのダウンタイムを最小限に抑えるには、ステージング スロットから運用環境に WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を入れ替えます。 その後、事前に警告されたステージング スロットから更新されたバージョンに入れ替えできます。

  1. ステージング スロットに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を設定するには、次のコマンドを使用します。

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  2. 次のコマンドを使用して、スロットと新しい設定を運用環境で入れ替え、同時にステージング スロットのバージョン設定を復元します。

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    

    入れ替えとステージング時のランタイム バージョンの復元の間に、ステージング スロットからエラーが表示される場合があります。 このエラーは、入れ替え中にステージングに WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 のみしかないと、ステージングの FUNCTIONS_EXTENSION_VERSION 設定が削除されるために発生する可能性があります。 バージョン設定がないと、スロットの状態が正しくありません。 入れ替えの直後にステージング スロットのバージョンを更新すると、スロットが適切な状態に戻り、必要に応じて変更をロールバックします。 ただし、入れ替えのロールバックでは、ステージングで見られる運用環境で同じエラーが発生しないように、入れ替えを元に戻す前に運用環境から WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を直接削除する必要もあります。 この運用環境設定の変更により、再起動が発生します。

  3. ステージング スロットにもう一度 WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 を設定するには、次のコマンドを使用します。

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    

    この時点で、両方のスロットで WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 が設定されています。

  4. 次のコマンドを使用して、FUNCTIONS_EXTENSION_VERSION を変更し、ステージング スロットを新しいランタイム バージョンに更新します。

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  5. Windows では、Functions ランタイムのバージョン 4.x には .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 .NET 6 でランタイムを実行できるように、次のコマンドを使用します。

    Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。

    az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
    

    .NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。

    この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。

  6. コード プロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージング スロットにデプロイします。

  7. 入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。

  8. 更新され、事前警告されたステージング スロットを運用環境と入れ替えるには、次のコマンドを使用します。

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    

バージョン 1.x の後に加えられた動作の変更

このセクションでは、トリガーとバインディングの両方の動作とコア Functions の機能と動作の点で、バージョン 1.x の後に加えられた変更について詳しく説明します。

トリガーとバインドでの変更

バージョン 2.x 以降では、アプリの関数で使用される特定のトリガーとバインドの拡張機能をインストールする必要があります。 この例外は、拡張機能を必要としない HTTP トリガーとタイマー トリガーのみです。 詳細については、バインド拡張機能の登録とインストールに関するページを参照してください。

バージョン間には、関数の function.json や属性の変更もいくつかあります。 たとえば、Event Hubs の path のプロパティは eventHubName になりました。 各バインドのドキュメントへのリンクについては、既存のバインド一覧を参照してください。

機能の変更

バージョン 1.x 後、いくつかの機能が削除、更新、置換されました。 このセクションでは、バージョン 1.x の後に後続のバージョンを使用した場合に気づく変更点について詳しく説明します。

バージョン 2.x では次の点が変更されました。

  • HTTP エンドポイントを呼び出すキーは、Azure Blob Storage 内で常に暗号化されて格納されます。 バージョン 1.x では、既定で Azure Files にキーが格納されていました。 アプリをバージョン 1.x からバージョン 2.x に移行すると、Azure Files 内の既存のシークレットはリセットされます。

  • バージョン 2.x ランタイムには、Webhook プロバイダーの組み込みサポートは含まれていません。 この変更はパフォーマンスを向上するために行われました。 Webhook のエンドポイントとして HTTP トリガーを使用することもできます。

  • 監視を改善するために、AzureWebJobsDashboard 設定を使用したポータルの WebJobs ダッシュボードは、APPINSIGHTS_INSTRUMENTATIONKEY 設定を使用する Azure Application Insights に置き換えられています。 詳しくは、「Azure Functions を監視する」をご覧ください。

  • 関数アプリ内のすべての関数は、同じ言語を共有する必要があります。 関数アプリを作成するときに、そのアプリのランタイム スタックを選択する必要があります。 ランタイム スタックは、アプリケーション設定の FUNCTIONS_WORKER_RUNTIME 値によって指定されます。 メモリ占有領域と起動時間を改善するために、この要件が追加されました。 ローカルで開発する場合は、この設定も local.settings.json ファイル に含める必要があります。

  • App Service プランでの関数に対する既定のタイムアウトは 30 分に変更されます。 host.json の functionTimeout 設定を使用して、手動でタイムアウトを無制限に変更することができます。

  • 従量課金プラン機能の場合、HTTP 同時実行のスロットルは既定で実装され、インスタンスあたりの既定の同時要求数は 100 です。 この動作は host.json ファイルの maxConcurrentRequests 設定で変更できます。

  • .NET Core の制限があるため、F# スクリプト (.fsx ファイル) 関数のサポートが削除されました。 コンパイル済みの F# 関数 (.fs) は引き続きサポートされます。

  • Event Grid トリガー Webhook の URL 形式は、次のパターンに従うように変更されました: https://{app}/runtime/webhooks/{triggerName}

  • 一部の事前定義済みカスタム メトリックの名前はバージョン 1.x の後に変更されました。 DurationMaxDurationMsMinDurationMsAvgDurationMs に置き換えられました。 Success Rate の名前も Success Rate に変更されました。

Azure Stack Hub に関する考慮事項

Azure Stack Hub 上のApp Serviceでは、バージョン 4.x の Azure Functions はサポートされていません。 Azure Stack Hub でバージョン 1.x からの移行を計画している場合は、次のいずれかのオプションを選択できます:

  • この記事の手順に従って、パブリック クラウド Azure Functions でホストされているバージョン 4.x に移行します。 既存のアプリをアップグレードする代わりに、バージョン 4.x を使用して新しいアプリを作成し、変更したプロジェクトをそれにデプロイします。
  • Azure Stack Hub の App Service プランでホストされている WebJobsに切り替えます。

次のステップ