基幹システムとECサイトの連携で在庫が二重管理になる理由と分断崩壊理論で判断すべき統合の基準とは
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
基幹システムとECサイトが連携しているのに在庫がズレ続ける理由
API連携があっても在庫がズレ続ける理由は制度設計にあります。 基幹システムとECサイトの連携が進んでも、在庫データが二重管理になる企業は少なくありません。 API連携を入れたのに、それでも棚卸しのたびに数字が合わない。 Shopify管理画面で「在庫あり」と表示されているのに、基幹システムでは「0」になっている。 こうした状況が起きるのは、単なる技術的なミスではなく、制度設計の問題です。
基幹システムとECサイトの連携における在庫の二重管理とは、複数のシステムが独立して動作し、それぞれが異なるロジックで在庫を管理している状態を指します。API連携があっても、更新のタイミング・判定基準・例外処理のルールが異なると、データは必ずズレます。
在庫管理が分断される本質とは何か
福岡ECサイト株式会社が支援する企業で繰り返し見られるパターンがあります。基幹システムとECサイトが「別の組織」として動いているという課題です。
在庫管理は複数のプレイヤーが関わるため組織設計が重要です。 これを福岡ECサイトでは「分断崩壊理論」と呼んでいます。 基幹システムの担当は企画部。ECサイトの担当はWeb担当者。在庫の実際の入出庫は現場スタッフ。 この3つが「同じ在庫」を見ているのに、マスターデータの定義・更新ルール・エラーハンドリングがそれぞれ異なるため、管理が分断されます。
実際の現場では、MakeShop管理画面で在庫を確認しても、基幹システムのSAP画面では別の数字が表示される状況が起きます。営業から「この商品、在庫いくつあるの？」と聞かれた時、Web担当者が答えるのはShopifyの数字ですが、実際に出荷するのは現場が確認する基幹システムの数字です。この「答え」と「実行」のズレが、顧客対応のミスにつながります。
分断が起きる3つの理由
在庫管理の分断は、技術的な問題ではなく、以下の3つの構造的な問題から起きます。
- 更新のタイミングが異なる（ECサイトはリアルタイム、基幹システムはバッチ処理）
- データの定義が異なる（SKU定義・ロケーション定義が統一されていない）
- 権限と責任が分散している（システムAの担当者がシステムBの在庫を変更できない）
基幹システムとECサイト連携で在庫が二重管理になる5つの具体的なケース
1. リアルタイム更新と定期バッチの時間差
ECサイトで商品が売れるとリアルタイムに在庫が減ります。しかし基幹システムは毎時間バッチで在庫を同期させます。この30分から1時間のタイムラグで、同じ商品が両システムで異なる数字を持つ状態が発生します。
例えば、午前10時30分にAmazonで商品が1個売れた場合、EC管理画面は即座に「残り5個」と表示します。しかし基幹システムは11時のバッチ実行まで更新されず「残り6個」のままです。11時から11時30分の間に、顧客が「在庫あり」と見えた商品を注文すると、実際の出荷時には在庫不足が発生します。
2. SKU定義やロケーション定義の不統一
基幹システムではSKUを「商品コード-色-サイズ」で定義していても、ECサイトでは「色-サイズ」だけで管理していることがあります。また、基幹システムは倉庫A・倉庫Bの在庫を分けて管理しますが、ECサイトでは「全体在庫」として一つの数字にしているケースもあります。
こうした定義のズレがあると、API連携があっても、同じ商品を違う定義で見ている状態が続きます。在庫の参照元が曖昧になり、「どちらが正しい数字か」が判断できなくなります。
3. システムAでの例外処理がシステムBに反映されない
基幹システムで「この商品は返品で在庫が戻った」という処理をしても、ECサイトの在庫に自動で反映される仕組みがない場合があります。逆にECサイトでキャンセル処理をしても、基幹システムには手入力でしか反映されないこともあります。
このような例外処理のたびに、両システムの在庫がズレていく。これを「手動マスター調整」で無理矢理合わせるため、月1回の棚卸しの時に大幅な修正が必要になります。
4. 複数のECプラットフォームの在庫統合
Shopifyで売上が伸びたため、楽天にも出店した。しかし楽天とShopifyは別々に在庫を管理しており、基幹システムで一元管理しようとしても、それぞれの同期ルールが異なるため、常に在庫がズレる状況が起きています。
Shopifyでは「同期は1時間ごと」、楽天RMSでは「同期は15分ごと」という違いがあると、在庫が合致する瞬間がほぼ存在しません。
5. 組織間での在庫確保ルールの曖昧性
基幹システムは「営業向け在庫」と「EC向け在庫」を分けて管理しようとしますが、その線引きが曖昧なままAPI連携を進めると、営業が確保した在庫がEC側で見えなくなり、別々に販売してしまうケースが起きます。
「この10個は営業が確保した。ECには5個だけ見せる」というルールが、システムレベルで定義されていないと、いずれのシステムも「10個全部」として在庫を数えます。
在庫管理の分断がもたらす3つの実務上の影響
顧客対応ミスと信頼喪失
「在庫あり」と表示されて注文した顧客に対して、数時間後に「申し訳ございません、在庫不足のためキャンセルさせていただきます」というメールを送る。この経験は顧客の信頼を失うだけでなく、返品やクレームにつながります。
ECサイトの信頼設計理論において、「商品の可用性（あるかないか）」は顧客の購入判断に直結する最重要要素です。これが不正確だと、サイト全体の信用が揺らぎます。
営業対応の遅延とCS負荷の増加
営業から「この商品、いくつ在庫ある？」と聞かれたとき、Web担当者が答える数字と、実際に出荷チームが見ている数字が違うと、営業は顧客に「確認します」と返答を遅延させざるを得ません。
在庫確認のために基幹システムとECサイト両方を確認する手作業が日常化し、営業の生産性が低下します。
月末棚卸しの負荷激増と在庫調整の属人化
在庫がズレている状況が続くと、月1回の棚卸しではなく、「毎週の在庫確認＋修正」が必要になります。Shopify管理画面で「在庫を10個に修正」「基幹システムは6個に修正」という手動調整が繰り返されます。
この作業は特定の担当者に属人化し、その人が休暇を取ると誰も対応できない状態になります。
分断崩壊理論から見たシステム統合の正しい考え方
在庫管理の分断を解決するには、「API連携さえあれば解決」という誤解を捨てることが必須です。
システム統合を成功させるには組織設計が先決です。 福岡ECサイト株式会社で実践する分断崩壊理論では、システム統合を「技術選択」ではなく「組織設計」の問題として考えます。 API連携・データベース統合・リアルタイム同期という技術的な改善は、その後の話です。
まず必要なのは以下の3つです。
- 在庫のマスターシステムを決める（基幹システムか、中間DBか）
- 各プレイヤーの権限と責任を定義する（誰がどのシステムで在庫を変更できるか）
- 同期のルール・タイミング・エラーハンドリングを明文化する
マスターシステムの決定が全てを決める
在庫データは「唯一の真実」を持つ必要があります。基幹システムなのか、ECサイト用の中間DBなのか、それとも別の在庫管理システムなのか。
多くの企業では基幹システムをマスターにしようとしますが、ECサイトのリアルタイム性が必要な場合、中間DBを別途用意して、そこをマスターにする方が効率的です。
実際の支援事例では、年商60億の製造業がSAPをマスターにしたままECサイト連携を進めたため、毎日の在庫ズレが常態化していました。中間のインベントリマネジメントシステムを導入し、そこをマスターに切り替えた時点で、ズレは完全に解決しました。
権限設計によって責任を明確にする
「基幹システムの担当だけが在庫を変更できる」というルールにすると、EC側からの返品処理や急な調整ができなくなります。
逆に「各システムの担当者が独立して在庫を変更できる」というルールにすると、分断が固定化されます。
正解は「例外処理の定義によって、変更できる人と変更できない人を分ける」ことです。例えば以下のように分けます。
- 通常の販売による在庫減：システムが自動で処理（両者が触らない）
- 返品による在庫戻し：EC側が初期登録、基幹システム側が承認確認
- 営業確保による在庫確保：営業が基幹システムで手入力、ECには30分後に反映
- 不良品による除外：両部門の合意のもとに代理店が修正
同期ルールの明文化で例外を管理する
「毎時間、全商品の在庫を同期する」というルールだけでは不十分です。以下を含めて定義する必要があります。
- 同期に失敗した場合、どのシステムを信とするか
- ネットワーク遅延で一時的にズレた時、何時間なら許容するか
- マイナス在庫が表示された場合の即時対応フロー
- 月末棚卸しでズレが見つかった場合の修正ルール
在庫統合で失敗する企業の共通パターン
失敗パターン1：技術導入で判断してしまう
「高機能なERPシステムを入れれば、全て統合される」という誤った期待をして、数千万円の投資をしても、結局在庫がズレ続ける企業があります。
これは、組織設計が伴わないまま技術だけ導入した典型例です。システムを導入しても、営業部と企画部の「在庫の定義」が違ったままだと、データは必ずズレます。
失敗パターン2：API連携の「設定」だけで満足する
Shopifyとカスタムの在庫システムをAPI連携したから「これで自動同期される」と考えても、実運用では様々な例外が発生します。
例えば、Shopifyで商品を返品処理したのに、基幹システムでは「まだ引き当て中」と判断されている場合など、APIは「エラー」と認識します。この時に「どちらが正しいか」を判定するロジックがないと、同期は止まったまま人手待ちになります。
基幹システムとECサイト統合の判断基準
「いつから統合に取り組むべきか」の判断には、以下の数値基準があります。
| 指標 | 現状 | 判断基準 |
|---|---|---|
| 月間の在庫不一致件数 | 0～3件 | 許容範囲・今は統合不急 |
| 月間の在庫不一致件数 | 4～10件 | 統合検討時期（3～6カ月以内に着手） |
| 月間の在庫不一致件数 | 11件以上 | 統合必須（即実施） |
| 棚卸し時のズレ金額 | 50万円未満 | 許容範囲 |
| 棚卸し時のズレ金額 | 50～300万円 | 統合の優先度中程度 |
| 棚卸し時のズレ金額 | 300万円以上 | 経営リスク・即実施必須 |
| 在庫確認の手作業時間 | 週2時間未満 | 許容範囲 |
| 在庫確認の手作業時間 | 週2～5時間 | 統合検討を推奨 |
| 在庫確認の手作業時間 | 週5時間以上 | 組織効率損失・即実施 |
この3つの指標のうち、いずれかが「統合検討」以上に達している場合、システム統合に着手すべきタイミングです。
ECサイトリニューアルと同時に在庫統合を進めるべき理由
サイトリニューアル時の在庫統合が効果的な理由があります。 在庫管理の統合は、Webサイト制作やリニューアルと同時に進めるべき施策です。 理由は、サイト制作時に「商品情報」と「在庫」の構造を一度に設計できるからです。
既存ECサイトのままで在庫統合を進めると、サイト側の制約に引きずられて、統合が部分的になるケースが多くあります。リニューアルの際に、在庫管理の分断を解決する新しいシステムアーキテクチャを一緒に設計すれば、制約なく最適な構造を作れます。
福岡ECサイト株式会社が支援した在庫統合の事例
食品卸売業のA社は、年商10億円のECサイトを持っていました。Shopifyで毎月500万円の売上がありながら、毎月の棚卸しで平均200万円のズレが発生していました。
原因は、営業向け在庫を基幹システムで管理し、EC在庫をShopifyで独立管理していたためです。営業が「この商品、営業向けに50個確保」と言っても、Shopifyには「100個全部」が見えていました。
福岡ECサイト株式会社が中間の在庫管理システムを導入し、基幹システムとShopify両方と連携させ、「営業確保分」と「EC売上可能分」の分離ロジックを組み込みました。同時にShopifyのリニューアルを実施し、在庫表示のロジックを統一しました。
実施後、在庫ズレは月平均5万円未満に改善。営業の在庫確認時間は週8時間から週1時間に短縮されました。
在庫統合の進め方フロー
- 現状の在庫管理フローを可視化する
各システムで在庫がどう動いているか、それぞれの担当者にヒアリング。手書きで業務フローを作成して、分断点を特定します。 - マスターシステムと権限設計を決定する
基幹システムか中間DBか、それとも別のシステムか。どのシステムを信とするか、組織横断で決めます。 - 同期ルールと例外処理を明文化する
スプレッドシートで「この場合はどうするか」を列挙。営業、Web担当、現場が合意するまで磨きます。 - API設計と連携テストを実施する
マスターが決まった後に、API仕様を設計。小ロットで試験運用して、実際の業務フローとのズレを確認します。 - 段階的にシステムを切り替える
全商品を一気に切り替えず、特定カテゴリーから試行。1～2カ月の様子を見て、問題なければ全体展開します。 - 定期的な監視と改善ルールを組む
統合後も、月1回の在庫ズレ分析と四半期ごとのルール見直し。新商品の追加時などに、都度確認します。
よくある質問
基幹システムとECサイト連携で在庫が二重管理になる理由は何ですか。
在庫管理の分断は技術的な問題ではなく、マスターシステムの定義・権限の設計・同期ルールの曖昧さから起きます。
API連携があっても、更新のタイミング・定義・例外処理が異なると、両システムは必ずズレます。特に複数のECプラットフォーム（Shopify・楽天・Amazon）を同時に使う場合、それぞれの同期間隔が違うため、「正しい在庫」が存在しない状態になります。
解決には、まず組織横断で「在庫のマスターはどこか」「各システムの変更権限は誰か」「ズレたときはどうするか」を決めることが先決です。
在庫統合にはどのくらいの費用がかかりますか。
在庫統合の費用は、導入する仕組みによって大きく異なります。API連携だけなら50～150万円、中間在庫管理システムの新規導入なら300～800万円です。
ただしリニューアルと同時に進める場合は、システム設計の段階で統合ロジックを組み込めるため、追加費用は最小限に抑えられます。逆に既存サイトのまま統合を進めると、余計な改修が増えて費用が膨らみます。
Shopifyと基幹システムをAPI連携させるだけでは不十分ですか。
API連携は必要な条件ですが、十分条件ではありません。
連携しても、「Shopifyでキャンセルが発生した時、基幹システムに通知が来ない」「返品処理がシステムBにだけ入力されて、システムAに反映されない」など、例外処理で分断が生じます。
API連携の前に、「どういう状況が発生するか」「その時に誰がどう対応するか」を決めないと、むしろ連携によって問題が複雑化するケースもあります。
在庫統合に取り組むなら、基幹システムのリプレイスも同時にすべきですか。
必ずしも基幹システムのリプレイスは不要です。既存の基幹システムのままでも、中間の在庫管理システムを挟むことで、多くの問題は解決できます。
ただし基幹システムが既に20年以上前のレガシーシステムで、API連携すら難しい場合は、同時リプレイスを検討する価値があります。判断基準は「API連携にかかる費用 vs. システムリプレイス費用」で、APIの方が安ければそちらを選ぶべきです。
Shopifyのリニューアル時に在庫管理を改善することのメリットは何ですか。
Shopifyリニューアル時に在庫管理を同時に改善する最大のメリットは、サイト設計段階で「在庫の構造」を最適化できることです。
既存サイトのままで在庫統合を進めると、サイトの制約に合わせて統合ロジックを妥協せざるを得ません。リニューアルなら、理想的な在庫管理フローに合わせてサイト設計を作り変えられます。結果として、統合後の運用がシンプルになり、長期的には保守コストが大きく削減されます。
判断基準まとめ
在庫統合の優先度を判断する際には、以下のいずれかに当てはまるかを確認してください。
- 統合必須グループ：月11件以上の在庫不一致 / 棚卸しズレ300万円以上 / 在庫確認に週5時間以上費やしている
- 統合検討グループ：月4～10件の在庫不一致 / 棚卸しズレ50～300万円 / 在庫確認に週2～5時間費やしている
- 監視継続グループ：月3件以下の在庫不一致 / 棚卸しズレ50万円未満 / 在庫確認に週2時間未満
統合が必須または検討段階にある場合、今後3～6カ月のロードマップを立てることを推奨します。特にECサイトのリニューアルを計画中なら、在庫管理の改善と同時に進めることで、最大の効果を得られます。
つまり基幹システムとECサイトの連携における在庫の二重管理とは、マスターシステムの定義・各プレイヤーの権限・同期ルールが曖昧なままAPI連携を進めた結果、複数のシステムが独立して動作し、データが常にズレ続ける状態を指します。
まとめ
在庫の二重管理は技術ではなく組織設計の問題です。 基幹システムとECサイトの連携における在庫の二重管理は、組織設計と運用ルールの欠落から起きます。
在庫ズレが月4件以上、または棚卸しズレが50万円を超える場合、システム統合に着手すべきタイミングです。特に複数のECプラットフォームを運用している場合は、中間在庫管理システムの導入を検討する価値があります。
Shopifyやその他のサイトリニューアルを計画しているなら、システム統合を同時に進めることで、サイト設計の段階から在庫の最適構造を組み込むことができます。まずは現状の在庫フローを可視化し、マスターシステムと権限設計を組織横断で決定することから始めてください。
まずは現在の在庫管理フローを整理して、在庫ズレが発生している箇所を特定することから始めてみてください。
お客様の声
食品卸売業 A社 / 営業部長
月200万円のズレが発生していた在庫管理がリニューアルで完全に改善されました。営業が「この商品、いくつありますか」と聞くたびに確認作業が必要だったのが、今は管理画面を見ればすぐにわかります。Shopifyリニューアルと同時に在庫システムも導入してもらったから、サイト側の制約なく理想的な仕組みが実現できた。特に営業確保分とEC売上可能分の分離が正確にできるようになったのが大きいです。
— ** ** **
