EC と基幹システムの在庫連携で売り越しを防ぐ：正の置き場所と、連携が止まったときの決め方

EC の在庫を基幹システムや各モールとつなぐとき、最初に出てくる問いは「バッチ連携か、API 連携か」です。ところが、実際に売り越しや欠品の事故が起きたとき、原因は連携方式そのものより、その手前の設計にあることが少なくありません。在庫の正をどこに置くのか、引当をどちらで持つのか、連携が止まったときに何を守るのか。これらが決まっていないと、方式を変えても同じ事故が起きます。

この記事では、EC と基幹システムの在庫連携を発注前に整理するための論点を、3 つに絞って解説します。

2026 年 10 月の障害が示したこと

ネットショップ担当者フォーラムの報道（2026 年 10 月 8 日）によると、IDC フロンティアは 2026 年 10 月 7 日午前 3 時 40 分頃に障害が発生し、原因は第三者によるランサムウェア攻撃だったと発表しました。二次被害を防ぐため、IDCF クラウドの東日本リージョン 1 をネットワークから遮断して停止し、影響は IDCF クラウドを契約する 495 の企業・自治体に及んでいます。

この影響で、グリニッジが提供する「らくらく在庫」「らくらく最安更新」「ウルトラASP（一部）」が停止し、対象サービスを使う全店舗で在庫連携や価格更新などの処理が止まりました。利用事業者には、必要に応じて各 EC モールの管理画面から在庫数や価格を直接確認するよう呼びかけられています。記事の時点では復旧の見通しは示されておらず、グリニッジが管理する顧客情報の流出は 10 月 7 日時点で確認されていません。

ここで押さえたいのは、特定のサービスの良し悪しではありません。EC の在庫や価格の更新が、外部のクラウドや外部サービスの上で動いている場合、その先が止まると自社の店舗運営にも影響が及ぶ、という構造です。止まる可能性があることを前提に設計しているかどうかで、止まったときの被害は変わります（これは筆者の見方です）。

売り越しはなぜ起きるのか

在庫連携の失敗事例を解説している記事（a-x.inc）は、在庫のずれの原因を大きく 3 つに分けています。手作業の入力ミスや更新忘れなどのヒューマンエラー、定時にまとめて更新する方式で更新の合間の販売が反映されないシステムのタイムラグ、そして自社 EC・モール・実店舗が独立して動き、一元管理の仕組みがないチャネルの複雑化です。

同記事は、定時更新のバッチ連携は低コストで導入しやすい一方、更新間隔によるタイムラグは避けられないこと、API 連携は販売などのイベントごとに即時通知でき、ずれを最小限にできる一方で費用が高くなる傾向があり、専門知識が必要な場合もあることを整理しています。対策としては、在庫の基準（マスター）を決めることを挙げ、小規模なら既存の基幹システムや EC を正とする方法、チャネルが多い場合は WMS などの在庫管理システムをハブにする方法が向いているとしています。

ここまでは多くの解説記事が触れているところです。ただ、「基準を決める」と書かれていても、実際に何をどこで決めるのかは案件ごとに違います。以下では、発注前に決めておきたい論点を具体的にします。

論点 1：在庫の「正」はどこにあるか

まず決めるのは、在庫数の正をどのシステムが持つかです。ここで言う正とは、数字が食い違ったときに「こちらが正しい」と扱う側のことです。

• 基幹システムを正とする：倉庫や仕入れの実態に近く、棚卸しの結果もそこに集まる場合に向いています。EC は基幹の在庫を参照して表示する側になります。
• EC 側を正とする：EC が主な販売チャネルで、基幹は後から受注を取り込む形の場合です。EC の注文が増えるほど、基幹への反映の遅れが問題になります。
• 在庫管理システムをハブにする：チャネルが多く、どれか 1 つを正にすると他が追いつかない場合です。

決めるときのポイントは、「棚卸しや返品処理の結果が最初に入る場所はどこか」を起点にすることです。入力が最初に起きる場所と正が別の場所にあると、そこに必ず同期の遅れが生まれます。また、正が 2 か所ある状態、つまり双方向に上書きし合う状態は、ずれの原因を追えなくなるため避けたい形です。

論点 2：引当（在庫の取り置き）をどちらで持つか

次に、注文が入った時点で在庫を確保する「引当」を、EC と基幹のどちらで行うかを決めます。

EC 側で引当をすると、注文の瞬間に購入可能数が減るため、売り越しを防ぎやすくなります。ただし、基幹に引当結果を渡す処理が必要になり、その連携が遅れると基幹側の数字と一時的にずれます。基幹側で引当をすると、実在庫との整合は取りやすい反面、EC の画面に表示する在庫数が基幹の更新を待つ形になり、更新の合間に売り越す余地が残ります（バッチ連携ではこの余地が大きくなります）。

実務では、次の組み合わせで考えることが多くなります（筆者の整理であり、一般論です）。

• 在庫が潤沢で、売り越しの影響が小さい商品：基幹で引当し、EC は定期的に更新する。
• 数に限りがある商品や、セールで注文が集中する商品：EC で先に引当し、基幹へ確定情報を渡す。
• キャンセルや返品が多い商品：引当を解除するタイミングと、在庫に戻すタイミング（検品後かどうか）を別に定義する。

どの組み合わせにするかは、商品の性質と、売り越したときの対応コスト（お詫び、代替品、キャンセル処理）で決まります。方式の比較に入る前に、この表を作っておくと、見積もりの前提がそろいます。

論点 3：連携が止まったとき、何を守るか

3 つ目が、冒頭の障害に直接つながる論点です。連携は止まる前提で、止まったときの振る舞いを決めておきます。

• 表示在庫を安全側に倒すか：最後に更新された在庫数のまま販売を続けるのか、一定時間更新がなければ「在庫わずか」や「購入不可」に切り替えるのか。前者は売り損じが少なく、後者は売り越しが少なくなります。
• どこまで自動で止めるか：連携の失敗を検知して、販売を止めるのか、アラートだけにするのか。夜間や休日に誰が気づくのかも含めて決めます。
• 復旧後にどう整合を取るか：止まっていた間の注文と在庫変動を、どの順番で反映し直すのか。同じ注文を二重に取り込まない仕組み（再実行しても結果が変わらない作り）が必要です。
• 手動で運用する手順があるか：今回の報道でも、利用事業者は各モールの管理画面で在庫数と価格を直接確認するよう呼びかけられました。手動に切り替える手順を、平時のうちに文書にしておくと、止まったときの判断が早くなります。

こうした「止まったときの設計」は、機能一覧には載りにくい項目です。要件定義の段階で話題にしないと、完成後に追加するのは費用も手間もかかります。

発注前のチェックリスト

EC の開発や在庫連携の見直しを外部に依頼する前に、次を整理しておくと、見積もりや設計の議論が進みやすくなります。

1. 在庫数の正はどのシステムか。棚卸しと返品の結果はどこに最初に入るか。
2. 引当は EC と基幹のどちらで行うか。商品の種類で分けるか。
3. 在庫の更新間隔はどれくらいまで許容できるか。売り越したときの対応コストはいくらか。
4. 外部サービスやクラウドが止まったとき、表示と販売をどうするか。
5. 復旧後の再取り込みで、二重計上を防ぐ仕組みは何か。
6. 手動運用に切り替える手順と、気づく人は決まっているか。

すべてに完璧な答えを用意する必要はありません。答えが決まっていない項目を把握しておくこと自体が、設計の出発点になります。

まとめ

EC と基幹システムの在庫連携は、バッチか API かの二択ではなく、在庫の正、引当の置き場所、連携が止まったときの振る舞いという 3 つの設計判断の組み合わせで決まります。外部サービスの障害が報じられた今は、自社の在庫連携がどこに依存していて、止まったら何が起きるのかを、見直す良い機会です。

私たちは、基幹システムとの在庫連携が前提となる EC など、既存の EC サービスでは実現しにくい仕組みを持つ EC を要件定義から設計・開発する「ECサイト構築」を提供しています。在庫連携の設計でお悩みの場合は、お気軽にご相談ください。