Azure でイベント駆動の連携を組むとき、最初に手が止まるのは「Event Grid を使うかどうか」ではなく「どの Event Grid を作るか」です。ポータルには Event Grid トピックと Event Grid 名前空間が並び、名前は似ているのに使える機能が違います。取り違えると、MQTT を扱いたいのにプッシュ配信専用のリソースを作ってしまう、といった作り直しが起きました。
この記事では、Basic レベルと Standard レベルの機能差、再試行とデッドレターの既定値、順序が保証されない前提での受信側の組み方、Service Bus や Event Hubs との境界を、設計時に踏む順番で整理します。数値は Microsoft Learn および Azure の料金ページを2026年9月時点で確認しました。
まとめ｜Event GridはHTTPとMQTTを束ねる発行/サブスクライブ基盤
- 実体はマネージドの pub/sub サービス：発行者と購読者を直結させず、ルーティングとフィルタリング、再試行を Event Grid が引き受けます。
- レベルで機能が分かれる：Basic は各種トピックでプッシュ配信、Standard は名前空間で MQTT とプル配信を扱います。
- 配信は最低1回：応答が返らなければ指数バックオフで最大24時間再試行されました。
- 順序は保証されない：順不同で届く前提で、冪等な処理とバージョン比較を先に用意します。
- デッドレターは既定で無効：ストレージアカウントを指定しない限り、打ち切られたイベントは破棄されます。
- 数え方は64KB単位：制限も課金も64KB換算で、128KBのイベントは2イベントとして数えられます。
Azure Event Gridとは｜イベントを発行者から購読者へ配る仕組み
Azure Event Grid は、メッセージ配布のためのフルマネージドな発行/サブスクライブ サービスだと Microsoft Learn は定義しています。発行側は「何が起きたか」を Event Grid へ送るだけで、誰が受け取るかを知る必要がありません。受け取る側はサブスクリプションを作り、条件で絞り込んだイベントだけを受け取ります。
2つのコア機能｜MQTTメッセージングとHTTPでのイベント配信
Event Grid には大きく2つの顔があります。1つは MQTT メッセージングで、IoT デバイスやアプリケーションが MQTT v3.1.1 および v5.0（WebSocket 経由を含む）で相互に通信し、そのメッセージを Azure サービスやカスタムエンドポイントへルーティングできる機能です。認証は X.509 証明書、Microsoft Entra ID、OAuth 2.0 の JWT、カスタム Webhook から選べました。
もう1つが HTTP でのイベント配信です。Azure サービス、自社アプリケーション、パートナー SaaS から送られたイベントを、Webhook や Azure Functions といったハンドラーへ配ります。HTTPS 経由で MQTT メッセージを送る機能も用意されていますが、2026年9月時点ではプレビュー段階でした。
プッシュ配信とプル配信の違いと、CloudEvents 1.0への対応
HTTP でのイベント消費には2つのモードがあります。プッシュ配信では、イベントサブスクリプションに宛先を定義しておき、Event Grid 側がその宛先へイベントを送り込む形です。プル配信では逆に、購読側アプリケーションが Event Grid へ接続してイベントを読み取ります。プル配信がサポートされるのは名前空間内のトピックだけ、という点が構成を決める分岐になりました。
Microsoft Learn は、受信タイミングを自分で握りたい場合、下流サービスの不調時に読み取ったイベントをブローカーへ戻したい場合、プライベートリンクを使いたい場合にプル配信を挙げています。逆に、状態変化をポーリングで検出したくない場合や、外部への発信ができないアプリケーションにはプッシュ配信が向きます。イベント形式としては、システム間の相互運用性をもたらす CloudEvents 1.0 仕様がサポートされました。イベント駆動という設計そのものの前提はイベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説で整理しています。
トピックの種類とレベル｜BasicのカスタムトピックとStandardの名前空間
Event Grid の Standard と Basic という2つのレベルが、ポータルに並ぶ「Event Grid トピック」と「Event Grid 名前空間」の違いに対応しました。後から入れ替えられない土台の選択になるため、先に決めておく必要があります。
Basicレベルが受け持つカスタム・システム・パートナーのトピック
Basic レベルは、カスタムトピック、システムトピック、ドメイン、パートナートピックによるプッシュ配信を担当します。システムトピックは Azure サービス自身が発行するイベントの入口で、カスタムトピックは自社アプリケーションが発行するイベントの入口です。ドメインは多数のトピックをまとめて扱う器で、1ドメインあたり10万トピックまで作れました。
クォータは Azure サブスクリプションあたりカスタムトピック100、トピックあたりのイベントサブスクリプション500（Azure のイベントサブスクリプションは100）、発行率は5,000イベントまたは5MB/秒のいずれか早い方です。イベントサイズの上限1MBとトピックでのイベント保持1日は引き上げられません。
Standardレベルの名前空間トピックとスループット単位という考え方
Standard レベルの名前空間は、MQTT ブローカー機能と HTTP のプル配信を有効にする器です。中にトピック、クライアント、クライアントグループ、トピック空間、アクセス許可バインドといったサブリソースが入れ子になり、名前空間を削除すると内部のリソースも消えます。名前空間は一意の FQDN を持ち、HTTP と MQTT の2つのエンドポイントを公開しました。
容量の単位はスループット単位（TU）です。TU が名前空間のイングレスとエグレスの容量を決め、名前空間あたりの上限は40 TU（超過分は問い合わせで引き上げ）でした。イベント側は TU あたりトピック100、イングレスが1秒1,000イベントまたは1MB/秒、イベント保持は7日、MQTT 側は TU あたり10,000セッション、メッセージ最大512KB という値が並びます。
選択の分かれ目はMQTTとプル配信が要るかどうかという一点にある
MQTT を扱うか、購読側がプルで取りに行くか、このどちらかに当てはまるなら名前空間、いずれも不要でハンドラーへ押し込むだけなら Basic のカスタムトピックで足ります。イベント保持期間も判断材料になり、名前空間トピックの7日に対しカスタムトピックは1日でした。提供リージョンの確認も先に済ませます。MQTT ブローカーと名前空間トピックには、2026年9月時点で東日本と西日本の双方が含まれていました。
配信の信頼性設計｜最低1回の配信保証と再試行・デッドレターの既定値
Event Grid は一致する各サブスクリプションに対して、各メッセージを最低1回は配信しようとします。逆に言えば、二重配信も打ち切りも起こり得ました。既定値のまま運用すると、失敗したイベントが静かに消える構成になりかねません。
再試行は10秒から最大24時間まで指数バックオフで段階的に進む
Event Grid はメッセージ配信後、30秒間応答を待ちます。応答がなければ再試行キューへ入り、10秒、30秒、1分、5分、10分、30分、1時間、3時間、6時間、以降12時間ごと（最大24時間）というスケジュールでベストエフォートの再試行が進みました。各手順には小さなランダム化が加えられ、エンドポイントが長時間ダウンしていると判断された場合は一部の再試行が飛ばされることもあります。
成功とみなされる応答コードは200、201、202、203、204の5つだけで、それ以外はすべて失敗として扱われます。処理を非同期に流す設計なら、受け取った時点で202を返し、重い処理は後段へ回す形が扱いやすくなりました。
再試行されないエラーコードとプロベーションによる配信抑制の挙動
すべての失敗が再試行されるわけではありません。Azure リソース宛では400、413、403、Webhook 宛では400、413、401、403 が再試行されない扱いでした。エンドポイントの削除や権限設定の誤りなど、時間を置いても直らない構成起因のエラーだからです。デッドレター未構成なら、この時点でイベントは破棄されます。さらに失敗が続くとサブスクリプションはプロベーション（試用期間）に入り、配信自体が遅延しました。止まった理由は lastDeliveryOutcome で切り分けられます。
最大試行回数30回とTTL1440分という既定値をどう詰めるか
イベントサブスクリプションでは、最大試行回数（1〜30、既定30）とイベントの Time-To-Live（1〜1440分、既定1440分）の2つで再試行ポリシーを絞り込めます。両方を設定した場合、先に到達した条件で打ち切られました。Microsoft Learn は、TTL 30分・最大試行10回という設定では TTL に達するまでに最大6回しか試行されず、最大試行回数側が効かない例を挙げています。
デッドレターは既定で無効です。有効にするにはイベントサブスクリプション作成時にストレージアカウントのコンテナーを指定します。最後の配信試行からデッドレター先へ届くまでには BLOB 操作を減らすための5分の遅延があり、デッドレター先が4時間利用できないとイベントは破棄されました。退避先の BLOB にイベントサブスクリプションを張って検知する構成まで含めて、初めて取りこぼしのない運用になります。
順序保証がない前提での受信実装｜冪等性と重複排除の組み立て方
Microsoft Learn は「Event Grid はイベント配信の順序を保証しない」と明記しています。加えて最低1回の配信であるため、同じイベントが2回届くこともあります。この2点は設定で変えられず、受信側の実装で吸収するしかありません。
イベントIDで重複を弾きバージョン比較で古い更新を捨てる実装
順不同を前提にするなら、イベントに単調増加するバージョン番号か発生時刻を載せ、受信側が「自分の持つ値より古いイベントは捨てる」判定を行う形にします。Event Grid スキーマには eventTime があり、業務側の更新シーケンス番号を data に含める方法も取れました。状態そのものをイベントに載せず「変わったこと」だけを通知し、最新値は購読側が API で取り直す設計にすれば、順序の問題は起きにくくなります。
重複対策は、イベント ID を主キーにした処理済みテーブルを持ち、処理済みなら何もせず成功応答を返すのが基本形です。副作用が外部システムへの書き込みなら、その API 側の冪等キーへイベント ID を渡します。重複を検知して例外で落とすとエラー応答になり、Event Grid がさらに再試行するため状況は悪化しました。重複は正常な入力として静かに握り潰す設計にしておきます。
Service Bus・Event Hubsとの使い分け｜メッセージとイベントの境目
Event Grid はイベント通知の配信とルーティング、Service Bus は業務メッセージのブローカー、Event Hubs は大量ストリームの取り込み、という役割分担で切り分けると判断がぶれにくくなります。
取りこぼしとFIFOが要件ならService Busを主にする
注文や決済のように、1件たりとも失えず、かつ順序が業務上の意味を持つメッセージは Service Bus の領分です。セッションによる順序保証、ロックを取ってから処理する Peek-Lock、デッドレターキューが標準で備わっています。Event Grid は順序を保証せず、購読側が消費速度を制御する手段も限られるため、この用途では主役になりません。キューとトピックの構造や料金階層はAzure Service Busとは？キュー・トピックの仕組みと料金階層・使い分けを実装視点で解説にまとめました。
Event Grid のイベントサブスクリプションは Service Bus のキューやトピックを宛先に取れるため、入口の通知を Event Grid が受け、確実な処理が要る区間だけ Service Bus へ流す組み合わせも成立します。
秒間数万件のテレメトリを取り込むならEvent Hubsを前段に置く
センサーやログのように、1件ごとの意味より総体としての流量が問題になるデータは Event Hubs が受け持ちます。Event Grid のカスタムトピックの発行率は5,000イベントまたは5MB/秒、名前空間でも TU あたり1秒1,000イベントという単位なので、桁が上の流量はストリーミング側の仕事でした。取り込み側の設計はAzure Event Hubsとは｜大量イベントを取り込むKafka互換ストリーミング基盤の仕組みと採用判断を参照してください。
AWS では、ルールでイベントを振り分けるAmazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説が Event Grid に近い位置にあり、トピック単位の通知配信はAmazon SNSとは｜Pub/Sub通知の仕組み・配信先・FIFO/フィルタリングと採用判断を実装者目線で解説が担いました。マルチクラウド構成では、どちらのイベント基盤を正とするかを先に決めておくと配線が単純になります。
実装の流れ｜トピック作成からサブスクリプションとハンドラー設定まで
ここからは Basic レベルのカスタムトピックを例に構築手順を追います。名前空間トピックでもリソースの種類が変わるだけで、骨格は同じでした。
Azure CLIでカスタムトピックとイベントサブスクリプションを作る
トピックを作り、そのリソース ID を控えてイベントサブスクリプションを作成します。再試行ポリシーとデッドレター先は、既定値のまま放置せず作成時に指定しておくのが安全側の作法です。
az eventgrid topic create --name egtopic-demo --resource-group rg-demo --location japaneast
topicid=$(az eventgrid topic show --name egtopic-demo --resource-group rg-demo --query id --output tsv)
az eventgrid event-subscription create --name sub-to-func --source-resource-id $topicid --endpoint 〈ハンドラーのエンドポイント〉 --max-delivery-attempts 5 --event-ttl 60 --deadletter-endpoint 〈デッドレター用コンテナーのID〉
発行側は、トピックのエンドポイントへアクセスキーまたは Microsoft Entra ID の資格情報でイベントを POST します。フィルタリングはイベントサブスクリプション側の仕事で、イベントの種類や件名の前方一致・後方一致で購読対象を絞り込めました。購読側のコードで条件分岐を書くより、サブスクリプションの条件で切ったほうが無駄な配信と課金を減らせます。
Webhookをハンドラーにする場合の検証とバッチ配信の設定
Webhook を宛先にする場合、Event Grid はエンドポイントの所有確認を求めます。Azure Functions の EventGrid トリガーや Logic Apps のようにこの手続きが組み込まれている宛先を選ぶと、検証まわりの実装を省けました。ワークフロー側でイベントを受けて業務処理につなぐ構成はAzure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説で整理しています。
高スループットの局面では出力のバッチ処理を有効にします。既定は1配信1イベントで、バッチあたり最大イベント数を1〜5,000、優先バッチサイズを1〜1,024KB で設定できました。all-or-nothing のため、購読側が30秒以内に処理し切れる件数へ抑えます。
制限と費用の見積り｜64KB単位の課金とTU・クォータの頭打ち
費用の見積りでつまずきやすいのは「1イベント＝1操作ではない」ところです。制限も価格も64KB のデータチャンク単位で数えられ、128KB のイベントは2イベントとして扱われました。
ペイロードは軽く保ちクォータの頭打ちを先に見積もるという原則
無料枠は、Basic が月10万操作、Standard が MQTT 操作とイベント操作それぞれ月100万操作でした。単価は Azure の料金ページ上では実数が表示されず、見積りツールでの確認が要ります。設計上の勘所は単価より容量で、カスタムトピックなら5,000イベントまたは5MB/秒、名前空間なら TU あたり1秒1,000イベント、TU 上限は40という値が上限線です。
イベントには識別子だけを載せ、本体は購読側が Blob やデータベースへ取りに行く設計にすると、64KB を超えにくくなります。イベントサイズの上限は名前空間・カスタムトピックともに1MB で、引き上げはできません。
Event Gridを採用してよい条件と見送ったほうがよい場面の判断基準
ここまでの仕様を踏まえて、採用の可否を条件付きで整理します。判断の軸は「イベントの性質」と「受信側を作り替えられるか」の2つです。
採用してよい3つの条件｜通知型・多対多・受信側を作り替えられる
1つ目は、流れるものが「状態が変わった」という通知で、本体データを含まない場合です。Blob の作成やリソースの構成変更に反応して後続処理を起こす用途は、Event Grid の設計思想とそのまま噛み合いました。2つ目は、1つのイベントを複数の購読者が別々の条件で受け取る多対多の構成です。サブスクリプション側でフィルタを書けるため、発行側を変更せず購読者を足していけます。
3つ目は、受信側の実装を冪等に作り替えられる場合です。順不同と重複を前提に処理を組み直せるなら、再試行とデッドレターを Event Grid に任せ、アプリケーション側から配信管理のコードを外せます。レガシーな受信処理へ手を入れられない状況では、この前提が崩れました。Azure でイベント基盤を含む構成を新規に組む段階なら、インフラ構築（AWS・Google Cloud・Azure）のように設計から運用までを通して見る支援を併走させる選択肢もあります。
見送ったほうがよい場面｜順序が業務要件・大容量・厳密な一度きり
順序が業務上の正しさに直結する処理は見送ります。会計仕訳や在庫の増減のように逆順で届くと結果が変わる処理を Event Grid だけで受けるのは無理があり、Service Bus のセッションを使うか、受信側で並べ替えを実装する必要が出ました。ペイロードが常に数百KB を超える連携も、64KB 換算の課金とクォータ、1MB のサイズ上限に同時に当たるため外します。ちょうど一度だけの実行を仕組みとして担保したい要件も対象外です。いずれの場合も、Event Grid を通知の入口に限定し、確実性が要る区間だけ別のサービスへ渡す二段構えを検討します。
よくある質問
Event Gridはイベントの順序を保証しますか？
保証しません。Microsoft Learn は、購読側がイベントを順不同で受け取る可能性があると明記しています。順序が意味を持つ処理では、イベントにバージョンや発生時刻を載せて古いものを捨てるか、Service Bus のセッションへ切り替えてください。
配信に失敗したイベントは最終的にどうなりますか？
再試行ポリシーの上限（既定は最大試行30回、TTL 1440分）に達すると打ち切られます。デッドレターを構成していればストレージアカウントへ退避され、構成していなければ破棄されました。デッドレター先が4時間利用できない場合も失われます。
カスタムトピックと名前空間トピックはどちらを選ぶべきですか？
MQTT を扱うか、購読側がプル配信で取りに行く構成なら名前空間トピックです。いずれも不要で、Webhook や Azure Functions へ押し込むだけならカスタムトピックで足ります。イベント保持期間も7日と1日で差があり、再処理の要否が判断材料になりました。
Event GridとEvent Hubsは何が違いますか？
Event Grid は個々のイベントを条件で振り分けて配るサービス、Event Hubs は大量のイベントを連続したストリームとして取り込み、購読側がオフセットを管理しながら読むサービスです。秒間数千件を超えるテレメトリの取り込みは Event Hubs、状態変化の通知は Event Grid という切り分けになります。
東日本リージョンでMQTTブローカーは使えますか？
使えます。提供リージョンの一覧には、2026年9月時点で東日本と西日本の双方が含まれていました。ただし提供状況は変わるため構築前に確認してください。HTTPS 経由での MQTT メッセージ発行がプレビュー段階である点にも注意が要ります。
関連記事
- Azure Service Busとは？キュー・トピックの仕組みと料金階層・使い分けを実装視点で解説：確実な処理が要る区間を担うブローカー側の仕組み。
- Azure Event Hubsとは｜大量イベントを取り込むKafka互換ストリーミング基盤の仕組みと採用判断：大量ストリーム取り込みの構造と採用判断。
- Azure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説：イベントを受けて業務処理へつなぐワークフロー側。
- イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説：ベンダー非依存のイベント駆動の考え方と実装パターン。
- Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説：AWS 側で近い位置を占めるサービスの構造。
- Amazon SNSとは｜Pub/Sub通知の仕組み・配信先・FIFO/フィルタリングと採用判断を実装者目線で解説：トピック単位の通知配信を AWS で組む場合の選択肢。
