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

図解 ： 1つの注文で「配送」と「店舗受取」を混在できる（Plus / Enterprise 向け） Checkout / 新機能 1つの注文で 「配送」と「店舗受取」を混在できる カート内の商品ごとに「自宅へ配送」か「店舗で受取」かを選べるようになった。今まで配送方法が違うと注文を分ける必要があったが、1回のチェックアウトで完結する。Plus / Enterprise プラン向け。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： カートから注文確定までの流れ 従来 vs 今回の比較 対象プランと提供スケジュール 注文・フルフィルメントはどう記録されるか 有効化の手順 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 今までは、同じ買い物でも「配送する商品」と「店舗で受け取る商品」が混ざると、 顧客は注文を分けて作る必要があった 。 今回から、 1回のチェックアウトの中で商品ごとに受け取り方法を選べる ようになった。 従来 ： 注文を分ける必要 配送と店舗受取が混在する場合、顧客は配送方法ごとに別々の注文（＝別チェックアウト）を作る必要があった。 今回 ： 1注文で混在OK 商品ごとに「配送」か「店舗受取」かを選択。全部配送・全部受取・一部だけ受取、いずれも1回のチェックアウトで完結。 顧客に提示される受け取り方法は、ストアが設定した ロケーション・在庫・配送方法 に基づき、 商品ごとに 利用可能なオプションが表示される。 2 仕組み図解 ： カートから注文確定までの流れ 顧客から見れば「1回の支払い」。一方、注文が作成されると 受け取り方法ごとに別々のフルフィルメント が生成され、それらが同じ注文に紐づく形で admin に表示される。 3 従来 vs 今回の比較 項目 従来 今回（配送＋受取の混在） 混在時の注文 分割必須 配送方法ごとに別注文を作成 1注文 1回のチェックアウトで完結 受け取り方法の選択単位 注文全体で統一 商品ごと に配送／受取を選択 顧客の支払い回数 注文ごとに複数回 1回 admin での見え方 別々の注文として並ぶ 1注文の中に受け取り方法別フルフィルメント 対象プラン — Plus / Enterprise 4 対象プランと提供スケジュール 対象は Plus / Enterprise 本機能を利用できるのは Plus プランおよび Enterprise プランのマーチャント。それ以外のプランについての記載はなし。 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改善が見込める。 技術メモ 店舗をピックアップロケーションとして整備し、小物の在庫を該当店舗に紐づけると受取オプションが出やすい。 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月の自動展開までに検証 が必須。」 source ： changelog.shopify.com / ship-and-pickup-in-one-order 公開日 ： 2026-06-17