公開2024.07.29更新2026.07.23 Azure

Azure Functionsとは？仕組み・料金プラン・使い方をわかりやすく解説【2026年版】

Azure Functionsは、サーバーの用意や管理をせずに「イベントが起きたときだけコードを動かす」Microsoft Azureのサーバーレス実行環境です。HTTPリクエストやタイマー、ストレージへのファイル追加などをきっかけに小さな関数が起動し、動いた分だけ課金される仕組みのため、常時起動のサーバーを持たずにAPIや定期バッチ、データ連携を作れます。この記事では、仕組み（トリガーとバインディング）、できること、ホスティングプランと料金、実際の使い方、そして2026年時点で必ず押さえたい注意点までを一次情報にもとづいて整理します。

まとめ：Azure Functionsの要点

正体：イベント駆動で関数単位にコードを実行するサーバーレス（FaaS）。サーバー管理不要で、動いた時間と回数だけ課金される。
中核概念：起動条件を決める「トリガー」と、外部サービスへの入出力を宣言的につなぐ「バインディング」。この2つでコード量を大きく減らせる。
プラン：2026年時点の推奨はFlex Consumption（ゼロスケール＋VNet統合＋コールドスタート緩和）。従来のConsumptionは「レガシー」扱いになった。
料金：実行回数×単価＋メモリ×実行時間（GB秒）の従量課金。Flexのon demandには毎月の無料枠がある。
2026年の注意：.NETのin-processモデルは2026年11月10日でサポート終了。C#は分離ワーカーモデルへの移行が必要。

以下で、それぞれを具体的な数値・仕様とともに掘り下げます。

Azure Functionsとは：サーバーレス（FaaS）の実行環境

Azure Functionsは、Function as a Service（FaaS）に分類されるサービスです。開発者は「どのイベントで、どのコードを動かすか」だけを書き、OSやWebサーバー、スケールのための台数調整はプラットフォームに任せます。アクセスが無い時間はインスタンスをゼロまで縮小でき（スケール・トゥ・ゼロ）、リクエストが増えれば自動的にインスタンスが増えるため、負荷の波が大きい処理や、たまにしか動かない処理と相性が良いのが特徴です。

サーバーレスの意味：物理サーバーの撤廃ではなく運用の委譲

サーバーレスは物理的にサーバーが無いという意味ではありません。サーバーの調達・パッチ適用・スケール設計といった運用をAzure側が引き受け、開発者は関数のコードに集中できる、という状態を指します。仮想マシン（IaaS）が「箱ごと自分で運用」、App Service（PaaS）が「アプリの実行基盤を借りる」のに対し、Functionsは「関数1つ分の実行だけを借りる」最も粒度の細かい選択肢だと考えると位置づけが掴めます。

仕組みの核心：トリガーとバインディング

Functionsを理解する鍵はトリガーとバインディングです。トリガーは関数を起動する「きっかけ」で、1つの関数に必ず1つ設定します。HTTPリクエスト、タイマー（cron式のスケジュール）、Blob Storageへのファイル追加、Queue/Service Busへのメッセージ到着、Cosmos DBの変更、Event Gridのイベントなどが代表例です。このうちService Busトリガーの入力元となるメッセージ基盤の全体像は、Azure Service Busとはで解説しています。

バインディングは、外部サービスとのデータ入出力を接続情報の宣言だけで実現する仕組みです。入力バインディングでCosmos DBのドキュメントを読み込む、出力バインディングでQueueにメッセージを書き込む、といった処理をSDKの初期化コードなしに属性やコンフィグで記述できます。データベースを扱う関数なら、接続をAzure Cosmos DB エミュレーターを使ったローカル開発で先に確認しておくと、バインディングの設定ミスを本番前に潰せます。

Azure Functionsでできること・主なユースケース

Functionsが向くのは「イベントに反応する、比較的短時間で終わる処理」です。具体的には次のような用途で使われます。

Web APIやWebhookのバックエンド：HTTPトリガーでREST APIを構築し、フロントエンドや外部サービスからの通知を受ける。
定期バッチ：タイマートリガーで、夜間の集計・データクレンジング・レポート生成を無人実行する。
ファイル処理：Blob Storageへの画像アップロードをトリガーにサムネイル生成や解析を行う。
データ連携・ETL：Queueやイベントを起点に、システム間のデータ変換・転送をつなぐ。
SPAのAPI層：静的サイトの動的処理を担う。フロントとセットで作るならAzure Static Web Appsの料金と構成と組み合わせると、Functionsがそのままバックエンドになる。

逆に、数十分以上動き続ける長時間処理や、常時高負荷で稼働し続けるサービスには向きません（後述の注意点を参照）。作ったAPIを社外に公開・保護したい場合は、Azure API Managementで料金プランやできることを確認し、認証・レート制限・バージョニングを前段に置く構成が定番です。

ホスティングプランの種類と選び方

Functionsは同じコードでも「どのプランで動かすか」で、スケール上限・コールドスタート・ネットワーク・課金が変わります。2026年時点の主なプランは次のとおりです。

プラン	スケール上限	ゼロスケール	VNet統合	課金	位置づけ
Flex Consumption	1,000	あり	対応	実行回数＋実行時間（＋任意のalways ready）	推奨・既定
Consumption	200	あり	非対応	実行回数＋実行時間	レガシー
Premium	大	なし（常時1以上）	対応	予約インスタンス＋従量	常時暖機が必要な場合
Dedicated（App Service）	プラン依存	なし	対応	App Serviceプラン固定	既存基盤に相乗り

このほか、既存のコンテナイメージやDockerfileでそのまま動かしたい場合は、上表の4プランとは別にAzure Container Apps上でのホスティングも選べます。コンテナ前提の移植やサイドカー構成が必要な用途はこちらが向きます。

Flex Consumptionが2026年の推奨プラン

Microsoftは現在、サーバーレスの推奨プランとしてFlex Consumption（Linux専用）を挙げています。従来のConsumptionプランのドキュメントは「レガシー」と明記され、新規はFlexが基本です。Flexの具体的な仕様は次のとおりです。

最大スケール1,000インスタンス（Consumptionは200）。関数ごとに独立してスケールする per-function scaling を採用。
インスタンスメモリを選択可能：512MB（0.25コア）／2048MB（1コア）／4096MB（2コア）。既定は2048MBで、多くの用途はこれで足りる。
コールドスタート緩和：always readyインスタンス（既定0）を指定すると、最低台数を常時起動して初回応答の遅延を抑えられる。
仮想ネットワーク統合：VNet内の他Azureサービスへ閉じた経路で接続できる。
ランタイムはv4.x以降のみ対応。旧Functions Proxiesは利用不可。

プランの選び方の判断基準

迷ったらFlex Consumptionを起点に、要件が合わなければ上位プランを検討する順が実務的です。最初に効くのはネットワークとコールドスタートの要件で、VNet内リソースへ閉域接続したい、あるいは初回応答の遅延を避けたいならFlexのalways readyかPremiumを選びます。次に効くのがOSで、Windowsが必須ならFlexは選べないためPremiumかDedicatedに絞られます。加えて、すでにApp Serviceプランに空きがあり相乗りでコストを抑えたいならDedicatedが候補です。なお、既存のConsumptionアプリはFlexへの移行が推奨されていますが、別プランからFlexへのインプレース移行はできず、新規アプリを作ってコードを再デプロイする必要があります。

Azure Functionsの料金体系と無料枠

Functionsのサーバーレスプランは、常時起動の月額ではなく「実行回数」と「実行時間×メモリ」で課金される従量制です。実行時間はメモリ量とのかけ算で「GB秒（GB-seconds）」という単位で計算されます。Flex Consumptionのon demandモードでは、毎月次の無料枠がサブスクリプション単位で提供されます（金額・無料枠は変動するため、最新は公式の料金ページで確認してください）。

無料枠（Flex on demand）：月あたり250,000回の実行と 100,000 GB秒。
実行回数：無料枠超過分は100万回あたり約$0.40。
実行時間：約$0.000016/GB秒。always readyの待機分（ベースライン）は約$0.000004/GB秒。
課金の丸め：1回の最小課金時間は1,000ミリ秒。以降は100ミリ秒単位で切り上げ。

ポイントは、無料枠の範囲で収まる小規模な用途なら実質無償で運用できる一方、常時高頻度で動かすと従量課金がかさみ、Premiumの予約インスタンスの方が安くなる分岐点が存在することです。想定リクエスト数とメモリ設定（512/2048/4096MB）を仮置きしてGB秒を試算し、無料枠と単価に当てはめて概算する手順を踏むと、プラン選定と同時にコストの見通しが立てられます。

Azure Functionsの使い方：対応言語から作成・デプロイまで

対応言語とランタイム（v4・分離ワーカーモデル）

現行ランタイムはv4系です。Flex Consumptionで対応する言語スタックは次のとおりで、いずれも比較的新しいバージョンが要求されます。

言語	対応バージョン（Flex）
C#（分離ワーカー）	.NET 8 / 9 / 10
Java	8 / 11 / 17 / 21 / 25
Node.js	22 / 24
Python	3.10 / 3.11 / 3.12 / 3.13 / 3.14
PowerShell	7.4

C#はホストと同一プロセスで動く従来のin-processモデルではなく、分離ワーカーモデル（isolated worker）が前提です。Flex ConsumptionではC# in-processは動作しません。この違いは後述の移行期限に直結するため、新規開発は最初から分離ワーカーで始めるのが安全です。

作成からローカル開発・デプロイまでの流れ

基本の開発サイクルは「ローカルで作って動作確認し、クラウドへデプロイする」形です。手順は次の順で進めます。

手順1・環境準備：Azure Functions Core Toolsと、使用言語のSDK（.NET/Node.js/Python等）をインストールする。
手順2・プロジェクト作成：関数プロジェクトを初期化し、トリガー種別（HTTP/Timer/Blobなど）を選んで関数を追加する。
手順3・ローカル実行：Core Toolsのローカルランタイムで起動し、HTTPトリガーならローカルURLに対して動作を確認する。バインディング先のストレージやDBはエミュレーターで代替する。
手順4・デプロイ：Flex Consumptionではコードをzip化してBlobストレージのコンテナへ配置し、起動時にそのパッケージから実行される方式。手動デプロイのほか、CI/CDで自動化するのが定石。

チーム開発では、デプロイをパイプライン化しておくとレビュー済みコードだけが本番へ流れます。具体的な組み方はAzure Pipelinesの使い方（YAMLでCI/CDを組む手順）が参考になります。

導入前に押さえる注意点（2026年時点）

Functionsは万能ではありません。採用判断で失敗しやすいポイントと、この時期に特有の移行期限を明確にしておきます。

.NET in-processモデルは2026年11月10日でサポート終了

C#で開発する場合の最重要事項です。従来のin-processモデルは2026年11月10日でサポートが終了します（Microsoftのリタイア告知）。終了後もアプリは動き続けますが、セキュリティ更新・機能追加が止まり、新規のin-processアプリはデプロイできなくなります。既存のin-processアプリは、期限までに分離ワーカーモデルへ移行してください。移行の作業量はアプリの規模や依存関係によって変わるため、期限から逆算して早めに移行計画を立てておくと安全です。

Functionsを選ぶべきでない場面

次のようなケースでは、Functionsは適さないか、割高になります。第一に、数十分以上動き続ける長時間処理です。プランごとに実行時間の上限があり、バッチが長引くとタイムアウトします。第二に、常時高トラフィックで休みなく稼働するサービスで、この場合はスケール・トゥ・ゼロの利点が活きず、Premiumの予約インスタンスやコンテナ基盤の方がコスト効率で勝ります。第三に、状態を保持し続ける処理で、関数はステートレスが基本のため、状態管理はDurable Functionsや外部ストレージへ切り出す設計が必要です。

AWS Lambdaとの使い分け

他クラウドのFaaSとしてはAWS Lambdaが代表格で、コンセプトはよく似ています。判断はどのクラウドに主軸を置くかで決めるのが実務的です。既存資産やデータベース、認証がAzure中心（App Service、Cosmos DB、Microsoft Entra IDなど）なら、バインディングで同一エコシステム内をつなげるFunctionsが有利です。逆にAWS上に基盤が集約されているならLambdaが自然で、FunctionsとLambdaを機能比較だけで選ぶより、周辺サービスとの連携コストで選ぶ方が運用の手戻りが少なくなります。