Azure Event Grid が Stripe を送信先として扱えるようになった、というより正確には、Stripe 側のイベント送信先に Azure Event Grid をネイティブに選べる Public Preview が公開された、という理解が実務ではいちばん分かりやすいです。Microsoft は 2026年4月10日にこのプレビューを公開し、Stripe イベントを Azure Event Grid に直接ルーティングすることで、Webhook 基盤や独自ブローカーを自前で持たずに、Azure Functions、Logic Apps、Event Hubs、Service Bus などへ流せるようになると案内しています。 (Microsoft)
要するに、Stripe と Azure を組み合わせるときの「受け口」をアプリ実装から Event Grid に寄せやすくなりました。支払い、請求、サブスクリプション更新のイベントを partner topic で受け、event subscription で用途別に分岐できるので、Azure 側の統合設計をかなり整理しやすくなります。 (Microsoft Learn)
Azure Event Grid と Stripe 連携で何が変わったのか
今回のポイントは、Stripe が Azure Event Grid を event destination type としてサポートし、azure_event_grid という送信先タイプを追加したことです。Microsoft 側では Event Grid を Stripe イベントの受け先として Public Preview で公開し、Stripe 側でも 2026年3月25日の changelog で Azure Event Grid 宛て送信の追加を告知しています。 (Stripe ドキュメント)
この連携は Event Grid の Partner Events / partner topics を使います。つまり、Stripe はイベント発生元であり、Azure 側では Stripe が作成する partner topic を購読して、Azure の各サービスへ配信する形です。Azure サービスのイベントを扱うときと近い考え方で、Stripe のイベントも Azure の標準的なイベントルーティングに載せられるようになります。 (Microsoft Learn)
Stripe イベントを Event Grid に送るメリット
いちばん大きいのは、Stripe のイベント受信と Azure 内の分岐を分離できることです。従来は Stripe の Webhook を自前の HTTPS エンドポイントで受け、その先のルーティングや再配信をアプリ側で抱え込みがちでした。Microsoft は今回のプレビューを「Webhook インフラや独自ブローカーを管理しなくてよい」方向の改善として説明しています。Stripe の Webhook は引き続き使えますが、Azure 中心の構成では Event Grid を受け口にしたほうが設計を標準化しやすくなります。 (Microsoft)
もうひとつの利点は、Stripe イベントを 1 か所で受けて複数用途に配れることです。たとえば payment_intent.succeeded を Azure Functions で注文確定に使い、同じイベントを Event Hubs に流して分析し、別の invoice.payment_failed を Logic Apps で通知に回す、といった分岐を event subscription で切れます。これは、1 本の Webhook の中で分岐ロジックを肥大化させる設計より保守しやすい構成です。 (Microsoft Learn)
どの宛先に流すべきか
| 宛先 | 向くケース | 実務上の使い方 |
|---|---|---|
| Azure Functions | 注文確定、権限付与、イベント変換 | Stripe イベントを受けて、社内ドメインイベントへ正規化する最初の処理層に向く |
| Logic Apps | メール通知、承認、SaaS 連携 | コードを増やさずに業務フローへ接続したいときに向く |
| Service Bus | 基幹連携、バッファリング、再処理 | 下流が遅い、停止しやすい、後追い再処理したい場合の吸収層に向く |
| Event Hubs / Fabric | 監視、分析、ストリーム処理 | 支払いシグナルを分析基盤に継続投入したい場合に向く |
上の使い分けは、Event Grid のサポート先、Azure Functions の変換・検証用途、Service Bus のバッファ用途、そして Microsoft が案内している Event Hubs / Fabric 連携をもとに整理したものです。 (Microsoft Learn)
どんなユースケースに向くのか
Stripe partner topics の公式ドキュメントでは、代表例として 支払い処理の自動化、サブスクリプションのライフサイクル管理、不正や異常の監視、顧客データ同期 が挙げられています。実務に落とすと、payment_intent.succeeded で注文確定、invoice.payment_failed で督促やアラート、customer.subscription.updated で権限や契約状態の更新、customer.* で CRM 同期、といった構成が作りやすい領域です。 (Microsoft Learn)
特に Azure を標準基盤にしている組織では、決済イベントをアプリ個別実装ではなく Azure 統合レイヤーへ引き上げられるのが大きいです。支払いイベントをトリガーに Functions で処理し、Logic Apps で通知し、Event Hubs や Fabric で分析へ流すという分担がしやすくなります。 (Microsoft)
Azure Event Grid と Stripe をつなぐ手順
- Azure サブスクリプションで Microsoft.EventGrid を登録します。 Event Grid を初めて使うサブスクリプションでは resource provider の登録が必要です。未登録だと関連リソースの作成に失敗します。 (Microsoft Learn)
- Event Grid Partner Configurations で Stripe を承認します。 Stripe が partner topic を作れるように、対象のリソースグループに対する partner authorization を作成します。有効期限は 1〜365 日で設定でき、Microsoft は必要最小限の期限を推奨しています。 (Microsoft Learn)
- Stripe ダッシュボード側で Azure Event Grid 向け送信先を作成します。 Microsoft Learn では
Developers > Destinations、Stripe ドキュメントでは Workbench のWebhooksタブから新しい送信先を作る流れが案内されています。画面表記は変わる可能性がありますが、やることは同じで、Azure で発行された partner topic channel URL を入力し、送信したいイベント型を選びます。 (Microsoft Learn) - Azure 側で partner topic を有効化します。 Stripe が送信先を設定すると、指定したサブスクリプションとリージョンに partner topic が作成されます。Stripe の公式ドキュメントでは、作成後 7 日以内に partner topic を有効化しないと Azure が自動削除し、Stripe 側の送信先も無効になると案内されています。 (Stripe ドキュメント)
- event subscription と event handler を作成します。 Azure Functions、Event Hubs、Service Bus Queue/Topic、Storage Queues、Webhook などを宛先にできます。Stripe のドキュメントでは、event subscription を作らない場合、イベントは Event Grid に送られて 24 時間保持されるものの、どこにも配信されないと明記されています。 (Microsoft Learn)
実装前に知っておくべき注意点
順序に依存しない設計にする
Event Grid はイベント配信順を保証しません。Stripe 側も、イベントが生成順に届く保証はなく、特定の順序で届く前提にしないよう案内しています。たとえば invoice.paid が先に来て、その後で関連イベントが届くことを前提に、受信イベントだけで状態確定せず、必要なら Stripe API から現在のオブジェクト状態を取り直す設計が安全です。 (Microsoft Learn)
重複を前提に冪等化する
Event Grid は各サブスクリプションに対して 最低 1 回 の配信を試み、失敗時は再試行します。Stripe も本番環境では Event Grid 送信先への配信を最長 3 日間、指数バックオフで再試行します。さらに Stripe の go-live チェックリストでは、遅延通知と重複通知に対応し、通知順序に依存しないことを確認するよう求めています。処理済み event ID の記録 や 業務キーでの重複排除 は必須です。 (Microsoft Learn)
応答が必要なイベントは Webhook を残す
Event Grid 連携ですべての Stripe イベントを置き換えられるわけではありません。Stripe の Event Grid 送信先は、応答が必要なイベントタイプには制約があります。たとえば issuing_authorization.request は Event Grid 宛てでは登録できず、リアルタイム承認が必要なため Webhook が必要です。また checkout_sessions.completed を Event Grid で受けても、Checkout のリダイレクト制御は変わりません。即時応答が業務要件に入る処理は、Webhook 併用前提で考えるべきです。 (Stripe ドキュメント)
受信データの形を決め打ちしない
Stripe の Event Grid 送信では、イベントは CloudEvents v1.0 のエンベロープで配信され、元の Stripe イベント JSON は data に格納されます。さらに Stripe は「軽量イベント」の考え方を案内しており、必要なら関連する API リソースを後から取得する前提で設計できます。つまり、受信オブジェクトを 1 種類の固定 JSON と決め打ちするより、CloudEvents + Stripe データの二層で扱うほうが実装ミスを減らせます。 (Stripe ドキュメント)
API バージョン差分も吸収できるようにする
Stripe は、送信される Event オブジェクトの構造が API バージョンの影響を受けることを説明しています。強い型付けの言語で受ける場合ほど、イベントスキーマの固定化 と バージョン変更時の検証 が重要です。Event Grid にしたことでこの課題が消えるわけではなく、むしろ複数サービスへ配るなら最初の受信点で正規化したほうが安全です。 (Stripe ドキュメント)
障害解析は「Stripe→Event Grid」と「Event Grid→宛先」を分けて見る
この構成は障害点が 2 つに分かれます。まず Stripe から Event Grid へ届いているか、次に Event Grid から各 subscriber へ届いているか です。前者は Stripe 側の送信先状態や再試行、後者は Event Grid 側の再試行・TTL・デッドレター設定で見る必要があります。切り分けを 1 本化すると、どこで詰まっているのか見失いやすいです。 (Stripe ドキュメント)
デッドレターは最初から設定しておく
Event Grid はイベントサブスクリプション作成時に、Blob コンテナーへのデッドレタリングと再試行ポリシーを設定できます。既定では TTL 24 時間、最大試行回数 30 回で、デッドレターを構成しないと条件によってはイベントが破棄されます。決済や契約更新のように後追い確認が必要なイベントでは、検証環境の段階から dead-letter を有効化しておくほうが安全です。 (Microsoft Learn)
まず試すならこの最小構成
最初からすべての Stripe イベントを流すより、3 種類だけで PoC を切るほうが失敗しにくいです。候補は payment_intent.succeeded、invoice.payment_failed、customer.subscription.updated です。どれも Microsoft Learn の手順や Stripe partner topics の説明で例示されているイベントで、受注、請求失敗、契約状態更新という主要な業務線を一通り検証できます。 (Microsoft Learn)
最小構成の例
payment_intent.succeeded→ Azure Functions
注文確定、ライセンス付与、社内イベントへの変換を担わせます。Functions は Event Grid の受け先として使え、変換や検証の前段にも向きます。 (Microsoft Learn)invoice.payment_failed→ Logic Apps
メール通知、Teams 通知、営業やサポートへのタスク化など、コードを増やしたくない処理に向きます。 (Microsoft Learn)customer.subscription.updated→ Service Bus
基幹システムや会員権限同期など、下流が遅くても止めたくない処理をバッファリングできます。 (Microsoft Learn)
この 3 本に Blob への dead-letter を足し、重複・順不同・再試行を検証してから live イベントを広げるのが現実的です。Stripe イベントを Azure Event Grid に載せる価値は、単に送れるようになったことではなく、Azure 側の統合設計を標準化できることにあります。まずは partner topic を 1 つ作り、1 つの Function と 1 つの dead-letter 設定から始めるのが、いちばん失敗しにくい進め方です。 (Microsoft Learn)
コメント