Azure Functions の「Migrate to v4 of the Node.js model for Azure Functions」は、Node.js で作った Function App を v3 の function.json 中心の書き方から、v4 のコード中心の書き方へ移行するための変更です。単に Azure ポータルで Node.js のバージョンを切り替える作業ではありません。影響するのは、JavaScript または TypeScript の Azure Functions で、@azure/functions v3 系、または function.json でトリガーやバインドを定義しているアプリです。
特に注意すべき点は、同じ Function App の中で v3 と v4 の Node.js プログラミングモデルを混在できないことです。v4 の関数を1つでも登録すると、function.json で登録された v3 関数が無視されるため、部分移行のつもりが一部の関数だけ動かない、という事故につながります。公式ドキュメントでも、v4 は @azure/functions npm パッケージのバージョンと結び付いており、Azure Functions ランタイム v4 とは別物として扱う必要があると説明されています。(Microsoft Learn)
Azure の Migrate to v4 of the Node.js model for Azure Functions とは
「Migrate to v4 of the Node.js model for Azure Functions」は、Azure Functions の Node.js プログラミングモデルを v3 から v4 に移行するための公式ガイドです。
ここでいう v4 は、Azure Functions ランタイム v4 ではなく、Node.js 向けのプログラミングモデル v4 を指します。名前が似ているため混同しやすいですが、意味は異なります。
| 項目 | 意味 | 確認する場所 |
|---|---|---|
| Azure Functions ランタイム v4 | Functions ホスト全体の実行基盤 | Azure ポータル、FUNCTIONS_EXTENSION_VERSION |
| Node.js プログラミングモデル v4 | JavaScript / TypeScript で関数を書くためのモデル | package.json の @azure/functions |
| Node.js バージョン | 実行する Node.js の言語ランタイム | Windows は WEBSITE_NODE_DEFAULT_VERSION、Linux は linuxFxVersion |
v4 の大きな狙いは、Node.js 開発者にとって自然な書き方に近づけることです。具体的には、ファイル構成を柔軟にし、トリガーやバインドの設定を function.json ではなくコード内で定義できるようにします。(Microsoft Learn)
誰に影響するのか
影響を受けるのは、Azure Functions で Node.js、JavaScript、TypeScript を使っている開発者・管理者です。すべての Azure 利用者に影響する変更ではありません。
| 利用状況 | 影響 | 対応の優先度 |
|---|---|---|
| Node.js の Azure Functions を新規作成する | v4 モデルで始めるのが自然 | 中 |
既存アプリが function.json を使っている | コードの移行が必要 | 高 |
@azure/functions が v3 系または未記載 | 依存関係とコードの確認が必要 | 高 |
TypeScript で Context、AzureFunction 型を使っている | 型エラーや書き換えが発生しやすい | 高 |
| C#、Java、Python、PowerShell の Functions | この Node.js v4 モデル移行の直接対象外 | 低 |
| Azure Functions ランタイムだけを v4 にしている | Node.js モデル v4 移行とは別問題 | 要確認 |
管理者目線では、「Node.js のサポート期限が近いから Azure ポータルで Node.js バージョンだけ上げる」という対応だけでは不十分な場合があります。Node.js プログラミングモデルのバージョンは @azure/functions パッケージと結び付いており、v4 ではコード構造そのものが変わるためです。(Microsoft Learn)
v3 から v4 で変わる主なポイント
Azure Functions Node.js v4 モデルの変更は、見た目以上に実装へ影響します。特に、function.json、ハンドラー引数、context、HTTP リクエスト・レスポンスの扱いは必ず確認してください。
| 変更点 | v3 の考え方 | v4 の考え方 |
|---|---|---|
| 関数定義 | function.json でトリガーやバインドを定義 | app.http()、app.timer() などでコード内に定義 |
| ファイル構成 | 関数ごとの固定的な構成になりやすい | package.json の main で柔軟に指定 |
| npm パッケージ | @azure/functions は主に型定義用途 | 実行時にも必要な主要パッケージ |
| ハンドラー引数 | (context, req) の順序が一般的 | (request, context) の順序 |
| 入力の取得 | context.req、context.bindings も使えた | トリガー入力は第1引数で受け取る |
| 出力の設定 | context.res、context.bindings に設定 | 戻り値として返す |
| HTTP 型 | Azure Functions 独自色が強い | fetch 標準に近い API |
| ログ | context.log.error() など | context.error()、context.warn() など |
公式ドキュメントでは、v4 では function.json を維持する必要がなくなり、TypeScript または JavaScript ファイル内で関数を直接定義できると説明されています。HTTP トリガーなら app.http()、タイマートリガーなら app.timer() のように、トリガー種別に応じたメソッドで登録します。(Microsoft Learn)
移行前に確認すべきバージョン要件
v4 へ移行する前に、アプリ、ローカル環境、Azure 側のバージョンをそろえる必要があります。コードだけを書き換えても、Node.js や Functions Runtime が古いと正常に動作しない可能性があります。
| 確認項目 | v4 の主な要件 | 確認方法の例 |
|---|---|---|
@azure/functions | v4.0.0 以上 | package.json、npm list @azure/functions |
| Node.js | v18 以上 | node -v、Azure の構成 |
| Azure Functions Runtime | v4.25 以上 | Azure ポータルの Function runtime settings |
| Azure Functions Core Tools | v4.0.5382 以上 | func --version |
| TypeScript | v4 以上 | package.json、npx tsc -v |
公式ドキュメントでは、Node.js プログラミングモデル v4 の最小要件として、@azure/functions v4.0.0、Node.js v18 以上、Azure Functions Runtime v4.25 以上、ローカル実行時は Azure Functions Core Tools v4.0.5382 以上が示されています。TypeScript を使う場合は TypeScript v4 以上も確認対象です。(Microsoft Learn)
まず確認すべきファイル
移行対象かどうかを判断するには、最初に次のファイルを見ます。
package.json
host.json
local.settings.json
各関数フォルダーの function.json
各関数の index.js / index.ts
tsconfig.json特に package.json の @azure/functions と main、各関数フォルダーの function.json の有無が重要です。
v3 でよくある構成
MyFunctionApp
├─ HttpTrigger1
│ ├─ function.json
│ └─ index.ts
├─ TimerTrigger1
│ ├─ function.json
│ └─ index.ts
├─ host.json
├─ package.json
└─ tsconfig.jsonv4 で考えやすい構成
MyFunctionApp
├─ src
│ └─ functions
│ ├─ httpTrigger1.ts
│ └─ timerTrigger1.ts
├─ host.json
├─ package.json
└─ tsconfig.jsonv4 では、アプリのルートに必要なファイルは基本的に host.json と package.json です。どのファイルを読み込むかは package.json の main フィールドで指定します。(Microsoft Learn)
package.json で見るべき変更点
v4 では、@azure/functions を dependencies に含める必要があります。devDependencies に入っているだけでは、本番実行時に不足する可能性があります。
{
"main": "dist/src/functions/*.js",
"dependencies": {
"@azure/functions": "^4.0.0"
},
"devDependencies": {
"typescript": "^5.0.0"
}
}JavaScript の場合は、出力先に合わせて次のように指定できます。
{
"main": "src/functions/*.js",
"dependencies": {
"@azure/functions": "^4.0.0"
}
}TypeScript の場合は、実行されるのはコンパイル後の JavaScript です。そのため、main には src/**/*.ts ではなく、dist/**/*.js のようにビルド後のパスを指定します。
よくある失敗は、main を追加し忘れて「ローカルではファイルがあるのに関数が検出されない」状態になることです。v4 移行では、@azure/functions の更新と main の設定をセットで確認してください。
function.json はコード定義へ移す
v3 では、HTTP トリガーの設定は function.json に書くのが一般的でした。
{
"bindings": [
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
]
}v4 では、これをコードに移します。
import { app, HttpRequest, HttpResponseInit, InvocationContext } from '@azure/functions';
export async function httpTrigger1(
request: HttpRequest,
context: InvocationContext
): Promise<HttpResponseInit> {
context.log(`Request URL: ${request.url}`);
const name = request.query.get('name') || (await request.text()) || 'world';
return {
status: 200,
body: `Hello, ${name}`
};
}
app.http('httpTrigger1', {
methods: ['GET', 'POST'],
authLevel: 'anonymous',
handler: httpTrigger1
});ポイントは、トリガーや認証レベル、HTTP メソッドを app.http() のオプションで定義することです。function.json を残したままにすると、チーム内で「どちらが正なのか」が分かりにくくなります。移行後は、不要になった function.json を削除する方が保守しやすくなります。
ハンドラー引数は順序が変わる
v3 では、次のような書き方が多く使われていました。
const httpTrigger = async function (context, req): Promise<void> {
const name = req.query.name || req.body || 'world';
context.res = {
body: `Hello, ${name}`
};
};v4 では、トリガー入力が第1引数、context が第2引数になります。
export async function httpTrigger1(request, context) {
const name = request.query.get('name') || (await request.text()) || 'world';
return {
body: `Hello, ${name}`
};
}context を使わない処理なら、次のように省略することもできます。
export async function httpTrigger1(request) {
return {
body: 'Hello'
};
}この変更は単なる見た目の違いではありません。(context, req) のまま v4 に移すと、リクエストを context として扱ってしまい、実行時エラーや型エラーの原因になります。
context.res ではなく return で返す
v4 では、HTTP レスポンスなどのプライマリ出力は戻り値として返します。v3 のように context.res に代入する書き方を残すと、意図したレスポンスにならない可能性があります。
v3 の例
context.res = {
status: 200,
body: {
message: 'ok'
}
};v4 の例
return {
status: 200,
jsonBody: {
message: 'ok'
}
};JSON を返す場合は、body にオブジェクトを入れるよりも jsonBody を使う方が分かりやすく、Content-Type の扱いも整理しやすくなります。公式ドキュメントでも、v4 ではプライマリ出力を戻り値で設定する方法が示されています。(Microsoft Learn)
HTTP リクエストの扱いも変わる
v4 の HTTP 要求・応答型は fetch 標準に近い形になっています。v3 の感覚で req.query.name や req.body に直接アクセスしているコードは、移行時に見直しが必要です。
| 目的 | v3 でよくある書き方 | v4 の書き方 |
|---|---|---|
| クエリ文字列を読む | req.query.name | request.query.get('name') |
| ヘッダーを読む | req.headers['content-type'] | request.headers.get('content-type') |
| テキスト本文を読む | req.body | await request.text() |
| JSON 本文を読む | req.body | await request.json() |
| レスポンス本文を返す | context.res = { body: ... } | return { body: ... } |
| JSON を返す | context.res = { body: object } | return { jsonBody: object } |
移行で見落としやすいのは、本文の読み取りです。request.text()、request.json()、request.formData() のどれで読むかを、API の仕様に合わせて明確に決めてください。v4 では HTTP 型の使い方が変わるため、TypeScript を使っている場合はビルドエラーを移行漏れの検出に活用できます。(Microsoft Learn)
ログ出力の書き方も確認する
v4 では context オブジェクトが整理されています。ログ出力では、次のような違いがあります。
// v3 で見かける書き方
context.log.error('error');
context.log.warn('warning');// v4 の書き方
context.error('error');
context.warn('warning');
context.log('info');ログは移行後のトラブルシューティングで最初に見る場所です。関数本体だけでなく、共通エラーハンドラーやユーティリティ関数に古いログ API が残っていないかも確認してください。
移行手順の実務フロー
本番環境の Function App をいきなり書き換えるのではなく、次の順序で進めると安全です。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 対象アプリを棚卸しする | Node.js、function.json、@azure/functions の有無 |
| 2 | ブランチまたは検証環境を作る | 本番アプリを直接変更しない |
| 3 | @azure/functions を v4 系へ更新 | dependencies に入っているか |
| 4 | package.json に main を設定 | TypeScript は dist 側を見る |
| 5 | function.json の内容をコードへ移す | app.http()、app.timer() など |
| 6 | ハンドラー引数と context の使い方を修正 | (request, context)、戻り値で出力 |
| 7 | HTTP リクエスト・レスポンス処理を修正 | query.get()、jsonBody など |
| 8 | ローカルでビルド・実行 | npm run build、func start |
| 9 | ステージングへデプロイ | App Settings、接続文字列、監視を確認 |
| 10 | 本番切り替え | スロットスワップやメンテナンス時間帯を使う |
重要なのは、1つの Function App 内では全関数をまとめて v4 モデルにそろえることです。関数単位で少しずつ移行したい場合は、Function App 自体を分ける、ステージングスロットでまとめて検証する、などの方法を検討してください。
短時間で移行漏れを探すチェック方法
コードベースが大きい場合は、まず古い書き方を検索します。
macOS / Linux / WSL の例
grep -R "context.req\|context.res\|context.bindings\|context.done\|function.json" .PowerShell の例
Get-ChildItem -Recurse -Include *.js,*.ts,function.json |
Select-String "context\.req|context\.res|context\.bindings|context\.done"次の文字列が見つかった場合は、v4 移行時に優先して確認してください。
context.req
context.res
context.bindings
context.done
req.query
req.body
context.log.error
context.log.warn
function.json
AzureFunction
ContextTypeScript プロジェクトでは、型エラーを「壊れた」のサインではなく「移行漏れを見つける仕組み」として使うのが効果的です。Context や AzureFunction など v3 前提の型を使っている場所を、InvocationContext、HttpRequest、HttpResponseInit などへ置き換えていきます。
Azure ポータルや CLI で確認すべき設定
Node.js v4 モデルへの移行では、コードと Azure 側の設定を分けて確認します。
| 確認項目 | Windows の主な確認先 | Linux の主な確認先 |
|---|---|---|
| Node.js バージョン | WEBSITE_NODE_DEFAULT_VERSION | linuxFxVersion |
| Functions Runtime | FUNCTIONS_EXTENSION_VERSION | FUNCTIONS_EXTENSION_VERSION |
| Worker runtime | FUNCTIONS_WORKER_RUNTIME=node | FUNCTIONS_WORKER_RUNTIME=node |
| App Settings | Azure ポータルの構成 | Azure ポータルまたは CLI |
| デプロイスロット | Production / Staging | Production / Staging |
Azure Functions の Node.js バージョン更新は、Windows では WEBSITE_NODE_DEFAULT_VERSION、Linux では linuxFxVersion によって管理されます。Linux Consumption プランでは、Azure ポータルから Node.js バージョンを変更できないケースがあり、その場合は Azure CLI を使います。(Microsoft Learn)
Windows の例です。
az functionapp config appsettings set \
--name "<FUNCTION_APP_NAME>" \
--resource-group "<RESOURCE_GROUP_NAME>" \
--settings WEBSITE_NODE_DEFAULT_VERSION=~22Linux の例です。
az functionapp config set \
--name "<FUNCTION_APP_NAME>" \
--resource-group "<RESOURCE_GROUP_NAME>" \
--linux-fx-version "node|22"実際に指定できるバージョンは、リージョン、OS、プラン、提供時期によって変わる可能性があります。更新前に、次のコマンドでサポートされている値を確認してから変更してください。
az functionapp list-runtimes --os linux --query "[?runtime == 'node'].{Version:version, linuxFxVersion:linux_fx_version}" --output table料金はどう変わるのか
Node.js プログラミングモデル v4 へ移行すること自体に、専用の追加料金が発生するわけではありません。ただし、移行と同時にホスティングプラン、Node.js バージョン、インスタンス設定、Always Ready、監視設定などを変更すると、結果として料金が変わることがあります。
Azure Functions の料金確認では、次の項目を見ます。
| 確認項目 | 料金に影響する理由 |
|---|---|
| ホスティングプラン | Consumption、Flex Consumption、Premium、Dedicated で課金モデルが異なる |
| 実行回数 | サーバーレス系プランでは実行回数がコストに関係する |
| 実行時間 | 処理が長くなるほどコストが増えやすい |
| メモリ使用量 | Consumption 系ではメモリと実行時間の組み合わせが重要 |
| Always Ready / 事前ウォーム | 待機インスタンス分のコストが発生する場合がある |
| Application Insights | ログ・テレメトリ量が増えると監視コストが増える場合がある |
Consumption プランでは、実行回数、実行時間、メモリ使用量をもとに課金が決まります。Flex Consumption では、実行中のインスタンスのメモリや Always Ready インスタンスなども確認対象です。(Microsoft Learn)
移行後にコストが増えた場合は、v4 そのものよりも、次の変化を疑ってください。
- Node.js バージョン変更後に処理時間が伸びていないか
- 依存パッケージが増えてコールドスタートが悪化していないか
- ログ出力量が増えて Application Insights の取り込み量が増えていないか
- Flex Consumption や Premium へ移行して Always Ready / 事前ウォームを有効にしていないか
- リトライや失敗が増えて実行回数が増えていないか
期限・サポートで確認すべきこと
「v4 にいつまでに移行すべきか」は、単一の期限だけで判断しない方が安全です。Node.js のサポート期限、Azure Functions ランタイムのサポート、利用しているホスティングプランの方針を分けて確認します。
2026年6月時点の公式情報では、Azure Functions の Node.js 24 は GA で、想定サポート終了日は 2028年4月30日、Node.js 22 は GA で、想定サポート終了日は 2027年4月30日とされています。また、Linux Consumption プランでは Node.js 22 が最後の対応 Node.js バージョンであり、それより新しい Node.js バージョンは追加されないとされています。(Microsoft Learn)
| 見るべき期限 | 何を意味するか | 実務上の対応 |
|---|---|---|
| Node.js のサポート期限 | 言語ランタイムの更新・セキュリティ対応に関係 | Node.js 22 / 24 などサポート中の版へ移行 |
| Functions Runtime のサポート | Function App の実行基盤に関係 | FUNCTIONS_EXTENSION_VERSION を確認 |
| Linux Consumption の方針 | 新しい言語バージョンの利用可否に関係 | 必要なら Flex Consumption などを検討 |
| npm パッケージの互換性 | アプリのビルド・実行に関係 | package-lock.json も含めて検証 |
| Azure SDK の対応 Node.js | SDK 更新時の警告やインストール失敗に関係 | SDK と Node.js の両方を確認 |
期限対応では、「Node.js だけを上げる」「Functions Runtime だけを上げる」「@azure/functions だけを上げる」を別々の作業として扱うと漏れが出やすくなります。実務では、Node.js バージョン、@azure/functions、Functions Runtime、ホスティングプランを1枚の棚卸し表にまとめてから、優先度を付けるのがおすすめです。
よくある失敗と対処法
| 失敗しやすいポイント | 起きること | 対処法 |
|---|---|---|
| v3 と v4 を同じ Function App で混在させる | v3 の function.json 関数が無視される | Function App 単位で移行計画を立てる |
@azure/functions を devDependencies に入れたままにする | 本番実行時にモジュール不足になる | dependencies に移す |
main を設定し忘れる | 関数が検出されない | ビルド後の JS パスを main に指定 |
TypeScript の main が src/*.ts を見ている | Azure 上で読み込めない | dist/**/*.js を指定 |
context.res を残す | レスポンスが返らない、型エラーになる | return { ... } に変更 |
req.query.name を残す | クエリが取れない | request.query.get('name') に変更 |
context.log.error() を残す | ログ出力でエラーになる可能性 | context.error() に変更 |
| Node.js バージョンだけ上げる | コードの v4 化が進まない | package とコードも確認 |
| 本番で直接更新する | 再起動や失敗時の影響が大きい | ステージングスロットや検証環境を使う |
特に本番 API として使っている HTTP トリガーでは、移行後にステータスコード、レスポンスヘッダー、JSON 形式が変わっていないかを確認してください。内部処理が動いていても、クライアント側から見るとレスポンス形式の微妙な違いが障害になることがあります。
管理者向けの確認チェックリスト
開発者ではなく Azure 管理者として確認する場合は、次の観点で棚卸しすると判断しやすくなります。
- 対象サブスクリプション内に Node.js の Function App があるか
- Runtime stack が Node.js の Function App を一覧化したか
- Windows / Linux、Consumption / Flex Consumption / Premium / Dedicated を確認したか
- Node.js 18、20 など古いバージョンが残っていないか
FUNCTIONS_EXTENSION_VERSIONが~4か- Linux Consumption を使っているアプリがないか
package.jsonの@azure/functionsバージョンを開発チームに確認したか- ステージングスロットまたは検証環境があるか
- Application Insights で移行前後のエラー率・実行時間・失敗回数を比較できるか
- 移行後のロールバック手順が決まっているか
管理者だけでは package.json やソースコードの中身を判断できないことがあります。その場合は、開発チームへ「Node.js バージョン」ではなく、「Node.js プログラミングモデル v3 / v4 のどちらか」を確認するのが重要です。
開発者向けの移行チェックリスト
開発者は、次の順番で作業すると漏れを減らせます。
@azure/functionsを v4 系に更新する@azure/functionsがdependenciesにあることを確認するpackage.jsonにmainを追加するfunction.jsonの定義をapp.http()などへ移す(context, req)を(request, context)に変更するcontext.req、context.res、context.bindingsを置き換える- HTTP の
query、headers、bodyの読み方を修正する - JSON レスポンスは
jsonBodyを検討する - TypeScript の型を
InvocationContext、HttpRequest、HttpResponseInitへ見直す npm run buildとfunc startでローカル検証する- Azure 上のステージング環境で実際のトリガーを動かす
- Application Insights で例外と失敗率を確認する
v4 移行は「npm パッケージを上げれば終わり」ではありません。トリガー定義、入出力、HTTP API、型、デプロイ設定まで含めた小さなリファクタリングとして扱う方が安全です。
移行の判断基準
すぐに v4 移行へ進めるべきケースは、次のようなアプリです。
| 状況 | 判断 |
|---|---|
| Node.js 22 / 24 への更新を予定している | v4 モデルへの移行も同時に計画する |
function.json が多数ある | 早めに棚卸しして移行工数を見積もる |
| TypeScript の型エラーが多く出そう | 小さな Function App から検証する |
| API として外部公開している | ステージングとリグレッションテストを必ず用意する |
| Linux Consumption を使っている | Node.js バージョンとプラン方針を早めに確認する |
| Durable Functions を使っている | 一般の v4 移行に加えて Durable Functions 固有の移行も確認する |
逆に、Node.js を使っていない Function App や、すでに @azure/functions v4 系でコード定義に移行済みのアプリは、今回の変更による直接的な修正は少ない可能性があります。ただし、Node.js のサポート期限や Azure Functions のホスティングプラン方針は別途確認してください。
まとめ：v4 移行は「設定変更」ではなく「コード移行」として扱う
Azure Functions の「Migrate to v4 of the Node.js model for Azure Functions」は、Node.js アプリの書き方を v4 モデルへ移すための重要な変更です。最大のポイントは、function.json からコード中心の定義へ移り、@azure/functions、package.json の main、ハンドラー引数、context、HTTP 入出力の扱いを見直すことです。
最初にやるべきことは、対象の Function App が Node.js かどうか、function.json を使っているか、@azure/functions が何版かを確認することです。そのうえで、ステージング環境を用意し、1つの Function App 内の関数をまとめて v4 モデルにそろえてから本番へ反映してください。
Node.js のサポート期限や Linux Consumption の制約も絡むため、開発者だけでなく Azure 管理者も一緒に、コード・設定・料金・期限を同時に確認するのが安全です。
コメント