--- title: "Azure Functionsとは？仕組み・料金プラン・使い方をわかりやすく解説【2026年版】" url: "https://www.issoh.co.jp/tech/details/3171/" published: 2024-07-29 updated: 2026-07-23 categories: ["Azure"] publisher: "株式会社一創" --- # 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とは](https://www.issoh.co.jp/tech/details/15527/)で解説しています。 バインディングは、外部サービスとのデータ入出力を接続情報の宣言だけで実現する仕組みです。入力バインディングでCosmos DBのドキュメントを読み込む、出力バインディングでQueueにメッセージを書き込む、といった処理をSDKの初期化コードなしに属性やコンフィグで記述できます。データベースを扱う関数なら、接続を[Azure Cosmos DB エミュレーターを使ったローカル開発](/tech/details/6259/)で先に確認しておくと、バインディングの設定ミスを本番前に潰せます。 ## Azure Functionsでできること・主なユースケース Functionsが向くのは「イベントに反応する、比較的短時間で終わる処理」です。具体的には次のような用途で使われます。 - **Web APIやWebhookのバックエンド**：HTTPトリガーでREST APIを構築し、フロントエンドや外部サービスからの通知を受ける。 - **定期バッチ**：タイマートリガーで、夜間の集計・データクレンジング・レポート生成を無人実行する。 - **ファイル処理**：Blob Storageへの画像アップロードをトリガーにサムネイル生成や解析を行う。 - **データ連携・ETL**：Queueやイベントを起点に、システム間のデータ変換・転送をつなぐ。 - **SPAのAPI層**：静的サイトの動的処理を担う。フロントとセットで作るなら[Azure Static Web Appsの料金と構成](/tech/details/3175/)と組み合わせると、Functionsがそのままバックエンドになる。 逆に、数十分以上動き続ける長時間処理や、常時高負荷で稼働し続けるサービスには向きません（後述の注意点を参照）。作ったAPIを社外に公開・保護したい場合は、[Azure API Managementで料金プランやできることを確認](/tech/details/3162/)し、認証・レート制限・バージョニングを前段に置く構成が定番です。 ## ホスティングプランの種類と選び方 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を組む手順）](/tech/details/3176/)が参考になります。 ## 導入前に押さえる注意点（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を機能比較だけで選ぶより、周辺サービスとの連携コストで選ぶ方が運用の手戻りが少なくなります。 ## よくある質問（FAQ） ### Azure FunctionsはREST APIとして使えますか？ 使えます。HTTPトリガーで関数を作ると、その関数がHTTPエンドポイントになり、GET/POSTなどのリクエストを受けてJSONを返すREST APIとして機能します。社外公開や認証・レート制限を加えるなら、前段にAPI Managementを置く構成が一般的です。 ### AWS Lambdaとの違いは何ですか？ どちらもイベント駆動のサーバーレスFaaSで基本思想は同じです。違いは動作クラウドと周辺サービスの連携で、FunctionsはAzureの各サービスとバインディングで密に接続でき、LambdaはAWSサービスと親和性が高い点です。主軸のクラウドに合わせて選ぶのが実務的です。 ### 無料で使えますか？ Flex Consumptionのon demandには月あたり250,000回の実行と100,000 GB秒の無料枠があり、この範囲に収まる小規模用途なら実質無償で運用できます。超過分は実行回数と実行時間（GB秒）に応じた従量課金です（最新の金額は公式料金ページで確認してください）。 ### どのプログラミング言語が使えますか？ C#（分離ワーカー）、Java、Node.js、Python、PowerShellに対応します。Flex Consumptionでは、C#は.NET 8/9/10、Node.jsは22/24、Pythonは3.10〜3.14など、いずれも新しめのバージョンが求められます。 ### コールドスタートは避けられますか？ 完全には避けられませんが、緩和できます。Flex Consumptionのalways readyインスタンスを1以上に設定して最低台数を常時起動しておくか、常時暖機が前提のPremiumプランを選ぶと、初回応答の遅延を抑えられます。 ## 関連記事 - [Azure API Managementとは？料金プラン・できること・使い方を解説【2026年版】](/tech/details/3162/) - [Azure Static Web Appsの料金｜Freeと有料Standardの違い・費用を実額で解説【2026年版】](/tech/details/3175/) - [Azure Cosmos DB エミュレーターを使ったローカル開発の全体像](/tech/details/6259/) - [Azure Pipelinesの使い方｜YAMLでCI/CDを組む手順と無料枠・権限設定](/tech/details/3176/) - [Azure DevOpsは日本語化できる？UIを日本語にする方法とServices/Serverの違い](/tech/details/6763/) --- 出典: [Azure Functionsとは？仕組み・料金プラン・使い方をわかりやすく解説【2026年版】]()（株式会社一創）