実店舗連動ECの設計｜在庫・POS連携のチェックリスト

公開日：2025.10.10

「ECと店舗の在庫が合わない」「店頭受け取りで現場が混乱」——多くは在庫の一元管理とイベント設計（予約・引当・取り置き）の不足が原因です。商品IDの突合・ロケーション管理・引当タイミング・店舗オペを先に決めれば、BOPIS（店頭受け取り）や在庫可視化は安定します。本稿は設計原則 → 実装パターン → チェックリストで、迷いどころを具体化します。

まず決めるべきこと：在庫の持ち方と引当のルール

はじめに在庫の“見え方”と“減り方”を定義します。単一在庫プールでロケーション別に配分するか、店舗ごとに完全分離するか、あるいはOMSでハブ化するか。引当タイミングは注文時／決済時／店舗確保完了時のどれかを選びます。店頭受け取り（BOPIS）は店舗での準備 → 受け渡し → 完了処理までが一連の体験。ここを設計書に落とし込むと現場の迷いが激減します。

実装パターンの比較（在庫の持ち方）

パターン	概要	向き／強み	注意点
A：単一在庫プール＋ロケーション別数量	1商品に複数ロケーション数量を保持	EC／店舗の一体運用が容易	ロケーションID管理が必須（API・権限
B：店舗別在庫の完全分離	店舗=在庫の最小単位	店舗裁量が大きい	跨店の引当/移動に運用負荷
C：OMS中継（在庫ハブ）	OMSが注文振り分け／引当	ルール柔軟・拡張に強い	初期コスト／設計が増える

引当（予約）設計のポイント

いつ在庫を減らすか（注文時／決済時／店舗確保時）を明確化
安全在庫（バッファ）と引当有効期限（〇分）を設定
取り置き失効 → 自動在庫戻し／通知フローを用意

BOPIS運用は「準備 → 通知 → 受け取り → 完了」の明確化が肝です。

データ設計：IDの突合とロケーション・SKU管理

EC×POS連携の失敗はIDの不一致から生まれます。まずSKU（社内ID）を主軸に、GTIN/JANなどの標準コードを紐づけ、バリエーション（色／サイズ）を持てるスキーマに。ロケーションは店舗・倉庫・EC倉庫を一意に識別し、棚卸や移動在庫も数量として扱える設計が安定します。Googleのローカル在庫広告を視野に入れる場合は、商品・在庫のローカルフィードも想定しましょう。

突合テーブルの基本（例）

product_id（社内） / sku / variant_id
gtin_jan（GTIN-13） / brand / category
location_id（店舗/倉庫） / qty_on_hand / qty_reserved
updated_at（POS側/EC側） / source_system

GTIN（JAN／EAN／UPC等）はGS1標準。店舗・倉庫での管理や外部配信（LIAなど）の基礎になります。

BOPIS／店舗受け取りの設計：フローと通知

BOPISは注文 → 引当 → 準備 → 通知 → 受け渡し → 完了のオペレーションが要です。EC側は受け取り場所の選択と引当ロジック、店舗側は準備リストと通知、引き渡し時は本人確認／検品／在庫確定をUIで支援。Shopify POSなどは店頭受け取りのステータス管理と通知が標準化されています。

必須UI／運用

店舗準備リスト：優先度（受取期限/在庫確保状況）で並び替え
通知：準備完了・期限切れ・キャンセルの自動通知
受け渡し：本人確認（注文番号/バーコード） → 完了処理で在庫確定

KPI例

準備リードタイム（注文 → 準備完了）
受取完了率／期限切れ率
受取時の追加購買率（BOPISは追加購買が起きやすい傾向）

連携方式の選択：API／バッチ／ミドルの使い分け

リアルタイム性と安定性はトレードオフです。API連携は鮮度に強い一方、リトライ／制限設計が必須。バッチ連携は堅実だが鮮度が落ちます。ミドル（OMS／在庫ハブ）はルールの柔軟性と監査性を確保しやすい反面、初期設計が増えます。POSはスマレジ等で在庫・受注系APIが公開されており、要件別に選び分けます

比較表（方式別）

方式	強み	弱み	こんな時に
API（双方向）	鮮度◎／イベント駆動	失敗時の再送／冪等性が必須	BOPISや店舗在庫表示をほぼ実時間で出したい
バッチ（CSV／Feed）	安定／監査しやすい	鮮度△	1日数回の在庫反映で十分
ミドル（OMS）	ルール柔軟／監視◎	初期工数	複数倉庫・複数チャネルを最適配分したい

セキュリティと決済の前提（要点だけ）

店舗×ECの連携ではカード情報の取り扱いを極力避ける設計が基本。トークン/外部決済でPCI DSSのスコープを縮小します。POSやEC間の通信はAPIキー/署名・IP制限で守り、ログ監査を残すこと。

最低限の実務

カード情報は保存しない（トークン化/代行）
管理画面・APIは二段階認証／IP制限
監査ログ（誰が／いつ／何を）を保存

実装チェックリスト（保存版｜在庫・POS連携）

要件定義〜公開前に“欠けやすい”ポイントを横断で点検できます。在庫の見せ方・減らし方・戻し方と、BOPIS運用、連携の堅牢性を一括で確認。現場配布用にExcel版へも展開可能です。

要件・データ

SKU ⇔ GTIN／JANの突合表を作成・共有（棚卸／外部配信も想定）
location_id（店舗／倉庫）を一意管理／ロケーション在庫API方針を決定
予約在庫（qty_reserved）と安全在庫の閾値を設定

在庫の減り方／戻し方

引当タイミング（注文／決済／準備完了）を合意
取り置き失効 → 自動戻し／通知のシナリオ化
返品・キャンセルの在庫戻しと期限を定義

BOPIS運用

店舗準備リスト → 準備完了通知 → 受け渡し → 完了処理の一連フローをUI化
本人確認（注文番号／バーコード）と在庫確定の手順書
KPI：準備LT／受取完了率／期限切れ率／追加購買率

連携・監視

API：リトライ／冪等性／レート制御／バッチ：再実行／差分
障害時の降格運転（在庫表示を“お取り寄せ”へ等）
監査ログと通知（在庫ズレ閾値）の設定

事例に学ぶ：小売の“店頭受け取り”が効く理由

BOPISは受取来店時の追加購買と配送コスト削減が同時に狙える施策。統計でも、受取時に追加購入が生まれやすいと報告されています。まずは受取体験の摩擦（待ち時間・導線・確認）を下げ、受取場所のPOPや関連導線を設計すると、売上の底上げが期待できます。

よくある質問（FAQ）

Q1：在庫は注文時と決済時のどちらで引き当てるべき？

A. 迷ったら注文時に仮押さえ → 期限切れで戻すが無難です。決済前に在庫が消える事故を抑えられます。BOPISでは店舗確保完了で本確定にする運用も多いです。

Q2：店頭受け取りで一番揉めるのは？

A. 準備完了・期限切れの通知不足と、受け渡し時の本人確認ミスです。POS／ECの通知機能を必ず使い、完了処理で在庫を確定させましょう。

Q3：まず小さく始めたい。API連携は必須？

A. 需要次第ですが、バッチ（1日数回）から開始 → 要件固まり次第APIが現実的です。スマレジ等はAPIが整っているので、将来拡張を考えている方にはおすすめです。

Q4：商品コードはJANだけでいい？

A. SKU（社内ID）＋GTIN／JANの二段構えが安全です。棚卸・外部配信・連携時の照合精度が上がります。

Q5：店舗在庫を広告にも活かせる？

A. Googleローカル在庫広告（LIA）で店舗別在庫を露出できます。Merchant CenterとBusiness Profileの連携が前提です。

まとめ

在庫が“どこで・どう減って・いつ戻るか”を先に決め、ID突合・ロケーション管理・BOPIS運用を設計書に落とし込めば、店舗連動ECは安定します。最初はシンプルに始め、通知・監視・ロールバックを備え、LIAなど集客との接続まで見据えると効果が長持ちします。
大阪でECサイト制作をご検討の方は、ぜひ一度ご相談ください。
無料相談はこちらから
関連サービス：ECサイト制作