Azure Functions入門 サーバーレスの基礎からトリガー・料金・AWS Lambdaとの違いまで現場で使える実践ガイド

「サーバーを立てずにコードだけ動かしたい」「イベント駆動でちょっとした処理を回したいが、VMを24時間動かすのはコスト的に厳しい」――オンプレでcronやバッチサーバーを運用してきたエンジニアなら、一度はこう考えたことがあるはずです。Azure FunctionsはまさにそのニーズにこたえるMicrosoft Azureのサーバーレスコンピューティングサービスで、コードの実行に必要な時間とリソースだけに課金される仕組みが特徴です。

ただ、AWS Lambdaと似ているようで、トリガー設計・料金プラン・コールドスタートの挙動・ローカル開発の流儀などに無視できない違いがあり、オンプレ経験者が移行時にハマるポイントも多くあります。

この記事では、Azure Functionsについて、オンプレ経験者にもわかりやすく解説します。サービスの概要、基本的な関数アプリ作成手順、料金プランの選び方、AWS Lambdaとの違い、よくあるトラブルまで、現場で使える知識をひととおりカバーします。

なぜAzure Functionsなのか？（オンプレとの違い・背景）

オンプレ環境では、定期バッチは専用サーバーのcronで、イベント処理は常駐デーモンで、APIはWebサーバー+アプリで――というようにサーバーを立てて動かすのが当たり前でした。しかし、実際の稼働率は数%ということも多く、アイドル時間分も電気代・ハードウェア減価償却・ライセンス費用がかかります。

Azure Functionsは「コードが動いた時間だけ課金される」サーバーレスモデルで、この無駄を丸ごと排除できます。インフラエンジニアにとって重要な違いは次のとおりです。

・サーバー管理が不要: OSパッチ、ミドルウェア更新、スケーリング設計はAzure側が担当
・自動スケール: リクエスト数に応じてインスタンスが自動で増減（最大200インスタンスまで）
・イベント駆動: HTTP・タイマー・Blob・Queue・Event Gridなど20種類以上のトリガーに対応
・従量課金: 実行回数と実行時間（GB秒）に応じた料金体系
・多言語対応: C#、Python、Node.js、Java、PowerShellなどで関数を記述可能

特にオンプレから移行する場合、「バッチ処理サーバー」「Webhook受信サーバー」「軽量API」の3領域はAzure Functionsに置き換えるだけでコストが半分以下になるケースも珍しくありません。

AWS Lambdaとの関係

Azure FunctionsはAWS Lambdaと同じ「FaaS（Function as a Service）」カテゴリに属します。思想もアーキテクチャもかなり似ていますが、Azure Functionsには「Durable Functions」というステートフルなワークフローを書く拡張機能が標準搭載されているなど、独自の強みがあります。詳細は後の比較セクションで触れます。

基本的な使い方（Azure PortalとAzure CLIでの関数アプリ作成）

ここでは、最小構成のHTTPトリガー関数をAzure Portalで作成する手順と、Azure CLIでの同等操作を示します。

1. リソースグループと関数アプリを作成

関数を動かすには、まず「関数アプリ（Function App）」という入れ物を作ります。関数アプリは1つ以上の関数をまとめる単位で、ストレージアカウント・App Service Plan・Application Insightsなどの関連リソースと紐づきます。

Azure Portalでの手順は次のとおりです。

・Portalの「リソースの作成」→「関数アプリ」を選択
・サブスクリプション、リソースグループ、関数アプリ名を入力
・ランタイムスタック（例: Python 3.11）とリージョン（例: Japan East）を選択
・ホスティングプラン（従量課金プラン / Premium / App Service）を選択
・「確認および作成」でデプロイ

Azure CLIで同じことをするなら、以下のコマンドになります。

# Azure CLI
# リソースグループ作成
az group create --name rg-functions-demo --location japaneast

# ストレージアカウント作成（Functionsの内部状態保存用、必須）
az storage account create \
  --name stfuncdemo001 \
  --location japaneast \
  --resource-group rg-functions-demo \
  --sku Standard_LRS

# 関数アプリ作成（従量課金プラン/Consumption）
az functionapp create \
  --resource-group rg-functions-demo \
  --consumption-plan-location japaneast \
  --runtime python \
  --runtime-version 3.11 \
  --functions-version 4 \
  --name func-demo-001 \
  --storage-account stfuncdemo001 \
  --os-type Linux

2. HTTPトリガー関数を追加する

関数アプリを作成したら、その中に関数を追加します。VSCode拡張機能「Azure Functions」を使う方法がもっともスムーズですが、Portalのコードエディタで直接書くことも可能です。

Pythonでの最小HTTPトリガー関数の例は次のとおりです。

# function_app.py（Python v2プログラミングモデル）
import azure.functions as func
import logging

app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)

@app.route(route="hello")
def hello(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('HTTP trigger function processed a request.')
    name = req.params.get('name', 'World')
    return func.HttpResponse(f"Hello, {name}!", status_code=200)

3. デプロイと動作確認

ローカルで書いたコードをAzureにデプロイするには、Azure Functions Core Toolsの`func azure functionapp publish`コマンドが定番です。

# Azure CLI + Core Tools
# ローカル開発環境でテスト
func start

# Azureへデプロイ
func azure functionapp publish func-demo-001

# デプロイ後の関数URLを取得
az functionapp function show \
  --name func-demo-001 \
  --resource-group rg-functions-demo \
  --function-name hello \
  --query invokeUrlTemplate

取得したURLに `?name=Azure` を付けてcurlで叩けば、”Hello, Azure!” が返ってきます。ここまでで、サーバー1台も立てずにHTTP APIが公開された状態です。

料金の仕組み（コスト感覚）

Azure Functionsの料金プランは大きく3種類あり、選び方を間違えると無駄なコストが発生します。

従量課金プランの料金は、2026年4月時点で以下のとおりです（東日本リージョン）。

・実行回数: 月間100万回まで無料、以降100万回ごとに$0.20
・実行時間: 月間40万GB秒まで無料、以降1GB秒あたり$0.000016
・最低メモリ: 128MB単位で切り上げ（実メモリ使用量が65MBでも128MBとして課金）

この料金体系なら、月10万回程度の軽量API・バッチ処理は事実上無料で動きます。オンプレで専用VMを立てていた場合と比較すると、年間数十万円のコスト削減になることも珍しくありません。

【重要】コスト見積もりの落とし穴

従量課金プランは安く見えますが、以下のケースではPremiumやApp Service Planの方が安くなります。

・常時アクセスがあるAPI: 実行時間が積み上がり、従量課金の方が高くなる
・VNet統合が必要: 従量課金プランではVNet統合不可、Premium以上が必須
・コールドスタートを許容できない: Premiumの事前ウォームインスタンスが必要

応用・実務Tips

Durable Functionsでステートフルな処理を書く

Azure Functionsは本来ステートレスですが、「Durable Functions」という拡張を使うと、複数の関数をオーケストレーションして状態を持った長時間処理を記述できます。AWS Step Functionsに相当する機能ですが、コード上で直感的に書ける点が優れています。

典型的なユースケースは、「承認フロー」「外部API呼び出し後の結果ポーリング」「ファンアウト/ファンインの並列処理」などです。

Application Insightsでの監視

関数アプリ作成時に自動でApplication Insightsが有効化されます。実行時間、失敗回数、コールドスタート発生頻度、例外スタックトレースなどが自動収集され、PortalのダッシュボードでKQLクエリを書いて可視化できます。オンプレでMackerelやPrometheusを運用していたエンジニアにとっては、「監視基盤を別途構築する必要がない」というのは大きなメリットです。

ローカル開発はVSCode拡張機能を使う

Azure Functions Core Tools単体でも開発できますが、VSCodeのAzure Functions拡張機能を使えば、プロジェクト作成・ローカル実行・デプロイ・ログ監視がすべてGUIで完結します。特にPythonやTypeScriptの開発者は、これを使わない理由がありません。

AWS Lambdaとの使い分け

マルチクラウド戦略で両方使う場合、選定基準は次のように整理できます。

・AWS中心の環境: S3・DynamoDB・SQSとの連携が多いならLambda
・Azure中心の環境: Azure AD認証・Microsoft 365連携・Cosmos DB利用ならFunctions
・ステートフルな長時間処理: Durable Functionsが書きやすいのでAzure有利
・コールドスタート要件が厳しい: LambdaのSnapStart（Java向け）かAzure Premiumプラン

よくあるトラブルと対処法

コールドスタートが遅すぎる

従量課金プランでは、一定時間アクセスがないとインスタンスが破棄され、次回リクエスト時に数秒のコールドスタートが発生します。.NETやJavaで顕著で、時には10秒以上かかることも。対処法は以下のとおりです。

・Premiumプランへ移行: 事前ウォームインスタンスでコールドスタートを排除
・軽量ランタイム選択: PythonやNode.jsは比較的早い
・定期Warmup: 5分間隔でタイマートリガーから自己HTTP呼び出し（簡易対策）

関数のタイムアウトで処理が途中終了する

従量課金プランの最大実行時間は10分（デフォルトは5分）です。長時間処理にはPremiumプラン（最大60分）を使うか、Durable Functionsでオーケストレーションに分割します。

Storageアカウント権限エラー

関数アプリはメタデータとトリガー状態を内部でストレージアカウントに保存するため、ストレージアカウントへのアクセス権がないとデプロイ直後から動きません。AzureAD認証に切り替える場合は、マネージドIDに「Storage Blob Data Owner」ロールを付与するのを忘れずに。

VNet統合できない

従量課金プランはVNet統合に対応していません。オンプレVPNや閉域網内のDBに接続する場合は、必ずPremiumプランかApp Service Planを選ぶ必要があります。これは料金体系と並ぶ「プラン選定時の最重要ポイント」です。

本記事のまとめ

Azure Functionsはオンプレのバッチサーバー・Webhookサーバー・軽量APIを置き換える強力なサーバーレス基盤です。本記事で解説したポイントを整理します。

・サーバー管理が不要で、コードの実行時間だけに課金される
・20種類以上のトリガーでイベント駆動処理を簡潔に書ける
・料金プランは3種類あり、ワークロード特性で選び分ける必要がある
・Durable Functionsでステートフルなワークフローも記述可能
・VNet統合やコールドスタート排除にはPremium以上が必須
・Application Insightsで監視基盤を別途用意する必要がない

クラウド上のLinux VMでバッチやAPIを動かしているなら、まずは最も利用頻度の低いスクリプトから1本、Azure Functionsに移してみることをおすすめします。実際に動かしてみると、運用負荷とコスト両面での効果を体感できるはずです。

なお、Azure Functionsから呼び出すことが多いLinuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。クラウドのIAM・暗号化まわりのセキュリティ基礎はSecurityMasters.TOKYOも参考になります。