Azure FunctionsでFlex Consumption PlanのFunction Appを作成・管理する場合、結論は「従来のConsumption Planと同じ感覚で作らない」ことです。新規作成、デプロイ、VNet統合、スケール、Always Ready、HTTP同時実行数、証明書、監視まで、Flex Consumption Plan専用の確認項目があります。特に既存アプリを移行する場合は、インプレース移行ではなく新しいFunction Appを作成してコードを再デプロイする前提で計画する必要があります。Microsoft Learnの該当ページは英語版で2026-05-18、日本語版で2026-05-20の最終更新表示があり、本記事では2026年5月19日前後の公式情報として整理します。(Microsoft Learn)
Azure FunctionsのFlex Consumption Planで何を確認すべきか
Azure Functionsの「Create and Manage Function Apps in a Flex Consumption Plan」は、Flex Consumption PlanでホストするFunction Appの作成方法と、作成後に変更できる主要設定をまとめた公式ドキュメントです。単なる作成手順ではなく、運用時に問題になりやすい設定が広く扱われています。(Microsoft Learn)
管理者・開発者がまず見るべきポイントは次のとおりです。
| 確認項目 | 重要な理由 | 実務での判断ポイント |
|---|---|---|
| リージョン対応 | Flex Consumption PlanはすべてのAzureリージョンで使えるとは限らない | 作成前にaz functionapp list-flexconsumption-locationsで確認する |
| ランタイム | C# in-processなど、サポート外の構成がある | .NETはisolated worker model前提で確認する |
| デプロイ方式 | Flex Consumptionでは.zipパッケージをBlob Storageコンテナーに配置する | Pythonや依存ライブラリが多い構成ではリモートビルドを使う |
| VNet統合 | サブネット要件と委任先がPremium/Dedicatedと異なる | /27以上、複数アプリや高負荷では/26を目安にする |
| スケール設定 | インスタンスメモリ、Always Ready、HTTP同時実行数で性能と費用が変わる | レイテンシ要件とコスト上限をセットで決める |
| 更新方式 | 既定のRecreateではデプロイ時に実行中処理が中断される可能性がある | ゼロダウンタイムが必要ならRollingUpdateの制約を確認する |
| 証明書 | Flex Consumptionではsite-scoped certificateモデルを使う | 証明書数、Key Vault連携、ファイルパス参照を確認する |
| 監視・コスト | Always Readyやメモリ設定により課金が変わる | Application Insights、Azure Monitor、Cost Managementを初期設定に含める |
Flex Consumption Planは、LinuxベースのAzure Functionsホスティングプランです。従来のConsumption Planと同じくサーバーレスの実行課金モデルを使いながら、VNet統合、インスタンスメモリ選択、Always Ready、関数単位のスケーリング、より大きなスケールアウトなどを利用できます。MicrosoftはFlex ConsumptionをAzure Functionsの推奨サーバーレスホスティングプランとして説明しています。(Microsoft Learn)
影響を受ける対象者
今回の公式情報は、新規にAzure Functionsを作る開発者だけでなく、既存のConsumption Planから移行を検討している管理者にも関係します。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | サブスクリプション権限、リージョン、クォータ、VNet、ストレージ、Cost Management |
| アプリ開発者 | ランタイム、依存ライブラリ、リモートビルド、HTTP同時実行数、証明書読み込み方法 |
| SRE・運用担当 | Application Insights、Azure Monitor、アラート、デプロイ時の中断、ロールバック手順 |
| セキュリティ担当 | マネージドID、Storage Blob Data Contributor、Key Vault、ストレージ公開設定 |
| 移行担当 | 既存プランからの新規作成・再デプロイ、スロット非対応、Blobトリガー、証明書再設定 |
特にLinux Consumption Planを使っている場合は、Microsoftが2028年9月30日にLinux Consumption PlanでのFunction Appホスティングを廃止予定としており、機能や言語の強化もLinux Consumption Planでは行われていないと説明しています。移行計画は余裕を持って始めるべきです。(Microsoft Learn)
新規Function App作成時の確認ポイント
Flex Consumption PlanのFunction Appを作成するには、少なくともリソースグループ、ストレージアカウント、Flex Consumption Plan上のFunction Appが必要です。Azure CLIをローカルで使う場合は、公式手順ではAzure CLI 2.60.0以降が前提とされています。(Microsoft Learn)
作成前に、まず対応リージョンを確認します。
az login
az functionapp list-flexconsumption-locations \
--query "sort_by(@, &name)[].{Region:name}" \
-o table次に、リソースグループとストレージアカウントを作成します。ストレージアカウント名はAzure Storage全体で一意で、数字と小文字のみの3〜24文字にする必要があります。公式手順では、ストレージアカウントへの不要なアクセスを制限することも重要事項として示されています。(Microsoft Learn)
az group create \
--name <RESOURCE_GROUP> \
--location <REGION>
az storage account create \
--name <STORAGE_NAME> \
--location <REGION> \
--resource-group <RESOURCE_GROUP> \
--sku Standard_LRS \
--allow-blob-public-access falseFunction App作成の基本形は次のようになります。
az functionapp create \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--storage-account <STORAGE_NAME> \
--flexconsumption-location <REGION> \
--runtime dotnet-isolated \
--runtime-version 8.0C#を使う場合、Flex Consumption PlanではC# in-processモデルがサポートされていません。既存の.NET Function Appを移行する場合は、isolated worker modelへの移行を先に確認してください。(Microsoft Learn)
Azure portalとVisual Studio Codeで作る場合の注意点
Azure portalでは、Function App作成時にホスティングオプションとして「Flex Consumption」を選び、リージョン、ランタイム、インスタンスサイズ、ストレージ、Application Insights、認証を指定します。公式手順では、認証タイプをマネージドIDにする選択肢も示されています。(Microsoft Learn)
Visual Studio CodeからもFlex Consumption PlanのFunction Appを作成できますが、すべての設定を作成時に指定できるわけではありません。たとえば、VNet統合、デプロイストレージ、インスタンスメモリ、Always Ready、HTTP同時実行数などは、Azure CLI、Azure portal、ARM/Bicepなどでの設定確認が必要になります。(Microsoft Learn)
デプロイ方式はBlob Storage上の.zipパッケージが前提
Flex Consumption Planのデプロイでは、プロジェクトコードと実行に必要なライブラリを含む.zipパッケージをBlob Storageコンテナーに配置します。既定ではAzureWebJobsStorageと同じストレージアカウントが使われますが、別のストレージアカウントや認証方式を指定することもできます。(Microsoft Learn)
既存のFunction Appへデプロイすると、そのアプリ内の内容は上書きされます。これは検証環境と本番環境の取り違えで事故につながりやすいポイントです。CI/CDでは、デプロイ先のFunction App名、リソースグループ、サブスクリプションを明示し、環境ごとに分けて管理しましょう。(Microsoft Learn)
Pythonプロジェクトでは、公式手順で常にリモートビルドを要求するよう案内されています。Windows上でビルドした成果物をLinux環境のFlex Consumption Planへそのまま配置すると、依存パッケージやネイティブライブラリの差で動かないことがあります。(Microsoft Learn)
az functionapp deployment source config-zip \
--src <FILE_PATH> \
--name <APP_NAME> \
--resource-group <RESOURCE_GROUP> \
--build-remote trueデプロイストレージをカスタマイズする場合は、ストレージアカウントとコンテナーが事前に存在している必要があります。複数のFunction Appが同じストレージアカウントを使う場合でも、デプロイコンテナーはアプリごとに分けるべきです。同じコンテナーを共有すると、デプロイパッケージの上書きが起きる可能性があります。(Microsoft Learn)
| 失敗しやすい点 | 起きる問題 | 対策 |
|---|---|---|
| 複数アプリで同じデプロイコンテナーを使う | パッケージ上書き、意図しないコード実行 | アプリごとに専用コンテナーを作る |
| Pythonでローカルビルド成果物を使う | Linux実行環境で依存関係エラー | --build-remote trueを使う |
| 既存アプリに誤ってデプロイする | 本番コードを上書き | CI/CDの環境変数と承認フローを分ける |
WEBSITE_RUN_FROM_PACKAGE前提でIaCを書く | Flex Consumptionでは想定通りに動かない | functionAppConfigベースへ見直す |
| 接続文字列だけでストレージアクセスする | シークレット管理が複雑になる | 可能な範囲でマネージドIDを使う |
VNet統合ではサブネット設計が重要
Flex Consumption Planでは、Function App作成時または作成後にVNet統合を有効化できます。ただし、Premium PlanやDedicated Planと同じネットワーク設計をそのまま流用すると失敗しやすいです。Flex Consumptionでは各インスタンスがサブネット内の一意のIPアドレスを直接使うのではなく、プラットフォーム管理のネットワークゲートウェイプールがIPを使うIP多重化の仕組みになっています。(Microsoft Learn)
サブネット設計の目安は次のとおりです。
| シナリオ | 推奨CIDR | 実務上の目安 |
|---|---|---|
| 単一のFlex Consumption Function App | /27 | 1アプリの最小構成として考える |
| 複数アプリを同一サブネットで運用 | /26 | 複数アプリや高スケールのワークロードで検討する |
| 送信トラフィックが多い構成 | /26以上を検討 | IP枯渇より送信スループットがボトルネックになりやすい |
サブネットはMicrosoft.App/environmentsへ委任する必要があります。PremiumやDedicatedで使われるMicrosoft.Web/serverFarmsとは異なります。また、プライベートエンドポイントやサービスエンドポイントで既に使っているサブネット、Azure Container Apps環境と共有しているサブネットは使えません。サブネット名にアンダースコアを含められない点も、地味ですが作成エラーの原因になります。(Microsoft Learn)
ネットワーク性能の観点では、サブネットが小さすぎてもスケールアウト自体が止まるとは限りません。代わりに、依存サービスへの送信呼び出しの遅延や外部サービスへの接続タイムアウトとして現れることがあります。本番投入前に、実際の想定スケールでロードテストし、Application Insightsで依存関係のレイテンシを監視することが重要です。(Microsoft Learn)
スケールと性能はメモリ、Always Ready、同時実行数で調整する
Flex Consumption Planでは、インスタンスメモリサイズを選択できます。公式ドキュメントでは、512MB、2,048MB、4,096MBの選択肢が示され、2,048MBが多くのシナリオの既定候補として説明されています。メモリサイズが大きいほど、CPUやネットワーク帯域も比例して増える一方、アクティブ期間あたりのコストも高くなります。(Microsoft Learn)
作成時にインスタンスメモリを指定する例は次のとおりです。
az functionapp create \
--instance-memory 4096 \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--storage-account <STORAGE_NAME> \
--flexconsumption-location <REGION> \
--runtime dotnet-isolated \
--runtime-version 8.0作成後に変更する場合は、az functionapp scale config setを使います。
az functionapp scale config set \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--instance-memory 512Always Readyは、特定のトリガーグループや関数を事前に起動状態にして、コールドスタートを抑える設定です。http、durable、blobのグループ、またはfunction:<FUNCTION_NAME>=n形式で個別関数に設定できます。インスタンス数を0より大きくすると、関数が実行されていない時間にも課金対象になるため、全関数に広く設定するのではなく、レイテンシ要件が厳しい入口だけに絞るのが現実的です。(Microsoft Learn)
az functionapp scale config always-ready set \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--settings http=2HTTPトリガーの同時実行数も調整できます。注意したいのは、一度手動でHTTP concurrencyを設定すると、インスタンスメモリサイズを変えてもその値が維持される点です。メモリを増やしたのにスループットが伸びない場合、手動設定した同時実行数がボトルネックになっていないか確認しましょう。(Microsoft Learn)
az functionapp scale config set \
--resource-group <RESOURCE_GROUP> \
--name <APP_NAME> \
--trigger-type http \
--trigger-settings perInstanceConcurrency=10サブスクリプションとリージョン単位のクォータも無視できません。Flex Consumptionアプリは、同一サブスクリプション・同一リージョン内で共有されるコンピュートクォータを消費します。公式情報では既定クォータとして250コア相当が示されており、Always Readyインスタンスもクォータに含まれます。スパイクが大きい複数アプリを同一リージョンに集約する場合は、事前にクォータ確認と必要に応じた引き上げ申請を検討してください。(Microsoft Learn)
デプロイ時の中断をどう扱うか
Flex Consumption Planでは、コードデプロイやアプリ設定変更などのサイト更新時に、既定でRecreate戦略が使われます。Recreateでは実行中のインスタンスが再起動されるため、短時間の停止や実行中処理の中断が問題になるワークロードでは注意が必要です。(Microsoft Learn)
ゼロダウンタイムを目指す場合は、RollingUpdate戦略を選べます。ただし、これは公開プレビューで、Azure CLI、Azure portal、Visual Studio Codeからは設定できず、BicepまたはARMテンプレートでfunctionAppConfig配下のsiteUpdateStrategyを設定します。公式ドキュメントでは、プレビュー期間中の制約確認が必要で、本番アプリでの利用には慎重な検討が求められています。(Microsoft Learn)
functionAppConfig: {
siteUpdateStrategy: {
type: 'RollingUpdate'
}
}Flex Consumption Planではデプロイスロットが現在サポートされていません。従来スロットを使って本番切り替えをしていた場合は、別のFunction Appを用意して検証する、Traffic ManagerやAPI Managementなど上位レイヤーで切り替える、またはRollingUpdateの制約を理解して使う、といった設計変更が必要です。(Microsoft Learn)
証明書はsite-scoped certificatesとして扱う
Flex Consumption Planでは、証明書は個別のFunction Appにスコープされるsite-scoped certificateモデルで扱われます。サポートはプレビューで、既存アプリに対する証明書の移行パスがないケースがあるため、証明書を使うアプリは移行時に再設定計画を立てる必要があります。(Microsoft Learn)
重要な制限は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| サポート状態 | site-scoped certificatesはプレビュー |
| 証明書数 | 1アプリあたり秘密証明書3個、公開証明書3個まで |
| CLI対応 | Azure CLIでの管理はまだ利用できないため、portalまたはARM/Bicepを使う |
| E2E暗号化 | 現時点ではサポートされていない |
| Linux実行環境 | Windows証明書ストアではなくファイルパスから読み込む |
| ファイル配置 | 公開証明書は/var/ssl/certs、秘密証明書は/var/ssl/private |
Key Vaultから証明書をインポートする場合は、サービスプリンシパルよりもマネージドIDの利用が推奨されています。Key Vault上で証明書を更新すると、プラットフォームのバックグラウンドジョブにより24時間以内にFunction Appへ同期されると説明されています。(Microsoft Learn)
既存アプリを移行する場合のチェックリスト
既存のFunction AppをFlex Consumption Planへ移す場合、インプレースでプランだけを変更する移行はサポートされていません。新しいFlex Consumption Function Appを作成し、既存アプリと並行してテストし、問題がなければトラフィックを切り替える流れになります。(Microsoft Learn)
移行前に確認すべき項目は次のとおりです。
| チェック項目 | 確認方法 | 対応が必要な例 |
|---|---|---|
| リージョン | Flex Consumption対応リージョン一覧を確認 | 現在のリージョンが未対応 |
| ランタイム | サポートされる言語スタックを確認 | C# in-processを使っている |
| バージョン | リージョンごとの対応ランタイムを確認 | 古いNode.js、Python、Javaなど |
| デプロイスロット | 既存アプリのDeployment slotsを確認 | スロット前提の本番切り替え |
| 証明書 | Certificates画面やCLIで確認 | 証明書数上限、読み込み方法変更 |
| Blobトリガー | sourceがEventGridか確認 | 既定のポーリング型Blobトリガーを使っている |
| IaC | ARM/Bicep/Terraformを確認 | 古いアプリ設定やsiteConfigプロパティを使っている |
Blob Storageトリガーでは、Flex Consumption PlanがEvent GridベースのBlobトリガーのみをサポートしている点に注意が必要です。既定のコンテナーポーリング方式を使っている場合は、移行前にEvent Gridベースへ変更する必要があります。(Microsoft Learn)
Infrastructure as Codeを使っている場合は、従来のアプリ設定をそのまま使わないようにします。Flex ConsumptionではfunctionAppConfigセクションが導入され、FUNCTIONS_WORKER_RUNTIME、WEBSITE_RUN_FROM_PACKAGE、WEBSITE_CONTENTSHARE、WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUTなど、多くの従来設定が非推奨または置き換え対象として示されています。(Microsoft Learn)
監視とコスト管理は作成直後に入れる
Flex Consumption Planでは、性能とコストの調整幅が広い分、監視を後回しにすると原因調査が難しくなります。Azure Monitorではプラットフォームメトリックを、Application Insightsではコードレベルのトレース、エラー、依存関係、実行時間を確認できます。(Microsoft Learn)
特に確認したいメトリックは次のとおりです。
| 目的 | 見るべき指標 |
|---|---|
| スケール状況 | InstanceCount |
| 実行量 | OnDemandFunctionExecutionCount、AlwaysReadyFunctionExecutionCount |
| 課金影響 | OnDemandFunctionExecutionUnits、AlwaysReadyFunctionExecutionUnits |
| メモリ | AverageMemoryWorkingSet、MemoryWorkingSet |
| CPU | CpuPercentage |
| Always Ready | AlwaysReadyUnits |
Application Insightsでは、移行後の失敗率、依存サービスの応答時間、インスタンスごとの挙動を確認します。コストはFunction App単体だけでなく、関連するストレージ、Application Insights、Log Analytics、VNet周辺リソースも含めてCost Managementで追跡しましょう。公式手順でも、Flex Consumption Planでは性能と運用コストを調整できるため、コスト確認が重要だと説明されています。(Microsoft Learn)
管理者・開発者が次にやるべきこと
Azure FunctionsのFlex Consumption Planを使うなら、まず既存Function Appの棚卸しから始めてください。リージョン、ランタイム、トリガー、証明書、デプロイスロット、VNet、IaC設定を一覧化し、Flex Consumptionでそのまま使えるものと変更が必要なものを分けます。
新規作成の場合は、最初から以下を決めておくと後戻りが少なくなります。
- 利用リージョンとクォータ
- インスタンスメモリの初期値
- Always Readyを使う関数
- HTTP同時実行数を手動設定するかどうか
- VNet統合の有無とサブネットサイズ
- デプロイストレージと認証方式
- 証明書とKey Vault連携
- Application Insights、Azure Monitor、Cost Managementの監視設計
- デプロイ時の中断を許容するか、RollingUpdateを検討するか
Flex Consumption Planは、従来のConsumption Planより柔軟にスケールと性能を調整できます。一方で、設定項目が増えたことで、ネットワーク、デプロイ、監視、コストを横断して設計する必要があります。小さな検証アプリで作成・デプロイ・監視・コスト確認まで一通り試し、その結果を本番移行チェックリストに落とし込むのが、安全で現実的な進め方です。
コメント