.NET Azure Functions isolated worker model 更新ポイント｜移行期限・設定変更・管理者の確認事項

.NET の Azure Functions を使っている開発者・管理者がまず確認すべき結論は、C# Azure Functions は今後、分離ワーカーモデルを前提に設計・移行計画を進めるべきという点です。2026年7月3日の公式ドキュメント更新履歴では大きな機能追加ではなく、主にパフォーマンス最適化に関する記述の整理が行われています。ただし、背景にある重要事項は変わっていません。in-process モデルのサポートは 2026年11月10日に終了予定であり、継続してサポートを受けるには isolated worker model への移行が必要です。(GitHub)

この記事では、Microsoft Learn の「Guide for running C# Azure Functions in the isolated worker model」をもとに、.NET の Azure Functions を運用する管理者・開発者が確認すべき更新ポイント、影響範囲、設定変更、移行期限、実務上のチェック項目を整理します。特に、.NET 8 / .NET 9 / .NET 10、Linux Consumption、Flex Consumption、Application Insights、CI/CD、FUNCTIONS_WORKER_RUNTIME の設定を扱っている環境では、単なるドキュメント更新として流さず、棚卸しと移行計画に落とし込むことが重要です。

.NET の Azure Functions isolated worker model とは

Azure Functions の .NET 実行モデルには、大きく分けて in-process モデルとisolated worker modelがあります。

in-process モデルでは、関数コードが Azure Functions ホストと同じプロセス内で実行されます。一方、isolated worker model では、関数コードがホストとは別の .NET ワーカープロセスで実行されます。Microsoft Learn では、isolated worker model の利点として、アセンブリ競合の低減、起動処理の制御、標準的な依存関係注入、.NET バージョン選択の柔軟性が挙げられています。(Microsoft Learn)

実務では、次のように理解すると分かりやすいです。

観点	in-process モデル	isolated worker model
実行場所	Functions ホストと同一プロセス	Functions ホストとは別の .NET ワーカープロセス
.NET バージョン選択	LTS 中心で制約が強い	LTS、STS、.NET Framework などに対応
依存関係の衝突	ホスト側ライブラリとの競合リスクがある	アプリ側プロセスが分離され、競合を抑えやすい
ミドルウェア	基本的に非対応	対応
DI・起動処理	Functions 固有の作法が多い	通常の .NET アプリに近い構成
今後の推奨度	移行対象	新規開発・移行先の中心

重要なのは、isolated worker model が単なる「別の書き方」ではないことです。Program.cs を持つコンソールアプリに近い構成になり、依存関係注入、構成、ログ、ミドルウェア、Azure SDK クライアント登録などを、より標準的な .NET の作法で扱えるようになります。

2026年7月3日の更新ポイントは「機能追加」よりも確認事項の明確化

2026年7月3日の GitHub 履歴では、対象ドキュメントに「Apply LAA suggestions from code review」というコミットが入り、dotnet-isolated-process-guide.md では 3行追加・3行削除の差分が確認できます。変更内容は、プレースホルダー最適化の説明文と ReadyToRun の説明文の表現調整が中心であり、新しい設定項目が追加されたわけではありません。(GitHub)

ただし、更新箇所がパフォーマンス最適化セクションに関係しているため、管理者は次の点を再確認する価値があります。

確認対象	確認すべき理由	実務で見る場所
プレースホルダー設定	.NET 8 以降のコールドスタート改善に関係する	アプリ設定、`WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED`
.NET バージョン設定	アプリのターゲットフレームワークと Azure 側設定の不一致を避ける	`netFrameworkVersion`、`linuxFxVersion`
64ビット設定	一部の最適化では 64ビット構成が前提になる	Azure Functions の構成、CLI
ReadyToRun	Consumption plan での起動性能改善に関係する	`.csproj`、発行プロファイル、CI/CD
依存パッケージ	最適化や新しい実行モデルで必要な最小バージョンがある	`.csproj`、NuGet、Dependabot

つまり、7月3日の更新は「新機能が追加されたので即時対応」というより、isolated worker model へ移行済み、または移行予定の環境で、パフォーマンス関連設定が正しくそろっているか確認するきっかけと捉えるのが現実的です。

影響範囲：どの .NET Azure Functions が確認対象になるか

今回の内容で特に影響を受けるのは、次のような環境です。

対象	影響度	確認ポイント
C# Azure Functions を in-process で運用中	高	2026年11月10日までの移行計画が必要
.NET 8 の Azure Functions を運用中	高	in-process か isolated かを確認
.NET 9 / .NET 10 を使いたい環境	高	isolated worker model が前提
Linux Consumption plan を利用中	高	.NET 10 では制約があり、Flex Consumption の検討が必要
HTTP トリガー中心の Functions	中〜高	ASP.NET Core integration の利用可否を確認
Application Insights を使っている環境	中	ログ設定が `host.json` だけで完結しない点を確認
CI/CD で Azure Functions を自動デプロイしている環境	中〜高	ランタイム設定、アプリ設定、発行成果物の整合性を確認

特に注意したいのは、Azure Portal 上で「動いているように見える」環境でも、アプリの実行モデル、ターゲットフレームワーク、Azure 側のスタック設定、CI/CD の発行設定がずれているケースです。isolated worker model への移行では、コードだけでなく Azure 側の構成変更も同時に必要になります。

サポート期限：in-process モデルは 2026年11月10日終了予定

Microsoft Learn では、.NET Azure Functions の in-process モデルのサポートは 2026年11月10日に終了すると案内されています。継続してフルサポートを受けるには、isolated worker model への移行が推奨されています。(Microsoft Learn)

また、Azure Functions ランタイム 1.x のサポートは 2026年9月14日に終了予定です。Functions 2.x と 3.x はすでにサポート対象外であり、現在の推奨ランタイムは 4.x です。(Microsoft Learn)

項目	期限・状態	対応方針
Azure Functions in-process モデル	2026年11月10日サポート終了予定	isolated worker model へ移行
Azure Functions ランタイム 1.x	2026年9月14日サポート終了予定	Functions 4.x へ移行
Azure Functions ランタイム 2.x / 3.x	サポート終了済み	速やかに 4.x へ移行
Linux Consumption plan	2028年9月30日廃止予定	Flex Consumption plan への移行を検討
.NET 6 / .NET 7	公式サポート終了済み	.NET 8 以降へ移行

管理者が避けたいのは、2026年秋に「ランタイム移行」「実行モデル移行」「.NET バージョン更新」「ホスティングプラン見直し」を同時に抱えることです。とくに基幹系や外部連携の多い Functions では、2026年11月を期限と見なすのではなく、検証・ステージング・本番切り替えを含めた社内期限を前倒しで設定するべきです。

サポートされる .NET バージョンの見方

Azure Functions 4.x の isolated worker model では、.NET 10、.NET 9、.NET 8、.NET Framework 4.8 系が対象として示されています。一方、in-process モデルは .NET 8 までであり、より新しい .NET バージョンを使うには isolated worker model への移行が必要です。(Microsoft Learn)

.NET バージョン	isolated worker model	in-process モデル	実務上の判断
.NET 10	対応	非対応	新規開発・長期運用候補。ただし Linux Consumption では制約あり
.NET 9	対応	非対応	STS 前提。採用時はサポート期限を確認
.NET 8	対応	対応	既存移行の現実的な第一候補
.NET Framework 4.8 系	対応	Functions 1.x などで利用	レガシー資産の延命策として検討
.NET 6 / .NET 7	サポート終了済み	サポート終了済み	移行対象

新規開発なら、原則として Azure Functions 4.x + isolated worker model を前提にします。既存の in-process アプリでは、まず .NET 8 isolated への移行を検討し、その後 .NET 10 などへの更新余地を確保する進め方が安全です。

.NET 10 と Linux Consumption plan の注意点

公式ガイドでは、.NET 10 アプリは Linux の Consumption plan では実行できず、Linux で実行する場合は Flex Consumption plan の利用が案内されています。(Microsoft Learn)

これは、グローバル展開している環境では特に重要です。たとえば、リージョンごとに Functions のホスティングプランが異なる、IaC テンプレートで Windows と Linux が混在している、古い Consumption plan をそのまま使っている、といったケースでは、.NET バージョンだけを更新してもデプロイや起動に失敗する可能性があります。

確認すべき観点は次のとおりです。

確認項目	具体的な確認内容
OS	Windows か Linux か
ホスティングプラン	Consumption、Flex Consumption、Premium、Dedicated など
ターゲット .NET	`net8.0`、`net9.0`、`net10.0` など
Azure 側スタック設定	Windows は `netFrameworkVersion`、Linux は `linuxFxVersion`
IaC	Bicep / ARM / Terraform 側の値が最新化されているか

特に、グローバル企業では「開発環境は Windows、検証環境は Linux、本番の一部リージョンだけ Consumption plan」という構成も珍しくありません。移行時はアプリ単位ではなく、サブスクリプション、リソースグループ、リージョン、ホスティングプラン単位で棚卸しすることが大切です。

パッケージ参照の更新ポイント

isolated worker model では、in-process モデルとは使用する NuGet パッケージが異なります。基本となるパッケージは Microsoft.Azure.Functions.Worker と Microsoft.Azure.Functions.Worker.Sdk です。ターゲット .NET バージョンごとに必要な最小バージョンも示されています。(Microsoft Learn)

ターゲット	`Microsoft.Azure.Functions.Worker`	`Microsoft.Azure.Functions.Worker.Sdk`
.NET 10	2.50.0 以降	2.0.5 以降
.NET 9	2.0.0 以降	2.0.0 以降
.NET 8	1.16.0 以降	1.11.0 以降
.NET Framework	1.16.0 以降	1.11.0 以降

ただし、実務では「最小バージョンを満たしているか」だけでは不十分です。公式ガイドでは、パフォーマンス最適化の文脈で、少なくとも Microsoft.Azure.Functions.Worker 1.19.0 以降、Microsoft.Azure.Functions.Worker.Sdk 1.16.4 以降、そして .NET Framework を除き Microsoft.AspNetCore.App の FrameworkReference を追加する構成が示されています。(Microsoft Learn)

移行時にやりがちな失敗は、Microsoft.NET.Sdk.Functions や Microsoft.Azure.WebJobs.* 系のパッケージが残ることです。isolated worker model では、Microsoft.Azure.Functions.Worker.Extensions.* 系の拡張パッケージへ置き換える必要があります。(Microsoft Learn)

確認すべき `.csproj` の例

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <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" />
  </ItemGroup>
</Project>

上記はあくまで .NET 8 移行例の考え方です。実際には、利用しているトリガーやバインディングに応じて、Storage、Service Bus、Event Hubs、Cosmos DB、Durable Functions などの拡張パッケージを個別に見直します。

`Program.cs` が移行の中心になる

isolated worker model では、Program.cs がアプリの起点になります。in-process モデルで Startup.cs や FunctionsStartup に書いていた依存関係注入や初期化処理は、Program.cs に移します。Microsoft の移行ガイドでも、isolated worker process へ移行する際は Program.cs の追加が必要とされています。(Microsoft Learn)

HTTP トリガーを使う場合は、ASP.NET Core integration を利用する構成が推奨される場面があります。

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 integration を使わない構成では、ConfigureFunctionsWorkerDefaults() を使うケースもあります。ただし、既存コードを機械的に置き換えるのではなく、HTTP トリガーの有無、ASP.NET Core の型を使うか、Application Insights の構成をどうするかを確認してから決めるべきです。

`FUNCTIONS_WORKER_RUNTIME` は `dotnet-isolated` に変更する

移行で必ず確認すべきアプリ設定が FUNCTIONS_WORKER_RUNTIME です。in-process では通常 dotnet を使いますが、isolated worker model では dotnet-isolated に変更します。ローカル環境の local.settings.json でも同じ考え方です。(Microsoft Learn)

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
  }
}

Azure 上でも、ステージングスロットや本番スロットのアプリ設定を確認します。特に CI/CD や IaC で設定を上書きしている場合、ポータル上で手動変更しても次回デプロイで元に戻ることがあります。

実務では次の順序で確認すると安全です。

| 順番 | 確認対象 | 見るべき内容 |
| -: | ———– | ————————————————– |
| 1 | ローカル設定 | local.settings.json の FUNCTIONS_WORKER_RUNTIME |
| 2 | Azure アプリ設定 | dotnet-isolated になっているか |
| 3 | スロット設定 | ステージングと本番で差異がないか |
| 4 | IaC | Bicep / ARM / Terraform の設定値 |
| 5 | CI/CD | デプロイ時にアプリ設定を上書きしていないか |

Azure 側のランタイム設定はコードと同時に変更する

isolated worker model への移行では、コードだけを先にデプロイしたり、Azure 側の設定だけを先に変えたりすると、アプリがエラー状態になる可能性があります。Microsoft の移行ガイドでは、デプロイ済みペイロードと構成済みランタイムが一致しない場合にエラー状態になるため、ステージングスロットを使って更新することが推奨されています。(Microsoft Learn)

本番環境では、次の流れが現実的です。

| 手順 | 作業 | 目的 |
| -: | —————————————– | —————————————– |
| 1 | 対象 Function App を棚卸し | in-process、Functions v1/v3、.NET 6/7 を洗い出す |
| 2 | ローカルプロジェクトを isolated worker model へ移行 | .csproj、Program.cs、属性、パッケージを変更 |
| 3 | ローカルで Azure Functions Core Tools により動作確認 | 起動、トリガー、ログ、例外処理を確認 |
| 4 | ステージングスロットを作成 | 本番影響を避ける |
| 5 | ステージング側で dotnet-isolated と .NET スタックを設定 | Azure 側のランタイムをコードに合わせる |
| 6 | ステージングへデプロイ | 実環境に近い条件で検証 |
| 7 | ログとメトリックを確認 | Application Insights、失敗率、コールドスタートを確認 |
| 8 | スロットスワップ | 本番へ反映 |
| 9 | 本番で再確認 | エラー率、応答時間、トリガー実行状況を確認 |

「設定変更とコード変更を同時に扱う」ことが移行の肝です。とくに複数スロットを使っている環境では、FUNCTIONS_WORKER_RUNTIME をスロット設定にするかどうかも含めて慎重に確認してください。Microsoft の移行手順では、FUNCTIONS_WORKER_RUNTIME はスロット設定としてマークしないよう案内されています。(Microsoft Learn)

HTTP トリガーは ASP.NET Core integration を検討する

HTTP トリガーでは、isolated worker model で次の2つのアプローチを選べます。

方式	主な型	向いているケース
ASP.NET Core integration	`HttpRequest`、`IActionResult`	ASP.NET Core に慣れた開発チーム、HTTP API 中心の Functions
built-in HTTP model	`HttpRequestData`、`HttpResponseData`	既存の isolated worker アプリとの互換性を重視する場合

公式ガイドでは、ASP.NET Core integration は ASP.NET Core 開発者になじみのある型を使える一方で、ASP.NET Core の全機能を提供するわけではないと説明されています。また、.NET Framework を対象とするアプリでは ASP.NET Core integration は利用できません。(Microsoft Learn)

移行時には、単に HttpRequestData に置き換えるのではなく、今後の保守性を考えて HttpRequest / IActionResult に寄せるかどうかを判断します。

判断基準

判断ポイント	ASP.NET Core integration が向く	built-in HTTP model が向く
チームの経験	ASP.NET Core MVC / Minimal API 経験が多い	Functions 独自モデルに慣れている
既存コード	`IActionResult` を多用している	`HttpRequestData` ベースで既に実装済み
シリアライズ	ASP.NET Core 側の JSON 設定を使いたい	worker の一般的な JSON 設定で十分
.NET Framework	不向き	選択肢になる
長期保守	Web API に近い書き方にしたい	小規模・単純な HTTP 関数

なお、HttpRequestData を使う場合、特定の HTTP リクエストボディの扱いで制約があるため、ストリーミングを扱うような API では ASP.NET Core integration を検討した方が安全です。(Microsoft Learn)

ログ設定は `host.json` だけでは不十分になる

isolated worker model でよくある落とし穴がログ設定です。Functions ホストと isolated process worker はログレベルの構成が分かれており、host.json の設定は worker 側のアプリコードから出るログには直接効きません。worker 側のログレベルは、コードまたは appsettings.json などで設定します。(Microsoft Learn)

たとえば、移行前に host.json で Application Insights のログレベルを制御していた環境では、移行後に「ログが増えた」「特定カテゴリのログが出ない」「Application Insights の課金が増えた」といった変化が起きる可能性があります。

確認すべきポイントは次の3つです。

確認項目	内容
ホスト側ログ	`host.json` で Functions host のログを制御
アプリ側ログ	`Program.cs` または `appsettings.json` で worker 側ログを制御
Application Insights	host と worker の両方から送られるログのカテゴリ・レベルを確認

新規プロジェクトでは FunctionsApplication.CreateBuilder() の利用が推奨される流れになっており、appsettings.json の読み込みや worker 構成が扱いやすくなります。既存の new HostBuilder() 構成を使っている場合は、必要に応じて ConfigureAppConfiguration() で appsettings.json を読み込む設計にします。(Microsoft Learn)

パフォーマンス最適化：Placeholders と ReadyToRun を確認する

今回の更新履歴で直接触れられているのが、パフォーマンス最適化セクションです。公式ガイドでは、コールドスタート改善に関する選択肢として、プレースホルダー、最適化済み executor、ReadyToRun が説明されています。(Microsoft Learn)

Placeholders

.NET 8 以降を対象とするアプリでは、プレースホルダーによってコールドスタート改善が期待できます。利用するには、依存関係を更新したうえで、WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1 を設定し、Azure 側の .NET バージョン設定や 64ビット設定も正しく合わせる必要があります。(Microsoft Learn)

az functionapp config appsettings set \
  -g <groupName> \
  -n <appName> \
  --settings WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1

注意点は、設定を1つ入れれば完了ではないことです。netFrameworkVersion、ターゲットフレームワーク、64ビット設定などが不一致だと、アプリが起動に失敗する可能性があります。

ReadyToRun

ReadyToRun は、アプリを ahead-of-time コンパイルに近い形で発行し、Consumption plan でのコールドスタート影響を抑えるための選択肢です。公式ガイドでは、.NET 8 以降かつ Azure Functions runtime 4.0 以降で利用できると説明されています。(Microsoft Learn)

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

ReadyToRun で重要なのは、ホスティング環境のアーキテクチャと RuntimeIdentifier を一致させることです。Windows 64ビットなら win-x64、Linux 64ビットなら linux-x64 を選ぶといった確認が必要です。アーキテクチャが合わないと、起動時エラーにつながります。

移行時に変更が必要になりやすいコード

isolated worker model への移行では、次のようなコード変更が発生します。

変更箇所	in-process	isolated worker model
関数属性	`[FunctionName("...")]`	`[Function("...")]`
using	`Microsoft.Azure.WebJobs`	`Microsoft.Azure.Functions.Worker`
ログ	メソッド引数の `ILogger`	DI で `ILogger<T>` を注入
出力バインド	`out`、`IAsyncCollector` など	戻り値、複数出力用クラス、SDK クライアント
起動処理	`Startup.cs`、`FunctionsStartup`	`Program.cs`
ランタイム設定	`dotnet`	`dotnet-isolated`

たとえば、Blob 出力バインドでは、in-process の [Blob(...)] が isolated worker model では [BlobOutput(...)] になるなど、属性名や引数が変わる場合があります。Microsoft の移行ガイドでは、出力バインドを関数パラメーターリストから移動することや、必要に応じて Azure SDK クライアントを直接使うことも案内されています。(Microsoft Learn)

実務では、まずビルドエラーを出しながら機械的に置換し、その後にトリガーごとの動作確認を行う進め方が効率的です。ただし、Queue、Blob、Service Bus、Event Hubs、Cosmos DB、Durable Functions は拡張パッケージやバインディングの変更影響が大きいため、単体テストだけでなく実際の Azure リソースを使った検証も必要です。

管理者が最初にやるべき棚卸し

移行を始める前に、管理者は対象アプリを棚卸しします。Azure PowerShell や Azure CLI、Azure Resource Graph、タグ情報、CI/CD の一覧を使い、少なくとも次の情報を整理します。

棚卸し項目	例
Function App 名	`func-order-prod`、`func-billing-api`
リージョン	Japan East、East US、West Europe
OS	Windows / Linux
ホスティングプラン	Consumption / Flex Consumption / Premium / Dedicated
Functions runtime	4.x / 1.x / 旧バージョン
実行モデル	`dotnet` / `dotnet-isolated`
ターゲット .NET	net8.0、net6.0、net48 など
トリガー	HTTP、Timer、Queue、Blob、Service Bus など
CI/CD	GitHub Actions、Azure DevOps、手動発行
監視	Application Insights、Log Analytics
業務重要度	高 / 中 / 低
移行難易度	低 / 中 / 高

優先順位は、次の順で付けると実務的です。

サポート切れ、または期限が近いもの
外部公開 API や基幹連携など停止影響が大きいもの
Linux Consumption など将来の制約が大きいもの
HTTP トリガーやバインディングが複雑で検証に時間がかかるもの
小規模で移行しやすく、先行事例にできるもの

最初から全アプリを一括移行しようとすると、障害時の切り分けが難しくなります。まずは低リスクな Function App を1つ選び、移行手順、CI/CD、監視、ロールバック手順をテンプレート化してから横展開するのが安全です。

移行チェックリスト

以下は、Azure Functions の .NET isolated worker model 移行で使える実務チェックリストです。

フェーズ	チェック項目	完了条件
事前調査	`FUNCTIONS_WORKER_RUNTIME` を確認	`dotnet` のアプリを移行対象として抽出
事前調査	Functions runtime を確認	4.x 以外は先に runtime 移行を計画
事前調査	.NET バージョンを確認	.NET 6 / 7 などサポート切れを抽出
設計	ターゲット .NET を決定	net8.0、net10.0 などを明確化
設計	ホスティングプランを確認	Linux Consumption 制約を確認
コード変更	`.csproj` を更新	Worker / Worker.Sdk / 拡張パッケージへ変更
コード変更	`Program.cs` を追加	起動処理、DI、Application Insights を移行
コード変更	属性・バインディングを更新	`[Function]`、`BlobOutput` などに変更
設定変更	`local.settings.json` を更新	`dotnet-isolated` に変更
設定変更	Azure アプリ設定を更新	`FUNCTIONS_WORKER_RUNTIME=dotnet-isolated`
設定変更	スタック設定を更新	Windows / Linux に応じた .NET 設定
検証	ローカル実行	主要トリガーが動作
検証	ステージングデプロイ	実 Azure 環境で動作
検証	ログ・メトリック確認	例外、失敗率、遅延、ログ量を確認
本番	スロットスワップ	本番影響を最小化
本番後	監視強化	数日間はエラー率と実行回数を重点監視

失敗しやすいポイント

`FUNCTIONS_WORKER_RUNTIME` だけ変更してしまう

FUNCTIONS_WORKER_RUNTIME を dotnet-isolated に変えても、デプロイされているコードが in-process のままだとエラーになります。逆に、コードだけ isolated にして Azure 側設定が dotnet のままでも失敗します。コード、パッケージ、アプリ設定、スタック設定はセットで変更します。

`Microsoft.Azure.WebJobs.*` が残っている

in-process 時代のパッケージや using Microsoft.Azure.WebJobs; が残っていると、ビルドエラーや実行時エラーの原因になります。拡張パッケージは Microsoft.Azure.Functions.Worker.Extensions.* 系へ見直します。

Application Insights のログ量が変わる

移行後は host 側と worker 側でログ設定が分かれます。host.json だけを見ていると、アプリコード側のログ制御を見落とします。移行後は Application Insights の取り込み量、カテゴリ別ログ、サンプリング設定を確認します。

HTTP トリガーの型を安易に選ぶ

HttpRequestData / HttpResponseData に寄せるのか、ASP.NET Core integration で HttpRequest / IActionResult を使うのかは、保守性に影響します。既存コード、チームスキル、シリアライズ要件、.NET Framework 対応の有無で判断します。

Linux Consumption の将来制約を見落とす

.NET 10 や新しい言語バージョンを使う計画がある場合、Linux Consumption plan の制約を必ず確認します。必要に応じて Flex Consumption plan への移行も同じロードマップに入れます。

新規開発ではどう設計すべきか

これから C# Azure Functions を新規作成する場合は、次の方針が現実的です。

設計項目	推奨方針
実行モデル	isolated worker model
Functions runtime	4.x
.NET バージョン	長期運用なら LTS を優先
HTTP API	ASP.NET Core integration を優先検討
依存関係注入	`Program.cs` に集約
Azure SDK	DI でクライアント登録
ログ	host 側と worker 側を分けて設計
デプロイ	ステージングスロットと CI/CD を前提
パフォーマンス	.NET 8 以降では Placeholders / ReadyToRun を検討

特に、今から in-process モデルで新規開発する理由はほとんどありません。既存資産との一時的な整合性が必要な場合を除き、isolated worker model を標準としたテンプレートを社内に用意するのがよいでしょう。

既存環境の移行判断：すぐ移行すべきか、段階移行すべきか

すべての Function App を即時移行する必要はありません。ただし、移行計画はすぐに作るべきです。

状況	推奨アクション
.NET 6 / .NET 7 で稼働中	優先度高。サポート切れのため早急に移行計画を作成
.NET 8 in-process で稼働中	2026年11月10日までに isolated worker model へ移行
.NET 8 isolated で稼働中	パッケージ、ログ、パフォーマンス設定を確認
.NET 10 を検討中	ホスティングプラン、Linux Consumption 制約を先に確認
Functions runtime 1.x	2026年9月14日までに 4.x 移行を計画
Functions runtime 2.x / 3.x	すでにサポート外のため、優先対応

移行期限だけを見ると 2026年11月まで余裕があるように見えます。しかし、業務アプリでは検証、承認、本番切り替え、監視、障害時ロールバックの期間が必要です。管理者は「期限までに着手」ではなく、「期限までに本番安定稼働」をゴールにするべきです。

まとめ：.NET Azure Functions は isolated worker model 前提で移行計画を作る

今回の「Guide for running C# Azure Functions in the isolated worker model」の更新は、機能追加というより、パフォーマンス最適化まわりの説明整理が中心です。しかし、運用担当者が見るべき本質は変わりません。C# Azure Functions の in-process モデルは 2026年11月10日にサポート終了予定であり、今後の .NET バージョン対応、依存関係管理、ログ設計、パフォーマンス最適化を考えると、isolated worker model への移行は避けて通れません。

まずは、現在の Function App を棚卸しし、FUNCTIONS_WORKER_RUNTIME、Functions runtime、ターゲット .NET、ホスティングプラン、利用トリガー、CI/CD、Application Insights 設定を確認してください。そのうえで、低リスクなアプリからステージングスロットを使って移行手順を固め、期限前に本番環境で安定稼働できる状態を目指すのが最も安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

.NET Azure Functions isolated worker model 更新ポイント｜移行期限・設定変更・管理者の確認事項

.NET の Azure Functions isolated worker model とは

2026年7月3日の更新ポイントは「機能追加」よりも確認事項の明確化

影響範囲：どの .NET Azure Functions が確認対象になるか

サポート期限：in-process モデルは 2026年11月10日終了予定

サポートされる .NET バージョンの見方

.NET 10 と Linux Consumption plan の注意点

パッケージ参照の更新ポイント

確認すべき `.csproj` の例

`Program.cs` が移行の中心になる

`FUNCTIONS_WORKER_RUNTIME` は `dotnet-isolated` に変更する

Azure 側のランタイム設定はコードと同時に変更する

HTTP トリガーは ASP.NET Core integration を検討する

判断基準

ログ設定は `host.json` だけでは不十分になる

パフォーマンス最適化：Placeholders と ReadyToRun を確認する

Placeholders

ReadyToRun

移行時に変更が必要になりやすいコード

管理者が最初にやるべき棚卸し

移行チェックリスト

失敗しやすいポイント

`FUNCTIONS_WORKER_RUNTIME` だけ変更してしまう

`Microsoft.Azure.WebJobs.*` が残っている

Application Insights のログ量が変わる

HTTP トリガーの型を安易に選ぶ

Linux Consumption の将来制約を見落とす

新規開発ではどう設計すべきか

既存環境の移行判断：すぐ移行すべきか、段階移行すべきか

まとめ：.NET Azure Functions は isolated worker model 前提で移行計画を作る

この記事を書いた人

コメント

コメントするコメントをキャンセル

.NET Azure Functions isolated worker model 更新ポイント｜移行期限・設定変更・管理者の確認事項

.NET の Azure Functions isolated worker model とは

2026年7月3日の更新ポイントは「機能追加」よりも確認事項の明確化

影響範囲：どの .NET Azure Functions が確認対象になるか

サポート期限：in-process モデルは 2026年11月10日終了予定

サポートされる .NET バージョンの見方

.NET 10 と Linux Consumption plan の注意点

パッケージ参照の更新ポイント

確認すべき .csproj の例

Program.cs が移行の中心になる

FUNCTIONS_WORKER_RUNTIME は dotnet-isolated に変更する

Azure 側のランタイム設定はコードと同時に変更する

HTTP トリガーは ASP.NET Core integration を検討する

判断基準

ログ設定は host.json だけでは不十分になる

パフォーマンス最適化：Placeholders と ReadyToRun を確認する

Placeholders

ReadyToRun

移行時に変更が必要になりやすいコード

管理者が最初にやるべき棚卸し

移行チェックリスト

失敗しやすいポイント

FUNCTIONS_WORKER_RUNTIME だけ変更してしまう

Microsoft.Azure.WebJobs.* が残っている

Application Insights のログ量が変わる

HTTP トリガーの型を安易に選ぶ

Linux Consumption の将来制約を見落とす

新規開発ではどう設計すべきか

既存環境の移行判断：すぐ移行すべきか、段階移行すべきか

まとめ：.NET Azure Functions は isolated worker model 前提で移行計画を作る

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

確認すべき `.csproj` の例

`Program.cs` が移行の中心になる

`FUNCTIONS_WORKER_RUNTIME` は `dotnet-isolated` に変更する

ログ設定は `host.json` だけでは不十分になる

`FUNCTIONS_WORKER_RUNTIME` だけ変更してしまう

`Microsoft.Azure.WebJobs.*` が残っている

コメントするコメントをキャンセル