基幹システムとECプラットフォーム連携で在庫ズレが生じる企業の共通点はAPI設計にある
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
基幹システムとECプラットフォームの連携で在庫ズレが起きる理由
基幹システムとECプラットフォームの在庫ズレは、API設計の不備によって生じる構造的な問題です。在庫ズレとは、基幹システムが保有する在庫数とECサイト上に表示される在庫数が一致していない状態のことで、発注ミス・顧客クレーム・機会損失を引き起こします。
多くのEC事業者は「在庫管理システムを導入すれば解決する」と考えがちですが、実際には導入後も在庫ズレが頻発します。その理由は、システム導入だけでなくAPI連携の設計が不十分だからです。
Shopify管理画面の在庫数と、基幹システムの数字が食い違っている。その瞬間、多くの担当者は「システムのバグだ」と思います。ここ、実はよくある誤解です。本当の原因は、リアルタイム連携のロジックが最初から設計されていないことにあります。
API設計が在庫ズレを起こす仕組みとは何か
API設計とは、基幹システムからECプラットフォームへデータを送る流れ・タイミング・精度を定義する設計のことです。在庫ズレとは、このAPI設計の不完全さによって生じる必然的な結果なのです。
在庫ズレが起きるメカニズムを理解するには、3つのレイヤーの連携構造を知る必要があります。
リアルタイム性の欠如がズレを生む
基幹システムで在庫が減った瞬間、その情報がECサイトに反映されるまでに時間差が生じます。多くの企業は15分ごと・1時間ごとの定期同期を採用していますが、その間にECサイトで商品が購入される可能性があります。
例えば、午前10時に基幹システムで在庫が1個に減ったとします。次の定期同期が10時15分だとすると、その15分間、ECサイトには在庫が2個あるように表示されたままです。この間に購入が入れば、在庫ズレが発生します。
API設計の不備な企業の特徴は「同期しているから大丈夫だろう」という思い込みです。実際には、同期の頻度・精度・エラーハンドリングが設計されていないため、ズレが蓄積していきます。
エラーハンドリングの欠落がズレを加速させる
API連携は必ず失敗します。ネットワーク遅延・タイムアウト・データ形式の不一致・サーバー側のエラーなど、様々な理由で同期が失敗することがあります。
問題は、この失敗が「無視される」ことです。エラーハンドリングが設計されていない連携では、同期に失敗しても通知が来ません。管理者も気づきません。結果として、基幹システムとECプラットフォームの数字がズレたまま放置されます。
福岡ECサイト株式会社が支援した食品メーカーの事例では、毎日平均3〜5件の同期エラーが発生していましたが、担当者は3ヶ月間気づかずにいました。その間、在庫ズレは累積し、顧客への欠品通知が遅れるトラブルが発生しました。
データ形式の不一致がズレの根本原因
基幹システムとECプラットフォームは異なるベンダーの製品であることが多く、在庫データの形式・単位・計算ロジックが異なることがあります。
例えば、基幹システムが「SKU単位」で在庫を管理し、ECプラットフォームが「色・サイズの組み合わせ単位」で在庫を管理している場合、単純な数値の一致だけでは不十分です。マッピング（変換）が必要になります。
このマッピングが正確に設計されていないと、在庫数は同期されているのに、商品ページに表示されるデータが間違っているという状況が生じます。
在庫ズレは5つのAPI設計の要素で決まる
在庫ズレを防ぐには、以下の5つのAPI設計要素を整備する必要があります。
- 同期の頻度と方向性の定義
- リアルタイム連携の仕組み
- エラーハンドリングとアラート
- データマッピングの正確性
- ロールバック・修復メカニズム
同期の頻度と方向性を定義する
最初に決めるべきは、どの頻度で、どの方向へ同期するかです。「基幹システム → ECプラットフォーム」が基本ですが、返品時に「ECプラットフォーム → 基幹システム」への逆同期も必要になることがあります。
同期の頻度は、売上規模と商品の回転速度で決まります。
- 月商100万円未満：1時間ごとで十分な場合が多い
- 月商100〜1000万円：15分ごと、または販売イベント時はリアルタイム
- 月商1000万円以上：リアルタイム連携が必須
判断基準は「在庫オーバーセリングのリスク」です。売上が大きいほど、ズレによる損失も大きくなるため、同期頻度を上げる必要があります。
リアルタイム連携の仕組みを実装する
定期同期の限界を超えるには、リアルタイム連携が必要です。基幹システムで在庫が変更された瞬間、その情報をECプラットフォームに即座に送る仕組みです。
実装方法は2つあります。
- Webhook型：基幹システムで在庫変更が発生した時点で、イベント通知を送る
- イベントストリーム型：在庫変更のログを順序保証で記録し、ECプラットフォームが読み込む
Webhook型は即座性が高いですが、失敗時の対応が複雑です。イベントストリーム型は遅延がありますが、再処理が容易です。月商500万円程度まではWebhook型で対応可能です。それ以上の規模ではイベントストリーム型の導入を検討する価値があります。
エラーハンドリングとアラートを設計する
連携エラーは「黙って失敗する」のではなく「可視化される」必要があります。エラーハンドリングとは、同期失敗時に自動的に再試行し、それでも失敗したら管理者に通知する仕組みです。
具体的には以下の3段構成です。
- 即座再試行：失敗から5秒以内に自動で再試行
- 遅延再試行：1分後・5分後・1時間後に段階的に再試行
- 管理者通知：複数回の再試行に失敗したら、Slackやメールで通知
深夜にSlack通知が来ると、担当者は焦ります。でも実際には、通知が来ることは正常の証明です。発見されないまま放置される方が、はるかに危険な状態です。通知が来るから、初めてエラーに気づき、対応できます。
データマッピングの正確性を確保する
基幹システムとECプラットフォームで異なるデータ形式を使っている場合、マッピング（変換）ロジックが重要になります。
例えば、基幹システムの「商品ID：001」が、ECプラットフォームの「SKU：A-001-RED-M」に対応する場合、この対応関係を正確に管理する必要があります。マッピングテーブルが間違っていると、在庫数は同期されても、間違った商品に反映されることになります。
マッピングテーブルは定期的に検証する必要があります。判断基準は「商品が追加・削除されるたび、マッピング漏れがないか確認する」です。
ロールバック・修復メカニズムを備える
ズレが発見されたとき、すぐに修復できる仕組みが必要です。
修復方法は3種類あります。
- 手動修正：管理画面から直接在庫数を修正（時間がかかる・ミスの原因になる）
- 自動ロールバック：基幹システムの数字を基準に、ECプラットフォームの在庫を自動修正
- 増分同期修復：ズレが生じた時点から現在までの取引を遡り、差分を計算して修正
月商100万円以上の企業は「自動ロールバック」の導入を検討すべきです。基幹システムが唯一の真実であり、ECプラットフォームはその複製という位置付けなら、自動修正が安全です。
従来の在庫連携とAPI設計型連携の構造的な違い
| 要素 | 従来の在庫連携 | API設計型連携 |
|---|---|---|
| 同期方式 | 定期同期（1時間ごと） | リアルタイム+定期バッチ併用 |
| エラー対応 | 失敗を無視・月1回の手動確認 | 失敗を検知・即座に再試行・通知 |
| データ形式 | 数値の一致のみ確認 | マッピング定義・単位変換・検証ルール |
| 修復 | 手動で台帳確認・手入力修正 | 自動ロールバック・増分修復 |
| ズレの頻度 | 月3〜10件 | 月0〜1件 |
従来方式は「同期している気がしているが、実際には放置されている」状態です。API設計型は「ズレを前提に、検知・修復を自動化している」アプローチです。
在庫ズレが実際に起きた企業が見落としていた設計ポイント
失敗例1：同期していることに満足して、エラーハンドリングがない
「システムを導入したから大丈夫」という思い込みは危険です。多くの場合、定期同期は実装されていますが、その同期が失敗したときの対応が設計されていません。
結果として、数週間前からのズレが蓄積し、在庫確認時に初めて発見されるという事態が起きます。
失敗例2：リアルタイム性が必要な販売イベント時の対応がない
セール期間中、販売ペースが通常の10倍になることがあります。このとき、1時間ごとの定期同期では追いつきません。
セール開始2時間後、在庫は実際には0なのに、ECサイトには10個あると表示されている状況が起きます。その間に20件の注文が入り、大量の欠品クレームが発生するケースは少なくありません。
API設計が在庫ズレを起こさない企業の条件
在庫ズレが起きない企業の共通点
API設計が適切に実装されている企業には、以下の特徴があります。
- 基幹システムとECプラットフォームの連携仕様書が存在する
- 同期頻度・データマッピング・エラー時の対応が明記されている
- 定期的な在庫検証が自動化されている
- ズレが発生したときの修復プロセスが決まっている
- 連携担当者だけでなく、営業担当者も在庫連携の制限を理解している
重要なのはここです。在庫ズレが起きない企業は「ズレを防ごうとしている」のではなく、「ズレが起きることを前提に、対応を設計している」という点が根本的に違います。
福岡ECサイト株式会社が支援した事例：月商2000万円の衣料品ECの在庫連携最適化
衣料品メーカーのECサイトでは、セール期間中に毎回20件以上の欠品クレームが発生していました。
原因は、基幹システムとShopifyの連携が「1時間ごとの定期同期のみ」だったこと。セール開始直後、1時間の間に100件の注文が入ると、在庫ズレが発生していました。
対策として以下を実装しました。
- Webhook型のリアルタイム連携を導入（基幹システムで在庫変更 → 即座にShopifyに反映）
- エラーハンドリングを整備（失敗時は自動再試行 → 2回失敗で管理者通知）
- セール期間中は5分ごとのバッチ同期も追加
- 毎日1回、在庫数の検証ロジックを自動実行
実装後、セール期間中の欠品クレームは0件に削減されました。同時に、基幹システムとShopifyの在庫ズレは月平均0.2件に減少（従来は月平均8件）。
重要なのは、これらの対応は「高額なシステム導入」ではなく、既存システムのAPI設計を適切に実装しただけだということです。
API設計で判断すべき在庫管理システムの選定基準
新たに在庫管理システムを選定する際、以下の3つの基準でAPI設計力を判断できます。
基準1：リアルタイム連携をサポートしているか
Webhook型またはイベントストリーム型のリアルタイム連携をサポートしているか確認します。単なる「API連携」ではなく、「リアルタイム」性を備えているかが重要です。
質問例：「在庫が変更されてから、ECプラットフォームに反映されるまでの平均時間は何秒か」
基準2：エラーハンドリングと再試行ロジックが自動化されているか
同期エラーが発生したとき、自動的に再試行され、失敗時には管理者に通知される仕組みが備わっているか確認します。
質問例：「連携に失敗したとき、何回まで自動再試行するのか。何分間隔で再試行するのか」
基準3：データマッピングのカスタマイズと検証がサポートされているか
異なるシステムのデータ形式の変換（マッピング）が柔軟にカスタマイズでき、定期的に検証できるか確認します。
質問例：「マッピングエラーが発生したとき、管理画面から修正できるのか。修正履歴は保存されるのか」
在庫ズレを防ぐための運用設計
連携監視ダッシュボードの設計
API設計が正常に機能しているか確認するには、リアルタイムな監視ダッシュボードが必要です。
ダッシュボードに含めるべき情報は以下の通りです。
- 前回の同期実行時刻と次回実行予定時刻
- 直近24時間のエラー件数
- 基幹システムとECプラットフォームの在庫数の差分（件数・SKU数）
- 修復が必要なマッピングエラーの一覧
Shopify管理画面で在庫確認していると、同時にこのダッシュボードも開き、「今この瞬間、連携は正常に動作しているのか」を確認する必要があります。
定期検証プロセスの設計
連携が正常に動作していても、蓄積されたズレを定期的に検証・修復する必要があります。
推奨されるプロセスは以下の通りです。
- 毎日：前日の同期ログを確認（エラーがないか）
- 毎週：基幹システムとECプラットフォームの全在庫数を照合（差分があるか）
- 毎月：マッピングテーブルを検証（新規商品の追加漏れがないか）
この検証を毎週手作業でやろうとすると、担当者の工数が膨らみ、やがて形骸化します。「自動化されたツールで数分で確認できる」という設計にすることが、継続運用の現実的な条件です。
よくある質問：API設計の基幹システム連携に関するよくある質問
Q1：基幹システムとECプラットフォームの連携でリアルタイム性はどの程度必要ですか？
売上規模と商品の回転速度で判断します。月商1000万円以上、または販売イベントが頻繁な企業の場合、5分以内のリアルタイム連携が推奨されます。
判断基準は「オーバーセリングが起きるリスク」です。1時間に100件以上の注文が予想される場合、定期同期では対応できません。
Q2：既存のシステムでリアルタイム連携に対応できない場合は？
段階的な対応が可能です。まずは定期同期の頻度を上げる（1時間 → 15分 → 5分）。並行して、エラーハンドリングと自動修復メカニズムを導入します。
その後、余力があればWebhook型のリアルタイム連携を導入する、という順序で対応できます。
Q3：API設計のためにどの程度の予算が必要ですか？
既存システムの活用で対応できる場合、カスタマイズに50万〜150万円程度のコストで対応可能です。新たにシステムを導入する場合は、システム費用200万〜500万円が必要になることもあります。
判断基準は「現在発生している在庫ズレによる損失」です。月10件以上の欠品クレームが発生していれば、対応投資は十分に回収できます。
Q4：在庫ズレが発生したときの顧客対応はどうすべきですか？
重要なのは「発見→修正→報告」のスピードです。ズレを発見したら、即座にシステムを修正し、影響を受けた顧客に報告すべきです。
報告の内容は「この度はご迷惑をおかけしました。在庫確認いただき、別日のお届けまたはキャンセルのご選択をお願いしております」という形が標準的です。
Q5：API設計を依頼する際、どの企業に相談すべきですか？
基幹システムとECプラットフォーム双方に詳しい、「両方のシステムの連携経験」を持つ企業を選ぶべきです。単一のシステムに詳しいだけでは、マッピングやエラーハンドリングの設計が不完全になりやすいです。
相談時に確認すべき点は「過去の連携実装事例」「エラーハンドリングの詳細設計」「定期検証ツールの有無」です。
在庫ズレを防ぐための最後の判断基準
以下の3つに当てはまる企業は、API設計の見直し優先度が高いです。
- 月3件以上の在庫ズレによる欠品クレームが発生している
- セール期間中、在庫確認の手作業が増えている
- 基幹システムとECプラットフォームの連携仕様書が存在しない
1つでも当てはまれば、API設計の診断を依頼することをお勧めします。
つまり、基幹システムとECプラットフォームの連携で在庫ズレが起きる企業と起きない企業の差とは何か
基幹システムとECプラットフォームの連携で在庫ズレが起きるかどうかは、API設計の完成度によって決まります。単なる「連携している」という状態ではなく、リアルタイム性・エラーハンドリング・データマッピング・修復メカニズムが全て設計されているかどうかが、ズレの有無を分けるのです。
まとめ
基幹システムとECプラットフォームの在庫ズレは、API設計の不備による構造的な問題です。解決には、単なるシステム導入ではなく、同期方式・エラーハンドリング・データマッピング・修復メカニズムの5つの要素を整備する必要があります。
判断基準は「月3件以上の在庫ズレが発生しているか」です。発生していれば、API設計の見直しを優先すべきです。見直しによって、在庫ズレを月0〜1件に削減し、顧客クレームと機会損失を大幅に減らせます。
まず手元にある連携仕様書を開いてみてください。エラーハンドリングの記載があるか、修復メカニズムの定義があるかを確認するだけで、現状の危険度がわかります。仕様書がそもそも存在しない場合は、それ自体が見直しのサインです。 —
