Webhook & イベント配送インフラ 2026 — Svix / Hookdeck / ngrok / Sequin / Convoy / Standard Webhooks 徹底解説

「Webhook は最も単純な非同期統合パターンであり、同時に最も頻繁に壊れる統合パターンでもある。2026 年において、生の POST ハンドラを自前で実装し続ける合理的な理由はもう存在しない。」— Standard Webhooks Working Group, 2024

Webhook は 2007 年に Jeff Lindsay が用語化して以来、パターンとしてはほとんど変わっていません。しかし運用面の表面積は爆発的に拡大しました。Stripe、Twilio、Shopify、GitHub、Slack のような SaaS を 1 つ統合するだけで、1 日に数十万から数百万件の POST が自社インフラに流れ込み、逆に自社サービスから外部へ出すイベントも同じ規模で増えています。

2026 年 5 月現在、Webhook インフラは単なる「HTTP POST 受信」ではなく、ゲートウェイ (Gateway)、信頼性 (Reliability)、トンネル (Tunnel)、デバッガ (Debugger)、クラウドネイティブイベントバス (Cloud-native Event Bus) の 5 カテゴリに分化した巨大な生態系です。本稿では Svix、Hookdeck、ngrok、smee.io、Sequin、Convoy、Webhook.site、RequestBin、Beeceptor、AWS EventBridge、GCP Eventarc、Azure Event Grid、Inngest、そして Standard Webhooks 仕様までを一度に整理します。

1. 2026 年の Webhook インフラ地図 — Gateway / Reliability / Tunnel / Cloud-Native

役割で切ると、Webhook インフラは 5 つの箱に整理できます。

送信側 (Producer) と 受信側 (Consumer) では要件が全く異なります。Producer は「送ったイベントが顧客に届いたか、届かなかったら何回リトライしたか」が重要、Consumer は「外から無作為に流れ込むトラフィックを自社のコアシステムから分離 (バッファ) できるか」が重要。Hookdeck のように両方を扱う製品もあれば、Svix のように Producer に集中する製品もあります。

Webhook インフラ選定の最初の分岐点は常に「自分は送信側か、受信側か、両方か」です。この問いが本稿全体を貫きます。

2. Webhook の標準 — Standard Webhooks (2023.4) とそのインパクト

20 年間、標準化されないまま育った結果、各 SaaS は異なる署名ヘッダ名、異なるペイロード形式、異なるリトライポリシーを持つことになりました。Stripe は Stripe-Signature、GitHub は X-Hub-Signature-256、Shopify は X-Shopify-Hmac-Sha256、Slack は X-Slack-Signature — 統合 1 件ごとに新しい SDK を覚える必要がありました。

2023 年 4 月、Svix が主導し Zapier、Twilio、Lob、Ngrok、Vercel、Supabase などが連名した Standard Webhooks イニシアチブが、この混沌を標準化するために発足しました。中核となる規約は次のとおりです。

• 共通ヘッダ 3 種: webhook-id, webhook-timestamp, webhook-signature
• 署名方式: HMAC-SHA256、base64 エンコード、v1, プレフィックス
• タイムスタンプ検証: デフォルト許容ウィンドウ 5 分 (再送攻撃対策)
• ペイロード形式: JSON、type + data 構造を推奨
• リトライポリシー推奨: 指数バックオフ (5 秒、5 分、30 分、2 時間、5 時間、10 時間、16 時間) — 約 24 時間で諦め
• イベント ID: 冪等性キーとして使える一意 ID

2024 年以降、Vercel、Supabase、Resend、Linear、Cal.com のようなモダン SaaS は最初から Standard Webhooks 互換でリリースされ、2025 年には Stripe も新しい v2 Event API で部分採用しました。2026 年 5 月現在、標準ヘッダ (webhook-id, webhook-timestamp, webhook-signature) をサポートする SaaS は 100 を超えています。

標準化がもたらした最大の価値は 検証 SDK の共通化 です。standardwebhooks パッケージひとつで全ての互換 SaaS の署名を検証でき、新しい統合を追加するたびに新 SDK を学ぶ必要がなくなりました。

3. 署名検証 — HMAC-SHA256、timing-safe compare

Webhook セキュリティの中核は「このリクエストは本当にその SaaS から来たのか」を検証することです。ほぼ全ての SaaS は HMAC-SHA256 ベースの署名を使います。標準フローは次のとおりです。

1. SaaS と自社が共有秘密 (signing secret) を持つ
2. SaaS はペイロードとタイムスタンプを結合し HMAC-SHA256 で署名
3. ヘッダに署名を載せて送信
4. 自社は同じ鍵で同じ入力を署名し比較
5. 必ず timing-safe compare で比較 (タイミング攻撃対策)

Node.js で Standard Webhooks 互換の検証を自前実装すると次のようになります。

import { createHmac, timingSafeEqual } from 'node:crypto'

export function verifyStandardWebhook(opts: {
  payload: string  // raw body — byte-exact な原本。JSON.stringify(parsed) ではない
  headers: Record<string, string>
  secret: string   // 'whsec_xxx' 形式の base64 エンコード済み鍵
  toleranceSeconds?: number
}): boolean {
  const { payload, headers, secret, toleranceSeconds = 300 } = opts
  const id = headers['webhook-id']
  const timestamp = headers['webhook-timestamp']
  const signature = headers['webhook-signature']
  if (!id || !timestamp || !signature) return false

  // 1) タイムスタンプウィンドウ検証 (再送攻撃対策)
  const ts = parseInt(timestamp, 10)
  const now = Math.floor(Date.now() / 1000)
  if (Math.abs(now - ts) > toleranceSeconds) return false

  // 2) signed content の組み立て: "id.timestamp.payload"
  const signedContent = `${id}.${timestamp}.${payload}`

  // 3) base64 の secret を raw bytes にデコード
  const secretBytes = Buffer.from(secret.replace(/^whsec_/, ''), 'base64')

  // 4) HMAC-SHA256 を計算
  const expected = createHmac('sha256', secretBytes)
    .update(signedContent)
    .digest('base64')

  // 5) ヘッダには "v1,sig1 v1,sig2" の形で複数署名が入りうる (キーローテーション対応)
  const sigs = signature.split(' ').map((s) => s.split(',')[1]).filter(Boolean)

  // 6) timing-safe compare — 絶対に === を使わない
  return sigs.some((sig) => {
    const sigBytes = Buffer.from(sig, 'base64')
    const expBytes = Buffer.from(expected, 'base64')
    if (sigBytes.length !== expBytes.length) return false
    return timingSafeEqual(sigBytes, expBytes)
  })
}

3 つの落とし穴があります。

ペイロードは raw bytes で受け取ること。 Express の body-parser や Next.js Route Handler が自動 JSON.parse したオブジェクトを再度 JSON.stringify すると、空白文字やキー順序が変わって署名が崩れます。Next.js App Router では await req.text()、Express では bodyParser.raw({ type: '*/*' }) で原本を受け取ってください。

タイムスタンプウィンドウ検証を忘れない。 署名のみを検証すると、攻撃者が一度傍受した有効リクエストを永遠に再送できます。Standard Webhooks、Stripe、Slack は全てデフォルト 5 分です。

timing-safe compare を必ず使う。 === や Buffer.compare は最初の異なるバイトで即 false を返すため、タイミング差から 1 バイトずつ署名を当てられます。Node.js には crypto.timingSafeEqual、Python には hmac.compare_digest、Go には subtle.ConstantTimeCompare があります。

4. 冪等性 + リトライ + 指数バックオフ

Webhook の 2 つ目の難所は「受信側が同じイベントを 2 回受け取ったらどうなるか」です。送信側は 200 を受け取るまでリトライするので、ハンドラがタイムアウトしたり一瞬落ちたりすると、同じイベントが何度も届きます。

冪等性 (Idempotency) の中核パターンは、イベント ID をキーにした重複処理防止テーブルです。

// 冪等処理の例 — Postgres + Redis の組み合わせ
import { db } from '@/lib/db'
import { redis } from '@/lib/redis'

export async function handleWebhookIdempotent(event: {
  id: string         // SaaS が送ってきた一意 ID (webhook-id ヘッダまたは payload 内 id)
  type: string
  data: unknown
}) {
  // 1) Redis で高速ロック (TTL 60 秒) — 同時到着への防御
  const lockKey = `webhook:lock:${event.id}`
  const acquired = await redis.set(lockKey, '1', 'NX', 'EX', 60)
  if (!acquired) {
    // 別ワーカが処理中 — 200 を返して SaaS のリトライキューを掃く
    return { status: 'in-flight' }
  }

  try {
    // 2) Postgres に永続的な処理記録 (UNIQUE 制約でデュープ防止)
    const inserted = await db.query(
      `INSERT INTO processed_webhooks (event_id, event_type, received_at)
       VALUES ($1, $2, NOW())
       ON CONFLICT (event_id) DO NOTHING
       RETURNING event_id`,
      [event.id, event.type]
    )

    if (inserted.rowCount === 0) {
      // 既に処理済み — 200
      return { status: 'duplicate' }
    }

    // 3) 実ビジネスロジック
    await processBusinessLogic(event)
    return { status: 'processed' }
  } finally {
    await redis.del(lockKey)
  }
}

送信側のリトライポリシーは 指数バックオフ + ジッター (Jitter) が標準です。Standard Webhooks の推奨は次のとおり。

ジッターをプラスマイナス 10〜25 % 加えると、thundering herd を防げます。

受信側が「今は受け取れない」と伝える方法は 2 つあります。429 Too Many Requests に Retry-After ヘッダを添えると、行儀の良い送信側はその時間だけ待ってくれます。5xx を返すと自動バックオフキューに入ります。4xx (400, 401, 422) を返すと恒久的失敗とみなされリトライされないので、一時的な問題のときに 4xx を返してはいけません。

5. Svix — オープンソースの Webhook ゲートウェイ

Svix (svix.com) は 2021 年創業、2023 年シリーズ A を獲得した Webhook インフラ企業で、最もよく知られたオープンソース Webhook ゲートウェイを運営しています。Lob、Brex、Clerk、Lightspeed、Benchling、Resend などが Svix の上で自社 Webhook を運用しています。

中核の価値提案は「Stripe レベルの Webhook システムを 1 週間ではなく 1 日で構築できる」。自前構築で必要なもの — キュー、リトライ、指数バックオフ、署名、冪等性、サーキットブレーカ、ダッシュボード、ログ保管、replay UI、OpenAPI スキーマ — を SDK 1 行で代替します。

// Svix で顧客にイベントを送る
import { Svix } from 'svix'

const svix = new Svix(process.env.SVIX_AUTH_TOKEN!)

// 1) 顧客アプリケーション作成 (1 度のみ)
const app = await svix.application.create({
  name: 'Acme Corp',
  uid: 'cust_acme_001',
})

// 2) 顧客が自分のエンドポイントを登録 (ダッシュボードまたは API)
await svix.endpoint.create(app.id, {
  url: 'https://acme.com/webhooks',
  description: 'Production endpoint',
})

// 3) イベント送信 — Svix がキュー、リトライ、署名を処理
await svix.message.create(app.id, {
  eventType: 'invoice.paid',
  eventId: `evt_${invoice.id}`,  // 冪等性キー
  payload: {
    invoice_id: invoice.id,
    amount: invoice.amount,
    customer: invoice.customer_id,
  },
})

Svix のオープンソース版 (github.com/svix/svix-webhooks) は Rust 製サーバ、PostgreSQL、Redis、RabbitMQ を自前ホストできます。クラウド版は月 5,000 件まで無料、それ以上はメッセージ単価課金です。

2025 年 11 月、React、Vue 向けの埋め込みダッシュボードウィジェット (@svix/react) が正式リリースされ、顧客が自社アプリ内で自分のエンドポイントの登録・テスト・ログ確認をできるようになりました。これは自前構築で最も時間がかかる部分なので大きな差別化要因です。

6. Hookdeck — Webhook 信頼性プラットフォーム

Hookdeck (hookdeck.com) はカナダのモントリオール拠点で 2021 年創業、2024 年にシリーズ A を獲得しました。Svix が「送信側」中心なら、Hookdeck は「受信側 + 双方向」中心です。

中核シナリオは インバウンド Webhook の信頼性保証 です。Stripe、Shopify、GitHub のような外部 SaaS の Webhook URL に https://hkdk.events/xxx を登録しておけば、Hookdeck がそれを受け取り自社バックエンドに転送します。自社バックエンドが死んでいても Hookdeck がバッファリング・リトライし、Hookdeck ダッシュボードから失敗イベントをワンクリックで replay できます。

# Hookdeck CLI でローカル開発環境に Webhook をフォワード
hookdeck listen 3000 stripe --path /api/webhooks/stripe

# 出力例:
# Inbound URL: https://hkdk.events/abcd1234
# Forwarding to: http://localhost:3000/api/webhooks/stripe
# Connection: stripe-local

この 1 行で ngrok なしでもローカル環境に外部 Webhook を受けられ、同時に全リクエストが Hookdeck ダッシュボードにログとして残ります。同じコマンドで production URL にもフォワードできるので、ローカル・ステージング・プロダクションで同一ゲートウェイを使えます。

2025 年にリリースされた Hookdeck Connect は Svix と正面競合するアウトバウンド Webhook プラットフォームで、同じダッシュボードで双方向を統合管理できます。

Hookdeck の差別化要素は Filtering & Transformation です。届いたペイロードを JavaScript 関数で変換したり、特定イベントタイプだけフィルタしてバックエンドに転送できます。

// Hookdeck Transformation の例
addHandler('transform', (request, context) => {
  // Stripe charge.succeeded イベントのみ通過
  if (request.body.type !== 'charge.succeeded') {
    return null  // drop
  }
  // ペイロード単純化
  return {
    ...request,
    body: {
      charge_id: request.body.data.object.id,
      amount: request.body.data.object.amount,
      customer: request.body.data.object.customer,
    },
  }
})

7. ngrok / Cloudflare Tunnel — ローカルトンネリング

Webhook 開発の永遠の課題は「ローカルマシンにどうやって外部トラフィックを届けるか」です。ngrok (ngrok.com) は 2013 年リリース以来の事実上の標準です。

2024 年、ngrok はブランドを Ngrok Edge にリネームし、単純なトンネルを超えて API Gateway、OAuth、Mutual TLS、Rate Limiting を提供するフルスタック ingress プラットフォームへ進化しました。

# 基本的な使い方 — ローカル 3000 ポートをインターネットに公開
ngrok http 3000

# 固定ドメイン (有料プラン)
ngrok http 3000 --domain=acme-dev.ngrok.app

# 認証・ヘッダ追加ゲートウェイとして
ngrok http 3000 \
  --domain=api-dev.acme.dev \
  --oauth=google \
  --oauth-allow-domain=acme.com

# YAML 設定ファイル
# ~/.ngrok2/ngrok.yml
# tunnels:
#   webhook-dev:
#     proto: http
#     addr: 3000
#     domain: webhooks-dev.acme.dev
#     request_header_add:
#       - "X-Forwarded-Source: ngrok-dev"

ngrok の対抗馬として浮上したのが Cloudflare Tunnel (旧 Argo Tunnel) です。Cloudflare アカウントさえあれば無料で永続ドメインを取得でき、Cloudflare のグローバルネットワークを通過するため DDoS・WAF が自動適用されます。

# cloudflared をインストールしたら一度認証
cloudflared tunnel login

# トンネル作成
cloudflared tunnel create my-dev-tunnel

# ルーティング (acme.com が Cloudflare DNS である必要あり)
cloudflared tunnel route dns my-dev-tunnel webhook-dev.acme.com

# ローカルサービスへフォワード
cloudflared tunnel run --url http://localhost:3000 my-dev-tunnel

Tailscale Funnel は 2023 年に GA となったもう 1 つの選択肢で、既存 Tailnet に属するノードをインターネットに公開できます。チーム内で既に Tailscale を使っているなら、追加アカウントなしで即活用できるのが利点です。

選定基準は次のとおり。素早い単発テスト は ngrok 無料プラン、チーム共用の永続開発 URL は Cloudflare Tunnel (無料)、エンタープライズの OAuth/Mutual TLS は ngrok Edge 有料プラン、既に Tailscale を使っているチーム は Funnel。

8. smee.io (GitHub) — 無料の開発フォワーディング

GitHub が運営する無料サービス smee.io (smee.io) は ngrok と似ていますがさらにシンプルです。ページで「Start a new channel」を 1 回押すだけで永続 URL が生成され、その URL に届くリクエストを SSE (Server-Sent Events) でローカルサーバへフォワードします。

# smee CLI インストール
npm install -g smee-client

# フォワード開始
smee --url https://smee.io/abcd1234 --path /webhooks/github --port 3000

# またはコードから
# import SmeeClient from 'smee-client'
# const smee = new SmeeClient({
#   source: 'https://smee.io/abcd1234',
#   target: 'http://localhost:3000/webhooks/github',
#   logger: console,
# })
# smee.start()

smee の強みは 無料、無制限、登録不要 です。弱点は SLA がないこと、トラフィックが急増すると GitHub に止められる可能性があること、認証・フィルタ機能がないこと。GitHub Apps 開発の公式ガイドに登場するツールなので、GitHub Webhook の学習用には最も摩擦の少ない選択肢です。

2025 年には smee.io に Web UI のペイロードプレビューが追加され、ブラウザでチャンネル URL を開いておけば届くリクエストをリアルタイム JSON で見られるようになりました。

9. Sequin — Postgres → Webhook/Kafka

Sequin (sequin.io) は 2022 年創業、2024 年に Andreessen Horowitz からシリーズ A を獲得した会社です。Sequin の差別化要素は Postgres の変更 (Change) を Webhook・Kafka・SQS にストリーミング することです。CDC (Change Data Capture) カテゴリですが、出力先として Webhook を 1 級でサポートします。

典型シナリオはこうです。自社バックエンドに外部統合用コードを書く時間がないとき、Sequin が Postgres トランザクションログ (WAL) を読み、INSERT/UPDATE/DELETE を自動で外部 HTTP エンドポイントに送ってくれます。

# sequin.yaml — Postgres テーブル → Webhook
sources:
  - name: orders-pg
    type: postgres
    url: postgresql://user:pass@db.acme.com:5432/app
    publication: sequin_pub
    slot: sequin_slot

destinations:
  - name: warehouse-webhook
    type: webhook
    url: https://warehouse.acme.com/api/orders
    headers:
      authorization: Bearer ${WAREHOUSE_TOKEN}
    retry:
      max_attempts: 8
      backoff: exponential

streams:
  - name: orders-to-warehouse
    source: orders-pg
    destination: warehouse-webhook
    tables:
      - name: orders
        actions: [insert, update]
        filter: "status IN ('paid', 'shipped')"

Sequin の長所は アプリケーションコード変更なし で DB 変更を外部に伝播することです。短所は Postgres WAL を正確に理解する必要があること、スキーマ変更時のスロット管理に注意が必要なこと。2025 年時点で Sequin は Stripe、Linear、Notion のような SaaS 連携も標準提供しており、「Stripe 新規 customer が生まれたら自社 DB に INSERT」のような双方向同期も可能です。

近隣カテゴリには Debezium (オープンソース、JVM ベース)、Fivetran HVR、Airbyte がありますが、Webhook 出力を 1 級でサポートするのは Sequin が最もきれいです。

10. Convoy — オープンソースの delivery

Convoy (getconvoy.io, github.com/frain-dev/convoy) はナイジェリアのラゴス拠点のオープンソース Webhook ゲートウェイです。Go 製、MIT ライセンスで、Svix Cloud と正面競合する self-hosted の選択肢です。

# Docker Compose で Convoy を起動
git clone https://github.com/frain-dev/convoy
cd convoy
docker compose -f deploy/docker-compose.yml up -d

# デフォルトでダッシュボードは 5005、API は 5004
open http://localhost:5005

Convoy のデータモデルは Svix とほぼ同じです。Project、Endpoint、Event、Subscription の 4 つのコアオブジェクトがあり、REST API でイベントをプッシュすると Convoy が Redis ベースのキューに入れ、ワーカーが外部 endpoint に配送します。

# Convoy CLI でイベント送信
curl -X POST http://localhost:5004/api/v1/projects/{project_id}/events \
  -H "Authorization: Bearer CONVOY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint_id": "endpoint_abc",
    "event_type": "user.created",
    "data": {
      "user_id": "u_123",
      "email": "alice@example.com"
    }
  }'

Convoy は Filter Expressions という SQL 風文法でルーティングルールを書けるのが特徴です。data.amount > 1000 AND data.currency == 'USD' のような条件で endpoint ごとに異なるイベントだけ受けられます。

自前ホストコストを負担せず始めたければ Convoy Cloud もありますが、Svix・Hookdeck と比べると市場シェアは小さい。自前ホストが必須な環境 (金融、ヘルスケア、GovCloud など) で検討する価値のある選択肢です。

11. Webhook.site / RequestBin / Beeceptor — デバッグ系ツール

Webhook を初めて統合するとき、最初に必要なのは「自分は本当に何を受け取っているのか」です。ペイロード構造、ヘッダ名、エンコーディングを目で見る必要があります。

Webhook.site (webhook.site) は最も人気のある無料ツールです。ページを開けば即座に一意 URL が生成され、その URL に届く全リクエストがリアルタイムで表示されます。ペイロード、ヘッダ、クエリ、メソッド、応答時間が全て 1 画面で確認可能。無料プランは 1 日 100 件、Premium は無制限 + 永続保管 + カスタム応答 + JavaScript で応答操作が可能です。

# テスト
curl -X POST https://webhook.site/abcd1234 \
  -H "Content-Type: application/json" \
  -d '{"hello": "world"}'

# ブラウザで https://webhook.site/#!/abcd1234 を開けばリアルタイム確認

RequestBin (requestbin.com) は Pipedream に買収後、有料化されましたが、オープンソース版 (github.com/Runscope/requestbin) を自前ホストできます。

Beeceptor (beeceptor.com) は単なるデバッグを超えて モック API サーバ を作るのに特化したツールです。届くリクエストに条件付き応答を定義でき、外部 API を模した偽サーバを 5 分で作れます。統合テスト環境で外部 SaaS がダウンした状況をシミュレートするときに有用です。

// Beeceptor の応答ルール例 (JS expression)
// 条件: request.body.action === "create"
// 応答: 201 + JSON
{
  "id": "{{$randomUUID}}",
  "created_at": "{{$timestamp}}",
  "echo": "{{request.body}}"
}

Diagnostic (diagnostic.dev) は 2024 年リリースの新ツールで、単なるインボックスではなく 使用した SaaS ごとのペイロードスキーマを自動推論 して OpenAPI 仕様を生成してくれます。Webhook.site で数日間受けたペイロードを解析し「この SaaS の invoice.paid イベントは平均 12 フィールドを送り、そのうち 3 つがオプショナル」といった統計を見せます。

3 ツールの分岐点は明確です。素早い単発デバッグ は Webhook.site、モック API は Beeceptor、長期ペイロード解析 は Diagnostic。

12. AWS EventBridge / Google Eventarc / Azure Event Grid — クラウドネイティブ

クラウド事業者も自社エコシステム向けイベントルータを提供しています。これらは単純な Webhook を超え、サービス間イベントバス の役割を果たします。

AWS EventBridge は 2019 年に GA となったサービスで、AWS 内部イベント (S3 PUT、EC2 状態変更など) と外部 SaaS (Stripe、Datadog、Shopify、GitHub など 100 以上のパートナー) のイベントを 1 か所でルーティングします。

# EventBridge ルール — Stripe 決済成功イベントが来たら Lambda 呼び出し
aws events put-rule \
  --name stripe-payment-success \
  --event-pattern '{
    "source": ["aws.partner/stripe.com"],
    "detail-type": ["charge.succeeded"]
  }'

aws events put-targets \
  --rule stripe-payment-success \
  --targets 'Id=1,Arn=arn:aws:lambda:us-east-1:123:function:processPayment'

EventBridge の中核は EventBridge Pipes (2022 年 GA) と Schema Registry です。Pipes は source → filter → enrich → target のパイプラインを GUI で構成し、Schema Registry は届くイベントスキーマを自動登録・バージョン管理します。

Google Eventarc は GCP 版です。Cloud Run、Cloud Functions、Workflows をイベントトリガとして呼び出し、Google Cloud の 70 以上のサービス (GCS、BigQuery、Pub/Sub、Cloud Build など) を source としてサポートします。AWS EventBridge より外部 SaaS の連携幅は狭いですが、CloudEvents v1.0 標準を 1 級でサポートします。

# Eventarc トリガ — GCS オブジェクト生成時に Cloud Run 呼び出し
gcloud eventarc triggers create gcs-upload-trigger \
  --location=us-central1 \
  --destination-run-service=process-upload \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=acme-uploads" \
  --service-account=eventarc@my-project.iam.gserviceaccount.com

Azure Event Grid は Microsoft の選択肢です。Azure サービス (Blob Storage、IoT Hub、Service Bus など) のイベントと SaaS イベントをルーティングし、MQTT v5 ブローカ機能まで統合されているため IoT シナリオに強い。2024 年に GA となった Event Grid Namespaces は pub/sub と webhook delivery を 1 リソースで処理します。

クラウドネイティブイベントバスの選定核心は 既にどのクラウドを使っているか です。AWS なら EventBridge、GCP なら Eventarc、Azure なら Event Grid。マルチクラウドなら Hookdeck・Svix のようなクラウド中立 SaaS が合理的です。

13. Inngest の Webhook 統合

Inngest (inngest.com) は 2022 年創業のイベントベースワークフロープラットフォームで、2024 年シリーズ B を獲得しました。中核価値は「キュー、cron、ワークフロー、Webhook を 1 つの SDK で」です。

Inngest は本来自前イベントシステムですが、2024 年から Webhook Source が 1 級市民になりました。Stripe・GitHub・Shopify の URL を Inngest ダッシュボードに登録すれば、Inngest がインボックスの役割を担い、届いたイベントを自動的に Inngest イベントに変換します。

// Inngest 関数 — Stripe webhook を受けて自動処理
import { inngest } from '@/inngest/client'

export const handleStripePayment = inngest.createFunction(
  {
    id: 'handle-stripe-payment',
    retries: 5,
    idempotency: 'event.data.id',  // Stripe event id で冪等性保証
  },
  { event: 'stripe/charge.succeeded' },  // Inngest が自動ルーティング
  async ({ event, step }) => {
    // step.run で包むと自動リトライ + 結果キャッシング
    const customer = await step.run('fetch-customer', async () =>
      db.customer.findUnique({ where: { stripeId: event.data.customer } })
    )

    await step.run('send-receipt', async () =>
      mailer.sendReceipt(customer.email, event.data)
    )

    // step.sleep で待機 — 関数一時停止、コスト 0
    await step.sleep('wait-1h', '1h')

    await step.run('send-followup', async () =>
      mailer.sendFollowup(customer.email)
    )
  }
)

Inngest の魅力は Webhook + キュー + ワークフロー + cron を 1 つの SDK に統合することです。Hookdeck が信頼性レイヤに集中するなら、Inngest はその上にビジネスロジックのオーケストレーションまで重ねます。

近隣カテゴリには Trigger.dev、Defer、Temporal Cloud があり、AWS Step Functions + EventBridge の組み合わせがクラウドネイティブな対抗馬です。

14. 韓国 / 日本の事例 — Toss、メルカリ、SmartHR

韓国 — Toss: トスペイメンツ (Toss Payments) は加盟店に 決済承認/取消/返金 Webhook を提供しており、自前構築のゲートウェイを使っています。2025 年のトスペイメンツ技術ブログで公開された内容によれば、1 日平均数億件の Webhook を処理するため Kafka ベースの自前キュー、ワーカープール、Redis ベースの冪等性キャッシュ、MongoDB ベースの永続ログ構造を採用しています。署名は RSA-SHA256 (公開鍵検証) + HMAC の二重構造で、加盟店はダッシュボードから直接失敗イベントを replay できます。

トスの特異点は 金融規制対応ロギング です。全 Webhook 送受信ログを 5 年間保管する必要があり、外部監査対応時に特定取引 ID でペイロード・署名・リトライ履歴を 1 秒以内に検索できる必要があります。これは Svix・Hookdeck のような外部 SaaS で解くのが難しい要件であり、トスが自前構築を選んだ理由でもあります。

日本 — メルカリ: メルカリはマイクロサービス間の非同期統合に Cloud Pub/Sub + Cloud Run + Eventarc の組み合わせを使っています。2024 年のメルカリエンジニアリングブログで公開された内容によれば、決済・在庫・配送ドメイン間のイベントフローを全て Pub/Sub topic で抽象化し、外部 SaaS 連携 (SendGrid、Stripe Connect など) は Eventarc trigger で受信します。内部サービスが外部 webhook を直接受け取らず常に Eventarc/Pub/Sub を経由するのが核心原則です。

日本 — SmartHR: HR SaaS の SmartHR は自社顧客 (人事担当者) に 従業員情報変更 Webhook を提供しています。2025 年の SmartHR Tech Blog で公開されたアーキテクチャは Rails + Sidekiq ベースの自前構築で、リトライは Sidekiq の指数バックオフ (最大 25 回、約 21 日)、署名は HMAC-SHA256、ペイロード形式は独自定義です。特異点は 顧客が登録した endpoint URL の信頼性スコア (Health Score) を計算し、スコアが低い endpoint は自動でサーキットブレーカを発動し顧客にメール通知を送ることです。

3 事例の共通点は 自前構築 + 運用自動化 です。一定規模を超えた SaaS は外部ゲートウェイを使うコストが自前構築コストを超え始めます。ただし自前構築は 6〜12 か月のエンジニアリング投資が必要なので、シリーズ A 以前の SaaS は Svix・Hookdeck で始めて PMF 検証後に自前構築へ移行するのが一般的な経路です。

15. 参考 / References

• Standard Webhooks specification — https://www.standardwebhooks.com/
• Standard Webhooks GitHub — https://github.com/standard-webhooks/standard-webhooks
• Svix documentation — https://docs.svix.com/
• Svix open source — https://github.com/svix/svix-webhooks
• Hookdeck documentation — https://hookdeck.com/docs
• Hookdeck CLI — https://github.com/hookdeck/hookdeck-cli
• Convoy open source — https://github.com/frain-dev/convoy
• Convoy documentation — https://docs.getconvoy.io/
• ngrok documentation — https://ngrok.com/docs
• Cloudflare Tunnel — https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
• Tailscale Funnel — https://tailscale.com/kb/1223/funnel
• smee.io — https://smee.io/
• Sequin — https://sequin.io/
• Webhook.site — https://webhook.site/
• Beeceptor — https://beeceptor.com/
• RequestBin (Pipedream) — https://pipedream.com/requestbin
• AWS EventBridge — https://docs.aws.amazon.com/eventbridge/
• AWS EventBridge Pipes — https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html
• Google Eventarc — https://cloud.google.com/eventarc/docs
• Azure Event Grid — https://learn.microsoft.com/en-us/azure/event-grid/
• Inngest webhooks — https://www.inngest.com/docs/platform/webhooks
• Stripe webhook signatures — https://docs.stripe.com/webhooks/signatures
• GitHub webhook deliveries — https://docs.github.com/en/webhooks
• Slack request signing — https://api.slack.com/authentication/verifying-requests-from-slack
• トスペイメンツ Developer Center — https://docs.tosspayments.com/
• メルカリ Engineering Blog — https://engineering.mercari.com/en/blog/
• SmartHR Tech Blog — https://tech.smarthr.jp/
• CloudEvents specification — https://cloudevents.io/
• OWASP Webhook Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Webhook_Security_Cheat_Sheet.html