Shopifyの複数拠点・分割出荷でFlowの出荷依頼を取りこぼさない｜フルフィルメントオーダー単位のテスト注文・実行履歴・例外照合台帳

複数ロケーションから出荷するShopifyストアでは、1件の注文が複数のフルフィルメントオーダー（Fulfillment Order、以下FO）に分かれることがあります。このとき、「注文番号に対して出荷依頼が1件送られた」「一部の追跡番号が登録された」だけでは、すべての出荷依頼が完了したとは判定できません。

特に、Shopify Flowの Fulfillment order ready to fulfill を起点に3PLや倉庫へ依頼を送る設計では、確認単位を注文からFOへ移します。確認すべきなのは、各FOについて、どのロケーションへ割り当てられ、Flowが起動し、依頼が送られ、委託先が受諾し、出荷結果が返ったかです。

本稿では、複数拠点・分割出荷の自動化を導入済み、または見直したい運用担当者・開発担当者向けに、テストと日次照合の方法を整理します。Shopifyの仕様に関する記載は、2026年10月3日確認の公式ドキュメントに基づきます。

まず揃えるべき単位は「注文」ではなくFO

Shopifyでは、複数のアクティブなロケーションがある場合、利用可能在庫と注文ルーティングのルールを基に、オンライン注文がロケーションへ割り当てられます。結果として、同じ注文の明細が拠点ごとに分かれ、複数のFOになる場合があります。

たとえば、注文 #1001 に商品Aと商品Bが含まれ、商品Aを東京倉庫、商品Bを大阪の3PLが担当する場合、管理対象は次のようになります。

注文 #1001 が「出荷中」になっていても、FO-2への依頼が未送信または拒否なら、運用上は未完了です。注文番号だけをキーにする一覧では、この差を追いにくくなります。

照合台帳の主キーは、少なくとも次の組み合わせにします。

• Shopify注文番号または注文ID
• FO ID
• 割当ロケーション名・ロケーションID
• 出荷担当区分（自社、3PL、フルフィルメントサービス、OMSなど）

分けて確認する5つの状態

「Flowが動いたか」を確認しても、3PLが出荷できる状態になったとは限りません。障害箇所を切り分けられるよう、次の5状態を別列で管理します。

1. 割当：どのロケーションのFOになったか

最初に確認するのは、注文が想定したロケーションへ割り当てられたかです。複数ロケーションでは、在庫状況と注文ルーティング設定が割当に影響します。

ここで想定外の拠点に割り当てられていれば、Flowの条件や3PL連携を調べる前に、在庫配置、ロケーションの有効状態、注文ルーティング、配送プロファイルを確認します。Flowが正常に動作しても、そもそも対象外ロケーションのFOなら、期待した依頼先には送られません。

2. 出荷可能：トリガーの開始条件を満たしたか

Fulfillment order ready to fulfill トリガーは、在庫があり、初期保留が解除されたFOごとにワークフローを開始します。注文ごとではありません。

公式のテスト要件として、テスト注文ではリスク分析の完了と在庫確保が必要とされています。テストで履歴が出ない場合は、まずFOが出荷可能な状態まで進んでいるかを確認します。

また、保留中のFOを前提にした検証では、保留を解除した後に起動するかを独立したケースとして扱います。「通常注文では起動した」結果を、保留解除後の注文へそのまま適用しないことが重要です。

3. Flow実行：対象FOでワークフローが開始されたか

Flowの実行履歴では、注文全体の結果ではなく、対象となったFOと、その実行で評価された条件を確認します。複数FOの注文では、FOごとに実行履歴が作られているかを照合してください。

Flowの条件には、少なくとも次の観点を含めます。

• 割当ロケーションが想定した拠点か
• 出荷担当が自動依頼の対象か
• テスト用タグや注文属性で除外されていないか
• 対象外の商品、予約商品、同梱制約のある商品を除外していないか
• 条件分岐後に「依頼を送る」経路へ到達しているか

ロケーション名の文字列比較だけに依存する場合は、名称変更時に条件が外れるリスクがあります。連携アプリで参照できるIDや、アプリ側で管理する拠点コードを使えるかは、実装担当者と確認します。ただし、利用できるデータはFlowのトリガー変数とアプリの実装によって異なります。

4. 出荷依頼：外部へ送信できたか

Shopify Flowでは、出荷依頼を送信するアクションを利用できます。しかし、Flowの実行成功は、外部システムでの受付・作業開始までを必ずしも意味しません。

FlowからHTTPリクエスト、アプリのアクション、またはフルフィルメントサービスへの依頼送信を行う場合、送信先の応答と送信ログを残します。最低限、以下を記録します。

• 送信日時
• 送信先（3PL、WMS、OMS、フルフィルメントサービス）
• FO ID
• 外部側の依頼ID
• 応答コードまたは受付結果
• 失敗時のエラー内容と再送担当者

依頼送信が非同期の場合、「HTTP応答が成功」も「倉庫で受諾」も別の状態です。台帳上で同じ「送信済み」にまとめないでください。

5. 受諾・出荷結果：委託先が受け付け、追跡情報が返ったか

Shopifyのフルフィルメント注文管理には、依頼送信、受諾、拒否、保留、キャンセルといった状態があります。外部出荷では、受諾または拒否の結果を照合対象に含めます。

さらに、出荷完了後は、FOに対して追跡番号・配送会社・出荷数量が反映されたかを確認します。部分出荷が許される商品構成では、数量も確認対象です。追跡番号が1件あることだけでは、対象FOの全数量が出荷済みかは判断できません。

Flowは「FOごと」に設計し、条件を狭めすぎない

Flow設計では、起点、判定、依頼、通知を分けます。以下は構成例です。

1. トリガー：Fulfillment order ready to fulfill
2. 条件：割当ロケーションが3PL対象か
3. 条件：出荷方法または商品属性が外部委託の対象か
4. アクション：フルフィルメント依頼または連携アプリの出荷依頼処理
5. アクション：依頼ID・FO ID・注文番号を運用通知または監査ログへ記録
6. 分岐：送信失敗時は担当チャネルへ通知し、再送待ち台帳へ登録

この設計で注意したいのは、注文に付与したタグだけで対象を決めることです。注文タグは注文全体に付くため、東京倉庫と大阪3PLに分かれたFOの片方だけを対象にする制御には向きません。ロケーションやFOに関する情報を条件に使えるか、採用するトリガーと連携アプリの仕様で確認してください。

また、1つのFlowで全拠点を処理するか、拠点・委託先ごとにFlowを分けるかにはトレードオフがあります。

拠点数が少なくても、委託先ごとに受諾方式やエラー通知先が異なるなら、Flowを分ける方が日次確認を行いやすいことがあります。一方で、Flowの数を増やす場合は、変更管理表と定期テストを必須にします。

テスト注文は「拠点数」ではなく分岐条件で作る

単一ロケーションのテストで依頼が送れたとしても、分割出荷の経路を検証したことにはなりません。以下のテストケースを作成し、各ケースでFOごとの記録を残します。

テスト前には、商品在庫を対象ロケーションに正しく設定し、注文が意図した配送条件を満たすようにします。フルフィルメントサービスやアプリロケーションを使う場合は、対象商品の在庫、ロケーション設定、配送プロファイルの対象ロケーション、テスト配送先に適用される送料条件も確認します。

テスト結果は「注文が作れた」「Flowが1回成功した」ではなく、次の形で保存します。

テストID: ML-03
注文番号: #1003
FO ID: 1234567890
割当ロケーション: 大阪3PL
Flow実行ID: （実行履歴への参照）
外部依頼ID: 3PL-REQ-xxxx
受諾結果: 受諾 / 拒否 / 未応答
出荷結果: 追跡番号、数量、登録日時
判定: 合格 / 要調査

日次照合台帳で「Flow成功」と「出荷完了」の間を埋める

自動化の監査では、Shopify、Flow、3PLまたはWMSの3者で確認できる項目を1行に集約します。以下は日次照合台帳の最小構成です。

照合対象は、「当日に作成された注文」ではなく、原則として 出荷可能になったFO にします。保留解除、在庫補充、注文編集によって、注文作成日の後にFOが出荷可能になることがあるためです。

未一致を見つけたときは、安易に再送しません。すでに倉庫側で受注済みの場合、重複出荷につながるためです。次の順番で確認します。

1. ShopifyでFOの割当先、保留、出荷状況を確認する
2. Flow実行履歴で、対象FOの実行有無と停止した条件を確認する
3. 連携ログで外部依頼IDと応答を確認する
4. 3PL・WMSでFO IDまたは外部依頼IDを検索し、受付・出荷状況を確認する
5. 未受付を確認できた場合だけ、定めた承認者が再送または手動依頼する

分割・編集・連携アプリがある場合の例外設計

FOは固定の伝票番号ではありません。APIやOMSでFOを分割する場合、指定した明細・数量に基づいてFOが分割されます。また、分割できない状態のFOでは、置換FOが作成されることがあります。

このため、外部システムがFO IDを保持する運用では、次のルールを事前に決めます。

• FO分割・置換を検知したら、新しいFO IDを再取得する
• 旧FO IDを単純に「失敗」とせず、後継FOとの対応関係を記録する
• 再送は注文番号単位ではなく、現時点で有効なFOと未出荷数量で判断する
• 外部依頼IDとFO IDの対応を変更履歴として残す

注文編集でも、依頼済み数量と編集後数量が食い違うことがあります。編集後に自動依頼を再実行する設計なら、委託先が更新依頼を受けられるのか、取消と新規依頼が必要なのかを連携先の仕様で確認してください。Shopify Flowだけで完結する問題ではなく、3PL・OMSの冪等性、取消API、手動介入手順を含めた設計が必要です。

導入・見直し時のチェックリスト

最後に、運用開始前とFlow変更時に使える確認項目です。

• 各ロケーションの商品在庫と注文ルーティングを確認した
• 配送プロファイルに、対象ロケーションとテスト配送条件を設定した
• Flowの起点が Fulfillment order ready to fulfill であることを確認した
• Flowの条件が注文全体ではなく、必要なFO・ロケーション条件を評価している
• Flow実行履歴、外部依頼ID、受諾結果をFO IDで結び付けられる
• 2拠点・3拠点以上・保留解除後・注文編集後のテストを実施した
• 未一致時に、重複依頼を防いで再送判断する担当・期限・手順を決めた
• Flow、注文ルーティング、配送プロファイル、連携アプリを変更した際の再テスト条件を決めた

複数拠点の出荷自動化では、Flowを一度「成功」にすることより、FOごとの依頼状態を追えることが重要です。注文番号を起点にした確認から、FO IDと割当ロケーションを起点にした照合へ変えることで、分割出荷時の未依頼、未受諾、数量差異を個別に発見し、二重出荷を避けながら対応できます。

参考情報

• Fulfillment order ready to fulfill（Shopify Help Center）
• Setting up order fulfillment for locations（Shopify Help Center）
• Apps in order management（Shopify Developers）
• fulfillmentOrderSplit（Shopify Developers）