定義
Webhook（ウェブフック） とは、あるシステムで特定のイベントが発生した瞬間に、そのシステム側からあらかじめ登録されたURL（エンドポイント）へ自動的にHTTPリクエスト（通常はPOST）を送信する仕組みです。受け取り側は「ポーリング」のように定期的に問い合わせる必要がなく、イベントドリブンでデータを受け取れます。
DTC・越境ECの文脈では、Shopify、WooCommerce、BASE、Magento、BigCommerceなどのECプラットフォームや、Stripe、PayPal、Klarnaなどの決済プロバイダー、さらにはShipStation、17track、ヤマトB2クラウドなどの物流系SaaSが標準でWebhookを提供しています。たとえば「注文が作成された」「決済が完了した」「配送業者が荷物をピックアップした」といったタイミングで、自社のOMS（受注管理システム）やWMS（倉庫管理システム）、CRM、MAツールへ即座にデータを流し込めます。
类比（たとえ話）
Webhookは「呼び鈴（インターホン）」に近い概念です。
- ポーリング＝玄関のドアを30秒おきに自分で開けて「誰か来てないかな？」と確認する行為。無駄が多く、来客に気づくのが最大30秒遅れる。
- Webhook＝来客がインターホンを押した瞬間に「ピンポン」と鳴る仕組み。自分はソファで休んでいてよく、鳴った瞬間だけ対応すればよい。
EC運営に置き換えると、ポーリングは「5分ごとにShopify APIへ新規注文がないか問い合わせる」、Webhookは「Shopifyが注文作成の瞬間に自社サーバーへ通知してくれる」という違いになります。
公式（仕組みの数式）
Webhookの基本的な動作は、次のように表現できます。
POST https://your-app.example.com/webhooks/shopify/orders-create
Headers:
X-Shopify-Topic: orders/create
X-Shopify-Hmac-Sha256: <署名>
Body:
{ "id": 820982911946154500, "total_price": "12800.00", "currency": "JPY", ... }
レスポンスは HTTP 200 を200ミリ秒以内に返すのが推奨です。Shopifyの場合、5秒以内に応答がないと失敗とみなされ、最大19回まで再送されます（初回失敗から48時間以内）。
冪等性を担保するためのキー式：
idempotency_key = hash(event_id + source + timestamp)
对比表：Webhook vs ポーリング vs 手動CSV
| 項目 | Webhook | ポーリング | 手動CSV |
|---|---|---|---|
| 通知タイミング | リアルタイム（通常1〜3秒） | 設定間隔に依存（例：5分） | 人手作業時のみ |
| APIコール数/日 | イベント発生時のみ（例：1,000件で1,000回） | 288回×エンドポイント数 | 0回 |
| 遅延リスク | ほぼゼロ | 最大で間隔分の遅延 | 数時間〜数日 |
| 実装難易度 | 中（署名検証・再送対応） | 低 | 極低 |
| 向いている用途 | 注文・決済・在庫・配送 | 日次バッチ、分析用集計 | 小規模・単発移行 |
| 代表例 | Shopify orders/create | 楽天RMS API定期取得 | 管理画面からCSV出力 |
応用シーン（DTC・越境ECでの具体例）
1. 注文同期：Shopifyで注文が入った瞬間、Webhookが自社OMSへPOST。平均1.8秒で在庫引当が完了し、ダブルセールを防止。
2. 決済ステータス更新：Stripeのpayment_intent.succeededを受信し、注文ステータスを「支払済」へ自動更新。手動突合の工数を月約40時間削減。
3. 越境配送トラッキング：17trackやShipStationのtracking.updatedを受信し、顧客のマイページとメール配信を自動トリガー。問い合わせ削減率32%の事例も。
4. 在庫・価格の双方向同期：WMSからinventory_level.updatedを受信し、Shopifyの在庫数を秒単位で反映。
5. CRM/MA連携：KlaviyoやHubSpotへcustomer.createdを送信し、ウェルカムフローを即日起動。
よくある誤解（アンチパターン）
- 「Webhookは絶対に届く」と思い込む：ネットワーク障害やダウンタイムで失敗します。必ず再送＋デッドレターキュー（DLQ）を設計。
- 署名検証を省略する：X-Shopify-Hmac-Sha256などのHMAC検証を怠ると、第三者による偽リクエストで不正注文が混入します。
- 重複イベントを考慮しない：同じevent_idが複数回届く前提で、冪等性キーを必ず実装。
- 処理を同期で行う：重い処理（PDF生成、外部API連携）はキューに積み、200を即返すのが鉄則。
- 1つのエンドポイントに全イベントを集約：トピックごとにURLを分けた方がデバッグが容易。
- リトライ間隔を無視：Shopifyは指数バックオフで再送。受信側もレート制限を意識する。
関連用語
- API：WebhookはAPIの「プッシュ型」の一種。
- ポーリング：Webhookの対義語的な取得方式。
- HMAC署名：リクエストの正当性を検証する仕組み。
- 冪等性（Idempotency）：同じリクエストを複数回受けても結果が変わらない性質。
- イベントドリブンアーキテクチャ：Webhookを中核とした設計思想。
- メッセージキュー：SQS、RabbitMQ、Cloud Tasksなど。Webhookの受け皿として頻用。
- Zapier / Make / n8n：ノーコードでWebhookを連携できるiPaaS。
- DLQ（Dead Letter Queue）：失敗イベントを退避させるキュー。
まとめ：Webhookは、DTC・越境ECにおいて「注文・決済・在庫・配送」を秒単位で同期させるための必須インフラです。ポーリング比でAPIコールを最大99%削減できる一方、署名検証・冪等性・再送設計という3点セットを欠かすと、かえってインシデントの温床になります。まずはShopifyやStripeの公式Webhookから始め、OMSやMAへ段階的に接続していくのが定石です。
