Azure Functions runtime v3 を Linux の Consumption plan で運用しているチームは、2026年9月30日までに runtime v4 へ移行し、本番同等のトリガー・依存サービス・コストを検証する必要があります。これは単なる「サポート終了のお知らせ」ではありません。Microsoft は、Linux Consumption 上で v3 runtime のまま動く Function App が 2026年9月30日以降に実行を停止すると案内しています。2026年4月18日時点では、まず対象アプリを洗い出し、v4移行、必要なら Flex Consumption への移行、負荷・監視・ロールバック計画まで一気通貫で進めるのが現実的です。(Microsoft Azure)
Azure Functions runtime v3 on Linux Consumption の何が変わるのか
今回のポイントは、Azure Functions runtime v3 の Linux Consumption 利用に最終的な停止期限が示されたことです。Azure Functions runtime 2.x / 3.x はすでにサポート対象外で、Microsoft Learn では「Azure Functions は現在 runtime host version 4.x のみをサポート」と説明されています。さらに、Linux の Consumption plan で end-of-life の v3 runtime を使う Function App は、2026年9月30日以降に停止すると明記されています。(Microsoft Learn)
ここで混同しやすいのが、2つの期限です。
| 期限 | 対象 | 何が起きるか | 今やるべきこと |
|---|---|---|---|
| 2026年9月30日 | Linux Consumption plan 上の Azure Functions runtime v3 | v3 のままでは Function App が停止する | runtime v4 へ移行し、本番検証を完了する |
| 2028年9月30日 | Linux Consumption plan での Function App ホスティング | Linux Consumption plan 自体がリタイア予定 | Flex Consumption など移行先プランを検討する |
つまり、2026年9月30日の対応は「v3をv4に上げる」ことが最優先です。ただし、Linux Consumption plan 自体も 2028年9月30日にリタイア予定であり、新しい機能や言語バージョンは追加されないため、単に延命するだけでなく Flex Consumption への移行計画も同時に持つべきです。Microsoft は新しいサーバーレス Function App には Flex Consumption plan を推奨し、既存の Consumption plan アプリも Flex Consumption へ移行するよう案内しています。(Microsoft Learn)
まず自社の Function App が対象か確認する
最初にやるべきことは、設計議論ではなく棚卸しです。対象アプリを見落とすと、2026年9月30日以降にバッチ、Webhook、キュー処理、APIバックエンドなどが突然止まる可能性があります。
特に確認すべき条件は次の3つです。
| 確認項目 | 対象になる条件 | 補足 |
|---|---|---|
| OS | Linux | Windows Consumption は今回の Linux Consumption v3 停止とは別扱い。ただし v3 はサポート対象外のため移行は必要 |
| ホスティングプラン | Consumption plan | Azure CLI では Dynamic と表示されることが多い |
| runtime | FUNCTIONS_EXTENSION_VERSION が ~3 または v3 固定 | v4移行対象。~4 への変更だけで済むとは限らない |
Azure CLI で Linux Consumption の Function App を一覧化する例です。
az functionapp list \
--query "[?contains(kind, 'linux') && sku=='Dynamic'].{name:name, resourceGroup:resourceGroup, location:location, kind:kind, sku:sku}" \
-o table各アプリの runtime 設定も確認します。
az functionapp config appsettings list \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--query "[?name=='FUNCTIONS_EXTENSION_VERSION' || name=='FUNCTIONS_WORKER_RUNTIME'].{name:name,value:value}" \
-o table大量の Function App がある場合は、サブスクリプション単位で「Linux Consumption」「runtime v3」「重要度」を付けて台帳化します。最低限、次の列を持つ一覧を作ってください。
| 台帳項目 | 記入例 | 判断に使う理由 |
|---|---|---|
| Function App名 | order-webhook-prod | 対象識別 |
| Resource Group / Subscription | rg-prod-serverless | 権限・IaC・課金確認 |
| Region | japaneast / eastus | Flex Consumption 対応リージョン確認 |
| runtime | ~3 | 2026年9月30日の停止対象判定 |
| 言語 | Node.js / Python / .NET / Java | 言語バージョン移行の影響確認 |
| トリガー | HTTP / Timer / Service Bus / Blob / Event Hubs | 切り替え時の重複実行・取りこぼしリスク確認 |
| SLA影響 | 高 / 中 / 低 | 移行順序とテスト深度の判断 |
| 移行方針 | v4のみ / v4 + Flex Consumption | 予算とスケジュールの分岐 |
移行方針は「v4だけ」か「Flex Consumptionまで」かで分ける
今回の期限だけを見ると、runtime v3 から v4 への移行が必須です。ただし、Linux Consumption plan 自体も将来的にリタイア予定のため、二度手間を避けたいチームは Flex Consumption まで含めて計画する価値があります。
| 方針 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| まず runtime v4 に上げる | 期限までの余裕が少ない、影響範囲が大きい、本番停止リスクを最小化したい | 2026年9月30日の停止リスクに集中できる | 2028年に向けてホスティングプラン移行が残る |
| runtime v4 + Flex Consumption へ移す | CI/CDやテスト環境が整っている、HTTP中心、または新規環境を作って切り替えやすい | 2026年と2028年の両方のリスクをまとめて減らせる | スロット、証明書、Blob trigger、スケール設定など差分確認が増える |
| Premium / Dedicated / Container Apps を検討する | 常時稼働、長時間処理、カスタムコンテナ、高いネットワーク要件がある | ワークロードに合わせた制御がしやすい | サーバーレス従量課金よりコスト構造が変わる |
Flex Consumption は、Linuxベースの Azure Functions ホスティングプランで、従量課金モデルを維持しながら、仮想ネットワーク統合、インスタンスメモリサイズ選択、より速いスケールアウト、always ready instances などを利用できます。Microsoft は Flex Consumption を Azure Functions の推奨サーバーレスホスティングプランとしています。(Microsoft Learn)
ただし、Flex Consumption には現時点で重要な制約もあります。C# in-process model はサポート対象外で、デプロイスロットも現在サポートされていません。Blob storage trigger では Event Grid source が前提になるなど、既存アプリによっては設計変更が必要です。(Microsoft Learn)
移行前に必ず動かすものを決める
Azure Functions の移行では、コードだけを見ていると失敗します。実際には、Function App の周辺にある設定、イベントソース、シークレット、監視、デプロイ方式まで含めて移す必要があります。
| 移すもの | 確認ポイント | よくある失敗 |
|---|---|---|
| runtime設定 | FUNCTIONS_EXTENSION_VERSION を v4 対応へ | ~4 に変えただけで依存パッケージが古く起動しない |
| 言語ランタイム | .NET / Node.js / Python / Java / PowerShell の対応バージョン | v3時代の古い言語バージョンを引きずる |
| バインディング拡張機能 | Storage、Service Bus、Event Hubs、Cosmos DB、Timer など | 拡張機能の破壊的変更を見落とす |
host.json | extension bundle、timeout、concurrency、logging | v4で必要な extension bundle バージョンに上がっていない |
| App settings | 接続文字列、環境変数、機能フラグ | 本番だけにある設定を移し忘れる |
| Managed Identity / RBAC | Key Vault、Storage、Service Bus、Cosmos DB への権限 | 新アプリのIDにロールがなく実行時エラーになる |
| ネットワーク | IP制限、Private Endpoint、VNet統合、CORS | 呼び出し元は変えていないのに通信が拒否される |
| デプロイ | GitHub Actions、Azure DevOps、Run From Package | 古い publish profile や zip deploy のまま失敗する |
| 監視 | Application Insights、アラート、ログクエリ | 移行後に失敗を検知できない |
| イベントソース | Queue、Service Bus、Event Hubs、Blob、Timer | 二重実行、取りこぼし、順序崩れが起きる |
Microsoft の v3 から v4 への移行手順でも、破壊的変更の確認、ローカルプロジェクトの移行、Azure Functions Core Tools v4 でのローカルテスト、Pre-Upgrade Validator の実行、Azure上の runtime 更新、再発行が推奨されています。(Microsoft Learn)
runtime v4 移行で見るべき実務ポイント
FUNCTIONS_EXTENSION_VERSION だけを先に変えない
Azure Functions の runtime は FUNCTIONS_EXTENSION_VERSION アプリ設定で制御されます。v4 の値は ~4 です。ただし Microsoft Learn でも、この設定を任意に変更せず、既存アプリでは移行手順に従うよう注意されています。(Microsoft Learn)
危険なのは、次のような進め方です。
az functionapp config appsettings set \
--settings FUNCTIONS_EXTENSION_VERSION=~4 \
-g <RESOURCE_GROUP_NAME> \
-n <APP_NAME>このコマンド自体は v4 へ更新する操作の一部ですが、コード、言語ランタイム、拡張機能、host.json、CI/CDを検証せずに本番で実行すると、起動失敗や一部トリガーの不発につながります。
本番で設定を変える前に、少なくとも次を終えてください。
- ローカルで Azure Functions Core Tools v4 による起動確認
- 対象言語のサポートバージョン確認
- バインディング拡張機能の更新
host.jsonの extension bundle 確認- Pre-Upgrade Validator の実行
- ステージング環境または新規 Function App での本番相当テスト
- ロールバック手順の文書化
.NET は in-process のまま残すかを慎重に判断する
.NET の Azure Functions を運用している場合は、v4移行と同時に execution model も確認してください。Microsoft Learn では、.NET in-process model のサポート終了が 2026年11月10日であること、完全なサポートのために isolated worker model への移行が推奨されることが示されています。(Microsoft Learn)
短期対応として in-process のまま v4 に上げる選択肢があっても、数か月後に再度移行が必要になる可能性があります。特に Flex Consumption では C# in-process model がサポートされないため、Flex Consumption まで視野に入れるなら isolated worker model への移行を前提に計画するのが安全です。(Microsoft Learn)
Node.js、Python、Javaも「動く」ではなく「今後使える」を見る
Linux Consumption plan では新しい言語バージョンが追加されない方針です。Microsoft Learn では、Linux Consumption plan で最後にサポートされる言語バージョンとして、.NET 9、Java 21、Node.js 22、PowerShell 7.4、Python 3.12 などが示されています。(Microsoft Learn)
たとえば「Node.js 18で動いているから大丈夫」ではなく、次の観点で見直します。
| 言語 | 見るべきこと |
|---|---|
| .NET | isolated worker model へ移るか、対象 .NET バージョンのサポート期限はいつか |
| Node.js / TypeScript | v4対応の Node.js バージョン、依存ライブラリ、ビルド成果物の互換性 |
| Python | Python バージョン、ネイティブ依存、ビルド方式、Linux上のパッケージ互換性 |
| Java | Java バージョン、Maven設定、FUNCTIONS_EXTENSION_VERSION の反映 |
| PowerShell | モジュールの互換性、実行ポリシー、依存モジュールの配置方法 |
Flex Consumption へ移す場合に追加で確認すること
Flex Consumption は単なる上位互換ではありません。スケール、デプロイ、ネットワーク、課金、制約が変わります。
スロットを使っている場合は移行戦略を変える
Consumption plan の Function App では deployment slot を持てる場合がありますが、Flex Consumption plan は現在 deployment slots をサポートしていません。既存環境でスロットを使って検証・切り替えをしている場合、Flex Consumption では別の Function App を非本番環境として用意し、API Management、Application Gateway、DNS、イベント購読など上流側で切り替える設計が必要です。(Microsoft Learn)
実務では、次のように切り替えます。
| 既存のやり方 | Flex Consumption移行後の代替 |
|---|---|
| deployment slot にデプロイして swap | 検証用 Function App を別名で作成し、上流ルーティングで切り替え |
| 本番スロットと検証スロットで同じURLを使う | API Management や Application Gateway でバックエンドを切り替え |
| スロット設定で本番値を分離 | Key Vault、App Configuration、環境別 App settings で分離 |
Blob trigger は Event Grid source を確認する
Flex Consumption では Blob storage trigger が Event Grid source を前提とするため、既存の Blob trigger がコンテナポーリング方式のままでは移行前に変更が必要です。Microsoft の移行ガイドでも、Blob trigger に source がない、または LogsAndContainerScan の場合は、Event Grid source へ変更する必要があると説明されています。(Microsoft Learn)
Blob trigger を使っているアプリでは、次を確認します。
az functionapp function list \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--query "[?config.bindings[0].type=='blobTrigger'].{Function:name,TriggerType:config.bindings[0].type,Source:config.bindings[0].source}" \
--output tableSource が空、または Event Grid でない場合は、Event Grid subscription の作成、イベント重複時の冪等性、既存コンテナの処理済みデータの扱いまで含めて設計します。
証明書、CORS、カスタムドメイン、認証設定を見落とさない
Flex Consumption 移行では、アプリ設定だけでなく、CORS、カスタムドメイン、HTTPバージョン、HTTPS only、TLS設定、クライアント証明書、IP制限、Managed Identity、RBAC なども確認対象です。Microsoft の移行ガイドでは、移行前に App settings、アプリ構成、Managed Identity、組み込み認証、受信アクセス制限を収集するよう案内されています。(Microsoft Learn)
特に、Key Vault や Storage へ接続文字列でアクセスしているアプリは、移行を機に Managed Identity + RBAC へ寄せると、シークレット管理の負荷を下げられます。Microsoft も、接続文字列の代わりに Microsoft Entra ID 認証と Managed Identity を使うことを推奨しています。(Microsoft Learn)
テストは「起動確認」では足りない
Azure Functions の移行テストでありがちな失敗は、HTTPの疎通確認だけで完了扱いにすることです。実際に止まりやすいのは、イベント処理、再試行、スケールアウト、認証、監視、コールドスタートです。
| テスト項目 | 具体的に見ること | 合格基準の例 |
|---|---|---|
| 起動テスト | Function Host が正常起動するか | 起動エラー、拡張機能エラー、依存DLL不足がない |
| HTTPテスト | APIレスポンス、認証、CORS、カスタムドメイン | 主要エンドポイントが本番同等の認証条件で成功 |
| イベントトリガー | Queue、Service Bus、Event Hubs、Blob、Timer | メッセージ取りこぼし、重複処理、順序問題が許容範囲内 |
| 冪等性 | 同じイベントを複数回処理しても破壊的副作用がないか | 二重請求、二重通知、二重登録が起きない |
| スケール | ピーク時の同時実行、インスタンス数、スロットリング | P95/P99がSLO内、失敗率が基準以下 |
| コールドスタート | アイドル後の初回応答 | ユーザー影響が許容範囲内。必要なら always ready を検討 |
| 監視 | Application Insights、ログ、アラート | 失敗、遅延、依存先エラーを検知できる |
| ロールバック | 旧アプリへ戻す、上流ルーティングを戻す | 手順書通りに短時間で戻せる |
Microsoft の Flex Consumption 移行ガイドでも、移行前後で同条件のベンチマークを取り、コールドスタート、スループット、P50/P95/P99 レイテンシを比較することが推奨されています。(Microsoft Learn)
トリガー別の切り替えリスクを先に潰す
HTTPだけの Function App は比較的移行しやすい一方、イベント駆動の Function App は慎重な切り替えが必要です。
| トリガー | 主なリスク | 移行時の対策 |
|---|---|---|
| HTTP | URL変更、認証、CORS、クライアント更新漏れ | API ManagementやDNSで切り替え、クライアント設定を一覧化 |
| Timer | 旧新アプリの同時実行 | 移行中は片方のTimerを無効化、スケジュールをずらす |
| Storage Queue | 二重処理、キュー取りこぼし | 新キューを用意し、送信元を段階的に切り替える |
| Service Bus | メッセージ重複、DLQ増加 | 新topic/queue、サブスクリプション、DLQ監視を設計 |
| Event Hubs | チェックポイント競合 | 新consumer groupを用意する |
| Cosmos DB Change Feed | lease競合、再処理 | 新lease container、StartFromBeginning の確認 |
| Blob | ポーリング方式からEvent Grid方式への変更 | Event Grid subscription、処理済みBlobの扱いを決める |
Microsoft の移行ガイドでも、Event Hubs では新しい consumer group、Cosmos DB では専用 lease container、Service Bus や Storage Queue では新しい queue/topic を使うなど、トリガー別の対策が示されています。(Microsoft Learn)
予算は実行料金だけで見積もらない
今回の移行で必要な予算は、Azure Functions の実行料金だけではありません。特に Flex Consumption へ移す場合、インスタンスメモリ、always ready instances、リージョンクォータ、並行稼働期間、監視ログ、負荷試験、ネットワーク構成まで含めて見積もる必要があります。
Flex Consumption の課金は、オンデマンド実行時の実行時間に加え、always ready instances を使う場合はその分のコストが発生します。Flex Consumption では 512MB、2048MB、4096MB のインスタンスメモリサイズを選べ、Microsoft は多くのシナリオで 2048MB を既定の選択肢として考えることを案内しています。(Microsoft Learn)
| 予算項目 | 見積もり観点 | 見落としやすいポイント |
|---|---|---|
| 開発工数 | 言語バージョン更新、依存パッケージ更新、テスト修正 | .NET isolated worker移行や古い拡張機能対応 |
| 検証環境 | 新 Function App、Storage、Service Bus、Cosmos DB、Key Vault | 本番相当のイベントソースを別途用意する費用 |
| 並行稼働 | 旧アプリと新アプリを一定期間同時運用 | メッセージ重複やログ量増加 |
| 負荷試験 | Azure Load Testingなどのツール、テストデータ作成 | ピーク時間帯に近い条件で測らないと意味が薄い |
| 監視 | Application Insights、Log Analytics、アラート | ログ量が増えるとコストが増える |
| Flex Consumption | 実行時間、メモリサイズ、always ready instances | コールドスタート対策で always ready を増やしすぎる |
| ネットワーク | VNet統合、Private Endpoint、API Management、Application Gateway | 段階的切り替えに上流ルーティングが必要になる |
| サポート | Microsoft サポート、外部レビュー、移行リハーサル | 期限直前は問い合わせが集中しやすい |
Flex Consumption では、サブスクリプションとリージョン単位で共有されるメモリ・コアのクォータも確認が必要です。Microsoft Learn では、既定のリージョン別クォータが 250 cores 相当であり、always ready instances もクォータに含まれると説明されています。大規模なスパイク処理を持つチームは、移行前にクォータ上限と引き上げ手順を確認しておくべきです。(Microsoft Learn)
2026年9月30日までの現実的な移行スケジュール
2026年4月18日から2026年9月30日までは165日です。大規模環境では長くありません。目安として、次のように逆算すると進めやすくなります。
| 時期 | やること | 完了条件 |
|---|---|---|
| 2026年4月〜5月 | 対象アプリの棚卸し、重要度分類、移行方針決定 | Linux Consumption + v3 の一覧が確定している |
| 2026年5月〜6月 | v4対応ブランチ作成、依存関係更新、ローカルテスト | Core Tools v4 で主要関数が起動・実行できる |
| 2026年6月〜7月 | 検証環境または新 Function App へデプロイ | App settings、Identity、ネットワーク、監視が再現できている |
| 2026年7月〜8月 | 負荷試験、トリガー別テスト、障害時テスト | P95/P99、失敗率、再試行、DLQ監視が基準内 |
| 2026年8月〜9月前半 | 本番切り替えリハーサル、ロールバック確認 | 手順書通りに切り替え・戻しができる |
| 2026年9月中旬まで | 本番移行完了 | 旧v3アプリに本番トラフィックやイベントが残っていない |
| 2026年9月30日 | 最終期限 | v3 Linux Consumption の本番依存がゼロ |
期限当日に切り替える計画は避けてください。Azure Functions の移行では、アプリ本体よりも上流・下流サービスの設定変更に時間がかかることがあります。特に、外部システムのWebhook送信先、顧客側のIP許可リスト、DNS変更、API Managementのバックエンド変更、Event Grid subscription の再作成は、関係者調整が必要になりがちです。
チーム別に今すぐやること
Cloud developers がやること
開発者は、まずコードと依存関係を v4 対応にします。
FUNCTIONS_EXTENSION_VERSIONだけでなく、プロジェクトファイルの Azure Functions version を確認する- 使用言語のサポートバージョンに上げる
- バインディング拡張機能を最新の安定版へ更新する
host.jsonの extension bundle を確認する- ローカルで Core Tools v4 による起動・実行テストを行う
- キュー、Blob、Service Bus、Event Hubs などの重複処理に備え、関数を冪等にする
- Application Insights のログ・メトリックで移行前後を比較できるようにする
Serverless platform owners がやること
プラットフォームオーナーは、アプリ単体ではなく、移行の型を作ります。
- サブスクリプション横断で v3 Linux Consumption を棚卸しする
- 重要度ごとに移行期限を前倒しで設定する
- v4のみ移行、Flex Consumption移行、Premium/Dedicated移行の判断基準を作る
- CI/CDテンプレート、IaC、Key Vault、Managed Identity、RBACの標準を更新する
- Flex Consumption の対応リージョン、クォータ、制約を確認する
- 負荷試験とロールバックの最低基準を定義する
- 2028年の Linux Consumption plan リタイアも含めたロードマップを作る
判断に迷ったときの基準
移行方針で迷ったら、次の基準で判断すると実務上の失敗を減らせます。
| 状況 | 推奨判断 |
|---|---|
| v3停止期限まで余裕がない | まず runtime v4 移行を優先し、Flex Consumption は次フェーズに分ける |
| HTTP中心で依存サービスが少ない | v4 + Flex Consumption を同時に進めやすい |
| Service Bus / Event Hubs / Cosmos DB Change Feed が中心 | 並行稼働・重複処理・チェックポイント設計を優先する |
| .NET in-process を使っている | isolated worker model 移行を含めて計画する |
| deployment slots に依存している | Flex Consumption移行時は別アプリ + 上流ルーティング方式を設計する |
| カスタム証明書や特殊なネットワーク要件がある | Flex Consumptionだけで足りるか、Premium/Dedicatedも比較する |
| コールドスタートがSLOに影響する | Flex Consumption の always ready instances または Premium を検討する |
最後に確認すべきチェックリスト
本番移行前に、次の項目がすべて「はい」になっているか確認してください。
| チェック | 確認内容 |
|---|---|
| 対象棚卸し | Linux Consumption + v3 の Function App をすべて特定した |
| コード移行 | runtime v4 対応のコード・依存パッケージ・host.json に更新した |
| ローカル検証 | Azure Functions Core Tools v4 で主要関数を実行した |
| Azure検証 | Pre-Upgrade Validator や検証環境で問題を潰した |
| 設定移行 | App settings、CORS、Identity、RBAC、ネットワーク、監視を再現した |
| トリガー検証 | HTTP以外のイベント処理で重複・取りこぼし・DLQを確認した |
| 性能検証 | コールドスタート、スループット、P95/P99を移行前後で比較した |
| 費用確認 | Flex Consumption、always ready、ログ、並行稼働、負荷試験の費用を見積もった |
| ロールバック | 旧アプリへ戻す手順、または上流ルーティングを戻す手順を確認した |
| 本番切替 | 2026年9月30日より前に、本番依存を v3 Linux Consumption から外した |
Azure Functions runtime v3 on Linux Consumption の停止対応は、後回しにすると「設定変更だけで済む移行」ではなくなります。まずは対象アプリを棚卸しし、v4移行を最優先で完了させてください。そのうえで、Linux Consumption plan の将来のリタイアを見据え、Flex Consumption へ移すか、Premium / Dedicated / Container Apps を選ぶかをワークロード単位で判断するのが、2026年以降の安全な進め方です。
コメント