リアルタイム在庫同期アーキテクチャ: Webhook、キュー、競合解決

1 回の過剰販売には、払い戻し処理、顧客サービス時間、市場での欠陥に対するペナルティ、信用の喪失といった直接コストが平均 47 ドルかかります。 4 つのチャネルで 1 日あたり 500 件の注文を処理する中規模市場の販売者の場合、過剰販売率が 1% であっても、年間 70,000 ドルの損失が発生します。根本的な原因は、ほとんどの場合、在庫同期の遅延です。

この投稿では、リアルタイムの在庫同期の背後にあるアーキテクチャ、つまりイベントがどのように伝播するか、キューがトラフィックの急増をどのように吸収するか、利益と市場での地位の両方を侵食する過剰販売を競合解決によってどのように防ぐかについて詳しく説明します。

重要なポイント

• Webhook は 1 秒未満の通知を配信しますが、冪等なハンドラーと検証が必要です
• メッセージ キューは取り込みを処理から切り離します - マーケットプレイスのイベントを同期的に処理しません
• 競合を解決するには、絶対数量の上書きではなく、デルタベースの更新を備えた中央在庫台帳が必要です
• Webhook が主要な同期方法である場合でも、ポーリングは調整メカニズムとして引き続き不可欠です

---

同期方法の比較

アーキテクチャに入る前に、チャネル間で在庫の同期を保つための 3 つの基本的なアプローチを理解するのに役立ちます。

運用上の推奨事項はハイブリッドです。 リアルタイムの更新と定期的な調整のためのポーリングには Webhook を使用します。これにより、イベント駆動型アーキテクチャの速度と、スケジュールされた検証の信頼性が得られます。

---

インベントリのイベント駆動型アーキテクチャ

イベント駆動型在庫システムは、販売、返品、発注書の受領、倉庫移動、手動調整など、在庫に影響を与えるあらゆるアクションをイベントとして扱います。これらのイベントはメッセージ キューに発行され、中央在庫台帳を更新して変更をすべてのチャネルに伝播するワーカーによって消費されます。

イベントの流れ

1. イベント ソース が在庫イベントを発行します (例: Shopify が orders/create Webhook を起動します)
2. 取り込みエンドポイント がイベントを受信し、信頼性を検証し、メッセージ キューに発行します。
3. 処理ワーカーがイベントを消費し、ERP の中央在庫台帳を更新します
4. 伝播ワーカー は更新された数量を読み取り、他のすべてのチャネルにプッシュします

このアーキテクチャには、次の 3 つの重要な特性があります。

• 非同期: 取り込みエンドポイントは Webhook にすぐに応答し (HTTP 200)、後で処理します。これにより、Webhook のタイムアウトが防止されます。
• 耐久性: メッセージ キューはイベントを永続化します。ワーカーがクラッシュすると、イベントが再配信されます。
• スケーラブル: 取り込みレイヤーを変更せずに、ワーカーを追加して、より高いスループットを処理できます。

---

Webhook: 設計と落とし穴

最新の e コマース プラットフォームのほとんどは、在庫関連イベントの Webhook をサポートしています。 Shopify は inventory_levels/update を送信し、Amazon SP-API は注文と在庫の変更に関する通知を提供し、WooCommerce は woocommerce_product_set_stock を起動します。

Webhook の検証

すべての Webhook ハンドラーは、リクエストが本物であることを確認する必要があります。偽造 Webhook ペイロードは実際の攻撃ベクトルです。攻撃者がシステム内で在庫変更を引き起こすと、意のままに過剰販売や在庫切れを引き起こす可能性があります。

• Shopify: X-Shopify-Hmac-SHA256 ヘッダーの HMAC-SHA256 署名、アプリ シークレットと照合して検証
• Amazon SP-API: SNS メッセージの署名検証
• WooCommerce: X-WC-Webhook-Signature ヘッダーの Webhook シークレット

処理する前に必ず確認してください。開発時には検証を決して省略しないでください。これが運用上の脆弱性になる 1 つの近道です。

べき等性

Webhook は、少なくとも 1 回、厳密に 1 回ではなく配信されます。ネットワークの問題、再試行、プラットフォームの不具合により、ハンドラーが重複したイベントを受信することがあります。ハンドラーは冪等である必要があります。同じイベントを 2 回処理すると、1 回処理した場合と同じ結果が生成される必要があります。

冪等性の実装パターン:

• 冪等キー: Webhook ID (またはペイロードのハッシュ) を TTL を使用して Redis に保存します。キーが存在する場合は処理をスキップします。
• デルタ操作: Webhook データから絶対量を設定しないでください。代わりに、重複したアプリケーションが検出できるようにデルタ (例: 「1 ずつ減らす」) を適用します。
• データベース制約: 外部イベント ID に一意の制約を使用して、注文の重複インポートを防ぎます。

// Pseudocode: idempotent webhook handler
function handleInventoryWebhook(payload) {
  const eventId = payload.id
  const exists = await redis.set(eventId, '1', 'NX', 'EX', 86400)
  if (!exists) return // duplicate, skip

  await queue.publish('inventory.update', {
    sku: payload.sku,
    delta: payload.quantity_change,
    source: payload.source,
    eventId: eventId
  })
}

Webhook 障害の処理

エンドポイントが 2xx 以外のステータスを返すと、マーケットプレイスは指数関数的バックオフで再試行します。 Shopify は 48 時間で最大 19 回再試行します。 Amazon は最大 3 日間再​​試行します。システムがメンテナンスのためにダウンしている場合、イベントはマーケットプレイス側でキューに登録され、オンラインに戻ったときに一気に到着します。

アーキテクチャはこのバーストを処理する必要があります。これもメッセージ キューを使用するもう 1 つの理由です。キューがバーストを吸収し、ワーカーが持続可能な速度でイベントを処理します。

---

インベントリ イベントのメッセージ キュー

メッセージ キューは、在庫同期アーキテクチャの背骨です。イベントの取り込みを処理から切り離し、耐久性を提供し、独立したスケーリングを可能にします。

キューテクノロジーの選択

Odoo ベースの統合の場合、ECOSIRE はデフォルトとして BullMQ (Redis 上に構築) を使用します。ジョブの優先順位付け、ジョブの遅延、レート制限、監視用のダッシュボードが提供されます。これらはすべてインベントリの同期に重要です。 Odoo デプロイメントではすでにキャッシュに Redis が使用されているため、セットアップは最小限で済みます。

キュー設計パターン

トピックベースのルーティング: さまざまなイベント タイプごとにキューを分けます。在庫イベントは inventory.updates に、注文イベントは orders.created に、価格変更は products.price_updated に移動します。これにより、ワーカーを個別にスケールすることができます。在庫同期により、ピーク時により多くのワーカーを獲得できる一方で、製品の更新は独自のペースで処理されます。

優先キュー: すべての在庫更新が同じであるわけではありません。過剰販売は即座に財務に影響を与えるため、販売（減額）は購入受領（増額）よりも緊急です。デクリメントイベントに高い優先順位を割り当てます。

デッド レター キュー (DLQ): N 回の再試行後に処理に失敗したイベントは、手動検査のために DLQ に移動します。これにより、有害なメッセージがキュー全体をブロックするのを防ぎます。 DLQ エントリを毎日確認します。多くの場合、データ マッピングの問題や API の変更が明らかになります。

---

紛争解決戦略

インベントリ同期における最も困難な問題は、同時更新です。 2 人の顧客が、異なるチャネルで同時に製品の最後のユニットを購入します。競合を解決しないと、両方の注文が成功し、過剰に販売されてしまいます。

中央元帳パターン

最も信頼できるアプローチは、唯一の信頼できる情報源である ERP 内の中央在庫台帳です。チャネルは売上を報告し、ハブは利用可能な数量を再計算します。

ルール: チャネルは絶対量を設定しません。デルタ (売上、返品、調整) が報告され、中央元帳が新しい利用可能数量を計算して伝播します。

これにより、2 つのチャネルが同時に同じ量を読み取り、それをローカルでデクリメントし、同じ値を書き戻す、つまりデクリメントの 1 つが失われるという、ある種の競合状態が排除されます。

予約システム

高速 SKU の場合、デルタベースの同期でも十分な速度が得られません。予約システムは、販売速度とバッファルールに基づいて在庫をチャネルに事前に割り当てます。

安全バッファは同期遅延を防ぎます。同期が伝播するまでに Amazon が 2 個のユニットを販売した場合、その差はバッファによって吸収されます。

最終的な整合性

マルチチャネル在庫は、結果的に整合性のあるシステムです。どのミリ秒においても、チャネル数量は中央台帳と正確に一致しない可能性があります。目標は、整合性ウィンドウ (変更から完全な伝播までの時間) を最小限に抑え、安全バッファーを使用してそのウィンドウ中のリスクを管理することです。

優先度に応じて整合性ウィンドウをターゲットにします。

• 売上 (減少): 5 秒未満
• 戻り値 (増分): 60 秒未満
• 調整: 5 分未満
• 完全な調整: 6 ～ 12 時間ごと

---

調整としてのポーリング

Webhook ファーストのアーキテクチャであっても、ポーリングは依然として不可欠です。 Webhook は、失われたり、遅延したり、順序が狂って到着したりする可能性があります。調整ジョブはスケジュールに従って実行され、各チャネルから現在の状態を取得し、それを中央台帳と比較します。

不一致にはフラグが付けられ、小さな差（3 単位未満）については自動的に修正され、大きな差については手動レビューのためにエスカレーションされます。これにより次のことがわかります。

• マーケットプレイスの停止により Webhook を逃した
• マーケットプレイスのダッシュボードで直接手動で調整
• 数量計算における丸め誤差
• システムメンテナンス期間中に失われたイベント

監視と障害検出のより広い視野については、「統合監視: 同期障害の検出」(/blog/integration-monitoring-sync-failures) を参照してください。

---

スケーリングに関する考慮事項

注文量が増加するにつれて、在庫同期アーキテクチャは新たな課題に直面します。

レート制限管理

すべてのマーケットプレイス API にはレート制限があります。倉庫受領後に Amazon の 5,000 SKU にわたる在庫を更新する必要がある場合、5,000 の API 呼び出しを同時に起動することはできません。レート制限されたワーカー キューは、最大許容レート (Amazon SP-API: インベントリ フィードの場合 10 リクエスト/秒) で更新をドリップします。

バッチとリアルタイムのトレードオフ

10,000 SKU を超えるカタログの場合、カタログ全体の同期は、リアルタイムの個別更新からバッチ化されたフィード送信に移行します。 Amazon の在庫フィードは、1 回の API 呼び出しで数千の SKU を処理します。 Shopify の一括操作 API は、大規模な更新を効率的に処理します。

アーキテクチャは両方のパターンをサポートする必要があります。高速 SKU (売上高上位 20%) の場合はリアルタイム、ロングテールの場合はバッチ処理です。

地理的分布

地域 (米国、EU、APAC) をまたいで販売すると、待ち時間の問題が生じます。米国東部の Redis インスタンスでは、EU ベースのプラットフォームからの Webhook 処理に往復 200 ミリ秒が追加されます。グローバル展開の場合は、中央台帳のクロスリージョン レプリケーションを使用したリージョン処理を検討してください。

マルチチャネル アーキテクチャ設計の詳細については、柱となる投稿: 究極の e コマース統合ガイド を参照してください。

---

よくある質問

過剰販売を防ぐには、在庫の同期はどれくらいの速度で行う必要がありますか?

ほとんどの販売業者にとって、30 秒未満の同期により、大部分の過剰販売が防止されます。リスク ウィンドウは、あるチャネルでの販売から在庫の更新が他のチャネルに届くまでの時間です。 30 秒のウィンドウで 1 日あたり 500 件の注文がある場合、同じ SKU が同時に販売される確率は 0.1% 未満です。高速 SKU (SKU ごとに 1 日あたり 100 以上の販売) では、5 秒未満の同期または予約システムのメリットが得られます。

Webhook の代わりにポーリングを使用できますか?

可能ですが、5 分間隔でポーリングすると、すべてのチャネルでインベントリが 5 分間古くなっている可能性があります。適度な注文量では、これにより過剰販売が保証されます。ポーリングはフォールバックおよび調整メカニズムとして機能しますが、Webhook をサポートするチャネルでは、Webhook を主要な同期トリガーにする必要があります。

Odoo ではどのメッセージ キューを使用すればよいですか?

Odoo の展開には、BullMQ (Redis 上に構築) が推奨されます。 Odoo インフラストラクチャにはキャッシュ用の Redis がすでに含まれているため、新しいインフラストラクチャは必要ありません。 BullMQ は、ジョブの優先順位付け、レート制限、遅延ジョブ、および監視ダッシュボードを提供します。 1 日あたり 100,000 イベントを超えるエンタープライズ展開の場合は、RabbitMQ または Kafka を検討してください。

マーケットプレイスの停止中に在庫の同期を処理するにはどうすればよいですか?

影響を受けるチャネルのすべてのアウトバウンド更新をキューに入れます。マーケットプレイスがオンラインに戻ったら、順番にキューを空にします。インバウンド イベント (マーケットプレイスからの注文) の場合、マーケットプレイスは回復時に Webhook を再実行します。冪等性レイヤーにより、重複した処理が発生しないことが保証されます。停止期間をカバーするために安全バッファを維持します。

理想的な調整頻度はどれくらいですか?

完全な調整は、アクティブな SKU については 6 ～ 12 時間ごとに、完全なカタログについては 24 時間ごとに実行します。調整を頻繁に行うと、動きの遅い SKU で API クォータが無駄になります。調整の頻度が低いと、ドリフトが蓄積する可能性があります。過剰販売率に基づいて調整します。ドリフト関連の問題が発生している場合は、頻度を増やします。

---

次は何ですか

在庫同期はマルチチャネル e コマースの技術的基盤ですが、単独で存在するものではありません。チャネル全体で在庫が正確になったら、次のステップは、フルフィルメント ネットワークを通る注文の流れを最適化することです。

Odoo 向けの実稼働対応インベントリ同期コネクタについては ECOSIRE の統合サービス をご覧ください。特定のアーキテクチャ要件については 当社のチームにお問い合わせください してください。

---

ECOSIRE によって発行 — Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。