配送と店舗受取を「1 注文」で Ship and pickup in one order

図解 ： Ship and pickup in one order（配送と店舗受取を 1 注文で）feature preview Action Required / Feature Preview 配送と店舗受取を「1 注文」で Ship and pickup in one order Shopify Plus / Enterprise 向けに、同じ注文の中で商品ごとに「配送」か「店舗受取」を選べる単一チェックアウトが登場。これまでは配送方法ごとに別注文が必要だった。デリバリー／フルフィルメント情報の流れ方が変わるため、アプリ提供者は今すぐ feature preview で検証・改修を。 Action Required Admin Extensions Admin GraphQL API Checkout UI Customer Accounts Functions Storefront GraphQL API このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 1 注文 → 複数フルフィルメント API は何が変わる／変わらないのか 従来 vs 新仕様の比較 放置するとどうなるか（リスク） テスト手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 今まで顧客は「配送で買う注文」と「店舗受取で買う注文」を 別々に 出す必要があった。 新仕様では、配送とローカルピックアップの両方を有効にしているマーチャントで、 カート内の商品ごとに「配送」か「店舗受取」を選べ、それが 1 つの注文にまとまる 。 従来 ： 配送方法ごとに別注文 配送したい商品と店舗受取したい商品を、それぞれ別のチェックアウトで購入する必要があった。決済も 2 回。 新仕様 ： 1 注文で混在 商品ごとに配送 / 店舗受取を選択。1 つの注文の中に「配送用」と「受取用」の複数フルフィルメントオーダーが生成される。決済は 1 回。 対象は Shopify Plus / Enterprise マーチャント。配送とローカルピックアップの両方が有効なストアで動く。マーチャント全体への展開時期や利用料の詳細は記事に 記載なし （現時点では feature preview のテスト期間）。 2 仕組み図解 ： 1 注文 → 複数フルフィルメント ポイントは 「1 注文 ＝ 1 配送方法」という前提が崩れる こと。フルフィルメントオーダー単位で delivery_method （ SHIPPING / PICK_UP ）を読み、商品をそれぞれのルートへ振り分ける必要がある。 3 API は何が変わる／変わらないのか 変わらない ： スキーマ 新しい API フィールドの追加も、破壊的なスキーマ変更も無い。 既存のフィールドがそのまま使われる。 変わる ： データの「組み合わせ」 既存フィールドが これまで来なかった組み合わせの値 を返すようになる。ここを前提に作っていないと壊れる。 新しく起こりうる 3 つの組み合わせ 対象 これまで これから（新仕様） Checkout の deliveryGroups 実質ひとまとまりで扱っていたケースが多い 複数 各グループが「その商品群をどう届けるか」を表す。配送グループと受取グループが同居しうる。 Order 内の fulfillment order 同一注文は基本同じ配送方法 混在 同じ注文に SHIPPING と PICK_UP の fulfillment order が両方存在しうる。 delivery_method フィールド 注文単位の前提で読んでいた可能性 要参照 fulfillment order ごとに付与され、各グループのフルフィルメント方法を示す。グループ単位で読む。 影響しうるアプリは「デリバリー／フルフィルメント情報を 読む・計算する・表示する 」もの全般。記事タグからも Admin GraphQL API / Storefront GraphQL API / Checkout UI / Functions / Customer Accounts / Admin Extensions と広範囲に及ぶことが分かる。 4 従来 vs 新仕様の比較 項目 従来 Ship and pickup in one order 顧客の購入体験 分割 配送と受取で別注文・別決済 統合 商品ごとに方法を選び 1 注文・1 決済 注文と配送方法の関係 1 注文 ＝ 1 配送方法（前提） 1 注文の中に配送と受取が 混在 fulfillment order 単一方法 SHIPPING と PICK_UP が併存しうる API スキーマ — 変更なし 既存フィールドの値の組み合わせが変わる アプリ側の対応 不要 要改修・要検証 feature preview で今すぐテスト 対象マーチャント — Shopify Plus / Enterprise（配送＋ローカルピックアップ有効） 5 放置するとどうなるか（リスク） チェックアウトエラー 複数 deliveryGroup を想定していないロジックが checkout 中に失敗し、購入を止めてしまう。 計算ミス 送料・税・在庫などを「注文 ＝ 単一配送方法」で合算していると、配送＋受取の混在で誤った数値を出す。 フルフィルメント振り分け失敗 delivery_method を見ずに一律ルーティングすると、受取商品を倉庫出荷に回す等の誤配送が起きる。 これは Action Required タグの付いた変更。未対応アプリはマーチャントのチェックアウト体験を直接損なう。テストウィンドウは すでに開いている ので、ロールアウト前に feature preview で対応を済ませること。 6 テスト手順（3ステップ） 1 Dev store を作る 「Dev stores」から開発ストアを新規作成。Shopify Plan で Plus 、「Test a feature preview」で Ship and pickup を選択。 2 混在注文を作る 配送商品と店舗受取商品の両方を含むテスト注文を実際に発注し、end-to-end で挙動を確認。 3 delivery_method で振り分け確認 アプリが fulfillment order の delivery_method を読み、商品を正しいルートに振り分けているか検証。 テスト前後にやること 事前 テストガイドの確認と前提の棚卸し 公式のテストガイドを読み、「1 注文に配送方法は 1 つ」と仮定している箇所をコード内で洗い出す（送料計算・在庫引当・出荷連携・表示まわり）。 事後 マーチャントへの周知 アプリ更新がマーチャント向けの挙動やワークフローを変える場合は、できるだけ早く各マーチャントに連絡する。疑問・最新情報は developer forum で。 7 技術者が押さえるべき5つのポイント 1. 新フィールドは無い。組み合わせが本質 スキーマは不変、破壊的変更も無い。 既存フィールドが新しい値の組み合わせを返す のがこの変更の核心。差分は「形」ではなく「中身」に出る。 2. deliveryGroups は複数前提で Checkout は複数の deliveryGroups を持ちうる。先頭グループだけを見る・単一前提で集計する実装は要修正。グループごとにループする。 3. 1 Order に配送＋受取が混在 同じ注文に SHIPPING と PICK_UP の fulfillment order が併存しうる。注文単位で配送方法を決め打ちしない。 4. 振り分けキーは delivery_method fulfillment order の delivery_method （ SHIPPING / PICK_UP ）を読んで、出荷連携・在庫・通知のルーティングを分岐させる。 5. 影響面は広い ── 全レイヤーで「単一配送前提」を総点検 記事タグは Admin GraphQL API / Storefront GraphQL API / Checkout UI / Functions / Customer Accounts / Admin Extensions に及ぶ。送料・税の計算、在庫引当、配送ステータス表示、顧客アカウントの注文表示、配送系 Function まで、 「注文に配送方法は 1 つ」という暗黙の仮定を持つ全箇所 を feature preview で実データ検証すること。 8 業務に活かせる3つのユースケース USE CASE 1 OMS / WMS 連携アプリの「混在注文ルーティング」改修 課題 自社の連携アプリが「1 注文 ＝ 1 配送方法」を前提に出荷指示を作っており、配送＋店舗受取が混在する注文で誤ルーティングや連携エラーが起きる恐れがある。 打ち手 feature preview の dev store で混在注文を再現し、fulfillment order ごとに delivery_method を読んで「倉庫出荷」と「店舗取り置き」を分岐させるようルーティングを改修。 効果 ロールアウト後のチェックアウトエラー・誤配送を未然に回避し、Action Required を期限内にクリア。 技術メモ 注文単位ではなく fulfillment order 単位でループ。 SHIPPING / PICK_UP の両値が同一注文に来る前提でテストケースを追加する。 USE CASE 2 Plus マーチャントの BOPIS 強化で客単価・CVR を上げる提案 課題 配送品と店舗受取品を 1 回の買い物で買いたい顧客が、別注文を強いられてカゴ落ち・買い回り低下を起こしている。 打ち手 Plus / Enterprise ストアでこの feature preview を有効化し、配送＋ローカルピックアップを 1 チェックアウトに統合。「大物は配送・すぐ要るものは店舗受取」を 1 注文で完結させる。 効果 1 決済で完結する UX により離脱を抑え、配送と受取の併用提案で客単価向上を狙える。 技術メモ 前提は配送とローカルピックアップの両方が有効なこと。テーマ／Checkout UI で配送方法の表示が崩れないか preview で確認する。 USE CASE 3 顧客アカウント／注文表示アプリの「複数フルフィルメント可視化」 課題 注文詳細やマイページで配送ステータスを「注文に 1 つ」前提で表示しており、配送分と受取分が混在すると進捗が正しく出ない。 打ち手 fulfillment order ごとに delivery_method と進捗を読み、「配送：追跡番号」「店舗受取：受取準備状況」を分けて表示するよう改修。 効果 顧客が 1 注文内の各商品の届き方を正しく把握でき、問い合わせ削減と体験向上につながる。 技術メモ Customer Accounts / Storefront GraphQL API のクエリを fulfillment order 単位に展開。配送・受取で異なる UI パーツを出し分ける。 9 提案で使える1行サマリ 「Plus / Enterprise 向けに、配送と店舗受取を 1 注文・1 決済 で混在できる新チェックアウト。 API のスキーマ変更は無いが、 同一注文に SHIPPING と PICK_UP が混在する 新しい組み合わせが来る。 今すぐ feature preview で delivery_method 前提の改修を済ませ、ロールアウト前にチェックアウトエラーと誤配送を潰す。」 source ： shopify.dev / changelog / ship-and-pickup-in-one-order-feature-preview generated 2026-05-24