【Microsoft Azure】MCPが話題になってきた今、Azure Flex Consumptionについて振り返る

2025.10.02

Azure Functionsの概要をおさらい
プランの比較とFlex従量課金の特徴について
Flex Consumptionを使ったほうが良いユースケース
まとめ

こんにちは、MS開発部の渋谷です。

Azure Functionsを使っている皆さんなら、サーバーレスアーキテクチャがもたらす俊敏性とコスト効率の良さを日々実感されていることでしょう。また、近頃話題になっているMCP周りでも、Azure FunctionsではMCPバインドの発表があるなど、いろいろと注目を浴びている状況だと思います。

一方で、同時に従来のホスティングプランが持つ「一長一短」に悩まれてきた方も少なくないはずです。コストを極限まで抑えられるが機能に制約のある「従量課金プラン」と、高機能・高性能だが常時コストが発生する「Premiumプラン」。この二者択一は、多くの開発者にとって悩ましいトレードオフだったと思います。

今回は、ある意味従来のプランの「良いとこどり」をしたような新プランである、Azure Functions Flex Consumptionプランについてみていきたいと思います。

Azure Functionsの概要をおさらい

Flex Consumptionプランの詳細に入る前に、Azure Functionsの基本的な考え方を改めて確認します。

Azure Functionsの最大の特徴は、「イベント駆動型アーキテクチャ」です。これは、特定の「イベント」の発生をきっかけに、それに応答するコード（関数）を実行するという非常にシンプルなモデルです。この「イベント」が、Functionsの世界では「トリガー（Trigger）」と呼ばれます。例えば、以下のようなものが代表的なトリガーです。

HTTPトリガー: 特定のURLへのHTTPリクエストを受け取ると関数が起動します。サーバーレスAPIやWebhookの実装に利用されます。
Timerトリガー: 「毎朝9時」「15分ごと」といったスケジュールに基づいて定期的に関数を実行します。
Queueトリガー: Azure Storage Queueに新しいメッセージが追加されると、そのメッセージを処理するために関数が起動します。
Blobトリガー: Azure Blob Storageに新しいファイルがアップロードされると、そのファイルを処理する関数が起動します。

そして、もう一つの重要な概念が「バインド（Binding）」です。これは、関数と外部のデータソース（Azure Cosmos DB、Azure SQL Database、Event Hubsなど）との接続を、コード上で宣言的に、かつシンプルに実現するための仕組みです。例えば、HTTPトリガーで受け取ったデータを、わずか数行の定義でデータベースに書き込む、といった処理を簡単に行えます。特に、バインドの最大のメリットはコード記述量が圧倒的に減る点です。通常、外部のデータソースへの読み書きをする際は、SDKを用いて○○クライアントを宣言して云々…と、お作法的なコードを書くことがほとんどです。一方で、Functionsのバインド機能を使うと、外部のデータソースとの連携部分についてはフレームワークにお任せすることが可能になります。

この強力なトリガーとバインドの仕組みを支えているのが、今回主題となる「ホスティングプラン」です。ホスティングプランは、これらのトリガーを監視し、イベントが発生した際に実際に関数を実行するためのコンピューティングリソース（CPU、メモリ、ネットワークなど）をどのように確保し、管理し、スケールさせるかを決定します。

プランの比較とFlex従量課金の特徴について

それでは、本題であるFlex Consumptionプランの特徴を理解するため、まずは既存のホスティングプランとの比較から始めます。

既存ホスティングプラン

従量課金 (Consumption) プラン: 「真のサーバーレス」を体現した最初のプランです。イベントが発生していないときはインスタンス数がゼロになり、コストも完全にゼロになります。月々の無料枠が非常に大きく、プロトタイピングやトラフィックの少ないバッチ処理には最適です。しかし、その裏返しとして、長期間アイドル状態が続いた後の初回リクエスト時に顕著な遅延（コールドスタート）が発生する、インスタンスのメモリが約1.5GBに固定されている、そして何より仮想ネットワーク（VNet）に接続できないという重大な制約がありました。
Premium プラン: 従量課金プランの弱点を克服するために登場したプランです。常時待機する「事前ウォーミングアップ済みインスタンス」によりコールドスタートをほぼ解消し、VNet統合によるセキュアなネットワーク接続、より高性能なインスタンスを提供します。しかし、その最大の代償はコストモデルです。最低1インスタンスが常に稼働し続けるため、「確保したリソース（vCPUとメモリ）の時間」に対して課金され、利用がない時間帯でも固定費が発生します。これにより、「スケール・トゥ・ゼロ」というサーバーレスの大きな魅力が失われていました。
Dedicated (App Service) プラン: 既存のApp Service（Web Appsなど）とコンピューティングリソースを共有するためのプランです。負荷が常に一定で予測可能な場合や、リソースを他のアプリケーションと効率的に共有したい場合に選択されます。ただし、このプランではFunctions本来のイベント駆動スケーリングは利用できず、スケールは手動またはルールベースで行う必要があります。これは、サーバーレスの俊敏性を求める多くのシナリオには不向きでした。

Azure Functions ホスティングプラン比較

特徴	従量課金プラン	Flex Consumptionプラン	Premiumプラン	App Serviceプラン
サーバーレス	〇	〇	×	×
スケール方式	イベント駆動	高度なイベント駆動	イベント駆動	手動/ルールベース
最大インスタンス数	100 – 200	1000	100	SKUに依存
コールドスタート	発生する	Always Readyで回避可能	事前ウォームインスタンスで回避可能	Always Onオプションで回避可能
VNET 統合	×	〇	〇	〇
主な課金要素	実行回数＋消費メモリ量	実行回数＋消費メモリ量	プロビジョニングされたインスタンス	プロビジョニングされたインスタンス
デプロイスロット	×	×（現在）	〇	〇
OS	Windows/Linux	Linux	Windows/Linux	Windows/Linux
主な用途	プロトタイプ、低頻度ジョブ	高スケールAPI	ミッションクリティカルAPI	予測可能な負荷、リソース共有

Flex Consumptionプランは、従来の従量課金プランが持っていた「スケール・トゥ・ゼロ」の経済性と、Premiumプランが持っていたエンタープライズ級の機能を融合させた、まさに「いいとこ取り」のプランです。ここからはその特徴について簡単に見ていきます。

高速なスケーリング

関数ごとのスケーリング (Per-Function Scaling): 従来のプランでは、Function App内のすべての関数が同じインスタンス群を共有してスケールしていました。Flex Consumptionプランでは、HTTPトリガーやBlobトリガーなどを除き、異なるトリガーを持つ関数がそれぞれ独立したインスタンス群でスケールできます。これにより、例えば「高負荷なQueueトリガー関数が、低負荷なTimerトリガー関数のリソースを食いつぶす」といった事態を避け、より効率的なリソース割り当てが実現します。
同時実行数の制御 (Configurable Concurrency): これがおそらく、パフォーマンスチューニングにおける最も強力な新機能です。開発者は、インスタンスあたりいくつのリクエストを同時に処理するか（perInstanceConcurrency）を細かく設定できるようになりました。これは、ワークロードの特性に合わせて性能とコストのバランスを最適化する強力な武器となります。同時実行数を下げてシステム全体のスループットを向上させた例についてはこちらにありますので併せてご覧ください。ただし、当たり前ですが、同時実行数を下げると多くのインスタンスが立ち上がりやすい傾向になるため、単位当たりのコストは上昇する傾向にあることはご注意ください。

VNet統合の実現

恐らく、エンタープライズ企業のみなさまにとっては、Flex Consumptionプランの中で最も期待されている機能なのではと予想できる機能がこちらです。

VNET統合をする場合は必ずPremiumプラン（もしくはApp Serviceプラン）が必要という状況から、Flex Consumptionプランも新たに選択肢に加わりました。これにより、スケール・トゥ・ゼロの恩恵を受けながら、データベースやストレージ、他のマイクロサービスといったVNet内のプライベートなリソースへ安全にアクセスできるようになります。実用上は、Function Appが利用するサブネットを Microsoft.App/environments に委任する設定が必要になる点に注意してください。この機能により、VNetで保護されたService Busからメッセージを処理したり、VNet内のEvent Hubsにデータを書き込んだりといった、エンタープライズで一般的なセキュアなアーキテクチャを、純粋なサーバーレスモデルで構築できるようになりました。

コールドスタート対応

サーバーレスの永遠の課題である「コールドスタート」（アイドル状態からの初回起動時の遅延）について、Flex Consumptionプランは「Always Ready」インスタンスというオプションを使って解決することが可能になりました。これは、指定した数のインスタンスを常にウォーム状態（起動済み）で待機させておく機能です。

これにより、トラフィックがゼロの状態から最初のイベントが到着した際に、待機中のインスタンスが即座に応答するため、ユーザーが体感する遅延を劇的に削減できます。Premiumプランの「事前ウォーミングアップ済みインスタンス」と似ていますが、課金モデルに決定的な違いがあります。

Flex従量課金プランでは、Always Readyインスタンスがアイドル状態のときは、より安価な「ベースライン」レートで課金され、実際にリクエストを処理しているときだけ実行レートが適用されます。これにより、Premiumプランを契約するよりもはるかに低いコストで、コールドスタート問題に的を絞った対策を講じることが可能になります。（正確ではありませんが、イメージとしてはContainer Appsのアイドル状態のコア数課金のようなものです）

Flex Consumptionを使ったほうが良いユースケース

高スループットなHTTP API

Eコマースサイトのフラッシュセール、オンラインゲームのリアルタイムランキング、大量のWebhookを受け付けるエンドポイントなど、突発的かつ大規模なトラフィックを処理する必要があるHTTP APIは、Flex Consumptionプランの最も得意とする領域です。前述の通り、HTTPの同時実行数をワークロードに合わせて調整することで、レイテンシを最小限に抑えながらスループットを最大化できます。そして、セール終了後などトラフィックがなくなれば、コストは自動的にゼロになります。つまり、ピーク性能のために高価なPremiumプランを契約し続ける必要がなくなります。

セキュアなイベント処理パイプライン

企業の基幹システムでは、セキュリティが最優先事項です。VNetで厳格にアクセス制御されたEvent HubsやService Bus、データベースを扱うシナリオは非常に一般的です。例えば、IoTデバイスから送信されるテレメトリデータや、金融取引のストリーミングデータを処理するパイプラインなどが挙げられます。実際にGitHub社は、Flex Consumptionプランを利用して、ネットワーク的に分離されたEvent Hubsから毎秒160万イベントを処理する大規模なパイプラインを構築した事例を公開しています。