MENU

Azure FunctionsのNode.js CI更新を解説：Node 18削除とNode 24/26追加の影響

Azure

Azure Functions documentation updateとして扱われている今回の更新は、Azure Functionsの本番ランタイムを自動でNode.js 26へ切り替える告知ではありません。実体は、Azure Functions Node.jsライブラリ側のCIテストマトリクスを見直し、EOLになったNode.js 18を外し、Node.js 24とNode.js 26を追加する変更です。Azure FunctionsでNode.jsアプリを運用している管理者・開発者は、まず「Node.js 18で動くアプリやCIが残っていないか」「Node.js 22/24へ上げる準備ができているか」「Linux ConsumptionやWindows 32bit設定に引っかからないか」を確認してください。公式PRでは、Node 18削除、Node 24/26追加、対象ファイルとしてazure-pipelines/templates/test.ymlが示されています。(GitHub)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

まず押さえるべき結論

今回のポイントは、次の3つです。

観点結論
変更の種類Azure Functions Node.jsライブラリのCIテスト対象変更
直接の変更内容Node.js 18をテスト対象から削除し、Node.js 24とNode.js 26を追加
実務上の対応Node.js 18利用の棚卸し、CI/CDのNodeバージョン更新、Azure Functionsの実行設定確認

特に重要なのは、CIでテストされなくなったバージョンは、今後の不具合検知や互換性確認の対象から外れていくという点です。Node.js 18で動いているFunction Appがまだある場合、「今は動いている」だけでは十分ではありません。セキュリティ修正、依存パッケージ、Azure Functionsランタイム、デプロイツールの更新に追従できなくなるリスクがあります。

Node.js公式のリリーススケジュールでは、Node.js 18は2025年4月30日にEOL、Node.js 20も2026年4月30日にEOLとされています。Node.js 24はActive LTS、Node.js 26はCurrentとして扱われ、Node.js 26は今後LTSへ移行予定のラインです。(GitHub)

何が変わったのか

公式PRの内容を見ると、CIのNode.jsテストマトリクスは次のように変わっています。PRは2026年5月20日にv4.xブランチへマージされ、差分としてazure-pipelines/templates/test.ymlとpackage-lock.jsonが変更されています。(GitHub)

変更前変更後
Node.js 18削除
Node.js 20継続
Node.js 22継続
なしNode.js 24を追加
なしNode.js 26を追加

PRの説明では、package.jsonのenginesフィールドはすでに>=20.0を要求しており、Node.js 18を外す方針と整合していることも示されています。また、パッケージング用のビルドステップは引き続きNode.js 20を使うとされています。(GitHub)

ここで誤解しやすいのは、「CIにNode.js 26が追加された」ことと「Azure Functionsの本番ランタイムとしてNode.js 26が正式利用できる」ことは別だという点です。CIの追加は、ライブラリやSDK側が将来のNode.jsバージョンとの互換性を早期に検証するための動きと見るべきです。

Azure Functions利用者への影響範囲

今回の更新で直接影響を受けやすいのは、次のような環境です。

対象影響取るべき対応
Node.js 18で動くFunction Appサポート外ランタイムに残るリスクが高いNode.js 22以上への移行計画を作る
CIでNode.js 18を使っているリポジトリ将来のライブラリ更新でテストが失敗しやすくなるNode.js 18を外し、20/22/24を中心に再設計
Azure Functions Node.jsライブラリを扱う開発者Node.js 24/26での互換性検証が必要テストマトリクスを公式PRに合わせる
Linux ConsumptionプランのNode.jsアプリNode.js 24以降へ進めない可能性があるFlex Consumptionなど移行先を確認
WindowsでNode.js 24を使うFunction App32bitプロセス設定だと起動失敗の可能性64bitプロセスを有効化

Microsoft LearnのAzure Functions対応言語一覧では、Node.js 24はPreview、Node.js 22はGA、Node.js 20はGAとして掲載され、Node.js 22がLinux Consumptionプランでサポートされる最後のNode.jsバージョンであることも明記されています。(Microsoft Learn)

そのため、運用環境の移行先は原則としてNode.js 22を第一候補にし、Node.js 24はPreview利用の可否を社内基準で判断するのが現実的です。Node.js 26はCIでの先行検証対象としては有用ですが、Azure Functionsの実行環境として使う場合は、必ず最新の公式サポート表を確認してから判断してください。

本番ランタイムとCIを分けて考える

Azure FunctionsのNode.js移行で失敗しやすいのは、次の3つを混同することです。

種類例役割
ローカル開発環境node -v、nvm、Volta開発者のPCで動くNode.js
CI/CD環境Azure Pipelines、GitHub Actionsテスト、ビルド、デプロイで使うNode.js
Azure Functions実行環境WEBSITE_NODE_DEFAULT_VERSION、linuxFxVersionAzure上でFunction Appを実行するNode.js

CIをNode.js 24にしても、Function Appの実行環境がNode.js 22のままなら、本番ではNode.js 22で動きます。逆に、Azure側だけNode.js 22へ上げても、CIがNode.js 18のままだと、テスト済みの前提と本番の実行条件がずれます。

移行時は、ローカル、CI、本番のNode.jsメジャーバージョンを意図的にそろえるか、少なくとも「CIでは本番バージョンと次期候補バージョンの両方をテストする」構成にしてください。

管理者が確認すべきAzure Functionsの設定

共通で確認する設定

Azure FunctionsのNode.jsアプリでは、まず以下を確認します。

設定確認内容
FUNCTIONS_EXTENSION_VERSION基本は~4であること
FUNCTIONS_WORKER_RUNTIMENode.jsアプリではnodeであること
WEBSITE_NODE_DEFAULT_VERSIONWindowsのNode.jsバージョン指定
linuxFxVersionLinuxのNode.jsバージョン指定
ホスティングプランConsumption、Flex Consumption、Premium、Dedicatedのどれか
OSWindowsかLinuxか
デプロイスロットステージング検証や切り戻しに使えるか

Microsoft Learnでは、FUNCTIONS_EXTENSION_VERSION=~4がFunctionsランタイム4.xを使う指定であり、FUNCTIONS_WORKER_RUNTIMEはFunction Appで読み込む言語ワーカーを指定する値と説明されています。Node.jsアプリの場合はFUNCTIONS_WORKER_RUNTIMEにnodeを使います。(Microsoft Learn)

現在の設定は、Azure CLIで次のように確認できます。

az functionapp config appsettings list \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --query "[?name=='FUNCTIONS_EXTENSION_VERSION' || name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']"

Linuxの場合は、次のコマンドでlinuxFxVersionを確認します。

az functionapp config show \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --query "{linuxFxVersion:linuxFxVersion, use32BitWorkerProcess:use32BitWorkerProcess}"

WindowsでNode.jsバージョンを変更する場合

Windows上のFunction Appでは、Node.jsバージョンはWEBSITE_NODE_DEFAULT_VERSIONで指定します。Microsoft Learnでは、チルダ付きのメジャーバージョンを使うことで、そのメジャー内の利用可能な最新バージョンを使わせる形式が説明されています。(Microsoft Learn)

Node.js 22へ移行する例は次のとおりです。

az functionapp config appsettings set \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --settings WEBSITE_NODE_DEFAULT_VERSION=~22

Node.js 24をWindows環境で使う場合は、64bitプロセスが有効かも確認してください。日本マイクロソフトのJapan PaaS Support Team Blogでは、Windows環境のApp Service / Azure FunctionsでNode.js 24を使う場合、Node.js 24のバイナリは64bitプロセス側に提供されるため、64bitプロセスの有効化が必要と説明されています。(Azure)

az functionapp config set \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --use-32bit-worker-process false

この確認を省くと、Node Language Workerが起動できず、Function Hostの起動失敗やHTTP 500につながる可能性があります。特に古いFunction Appでは、過去の設定が残っていないかを移行前に必ず見てください。

LinuxでNode.jsバージョンを変更する場合

Linux上のFunction Appでは、Node.jsバージョンはlinuxFxVersionで指定します。Microsoft Learnでは、LinuxではAzure CLIでlinuxFxVersionを更新する方法が示されています。(Microsoft Learn)

Node.js 22へ変更する例は次のとおりです。

az functionapp config set \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --linux-fx-version "node|22"

Node.js 24を検討する場合は、実行中のホスティングプランに注意してください。Azure Functionsの対応言語一覧では、Node.js 22がLinux Consumptionプランでサポートされる最後のNode.jsバージョンと説明されています。Node.js 24以降を使いたいLinux Consumptionアプリでは、Flex Consumptionなど別プランへの移行可否を確認する必要があります。(Microsoft Learn)

Linux ConsumptionからFlex Consumptionへの移行では、リージョン、言語スタック、スタックバージョン、デプロイスロット、証明書、Blob Storageトリガーなどを確認する手順がMicrosoft Learnに整理されています。特にFlex Consumptionでは一部の従来設定がfunctionAppConfigへ置き換わるため、ARM、Bicep、Terraformで管理している環境はIaC定義も見直してください。(Microsoft Learn)

開発者が確認すべきpackage.jsonとプログラミングモデル

Azure FunctionsのNode.jsでは、Node.jsのメジャーバージョンだけでなく、@azure/functionsパッケージとプログラミングモデルの整合性も重要です。

Microsoft Learnでは、Node.jsプログラミングモデルとAzure Functionsランタイムは別物であり、プログラミングモデルのバージョンは@azure/functions npmパッケージのバージョンと結び付いていると説明されています。また、同一Function App内でv3モデルとv4モデルを混在できず、v4関数を登録するとfunction.jsonで登録されたv3関数が無視される点にも注意が必要です。(Microsoft Learn)

確認すべきファイルは主に次の3つです。

ファイル確認ポイント
package.jsonengines.node、@azure/functions、依存パッケージの対応Node.js
package-lock.jsonNode.js/npm変更後に意図しない差分が出ていないか
host.json拡張機能、ログ、拡張バンドルの設定

engines.nodeに18や^18が残っている場合は、移行先に合わせて見直します。Node.js 22へ移行するなら、例えば次のように明示しておくと、開発者のローカル環境やCIで古いNode.jsを使った時に検知しやすくなります。

{
  "engines": {
    "node": ">=22 <23"
  }
}

ただし、CIでNode.js 22と24の両方を検証したいライブラリでは、>=22 <25のように幅を持たせる判断もあります。業務アプリでは本番実行バージョンに寄せ、ライブラリではサポート範囲に合わせるのが基本です。

CI/CDパイプラインの更新例

今回の公式PRでは、Azure PipelinesのテストマトリクスからNode.js 18が削除され、Node.js 24と26が追加されています。自社のCIでも同じ考え方を取り入れるなら、まずNode.js 18を外し、本番候補と将来候補を分けて設計します。(GitHub)

Azure Pipelinesの例です。

strategy:
  matrix:
    Node20:
      NODE_VERSION: '20.x'
    Node22:
      NODE_VERSION: '22.x'
    Node24:
      NODE_VERSION: '24.x'
    Node26:
      NODE_VERSION: '26.x'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '$(NODE_VERSION)'
  - script: npm ci
    displayName: npm ci
  - script: npm test
    displayName: npm test

業務アプリでは、Node.js 26を必須テストにするかは慎重に判断してください。Node.js公式ブログでは、Node.js 26はリリース時点でCurrentであり、LTS入りまでは評価期間という位置付けで説明されています。(Node.js)

GitHub Actionsを使っている場合は、次のようにできます。

name: test

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20.x, 22.x, 24.x]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

Node.js 26を入れる場合は、最初は「将来互換性の検出用」として扱い、失敗時に本番リリースを止めるかどうかをチームで決めておくと安全です。たとえばライブラリ開発では必須、社内業務アプリでは任意または別ジョブ、という分け方が現実的です。

移行前にやるべき棚卸し

Node.js 18からの移行は、単にAzure Portalでバージョンを変えるだけでは不十分です。次の順番で棚卸ししてください。

手順確認内容判断基準
アプリ一覧化Node.jsで動くFunction Appを洗い出すFUNCTIONS_WORKER_RUNTIME=nodeが対象
バージョン確認WindowsはWEBSITE_NODE_DEFAULT_VERSION、LinuxはlinuxFxVersionを見る18が残っていれば移行対象
プラン確認Linux Consumptionか、Premium/Dedicated/FlexかNode.js 24以降を使えるかに影響
CI確認Azure PipelinesやGitHub ActionsのNode.js指定を見る18.xを削除
依存関係確認ネイティブモジュール、古いSDK、非推奨APIを確認npm ciとテストで検出
監視確認Application Insights、ログ、アラートを確認移行後の異常検知に必要

サブスクリプション内のFunction Appを一覧化する例です。

az functionapp list \
  --query "[].{name:name, resourceGroup:resourceGroup, kind:kind, state:state}" \
  --output table

特定アプリの設定確認例です。

az functionapp config appsettings list \
  --name <FUNCTION_APP_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --query "[].{name:name, value:value}" \
  --output table

本番環境だけでなく、検証環境、DR環境、停止中のFunction App、古いデプロイスロットも確認してください。停止中のアプリが古いNode.jsのまま残り、後日再開したタイミングで起動しない、というケースは実務で起こりがちです。

移行時に失敗しやすいポイント

Node.jsの機能差分を軽く見てしまう

Node.js 18から22、24へ上げると、ランタイムの標準API、依存パッケージ、トランスパイル設定、ESM/CommonJSの扱いで差が出ることがあります。特にTypeScript、Webpack、esbuild、Prisma、sharp、bcrypt、Playwrightなど、ビルドやネイティブバイナリに関係するパッケージは注意が必要です。

移行後は最低限、次を実行してください。

node -v
npm ci
npm test
npm run build

本番相当の検証では、HTTPトリガーだけでなく、Timer、Queue、Service Bus、Event Hub、Blobトリガーなど、実際に使っているトリガー単位で動作確認します。

Azure側だけ変えてCIを更新しない

Azure Functionsの実行環境をNode.js 22に変えても、CIがNode.js 18のままだと、テスト結果の信頼性が落ちます。逆にCIだけNode.js 24で通っても、本番がNode.js 22なら、本番で使えないAPIをうっかり使う可能性があります。

対策はシンプルです。本番のNode.jsメジャーバージョンをCIの必須テストに入れ、次期候補バージョンは追加テストとして入れます。

Linux ConsumptionでNode.js 24を前提にする

Linux Consumptionプランでは、Node.js 22が最後のサポート対象とされています。Node.js 24へ進めたい場合は、コードの移行だけでなく、ホスティングプランの移行も検討が必要です。Flex Consumptionへの移行では、既存アプリの横に新しいアプリを作り、テスト後に切り替える流れが説明されています。(Microsoft Learn)

Windowsの32bit設定を見落とす

WindowsでNode.js 24を使う場合は、64bitプロセスの有効化が重要です。32bitプロセスのままだと、Node.js 24のバイナリが見つからず、Function Hostが正常起動しない可能性があります。(Azure)

プログラミングモデルv3/v4を混在させる

Node.jsのプログラミングモデルv4へ移行する場合、v3のfunction.jsonベースの関数とv4のコード中心の登録方式を同一Function Appで混在させないでください。Microsoft Learnでは、v4関数を登録するとv3のfunction.json関数が無視されると説明されています。(Microsoft Learn)

推奨する移行シナリオ

Node.js 18で本番運用している場合

最優先で移行計画を作ります。移行先は、安定性を重視するならNode.js 22を基本にします。Node.js 24はPreview扱いのため、本番で使う場合は社内のPreview利用基準、SLA要件、障害時の切り戻し方法を確認してから判断します。Azure Functionsの公式対応表ではNode.js 24はPreview、Node.js 22はGAとして掲載されています。(Microsoft Learn)

おすすめの流れは次のとおりです。

フェーズ作業
事前確認Node.js 18利用アプリ、CI、依存パッケージを洗い出す
ローカル検証Node.js 22でnpm ci、テスト、ビルドを通す
CI更新Node.js 22を必須テストに追加し、18を削除
ステージング展開スロットまたは別Function Appで検証
本番切替低トラフィック時間帯に設定変更またはスワップ
監視Application Insights、ログ、エラー率、処理遅延を確認

Node.js 20で運用している場合

Node.js 20は、Azure Functionsのサポート表ではGAとして掲載されつつ、期待サポート終了日が2026年4月30日とされています。新規開発や長期運用の移行先としてNode.js 20を選ぶメリットは小さいため、Node.js 22以上への移行を前提にしてください。(Microsoft Learn)

Node.js 22で運用している場合

すぐに大きな変更が必要とは限りません。ただし、CIにNode.js 24を追加して将来の互換性を確認する価値はあります。ライブラリや共通部品を開発しているチームでは、Node.js 24を追加テストに入れることで、将来の移行コストを下げられます。

Node.js 24を検討している場合

Node.js 24はNode.js公式ではLTSラインですが、Azure Functions側ではPreviewとして扱われています。業務影響が大きいFunction Appでは、Node.js 22で安定運用しつつ、Node.js 24は検証環境や低リスクなアプリから試すのが安全です。Windowsでは64bitプロセス、Linuxではホスティングプランの制約を必ず確認してください。(Microsoft Learn)

Node.js 26を検討している場合

Node.js 26は公式PRのCIテスト対象には追加されていますが、これは早期互換性検証の意味合いが強いと考えるべきです。Node.js公式では、Node.js 26はリリース時点でCurrentであり、LTS入りまでは評価期間です。Azure Functionsの本番ランタイムとして使う前提で設計するのではなく、ライブラリや共通コードの将来互換性確認に使うのが現実的です。(Node.js)

展開時のチェックリスト

本番展開前に、次の項目を確認してください。

チェック項目確認方法
Node.js実行バージョンFunction内でprocess.versionをログ出力
Azure FunctionsランタイムFUNCTIONS_EXTENSION_VERSIONが~4
ワーカーランタイムFUNCTIONS_WORKER_RUNTIME=node
Windows設定WEBSITE_NODE_DEFAULT_VERSIONと64bitプロセス
Linux設定linuxFxVersionとホスティングプラン
CI本番Node.jsバージョンでテストが通る
依存パッケージnpm ciで再現性がある
トリガー実利用トリガーごとに動作確認
監視Application Insightsで例外、失敗率、遅延を見る
切り戻しスロット、設定値、旧デプロイパッケージを準備

移行後は、少なくとも次のような観点でログを確認します。

app.http('versionCheck', {
  methods: ['GET'],
  authLevel: 'function',
  handler: async (request, context) => {
    context.log(`Node.js version: ${process.version}`);
    return { body: `Node.js version: ${process.version}` };
  }
});

このような簡単な確認エンドポイントを検証環境に用意しておくと、Azure側の設定変更が実際に反映されたかを素早く確認できます。本番で公開する場合は、認証レベルや削除タイミングを決めておきましょう。

今回の更新から取るべき次のアクション

今回のAzure Functions documentation updateで最も重要なのは、Node.js 18を前提にした開発・検証・運用を終わらせるタイミングが来ているということです。公式リポジトリのCIはNode.js 18を外し、Node.js 24/26を見据えた検証へ進んでいます。(GitHub)

今日やるべきことは、次の3つです。

  • Function AppとCIにNode.js 18が残っていないか棚卸しする
  • 本番移行先はNode.js 22を基本にし、Node.js 24はPreview利用の条件を確認する
  • Windows、Linux、Linux Consumption、Flex Consumptionの違いを踏まえて設定と展開方法を見直す

CIのNode.jsバージョン更新は小さな変更に見えますが、実際にはサポートライフサイクル、セキュリティ、依存パッケージ、ホスティングプランを横断する運用課題です。Node.js 18が残っている環境は、まず検証環境でNode.js 22へ上げ、CIとAzure Functionsの実行設定をそろえるところから始めてください。

Azure
CI/CD サーバーレス Node.js Azure Functions

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次