Azure Functionsの「Compare Azure Functions Runtime Versions」でまず押さえるべき結論は、新規・既存を問わず、基本方針はAzure Functionsランタイム4.xへ集約することです。1.xは.NET Frameworkが必要なC#アプリ向けに残っていますが、2026年9月14日にサポート終了予定です。2.xと3.xはすでにサポート対象外で、特にLinuxの従量課金プランでv3ランタイムを使っている関数アプリは、2026年9月30日以降に停止リスクがあります。(Microsoft Learn)
この記事では、Azure Functions Runtime Versionsの比較ポイント、管理者・開発者が確認すべき設定、移行時に失敗しやすい箇所、展開前のチェック項目を実務向けに整理します。単に「4.xにすればよい」で終わらせず、FUNCTIONS_EXTENSION_VERSION、FUNCTIONS_WORKER_RUNTIME、.NETの実行モデル、Linux ConsumptionからFlex Consumptionへの移行まで、運用で見落としやすい論点を確認していきます。
Compare Azure Functions Runtime Versionsの要点
Azure Functionsのランタイム比較で重要なのは、バージョン番号そのものよりも、サポートされる実行環境・言語バージョン・ホスティングプラン・移行期限が組み合わさっている点です。
公式情報では、ランタイムホストとして実質的に中心となるのは4.xです。1.xはGAではあるものの、.NET Frameworkを使う必要があるC#アプリ向けの例外的な選択肢で、メンテナンスモードに位置付けられています。2.xと3.xは廃止済みで、完全なサポート、新機能、セキュリティ修正、パフォーマンス最適化を受けるには4.xへの移行が必要です。(Microsoft Learn)
| ランタイム | 現在の扱い | 主な対象 | 管理者・開発者の判断 |
|---|---|---|---|
| 4.x | 推奨ランタイム | ほぼすべての言語・新規アプリ | 標準選択。既存アプリも原則4.xへ移行する |
| 1.x | GAだが終了予定 | .NET Frameworkが必須のC#アプリ | 2026年9月14日までに4.x移行可否を判断する |
| 3.x | サポート対象外 | 旧環境 | 早急に4.xへ移行。Linux Consumptionは停止リスクに注意 |
| 2.x | サポート対象外 | 旧環境 | 新規機能・修正を期待せず、移行計画を立てる |
この変更は、Azure Functionsを単体で使っているチームだけでなく、CI/CD、IaC、監視、セキュリティ運用を含むチーム全体に影響します。たとえば、アプリ本体は動いていても、古いランタイムのままでは新しい言語バージョンを選べない、トリガーやバインディング拡張機能の最低要件を満たせない、サポート問い合わせ時に先に移行を求められる、といった問題が起こり得ます。
影響を受けやすいAzure Functions環境
今回のランタイム比較で特に確認すべき環境は、次の4つです。
ランタイム1.xを使っているC#アプリ
Azure Functions 1.xは、.NET Frameworkを使う必要があるC#アプリ向けに残っています。ただし、サポート終了日は2026年9月14日と明示されています。つまり、1.xを使い続ける判断をする場合でも、「いつまでに4.xへ移行するか」「.NET Framework依存をどう解消するか」を管理対象にする必要があります。(Microsoft Learn)
移行の検討では、単にランタイムを~1から~4へ変えるのではなく、プロジェクトのターゲットフレームワーク、使用しているNuGetパッケージ、トリガー、バインディング、接続文字列、認証方式を確認します。特に古いStorage Queue、Timer Trigger、HTTP Trigger、Service Bus連携を使っているアプリでは、拡張機能のバージョン差が影響することがあります。
ランタイム2.xまたは3.xを使っているアプリ
2.xと3.xは、2022年12月13日に延長サポートが終了しています。公式情報では、2.x/3.xのアプリはCI/CDパイプラインから作成・デプロイできる場合があり、既存アプリも一部を除いて継続実行されますが、新機能、セキュリティパッチ、パフォーマンス最適化の対象ではありません。関連するサービスサポートも、4.xへのアップグレード後が前提になります。(Microsoft Learn)
ここで注意したいのは、「動いているから問題ない」と判断しないことです。サポート外ランタイムは、障害発生時の復旧選択肢が狭くなります。たとえば、依存ライブラリの更新、言語ランタイムの更新、Azure側の仕様変更が重なったときに、修正よりも先にランタイム移行が必要になるケースがあります。
Linuxの従量課金プランでv3を使っているアプリ
Linuxの従量課金プランでv3ランタイムを実行している関数アプリは、2026年9月30日以降に実行停止のリスクが明示されています。さらに、Linuxの従量課金プラン自体も2028年9月30日に廃止予定で、新しい機能や言語バージョンは追加されません。Windowsの従量課金プランで動作しているアプリは、同じ案内の中では現時点で影響対象外とされています。(Microsoft Learn)
このため、Linux Consumptionを使っている場合は、ランタイム4.xへの移行だけでなく、Flex Consumptionプランへの移行も同時に検討した方が現実的です。Microsoft Learnでは、ConsumptionからFlex Consumptionへの移行について、多くのアプリではコード変更なしで進められると説明されていますが、新しいアプリを並行作成してテスト後に切り替える流れが前提です。(Microsoft Learn)
.NETのin-processモデルを使っているアプリ
.NETのAzure Functionsでは、ランタイム4.xであっても、in-processモデルを使っている場合は別の期限があります。公式情報では、in-processモデルのサポートは2026年11月10日に終了予定であり、完全なサポートを受けるにはisolated worker modelへの移行が推奨されています。(Microsoft Learn)
これは見落とされやすいポイントです。FUNCTIONS_EXTENSION_VERSIONが~4であっても、C#アプリがin-processモデルのままだと、将来の.NETバージョンへ追従しづらくなります。特に長期運用する業務システムでは、「Functions 4.x化」と「.NET isolated worker化」を別プロジェクトにせず、同じ移行計画で扱う方が手戻りを減らせます。
サポートされる言語バージョンの見方
Azure Functionsでは、ランタイムバージョンだけでなく、使う言語のバージョンも確認が必要です。関数アプリ内のすべての関数は同じ言語を共有し、言語はFUNCTIONS_WORKER_RUNTIME設定で管理されます。既存の関数がある場合、この言語設定は簡単には変更できません。(Microsoft Learn)
| 言語・実行環境 | 確認すべきポイント |
|---|---|
| .NET isolated worker | .NET 10、.NET 9、.NET 8、.NET Framework 4.8.1などの対応状況を確認する |
| .NET in-process | 現在は.NET 8中心。2026年11月10日のサポート終了を前提に移行を計画する |
| Java | Java 25、21、17、11、8の対応期限を確認する |
| Node.js | Node.js 24、22が中心。TypeScriptはJavaScriptへトランスパイルして利用する |
| PowerShell | 7.4がGA、7.6はPreviewとして扱われる |
| Python | 3.13、3.12、3.11、3.10などの対応期限を確認する。3.14はPreview扱い |
| Go | Previewで、Flex Consumptionプラン上の関数アプリに限定される |
実務では、言語バージョンを「最新版に上げる」だけで判断しないことが重要です。たとえば、Linux Consumptionでは、.NET 9、Java 21、Node.js 22、PowerShell 7.4、Python 3.12がそれぞれ最後にサポートされるバージョンとして示されており、それより新しい言語バージョンは追加されない前提です。(Microsoft Learn)
つまり、言語バージョンを上げたい場合は、ホスティングプランの見直しもセットになります。Python 3.13やNode.js 24などを使いたいのにLinux Consumptionに残り続ける、といった設計は将来の詰まりどころになります。
管理者が最初に確認すべき設定
Azure Functionsのランタイム管理で最初に見るべき設定は、FUNCTIONS_EXTENSION_VERSIONです。このアプリケーション設定が、Azure上で発行済みアプリが使うFunctionsランタイムのバージョンを決定します。通常、4.xを対象にする場合は~4が使われます。(Microsoft Learn)
Azureポータルでは、Function Appを開き、設定メニューから構成を確認します。Azure CLIでは、次のようにアプリ設定を取得できます。公式ドキュメントでも、FUNCTIONS_EXTENSION_VERSIONとFUNCTIONS_WORKER_RUNTIMEを確認する例が示されています。(Microsoft Learn)
az functionapp config appsettings list \
--name <function_app> \
--resource-group <resource_group>確認すべき値は、最低限この3つです。
| 設定・項目 | 確認内容 | よくある問題 |
|---|---|---|
FUNCTIONS_EXTENSION_VERSION | ~4、~1、特定マイナーバージョンなど | 古いランタイムや一時的な固定が放置されている |
FUNCTIONS_WORKER_RUNTIME | dotnet、dotnet-isolated、node、pythonなど | 想定と違う言語ワーカーで作成されている |
| ホスティングプラン | Consumption、Flex Consumption、Premium、App Service Planなど | Linux Consumptionのまま新しい言語バージョンを使おうとしている |
FUNCTIONS_EXTENSION_VERSIONを手動で変更すれば移行できる、と考えるのは危険です。公式情報でも、既存アプリでは他のアプリ設定や関数コードの変更が必要になる可能性があるため、この設定を任意に変更しないよう注意されています。(Microsoft Learn)
開発者が確認すべきプロジェクト設定
ローカル開発環境では、Azure上のランタイムとプロジェクト設定がずれていないかを確認します。Visual Studioのプロジェクトでは、.csproj内のTargetFrameworkとAzureFunctionsVersionが重要です。4.xを対象にする場合は、たとえば次のような設定になります。(Microsoft Learn)
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>Visual Studio Codeやコマンドライン開発では、Azure Functions Core Toolsのメジャーバージョンが、Azure上のFunctionsランタイムのメジャーバージョンと一致しているかを確認します。公式情報でも、ローカル開発時はインストール済みのAzure Functions Core Toolsが、Azure上の関数アプリで使うメジャーランタイムと一致している必要があると説明されています。(Microsoft Learn)
開発者が特に注意すべきなのは、次のようなケースです。
| ケース | 確認すること |
|---|---|
| .NET 6や.NET 7のまま | すでに公式サポート終了済みのため、.NET 8以降やisolated workerへの移行を検討する |
| C# in-processを使っている | 2026年11月10日のサポート終了を見据え、isolated worker化を計画する |
古いMicrosoft.NET.Sdk.Functionsを使っている | Functions v4に対応するパッケージ要件を満たすか確認する |
| VS Codeテンプレートが古い | azureFunctions.projectRuntimeやCore Toolsのバージョンを確認する |
| CI/CDだけでデプロイしている | パイプライン内のSDK、Node、Python、Core Toolsのバージョンを棚卸しする |
特に.NET移行では、ランタイム4.x化とisolated worker化を分けて考えると、短期的には楽に見えても後で再移行が必要になりがちです。公式移行ガイドでも、3.xから4.xへ移行する際にisolated worker modelへ移ることで、将来の.NETバージョンを対象にしやすくなると説明されています。(Microsoft Learn)
移行前に作るべき棚卸しリスト
Azure Functionsのランタイム移行は、対象アプリを正しく棚卸しできるかで成否が分かれます。最初に全Function Appを一覧化し、少なくとも次の項目を記録してください。
| 棚卸し項目 | 理由 |
|---|---|
| Function App名、リソースグループ、サブスクリプション | 移行対象を漏らさないため |
現在のFUNCTIONS_EXTENSION_VERSION | 1.x、2.x、3.x、4.x、固定マイナーを判定するため |
FUNCTIONS_WORKER_RUNTIME | 言語別の移行手順を選ぶため |
| OSとホスティングプラン | Linux ConsumptionやFlex Consumption移行要否を判断するため |
| トリガーとバインディング | Storage、Service Bus、Event Hubsなどの拡張機能影響を確認するため |
| デプロイ方式 | GitHub Actions、Azure DevOps、Zip Deploy、Run From Packageなどの修正範囲を見るため |
| 本番・検証・ステージングスロットの有無 | ダウンタイムを抑えた切り替えが可能か判断するため |
| 監視・アラート | 移行後の異常検知を準備するため |
PowerShellで3.xを対象にする例は、公式の3.xから4.xへの移行ガイドでも紹介されています。移行前には、対象アプリの特定、破壊的変更の確認、ローカルでの4.xテスト、Azure上の事前検証、ステージングスロットを使った確認、公開という流れで進めることが推奨されています。(Microsoft Learn)
ランタイム4.xへ移行する基本手順
移行作業は、いきなり本番アプリの設定を変えるのではなく、段階的に進めます。
| 手順 | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | ランタイム、言語、ホスティングプランを一覧化 | サブスクリプションや検証環境の漏れ |
| 移行方針の決定 | 4.x化、isolated worker化、Flex移行を切り分ける | ランタイムだけ変えて依存関係を放置する |
| ローカル修正 | プロジェクトファイル、パッケージ、Core Toolsを更新 | ローカルでは動くがAzure設定と不一致 |
| 拡張機能確認 | トリガー・バインディング拡張機能を更新 | host.jsonやNuGetの最低バージョン不足 |
| 検証環境デプロイ | ステージングスロットまたは新アプリで検証 | 本番接続先を誤って使う |
| 本番切り替え | スロットスワップ、DNS、ルーティングなどを切り替え | 監視・ロールバック手順が未準備 |
| 移行後監視 | Application Insights、ログ、実行失敗率を確認 | Timer TriggerやQueue Triggerの遅延を見逃す |
公式移行ガイドでは、既存アプリを4.xに移行する前に、破壊的変更の確認、ローカルプロジェクトの移行、Core Tools 4.xでのテスト、Azure上のpre-upgrade validatorの実行、必要に応じたステージングスロットでの検証が推奨されています。(Microsoft Learn)
本番停止を避けたい場合は、ステージングスロットを使えるプランではスロットで検証し、ConsumptionからFlex Consumptionへ移る場合は新しいFlex Consumptionアプリを並行作成して十分にテストします。Flex Consumptionへの移行では、新しいアプリを既存アプリの横に作成し、テスト後にトラフィックを切り替え、旧アプリを廃止する流れが一般原則として示されています。(Microsoft Learn)
拡張機能とhost.jsonで見落としやすい点
Azure Functions 4.xでは、トリガーやバインディング拡張機能の最低バージョンが適用されます。バインディング拡張機能のバージョンとFunctionsランタイムのバージョンに技術的な相関が常にあるわけではありませんが、4.x以降では最低要件を満たさない場合に警告や実行時エラーの原因になります。(Microsoft Learn)
C#スクリプトなどでExtension Bundleを使っている場合は、host.jsonの設定も確認してください。公式情報では、次のような範囲指定が例として示されています。(Microsoft Learn)
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.0.0, 5.0.0)"
}
}ここで失敗しやすいのは、アプリ設定のFUNCTIONS_EXTENSION_VERSIONだけを~4に変更し、host.jsonやNuGetパッケージを古いままにするパターンです。HTTP Triggerだけの小さなアプリでは問題が見えにくくても、Storage Queue、Cosmos DB、Service Bus、Event Hubs、Timer Triggerなどを使うアプリでは、バインディング拡張機能の差が本番で表面化することがあります。
マイナーバージョン固定は一時対応にとどめる
Azure Functionsでは、FUNCTIONS_EXTENSION_VERSIONに~4を指定すると、4.xの新しいマイナーバージョンへ自動更新されます。特定の不具合回避などでマイナーバージョンへ固定することはできますが、公式情報では、可能な限り最新のサポート済みランタイムを使い、固定は必要な期間だけにする方針が示されています。(Microsoft Learn)
注意点は3つあります。
| 注意点 | 内容 |
|---|---|
| 固定すると再起動が発生する | 設定変更時にFunction Appが再起動する |
| 古いマイナーバージョンは削除される | 固定したバージョンがいつまでも使えるとは限らない |
| Linuxでは扱いが異なる | LinuxではlinuxFxVersionも関係し、固定方法や制約がWindowsと異なる |
特にLinuxアプリでは、固定されたFunction Appは通常のセキュリティ更新やホスト機能更新を受け取らない点に注意が必要です。また、Linux Consumptionでは特定ランタイムへの固定が現在サポートされないと説明されています。(Microsoft Learn)
Linux ConsumptionからFlex Consumptionへ移るべきか
Linux Consumptionを使っている場合、ランタイム4.xへの移行だけでなく、Flex Consumptionへの移行を検討する価値があります。理由は、Linux Consumptionのホスティング自体が2028年9月30日に廃止予定であり、新しい機能や言語バージョンが追加されないためです。(Microsoft Learn)
Flex Consumptionへ移るメリットとして、公式ガイドでは、Always-ready instancesによるコールドスタート改善、関数単位のスケーリング、同時実行制御、仮想ネットワーク対応、新機能の投資先であることが挙げられています。(Microsoft Learn)
判断基準は次の通りです。
| 状況 | 推奨判断 |
|---|---|
| Linux Consumptionでv3を使っている | 4.x移行とFlex Consumption移行を優先度高で計画する |
| Linux Consumptionで新しい言語バージョンを使いたい | Flex Consumptionへの移行を前提に検討する |
| Windows Consumptionで安定稼働している | 直ちに同じ影響は受けないが、ランタイムと言語サポートは確認する |
| VNet接続や低レイテンシが重要 | Flex Consumption、Premium、App Service Planなどを比較する |
| IaCで管理している | Flex Consumption用のリソース定義差分を確認する |
Flex Consumption移行では、既存アプリを直接書き換えるのではなく、新しいFlex Consumptionアプリを作成し、依存サービスを確認し、テスト後に切り替える考え方が重要です。公式ガイドでも、移行プロセスは新しいアプリを既存アプリの横に作り、切り替えタイミングを制御できると説明されています。(Microsoft Learn)
実務で使える確認チェックリスト
移行判断を始める前に、次のチェックを順番に実施してください。
| チェック | OKの目安 |
|---|---|
| すべてのFunction Appを一覧化した | 本番、検証、開発、停止中リソースも含めて確認済み |
FUNCTIONS_EXTENSION_VERSIONを確認した | 原則~4。~1、~2、~3、固定マイナーは要対応 |
FUNCTIONS_WORKER_RUNTIMEを確認した | 実際のコードと言語ワーカーが一致している |
| .NETの実行モデルを確認した | in-processの場合はisolated worker移行計画がある |
| Linux Consumption利用を確認した | 2026年・2028年の期限を踏まえた対応計画がある |
| Core ToolsとローカルSDKを確認した | Azure上のランタイムとメジャーバージョンが一致している |
| NuGetやExtension Bundleを確認した | Functions 4.xの最低要件を満たしている |
| ステージングまたは並行環境で検証した | 本番切り替え前に実行ログと依存サービスを確認済み |
| ロールバック方法を決めた | スロット戻し、旧アプリへの切り戻し、再デプロイ手順がある |
| 移行後の監視項目を決めた | 失敗率、実行時間、スケール、キュー滞留、例外ログを確認する |
特に管理者は「サポート終了日」だけを追うのではなく、開発者が実際に移行できる状態かを確認する必要があります。古いランタイムのアプリは、担当者不在、ローカル環境の再現不可、依存パッケージの固定、CI/CDの認証情報切れなど、技術以外の理由で移行が遅れがちです。
失敗しやすい移行パターン
Azure Functions Runtime Versionsの移行でよくある失敗は、次のようなものです。
| 失敗パターン | 何が問題か | 対策 |
|---|---|---|
アプリ設定だけ~4に変える | コード、パッケージ、拡張機能が未対応のままになる | 移行ガイドに沿ってローカル修正と検証を行う |
| .NET in-processを残したまま安心する | 4.xでもin-processのサポート期限が別にある | isolated worker modelへの移行計画を作る |
| Linux Consumptionの期限を見落とす | ランタイムだけでなくプラン自体の将来制約がある | Flex Consumption移行を同時に検討する |
| 固定マイナーバージョンを放置する | 古いバージョン削除や更新漏れの原因になる | 一時対応後は~4へ戻す |
| 開発環境とAzure環境がずれる | ローカルでは成功してもAzureで失敗する | Core Tools、SDK、CI/CDのバージョンを合わせる |
| 監視なしで切り替える | TimerやQueueの遅延、再試行増加を見逃す | Application Insightsとアラートを事前に設定する |
移行作業では、「設定変更」「コード変更」「ホスティング変更」を分けて検証できるようにすることが大切です。たとえば、まず4.x対応のコードを検証環境で動かし、その後Flex Consumptionへ移す、最後に本番トラフィックを切り替える、といった段階化を行うと障害時の原因切り分けが容易になります。
次に取るべき行動
Azure Functionsの「Compare Azure Functions Runtime Versions」で示されているポイントは、単なるバージョン表ではありません。今後の運用では、4.xを標準とし、1.x、2.x、3.x、Linux Consumption、.NET in-processを重点的に棚卸しする必要があります。
まず実施すべきことは、全Function AppのFUNCTIONS_EXTENSION_VERSION、FUNCTIONS_WORKER_RUNTIME、ホスティングプラン、.NET実行モデルを一覧化することです。そのうえで、1.xは2026年9月14日、Linux Consumption上のv3は2026年9月30日、.NET in-processは2026年11月10日、Linux Consumptionプランは2028年9月30日という期限を軸に、移行優先度を決めてください。(Microsoft Learn)
最も安全な進め方は、対象アプリを棚卸しし、ローカルで4.x対応を完了し、拡張機能とCI/CDを更新し、ステージングまたは新しいFlex Consumptionアプリで検証してから本番へ切り替える流れです。今すぐすべてを移行できない場合でも、固定マイナーバージョンやサポート外ランタイムを放置せず、アプリごとの期限と担当者を明確にするところから始めましょう。
コメント