Azure Functions Flex Consumption のデプロイと運用｜従来プランとの違いと利用の注意点
Flex Consumption には、デプロイスロットも配置の履歴もなく、外向きの通信はすべて仮想ネットワークを通ります。従来プランの定石が、そのままでは通用しません。
特に配置は、コマンドが完了しても関数が1つも動いていないことがあり、逆に失敗と返しても配置は済んでいることがあります。違いを知ったうえで、成否の確かめ方と戻し方を先に決めておくことが、安全に使うための条件です。
従来の Consumption プランや Premium プランで、ZIP デプロイやデプロイスロットを使った運用に慣れている方は多いと思います。Flex Consumption はその後継に見えますが、配置・戻し方・通信の前提がいくつも変わります。弊社はお客様専用の環境を Flex Consumption で構築・運用する中で、「コマンドは完了したのに関数が0件」と「コマンドは失敗したのに配置は成功」の両方を経験しました。この記事では、従来プランとの違いを整理したうえで、実際に運用して分かった利用の注意点を5つに分けて解説します。
目次
株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。
Azure Functions Flex Consumption とは
Flex Consumption は、Azure Functions の Linux ベースのホスティングプランです。使った分だけ支払う従量課金のサーバーレスの考え方はそのままに、仮想ネットワークへの統合、インスタンスのメモリサイズの選択、常時準備（Always ready）のインスタンスといった機能が加わっています。Microsoft Learn は、Azure Functions のサーバーレスのホスティングプランとして Flex Consumption を推奨しています。
仮想ネットワークに統合できることが、お客様専用の環境で Flex Consumption を選ぶいちばんの理由です。閉域の中にある Azure OpenAI や Storage へ、サーバーレスのまま安全に接続できます。
従来プランとの違い
従来の Consumption プランと比べると、機能が増えた点と、運用の前提が変わった点の両方があります。
| 項目 | Flex Consumption | 従来の Consumption |
|---|---|---|
| 仮想ネットワーク | 統合できる（外向きの通信はすべて仮想ネットワーク経由） | 統合できない |
| コールドスタートの緩和 | 常時準備のインスタンスを指定できる | 手段なし |
| スケールアウトの上限 | 1,000 インスタンス | 200 インスタンス |
| OS | Linux のみ | Windows・Linux |
| 配置の方式 | パッケージを配置コンテナへ置く1方式のみ | ZIP デプロイ・外部パッケージ URL など複数 |
| デプロイスロット | 使えない | 使える（Windows） |
| タイムゾーンの設定 | できない（UTC で動く） | できる（Windows） |
| 既存アプリからの切り替え | その場ではできない（作り直して配置） | — |
「従来と同じ感覚で使えるのでは」と考えがちですが、表のうち配置の方式・デプロイスロット・タイムゾーン、そして仮想ネットワークでの通信の扱いは、どれも従来プランで当たり前だった運用の手を使えなくします。配置の方式を選べない、スロットで切り替えて戻せない、通信が既定で閉じた経路を通る、時刻が日本時間にならない。以下では、これらが実際の運用でどう効いてくるかを、5つの注意点に分けて説明します。
注意点1：配置の方式は1つしかない
Learn は Flex Consumption の配置について「配置は1つの経路をたどります。配置の挙動を左右するためのアプリ設定は、もう必要ありません」と説明しています。プロジェクトを実行できる形のパッケージにまとめ、Blob Storage の配置コンテナに置く。アプリは起動するときにそのパッケージを取得し、そこから関数を実行する、という仕組みです。
このため、従来のプランで使えた方式の多くは使えません。Learn の対応表では、ZIP デプロイ、外部パッケージ URL、コンテナイメージ、ソース管理との連携、ローカル Git、FTPS、ポータル上での編集は、いずれも Flex Consumption では非対応です。WEBSITE_RUN_FROM_PACKAGE のような設定で配置の挙動を変える、という従来の定石も当てはまりません。
配置コンテナは、既定ではホストの内部データを置く Storage アカウント（AzureWebJobsStorage）と同じものが使われます。アプリを作るときに、別の Storage アカウントや、マネージド ID による認証を指定することもできます。Learn は、配置ツールが「配置コンテナへ直接アップロードするのではなく、まずアプリの配置エンドポイントへソースのパッケージを送る」とも書いています。どのツールを使っても、処理済みのパッケージが配置コンテナに保存される、という結果は同じです。
注意点2：コマンドの結果を、配置の成否として扱わない
配置で事故が起きると、まず「使うコマンドを間違えたのではないか」と考えます。ところが Flex Consumption では、公式に案内されている配置の手段はどれも同じ1本の経路に乗ります。Learn は、Visual Studio Code の発行、Azure Functions Core Tools、Azure CLI、そして Azure Pipelines のタスクや GitHub Actions が、Flex Consumption のアプリを検出すると正しい配置の方式を選ぶ、と説明しています。それでも弊社では、コマンドの結果と実際の状態が食い違うことを、向きの違う2つの形で経験しました。
「完了」と返ったのに、関数が0件になった
弊社では、稼働中の Flex Consumption のアプリへ Azure CLI の az functionapp deployment source config-zip で配置した直後に、アプリに登録された関数が0件になり、すべての経路が応答しなくなったことがあります。Core Tools で配置し直して復旧しましたが、なぜ0件になったのかは特定できていません。Learn は Azure CLI のこのコマンドを Flex Consumption の配置手段として案内しているので、コマンドそのものが対応していないわけではありません。パッケージの中身の構成や、使っていた CLI の状態など、手元の条件が重なった可能性があります。
「失敗」と返ったのに、配置は済んでいた
逆向きの食い違いもあります。Front Door の背後に置き、Front Door 以外からの接続を拒否する（オリジンロック）構成にしたアプリでは、Core Tools での配置がエラーで終わるようになりました。
原因は、配置の後に行われる確認の手順です。Core Tools は配置を終えた後、アプリのホストが正常に動いているかを、アプリの既定のホスト名へ直接問い合わせて確かめます。オリジンロックをしていると、この問い合わせはアクセス制限で 403 として拒否され、コマンドはエラーとして終了します。しかしこの時点で、パッケージのアップロードもトリガーの同期も完了しています。失敗しているのは確認の手順だけで、配置そのものは成功しています。
ここで終了コードを見て配置をやり直すと、同じ結果を繰り返すだけです。自動化の手順が終了コードで失敗を判定していると、正しく配置できているのに毎回失敗として扱われます。オリジンロックの張り方はAzure Front Door の背後のアプリを守るで解説しています。
対策：手段を1つに固定し、判定はコマンドと別に持つ
この2つの経験から学んだのは、「このコマンドなら安全」という答えは無い、ということです。そこで弊社は、手作業で配置するときは Core Tools に統一しています。プロジェクトのルート（host.json のあるフォルダ）で実行すると、パッケージの作成から配置、トリガーの同期までを1つのコマンドで行えます。手段を固定しておくと、うまくいかなかったときに比べる基準が1つで済みます。
func azure functionapp publish <アプリ名> 依存パッケージを手元で揃えてからパッケージに含める場合は、--no-build を付けると配置の途中でのビルドを省けます。そのうえで、どの手段を使っても、配置が終わったら実際の状態を確かめて、はじめて完了とします。何を確かめるかを次の章で説明します。
配置の成否を確かめる3つの確認
弊社では、配置の後に次の3つを確かめ、すべて揃ったら成功とみなしています。
1. 期待する関数がすべて登録されている
アプリに登録されている関数の一覧を取り、配置したはずの関数が名前まで揃っているかを確かめます。関数が0件になる事故は、ここで確実に見つかります。件数だけでなく名前で突き合わせておくと、一部の関数だけが抜けた場合にも気づけます。
az functionapp function list \
--resource-group <リソースグループ名> \
--name <アプリ名> \
--query "[].name" -o tsv 2. 利用者と同じ経路で、期待する応答が返る
Front Door のように利用者が実際に通る経路から、代表的な画面や API を呼び出し、期待する応答が返るかを確かめます。認証をかけている画面では、サインイン画面への転送（302）が返ることがあります。302 は認証の仕組みが手前で応答しているだけで、関数が動いている証明にはなりません。転送先が意図したサインイン画面になっているかまで見るか、認証を通した状態で確かめます。
3. アプリへの直接の接続が、拒否される
オリジンロックをしている場合は、アプリの既定のホスト名へ直接接続すると拒否されることも確かめます。配置の作業でアクセス制限を一時的に緩めた場合、戻し忘れはここで見つかります。配置が成功したことと、守りが元に戻っていることを、同じ手順の中で確認するのが要点です。
この3つは、配置の直後に分かることの確認です。配置してしばらくしてから表に出る不具合に備えて、失敗率の変化を知らせる監視もあわせて用意しておきます。通知の設計はApplication Insights Smart Detectionのアラート設定勘所で解説しています。
注意点3：デプロイスロットも、配置の履歴もない
配置に失敗したとき、どこへ戻せるかも従来のプランとは違います。Flex Consumption の配置には、次の性質があります。
- 配置のたびに、現在のパッケージは上書きされる
- 以前のバージョンを残しておく仕組みを、プラットフォームは持たない
- デプロイスロットは使えない
- アプリ設定はコードとは別に反映され、プラットフォームは以前の状態に戻せない
つまり、いま動いているパッケージの実物は、配置コンテナにある1つだけです。スロットを入れ替えて元に戻す、という従来の手は使えません。
手元の控えより、配置コンテナの現物を正とする
コードの一部だけを直して配置し直したいとき、手元のフォルダを元にすると、別の担当者が配置した変更を古い版で巻き戻してしまうことがあります。弊社では、配置コンテナにある現在のパッケージを取得し、それを土台に変更を加えるようにしています。配置コンテナの場所は、アプリの配置設定で確認できます。
az functionapp deployment config show \
--resource-group <リソースグループ名> \
--name <アプリ名> 閉域の環境では、この Storage アカウントも公開のネットワークからの接続を無効にしているのが普通です。取得するときは、作業する端末からの接続を一時的に許可し、取得したらすぐに元へ戻します。戻したことは、前の章の3つめの確認と同じ考え方で、作業の最後に必ず確かめます。
本来の戻し方は、パイプラインの再実行
プラットフォームが履歴を持たない以上、ある時点の配置をたどれるのは、ソースの変更履歴と配置パイプラインの実行記録だけです。戻し方は、配置パイプラインの過去に成功した実行をやり直す、問題の変更を取り消すコミットを作って配置し直す、修正を加えて配置する、のいずれかになります。アプリ設定も配置パイプラインの中で反映するようにしておけば、コードと設定をまとめて戻せます。
本番の環境では、配置はパイプラインから行い、手作業での配置は緊急時に限るのが基本です。そのうえで弊社は、配置の前に現在のパッケージを退避しておき、万一のときにはそれを配置し直せるようにしています。
注意点4：閉域では、外向きの通信がすべて仮想ネットワークを通る
Flex Consumption を仮想ネットワークに統合すると、通信の流れが従来のプランと変わります。閉域の構成で特に効いてくるのは次の点です。
送信の規則が、外部への通信すべてに効く
Premium プランや App Service プランでは、仮想ネットワークに統合しても、既定ではインターネット宛ての通信は仮想ネットワークを通りません。すべての通信を通すには「すべてルーティング（Route All）」を有効にします。Learn は Flex Consumption について「すべての通信がすでに仮想ネットワーク経由でルーティングされており、Route All は必要ありません」と書いています。
このため、ネットワークセキュリティグループ（NSG）で送信を絞ると、その規則はアプリから外部への通信すべてに効きます。外部の API や通知の送り先を呼び出す処理があれば、許可する宛先に含めるか、通知を Azure Monitor の側から出す設計に変えます。閉域の構成全体はAzure OpenAI・AI Searchを閉域で使うで解説しています。
サブネットには専用の条件がある
| 条件 | 内容 |
|---|---|
| サブネットの委任 | Microsoft.App/environments。Premium プランや App Service プランとは委任先が異なるため、既存のサブネットをそのまま流用できない |
| リソースプロバイダー | サブスクリプションで Microsoft.App を登録しておく必要がある |
| サブネットの大きさ | 最小は /27。複数のアプリで共有するなら /26 が推奨 |
| 共有できないもの | Private Endpoint など他の用途に使っているサブネットや、Container Apps 環境とは共有できない |
| 名前の制約 | 名前にアンダースコア（_）を含むサブネットは使えない |
アプリを閉じると、配置する側も閉域の中にいる必要がある
アプリに Private Endpoint を設定し、公開のネットワークからの接続を無効にすると、配置エンドポイントにもインターネットから届かなくなります。Learn は、この場合「配置を行う端末・ランナー・エージェントは、プライベートの配置エンドポイントへの接続と名前解決の両方を備えている必要があります」としています。配置パイプラインを使うなら、仮想ネットワークにつながるセルフホストのエージェントを用意するなど、配置の経路も閉域の設計に含めておきます。
注意点5：タイムゾーンなど、従来と違う細かな仕様
最後に、知らずに進めると後から手戻りになる仕様をまとめます。いずれも従来プランの感覚で設計すると見落としやすい点です。
| 仕様 | 運用上の意味 |
|---|---|
| タイムゾーンを設定できない | WEBSITE_TIME_ZONE と TZ のアプリ設定には対応していません。アプリは協定世界時（UTC）で動くため、日付を使う採番や締め処理は、コードの側で日本時間へ変換します。日本時間の0時から9時の間だけ日付が前日になる、という不具合として表に出ます。 |
| 1つのプランに1つのアプリ | 従来の App Service プランのように、1つのプランへ複数のアプリを載せることはできません。 |
| 起動の初期化は30秒で打ち切り | アプリの初期化に30秒以上かかると、タイムアウトになります。この時間は変更できません。起動時の重い処理は避けます。 |
| プランの移行はその場でできない | 既存のアプリを Flex Consumption へ切り替えることも、Flex Consumption から他のプランへ移すこともできません。新しいアプリを作って配置し直します。 |
| Blob トリガーは Event Grid 経由のみ | Blob Storage のトリガーは、Event Grid をソースとする方式だけに対応しています。従来のポーリング方式のトリガーは移し替えが必要です。 |
利用の注意点のまとめ
- 配置の方式は1つで、パッケージは上書きされる
- コマンドの結果を成否として扱わず、関数の一覧・利用者の経路での応答・直接接続の拒否の3点で確かめる
- スロットも履歴もないので、戻す手段はソースの変更履歴と配置パイプラインで用意する
- 閉域では外向きの通信がすべて仮想ネットワークを通り、配置する側も閉域の中にいる必要がある
- タイムゾーンは設定できず、プランの切り替えもその場ではできない
弊社の支援
弊社は、お客様専用のAI基盤やアプリを Azure 上に構築する形で、AIの業務活用を支援しています。Flex Consumption は、閉域の構成とサーバーレスの手軽さを両立できる有力な選択肢ですが、配置と戻し方の考え方は従来のプランと違います。
弊社では、構築の段階で配置の手順と成否の判定、戻し方までを決め、運用を始めてから迷わない状態にしてお渡しすることを重視しています。インフラの払い出しを標準化する考え方はAzureのインフラ払い出しをセルフサービス化するもあわせてご覧ください。
よくあるご質問
こちらをクリックして「よくある質問」を表示
Flex Consumption で Azure CLI の config-zip は使えますか？
使えます。Microsoft Learn は、Azure CLI の az functionapp deployment source config-zip を Flex Consumption の配置手段として案内しています。弊社では配置の直後に関数が0件になった経験があるため Core Tools に統一していますが、どの手段を使う場合でも、配置の後に関数の一覧などで実際の状態を確かめることをお勧めします。
従来の Consumption プランのアプリを、そのまま Flex Consumption へ切り替えられますか？
その場では切り替えられません。Flex Consumption のアプリを新しく作り、コードを配置し直します。あわせて、配置の方式・タイムゾーン・仮想ネットワークでの通信の扱いが変わるため、切り替えの前にこの記事の注意点に当てはまる箇所がないかを確認してください。なお、デプロイスロットも使えないため、検証には同じ構成の Flex Consumption のアプリを別に用意します。
以前のバージョンへ戻すには、どうすればよいですか？
プラットフォームは以前のバージョンを残さないため、戻す手段は自分で用意します。基本は、配置パイプラインで過去に成功した実行をやり直すか、問題のコミットを取り消して配置し直す方法です。あわせて、配置の前に現在のパッケージを退避しておくと、緊急時にそれを配置し直せます。
Core Tools での配置がエラーで終わりました。やり直すべきですか？
やり直す前に、まず実際の状態を確かめてください。オリジンロックなどでアプリへの直接の接続を制限していると、配置の後の確認の手順だけが失敗し、配置そのものは済んでいることがあります。関数の一覧と、利用者と同じ経路での応答を確かめ、揃っていれば配置は成功しています。
仮想ネットワークに統合したら、外部の API に接続できなくなりました。なぜですか？
Flex Consumption では、仮想ネットワークに統合すると外向きの通信がすべて仮想ネットワークを通ります。ネットワークセキュリティグループの送信規則やルートの設定で、その宛先への通信が止められていないかを確認してください。Premium プランなどとは既定の振る舞いが異なる点に注意が必要です。
アプリのタイムゾーンを日本時間にできますか？
Flex Consumption では、タイムゾーンを指定するアプリ設定には対応していません。アプリは協定世界時（UTC）で動くため、日付や時刻を扱う処理は、コードの側で日本時間へ変換してください。
Flex Consumption を選ぶか、他のプランやコンテナで動かすかは、閉域の要件や処理の性質によって変わります。現在の構成や運用体制をお聞かせいただければ、ホスティングの選び方から配置と運用の手順まで、設計案をご提案します。お問い合わせよりお気軽にご相談ください。
関連サービス・関連コラム
- クラウド導入支援（Azure）｜アセスメントから移行・運用まで一気通貫で伴走
- Azure OpenAI・AI Searchを閉域で使う｜Private Endpointと仮想ネットワークの設計
- Azure Front Door の背後のアプリを守る｜App Service 認証（Easy Auth）とオリジンロックの設計
- Application Insights Smart Detectionのアラート設定勘所｜検知した異常が誰にも届かない状態を防ぐ
- Azureのインフラ払い出しをセルフサービス化する｜IaCとDeployment Stacksで申請から変更管理まで統制する
- Azure Container Apps の料金を抑える設定｜使わない間は止めるか、常時起動にするかの判断基準
- Azureの構成をBicepで管理するときの落とし穴｜手作業の設定が消える理由と、本番に適用する前の確認
- Azure DevOps で本番環境へのデプロイを管理する｜承認・自動確認・切り戻しの組み立て方
- 稼働中のシステムを別のAzureリージョンへ移す｜引き継がれない設定と、切り替えの順序設計
まずは無料トライアルで、効果をご確認ください
「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。
