Azure Functions トリガー・バインディング シリーズ - HTTP / Webhook トリガー

Published: feedback 共有

HTTP トリガー は、HTTP 要求を受信したタイミングで関数を実行するトリガーです。Azure Functions で API エンドポイントを公開する用途のほか、Webhook の受信口としても広く利用されます。

HTTP トリガーでは、受信した HTTP メソッド、URL パス、クエリ文字列、ヘッダー、本文を関数コードで扱うことができます。具体的な要求オブジェクトや応答オブジェクトの型は、利用する言語やプログラミング モデルによって異なりますが、いずれも HTTP 要求を受け取り、HTTP 応答を返すという基本的な考え方は共通です。

HTTP でトリガーされた関数の既定の戻り値は、Functions 2.x 以降では本文が空の HTTP 204 No Content です。任意のステータス コードやレスポンス本文を返したい場合は、出力として明示的に HTTP 応答を構成します。

動作の仕組み

HTTP / Webhook トリガーの動作は、概ね以下の流れとなります。

  1. HTTP 要求の受信: Azure Functions Host が公開している HTTP エンドポイントに対してクライアントまたは外部サービスから要求が送信されます。
  2. ルーティング: Host が関数名や Route 設定に基づき、対象の HTTP トリガー関数へ要求を振り分けます。
  3. 認証・認可の判定: AuthorizationLevel や App Service Authentication / Authorization などの設定に応じて、要求の許可可否が判定されます。
  4. 関数の実行: 関数コードが実行され、要求本文、ヘッダー、クエリ文字列、ルート パラメーターなどが処理されます。
  5. HTTP 応答の返却: 関数の戻り値またはレスポンス オブジェクトに基づいて、クライアントへ応答が返されます。

Webhook シナリオでも基本的な流れは同様ですが、送信元サービス固有の署名検証やチャレンジ応答が必要となる場合があります。その場合は、送信元サービスの仕様に従ってヘッダーや要求本文を検証してください。

作成手順

HTTP トリガーの作成方法は、チュートリアルで紹介されているテンプレートをご利用ください。
コード例として、以下では C# で HTTP トリガーを定義しています。

1
2
3
4
5
6
7
8
9
[Function("HttpFunction")]
public static HttpResponseData Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = "items/{id?}")] HttpRequestData req,
    FunctionContext context)
{
    var response = req.CreateResponse(HttpStatusCode.OK);
    response.WriteString("OK");
    return response;
}

主要な設定項目は以下の通りです。

属性 主な設定値 説明
AuthorizationLevel Anonymous / Function / Admin 関数キーの要否を制御します
methods get, post, put, delete など 許可する HTTP メソッドを制限します
Route 任意のルート テンプレート URL パスを関数へマッピングします

Azure 上にデプロイする場合、HTTP エンドポイントは関数アプリの URL 配下に公開されます。Webhook の送信先として利用する場合は、送信元サービスから到達できる URL であること、必要に応じてキーまたは認証を設定していることを確認してください。

実行状況をログで確認する

HTTP トリガーの実行詳細をログから確認します。host.json の logging で下記のカテゴリのログを出力するように設定します。デバッグ用となるため、運用状況によって有効/無効化を検討ください。

host.json

1
2
3
4
5
6
7
8
"logging": {
  "logLevel": {
        "default": "Information",
        "Host.Results": "Debug",
        "Host.Aggregator": "Debug",
        "Function": "Debug"
  }
}

Application Insights で利用するクエリ

HTTP トリガーは要求駆動で実行されるため、Application Insights では requests テーブルと traces テーブルを中心に確認することが一般的です。関数実行時のアプリケーション ログは traces、HTTP 要求単位の成否や応答時間は requests に記録されます。

HTTP 要求の成否と応答時間

1
2
3
4
5
6
requests
| where timestamp > datetime("yyyy-mm-dd hh:mi")
| where cloud_RoleName =~ "<関数アプリ名>"
| where operation_Name =~ "<関数名>"
| project timestamp, name, resultCode, success, duration, operation_Id
| order by timestamp asc

実行時ログの確認

1
2
3
4
5
6
traces
| where timestamp > datetime("yyyy-mm-dd hh:mi")
| where cloud_RoleName =~ "<関数アプリ名>"
| where operation_Name =~ "<関数名>"
| project timestamp, message, severityLevel, operation_Id
| order by timestamp asc

例外ログの確認

1
2
3
4
5
exceptions
| where timestamp > datetime("yyyy-mm-dd hh:mi")
| where cloud_RoleName =~ "<関数アプリ名>"
| project timestamp, outerMessage, details, operation_Id
| order by timestamp asc

上記の設定を行った際に記録されるログの例です。

起動時のログ

起動処理を行った際に、定義している関数のルートをマッピングしていることがわかります。
下記の例では 5 つの関数を定義しており、それぞれのパス、及び、許可しているメソッドが確認できます。

traces ログ：

image.png

実行ログ

HTTP のリクエストを受け付けるとトリガーが実行されます。
requests テーブルでは HTTP 要求としてのステータス コードや処理時間が確認でき、traces テーブルでは HTTP 要求の認証を行った後に、Executing~ と Executed~ にて実行状況が記録されます。
アプリケーションが正常に終了した場合でも、ステータスコードを意図的に変更している場合は、両テーブルにおける実行結果の記録が異なる点にご留意ください。
それぞれのテーブルは operation_Id の値で関連付けが可能です。

requests ログ：

image.png

traces ログ：

image.png

並行処理とチューニング

並行処理の考え方

HTTP トリガーは HTTP 要求を受けて都度実行されるため、HTTP 要求が短時間に集中した場合、Azure Functions は受信した要求を処理するために複数インスタンスへスケール アウトが行われます。

チューニングの観点

HTTP トリガーは host.json で構成可能な maxConcurrentRequests と maxOutstandingRequests をチューニングして並列度を調整します。

maxConcurrentRequests は並行実行数の定義となり、リソース使用率に直結するため、アプリケーションの処理内容に応じた値に調整する必要があります。値が大きいほど同時に処理できる量は増えますが、リソース消費量が多くなります。

例として、応答に約 15 秒がかかる アプリケーションにて maxConcurrentRequests を 2 として設定した際に同時に複数リクエストを発行します。
HTTP 要求を記録する requests テーブルでは、0:07:43 ～ 0:07:44 間に 5 件リクエストが来ていますが、応答まで要した時刻に差が生じます。
traces テーブルを確認するとアプリケーションの処理開始となる Executing ~ の記録が並行実行数の 2 を上限に前の処理が終わるのを待ち合わせていることがわかります（各マーカーの色にてテーブル間のログの関連性を示しています）。
また、処理時間はいずれも 15 秒程となり、アプリケーションの処理に時間を要したわけではなく、キューに滞留したため、HTTP 応答として時間がかかったことを確認できます。

requests ログ：

image.png

traces ログ：

image.png

maxOutstandingRequests は実行中のリクエストを含め、処理待ちとして許可するリクエスト数を定義し、この値を超過することでスケール アウトの判断が行われます。値が大きすぎると、HTTP の要求数に対して、待機数が多いためスケール アウトが遅延する可能性があります。逆に小さすぎるとスケール条件が厳しくなるため、リソース状況に余裕があるにも関わらず、過剰にインスタンスを確保する状況となります。

こちらも例として、応答に約 15 秒がかかる アプリケーションにて maxConcurrentRequests 、及び maxOutstandingRequests を 2 で設定し、複数のリクエストを発行します。
maxOutstandingRequests を超過した場合には Azure Functions の HTTP 要求を受け付ける Front End という内部ロード バランサーにて要求が破棄されるため、アプリケーションまでリクエストが到達せずに requests テーブル、及び、traces テーブルにはログが残りません。
クライアントには下記の図のようにステータス コード 429 が応答されます。

image.png

リソース状況を鑑みて、2 つのパラメーターを定義することで、何件まで並行実行するか、どのくらいのトラフィック量でスケール アウトさせるべきかを調整することができます。

よくお問い合わせいただく動作

弊サポートにてよくお問い合わせいただく事例について紹介します。下記に記載しますログ出力例は、Function Host のランタイム バージョンが v4.1048.200.26180 時点の例となります。バージョンが異なることにより出力内容が異なる可能性がありますことをご留意ください。なお、ログは Application Insights で利用するクエリ、及び、以下のエラー詳細を確認するクエリを実行した結果より確認しています。

デプロイ後に HTTP エンドポイントへアクセスできない

本事象は Azure Functions までリクエストが到達していない可能性が高く、クライアント側で 404 エラーが記録されるものの、Application Insights のログに記録されないことがあります。
Azure 上へ展開した後にエンドポイントへアクセスできない場合、まず URL、ルート、ネットワーク制限を確認します。

確認ポイント:

  • 関数 URL が正しいことを確認してください
  • Route の設定により期待するパスと実際のパスがずれていないか確認してください
  • アクセス制限、プライベート エンドポイント等で到達性が制限されていないか確認してください

Webhook の送信元から 401 / 403 が返る

Webhook 受信で 401 / 403 が返る場合、Functions 側の認証設定と送信元サービスの送信仕様が一致していない可能性があります。
traces テーブルで認証失敗していることが確認できます。
なお、処理としては正常（意図したアクセス拒否）なため、exceptions テーブルにはログが出力されない点をご留意ください。

traces ログ：

image.png

対処方法:

  • 関数キーが必要な構成である場合、送信元がキーを付与できるか確認してください
  • 送信元でカスタム ヘッダーを送れる場合、署名検証ロジックと合わせて受信側実装を確認してください
  • Functions の組み込み認証やネットワーク制限が送信元からの通信を拒否していないか確認してください

長時間処理でタイムアウトや再試行が発生する

HTTP トリガーは、呼び出し元が同期的に応答を待つケースが多いため、処理時間が長いとクライアント側タイムアウトや送信元の再試行が発生することがあります。

また、Azure Functions において、HTTP 要求は 約 240 秒でタイムアウト(Windows アプリでは 230 秒、Linux アプリでは 240 秒)となるため、処理時間が長い場合にはエラーとなります。

HTTP 要求としてはタイムアウトとなった場合でもバックエンドで動作する関数が正常に完了した場合、ログ上はエラーとして記録がされない状況となります。
そのため、再試行処理が生じた際も同一結果となるよう冪等性を保つことが重要となります。

requests ログ：

image.png

traces ログ：

image.png

対処方法:

  • 即時応答が必要な部分と時間のかかる処理を分離してください
  • 重い処理は Queue Storage、Service Bus、Durable Functions などへ委譲する構成を検討してください

まとめ

本記事では HTTP / Webhook トリガーの基本動作、作成方法、ログ確認、運用時の留意点を整理しました。HTTP トリガーは Azure Functions でもっとも利用機会の多いトリガーのひとつであり、API と Webhook の両面で広く利用されます。安定運用のためには、認証、入力検証、外部接続管理、長時間処理の分離を合わせて検討することが重要です。

参考ドキュメント

Azure Functions の HTTP トリガー

Azure Functions の HTTP 出力バインディング

Azure Functions で接続を管理する方法

Azure Functions のスケールとホスティング





2026 年 6 月 23 日時点の内容となります。

本記事の内容は予告なく変更される場合がございますので予めご了承ください。



※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。