この記事の対象: Shopifyで配送日時を受けたい事業者・EC担当者、メール便と宅配便を併用していて設定に悩んでいる運用担当者
読了時間: 約14分
先に結論から書きます。メール便（ネコポス、ゆうパケット、クリックポスト、ゆうメールなど）は、配送日時の指定ができません。 宅配便のような手渡しではなくポストへの投函で完了する送り方なので、そもそも「何日の何時に届ける」という約束が成立しない仕組みになっています。
ここを曖昧にしたまま配送日時指定を入れると、事故が起きます。送料を抑えるためにメール便を選んだお客様の画面に、宅配便と同じ日時カレンダーが出てしまう。お客様は「12月24日の午前中」を選んで注文する。けれど実際にはポストに入るだけで、しかも日付は約束できない。クレームになり、謝罪して、再送して、レビューが1つ落ちる——という流れです。
この記事では、配送方法によって日時指定を出し分ける設計を中心に扱います。あわせて、Shopifyで配送日時を受ける3つの方法、選ばせてはいけない日の潰し方、受け取った日時を送り状まで届ける手順まで、導入から運用までを一本で整理します。
メール便と宅配便は、そもそも別物として扱う
指定できること・できないことの違い
Shopifyの設定画面に向かう前に、配送方法ごとの性質を整理しておきます。ここが頭に入っていないと、どの設定が必要でどの設定が無意味かを判断できません。
| 項目 | 宅配便（手渡し） | メール便（ポスト投函） |
|---|---|---|
| お届け日の指定 | 可能 | できない |
| 時間帯の指定 | 可能 | できない |
| 受け取り方 | 対面で手渡し・再配達あり | ポスト投函で完了・再配達なし |
| サイズ・重量 | 幅広く対応 | 厚さと重量に上限がある |
| 追跡 | あり | 商品によってあり・なし |
| 送料 | 高い | 安い |
| 補償 | あり | 無し〜限定的 |
メール便で日時指定ができない理由は、配送プロセスそのものにあります。手渡しの配送は「受け取る人がいる時間」に合わせて配達ルートを組む必要があるため、時間帯というパラメータが運用に組み込まれています。ポスト投函はその制約がないので、配達員は最も効率のよい順番で回ります。日付の約束を入れる余地が設計上ないわけです。
もうひとつ、見落とされがちな性質があります。メール便はお届け日数の目安も幅で示されること。宅配便より日数がかかる想定で見るのが普通で、繁忙期にはさらに伸びます。「ギフトだから到着日を指定したい」という要望に対しては、送料が安いからという理由でメール便を選ばせてはいけない、という判断も必要になります。
なぜShopifyでこれが問題になりやすいのか
Shopifyには標準機能として配送日時の指定欄がありません。だから何かを足すことになります。このとき、追加した日時入力欄はカートページや決済画面の「どこかに」置かれることになり、配送方法の選択とは別の場所で独立して動きます。
つまり、何も考えずに実装すると、お客様が「ネコポス」を選んでも、日時カレンダーはそのまま表示され続けます。入力欄と配送方法の選択が連動していないのが既定の状態なのです。
もともとShopifyはグローバル向けのプラットフォームで、北米・欧州のECでは購入者が「◯月◯日の午前中に」と指定する習慣がそこまで強くありません。配送は「◯〜◯営業日で届く」という幅で提示されるのが一般的です。日本のEC購入者は宅配便の時間帯指定に慣れていて「選べて当たり前」という感覚がある。このズレが出発点なので、Shopify本体の機能追加を待っても解決しない問題だと割り切って設計します。
配送方法で日時指定を出し分ける3つの設計
ここが、この記事でいちばん伝えたい部分です。メール便と宅配便を併用するストアで取れる設計は、大きく3つあります。
A. 動的に出し分ける
- 宅配便を選んだときだけカレンダーを出す
- 体験は最も自然
- 実装・検証の手間は最大
B. 注意書きで運用する
- カレンダーは常に出す
- 「メール便は指定不可」と明記
- 最も軽いが取りこぼしが残る
C. 商品・条件で分ける
- メール便対象商品を限定する
- 日時指定が要る商品は宅配便のみ
- 商品設計から決める必要がある
AからCの順に「実装が重い／運用が軽い」。自社の注文件数と商品構成で選びます。
どれが正解というより、件数が増えたときに人の手が入らない設計はどれかで選びます。注文数が少なければ注意書きで回りますが、増えると回らなくなります。
A. 選ばれた配送方法で、カレンダーの表示を切り替える
最も体験がいいのがこれです。お客様が宅配便を選んだときだけ日時カレンダーが出て、メール便を選ぶとカレンダーが消え、代わりに「メール便は日時のご指定を承れません」といった説明が出る。
実装の考え方は、配送方法の選択が変わったタイミングで、画面上の入力欄を出し入れするだけです。判定の軸になるのは配送レート名（配送方法の表示名）です。
4つ目が、実装で最も忘れられる箇所です。入力欄を隠しただけだと、先に選んだ日付が残ったまま注文が通ります。 管理画面にはメール便の注文に「12月24日午前中希望」と書かれた状態で入ってきて、出荷担当が混乱します。隠すときは必ず値も消してください。
注意点として、この設計には前提があります。
- 配送レートの名前を、判定できる形で統一しておくこと。「ネコポス」「ゆうパケット」「メール便（追跡あり）」のようにバラバラの命名でも構いませんが、どの名前が日時指定不可に該当するかを一覧で持ち、増えたら更新する必要があります
- 配送料金設定を変更したら、必ず実注文で再確認すること。レート名を変えると判定から外れ、メール便にカレンダーが出る状態に黙って戻ります
- Shopifyの決済画面（チェックアウト）で配送方法を選ぶ場合、カートページでは配送方法が確定していない。この順序の問題が次の論点につながります
B. 常に出して、注意書きで運用する
実装が最も軽い選択です。日時カレンダーは常に表示したまま、その近くに「メール便をご選択の場合、お届け日時のご指定は承れません」と明記します。
これで済むのは、次の条件を満たす場合です。
- メール便の注文比率が低い
- 出荷前に人の目が必ず通る運用になっている
- 日時が指定されたメール便注文が来たとき、個別に連絡する余力がある
この設計を選ぶなら、注意書きを置く場所を3か所に増やすのが効きます。カートの入力欄のすぐ横、配送方法を説明する固定ページ、そして注文確認メール。1か所だけだと読み飛ばされ、「書いてあったのに」という水掛け論になります。注文確認メールに入れておくと、少なくとも「届いてから気づく」事態は防げます。
メールのテンプレート編集はShopifyの管理画面から行えますが、どのメールをどの順で直すかは優先順位があります。
https://soreiine.jp/magazine/technique/shopify-notification-email-template-edit/
C. 商品側で分けてしまう
いちばん堅い設計です。日時指定を受ける商品と、メール便で送る商品を、そもそも混ぜない。
具体的には、メール便対象商品にタグを付け、その商品がカートに入っているときは配送方法をメール便に限定し、日時カレンダーを出さない。逆に、日時指定が必要な商品（生菓子、ギフト、生鮮品など）は宅配便専用にして、メール便のレートを出さない。
この設計の利点は、判定がカートの中身だけで決まることです。配送方法の選択を待たずに判断できるので、カートページの段階で表示を確定でき、決済画面で配送方法が変わって齟齬が出る心配もありません。
欠点は、商品設計そのものに手を入れる必要があること。「ステッカー1枚（メール便）とケーキ（宅配便・要冷蔵）を一緒に買いたい」という注文が実際にあるなら、この設計は使えません。混載が起きる商品構成かどうかを先に確認してから選びます。
日時を受け取る方法は3つある
出し分けの設計が決まったら、次は「そもそもどこで日時を受け取るか」です。技術的な難しさより、運用に乗るかどうかで選ぶべきものです。
方法1: カート属性（cart attributes）で受ける
Shopifyのカートには、注文に紐づく任意のメモを持たせる仕組みがあります。これが「カート属性」です。カートページに日付入力欄を置き、選ばれた値をカート属性として送ると、注文管理画面の「追加詳細」欄に表示されます。
カート属性とは: 注文に付随する自由な項目のこと。「ギフトメッセージ」「ラッピング希望」なども同じ仕組みで受けられます。商品ごとではなく、注文全体に1セット付きます。
この方法の要点は、Shopifyの決済フロー自体には一切手を入れていないことです。カートページという、テーマが自由に触れる範囲だけで完結するため壊れにくく、Shopify側の仕様変更の影響を受けにくい。
| 向いているケース | 向かないケース |
|---|---|
| 日付・時間帯を受け取れれば十分 | 選んだ日時で送料や在庫を変えたい |
| 商品の種類がそれほど多くない | 商品ごとに指定可能日が違う |
| 出荷作業が人の目を通る | 完全に自動で配送業者へ流したい |
| 月額を増やしたくない | 社内に実装を頼める先がない |
ただし、メール便との出し分けという観点では弱点があります。カートページの時点では、お客様がまだ配送方法を選んでいない。配送方法の選択は決済画面で行われるため、カートページのカレンダーは「どの配送方法で送られるか分からない状態」で表示されることになります。
この弱点を埋めるには、前章のC案（商品側で分ける）と組み合わせるのが現実的です。カートの中身から配送方法が一意に決まるなら、カートページでも正しく出し分けられます。
もうひとつ、カート属性は購入者側から送られる値なので、後から検証する経路がありません。休業日が選ばれた注文が入る可能性をゼロにはできないので、注文後に確認する運用を必ずセットで用意します。
方法2: 配送日時指定アプリを入れる
Shopify App Storeには、配送日時指定を専門に扱うアプリがいくつもあります。カレンダーUI、休業日の除外、リードタイム設定、時間帯マスタといった機能が最初から入っています。
アプリ選定で見るべきは機能一覧ではありません。 メール便を併用しているなら、確認すべき項目は次の通りです。
| 確認する箇所 | なぜ見るのか |
|---|---|
| 配送方法ごとの出し分け対応 | これが無いアプリだと、本記事の核心が解決しない |
| 商品タグごとの条件設定 | C案（商品で分ける）を取るときに必須 |
| 最終更新日 | 長く更新がないものはShopify側の仕様変更に追従していない可能性 |
| 日本語対応の範囲 | 購入者画面だけ日本語で管理画面は英語、というケースが多い |
| サポートの言語と時間帯 | 出荷が止まる種類の障害。時差のある英語サポートだけだと厳しい |
| 注文データへの残り方 | メタフィールドか注文メモか。後述の送り状連携に直結する |
確認の方法としては、レビュー本文を「星の数」ではなく「直近の低評価の中身」から読むのが早いです。表示崩れ・日本語化の範囲・サポートの応答といった、機能一覧に出ない情報はそこに集まります。
そして必ず、本番テーマの複製に入れて試すこと。アプリの埋め込みはテーマファイルに触れるものがあり、本番で試して戻す前提だと消し残りが出ます。料金は無料枠のあるものから月額課金のものまで幅があり、注文件数に応じた従量課金に切り替わることもあるため、最新の料金は各アプリのページで必ず確認してください。
方法3: チェックアウト画面に出す
Shopifyの決済画面は長らくテーマから触れない領域でしたが、現在は拡張の仕組みが用意されていて、対応したアプリであれば決済画面上に日時指定欄を出せます。プランによって使える範囲が変わるため、自社の契約プランで何ができるかを先に確認してください。
メール便との出し分けという観点では、この方式が最も有利です。 決済画面では配送方法がすでに選ばれているため、選ばれたレートに応じて表示を切り替える判定が確実に行えます。カートページ方式のような「まだ配送方法が決まっていない」問題が発生しません。
もう一点、カートページに置く方式には取りこぼしの経路があります。商品ページの「今すぐ購入」ボタンや外部決済のショートカットから決済に直行すると、カートページを素通りするため日時指定が入力されないまま注文が成立します。この経路を塞ぐ（テーマ設定で該当ボタンを非表示にする）か、注文後にフォローする運用を用意するか、どちらかを必ず決めておきます。塞ぐ判断は、カートを経由しない購入導線を丸ごと捨てることでもあるので、その導線からの注文量を確認してから決めてください。
アプリで足りる線と、テーマ改修が必要になる線
アプリで足りることが多い
- 全商品で同じリードタイム
- 休業日は全社共通
- 時間帯は宅配便の標準区分そのまま
- メール便と宅配便が混ざらない
- 受け取ったデータは人が見て処理する
テーマ改修・開発が要りやすい
- 商品ごとに指定可能日が違う
- メール便と宅配便が1注文に混在する
- 地域で選べる時間帯が変わる
- 冷凍・常温など配送区分が混在
- 基幹システム・WMSへ自動連携する
左側に全部当てはまるならアプリが素直です。右側に1つでも該当するなら、アプリの設定画面で表現しきれるかを事前に検証してください。
検証のやり方は決まっています。自社で実際に起きる注文パターンを3つ書き出して、それをアプリの設定画面で組めるかを試す。 「メール便対象商品だけの注文」「メール便商品と宅配便商品が混ざった注文」「離島宛の注文」のように、条件が最も複雑になる組み合わせを選びます。機能一覧を眺めて判断すると、見誤りやすくなります。
「機能が足りるか」より「誰が毎月触るか」
制作会社としてShopifyを構築する一方、自社でもShopifyストアを運営している立場から言えるのは、その設定を毎月誰が触るかのほうが後々効いてくるということです。
年末年始の休業日を登録する。臨時休業を反映する。繁忙期にリードタイムを1日延ばす。これらは全部、実装が終わったあとに毎月・毎年発生する作業です。設定画面が英語だったり項目名の意味がわかりにくかったりすると、この作業は「わかる人」に集中します。その人が異動すると、休業日が更新されないまま注文が入る——という事故につながります。
- 設定を月1回以上触る想定なら、管理画面のわかりやすさを最優先に選ぶ
- 設定がほぼ固定なら、テーマ側に組み込んで月額を発生させない選択も合理的
- 設定が複雑で、かつ頻繁に変わるなら、専用の管理UIを作るところまで検討する
公開後の更新を誰が担当するかは、実装方式の選定と同じくらい結果を左右します。
https://soreiine.jp/magazine/guide/shopify-operation-team-structure/
なお「自前実装＝安い」ではありません。カレンダーUI、休業日マスタ、リードタイム計算、配送方法との連動、送り状向けの出力形式——このうちどこまで作るかで工数は大きく変わります。見積もりを取るときは機能を1つずつ分解して提示してください。「配送日時指定一式」でまとめて聞くと各社の想定がバラバラになり、比較できない見積もりが並びます。
指定できない日をどう潰すか
配送日時指定の実装で、実際にいちばん時間を使うのがこの部分です。「日付を選べるようにする」のは簡単で、「選ばせてはいけない日を潰す」のが本体です。
除外すべき日は4種類
| 分類 | 中身 | アプリの標準対応 |
|---|---|---|
| 出荷リードタイム | 注文から出荷までの営業日数。商品ごとに違う場合あり | ほぼ対応 |
| 自社の休業日 | 定休日、年末年始、臨時休業 | ほぼ対応 |
| 配送業者側の事情 | 年末年始の集荷停止、離島の日数加算、時間帯指定不可エリア | 分かれる |
| 受付上限 | 先の日付をどこまで開けるか、1日あたりの出荷キャパ | 分かれる |
3つ目は特に、自社では検知できないという性質があります。配送業者の集荷停止期間や地域ごとの日数加算は、業者側の告知を見て手で反映するしかありません。年末年始の運用を決めるときは、業者の告知が出る時期を先に確認して、反映作業の予定を年間スケジュールに入れておきます。
リードタイムの数え方で事故る
「注文から3日後以降を選べる」と設定するとき、その3日は営業日なのか暦日なのか。ここが実装でも運用でも最も事故りやすいポイントです。
| 数え方 | 金曜18時の注文の最短日 | 想定される混乱 |
|---|---|---|
| 暦日で3日 | 月曜 | 土日に出荷していないのに月曜着になる |
| 営業日で3日（土日休） | 水曜 | 購入者からは「なぜ月曜じゃないのか」と見える |
| 営業日3日＋当日締切考慮 | 水曜（当日15時締切なら木曜） | 締切時刻を明示しないとクレームになる |
締切時刻の扱いを決めておくことが特に重要です。「当日15時までのご注文は当日出荷」という運用をしているなら、15時1分の注文と14時59分の注文で最短指定日が変わります。これをシステム側で自動的に切り替えるのか、安全側に倒して常に翌営業日起算にするのか。前者は購入者に親切ですが、実装も検証も増えます。
もう一つ、締切判定でつまずくのがタイムゾーンです。判定をブラウザ側で行うと、購入者の端末の時計とタイムゾーン設定に依存します。日付の境界に関わる判定は、ストアのタイムゾーンを基準に固定するのが原則です。
導入時には、最短日は少し余裕を持たせるほうが運用は安定します。ギリギリに設定して間に合わなかったときのコスト（謝罪、再送、レビューの毀損）は、1日長く見せて機会損失するコストより大きいことが多いためです。
休業日は「コードを触らずに変えられる」ように
年末年始の休業日を毎年テーマのコードを編集して更新している、という状態は避けます。自前実装の場合は次のいずれかを用意します。
- テーマ設定（settings_schema）に休業日リストを持たせる——テーマエディタから編集でき、コードに触らずに済む
- メタオブジェクトで休業日マスタを作る——構造化して持てるので、定休日と臨時休業を分けて管理できる
休業日の件数が増える見込みがあるならメタオブジェクト、年に数日足すだけならテーマ設定で十分です。ただしテーマ設定に持たせる場合、テーマを差し替えると設定値も入れ替わる点に注意します。更新手順書に「休業日設定の引き継ぎ」を明記しておいてください。
いずれの方法でも、登録した休業日が実際にカレンダーで潰れているかを公開前に目視確認すること。設定値の書式（2026-12-30 なのか 12/30 なのか）がズレていて無言で無視される、という失敗は頻繁に起きます。設定したのに画面に反映されないときの切り分けは、原因の種類ごとに確認する順番が決まっています。
https://soreiine.jp/magazine/technique/shopify-not-reflected-not-displayed-causes/
受け取った日時を、送り状まで届ける
「カートで日時を受け取れた」ことと「その日時で実際に届く」ことの間には、まだ距離があります。
注文データのどこに入るかで後工程が変わる
| 格納先 | 注文CSVエクスポート | 外部連携での扱い |
|---|---|---|
| カート属性（追加詳細） | 出力される | 連携ツール側で読めることが多い |
| 注文メタフィールド | 標準の注文CSVには出ない | APIでは取得可能。ツールによっては読めない |
| 配送方法名に埋め込む | 出力される | 送り状ソフトの取込項目に乗りやすい |
| アプリ独自のDB | アプリ側の機能に依存 | アプリを解約すると閲覧不能 |
一番下の行が、いちばん警戒すべき箇所です。 アプリ独自のデータベースに日時が保存されるタイプは、解約した時点で過去注文の配送日時にアクセスできなくなる可能性があります。返品・再送・問い合わせ対応で過去注文を遡ることは普通にあるので、選定時に「注文オブジェクト側にも値が残るか」を確認しておきます。
確認の仕方は簡単で、テスト注文を1件通してから注文CSVをエクスポートしてみる。そこに日時が出ていれば後工程で困りません。導入前の10分の作業で、解約時の数時間が消えます。
Shopify自体を解約するときに何が残り何が消えるかも、同じ考え方で先に押さえておくと安全です。
https://soreiine.jp/magazine/guide/shopify-cancel-data-export-guide/
時間帯の選択肢は、送り状の区分そのままで作る
送り状発行システムが受け付ける時間帯は、決められたコードや区分名で指定する形式になっています。ストア側で自由なテキストとして受け取ると、そのままでは取り込めません。
対策はシンプルで、入力段階で送り状側の区分に合わせておくことです。 時間帯の選択肢を、使う配送業者が用意している区分そのままの表記で作る。自由記述欄にしない。ここを最初に決めておくと、後工程の変換が単純なマッピングで済みます。
日付の書式も同じです。途中に表計算ソフトを挟むと、日付が別の形式に自動変換されて取り込めなくなる——という定番の事故が起きます。CSVを表計算ソフトで開いて保存し直す運用は、可能なら避けます。
逆にやってはいけないのが、「ご希望があればご記入ください」という自由記述の備考欄で受けること。表記ゆれ（「午前中」「AM」「午前」「朝」）が発生し、毎回人が読んで判断することになります。件数が増えたときに真っ先に破綻します。
「指定を受ける」と「約束する」は違う
カートで受け取った日時を、希望として受けるのか、確約として扱うのか。運用ルールとして先に決めておきます。
- 希望として受けるなら、注文確認メールや商品ページに「交通事情等により前後する場合があります」と明示する。カレンダーのラベルも「お届け希望日」にする
- 確約として扱うなら、在庫・出荷キャパ・配送業者の状況を踏まえた設計が必要になる。1日あたりの受注上限を設ける仕組みも検討対象
多くのストアは前者です。表記の一貫性も見落とされがちで、カートのラベルが「お届け希望日」なのに注文確認メールでは「お届け日」と書かれている——この程度のズレでも、遅延したときの受け止められ方が変わります。カート・注文確認メール・発送通知メール・商品ページの4か所で、同じ言い方に揃えてください。
実店舗がある場合は、店舗受け取りという選択肢を足すことで日時指定そのものの必要性が下がるケースもあります。
https://soreiine.jp/magazine/guide/shopify-store-pickup-inventory/
実装前に決めておくことチェックリスト
要件を制作会社に伝える前、あるいは自分で実装に入る前に、次の項目を決めておくと手戻りが減ります。
配送方法について
- メール便と宅配便を併用するか
- 併用する場合、1注文に両方が混ざることがあるか
- 混ざる場合、日時指定をどう扱うか（出し分け／注意書き／商品で分離）
- 配送レートの名前は、判定できる形で統一されているか
受け取る内容について
- 日付だけか、時間帯も必要か
- 「指定なし」を選べるようにするか、必須にするか
- 商品によって条件が変わるか
日付の範囲について
- 最短で何日後から選べるか。営業日か暦日か
- 当日締切の時刻を設けるか
- 最長で何日先まで開けるか
- 定休日・休業日をどこで管理するか
運用について
- 受け取った日時を、誰がどの画面で見るか
- 送り状ソフトへどう渡すか。時間帯の選択肢は業者の区分に合っているか
- 「希望」なのか「確約」なのか。4か所の表記は揃っているか
- 「今すぐ購入」など、カートを経由しない導線があるか。塞ぐかフォローするか
このリストを埋めた状態で相談すれば、見積もりの精度も提案の中身も変わります。「配送日時を指定できるようにしたい」という一行だけで見積もりを取ると、各社の想定がバラバラになって比較できません。
なお、カートまわりの表示や配送に関する案内文をどう見せるかは、他社のECサイトを見るのが最も早い学習法です。Soreiine!!のギャラリーには実際に公開されているサイトが集まっているので、配送・送料まわりの案内をどこに置いているか、どんな言い回しにしているかを横断して眺めると、自社の文面を決める材料になります。
よくある質問
Shopifyでメール便（ネコポス・ゆうパケット）に配送日時を指定できますか
できません。メール便はポストへの投函で配達が完了する送り方で、受け取る人の在宅時間に合わせたルート設計をしないため、日付と時間帯の指定という概念がそもそもありません。Shopify側の設定や有料アプリで解決できる問題ではなく、日時指定が必要な注文は宅配便に誘導する設計にしてください。
メール便と宅配便を併用しているとき、日時カレンダーはどう出せばいいですか
取れる設計は3つです。選ばれた配送方法に応じてカレンダーを出し入れする、カレンダーは常に出して「メール便は指定不可」と明記する、メール便対象商品と日時指定が必要な商品をそもそも分ける。注文件数が少ないうちは注意書きで回りますが、件数が増えると人の手が追いつかなくなるため、出し分けか商品分離を検討してください。
配送方法を変えたら日時がクリアされません。何が起きていますか
入力欄を画面上で非表示にしているだけで、入力済みの値が消えていない状態です。この場合、メール便の注文に「◯月◯日 午前中希望」という値が付いたまま管理画面に入ってきます。表示を切り替える処理と、保持している値をクリアする処理は別物なので、両方を実装してテスト注文で確認してください。
「今すぐ購入」ボタンから注文されると日時指定が入りません
カートページに入力欄を置く方式では、商品ページから直接チェックアウトへ飛ぶ導線で入力が抜け落ちます。対策は、該当ボタンを非表示にするか、チェックアウト画面上に入力欄を出せる方式に切り替えるかの2つです。前者はカートを経由しない購入導線を捨てる判断になるので、その導線からの注文量を確認してから決めてください。
アプリを解約したら、過去の注文の配送日時はどうなりますか
アプリの実装方式によります。カート属性や注文メタフィールドに値を書き込むタイプなら注文データ側に残りますが、アプリ独自のデータベースだけに保存するタイプは解約後に閲覧できなくなる可能性があります。導入時にテスト注文のCSVをエクスポートして格納先を確認し、解約前には必ず過去注文をエクスポートしてください。
まとめ
メール便は配送日時を指定できません。これは設定で解決できる話ではなく、配送方法そのものの性質です。Shopifyで配送日時指定を入れるときは、まずメール便と宅配便をどう扱い分けるかを決めてから、実装方法の検討に入ってください。順序を逆にすると、カレンダーを作ってから出し分けを後付けすることになり、検証項目が倍に増えます。
選択肢の整理は次の通りです。
- 出し分けの設計 — 配送方法に連動させる／注意書きで運用する／商品側で分ける。注文件数と商品構成で決まる
- 受け取る場所 — カート属性、専用アプリ、チェックアウト拡張。メール便との出し分けを厳密にやるなら、配送方法が確定している決済画面側が有利
- 選ばせてはいけない日の潰し方 — リードタイムを営業日で数えるか暦日で数えるかを最初に決める
- 送り状までの経路 — 時間帯の選択肢を配送業者の区分そのままで作っておくと、後工程の変換が単純になる
そして実装の巧拙より長く影響するのが、その設定を毎月誰が触るかです。「休業日を追加するとき、どの画面のどこを触るか」に即答できる設計になっているかを、選定の段階で確かめてください。制作会社に依頼するなら、この質問に答えられるかどうかが、運用まで考えて設計しているかの判定に使えます。
配送日時指定は、うまく入れれば問い合わせ対応の工数が減り、再配達も減り、購入前の離脱も減ります。逆に雑に入れると、手作業と表記ゆれと確認漏れが積み上がります。配送方法の棚卸しから始めるだけで、結果はかなり変わります。
