商品ページ、カート、チェックアウト — 配達日ピッカーはどこに置くべきか

時間に左右される商品を売っているストアは、遅かれ早かれ同じ問いに行き着きます。配達日ピッカーは、結局どこに置けばいいのか。

見つかる答えはたいてい「どう置くか」の話で、「どこに置くか」の話ではありません。こちらにテーマのスニペット、あちらにチェックアウト拡張、という具合です。設置場所そのものは細部として扱われます。細部ではありません。どの顧客が日付をくれて、どの顧客が日付なしで通り抜けるのか、そしてそれに気づくのが手遅れになる頻度を決めているのは、設置場所です。

場所は3つあります。そのどれもが「最善」ではありません。

Shopifyのプランで何ができるか

ここから始めてください。好みを持ち出す前に、選択肢が絞られます。

Checkout UI extensionはPlusのチェックアウトでしか動きません。これはアプリの制限ではなくプラットフォームの境界であり、どのアプリもこれを回避して売ることはできません。

ここで1つ、時系列の誤解をほどいておきます。checkout.liquidとAdditional Scriptsが動作を終えたのは、非Plusストアでは2026年8月です。Plusストアは2024年と2025年にすでに移行を終えていました。つまり、最近チェックアウトのカスタマイズが壊れたことでこの問いにたどり着いたなら、ほぼ間違いなく非Plusのプランです。そしてあなたにとっての解決策は、実行できないチェックアウト拡張ではなく、商品ページまたはカートへの設置です。

商品ページ

日付はカートに追加するフォームの中にあるため、商品がカートに入る前に選ばれます。

日付が購入判断の一部であるときに選んでください。 土曜日が埋まっているなら、土曜日用のケーキは買う意味がありません。14日に届けられない花束は、購入ではなく落胆です。選ぶその瞬間に空き状況を見せられるかどうかが、売上と返金の分かれ目になります。

また、Buy Nowを生き延びる唯一の設置場所でもあります。商品フォームの内側にあるため、動的チェックアウトボタンを使った購入者も日付を持ったまま進みます。

その代償。 カートが存在するより前に確約を求めることになり、最も早い段階で摩擦が生じます。さらに複数商品の注文には形が合いません。4点買う顧客は、商品が本当に別々に出荷されるのでもない限り、4つの日付を選びたいとは思わないからです。

カート

注文に対して1つの日付を、すべてがかごに入ったあとで選びます。

日付が個々の商品ではなく注文全体に適用されるときに選んでください。 毎週の食料品配達、ケータリングの注文、1回のスケジュール配送などです。

その代償、そしてここで多くの人がつまずきます。 Buy Nowボタンはカートを完全に飛ばします。これを使った購入者は、カートページのピッカーが一度も描画されないままチェックアウトに直行し、その注文には日付が付かないまま届きます。エラーは出ません。出てくるのは、日程を組めない注文です。

さらにカートの形式の問題もあります。Shopifyが公開しているカート用日付ピッカーの手法が動くのはカートページだけで、ドロワー型やポップアップ型のカートでは動かないとヘルプ記事にはっきり書かれています。多くのストアは、まったく別の理由でドロワー型カートに切り替えたあとにこれを知ります。

チェックアウト — Shopify Plus

セレクターは最終ステップ、チェックアウトそのものの一部として表示されます。

日付が選択ではなく確認であるとき、またはカートまでの導線をすっきり保ちたいときに選んでください。購入者がどの経路で来たかに関わらずすべての注文を捕捉できる唯一の設置場所でもあります。チェックアウトは全員が通るからです。

実務上の落とし穴。 機能をオンにするだけでは足りません。セレクターが表示されるのは、配達日が有効で、受付ルールが少なくとも1つ存在し、チェックアウトのスイッチがオンで、かつShopifyのチェックアウトエディタにブロックが配置されているときだけです。このうち3つはアプリ側に、4つ目はShopify側にあります。「有効にしたのに何も起きない」がこの設置場所で最も多い質問なのは、そのためです。

その代償。 顧客はファネルの最も深いところにいます。ここで日付が使えないと判明するのは、判明するタイミングとして最も高くつきます。だからこそキャパシティは最終ステップだけでなく、その手前でも効いている必要があります。そしてPlusが必要です。

商品ごとか、注文ごとか

設置場所と日付の粒度は別々の判断ですが、互いを縛ります。これを切り離して決めると、たいてい作り直しが二度発生します。

注文ごととは、かご全体に1つの日付ということです。食料品、ケータリング、週次のボックスなど、ある1日に1台の車で出ていくものに向いています。その時点でかごの中身は確定しているため、カートとチェックアウトの設置場所が自然に噛み合います。

商品ごととは、明細1行ごとに日付を持つということです。商品によって製作期間が本当に違うストアに向いています。明日出荷できる在庫のクッションと、10週間かかる張り地の椅子が並ぶような場合です。これが実際に機能するのは商品ページだけです。顧客が単一の商品とそのリードタイムだけを見ている場所は、そこしかないからです。

よくある間違いは、商品ごとの日付を採用しながら、それをカートで集めようとすることです。顧客は同じ質問を何度も受け、集まった答えは1本の配送ルートと突き合わせにくくなります。まとめて出荷するなら、日付は1つが誠実なモデルです。本当に別々に出るのなら、商品単位でそう伝えてください。

誰も触れない不具合

Shopifyのコミュニティをのぞけば、同じ2つのスレッドが繰り返し見つかります。カートで選んだ日付がチェックアウトに出てこない、そして日付が注文に保存されない。

配達日における本当のリスクはこれで、設置場所の問題ではありません。値が受け渡しを生き延びるかどうかの問題です。日付はストアフロントで取得され、チェックアウトに届き、注文に書き込まれ、そして実際に作業で見る場所 — 管理画面、注文タグ、配送ルート用のCSVエクスポート — に届かなければなりません。

どこか1か所でも切れれば、ピッカーは依然として動いているように見えます。カレンダーは描画され、顧客は選び、注文は完了します。気づくのは梱包台の上です。

手法を評価するとき — テーマのスニペット、アプリ、独自の拡張のいずれでも — 問うべきは「カレンダーが表示されるか」ではありません。テスト注文を1件入れ、管理画面で注文を確認し、そのタグを確認し、CSVエクスポートを確認する。 3つすべてに日付があれば、鎖はつながっています。

選び方

多くのストアは商品ページかカートに落ち着きます。Plusストアはたいてい1か所ではなく2か所に落ち着きます。

OrderRulesでの動き

3つの設置場所はいずれも同じ受付ルール、リードタイム、締め切り、休業日、キャパシティを読み込みます。二重に管理する設定はなく、チェックアウトの表示が商品ページの表示と食い違うこともありません。読んでいる元が1つだからです。

• 先に選ばれた日付は引き継がれます。チェックアウトでは選び直しではなく確認になり、商品が個別の日付を持つ場合は読み取り専用の確認として表示されます。
• キャパシティはどこでも効きます。 満席の日付は、商品ページのピッカーでも、カートでも、チェックアウトでもグレーアウトします。
• 日付は実際に作業する場所に届きます。 注文に保存され、注文タグとして付与され、配送ルート用のCSVエクスポートに含まれます。
• Plusではチェックアウトへの設置は置き換えではなく追加です。それ以外のプランでは、商品ページとカートのピッカーはこれまでどおり動きます。

制約が「どの曜日に配達するか」ではなく「その日に何個作れるか」であれば、それは別の設定です。注文日ではなく配達日で1日の上限を数える方法は注文日と配達日で扱っています。

正直な限界

1つはっきり書いておきます。これはピッカーをどこに置いても当てはまります。

キャパシティはチェックアウトで強制され、エクスプレス決済を含む通常のケースではすべて機能します。していないのは、ロックを取ることです。チェックアウトの検証は、すでに予約済みの状態のスナップショットを読みます。そのため、残り1枠の同じ日付に対して、ほぼ同じ秒にチェックアウトを完了した2人が、両方とも通ってしまうことがあります。

最後の1枠まで埋まった日付に、ほぼ同時のチェックアウトが必要になるため、めったに起きません。ただし不可能ではないので、日付ごとのキャパシティが小さい場合は、ぴったり上限まで設定するのではなく1枠の余裕を持たせる価値があります。これと違うことを言うアプリは、プラットフォームが提供していないものを主張しています。

次に読むもの

• チェックアウトでの配達日 — Plus向けの設置と、必要な4つの条件
• 配達日をはじめる — どのプランでも使える商品ページとカートのピッカー
• Theme app blockの設定 — テーマへのブロックの配置
• 配達キャパシティの上限 — 満席の日付がグレーアウトする理由
• Shopifyの配達日ピッカーアプリ比較 — ツールをまだ選んでいる場合