この記事の対象: 実店舗を持ちながらShopifyでのEC構築・リニューアルを検討している事業者
読了時間: 約14分
「ネットショップも始めたいけれど、店の在庫とごちゃごちゃにならないか心配」——実店舗を持つ事業者からの相談で、最初に出てくるのはほぼこの一言です。
そして次に来るのが「店舗受取もやりたい」。近所のお客さんが送料を払うのは不自然だし、取り置きの電話対応を減らしたい。発想としては正しい方向です。
ただ、この2つは見た目ほど簡単ではありません。Shopifyの管理画面で「店舗受取を有効にする」のチェックを入れれば機能自体は動きますが、動かした先で困るのは、店頭に立っている人です。注文が入っていることに気づかない、取り置き分が売れてしまった、受け取りに来たお客さんを待たせる。設定は短時間で終わるのに、運用が回らない。
この記事では、Shopifyの予約・店舗受取と在庫連携について「何ができるか」ではなく「どの条件なら成立して、どこから作り込みが必要になるか」を整理します。アプリの紹介記事ではありません。発注側が自分のケースで判断できる状態になることを目指します。
実店舗を持つ事業者がShopifyで実現できる4つのこと
まず全体像です。実店舗×ECで語られる話は、実は次の4つに分解できます。混ぜて考えると議論が進まないので、最初に切り分けます。
受け取り方を増やす
- 店舗受取（BOPIS）
- ローカル配送
- 店頭取り置き・予約
在庫をつなぐ
- ロケーション管理
- 店頭POSとの同期
- 在庫の見せ方
顧客をつなぐ
- 会員・ポイント
- 購買履歴の統合
情報を出す
- 店舗ページ
- 営業日・アクセス
相談の入口は「店舗受取」でも、実際に工数がかかるのは「在庫をつなぐ」側です。
この4つのうち、Shopifyの標準機能だけで完結するのは「受け取り方を増やす」と「情報を出す」。残り2つは、条件次第でアプリかテーマ改修、あるいは両方が必要になります。
「店舗受取ができる」の意味を揃えておく
Shopifyの店舗受取は、正確には「ロケーションを受け取り場所として公開し、チェックアウトで配送方法の代わりに選べるようにする」機能です。標準で以下が動きます。
- チェックアウトに「店舗受取」の選択肢が出る（住所入力が不要になる）
- 受取可能な店舗が複数あれば一覧から選べる
- 注文管理画面に「受取待ち」のステータスが付く
- 「準備完了」にすると、お客さんへ通知メールが飛ぶ
ここまでは追加費用なしで使えます。よく誤解されるのが次の点です。
| よくある期待 | 標準機能での実態 |
|---|---|
| 店頭在庫があるものだけ店舗受取を選ばせたい | ロケーション単位の在庫がゼロでも、設定次第では選べてしまう |
| 商品ページに「◯◯店に在庫あり」と出したい | 標準のDawn系テーマには在庫の店舗別表示がない |
| 受け取り期限を過ぎたら自動でキャンセルしたい | 標準にはなし。手動運用かアプリ |
| 店頭スタッフのスマホに新着注文を通知したい | Shopifyアプリ（管理用）の通知か、外部連携 |
| 受取時にその場で追加購入・会計したい | Shopify POSの領域 |
| 「◯月◯日に取りに行く」と日時を予約させたい | 標準の店舗受取に日時指定はない。アプリかカスタム実装 |
ここがアプリを検討し始めるラインです。「店舗受取をやりたい」という要望が、上の表のどれを含んでいるのか。発注前にここを言語化しておくと、見積もりの精度が変わります。
「予約」と「店舗受取」は別の機能
相談の場でよく混ざるのが、この2つです。言葉としては近いのに、Shopify上ではまったく別の仕組みになります。
- 店舗受取：商品を買ったうえで、配送の代わりに店頭で受け取る。決済はEC側で完了している
- 予約販売（プレオーダー）：まだ入荷していない商品を先に注文させる。在庫ゼロでも購入できるようにする設定・アプリが要る
- 来店予約：商品の購入ではなく、来店の枠を押さえる。試着・相談・施術などの時間枠を売る形
3つ目の来店予約は、Shopifyの商品・在庫の仕組みとは相性が悪い領域です。時間枠を「在庫1個の商品」として売る方法もありますが、予約枠の変更やキャンセルまで運用に乗せると、専用の予約システムを別に立てたほうが結果的に安く済むケースが多くあります。「Shopifyで全部やる」を目的にせず、どこまでをShopifyに寄せるかを先に決めてください。
在庫をどう扱うか：3つのパターンで考える
在庫の話は、抽象的に議論すると永遠に終わりません。実務では次の3パターンのどれかに落ちます。自社がどれに当たるかを先に決めてください。
この3つは優劣ではなく、店頭オペレーションの精度と品目数で決まります。
パターンA：EC用と店頭用を分ける
Shopifyのロケーションを「ECの倉庫」と「店舗」で分け、ECの販売可能ロケーションを倉庫だけにする形です。
向いているケース
– 店頭のレジがShopify POSではない（既存のレジ・POSレジを使い続ける）
– 品目が多く、店頭の在庫精度に自信がない
– 店舗が1〜2店舗で、取り置きは電話・LINEで足りている
メリットは、売り越し（在庫がないのに注文が入る）がほぼ起きないこと。ECは倉庫の数字だけ見ればいいので、事故の余地が小さい。
デメリットは、店頭の余剰在庫をECで売れないこと。季節商材やアパレルのように、店舗ごとに消化スピードが違う業態では機会損失になります。
運用上の注意がひとつあります。このパターンでも店舗受取自体は使えますが、受取に指定された商品は倉庫から店舗へ動かす必要があるという点です。店舗と倉庫が同じ建物ならいいのですが、離れている場合は「いつ運ぶか」が運用の要になります。週2便しか社内便がないなら、受取可能日はそれに合わせて案内しなければなりません。
多くの事業者にとって、最初のEC立ち上げはこのAで始めるのが現実的です。Bから始めて在庫事故を起こすと、社内でECへの不信感が生まれ、その後の改善が全部やりにくくなります。
パターンB：在庫を共有する
同じロケーションの在庫をECからも店頭からも引く形です。理想形に見えますが、成立条件が厳しい。
成立に必要な前提
1. 店頭のレジがShopify POS、またはShopifyと在庫を双方向同期する仕組みを持っている
2. 店頭スタッフが「売れたらレジを通す」を徹底できる（手売り・後入力がない）
3. 入荷・返品・棚卸しの入力ルールが決まっている
3番目が実は一番の関門です。ECだけなら入荷担当が1人でも、店舗が絡むと入力する人が増えます。在庫連携の失敗は、システムではなく入力ルールの不在で起きます。
売り越しが起きたときの運用も決めておく必要があります。同じ商品の最後の1点が、店頭とECでほぼ同時に売れたらどうするか。謝罪してキャンセルするのか、取り寄せるのか。この判断を「そのとき考える」にしておくと、現場が止まります。
売り越しを減らす実務的な手当てとして、ECに出す在庫を実数より少なく見せる方法があります。店頭で動きの速い商品だけ、ECの販売可能数から数点を除いて売る。Shopifyのロケーション設定だけでは実現できないので、在庫管理アプリか、定期的な手動調整で運用することになります。完全に防ぐのではなく、事故の頻度を許容範囲まで下げる発想です。
パターンC：店頭在庫は「見せるだけ」
商品ページに「◯◯店に在庫あり」と表示するが、ECの注文は倉庫から出す。あるいは表示を見たお客さんが店舗に来る導線だけ作る。
大型チェーンのアパレル・家電などでよく見る形です。ECの売上ではなく来店を増やしたい事業者にはこれが合います。売り越しのリスクがなく、在庫数の表示を「あり／残りわずか／なし」の3段階に丸めれば、多少の誤差も吸収できます。
数字をそのまま出さないのは、体裁の問題ではありません。「残り1点」と出したものが実は前日に売れていた場合、来店したお客さんの体験は最悪になります。丸めた表示なら「在庫の状況は変動します」という但し書きが自然に効き、クレームの芽を減らせます。
ただし、この表示を作るにはテーマ改修が必要です。ロケーション別在庫をフロントに出す標準機能は、Dawn系テーマには入っていません。
アプリで足りる範囲と、テーマ改修が必要になる境界
ここが発注側にとって一番お金に効く話です。「アプリで解決できます」と言われたときに、それが本当かを自分で検証できる材料を置きます。
アプリで足りる
- チェックアウトの挙動を変えたい
- 管理画面側の業務を効率化したい
- 通知・帳票を増やしたい
- 倉庫・POSと数字をつなぎたい
テーマ改修が要る
- 商品ページの見た目・文言を変える
- 店舗ごとの在庫を商品ページに出す
- 店舗検索・店舗一覧ページを作る
- 受取店舗の選択を購入前に置く
大まかな線引きは「チェックアウト以降と管理画面はアプリ、商品ページの見た目はテーマ」です。
アプリが得意なこと
店舗受取まわりで広く使われているのは、次のような役割のアプリです。個別の使用感ではなく、解決する課題で覚えてください。
| 役割 | 解決する課題 | 検討の目安 |
|---|---|---|
| 店舗受取・ローカル配送の拡張 | 受取日時の指定、受取可能条件の細分化、期限管理 | 標準の店舗受取で足りないと分かってから |
| 在庫同期（POS・基幹連携） | Shopify外のレジ・在庫システムと数字を合わせる | パターンBを選んだ時点で必須 |
| 店舗検索（ストアロケーター） | 店舗一覧・地図・営業時間の管理 | 3店舗以上、または営業時間が頻繁に変わるなら |
| 配送日時指定 | 日本の商習慣に合わせた時間帯指定 | EC比率が高いなら早めに |
| 通知の拡張 | 受取準備完了の連絡をLINE・SMSでも出す | メール開封率が低い顧客層なら |
| 予約販売（プレオーダー） | 入荷前の商品を先に注文させる | 受注生産・入荷待ちが常態なら |
料金体系はアプリごとに違い、変更も頻繁です。無料枠を持つものもあれば、月額課金のものもあります。最新の料金は必ず各アプリのページで確認してください。ここで断定的な金額を書いている記事は、たいてい情報が古くなっています。
テーマ改修が必要になる代表例
「店舗ごとの在庫を商品ページに出す」は、ほぼ必ず改修です。Shopifyのロケーション別在庫はAPIでは取得できますが、テーマのLiquidから素直に引けるようにはなっていません。実装方法は複数あり、リアルタイム性をどこまで求めるかで難易度が変わります。
- 1時間に1回程度の更新でよい → メタフィールドに書き出す方式で軽く作れる
- 常に最新を出したい → フロントからAPIを叩く構成になり、表示速度と設計の検討が要る
前者は、外部から定期的にロケーション別在庫を読み、商品メタフィールドへ書き戻す仕組みを別途動かす形になります。テーマ側は書かれた値を表示するだけなので軽い。代わりに、書き戻しの処理が止まったときに古い数字が表示され続けるリスクを抱えます。「最終更新：◯時◯分時点」と併記しておくと、現場もお客さんも誤解しません。
もうひとつが「受取店舗を購入前に選ばせる」。Shopify標準ではチェックアウト画面で選ぶ流れですが、店舗ごとに在庫が違う業態では「先に店舗を選ばせて、その店舗の在庫だけ見せる」ほうが自然です。これは実質的にサイト全体の設計変更になるため、規模は小さくありません。商品一覧の絞り込み、カート内の整合、店舗を切り替えたときのカートの扱いまで、判断すべき箇所が広範囲に及びます。
改修を入れるなら、テーマのアップデートに耐える形にしておくことが重要です。Dawn本体のファイルを直接書き換えると、テーマを更新するたびに改修が消えます。
費用の考え方
金額そのものより、何が費用を動かすかを押さえておくほうが実務では役に立ちます。店舗受取まわりで見積もりが膨らむ要因は、おおむね次の4つです。
- 店舗数 — 1店舗と10店舗では、店舗検索・在庫表示・運用ルールの設計量が変わる
- 既存システムの有無 — 既存レジ・基幹システムとの連携は、相手側の仕様調査から始まるため読みにくい
- リアルタイム性の要求 — 「常に最新の在庫」は、定期更新の数倍の設計工数になる
- 購入前に店舗を選ばせるか — ここに踏み込むと、サイト全体の設計に波及する
見積もりを受け取ったら、この4つがどう見込まれているかを聞いてください。「店舗受取の実装一式」とだけ書かれた見積もりは、どちらが何を想定しているか分からないまま進み、後で揉めます。
Shopify POSとの関係を正しく理解する
実店舗の話をすると必ず出てくるのがPOSです。ここは誤解が多いので、分けて説明します。
POSは「レジ」であって「連携機能」ではない
Shopify POSは、Shopifyの管理画面と同じ商品・在庫・顧客データを使ってレジ業務を行うアプリです。POSを入れると自動的に在庫が連携されるのではなく、POSがShopifyのデータをそのまま使っているから結果的にズレない、という構造です。
つまり、既存のレジを使い続けるならPOSの恩恵はなく、在庫を合わせたければ別途の同期の仕組みが要ります。逆に、レジごとShopifyに寄せる判断ができるなら、在庫連携の悩みは大部分が消えます。
POS導入を検討すべき／しなくていい条件
| POSに寄せたほうがいい | 既存レジのままでいい |
|---|---|
| レジの入れ替え時期が近い | レジがリース契約の途中 |
| 店頭とECで同じ顧客が買う | 店頭客とEC客がほぼ別 |
| 店舗数が少ない（1〜3店舗） | 多店舗でレジ運用が固まっている |
| 店頭在庫をECでも売りたい | 在庫を分けて運用できる |
| 会員・ポイントを統合したい | 既存の会員システムが動いている |
POSには基本機能の範囲と、より高度な機能を含む上位プランがあります。店舗数・レジ台数によって費用の考え方が変わるので、検討する場合はShopifyの公式ページで現在の条件を確認してください。ここでも金額の断定は避けます。
見落とされがちなのが、レジまわりの周辺機器です。カードリーダー、レシートプリンタ、キャッシュドロア、バーコードスキャナ。ソフトの費用だけ見て検討を進めると、ここが後から乗ります。既存レジから乗り換える場合、周辺機器がそのまま使えるとは限らない点も確認事項です。
中間の選択肢：POSを「受取対応だけ」に使う
意外と知られていない使い方として、レジは既存のまま、店舗受取の処理だけShopify POSで行うという形があります。店頭スタッフがタブレットやスマホでPOSアプリを開き、受取に来たお客さんの注文を引き当てて「受け渡し済み」にする。会計は発生していない（EC側で決済済み）ので、レジを置き換えずに済みます。
この形なら、店頭オペレーションを大きく変えずに店舗受取を始められます。パターンAで始める事業者と相性がいい選択肢です。スタッフに覚えてもらう操作も「注文を探して、渡して、完了にする」の3手順で済むため、教育コストが小さいのも利点です。
導入後に効いてくる4つの論点
アプリもテーマ改修も、入れた直後は誰も困りません。困るのは3ヶ月後、1年後です。発注前に考えておくべき論点を4つ挙げます。
1. 月額が積み上がる
店舗受取まわりは、アプリが増えやすい領域です。受取日時指定、店舗検索、在庫同期、通知拡張——それぞれは小さな金額でも、5本入れれば毎月の固定費になります。しかも売上が伸びると課金が上がるタイプのアプリもあり、「売れるほどコストが増える」構造に気づかないまま運用しているケースは珍しくありません。
対策はシンプルで、入れる前に「これは何年使うか」を決めること。半年の試行で入れるなら解約前提で設計し、恒久的に使うならテーマ側に持たせるほうが安いこともあります。
2. 表示速度が落ちる
商品ページに店舗別在庫を出す、店舗検索に地図を埋め込む——どちらもフロント側の読み込みを増やします。アプリが埋め込むスクリプトは、テーマの管理外で動くものもあり、気づいたら商品ページの表示が目に見えて遅くなっていたという状況が起きます。
特に地図系は重い。店舗数が5店舗程度なら、地図を埋め込まずに住所とリンクだけ置く判断のほうが、体験としてはむしろ良いことがあります。地図アプリへのリンクを置けば、経路案内はスマホ側が引き受けてくれます。自前で地図を抱え込む理由は、店舗数が多くて一覧から探しにくい場合にほぼ限られます。
3. 解約しても残るものがある
アプリを解約したとき、商品データやテーマに書き込まれたものは残ることがあります。よくあるのは次の3つです。
- 商品メタフィールドに書かれた設定値
- テーマのLiquidに埋め込まれたアプリブロック・スクリプトタグ
- タグとして商品・顧客に付与された管理用ラベル
残っていても害がないものもありますが、テーマに残ったスクリプトが404を叩き続けたり、使わなくなったメタフィールドが管理画面を圧迫したりします。解約時に何を消す必要があるかは、導入時にドキュメントを確認しておくべき項目です。
もうひとつ、アプリが持っているデータは戻ってこない点も押さえておいてください。受取履歴や店舗ごとの設定をアプリ側に溜めていた場合、解約するとそれを引き継ぐ手段がないことがあります。乗り換えの可能性があるなら、導入時にエクスポート機能の有無を見ておくべきです。
4. 管理画面を触る人の負担
ここが最も軽視されます。店舗受取を入れると、注文管理の動線が2種類になります。配送の注文はいつも通り出荷、受取の注文は準備完了にして通知を出し、受け渡し後にフルフィルメント完了にする。
この2動線を、店頭スタッフが片手間で回せるか。ここが回らないと、受取の注文が何日も放置されます。
- 誰が注文をチェックするのか（役割を決める）
- どのタイミングで見るのか（開店時・閉店時など）
- 気づく仕組みはあるのか（通知・共有）
システムより先に、この3つを決めてください。決めずに導入して失敗した事例のほうが、システムの問題で失敗した事例より圧倒的に多いのが実感です。
あわせて、担当が休んだ日に誰が見るかまで決めておくと事故が減ります。店舗受取は「1日見落とすと、その日来店したお客さんが手ぶらで帰る」種類の業務です。属人化させた状態で連休に入ると、そこで確実に止まります。
アプリを選ぶときに実際に見る箇所
アプリストアの評価と件数だけで選ぶのは危険です。制作側が見ている項目を挙げます。
最終更新日
これが一番わかりやすい指標です。Shopifyは年に何度も仕様を変えるため、1年以上更新されていないアプリは、どこかで壊れる可能性が高い。特にチェックアウト関連は、Shopifyが拡張の仕組み自体を切り替えているため、古い方式のままのアプリは動かなくなるリスクがあります。
日本語・日本の商習慣への対応
海外製アプリは、UIが日本語化されていても、次の部分で不都合が出ます。
- 住所の表記順（郵便番号・都道府県の扱い）
- 日付の表記（曜日の出方、和暦は基本非対応）
- 顧客に届くメール文面（翻訳が不自然なことがある）
- 配送日時指定の時間帯区分（日本の宅配便の区分と合わない）
顧客の目に触れる文言を編集できるかは、導入前に必ず確認してください。編集できないアプリは、たとえ機能が優れていても採用しづらい。
サポートの言語と応答速度
障害が起きたとき、英語でやり取りできるか。時差があってやり取りが1日1往復になる前提で許容できるか。店舗受取のように現場が止まる機能では、ここが実務的に重要です。
自社テーマとの相性
アプリがテーマに要素を埋め込む場合、テーマ側の構造によっては表示が崩れます。特にカスタマイズ済みのテーマは要注意。導入前に開発ストアやコピーテーマで試すのが本来の手順ですが、そこまでやらないアプリも多い。せめて商品ページ・カート・チェックアウトの3画面は確認してから本番へ入れるべきです。
レビューの読み方
星の平均より、低評価レビューの中身と、それに対する開発元の返答を読んでください。「動かない」への返答が無いアプリと、原因と対処が書かれているアプリでは、導入後に問題が起きたときの展開がまったく違います。直近のレビューに同じ不具合が並んでいたら、それは今まさに壊れているサインです。
判断基準をもう少し体系的に整理した記事があります。
店舗受取を始める現実的な手順
最後に、実際に導入するときの順番を置きます。
2の段階を飛ばさないことが要点です。 最初からアプリを揃えると、何が必要だったのか検証できないまま固定費が乗ります。標準機能で回してみると、「受取日時の指定は要らなかった」「むしろ通知の方が問題だった」といった発見が出てきます。
この試行期間は、店舗受取をサイト上で大きく打ち出さずに始めるのが安全です。導線を絞って件数をコントロールし、オペレーションが回ることを確認してから前面に出す。最初から目立つ場所に置いて注文が殺到すると、検証どころではなくなります。
運用設計で決めておく項目
| 項目 | 決めておく内容 |
|---|---|
| 受取可能時間 | 営業時間全部か、混雑時間を除くか |
| 準備時間 | 注文から何時間・何日で準備完了とするか |
| 保管期限 | 何日間取り置くか、超えたらどうするか |
| 本人確認 | 注文番号のみか、身分証を見るか |
| 代理受取 | 家族などの受け取りを認めるか |
| 支払い | EC決済のみか、店頭払いも受けるか |
| 返品・交換 | 店頭で受けるか、EC窓口に一本化するか |
| 取り置き場所 | 店内のどこに置き、どう識別するか |
このうち「保管期限」と「代理受取」は、決めていないとトラブルになります。特に保管期限は、決めていなければ在庫が延々と押さえられたままになります。
最後の「取り置き場所」は地味ですが効きます。受取分をどこに置き、どの注文か分かるようにしておくか。バックヤードに無造作に積むと、受け渡しのたびに探す時間が発生し、それが積み重なって現場が嫌がるようになります。注文番号を書いた紙を貼って、受取日の近い順に並べる。この程度の取り決めがあるかないかで、運用の持続性が変わります。
顧客に伝える文言も同時に作る
機能を入れるだけでは足りません。商品ページ・カート・チェックアウト・注文確認メールのそれぞれで、店舗受取の条件が伝わっているかを確認してください。
「準備完了のメールが届いてから来店してください」が伝わっていないと、注文直後に来店するお客さんが必ず出ます。この1文があるかないかで、店頭の負荷が変わります。
同じ理由で、保管期限も注文確認メールに入れておくべきです。「◯日以内にお受け取りください」が最初のメールに書いてあれば、期限を過ぎた連絡も角が立ちません。後から電話で伝える運用は、伝え漏れが必ず起きます。
注文確認メールは標準テンプレートのままだと情報が足りないことが多い領域です。
配送設定との整合も忘れずに
店舗受取を入れると、配送設定側も見直しが必要になります。「近隣なら店舗受取、遠方なら配送」という設計にするなら、送料の刻み方も合わせて考えるべきです。店舗受取を選ぶと送料が浮く構造になっているか、そこがお客さんに伝わっているか。配送プロファイルの設計と一緒に整理すると手戻りがありません。
送料無料のラインを設けている場合は、店舗受取との関係も決めておいてください。受取なら金額に関係なく送料ゼロなのか、それとも送料無料ラインの訴求は配送のみに適用するのか。ここが曖昧だと、カート画面で意図しない表示になります。
店舗情報ページをどこに置くか
実店舗がある場合、店舗ページの置き場所も判断が必要です。コーポレートサイトとShopifyが別々にあると、営業時間の変更を2箇所で直すことになります。年末年始・臨時休業のたびに片方が古いまま、という状態は珍しくありません。
Shopify側に店舗情報を集約し、コーポレートサイトの役割まで持たせる構成は、実店舗を持つ事業者と特に相性が良い選択肢です。会社概要・店舗情報・お知らせをShopifyのページとブログで運用し、ECと同じ管理画面で完結させる。更新の手間が減ります。
店舗ページに載せる情報は、その場で判断できる粒度にしてください。住所と電話番号だけの店舗ページは、来店の意思決定を助けません。営業時間、定休日、駐車場の有無、最寄り駅からの所要時間、店内の写真。来店前に確認したいことは決まっているので、それを先回りして置きます。店舗受取をやるなら「受け取りカウンターの場所」まで書いてあると、初来店のお客さんが迷いません。
この考え方を詳しく整理した記事があります。
一方で、採用情報やIR、事業紹介が厚い企業だと、Shopifyだけでは表現の自由度が足りない場面もあります。店舗が事業の中心か、企業情報の発信が中心かで判断が変わります。
よくある質問
Shopifyの店舗受取は無料で使えますか？
Shopify標準の店舗受取機能自体に追加費用はかかりません。ロケーションを登録し、受取を有効にするだけで使えます。追加費用が発生するのは、受取日時の指定や期限管理などをアプリで拡張する場合、および商品ページの表示をテーマ改修で変える場合です。まずは標準機能で運用してみることをおすすめします。
店頭のレジとShopifyの在庫は自動で連動しますか？
レジがShopify POSであれば同じ在庫データを見るのでズレません。既存の別システムのレジを使い続ける場合は自動では連動せず、在庫同期アプリや個別の連携開発が必要になります。連携の難易度と費用は、既存レジ側がAPIを提供しているかどうかで大きく変わります。
商品ページに「◯◯店に在庫あり」と表示できますか？
Shopifyはロケーション別の在庫データを持っていますが、Dawn系の標準テーマにはそれを商品ページへ表示する機能がありません。表示するにはテーマ改修か、店舗在庫表示に対応したアプリの導入が必要です。更新のリアルタイム性をどこまで求めるかで実装方法と工数が変わります。
Shopifyで「受け取り日時の予約」までできますか？
標準の店舗受取に日時指定の機能はありません。受取日時を選ばせたい場合は、受取日時指定に対応したアプリを入れるか、カスタム実装が必要です。ただし日時を指定させると、その時間に必ず用意しておく約束が発生します。店頭の人員が薄い時間帯があるなら、日時指定より「準備完了メールが届いてから来店」の運用のほうが破綻しにくい場合もあります。
店舗が1店舗だけでも店舗受取をやる意味はありますか？
あります。近隣顧客の送料負担がなくなり、取り置きの電話対応が減ります。むしろ1店舗のほうが運用がシンプルで、失敗しにくい。ただし受取注文を誰がいつ確認するかだけは、店舗数に関係なく決めておく必要があります。
Shopify POSに切り替えるべきタイミングはいつですか？
既存レジの契約更新やリース満了のタイミングが最も検討しやすい時期です。契約途中で乗り換えると二重コストが発生します。EC側を先に立ち上げて在庫を分けて運用し、レジの更新時期に合わせてPOSへ寄せる進め方が、費用面でも現場の負担面でも無理がありません。
まとめ
実店舗を持つ事業者のShopify活用は、機能の話より運用の話が先です。
- 在庫は3パターンのどれかを先に決める — 分ける／共有する／見せるだけ。最初はAの「分ける」が安全
- 標準機能の店舗受取から始める — アプリを最初から揃えると、何が必要だったか検証できない
- 「予約」と「店舗受取」を分けて考える — 来店予約まで含めるなら、Shopifyに寄せない判断もある
- アプリとテーマ改修の境界は「チェックアウト以降か、商品ページの見た目か」 — この線引きで見積もりの妥当性を判断できる
- POSは連携機能ではなくレジ — 既存レジを使い続けるなら別途の同期が要る
- 導入後の4論点を先に考える — 月額の積み上がり、表示速度、解約時の残り物、管理画面を触る人の負担
- 運用ルールを決めてから機能を入れる — 保管期限と代理受取は必ず決める
店舗受取が失敗する原因は、ほとんどがシステムではありません。誰が注文を見て、いつ準備して、何日で期限とするか。この3つを決めずに始めたときに止まります。逆に言えば、そこさえ決まっていれば、Shopifyの標準機能だけでも十分に始められます。
