Azure Functionsで新しくサーバーレス構成を選ぶなら、まず確認すべきなのは「Azure Functions Flex Consumption plan hosting」です。Flex Consumptionは、従来の従量課金プランのようにスケールゼロと実行ベース課金を使いながら、仮想ネットワーク統合、関数ごとのスケーリング、インスタンスメモリ選択、Always-readyインスタンス、Azure Filesマウントなどを追加したLinuxベースのホスティングプランです。Microsoftは、新しいサーバーレスのAzure FunctionsではFlex Consumption planを推奨しています。(Microsoft Learn)
ただし、単に「従量課金プランの上位版」と考えると移行でつまずきます。Windows非対応、C# in-process非対応、デプロイスロット非対応、1プラン1アプリ、従来の一部アプリ設定の非推奨、リージョン別クォータなど、設計・IaC・CI/CDに影響する変更があるためです。この記事では、2026年5月時点の公式情報を基に、管理者と開発者が確認すべき変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。
Azure Functions Flex Consumption plan hostingの要点
Azure Functions Flex Consumption plan hostingは、Azure FunctionsをLinux環境でサーバーレス実行するためのホスティングプランです。従来のConsumption planと同じく、アイドル時はスケールゼロにでき、必要に応じてイベント駆動でスケールします。一方で、従来のConsumption planでは難しかったVNet統合やコールドスタート対策、メモリサイズの選択、より大きなスケールアウトに対応している点が大きな違いです。(Microsoft Learn)
まず押さえるべき結論は次の3つです。
- 新規のサーバーレスAzure Functionsでは、原則としてFlex Consumption planを第一候補にする
- 既存のLinux Consumption planアプリは、廃止時期を見据えてFlex Consumptionへの移行計画を立てる
- 移行ではコードだけでなく、ランタイム、ネットワーク、デプロイ方式、IaC設定、クォータ、課金を確認する
特にLinux Consumption planは、2028年9月30日にホスティングオプションが廃止予定です。また、LinuxのConsumption planでv3ランタイムを使っている関数アプリは、2026年9月30日以降に停止するため、早めにv4ランタイムやFlex Consumptionへの対応を確認する必要があります。(Microsoft Learn)
従来のConsumption planと何が変わるのか
Flex Consumption planは、従来のConsumption planと同じ「使った分だけ支払う」サーバーレスの考え方を維持しながら、運用上の制御範囲を広げたプランです。主な違いは次のとおりです。(Microsoft Learn)
| 比較項目 | Flex Consumption plan | 従来のConsumption plan |
|---|---|---|
| OS | Linuxのみ | Windows対応。Linuxはレガシ扱い |
| スケールゼロ | 対応 | 対応 |
| 最大スケールアウト | 最大1,000インスタンス | Windowsは最大200、Linuxは最大100の扱い |
| VNet統合 | 対応 | Consumptionでは非対応 |
| コールドスタート対策 | Always-readyインスタンスを設定可能 | 専用のAlways-readyなし |
| スケーリング | 関数ごとのスケーリングに対応 | アプリ単位のスケールが中心 |
| メモリサイズ | 512MB、2,048MB、4,096MBから選択 | 選択制ではない |
| Azure Filesマウント | 対応 | 非対応 |
| デプロイスロット | 非対応 | 一部プランで利用可だがConsumptionでは制約あり |
| 既存アプリのインプレース移行 | 非対応 | 該当なし |
開発者にとっての大きなメリットは、HTTP関数、Blobトリガー、Durable Functionsなどの負荷特性に合わせてスケールや同時実行を調整しやすくなることです。管理者にとっては、VNet統合によりプライベートなAzureリソースへ接続しやすくなる一方、サブネット設計やリージョンクォータの確認が必須になります。
影響を受ける対象者
Flex Consumption planの影響は、新規開発だけに限られません。特に次の環境では、設定の棚卸しが必要です。
| 対象 | 影響 | まず確認すること |
|---|---|---|
| 新規でAzure Functionsを作るチーム | 推奨プランがFlex Consumption寄りになる | Windows依存やコンテナ要件がないか |
| Linux Consumption plan利用中のチーム | 将来的な廃止に備えた移行が必要 | ランタイム、リージョン、トリガー、デプロイ方法 |
| Windows Consumption plan利用中のチーム | 現時点では直接の廃止対象ではないが、Flex移行時はLinux化が必要 | Windows固有機能やPowerShellモジュール依存 |
| IaCでFunction Appを作成している管理者 | functionAppConfig中心の設定に見直しが必要 | 非推奨アプリ設定やsiteConfigの使用有無 |
| CI/CDパイプライン管理者 | パッケージ配置、ストレージ認証、スロット非対応への対応が必要 | ZIPデプロイ、Blob配置、RollingUpdateの要否 |
| ネットワーク管理者 | VNet統合時にサブネット委任やIP設計が必要 | Microsoft.App/environments委任、サブネットサイズ |
既存のConsumption planからFlex Consumptionへ移行する場合、既存アプリをそのままプラン変更するインプレース移行はできません。新しいFlex Consumption planの関数アプリを作成し、コードを再デプロイしてから切り替える流れになります。(Microsoft Learn)
管理者が確認すべき設定ポイント
リージョンとクォータ
Flex Consumption planは多くのAzureリージョンで利用できますが、すべてのリージョンに対応しているわけではありません。アプリ作成前に、対象リージョンがFlex Consumptionに対応しているかを確認します。公式ドキュメントでは、Azure CLIで対応リージョンを確認する方法が案内されています。(Microsoft Learn)
az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o tableもう一つ重要なのが、リージョン別のサブスクリプションクォータです。Flex Consumptionでは、同じサブスクリプション・同じリージョン内のFlex Consumptionアプリがコンピューティングクォータを共有します。既定では250コア相当が目安で、Always-readyインスタンスもクォータにカウントされます。スケールゼロ中のアプリや削除予定のインスタンスはカウントされません。(Microsoft Learn)
| インスタンスメモリ | コア目安 | 250コアで到達するインスタンス数の目安 |
|---|---|---|
| 512MB | 0.25コア | 1,000インスタンス |
| 2,048MB | 1コア | 250インスタンス |
| 4,096MB | 2コア | 125インスタンス |
大量アクセスを受けるHTTP APIや、複数のFlex Consumptionアプリを同一リージョンに集約する構成では、「最大1,000インスタンスまでスケールできる」だけで判断しないことが重要です。サブスクリプション単位の合計クォータに達すると、実行やデプロイの遅延、スケーリングの抑制が起きる可能性があります。
VNet統合とサブネット設計
Flex Consumption planの大きな変更点は、サーバーレスのままVNet統合を使えることです。Key Vault、Storage、Service Bus、Event Hubsなどをプライベートネットワーク経由で利用したい構成では有力な選択肢になります。(Microsoft Learn)
ただし、VNet統合には次の条件があります。
| 確認項目 | 内容 |
|---|---|
| リソースプロバイダー | Microsoft.App の登録が必要 |
| サブネット委任 | Microsoft.App/environments が必要 |
| リージョン | 関数アプリとVNetは同一リージョンが必要 |
| サブネット名 | アンダースコア _ を含む名前は避ける |
| 共有制限 | Container Apps環境と同じサブネットは共有不可 |
| サブネット用途 | Private Endpoint、Service Endpoint、他サービス委任済みのサブネットは避ける |
サブネットサイズは、単一アプリなら/27、複数アプリや高スケール用途では/26が目安として示されています。特に複数のFunction Appが同じサブネットを共有し、同時に大量のアウトバウンド通信を行う場合、IP不足よりもネットワークスループットや依存サービスへの接続遅延がボトルネックになる可能性があります。(Microsoft Learn)
実務では、サブネットを小さく作りすぎないことが重要です。検証環境では問題が出なくても、本番負荷で外部API、Storage、DB、メッセージングサービスへの接続が増えると、タイムアウトやレイテンシ増加として現れます。Application Insightsで依存関係の応答時間を監視し、本番相当の負荷試験を行ってからサブネット設計を確定しましょう。
インスタンスメモリと同時実行
Flex Consumptionでは、インスタンスメモリを512MB、2,048MB、4,096MBから選択できます。公式ドキュメントでは、ほとんどのシナリオで2,048MBを既定として使い、処理内容に応じて512MBや4,096MBを選ぶ考え方が示されています。(Microsoft Learn)
| 選び方 | 向いているケース | 注意点 |
|---|---|---|
| 512MB | 軽量なHTTP API、短時間のイベント処理 | 同時実行やCPU負荷が高いと詰まりやすい |
| 2,048MB | 一般的な業務API、キュー処理、標準的なバッチ | まず試す基準にしやすい |
| 4,096MB | CPU・メモリを使う処理、重い変換処理、並列実行が多い処理 | インスタンスあたりのコストとクォータ消費が増える |
HTTPトリガーの同時実行数は、インスタンスメモリサイズに応じた既定値があります。必要に応じて、az functionapp scale config setでHTTPトリガーの同時実行数を明示的に設定できます。(Microsoft Learn)
az functionapp scale config set \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--trigger-type http \
--trigger-settings perInstanceConcurrency=10同時実行数を上げると、1インスタンスでより多くのリクエストを処理できます。一方で、処理がCPU集約型、メモリ集約型、外部API待ちの多い設計では、むやみに上げるとレスポンス遅延やタイムアウトが増えます。まずはApplication Insightsで実行時間、CPU負荷、依存関係の遅延、失敗率を確認しながら調整しましょう。
Always-readyインスタンスのコスト
Always-readyインスタンスは、常に待機しているインスタンスを確保し、コールドスタートを減らすための機能です。HTTP APIやユーザー操作に直結する関数では有効ですが、課金とクォータの両方に影響します。(Microsoft Learn)
たとえば、HTTPトリガーグループにAlways-readyを10個設定する場合は次のように指定します。
az functionapp scale config always-ready set \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--settings http=10注意したいのは、Always-readyにはオンデマンド実行のような無料枠が適用されない点です。ベースラインとして確保されたメモリ量、実行中のメモリ量、実行回数が課金対象になります。ユーザー向けAPIの初回応答を安定させる目的なら有効ですが、深夜や休日にほとんど呼ばれない処理へ安易に設定すると、コストだけが増える可能性があります。(Microsoft Learn)
開発者が確認すべきランタイムとコード上の注意点
Flex ConsumptionはLinuxベースのプランです。そのため、Windows固有のパス、OS依存のライブラリ、Windows専用PowerShellモジュール、フル.NET Framework依存がある場合は、そのまま移行できない可能性があります。特にC#では、in-processモデルがサポートされず、isolated worker modelへの移行が必要です。(Microsoft Learn)
2026年5月時点で確認すべき主なスタックは次のとおりです。
| スタック | Flex Consumptionでの確認ポイント |
|---|---|
| C# | isolated worker modelが必要。.NET 8、.NET 9、.NET 10など対応バージョンを確認 |
| Java | Java 8、11、17、21、25など、対象リージョンでの対応を確認 |
| Node.js | Node.js 20、22などの対応を確認 |
| Python | Python 3.10、3.11、3.12、3.13などの対応を確認 |
| PowerShell | PowerShell 7.4を確認。マネージド依存関係は非対応 |
| Custom handlers | 対応可否とバージョンを確認 |
対応ランタイムはリージョンや時期によって変わる可能性があるため、移行前にCLIで確認するのが安全です。(Microsoft Learn)
az functionapp list-flexconsumption-runtimes \
--location <REGION> \
--runtime <LANGUAGE_STACK> \
--query '[].{version:version}' -o tsvBlob Storageトリガーにも注意が必要です。Flex Consumption planではBlob StorageトリガーはEvent Gridソースのみをサポートします。また、C#以外の関数アプリでは、Extension Bundleのバージョン要件も確認する必要があります。(Microsoft Learn)
デプロイ方式の変更とCI/CDの注意点
Flex Consumption planのデプロイは、プロジェクトをビルドしてZIPなどのアプリケーションパッケージにし、Blob Storageコンテナーへ配置し、関数アプリが起動時にそのパッケージからコードを実行する方式です。既定では、AzureWebJobsStorageと同じストレージアカウントがデプロイコンテナーとして使われますが、別のストレージアカウントや認証方式も構成できます。(Microsoft Learn)
CI/CDで特に確認すべき点は次のとおりです。
| 項目 | 確認ポイント |
|---|---|
| デプロイストレージ | アプリごとに専用コンテナーを用意する |
| 認証方式 | 可能であればマネージドIDを使う |
WEBSITE_RUN_FROM_PACKAGE | Flex Consumptionでは使わない |
| デプロイスロット | 現在サポートされない |
| 診断 | Azure Portalの「Flex Consumption Deployment」診断ツールを活用する |
複数アプリで同じデプロイコンテナーを共有すると、パッケージが上書きされる可能性があります。環境ごと、アプリごとにコンテナーを分ける設計にしておくと、障害時の切り分けもしやすくなります。(Microsoft Learn)
Rolling Updateは便利だが本番適用は慎重に
Flex Consumptionでは、サイト更新戦略としてRecreateとRollingUpdateを選べます。既定はRecreateで、コードや設定の変更時に実行中インスタンスを再作成します。RollingUpdateは、インスタンスをバッチ単位で入れ替えることでゼロダウンタイムに近いデプロイを狙う方式ですが、公式ドキュメントではパブリックプレビューであり、本番アプリには推奨されていない点に注意が必要です。(Microsoft Learn)
| 更新戦略 | 向いているケース | 注意点 |
|---|---|---|
| Recreate | 短時間で確実に切り替えたい。短い停止を許容できる | 実行中の処理が中断される可能性がある |
| RollingUpdate | ダウンタイムを避けたい。実行中処理を完了させたい | プレビュー機能。後方互換性が必要。完了監視に制約がある |
RollingUpdateは、変更前後のコードが同時に動く時間帯があります。そのため、DBスキーマ変更、キューのメッセージ形式変更、Durable Functionsのオーケストレーション変更などでは、古いバージョンと新しいバージョンが同時に動いても破綻しない設計が必要です。破壊的変更を含む場合は、Recreateで短時間に切り替えるか、別のFlex Consumptionアプリを作ってトラフィック制御する方法を検討したほうが安全です。(Microsoft Learn)
IaCとアプリ設定で見落としやすい非推奨項目
Flex Consumption planでは、多くの従来アプリ設定やsiteConfigプロパティが非推奨または別設定に置き換えられています。ARM、Bicep、TerraformでFunction Appを作成している場合、既存テンプレートをそのまま流用すると意図した設定にならない可能性があります。(Microsoft Learn)
代表的な見直しポイントは次のとおりです。
| 従来の設定・プロパティ | Flex Consumptionでの考え方 |
|---|---|
FUNCTIONS_WORKER_RUNTIME | properties.functionAppConfig.runtime.nameへ移行 |
FUNCTIONS_WORKER_RUNTIME_VERSION | properties.functionAppConfig.runtime.versionへ移行 |
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT | maximumInstanceCountへ移行 |
FUNCTIONS_MAX_HTTP_CONCURRENCY | scale and concurrencyのtrigger設定へ移行 |
WEBSITE_RUN_FROM_PACKAGE | Flex Consumptionのデプロイでは使用しない |
WEBSITE_CONTENTSHARE | deploymentセクションへ移行 |
WEBSITE_VNET_ROUTE_ALL | Flex Consumptionのネットワーク設定では使用しない |
properties.containerSize | instanceMemoryMBへ名称変更 |
properties.siteConfig.preWarmedInstanceCount | alwaysReadyInstancesへ移行 |
properties.alwaysOn | Flex Consumptionでは無効 |
移行時は、ポータルで作ったFunction Appの設定を目視で合わせるだけでは不十分です。IaCテンプレート、GitHub Actions、Azure DevOps Pipeline、CLIスクリプト、環境別パラメータファイルまで確認してください。特にWEBSITE_RUN_FROM_PACKAGEやWEBSITE_CONTENTSHAREは、従来のAzure Functionsデプロイでよく使われていたため、無意識に残りやすい設定です。
移行前に実施すべきチェックリスト
既存のConsumption planアプリをFlex Consumptionへ移行する場合は、次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| アプリ棚卸し | OS、プラン、リージョン、ランタイム、トリガーを確認 | Windows依存や古いランタイムを見落とす |
| 対応リージョン確認 | Flex Consumption対応リージョンか確認 | 依存サービスと別リージョンになり遅延が増える |
| ランタイム確認 | C# isolated、Node、Python、Javaなどの対応を確認 | C# in-processのまま移行しようとする |
| ネットワーク確認 | VNet、サブネット委任、Private Endpoint構成を確認 | Microsoft.App/environments委任を忘れる |
| IaC更新 | functionAppConfigへ設定を移す | 非推奨アプリ設定が残る |
| デプロイ設計 | パッケージ配置、ストレージ認証、コンテナー分離を確認 | 複数アプリで同じデプロイコンテナーを共有する |
| スケール設計 | メモリ、同時実行、Always-ready、最大インスタンス数を確認 | クォータやAlways-readyコストを見落とす |
| 検証 | 負荷試験、依存サービス接続、ログ、失敗率を確認 | 開発環境だけで判断する |
| 切り替え | DNS、API Management、Front Doorなどで段階的に切り替え | ロールバック先を用意しない |
Linux Consumption planのアプリでは、az functionapp flex-migration listを使って移行候補と非対応理由を確認できます。Windows Consumption planの場合は、手動の確認・作成・構成が必要になるため、OS依存の洗い出しを先に行いましょう。(Microsoft Learn)
az functionapp flex-migration listFlex Consumptionを選ぶべきケース、避けるべきケース
Flex Consumption planは多くのサーバーレス用途に向いていますが、すべてのAzure Functionsに最適というわけではありません。判断基準は次のように整理できます。
| 判断 | 向いている・向いていない条件 |
|---|---|
| Flex Consumptionを選ぶべき | サーバーレス課金を維持したい、VNet統合が必要、負荷変動が大きい、コールドスタートを減らしたい、最大1,000インスタンス級のスケールが必要 |
| Premium planを検討 | 複数アプリを同一プランに載せたい、デプロイスロットを使いたい、常時稼働に近い、より大きなCPU・メモリ選択肢が必要 |
| Dedicated planを検討 | 既存App Service資産と同居したい、手動スケールや固定費にしたい、完全に予測可能な運用を重視する |
| Container Appsを検討 | 独自コンテナイメージ、特殊ライブラリ、マイクロサービス統合、コンテナ前提の運用が必要 |
| 従来のConsumptionを残す可能性 | Windows依存、フル.NET Framework、Windows固有機能がある |
Microsoft Learnのホスティング比較でも、新規のサーバーレスFunction AppではFlex Consumption planの利用が推奨され、Consumption planはレガシ扱いとして整理されています。一方で、Windows依存がある場合はConsumption planを使い続ける判断が必要になることもあります。(Microsoft Learn)
実務でのおすすめ移行方針
まずは、すべてのAzure Functionsを一括で移行しようとしないことです。失敗しにくい順番は、軽量なHTTP APIやキュー処理など、外部依存が少なく、Windows依存がないアプリからです。そこでFlex Consumptionのデプロイ、監視、コスト、クォータ、ネットワーク動作を確認し、標準テンプレートを作ってから本命アプリへ展開します。
移行の進め方は次の流れが現実的です。
- 既存Function Appを棚卸しする
- Linux Consumption planと古いランタイムを優先度高で抽出する
- Flex Consumption対応リージョンとランタイムを確認する
- BicepやTerraformのテンプレートをFlex Consumption用に更新する
- 新しいFlex Consumptionアプリを作成する
- デプロイストレージ、VNet、マネージドID、Application Insightsを設定する
- 同じコードを再デプロイし、負荷試験と依存サービス接続を確認する
- API Management、Front Door、DNSなどで段階的に切り替える
- 旧アプリを一定期間残し、問題がなければ停止・削除する
特に業務APIでは、移行直後の「動いた」だけで判断しないことが重要です。Flex Consumptionではスケールや同時実行の挙動が変わるため、ピーク時の依存サービス接続数、DBコネクション、Service BusやEvent Hubsの処理速度、Blobトリガーの動作を本番相当の負荷で確認してください。
まとめ：Flex Consumptionは新標準。ただし設定棚卸しが成功条件
Azure Functions Flex Consumption plan hostingは、従来のConsumption planの手軽さを残しながら、VNet統合、関数ごとのスケーリング、メモリサイズ選択、Always-ready、Azure Filesマウント、最大1,000インスタンスのスケールアウトなどを利用できる実用的なサーバーレスホスティングです。新規開発では、Windows依存やコンテナ要件がない限り、まずFlex Consumption planを検討する価値があります。
一方で、移行時は「コードを再デプロイすれば終わり」ではありません。Linuxのみ、C# in-process非対応、デプロイスロット非対応、1プラン1アプリ、リージョンクォータ、サブネット委任、非推奨アプリ設定など、運用設計に直結する確認項目があります。
次に取るべき行動は明確です。まず、既存のAzure Functionsをプラン別・OS別・ランタイム別に棚卸しし、Linux Consumption planと古いランタイムのアプリを優先的に抽出してください。そのうえで、Flex Consumption対応リージョン、ランタイム、VNet、IaC、デプロイ方式、Always-readyのコストを確認し、小さなアプリから移行検証を始めるのが安全です。
コメント