CONTENT
ここから
第27章では、クーポン・割引・キャンペーンについて学びました。
クーポンは、安く売るためではなく、購入のきっかけを作るために使うものでした。
この章では、ECだけでなく、実店舗・催事・ポップアップ販売にも対応する設計を考えます。
小規模事業者では、販売場所が1つとは限りません。
ECサイト
実店舗
百貨店催事
マルシェ
イベント会場
ポップアップストア
SNS販売
売り場が増えると、売れるチャンスも増えます。
しかし同時に、在庫、受取場所、決済、販売期間、管理方法が複雑になります。
ECでは在庫あり
でも催事では売り切れ
催事用に確保した商品を
ECで売ってしまった
オンライン決済済みなのに
現地でまた支払いを受けてしまった
この章では、複数の売り場を無理なく運用するための考え方を整理します。
攻略本風に言えば、第28章は**「売り場が増えても混乱しないためのマップ管理ステージ」**です。
28.1 実店舗とECの在庫をどう分けるか
多店舗・催事対応で最初に考えるべきことは、在庫の分け方です。
ECと実店舗で同じ商品を売る場合、在庫をどう管理するかを決める必要があります。
一番シンプルなのは、販売場所ごとに在庫を分ける方法です。
総在庫：100個
EC用：40個
実店舗用：40個
催事用：20個
この方法なら、ECで売る分と実店舗で売る分が混ざりにくくなります。
ECで販売できる数：
EC用在庫だけ
実店舗で販売できる数：
実店舗用在庫だけ
催事で販売できる数：
催事用在庫だけ
在庫を分けない場合、次のようなトラブルが起きやすくなります。
ECで注文が入った
↓
でも実店舗で同じ商品が売れていた
↓
在庫が足りない
↓
発送できない
Squareには、商品カタログや在庫を扱うAPIが用意されています。Catalog APIは商品ライブラリを管理するAPIで、Inventory APIはSquare sellerのCatalog itemの在庫数量や在庫変動を管理できます。(
)また、SquareのInventory APIでは、CatalogObjectの在庫数をLocationごとに取得できます。つまり、店舗や拠点ごとの在庫を扱う考え方と相性があります。(
)
ただし、小規模ECでは、最初からすべてを完全リアルタイム連携しようとしなくても構いません。
最初は、自前DBで販売チャネルごとの在庫を分けるだけでも十分です。
product_stocks
product_id
channel
location_name
stock
チャネルの例です。
ec
store
event
popup
TypeScriptで考えると、次のようになります。
type SalesChannel = 'ec' | 'store' | 'event' | 'popup';
type ProductStock = {
productId: string;
channel: SalesChannel;
locationName: string;
stock: number;
};
/**
* 役割: 指定した販売チャネルの商品在庫を取得する
* 入力: 商品IDと販売チャネル
* 出力: そのチャネルで販売できる在庫数
*/
function getAvailableStock(
stocks: ProductStock[],
productId: string,
channel: SalesChannel
): number {
const targetStock = stocks.find(
(stock) => stock.productId === productId && stock.channel === channel
);
return targetStock?.stock ?? 0;
}
在庫管理の基本は、次の一言です。
どこで売る在庫なのかを決めておく。
EC用、実店舗用、催事用。
この区別ができていれば、運用の混乱はかなり減ります。
28.2 催事用商品ページ
催事やポップアップ販売では、通常の商品ページとは別に、催事用の商品ページを作ると便利です。
催事用商品ページとは、特定のイベントや販売期間に合わせた商品ページです。
通常商品ページ：
いつでも販売する商品
催事用商品ページ：
特定の催事で販売する商品
催事用商品ページに必要な情報は、次の通りです。
・催事名
・開催場所
・開催期間
・受取日時
・販売商品
・数量限定の有無
・事前予約の可否
・現地決済かオンライン決済か
・受取場所の案内
ページ構成の例です。
笹加 夏の特別展 限定販売
開催期間：
2026年7月18日〜7月21日
受取場所：
〇〇百貨店 7階 催事会場
販売商品：
限定ギフトセット
催事限定詰め合わせ
[事前予約する]
催事用商品ページの役割は、購入者の不安を減らすことです。
どこで受け取るのか
いつ受け取れるのか
支払いはいつするのか
売り切れたらどうなるのか
催事では、通常配送とは違うルールになることがあります。
配送なし
現地受取のみ
予約者優先
数量限定
開催期間中だけ販売
そのため、通常商品ページと混ぜない方が分かりやすいです。
通常EC商品：
配送前提
催事商品：
現地受取前提
催事用ページでは、CTAも変えます。
通常商品：
[購入する]
催事商品：
[催事受取で予約する]
[現地受取を申し込む]
催事用商品ページは、売り場の案内板です。
購入者が会場で迷わないように、場所、日時、受取方法をはっきり書きます。
28.3 期間限定販売
催事やポップアップでは、販売期間が決まっていることが多いです。
期間限定販売では、開始日時と終了日時を必ず管理します。
販売開始：
2026年7月1日 10:00
販売終了：
2026年7月15日 23:59
期間限定販売では、次の3つの状態を考えます。
販売前
販売中
販売終了
それぞれの表示を分けます。
販売前：
販売開始までお待ちください
販売中：
購入・予約できます
販売終了：
販売は終了しました
システム側では、現在時刻を見て販売可否を判定します。
現在時刻
↓
販売開始日時より前か
↓
販売終了日時より後か
↓
販売できるか判定
TypeScriptの例です。
type LimitedSalePeriod = {
startsAt: string;
endsAt: string;
};
/**
* 役割: 現在時刻が販売期間内か判定する
* 入力: 販売期間と現在時刻
* 出力: 販売中ならtrue
*/
function isSaleActive(
period: LimitedSalePeriod,
currentDate: Date
): boolean {
const startsAt = new Date(period.startsAt);
const endsAt = new Date(period.endsAt);
return currentDate >= startsAt && currentDate <= endsAt;
}
期間限定販売で避けたいのは、画面表示と購入可否がズレることです。
画面：
販売中
実際：
購入できない
または
画面：
販売終了
実際：
購入できてしまう
表示だけでなく、サーバー側でも販売期間を確認します。
画面：
販売期間を表示
サーバー：
決済リンク作成前に販売期間を確認
期間限定販売では、販売終了後の表示も大切です。
販売終了しました。
たくさんのご注文をいただき、ありがとうございました。
次回販売のお知らせをご希望の方は、LINEにご登録ください。
販売終了後も、ページを活用して次回の導線につなげます。
28.4 受取場所の選択
多店舗・催事対応では、受取場所の選択が重要になります。
通常のECでは、商品は配送されます。
しかし、催事や実店舗では、購入者が現地で受け取ることがあります。
配送
店舗受取
催事受取
ポップアップ受取
受取場所の選択肢は、注文時に分かりやすく表示します。
受取方法を選択してください。
[配送]
[店舗で受け取る]
[催事会場で受け取る]
受取場所を選ぶと、必要な情報も変わります。
配送：
配送先住所が必要
店舗受取：
受取店舗が必要
催事受取：
催事名、会場、受取日が必要
注文データには、受取方法と受取場所を保存します。
type FulfillmentType = 'shipping' | 'store_pickup' | 'event_pickup';
type OrderFulfillment = {
type: FulfillmentType;
locationName: string | null;
pickupDate: string | null;
shippingAddressId: string | null;
};
受取場所の例です。
店舗受取：
金七商店 本店
催事受取：
名古屋高島屋 地下催事会場
ポップアップ受取：
〇〇マルシェ A-12ブース
SquareのOrders APIでは、注文の履行情報を
fulfillments
として持つことができます。Squareのドキュメントでは、pickup orderを作る場合、orderに
fulfillments
オブジェクトを追加する説明があります。(
)
ただし、自社ECで独自に催事受取を管理する場合、最初は自前DBに受取場所を保存する設計でも十分です。
最初：
自前DBで受取場所を管理
発展：
Square Order Fulfillmentとも連携
購入者へのメールにも、受取場所を必ず入れます。
ご注文ありがとうございます。
受取方法：
催事会場受取
受取場所：
〇〇百貨店 7階 催事会場
受取日時：
2026年7月18日 13:00〜17:00
受取場所は、注文後に店舗スタッフが確認する情報でもあります。
管理画面でも目立つように表示します。
28.5 店舗別在庫
店舗別在庫とは、店舗や会場ごとに在庫を分ける考え方です。
本店：20個
名古屋催事：15個
東京ポップアップ：10個
EC倉庫：30個
店舗別在庫が必要になるのは、次のような場合です。
・複数店舗がある
・催事会場に商品を持ち込む
・ポップアップ販売がある
・EC用と店頭用を分けたい
・店舗受取に対応したい
店舗別在庫のデータ設計です。
type LocationStock = {
productId: string;
locationId: string;
locationName: string;
stock: number;
reservedStock: number;
};
reservedStockは、予約済みで確保している在庫です。
実在庫：20個
予約済み：5個
販売可能：15個
販売可能在庫は、次のように考えます。
販売可能在庫
=
実在庫 - 予約済み在庫
店舗別在庫では、商品がどこにあるかを管理します。
商品A：
EC倉庫に30個
本店に10個
催事会場に5個
催事前には、EC在庫から催事用在庫へ移動することがあります。
EC倉庫：50個
↓
催事へ20個移動
EC倉庫：30個
催事：20個
この移動も、在庫履歴として残すと安心です。
2026-07-10
EC倉庫から名古屋催事へ20個移動
担当：山田
SquareのLocations APIでは、Square sellerのLocation情報を取得・更新できます。Inventory APIでは、在庫数や在庫変動をAPIで管理できるため、発展的にはSquareのLocationと自社DBの受取場所を紐づける設計も考えられます。(
)
ただし、最初から完全連携しようとすると複雑です。
小規模事業者では、まず次の形で十分です。
EC用在庫
店舗用在庫
催事用在庫
この3つを分ける
店舗別在庫は、売り場が増えたときの混乱を防ぐための基本です。
28.6 Square POSとの連携方針
実店舗や催事では、Square POSを使って現地決済することがあります。
Square POSは、店頭やイベント会場でカード決済や売上管理に使える便利な仕組みです。
ここで重要なのは、自社ECとSquare POSをどこまで連携するかです。
最初から完全連携を目指すと、設計が難しくなります。
EC
↔
Square POS
↔
在庫
↔
注文
↔
顧客
理想は、ECとPOSの在庫や注文が自動で同期することです。
しかし、小規模事業者の初期段階では、次のように分ける方が現実的です。
EC：
オンライン注文を管理
Square POS：
現地販売を管理
日次または週次で在庫を調整
SquareのOrders APIは、注文商品、合計計算、支払い確認、履行状況の追跡、カタログ在庫の更新などを扱えます。また、注文をSquare POSアプリへ送って履行することもできます。(
)
ただし、本書のような小規模ECでは、まず次の方針で十分です。
第1段階：
ECとPOSを分けて運用
第2段階：
商品マスターだけ揃える
第3段階：
在庫や注文をAPIで連携
第4段階：
POS側の履行管理まで連携
Square POSとの連携で決めることです。
・商品マスターをどちらで管理するか
・在庫をどちらで正とするか
・現地販売分をEC在庫に反映するか
・催事終了後に在庫を戻すか
・オンライン予約分をPOSでどう扱うか
最初に決めたいのは、在庫の正とする場所です。
自社DBを正にする
Squareを正にする
手動棚卸しを正にする
どれが正解というより、運用できる方法を選びます。
自動連携できないなら、
最初は手動で分ける。
無理に複雑な連携を作るより、実際に店舗スタッフが迷わず運用できることを優先します。
28.7 現地決済とオンライン決済
催事やポップアップ販売では、決済方法を2つに分けて考えます。
オンライン決済：
事前にWeb上で支払う
現地決済：
会場で支払う
オンライン決済の流れです。
ECで注文
↓
Squareでオンライン決済
↓
注文確定
↓
会場で受け取り
現地決済の流れです。
ECで予約
↓
会場で商品を受け取る
↓
Square POSで現地決済
それぞれのメリットです。
オンライン決済：
事前に売上が確定しやすい
無断キャンセルを減らしやすい
会場での会計がスムーズ
現地決済：
購入者の心理的ハードルが低い
会場で変更対応しやすい
その場で追加購入につなげやすい
それぞれの注意点です。
オンライン決済：
受取忘れやキャンセル対応が必要
現地決済：
無断キャンセルや在庫確保のリスクがある
注文ステータスも分けます。
オンライン決済済み：
paid
現地決済予定：
reserved
現地決済完了：
paid_at_event
現地決済予約では、在庫を確保するかどうかを決めます。
予約時に在庫確保する：
売り逃しは減るが、無断キャンセルリスクあり
現地決済時に在庫確保する：
在庫管理は楽だが、予約者分がなくなる可能性あり
おすすめは、催事の規模に応じて分けることです。
数量限定商品：
オンライン決済で事前確定
通常商品：
現地決済予約でもよい
購入者には、決済方法を明確に表示します。
この商品は、オンライン決済後に会場でお受け取りいただけます。
または
この商品は、会場でのお支払いとなります。
決済方法が曖昧だと、現場で混乱します。
28.8 予約販売
予約販売とは、商品をすぐに発送・受取できない状態で、先に注文や予約を受け付ける販売方法です。
販売前
↓
予約受付
↓
製造・準備
↓
発送または受取
予約販売が向いている場面です。
・新商品発売前
・季節商品
・催事受取商品
・数量限定商品
・製造数を事前に決めたい商品
・受注生産商品
予約販売で必ず表示する情報です。
・予約受付期間
・発送予定日
・受取予定日
・決済タイミング
・キャンセル可否
・数量上限
・販売終了条件
予約販売のステータス例です。
reserved：
予約受付済み
paid_reserved：
決済済み予約
preparing:
準備中
ready_for_pickup：
受取準備完了
shipped：
発送済み
cancelled：
キャンセル
予約販売では、通常購入と違い、注文から受取まで時間が空きます。
そのため、メール通知が大切です。
予約受付メール
準備開始メール
受取案内メール
発送完了メール
予約販売の注文フローです。
予約商品ページ
↓
予約申し込み
↓
決済または現地決済予定
↓
予約注文作成
↓
販売期間終了
↓
準備
↓
発送または受取
予約販売では、キャンセルルールを明確にします。
予約後のキャンセルは、〇月〇日まで承ります。
それ以降は準備に入るため、キャンセルをお受けできない場合があります。
予約販売は、在庫リスクを減らす強力な方法です。
先に需要を見る
↓
必要数を準備する
↓
売れ残りリスクを減らす
ただし、購入者を待たせる販売方法でもあります。
そのため、予定日と連絡を丁寧にします。
28.9 販売終了後の商品ページ運用
催事や期間限定販売が終わった後、商品ページをどうするかも重要です。
販売終了したからといって、すぐにページを削除するのはおすすめしません。
理由は、検索やSNSからまだアクセスが来る可能性があるからです。
SNS投稿を見る
↓
商品ページへアクセス
↓
ページが404
↓
機会損失
販売終了後の対応には、次の選択肢があります。
・販売終了表示にする
・次回販売案内に切り替える
・関連商品へ誘導する
・LINE登録へ誘導する
・完全終了ならリダイレクトする
販売終了表示の例です。
こちらの商品は販売を終了しました。
たくさんのご注文をいただき、ありがとうございました。
次回販売がある場合です。
次回販売のお知らせをご希望の方は、LINEにご登録ください。
販売開始時にご案内いたします。
関連商品へ誘導する場合です。
現在販売中の類似商品はこちらです。
販売終了後もページを残すメリットです。
・過去の実績として見せられる
・検索流入を受け止められる
・次回販売のWaiting Listにつなげられる
・SNSリンク切れを防げる
毎年行う季節販売なら、同じURLを育てる方法もあります。
/summer-event
/winter-gift
/popup-nagoya
年ごとにURLを変えすぎると、ページの評価や共有リンクが分散します。
毎年URLを変える：
/2026/summer-event
/2027/summer-event
継続して使う：
/summer-event
販売終了後の商品ページは、次回販売への入口として活用します。
28.10 小規模事業者向けの現実的な運用
最後に、小規模事業者向けの現実的な運用を整理します。
多店舗、催事、ポップアップ、Square POS、EC在庫をすべて完全連携しようとすると、かなり複雑になります。
最初から完璧を目指す必要はありません。
完璧な自動連携
↓
開発コストが高い
運用も難しい
トラブル時に原因が追いづらい
最初におすすめの運用は、在庫を分けて手動で管理する方法です。
EC用：30個
催事用：20個
店舗用：10個
催事が終わったら、残った在庫をEC用に戻します。
催事開始前：
EC用 30個
催事用 20個
催事終了後：
催事残 8個
EC用へ戻す：
EC用 38個
催事用 0個
最初の運用ルールです。
・EC用在庫と催事用在庫を分ける
・催事商品ページを用意する
・受取場所を明確にする
・現地決済とオンライン決済を分ける
・販売終了後のページを消さない
・催事終了後に在庫を棚卸しする
管理画面では、最低限次の機能があれば十分です。
・販売チャネル別在庫
・催事商品一覧
・予約注文一覧
・受取場所表示
・ステータス変更
・管理メモ
発展段階では、Square APIやPOSと連携します。
初期：
手動運用
中期：
CSVで在庫調整
発展：
Square Inventory APIやOrders APIと連携
本格運用：
POS、EC、在庫、注文を統合
小規模事業者にとって大切なのは、最初から大企業のようなシステムを作らないことです。
最初に必要なのは、
完璧な自動化ではなく、
間違えにくい運用。
売り場が増えると、現場の混乱が起きやすくなります。
だからこそ、ルールをシンプルにします。
どの商品を
どこで
いつまで
何個売るのか
どう受け取るのか
どう決済するのか
これが分かる状態を作れば、小規模事業者でも十分に多店舗・催事対応ができます。
第28章のまとめ
多店舗・催事・ポップアップ販売では、売り場が増える分、在庫、受取、決済、販売期間の管理が複雑になります。
この章で覚えておきたいポイントは、次の通りです。
1. 実店舗、EC、催事の在庫は最初から分けて考える
2. 催事用商品ページでは、開催場所、期間、受取方法を明確にする
3. 期間限定販売では、販売前・販売中・販売終了の表示を分ける
4. 受取場所は注文データとメールに必ず保存する
5. 店舗別在庫では、実在庫と予約済み在庫を分ける
6. Square POSとの連携は、段階的に考える
7. 現地決済とオンライン決済は、ステータスを分けて管理する
8. 予約販売では、受付期間、受取日、キャンセル条件を明確にする
9. 販売終了後の商品ページは削除せず、次回販売や関連商品へつなげる
10. 小規模事業者は、最初から完全自動化せず、間違えにくい手動運用から始める
多店舗・催事対応の基本は、次の一言にまとめられます。
売り場が増えたら、在庫と決済と受取場所を分けて考える。
EC、実店舗、催事、ポップアップ。
それぞれの売り場を混ぜずに管理することで、現場の混乱を防げます。
第29章では、売上、注文数、顧客行動を見える化するための分析とレポート設計を学んでいきます。