Azureを学ぶ Azure Event Grid について調べる

Last updated at 2026-02-11Posted at 2026-02-11

本記事は Microsoft Learn の「Azure Event Grid について調べる」というモジュールをまとめたものである。

Azure Event Grid について調べる

Azure Event Grid は、システム間の「出来事（イベント）」を効率的に届けるフルマネージドな Pub/Sub 型配信サービス。

1. 主な機能と役割

柔軟な接続：HTTP に加え、IoT 向けの MQTT プロトコル（v3.1.1 / v5.0）に対応
利用シーン：デバイスデータのパイプライン構築、アプリ統合、サーバーレスアーキテクチャの実現
相互運用性：業界標準の CloudEvents 1.0 に準拠し、異なるシステム間でも連携が容易

2. 配信パターン

プッシュ配信：Event Grid がサブスクライバーへ能動的にイベントを送信する
プル配信：サブスクライバー側が Event Grid に接続してイベントを読み取りに行く

3. メリット

高スケーラブル：大量のイベントを自動で処理可能
運用の簡略化：インフラ管理が不要なフルマネージドサービス

Azure Event Grid の概念

パブリッシャー（発行元）

Event Grid における「発行元」とは、システム内で発生したイベントを Event Grid に向けて送信する役割を持つアプリケーションやサービスを指す。

1. 発行元の種類と役割

イベントソースとの関係：イベントが発生した場所そのもの（ソース）が発行元を兼ねる場合が多い
Azure サービス：Azure 内部の各サービスが自身の状態変化を通知するために発行
カスタムアプリケーション：ユーザーが独自に構築したアプリや、Azure 以外で稼働するサービスからも発行可能

2. 「パートナー」という特別な発行元

定義：Azure 外部のサードパーティシステムからイベントを送信し、Azure ユーザーが利用できるようにする形態
双方向性：パートナーイベント機能を介して、イベントの発行だけでなく受信も可能
エコシステムの活用：外部 SaaS などとの高度な連携を実現

イベントと CloudEvents

イベントとは、システム内で起きた「出来事」を伝える最小単位の情報。Event Grid は標準規格を採用することで、異なるシステム間でもデータの中身を正しく理解できるようにしている。

1. イベントに含まれる情報
すべてのイベントは、共通の基本情報と、個別の詳細データで構成される。

共通項目：発生源（source）、発生時刻（time）、一意識別子（id）など
個別項目：そのイベント固有の詳細内容（注文IDやURLなど）

2. 標準規格「CloudEvents 1.0」

オープンスタンダード：CNCF（Cloud Native Computing Foundation）が策定した仕様に準拠
形式：JSON 形式で HTTP プロトコルを使用して通信
メリット：標準化されているため、異なるプラットフォームやサービス間での連携がスムーズになる

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "https://yourcompany.com/orders/",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

イベントソース

イベントソースは、その名の通り「イベントがどこから来たか」を指す発生源のこと。

1. イベントソースの役割

発生場所の特定：システム内で変化やアクションが起きた「現場」を指す
イベントの送信：発生した出来事を Event Grid へ向けて送り出す

2. 主な具体例

Azure Storage：新しいファイル（BLOB）が作成・削除された際にソースとなる
IoT Hub：接続されたデバイスからメッセージが届いた際にソースとなる
カスタムアプリケーション：ユーザーが独自に作成したアプリも、定義次第でソースになれる

3. イベントの種類との関係

多対多の関連性：1つのソースが「作成」「削除」「更新」など、複数の異なる種類のイベントを発生させることが可能

トピックの概要

トピックは、発行されたイベントを一時的に保持する「仕分け先」のリソース。サブスクライバー（受信者）は、どのトピックから情報を得るかを選択する。

1. トピックの役割

イベントの集約：関連するイベントをグループ化して管理する
購読の窓口：受信側が「どの情報が欲しいか」を指定する対象となる

2. トピックの 3 つの種類

システムトピック：Azure サービス（Storage 等）が標準で提供する組み込みトピック。リソース一覧には表示されないが、リソースへのアクセス権があれば購読可能
カスタムトピック：ユーザー独自のアプリやサードパーティ製アプリのために作成するトピック。自分のサブスクリプション内で管理・表示される
パートナートピック：特定の外部 SaaS パートナーからイベントを受け取るための専用トピック。パートナーイベント機能を通じて連携する

イベントサブスクリプション

イベントサブスクリプションは、「どのイベントを」「どこに届けるか」を定義する設定。これにより、Event Grid は膨大なイベントの中から必要なものだけを適切な場所に配送できる。

1. 主な役割

受信の意思表示：特定のトピックからイベントを受け取ることを Event Grid に登録する
エンドポイントの指定：イベントを処理する送り先（Azure Functions、Webhook など）を指定する

2. フィルタリング機能
すべてのイベントを受け取るのではなく、条件を絞り込んで受信可能。

イベントの種類：「作成時のみ」「削除時のみ」などのタイプで選択
サブジェクトのパターン：ファイル名やパスの特定パターン（前方一致・後方一致など）で絞り込み

3. 運用管理

有効期限の設定：期間限定のキャンペーンやテスト用に、サブスクリプションの自動消滅時間を設定できる
クリーンアップの自動化：使い終わった設定を手動で消す手間を省き、リソースの散らかりを防止する

イベントハンドラー

イベントハンドラーは、Event Grid から送られてきたイベントを受け取り、具体的な処理（アクション）を実行する「最終目的地」。

1. 役割と送り先

処理の実行：届いたデータをもとに、プログラムを動かしたりデータを保存したりする
多様な接続先：Azure サービス（Functions、Logic Apps、Event Hubs 等）や、独自の Webhook を指定可能

2. 配信の保証と再試行メカニズム
ハンドラーの種類に応じて、確実な配送を保証する仕組みがある。

HTTP Webhook：受信側が 200 OK を返すまで、Event Grid が繰り返し再試行を行う
Azure Storage Queue：キューへのメッセージ追加が正常に完了するまで再試行を継続
信頼性の確保：一時的なネットワークエラーや受信側の高負荷による取りこぼしを防止

セキュリティ

Event Grid は、イベントの「発行」と「購読（サブスクライブ）」の両面でアクセス制御を行い、安全な通信を確保する。

1. 購読のセキュリティ

権限の必要性：トピックを購読するには、そのリソースに対する十分なアクセス許可が必要
RBAC の活用：Azure のロールベースのアクセス制御により、誰が購読できるかを厳格に管理

2. 配信（プッシュ）の認証

マネージド ID の利用：イベントハンドラーが Azure サービスの場合、パスワード管理が不要なマネージド ID を使用して認証可能
適切なロール割り当て：ID に対して、送信先に応じた適切な権限を付与する必要がある
- 例：Event Hubs へ送るなら「Event Hubs データ送信者」ロールが必要

3. 発行の保護

認証の強制：トピックへイベントを投げ込む際も、正当な発行元であることを証明する認証が求められる

まとめると、

パブリッシャー：Event Grid に対してイベントを送信する、Azure サービスやカスタムアプリなどの発行元
イベント：システム内で「何が起きたか」を詳細に記述した、CloudEvents 等の標準形式に基づく最小限の情報
イベントソース：イベントが実際に発生した「現場」となる具体的なリソース（Storage や IoT Hub など）
トピック：発行されたイベントを集約し、受信者への窓口となる Event Grid 上の管理用エンドポイント
イベントサブスクリプション：どのイベントをどのハンドラーへ配送するかを定義する、フィルタ設定を含む配送伝票
イベントハンドラー：送られてきたイベントを受け取り、具体的な処理やアクションを最終的に実行する目的地

イベントスキーマの検出

Azure Event Grid がサポートする 2 種類のスキーマ（Event Grid スキーマ / CloudEvents スキーマ）の構造と制限についてのルール。

1. イベントの構造

共通プロパティ：すべての発行元で共通する 4 つの必須文字列プロパティで構成
データオブジェクト：各パブリッシャー（Azure Storage 等）固有の詳細情報が含まれる
スキーマストア：各 Azure サービスの具体的な JSON スキーマは、公式のスキーマストアで確認可能

2. 送信のルールとサイズ制限

配列形式での送信：イベントソースは、複数のイベントオブジェクトを「配列」にまとめて送信する
サイズ上限：配列全体の合計サイズ、および各イベント単体のサイズはともに最大 1 MB
超過時の挙動：制限を超えると 413 Payload Too Large エラーが発生し、受信を拒否される

3. 課金の仕組み

課金単位：64 KB ごとの増分単位でカウント
具体例：130 KB のイベント 1 つは、3 つ分の操作として料金が発生（130 ÷ 64 ≒ 2.03 なので切り上げ）

4. 受信側の動作

サブスクライバーへの配信：Event Grid から受信側へは、単一のイベントを含む配列として届けられる

イベントスキーマ

すべての発行者で使用されるプロパティの例を次に示す。

[
  {
    "topic": string,
    "subject": string,
    "id": string,
    "eventType": string,
    "eventTime": string,
    "data":{
      object-unique-to-each-publisher
    },
    "dataVersion": string,
    "metadataVersion": string
  }
]

イベントプロパティ

すべてのイベントは共通の「最上位プロパティ」を持ち、これによってイベントの識別やフィルタリングが行われる。

1. 全イベント共通の最上位プロパティ

topic（トピック）：イベントソースのリソースパス。省略しても Event Grid が自動付与する
subject（件名）：イベント対象の具体的なパス。フィルタリングに不可欠（必須）
eventType（イベントの種類）：リソース内で起きた事象の種類（必須）
eventTime（発生時刻）：イベント生成時の UTC 時刻（必須）
id（識別子）：イベントごとの一意な ID（必須）
data（データ）：各サービス固有の詳細情報（オブジェクト）
dataVersion（データバージョン）：data オブジェクトのスキーマのバージョン
metadataVersion（メタデータバージョン）：最上位プロパティのスキーマバージョン（現在は 1 固定）

2. カスタムトピックにおける設計の重要性
独自イベントを作る際は、受信側が処理しやすいよう最上位プロパティを適切に構成する必要がある。

subject のパス設計：/A/B/C のように階層構造にすることで、セグメント単位の柔軟なフィルタリングが可能になる
フィルタリングの幅：/A で指定すれば広範囲に、/A/B ならより絞り込んだイベント取得ができる
詳細な情報提供：ストレージの例（コンテナー名やファイル名を含むパス）のように、対象物を特定できる具体的なパスを含めるのが望ましい
サフィックスの活用：.txt などの拡張子でフィルタリングすることで、特定のファイル形式のみを抽出することも可能

クラウドイベントスキーマ（CloudEvents）

Azure Event Grid は、独自のスキーマに加えて業界標準の CloudEvents v1.0 をネイティブにサポートしている。これにより、異なるクラウドサービスやプラットフォーム間での相互運用性が向上する。

1. CloudEvents を利用するメリット

相互運用性の簡略化：クラウド間のイベント発行・利用に共通のスキーマを提供し、プラットフォームを越えた統合を容易にする
標準化：ツールの統一や、イベントのルーティング・処理・逆シリアル化の方法を標準化できる
柔軟性：Azure のシステムイベント（Blob Storage 等）とカスタムイベントの両方で利用可能

2. Event Grid スキーマとの主な違い

Content-Type ヘッダー：
- CloudEvents：application/cloudevents+json; charset=utf-8
- Event Grid：application/json; charset=utf-8
プロパティ名：specversion や source など、CloudEvents 仕様に基づいた命名規則が使用される

3. Event Grid での動作

双方向サポート：イベントの入力（受信）と出力（配信）の両方で CloudEvents 形式を使用可能
プロトコル変換：ネットワーク上を流れるイベントを、必要に応じて Event Grid スキーマと CloudEvents スキーマの間で相互変換できる

{
    "specversion": "1.0",
    "type": "Microsoft.Storage.BlobCreated",  
    "source": "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Storage/storageAccounts/{storage-account}",
    "id": "9aeb0fdf-c01e-0131-0922-9eb54906e209",
    "time": "2019-11-18T15:13:39.4589254Z",
    "subject": "blobServices/default/containers/{storage-container}/blobs/{new-file}",
    "dataschema": "#",
    "data": {
        "api": "PutBlockList",
        "clientRequestId": "4c5dd7fb-2c48-4a27-bb30-5361b5de920a",
        "requestId": "9aeb0fdf-c01e-0131-0922-9eb549000000",
        "eTag": "0x8D76C39E4407333",
        "contentType": "image/png",
        "contentLength": 30699,
        "blobType": "BlockBlob",
        "url": "https://gridtesting.blob.core.windows.net/testcontainer/{new-file}",
        "sequencer": "000000000000000000000000000099240000000000c41c18",
        "storageDiagnostics": {
            "batchId": "681fe319-3006-00a8-0022-9e7cde000000"
        }
    }
}

イベントサブスクリプションを作成する際に、イベントスキーマを選択することができる。

イベント配信の耐久性

Event Grid は、イベントを消失させず確実に届けるための「持続性のある配信」機能を備えている。

1. 配信の保証

少なくとも 1 回の試行：一致するサブスクリプションごとに、最低 1 回は必ず配信を試みる
受信確認の重視：サブスクライバー側からの「受け取った」という応答（ACK）がない限り、配信完了とは見なさない

2. 再試行の仕組み

エラー時の対応：エンドポイントが反応しない、またはエラーを返した場合は自動で再試行する
スケジュールの適用：あらかじめ定義された「固定再試行スケジュール」と「再試行ポリシー」に基づいて実行される

3. 配信の形式

順次配信：既定では、サブスクライバーに対して 1 回に 1 つのイベントを配信する
データ構造：ペイロードは、常に「1 つのイベントを含む配列」の形式で送られる

再試行スケジュールと例外処理

Event Grid は配信エラーが発生した際、その内容に応じて「再試行」「配信不能（デッドレター）処理」「削除」のいずれかを自動で判断する。

1. 再試行が行われないケース（即時ドロップまたは配信不能処理）
設定ミスなどの致命的なエラー（構成関連エラー）の場合、再試行は行われない。

Azure リソースへの配信：400 (不正な要求)、413 (サイズ超過)
Webhook への配信：400、413、401 (未認証)
対応：配信不能先が未設定ならイベントは破棄される

2. 再試行の仕組み
上記以外のエラー（一時的なダウン等）では、以下のルールで再試行される。

応答待ち時間：メッセージ送信後、30 秒間レスポンスを待機
再試行ポリシー：指数バックオフ（徐々に間隔を広げる方式）を採用
ランダム化：再試行タイミングに少量のランダムな時間を加え、負荷集中を回避
動的調整：相手先が長期間ダウンしている場合は、特定の再試行をスキップして効率化を図る

3. 重複配信の可能性

ベストエフォート：エンドポイントが 3 分以内に応答すれば再試行を止めようとするが、システムの特性上、同じイベントが重複して届く可能性がある

再試行ポリシー

イベントサブスクリプションの作成時に、配信が失敗した際の「諦め時」を 2 つの制限値で設定できる。いずれかの制限に達した時点で、イベントは破棄（または配信不能処理）される。

1. 設定可能な 2 つの制限

試行の最大数：配信を試みる回数の上限。1 ～ 30 の範囲で指定可能（既定値：30 回）
イベントの有効期間 (TTL)：イベントを保持し再試行を続ける時間の長さ。1 ～ 1440 分（24時間）の範囲で指定可能（既定値：1440 分）

2. 設定のポイント

リソースの最適化：重要度の低いイベントは試行回数を減らし、システム負荷を抑える
自動削除：どちらか一方の条件を満たした時点で再試行が止まるため、クリーンアップが自動で行われる
柔軟な変更：Azure CLI やポータルから、業務要件に合わせて簡単に調整可能

az eventgrid event-subscription create \
  -g gridResourceGroup \
  --topic-name <topic_name> \
  --name <event_subscription_name> \
  --endpoint <endpoint_URL> \
  --max-delivery-attempts 18

出力のバッチ処理

大量のイベントが発生する環境で、HTTP 通信のオーバーヘッドを減らしパフォーマンスを向上させるための機能。

1. バッチ処理の基本

初期設定：既定では無効。サブスクリプションごとに有効化が必要
配信動作：複数のイベントを一つの配列にまとめて、一度の HTTP リクエストで送信する

2. 設定できる 2 つの項目

バッチあたりの最大イベント数：
- 1 回の配信に含めるイベントの最大数（1 ～ 5,000）
- 溜まるのを待たずに、利用可能な分だけを即座に送るため、遅延は発生しない
推奨されるバッチサイズ (KB)：
- バッチ全体の容量の目標上限
- 例外：単一のイベントがこのサイズを超えていても、破棄されずそのイベント専用のバッチとして配信される

3. メリット

効率化：高スループットな状況において、接続回数を減らしてスループットを最大化できる
柔軟性：イベントの数とデータ容量の両面から制限をかけ、受信側の負荷をコントロールできる

配信の遅延

エンドポイントでエラーが連続すると、Event Grid はその宛先への送信を一時的に抑制する。

1. 遅延が発生する仕組み

エラーの検知：例えば最初の 10 件が連続して失敗した場合などに発動
抑制の動作：対象エンドポイントへの「新しい配信」と「再試行」の両方を保留にする
遅延時間：状況により、数時間に及ぶ場合もある

2. 遅延させる目的

エンドポイントの保護：ダウンしている、あるいは過負荷な受信サーバーに追い打ちをかけるのを防ぐ
システム全体の安定：無駄な再試行を繰り返して Event Grid 自体のリソースが圧迫されるのを回避する

3. 動作のイメージ

自動バックオフ：相手が「異常」と判断されたら、無理に送り続けず一歩引いて様子を見るインテリジェントな制御

配信不能イベント（デッドレター）

配信に失敗し続けたイベントを、消滅させずにストレージへ退避させる仕組み。これを「デッドレタリング」と呼ぶ。

1. 配信不能（デッドレター）になる条件
以下のいずれかを満たしたときに実行される。

有効期間（TTL）切れ：設定された時間内に配信が完了しなかった
試行回数の上限超過：最大試行回数（最大30回）を超えて失敗した
致命的なエラー：400 (不正な要求) や 413 (サイズ超過) を受信し、再試行が無意味と判断された

2. 設定と運用のルール

既定の設定：初期状態では無効。利用にはストレージアカウントの指定が必要
救済措置：退避されたイベントをストレージから読み取ることで、手動でのリカバリや原因調査が可能
遅延処理：ストレージへの書き込み負荷を抑えるため、最後の配信試行から約 5 分間の猶予を持って書き込まれる
最終的な消失：配信不能先のストレージが 4 時間以上利用できない場合は、イベント自体が破棄される

カスタム配信プロパティ

イベントを送信する際、HTTP ヘッダーに独自の情報を付加できる機能。これにより、受信側のシステムが要求する特定の認証情報やメタデータを自由に設定できる。

1. カスタムヘッダーの仕様

設定数：1 つのイベントサブスクリプションにつき最大 10 個まで
サイズ制限：各ヘッダーの値は 4,096 バイト（4 KB）以内
用途：受信側での認証、フィルタリング用のタグ付け、ルーティングの補助など

2. 対応している送信先（宛先）
以下のエンドポイントへの配信時にカスタムヘッダーを付与可能。

Webhooks
Azure Service Bus（トピックおよびキュー）
Azure Event Hubs
Relay ハイブリッド接続

3. 配信不能設定との関係

保存先の要件：配信不能イベント（デッドレター）を有効にするには、あらかじめストレージアカウント内にコンテナーを作成しておく必要がある
指定方法：サブスクリプション作成時に、そのコンテナーのエンドポイントを保存先として登録する

イベントへのアクセスを制御する

Azure Event Grid は、Azure RBAC（ロールベースのアクセス制御）を利用して、操作権限をきめ細かく管理する。

1. 制御できる主な操作

管理アクション：イベントサブスクリプションの一覧表示や新規作成
セキュリティ管理：認証用キーの再生成
リソース操作：トピックの作成や削除

2. 管理の仕組み

Azure RBAC の採用：ユーザー、グループ、アプリケーションごとに「誰が何をしてよいか」を定義
最小権限の原則：必要以上の権限を与えず、役割に応じた適切なアクセスレベル（閲覧のみ、作成可能など）を割り当て可能

組み込みロール

Event Grid には役割に応じた 4 つの専用ロールがあり、権限を分離して管理できる。

1. 主要な組み込みロール

Event Grid サブスクリプションリーダー：設定内容の「閲覧」のみが可能
Event Grid サブスクリプション共同作成者：サブスクリプションの「作成・編集・削除」が可能
Event Grid 共同作成者：トピックの作成を含め、Event Grid リソース全体の「フル管理」が可能
Event Grid データ送信者：トピックに対してイベントを「送る」ことだけが可能

2. 権限設計のポイント

サブスクリプション管理に特化：
- 「リーダー」と「サブスクリプション共同作成者」は、配信先の設定管理がメイン
- トピック自体の作成権限は持たないため、イベントドメイン環境でのユーザー権限割り当てに最適
リソース管理：
- 開発者や管理者は「共同作成者」を使用し、インフラ全体の構成を管理
送信専用権限：
- イベントを発行するアプリや外部システムには、安全のため「データ送信者」のみを付与

イベントサブスクリプションのアクセス許可

Webhook 以外のハンドラー（Event Hubs や Queue Storage 等）を利用する場合、宛先を設定するための特定の書き込み権限が必要。

1. 必要な権限と目的

対象権限：Microsoft.EventGrid/EventSubscriptions/Write
権限が必要な場所：イベントの発生元（ソース）となるリソース
目的：承認されていないユーザーが、勝手にリソースからイベントを外部へ転送することを防ぐ

2. トピックの種類による権限の範囲
購読するトピックのタイプによって、権限を付与すべき対象リソースが異なる。

トピックの種類	権限が必要なリソーススコープ
システムトピック	イベントを発行する Azure リソースそのもの（例：特定の Storage Account）
カスタムトピック	作成済みの Event Grid トピック自体

3. スコープの具体例

システムトピック：/subscriptions/.../providers/Microsoft.Storage/storageAccounts/{name}
カスタムトピック：/subscriptions/.../providers/Microsoft.EventGrid/topics/{name}

Webhook を使用してイベントを受信する

Webhook は Event Grid からイベントを受け取る主要な手法の一つ。イベント発生時、Event Grid は指定されたエンドポイントへ HTTP POST リクエストを送信する。

1. エンドポイントの所有権証明
イベントの配信を開始する前に、その URL が自分の管理下にあることを証明（検証）する必要がある。

目的：第三者のエンドポイントに大量のデータを送りつける攻撃（サービス拒否攻撃）を防止するため
仕組み：Event Grid が検証用コードを送り、受信側が正しく応答することで成立

2. 検証が自動化されるサービス
以下の Azure サービスをハンドラーとして使用する場合、Azure 内部で検証が完結するため、手動での対応は不要。

Azure Logic Apps（Event Grid コネクタ使用時）
Azure Automation（Webhook 使用時）
Azure Functions（Event Grid トリガー使用時）

3. その他の Webhook（独自実装など）

手動検証の必要性：自前の Web サーバーなどを Webhook 先にする場合は、Event Grid の検証プロトコル（ハンドシェイク）をコードで実装しなければならない

Event Grid イベントを使用したエンドポイントの検証

独自の Webhook（Azure Functions の HTTP トリガー等）を使用する場合、Event Grid との「検証ハンドシェイク」を実装する必要がある。これには 2 つの方法が存在する。

1. 同期ハンドシェイク
アプリケーションがプログラムで自動応答する方法。

手順：サブスクリプション作成時、Event Grid から validationCode を含む検証イベントが届く
対応：アプリケーション側でそのコードを抽出し、レスポンスとして即座に（同期的に）返す
特徴：すべての Event Grid バージョンで利用可能な標準的な手法

2. 非同期ハンドシェイク（手動検証）
Zapier や IFTTT など、プログラムによる即時応答が難しいサードパーティサービス向けの方法。

手順：検証イベントに含まれる validationUrl を取得する
対応：その URL に対して、5 分以内にブラウザや REST クライアントから GET リクエストを実行する
状態推移：実行待機中は AwaitingManualAction 状態となり、URL へのアクセス成功で検証完了となる
前提条件：エンドポイントは、最初の検証用 POST リクエストに対し、まず HTTP 200 を返しておく必要がある

3. 注意点

有効期限：手動検証用の URL は発行から 5 分間のみ有効
タイムアウト：5 分を過ぎるとプロビジョニング状態が Failed になり、サブスクリプションの再作成が必要になる

イベントをフィルターする

イベントサブスクリプションを作成する際、必要なイベントだけを抽出するための 3 つのフィルタリング手法が用意されている。

イベントの種類（Event Types）
件名のフィルタリング（Subject Filtering）
高度なフィルタリング（Advanced Filtering）

イベントタイプフィルタリング

イベントソースから発生する多種多様な事象の中から、特定のアクションに関連するものだけを選択して受信する機能。

1. 基本動作

既定の設定：何もしない場合は、ソースで発生する「すべての種類」のイベントが配信される
絞り込み：必要なイベントの種類だけをリストアップして指定可能
例：リソースの「更新」だけを知りたい場合は ResourceWriteSuccess のみを指定し、「削除」などは無視する

2. 指定方法

配列形式：複数のイベントタイプをリスト（配列）として定義する
特殊な指定（All）：すべてのイベントタイプを取得したい場合は All を指定する

3. JSON 構成のポイント

includedEventTypes：このプロパティ内に、受け取りたいイベントの識別名を記述する
柔軟性：後から配信対象のイベントタイプを追加・削除することも容易

"filter": {
  "includedEventTypes": [
    "Microsoft.Resources.ResourceWriteFailure",
    "Microsoft.Resources.ResourceWriteSuccess"
  ]
}

件名（Subject）フィルタリング

subject プロパティの文字列の「始まり」や「終わり」をチェックして、配信対象を絞り込む最も一般的なフィルタリング手法。

1. フィルタリングの種類

前方一致（subjectBeginsWith）：
- 指定した文字列で始まるイベントのみを取得
- 例：特定のコンテナーやフォルダ（/mycontainer/log）内の事象に限定する際に使用
後方一致（subjectEndsWith）：
- 指定した文字列で終わるイベントのみを取得
- 例：特定のファイル形式（.jpg や .txt）に関連する通知だけを抽出する際に使用

2. JSON 構文の構成

filter オブジェクト：内部に subjectBeginsWith と subjectEndsWith を定義する
組み合わせ：両方を同時に指定して、「特定のフォルダ内」かつ「特定の拡張子」といった条件設定も可能

"filter": {
  "subjectBeginsWith": "/blobServices/default/containers/mycontainer/log",
  "subjectEndsWith": ".jpg"
}

3. 実用的なメリット

階層による制御：ストレージのパス構造（コンテナー/フォルダ/ファイル）を活かした柔軟な絞り込みができる
ノイズの削減：関係のないディレクトリやファイル形式のイベントを入り口で遮断できる

高度なフィルター処理

data オブジェクト内の詳細な値や、複雑な比較演算子を用いてイベントを精密に選別する機能。

1. フィルターの構成要素

演算子の種類：比較のルール（「以上」「含む」など）を指定する
キー：イベントデータ内のどの項目をチェックするかを指定。数値、真偽値（ブール値）、文字列が使用可能
値（または値のリスト）：比較の対象となる具体的な数値や文字列

2. 代表的な演算子の例

数値比較：NumberGreaterThanOrEquals（以上）、NumberIn（指定した数値のいずれか）など
文字列比較：StringContains（含む）、StringIn（一致）、StringBeginsWith（前方一致）など
論理比較：BoolEquals（真偽値の一致）など

3. JSON 構文の特徴

advancedFilters：複数のフィルター条件を配列として定義できる
柔軟なパス指定：Data.Key1 のように階層を辿って深い位置にあるデータを指定可能
複数値の指定：values プロパティを使って、「A または B を含む」といった複数条件を一度に記述できる

"filter": {
  "advancedFilters": [
    {
      "operatorType": "NumberGreaterThanOrEquals",
      "key": "Data.Key1",
      "value": 5
    },
    {
      "operatorType": "StringContains",
      "key": "Subject",
      "values": ["container1", "container2"]
    }
  ]
}

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up