目次
Shopifyは2026年11月5日、Order Routing Location Ruleのunstable版で、複数の出荷グループへ同じ拠点順位をまとめて返せるようにしたと告知しました。倉庫を店舗より優先するなど、同じ順位表をグループごとに繰り返している実装が対象です。まず従来の出力を保存し、共通順位を一件にまとめてもグループごとの最終順位が一致するか確認します。11月7日時点の公式資料に基づく検証手順です。 Shopify開発者向け変更履歴（2026年11月5日）
スポンサーリンク
共通化するのは順位表であり出荷グループは残る
出荷ルーティングでは、カートの商品をどの拠点から出荷するかの判断に順位を使います。一つのカートでも出荷グループが複数になる場合があります。既存のfulfillmentGroupLocationRankingAddは対象グループのハンドルを一つ受け取り、そのグループの拠点順位を返します。同じ順位表を十のグループに付ける場合、従来の出力では同じ拠点ハンドルと順位の組を十回並べます。
追加されたfulfillmentGroupsLocationRankingAddはグループのハンドルを配列で受け取り、一つの順位表をそれぞれに適用します。グループを統合して荷物を一つにしたり、在庫のない拠点を候補にしたりする指定ではありません。公式資料は同じ順位表を繰り返すとFunctionの出力サイズ上限に達し得ることを挙げています。出力が小さくなるかは、共有できる順位表の件数と例外の数を自分のデータで比べて判断します。 Shopify公式のOrder Routing Location Rule API資料
対象はベータで、公式資料ではShopify Plusのマーチャントが申請して利用できると案内されています。自作のカスタムアプリやルールを配備するにはPartnersプログラムへの登録も必要です。さらに複数グループ向け操作はunstable版の変更なので、ストアの利用資格と拡張機能が対象を使えることを別々に確認します。安定版への提供時期はここで前提にせず、検証環境で扱います。
入力にあるハンドルを使って最小の出力を作る
対象の実行ターゲットはcart.fulfillment-groups.location-rankings.generate.runです。入力クエリーでは、例えばfulfillmentGroupsからhandleとinventoryLocationHandlesを取得し、順位の決定に使う項目だけを足します。出力に使うグループと拠点のハンドルはShopifyが生成するため、実際の入力から読み取ります。管理画面に表示される拠点名をハンドルの代わりに返す構成にはしません。 Shopify公式のOrder Routing Location Rule API資料
次は架空の入力に対する出力例です。グループg-aとg-bで倉庫w-mainを先にし、店舗s-eastを次にするものとします。拠点の名前や在庫の設定は別に必要です。以下のはデータ形状を示す未実行例で、実際のハンドルを固定して使う設定ではありません。
{
"operations": [
{
"fulfillmentGroupsLocationRankingAdd": {
"fulfillmentGroupHandles": ["g-a", "g-b"],
"rankings": [
{ "locationHandle": "w-main", "rank": 0 },
{ "locationHandle": "s-east", "rank": 1 }
]
}
},
{
"fulfillmentGroupLocationRankingAdd": {
"fulfillmentGroupHandle": "g-b",
"rankings": [
{ "locationHandle": "s-east", "rank": 0 },
{ "locationHandle": "w-main", "rank": 1 }
]
}
}
]
}最初の操作は二つのグループへ共通順位を付け、二番目はg-bだけを店舗優先に変えます。Shopifyはoperationsの並び順で適用し、同じグループの同じ拠点に対する後の順位で先の順位を置き換えます。rankings内の並びは優先度を決めず、rankの値が順序を決めます。コードレビューでは、配列を並べ替えた箇所と、数値を変えた箇所を分けて見ます。 Shopify公式のOrder Routing Location Rule API資料
スポンサーリンク
一部だけ上書きすると残りの順位は引き継がれる
上の例で二番目の操作からw-mainを除くと、g-bのw-mainには最初のrank 0が残ります。s-eastだけをrank 0へ上げても、二拠点の順位は逆転せず、同順位になります。店舗を倉庫より優先する条件なら両方を指定します。グループの順位表全体を作り直す意図なら、そのグループに含まれる全拠点を後の操作に列挙します。
拠点の優先順位を共通にできても、取扱商品や配送先によって例外が多いなら、個別操作を残す方が読みやすい場合があります。例えば常温商品のグループは中央倉庫優先で揃えられても、温度帯の違いによって優先先が変わるグループまで同じ扱いにはできません。既存の実装で何を条件に優先順位を変えているかを洗い出し、同じ表を共有できる集合だけを選びます。例外の条件が重なる場合は、どちらの規則が優先するかを出力順で明示します。
入力の候補と最終結果を照合する
公式仕様では、共通順位にある拠点が特定のグループの候補に含まれない場合、そのグループでは拠点を飛ばします。また、どの操作でも順位付けされなかった候補は順位を付けた拠点の後ろになります。存在しないグループハンドルも無視されます。エラーが返らないケースがあるため、実行成功だけを合格にすると、入力の選び方が誤っていても見逃します。 Shopify公式のOrder Routing Location Rule API資料
例えばg-aに倉庫と店舗があり、g-bには店舗だけがある入力を用意します。共通順位が倉庫優先でも、g-bの候補にない倉庫は使われません。ここに第三の拠点が候補として加わる入力も試し、順位を付けなかった場合に既存の実装と並びが変わらないかを確かめます。第三の拠点へ意図した優先度を付けたい場合は、共通表か個別操作のどちらが責任を持つか決めてください。
別の試験では、意図的に入力にないグループハンドルを含めます。予想されるのはその指定が適用されないことです。実装の検証では、出力に現れたグループの一覧を入力と照合し、想定したグループを取りこぼしていないかを確認します。開発時の記録は、注文者の住所や連絡先を含めず、試験用のハンドルと候補の組だけで再現できるようにします。
スポンサーリンク
バイト数と出荷先を別々に比較する
移行前の関数で作った出力を保存し、同じ入力で新しい実装を実行します。比較する指標は、operationsの件数、JSONをUTF-8へ変換した際のバイト数、グループと拠点の組に適用される順位です。JSONの整形や空白だけで差が出ないよう、同じシリアライズ条件で測ります。これらは検証のための指標で、ローカルで測ったバイト数だけからサービス側の上限や処理速度を断定できません。
試験データは共通順位だけのカート、例外が一件あるカート、候補拠点が異なるカートに分けます。グループ数が増える入力では、同じ順位表の繰り返しがどれだけ減るかを測ります。逆に例外がほとんどのグループに必要な場合は、共通操作に加えて個別操作が増えます。出力が小さくても順位が変われば、同じ動作を維持する移行としては不合格です。
関数の結果が一致したら、検証ストアで実際に出荷先を確認します。順位は拠点選択の入力なので、関数のJSONだけで配送可否や最終的な割り当てが決まったと扱いません。例えば、同じ商品を複数拠点に用意した注文と、優先拠点に必要数がない注文を別に作ります。処理前の在庫、対象商品、配送先の条件、適用ルール、実際の割り当てを一組で記録すると、順位の計算と候補の違いを切り分けられます。
更新されない結果は入力とキャッシュを確認する
Shopifyはカートの行や配送先など配送に関わるデータが変わるとこの関数を実行し、同じデータで直近15分以内の結果があれば再利用すると説明しています。検証で順位が変わらない場合は、入力条件、適用された関数の版、再利用の可能性を順に確認します。ブラウザーを再読み込みしただけでサーバー側が新しい結果を計算したとは判断しません。 Shopify公式のOrder Routing Location Rule API資料
一方、スキーマで操作名が受け付けられない場合は、まず拡張機能が参照するAPI版と生成した型を確認します。ここでの複数形と単数形は別の操作で、グループを渡すフィールド名も異なります。古い型定義を迂回して出力だけを書き換えると、検証と実行の前提が揃いません。安定版を使う既存アプリでは個別操作の経路を維持し、unstable版を使える別環境で結果を比較します。
出荷グループが想定どおりに分かれない場合は、順位表を変える前に入力を調べます。入力に含まれるグループ数や候補が違えば、同じ関数でも出力が違います。標準のチェックアウトで検証を始め、管理画面の注文編集やPOSなどへ広げる場合は、公式の対応表と自社で使う操作を照らし合わせます。例えばPOSでは顧客へ配送する場合に限った対応なので、店頭で持ち帰る取引の結果まで一般化しません。
共通化を取り消せる単位で検証する
比較時には順位計算と出力形式の変更を分けます。まず旧実装と同じ順位を計算した上で、その結果を共通操作へまとめます。倉庫の優先ルールや店舗の在庫条件を同時に変更すると、割り当てが変わった原因を追いにくくなります。検証を止める場合に備え、元の個別操作を作るコードと、比較に使った拡張機能の版を保持します。
移行の記録には、どのグループが共通順位を使い、どの条件で個別の上書きを行うかを記します。共通順位の後に例外を適用すること、候補外の拠点を飛ばすこと、順位を付けない候補が後ろに残ることを試験データと一緒に保管します。安定版での採用を判断する段階では、配布先で使えるAPI版と契約条件を再確認し、同じ出荷試験を実行します。
参考資料
Shopify開発者向け変更履歴（2026年11月5日）
Shopify公式のOrder Routing Location Rule API資料
