Azure FunctionsでNode.js 24のサポートが一般提供（GA）になりました。結論から言うと、Node.js 24でローカル開発した関数アプリを、Linux／Windowsの対応プランへ本番展開しやすくなった更新です。特にFlex Consumptionプランも対象に含まれるため、今後Node.js 20以前から移行するチームや、新規のサーバーレスAPIを構築する開発者にとって重要な変更です。(Microsoft Azure)
ただし、「バージョンを24に上げれば終わり」ではありません。Windowsでは64bitプロセスの確認、Linux Consumptionではプラン選定、Flex ConsumptionではRemote Buildの展開状況、CI/CDではビルド環境と依存パッケージの互換性を確認する必要があります。この記事では、Azure FunctionsのNode.js 24対応で何が変わるのか、管理者・開発者が確認すべき設定、移行時に失敗しやすいポイントを実務目線で整理します。
Azure FunctionsのNode.js 24対応で何が変わったのか
今回の更新により、Azure FunctionsでNode.js 24を使ったアプリ開発とデプロイがGA扱いになりました。公式情報では、Node.js 24をローカルで使って開発し、Linux／Windowsの対応するAzure Functionsプランへデプロイできると案内されています。Flex Consumptionプランも対象に含まれます。(Microsoft Azure)
Azure Functionsの対応言語一覧では、Node.js 24はGA、想定サポート終了日は2028年4月30日とされています。Node.js 22もGAですが、想定サポート終了日は2027年4月30日です。長めの保守期間を見込んで新規開発するなら、Node.js 24を優先候補にできます。(Microsoft Learn)
| 項目 | 変更内容 | 実務上の意味 |
|---|---|---|
| サポート状態 | Node.js 24がGA | 本番利用の候補にしやすくなった |
| 対応OS | Linux／Windowsの対応プラン | 既存構成に合わせて移行を検討できる |
| Flex Consumption | 対応対象に含まれる | 新しいサーバーレス構成でNode.js 24を採用しやすい |
| Remote Build | Flex Consumption向けNode.js 24のRemote Buildは順次展開 | 展開直後はリージョン差に注意が必要 |
| サポート期限 | Node.js 24は2028年4月30日予定 | Node.js 22より長期運用に向く |
特に注意したいのは、Node.js 24対応が「すべての古いホスティング構成をそのまま救済する」という意味ではない点です。Microsoft Learnでは、Linux Consumptionプランで追加されるNode.jsの最終バージョンはNode.js 22であり、それ以降の新しいNode.jsバージョンはLinux Consumptionに追加されないと説明されています。Linux Consumptionを使っている場合は、Flex Consumptionなど別プランへの移行も検討対象になります。(Microsoft Learn)
影響を受ける利用者と確認すべきポイント
今回の更新で最も影響を受けるのは、Node.jsでAzure Functionsを運用しているチームです。新規開発よりも、既存アプリのアップグレード時に設定差分やデプロイ方式の違いが表面化しやすくなります。
| 対象 | 確認すべきこと | 判断の目安 |
|---|---|---|
| 新規にNode.js関数を作る開発者 | Node.js 24、Functionsランタイムv4、プログラミングモデルv4を前提にする | 長期運用するならNode.js 24を第一候補にする |
| Node.js 20以前を利用中のチーム | サポート状況、依存パッケージ、CI/CDのNodeバージョン | 早めにNode.js 22または24へ移行計画を作る |
| Linux Consumption利用者 | Node.js 24を使えるプランか | Flex Consumption、Premium、Dedicatedなどを比較する |
| Windows利用者 | 64bitプロセスが有効か | 32bitのままだとNode.js 24で起動失敗する可能性がある |
| Flex Consumption利用者 | Remote Buildのリージョン展開状況 | 本番前に対象リージョンで実デプロイを検証する |
| 管理者・SRE | スロット、ローリング更新、監視、ロールバック | デプロイ中断やコールドスタート影響を事前に評価する |
Node.js 24へ移行する場合は、Azure Functions側のランタイムだけでなく、package.json、Azure Functions Core Tools、GitHub ActionsやAzure PipelinesのNode.jsバージョン、ネイティブ依存パッケージまで一体で確認する必要があります。sharp、bcrypt、canvas、データベースドライバーのようにネイティブバイナリを含むパッケージは、ローカルでは動いてもAzure上で失敗することがあります。
Node.js 24対応で混同しやすい「ランタイム」と「プログラミングモデル」
Azure FunctionsのNode.jsでは、次の2つを分けて考える必要があります。
| 用語 | 意味 | 例 |
|---|---|---|
| Node.jsランタイム | JavaScriptコードを実行するNode.jsのバージョン | Node.js 24、Node.js 22 |
| Azure Functionsランタイム | Azure Functions全体の実行基盤 | Functions runtime 4.x |
| Node.jsプログラミングモデル | 関数の書き方、トリガー定義、@azure/functionsの利用方法 | v3、v4 |
Microsoft Learnでは、Node.jsのプログラミングモデルとAzure Functionsランタイムは別物であり、プログラミングモデルのバージョンは@azure/functions npmパッケージのバージョンと密接に関係すると説明されています。また、同じFunction App内でv3とv4のプログラミングモデルを混在できない点も明記されています。(Microsoft Learn)
Node.js 24を使う場合は、基本的にNode.jsプログラミングモデルv4を前提に考えるのが安全です。公式の対応表では、Node.jsプログラミングモデルv4がFunctions runtime 4.25以降とNode.js 24／22／20／18に対応しています。一方、v3モデルはfunction.jsonを使う従来型の構成です。(Microsoft Learn)
既存のv3モデルをそのまま上げると起きやすい問題
v3モデルの関数アプリで、Node.jsのバージョンだけを24へ上げようとすると、次のような問題が起きやすくなります。
| よくある問題 | 原因 | 対策 |
|---|---|---|
| 関数が一覧に出ない | v3とv4の構成が混在している | Function App単位でv4へ統一する |
| ローカルでは動くがAzureで失敗する | Core Tools、@azure/functions、Node.jsの組み合わせが古い | 開発環境とCIのバージョンをそろえる |
| デプロイ後にトリガーが認識されない | ビルド成果物やエントリーポイントの配置が不適切 | main、scriptFile、ビルド出力先を確認する |
| TypeScriptだけ失敗する | トランスパイル後のJavaScriptがデプロイされていない | npm run build後の成果物をデプロイ対象に含める |
移行時は、Function Appにv3関数とv4関数を混在させるより、検証用の新しいFunction Appを作成してv4モデルへ移す方が安全です。小さなHTTPトリガーから移し、Queue、Timer、Event Hubなど副作用のあるトリガーは最後に移行すると事故を減らせます。
管理者が最初に確認すべきAzure Functions設定
Node.js 24へ移行する前に、管理者は次の設定を確認してください。
| 確認項目 | 見る場所 | 推奨アクション |
|---|---|---|
| Functionsランタイム | Function Appの構成、アプリ設定 | ~4系で動いているか確認する |
| Node.jsバージョン | WindowsはWEBSITE_NODE_DEFAULT_VERSION、LinuxはlinuxFxVersion | Node.js 24に変更する前に検証環境で確認する |
| OSとプラン | Function Appの概要、App Service Plan | Linux Consumptionの場合はNode.js 24対象外に注意する |
| 64bitプロセス | Windowsの構成設定 | Node.js 24利用時は64bitを有効化する |
| デプロイ方式 | Deployment Center、CI/CD定義 | Flex ConsumptionはOne Deploy前提で確認する |
| 監視 | Application Insights、ログ、アラート | 移行前後のエラー率・実行時間を比較する |
Azure FunctionsのNode.jsバージョン設定は、WindowsとLinuxで異なります。WindowsではWEBSITE_NODE_DEFAULT_VERSIONアプリ設定、LinuxではlinuxFxVersionサイト設定を使います。Microsoft Learnでは、Node.jsのバージョンを上げる前に、Function Appが最新のAzure Functionsランタイムで動いていることを確認するよう案内されています。(Microsoft Learn)
Windowsでは64bitプロセスを必ず確認する
Windows上のAzure FunctionsでNode.js 24を使う場合は、64bitプロセスの有効化が重要です。日本マイクロソフトのPaaSサポートブログでは、Node.js 24のバイナリは64bitプロセス用に提供され、32bitプロセス用のパスには用意されていないと説明されています。32bitのままだと、Node Language Workerを起動できず、Functions Hostが正常起動しない可能性があります。(Azure)
Azure CLIで確認・変更する場合の例は次のとおりです。
az functionapp config set \
--resource-group <RESOURCE_GROUP_NAME> \
--name <FUNCTION_APP_NAME> \
--use-32bit-worker-process falseNode.js 24を指定するWindowsの例です。
az functionapp config appsettings set \
--resource-group <RESOURCE_GROUP_NAME> \
--name <FUNCTION_APP_NAME> \
--settings WEBSITE_NODE_DEFAULT_VERSION=~24Linuxの場合は、次のようにlinuxFxVersionを指定します。
az functionapp config set \
--resource-group <RESOURCE_GROUP_NAME> \
--name <FUNCTION_APP_NAME> \
--linux-fx-version "node|24"ただし、Linux ConsumptionプランではNode.js 24が追加対象ではない点に注意してください。Linux ConsumptionでNode.js 24を使いたい場合は、Flex Consumptionなど対応プランへの移行を検討します。(Microsoft Learn)
Flex ConsumptionでNode.js 24を使うときの注意点
Flex Consumptionは、従来の従量課金型の良さを残しつつ、仮想ネットワーク統合、インスタンスメモリサイズの選択、高速なスケールアウト、Always Readyインスタンスなどを利用できるLinuxベースのAzure Functionsホスティングプランです。Microsoft Learnでは、Azure Functionsの推奨サーバーレスホスティングプランとして説明されています。(Microsoft Learn)
Node.js 24対応により、Flex ConsumptionでもNode.js 24を選びやすくなりました。ただし、デプロイ方式には注意が必要です。Azure Functionsのデプロイ技術の説明では、Flex Consumptionで利用できるデプロイ技術はOne Deployのみとされています。アプリのコンテンツは、作成時に指定するデプロイ用のBlobコンテナーへアップロードされます。(Microsoft Learn)
Remote Buildはリージョン展開状況を確認する
今回の公式更新では、Flex ConsumptionにおけるNode.js 24のRemote Buildは順次展開中で、すべてのパブリックリージョンで利用可能になるまで一定期間があると案内されています。(Microsoft Azure)
そのため、GA直後に本番デプロイする場合は、対象リージョンで次の確認をしておくべきです。
| 確認内容 | 具体的な確認方法 | 失敗時の代替策 |
|---|---|---|
| Remote Buildが成功するか | 検証用Function Appへ同じCI/CDでデプロイ | Linuxビルドエージェントで事前ビルドしてデプロイ |
| 依存パッケージが解決されるか | npm ci、ビルドログ、起動ログを確認 | lockfileを更新し、Node.js 24対応版へ上げる |
| 関数が認識されるか | PortalのFunctions一覧、/admin/host/status、ログを確認 | ビルド出力先とエントリーポイントを見直す |
| 起動時間が悪化していないか | Application InsightsでCold startや実行時間を比較 | Always Ready、メモリサイズ、バンドルサイズを調整 |
Flex Consumptionは便利ですが、ネットワーク制限を強くした環境ではデプロイ経路も設計が必要です。Function AppやストレージアカウントをPrivate Endpointで保護し、パブリックアクセスを無効にしている場合、外部のCI/CDから直接デプロイできないことがあります。Microsoft Learnでは、このような構成ではAzure Pipelinesのセルフホステッドエージェント、GitHub Actionsのセルフホステッドランナー、VPN、ExpressRouteなど、仮想ネットワークへ到達できる経路が必要と説明されています。(Microsoft Learn)
開発者がNode.js 24移行前に確認すべきコードと依存関係
Node.js 24への移行で実際に問題になりやすいのは、Azure側の設定よりもアプリケーションコードと依存関係です。特に、古いSDK、CommonJS／ES Modulesの混在、ネイティブモジュール、テスト不足が原因で移行後に障害が起きます。
package.jsonを移行の起点にする
まずpackage.jsonを確認します。
{
"engines": {
"node": ">=24 <25"
},
"scripts": {
"build": "tsc",
"start": "func start",
"test": "npm test"
},
"dependencies": {
"@azure/functions": "^4.0.0"
}
}実際のバージョン指定はプロジェクトの検証結果に合わせますが、少なくとも次の点は確認してください。
| 確認項目 | 見るポイント |
|---|---|
@azure/functions | v4プログラミングモデルを使うなら対応バージョンへ更新する |
| Azure SDK | Node.js 24で警告や非互換が出ないか確認する |
| TypeScript | tsconfig.jsonの出力先とデプロイ対象が一致しているか |
| lockfile | package-lock.jsonやpnpm-lock.yamlをCIと一致させる |
| ネイティブ依存 | Linux上でビルドされるか、Remote Buildで解決されるか |
Node.js 24に上げるタイミングで、npm installではなくnpm ciをCI/CDで使うようにすると、ローカルと本番の依存関係差分を減らせます。依存関係の更新とNode.jsの更新を同時に大量に行うと原因切り分けが難しくなるため、先に依存パッケージを現行Node.jsで更新し、その後Node.js 24へ上げる流れが安全です。
ローカル検証で最低限見るべきログ
移行前のローカル検証では、単にHTTP 200が返るかだけでなく、Functions Hostの起動ログを確認します。
node -v
npm ci
npm run build
func start確認するポイントは次のとおりです。
| ログ・挙動 | 判断基準 |
|---|---|
node -v | v24.xになっている |
| Functions Host起動 | エラーなくトリガーが列挙される |
| HTTPトリガー | ローカルURLで期待するレスポンスが返る |
| Queue／Timerなど | トリガー登録がログに出る |
| 警告 | 非推奨API、SDK、依存パッケージの警告を記録する |
本番移行前には、Application Insightsで移行前後の失敗率、平均実行時間、依存サービス呼び出し、コールドスタート傾向を比較できる状態にしておくと、問題発生時に戻すべきか調整すべきか判断しやすくなります。
移行・展開のおすすめ手順
Node.js 24への移行は、既存アプリへ直接適用するのではなく、検証用環境で差分を固めてから本番へ反映するのが基本です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 現状把握 | Function App、OS、プラン、Node.js、Functionsランタイムを棚卸し | 対象アプリ一覧ができている |
| 移行方針決定 | Node.js 24へ上げるか、まずNode.js 22へ上げるか決める | サポート期限と依存関係リスクを比較済み |
| ローカル更新 | Node.js 24、Core Tools、依存パッケージを更新 | func startで正常起動する |
| 検証環境デプロイ | 本番と同じプラン・OSでデプロイ | トリガー認識、ログ、外部接続が正常 |
| 負荷・回帰テスト | 主要API、キュー処理、タイマー処理を確認 | エラー率・実行時間が許容範囲 |
| 本番展開 | スロット、ローリング更新、段階展開を使う | 監視しながら切り替え完了 |
| ロールバック確認 | 旧バージョンへ戻す手順を確認 | 戻し先と手順が明文化されている |
Azure Functionsのデプロイでは、プランによって更新時の挙動が異なります。Consumption、Elastic Premium、Dedicatedでは、デプロイ時に実行中の関数が終了される可能性があり、スロットを使った検証とスワップが推奨されます。Flex Consumptionも既定では再作成戦略を使いますが、ゼロダウンタイム向けのローリング更新を構成できます。(Microsoft Learn)
本番展開前のチェックリスト
| チェック | 内容 |
|---|---|
| ランタイム | Functions runtime v4で動作している |
| Node.js | 検証環境と本番環境でNode.js 24を指定している |
| Windows | 64bitプロセスが有効になっている |
| Linux | 対象プランがNode.js 24に対応している |
| Flex Consumption | One Deploy前提のCI/CDになっている |
| Remote Build | 対象リージョンで成功することを確認済み |
| 依存関係 | npm ciで再現可能なビルドになっている |
| TypeScript | ビルド成果物がデプロイ対象に含まれている |
| 監視 | Application Insightsで移行前後を比較できる |
| ロールバック | 旧パッケージ、旧スロット、旧設定へ戻せる |
Node.js 24へすぐ移行すべきケース、慎重に進めるべきケース
Node.js 24はGAになったため、新規開発では有力な選択肢です。ただし、すべての既存アプリを即日で移行すべきとは限りません。
| 判断 | 該当するケース | 進め方 |
|---|---|---|
| すぐNode.js 24を検討 | 新規開発、依存パッケージが新しい、Flex Consumptionを新規採用 | 最初からNode.js 24・v4モデルで作る |
| 段階移行が安全 | Node.js 20以前、古いSDK、v3モデル、複数トリガーがある | 検証環境でv4モデル化してからNode.js 24へ移行 |
| 先に設計見直し | Linux Consumptionで運用中、ネットワーク制限が強い、CI/CDが古い | プラン移行とデプロイ経路を先に決める |
| 慎重に検証 | ネイティブモジュール、重い画像処理、長時間処理がある | Linuxビルド環境と負荷テストを用意する |
特にLinux Consumptionを使っている場合は、Node.jsのバージョン更新だけでなく、ホスティングプランの将来性もあわせて見直すべきです。Microsoft Learnでは、Linux Consumptionプランは新しい言語バージョンが追加されず、ホスティングオプション自体も2028年9月30日に廃止予定とされています。(Microsoft Learn)
よくある質問
Node.js 24にすると既存のAzure Functionsは自動で更新されますか？
通常、既存アプリが自動的にNode.js 24へ切り替わるわけではありません。Function Appの構成、アプリ設定、CI/CD、package.json、ランタイムを確認し、検証したうえで変更します。自動更新を期待して放置すると、古いNode.jsのまま運用が続く可能性があります。
Node.js 22とNode.js 24のどちらを選ぶべきですか？
新規開発で依存関係に問題がなければ、サポート期間の長いNode.js 24を優先しやすいです。一方、既存アプリで依存パッケージのNode.js 24対応に不安がある場合は、まずNode.js 22へ上げてからNode.js 24を検証する段階移行も現実的です。Azure Functionsの対応表では、Node.js 24は2028年4月30日、Node.js 22は2027年4月30日が想定サポート終了日です。(Microsoft Learn)
Azure PortalだけでNode.js 24へ変更できますか？
WindowsのFunction AppではAzure Portalから変更できる場合がありますが、LinuxではCLIやデプロイ構成での管理が必要になるケースがあります。Microsoft Learnでは、WindowsはWEBSITE_NODE_DEFAULT_VERSION、LinuxはlinuxFxVersionでNode.jsバージョンを設定すると説明されています。(Microsoft Learn)
Flex ConsumptionでRemote Buildが失敗した場合はどうすればよいですか？
まず対象リージョンでRemote Buildが利用可能か確認します。GA直後はFlex Consumption向けNode.js 24のRemote Buildが順次展開中と案内されているためです。急ぎの本番展開では、LinuxのCIエージェントでnpm ciとビルドを実行し、実行可能な成果物をOne Deployで展開する方法を検討します。(Microsoft Azure)
まとめ：Node.js 24対応は「設定・プラン・CI/CD」まで含めて確認する
Azure FunctionsのNode.js 24対応GAは、Node.jsベースのサーバーレスアプリを長期運用しやすくする重要な更新です。新規開発ではNode.js 24とNode.jsプログラミングモデルv4を前提に設計し、既存アプリでは現在のNode.jsバージョン、Functionsランタイム、ホスティングプラン、デプロイ方式を棚卸ししてから移行するのが安全です。
最初に行うべきことは、対象Function Appの一覧化です。次に、Windowsなら64bitプロセス、Linuxなら対応プラン、Flex ConsumptionならRemote BuildとOne Deploy、CI/CDならNode.js 24での再現可能なビルドを確認します。小さな検証環境で成功パターンを作ってから本番へ展開すれば、Node.js 24のメリットを取り込みつつ、移行トラブルを最小限に抑えられます。
コメント