実店舗連動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サイト制作

この記事を書いた人

digrart編集部

大阪市中央区のweb制作会社のメンバーが、Webサイト制作、ECサイト構築、SEO対策、Webコンサルティングの最新情報や実践的なハウツーをお届けします。初心者からプロまで役立つノウハウや業界トレンドを分かりやすく解説。web戦略の成功をサポートするための情報が満載です！