Checkout / 新機能

1つの注文で
「配送」と「店舗受取」を混在できる

カート内の商品ごとに「自宅へ配送」か「店舗で受取」かを選べるようになった。今まで配送方法が違うと注文を分ける必要があったが、1回のチェックアウトで完結する。Plus / Enterprise プラン向け。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : カートから注文確定までの流れ
  3. 従来 vs 今回の比較
  4. 対象プランと提供スケジュール
  5. 注文・フルフィルメントはどう記録されるか
  6. 有効化の手順
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

今までは、同じ買い物でも「配送する商品」と「店舗で受け取る商品」が混ざると、顧客は注文を分けて作る必要があった
今回から、1回のチェックアウトの中で商品ごとに受け取り方法を選べるようになった。
×2

従来 : 注文を分ける必要

配送と店舗受取が混在する場合、顧客は配送方法ごとに別々の注文(=別チェックアウト)を作る必要があった。

今回 : 1注文で混在OK

商品ごとに「配送」か「店舗受取」かを選択。全部配送・全部受取・一部だけ受取、いずれも1回のチェックアウトで完結。

顧客に提示される受け取り方法は、ストアが設定したロケーション・在庫・配送方法に基づき、商品ごとに利用可能なオプションが表示される。

2仕組み図解 : カートから注文確定までの流れ

カート 商品A・商品C 商品B 複数アイテム 商品ごとに方法を選択 ロケーション・在庫・ 配送方法から 利用可能な選択肢を提示 A・C → 配送 B → 店舗受取 1回で決済 1つの注文(admin) フルフィルメント①:配送 商品A・商品C フルフィルメント②:店舗受取 商品B
顧客から見れば「1回の支払い」。一方、注文が作成されると受け取り方法ごとに別々のフルフィルメントが生成され、それらが同じ注文に紐づく形で admin に表示される。

3従来 vs 今回の比較

項目従来今回(配送+受取の混在)
混在時の注文 分割必須 配送方法ごとに別注文を作成 1注文 1回のチェックアウトで完結
受け取り方法の選択単位 注文全体で統一 商品ごと に配送/受取を選択
顧客の支払い回数 注文ごとに複数回 1回
admin での見え方 別々の注文として並ぶ 1注文の中に受け取り方法別フルフィルメント
対象プラン Plus / Enterprise

4対象プランと提供スケジュール

対象は Plus / Enterprise

本機能を利用できるのは Plus プランおよび Enterprise プランのマーチャント。それ以外のプランについての記載はなし。

2027.07

2027年7月に自動展開

いまは「Feature test drives」から手動で有効化。2027年7月に、対象となる全チェックアウトへ自動リリースされる予定。

2027年7月の自動展開は「テストするかどうかの締め切り」でもある。配送・フルフィルメント・注文ロジックに関わるアプリや連携がある場合、それまでに分割注文への対応を確認しておく必要がある(詳細は §7)。

5注文・フルフィルメントはどう記録されるか

注文が作成されると、受け取り方法ごとに別々のフルフィルメントが生成され、それらが同一注文に紐づいて admin に表示される。どの商品が「店舗受取」で、どの商品が「配送」かが一目で分かる。

配送フルフィルメント

自宅などへ配送される商品群

顧客が指定した住所へ届ける商品をまとめたフルフィルメント。通常の配送フローで処理。

受取フルフィルメント

店舗で受け取る商品群

店舗ピックアップを選んだ商品をまとめたフルフィルメント。受取ロケーションでの引き渡しとして処理。

6有効化の手順

1

Feature test drives を開く

管理画面の「Feature test drives」から本機能を探す。

2

機能を有効化する

対象機能をオンにして、自店のチェックアウトで試す。

3

連携アプリを総点検

配送・フルフィルメント・注文に関わるアプリ/ワークフローを分割注文で検証(§7)。

ヘルプドキュメント、および開発者向け changelog の開発者向け手順が別途用意されている。質問・フィードバックはコミュニティフォーラムへ、と案内されている。

7技術者が押さえるべき5つのポイント

1. 1注文が「分割注文」になる

顧客には1注文・1決済でも、内部では受け取り方法ごとにフルフィルメントへ分割される。split orders(分割注文)を前提にした処理設計が必要。

2. 連携アプリは要再検証

配送・フルフィルメント・注文ロジックに触れるサードパーティ/カスタムアプリ、ワークフロー、連携は、本機能ありで徹底的にテストする必要があると明記されている。

3. アプリ開発元に対応確認を

利用中アプリの開発元に連絡し、分割注文(split orders)に対応済みかを確認するよう案内されている。フルフィルメントのルーティングが期待通り動くかが論点。

4. 表示は在庫・ロケーション依存

顧客に出る受け取り方法は、ストアのロケーション・在庫・配送方法の設定で決まる。受取ロケーションや在庫の整備が、選択肢の出方に直結する。

手動 自動

5. 2027年7月の自動展開がデッドライン

いまは Feature test drives での手動オプトインだが、2027年7月に対象チェックアウトへ自動リリースされる。つまり「テストしない」という選択肢は実質なく、それまでに連携の検証を済ませる前提でスケジュールを引くのが安全。

8業務に活かせる3つのユースケース

USE CASE 1

家具+小物の「大型は配送・小物は店舗受取」を1注文に

課題
大型商品は配送、当日欲しい小物は近くの店舗で受け取りたい顧客が、毎回注文を2つに分けてカゴ落ちしていた。
打ち手
配送+店舗受取の混在を有効化し、商品ごとに受け取り方法を選べる1注文の導線に切り替える。
効果
分割発注の手間を解消し、混在ニーズの取りこぼし(カゴ落ち)を削減。1決済化でCVR改善が見込める。
技術メモ
店舗をピックアップロケーションとして整備し、小物の在庫を該当店舗に紐づけると受取オプションが出やすい。
1 ORDER 配送 FF 受取 FF
USE CASE 2

OMS / フルフィルメント連携の「分割注文対応」棚卸し案件

課題
WMS・OMS・配送ラベル発行・ERP 連携などが「1注文=1配送方法」前提で組まれており、混在注文で処理が崩れるリスクがある。
打ち手
Feature test drives で有効化したサンドボックスで分割注文を発生させ、各連携が受け取り方法別フルフィルメントを正しく扱えるか検証→アプリ開発元へ対応確認。
効果
2027年7月の自動展開までに不具合を洗い出し、本番障害を回避。検証結果をそのまま顧客報告資料に転用可能。
技術メモ
注文・フルフィルメント・配送に触れる全アプリが対象。開発者向け changelog の開発者手順を起点にケースを設計する。
USE CASE 3

店舗在庫を活かした「即日受取」で来店送客

課題
店舗在庫がオンライン購入に活かせず、配送リードタイムを待てない顧客を逃していた。来店動機も作れていない。
打ち手
店舗をピックアップロケーション化し、在庫がある商品だけ店舗受取を選べるように。配送商品と同じ注文で完結させる。
効果
「今すぐ欲しい商品は店舗受取・残りは配送」を1回で実現。受取来店時のついで買いによる客単価向上も狙える。
技術メモ
受取オプションの表示はロケーション・在庫・配送方法の設定次第。店舗別在庫の精度が体験品質を左右する。

9提案で使える1行サマリ

「Plus / Enterprise 向けに、1回のチェックアウトで商品ごとに『配送』と『店舗受取』を混在できるように。
内部では受け取り方法別フルフィルメントに分割されるsplit orders のため、
配送・フルフィルメント連携アプリは2027年7月の自動展開までに検証が必須。」