Event Grid トリガー は、Azure Event Grid から送信されるイベントを受信して実行されるトリガーです。Azure Storage、Key Vault、Custom Topic、System Topic などのイベント ソースから通知を受け取り、イベント駆動で関数を起動できます。
Event Grid トリガーはプッシュ型のトリガーであり、関数アプリ側がイベントをポーリングするのではなく、Event Grid が HTTP 経由でイベントを配信します。そのため、イベントの到達性、サブスクリプション設定、エンドポイント検証が動作成立の前提となります。
公式ドキュメントにも記載のとおり、Event Grid トリガーは内部ロード バランサー構成の App Service Environment (ASE) ではネイティブにはサポートされません。仮想ネットワーク越しの到達性に制約がある環境では、イベントが関数アプリまで届かない場合があります。
動作の仕組み
Event Grid トリガーの動作は以下の流れとなります。
- イベント ソースの変更発生: Blob 作成、リソース変更、カスタム イベント発行などが発生します。
- イベント サブスクリプションによる配信先決定: Event Grid が構成済みのイベント サブスクリプションに従い、関数アプリのエンドポイントへイベントを送信します。
- エンドポイント検証: サブスクリプション作成時や必要に応じて、Event Grid がエンドポイントの到達性と応答を検証します。
- 関数の実行: 受信したイベントが、利用する言語やプログラミング モデルに応じた型または JSON ペイロードとして関数へ渡されます。
- 処理結果に応じた再試行: 配信が成功しない場合、Event Grid 側の再試行ポリシーに基づき再配信される場合があります。
受信イベントのスキーマは、イベント ソースやイベント サブスクリプションの設定にも依存します。共通プロパティとイベント固有プロパティについて詳しくは、Event Grid のドキュメントのイベントのプロパティにまとめられています。
Webhook エンドポイントについて
/runtime/webhooks/eventgrid エンドポイントが使用されます。
Azure Event Grid からの HTTP プッシュ配信を Functions ランタイムが受け付ける拡張 Webhook 入口です。Functions 側では Event Grid 拡張がこの入口で要求を受け取り、該当の EventGrid トリガー関数を起動します。
システムキーについて
EventGrid トリガーでは、 Event Grid Webhook に固有の承認キーであるシステム キーを Event Grid トリガーのエンドポイント URL への要求に含める必要があります。
作成手順
Event Grid トリガーの作成方法は チュートリアル で紹介されているテンプレートをご利用ください。チュートリアルでは HTTP トリガーを利用しておりますが、同画面にて Event Grid トリガーを選択いただくことができます。
Event Grid は HTTP プッシュ配信であるため、Functions 側でのコード作成に加えて、イベント サブスクリプション設定が必須です。コードだけ作成してもイベントは自動では流れてこない点に注意してください。
実行状況をログで確認する
実行詳細をログから確認します。host.json の logging で下記のカテゴリのログを出力するように設定します。デバッグ用となるため、運用状況によって有効/無効化を検討ください。
host.json
1 | "logging": { |
Application Insights で利用するクエリ
実行ログ
1 | traces |
例外ログ
1 | exceptions |
上記の設定を行った際に記録されるログの例です。
関数起動時には Webhook として受け付けるエンドポイントがログに記録されます。
traces ログ:

正常実行時では、システム キーを使用し、認証に成功した後に、関数の実行ログである Executing~ と Executed~ が記録されていることを確認できます。
traces ログ:

並行処理とチューニング
並行処理の考え方
Event Grid トリガーはプッシュ型であり、イベント到着に応じて関数が実行されます。イベント(Webhook へのリクエスト)が短時間に集中した場合、Azure Functions は受信した要求を処理するために複数インスタンスへスケール アウトが行われます。
そのため、並行度のチューニングは HTTP トリガー同様に host.json で構成可能な maxConcurrentRequests (実際に処理が行われる並行実行数)と maxOutstandingRequests (実行中のリクエストを含めて、保持しておくリクエスト数)を調整します。
よくお問い合わせいただく動作
イベント サブスクリプションを作成したが関数が実行されない
Event Grid トリガーで最も多い確認ポイントは、イベント サブスクリプション自体が正しく構成されているか、また配信先エンドポイントに到達できるかです。
この場合、Azure Functions までリクエストが到達していない状況となるため、Azure Functions ではログが記録されません。
また、Event Grid 側では配信失敗の場合には記録がされますが、フィルタにて除外されている場合は記録されない点も注意が必要です。
対処方法:
- イベント サブスクリプションが正しいイベント ソースとイベント種別を対象にしているか確認してください
- 配信先として正しい関数エンドポイントを指定しているか確認してください
- 関数アプリが Event Grid から到達可能なネットワーク構成であることを確認してください
- Event Grid 側の配信失敗や検証失敗が記録されていないか確認してください
サブスクリプション作成時の検証に失敗する
Event Grid は配信先エンドポイントの検証を行います。検証要求に対して期待どおりの応答が返せない場合、サブスクリプション作成や更新に失敗する場合があります。
例)ネットワーク制限のかかった Azure Functions に az eventgrid でサブスクリプションを作成しようとすると以下のようにエラーが出力されます。
(URL validation) Webhook validation handshake failed for
https://<関数リソース名>.azurewebsites.net/runtime/webhooks/eventgrid.
Http POST request failed with response code Unknown.
対処方法:
- 関数エンドポイントが外部から到達可能であることを確認してください
- 必要な認証設定が Event Grid の配信方式と整合しているか確認してください
- ネットワーク制限、アクセス制限、プライベート エンドポイント設定を確認してください
同じイベントが複数回処理されたように見える
Event Grid では、配信失敗やタイムアウト時にイベントが再試行される場合があります。そのため、関数側から見ると同一イベントが複数回届いたように見えることがあります。
以下は例外時にイベント ID を記録するように実装した際の例となりますが、同一のイベント ID で再試行されていることが確認できます。
exceptions ログ:

対処方法:
- イベント ID や関連キーを用いて重複処理を判定できるようにしてください
- 出力先の更新処理は冪等に設計してください
- 一時的な失敗であるか恒常的な失敗であるかをログで切り分けてください
ASE や閉域構成で動作しない
公式ドキュメントにもある通り、Event Grid トリガーは内部ロード バランサーの App Service Environment (ASE) ではネイティブにサポートされません。閉域構成で Event Grid からの HTTP リクエストが到達しない場合には、正常に動作しない可能性があります。
対処方法:
- 配信元からエンドポイントへ到達できる構成かを確認してください
- 必要に応じて中継コンポーネントや代替アーキテクチャを検討してください
まとめ
本記事では Event Grid トリガーの基本動作、作成方法、ログ確認、よくある問い合わせの観点を整理しました。Event Grid トリガーは Azure リソースのイベント駆動連携に適しており、ポーリング不要でリアルタイムに近い処理を実装できます。一方で、配信先の到達性、イベント サブスクリプション構成、再試行を前提とした冪等設計が安定運用のポイントとなります。
参考ドキュメント
Azure Functions の Event Grid トリガー
Azure Functions の Event Grid バインディングの概要
2026 年 5 月 22 日時点の内容となります。
本記事の内容は予告なく変更される場合がございますので予めご了承ください。
※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。