ECの「出荷してよい注文」を担当者判断で終わらせない｜出荷保留・解放台帳、例外キュー、Shopify Flowの設計手順

出荷保留は、不正検知や住所確認だけの機能ではありません。ERP、3PL、定期購入、購入後アプリ、在庫確認など、複数の仕組みが注文に関与する環境では、「誰が、何を確認したら、どこへ出荷指示を渡してよいか」を固定するための統制点になります。

重要なのは、保留を付けること自体ではなく、出荷解放の判断を記録可能な業務状態にすることです。担当者のチャット返信や口頭判断だけで解除すると、確認根拁、解除日時、3PLへの送信成否を後から追えません。

本稿では、出荷可否を HOLD、READY、RELEASED として扱い、例外キューと台帳を設計する方法を説明します。Shopifyでは、保留が注文全体ではなくフルフィルメント単位で存在する点を前提にします。

確認時点について：調査資料には「2026年9月3日確認」とありますが、本稿の作成時点では将来日付です。そのため、Shopifyの画面、利用可能なFlowアクション、連携アプリの挙動は、実装前に末尾のShopify公式ヘルプで再確認してください。料金・法令・統計は本稿では扱いません。

出荷可否を「注文の属性」ではなく「出荷単位の状態」として定義する

最初に決めるべきは、「保留中」「出荷可能」という言葉の意味です。ここが曖昧なままタグやスプレッドシートを増やすと、同じ注文に対して異なる担当者が異なる結論を持つ状態になります。

実務では、少なくとも次の3状態を分けます。

この定義で注意したいのは、READY と RELEASED を一つにしないことです。担当者が確認を終えたことと、3PLまたはWMSが出荷対象として受信したことは別の出来事です。CSV取込、API、Webhookのいずれでも、送信失敗や再試行、重複送信は起こり得ます。READY を「人の判断」、RELEASED を「連携結果を確認した状態」と区別すると、問題の切り分け先が明確になります。

また、状態を管理する単位は注文番号だけに固定しません。分割出荷、複数ロケーション、倉庫別の出荷では、同じ注文内でも一方は出荷可能で、他方は保留ということがあります。Shopify公式ヘルプでも、保留はフルフィルメントに対して設定され、複数フルフィルメントを持つ注文では注文全体の表示が個々の保留状況をそのまま示さない場合があると案内されています。

したがって、台帳の主キーは次のように設計します。

注文番号 + フルフィルメント注文ID（または倉庫・出荷グループID）

カートやWMSでフルフィルメント注文IDを取得できない場合でも、少なくとも「注文番号＋出荷元ロケーション」「注文番号＋分割出荷番号」のように、出荷指示を分ける単位で行を作ります。

保留理由ごとに、解除条件・権限・期限を先に決める

保留理由を「確認中」の一語にまとめると、担当者は何を確認すれば解除できるか判断できません。保留には理由コードを付け、理由ごとに解除条件を定義します。

以下は、台帳へ登録するための設計例です。これは特定の審査基準や期限を推奨するものではなく、自社の商材、配送リードタイム、契約している3PLの締め時刻に合わせて決めるための骨組みです。

保留理由を複数持てるようにすることも大切です。たとえば住所確認が終わっても、在庫確認が残っていれば出荷は解放できません。解除時には「自分が担当する理由を解決した」ことと、「この出荷単位に残る保留理由がない」ことを分けて確認します。

出荷解放台帳は「正本」と「作業キュー」を分けて作る

台帳はスプレッドシートでも、ERPのカスタム項目でも、チケットシステムでも構いません。ただし、すべてを一つの一覧だけで済ませようとすると、履歴が消えるか、現場の処理速度が落ちます。

おすすめは、出荷可否の正本と、担当者が見る例外キューを役割分担させることです。

正本に残す項目

正本は、後から「なぜ出荷されたか」「なぜ送られなかったか」を確認する記録です。上書きではなく、更新日時と更新者が追える場所に置きます。

• 注文番号
• フルフィルメント注文ID、または出荷グループを識別するID
• 出荷元ロケーション・倉庫
• 現在の出荷状態（HOLD／READY／RELEASED）
• 保留理由コード（複数可）
• 保留を設定した日時・設定元（手動、Flow、ERP、3PLなど）
• 判定に使った根拠への参照先
• 解除条件と、確認済み項目
• 解除者・解除日時
• 3PL／WMS送信ID、送信日時、送信結果
• 再送の有無と重複確認結果
• 最終更新日時

「根拠への参照先」は、詳細を台帳に複写する欄ではありません。不正審査の結果画面、顧客からの返信、在庫確認チケット、ERPの引当記録など、確認者が必要な権限で参照できる場所へのリンクまたはIDを記録します。

EC-CUBEの公開実装設計では、梱包注意、同梱物、出荷時確認事項を注文確定時に受注明細へコピーし、後から商品側を変更しても過去注文の値が変わらないようにする方針が示されています。この考え方は、カートを問わず有効です。出荷時に必要な商品別指示はマスタ参照だけにせず、その注文で確定した内容を受注明細または出荷指示データにスナップショットとして残す設計を検討してください。

例外キューに表示する項目

例外キューは、今日対応すべきものを並べる場所です。履歴を全部見せるのではなく、優先順位を決めるために絞ります。

• 出荷締め時刻までの残り時間
• 保留理由
• 保留開始からの経過時間
• 担当チーム・担当者
• 次のアクション
• 顧客連絡の要否
• 解除後に必要な連携処理
• 同じ出荷単位に残る未解決理由の数

ここでの優先順位は、注文金額だけで決めないほうが安全です。配送指定日、倉庫の締め時刻、欠品時の選択肢、顧客への連絡期限など、自社で約束している条件を加味します。保留を厳格にしすぎれば出荷遅延が増え、緩くしすぎれば未確認出荷のリスクが上がります。どの理由を自動保留にし、どの理由を人の確認に残すかは、このトレードオフを明文化して決めます。

Shopifyではフルフィルメント単位で保留を確認する

Shopifyの保留運用では、注文画面の表示だけで「この注文は止まっている」「もう出荷できる」と判定しないことが重要です。Shopify公式ヘルプによると、手動での保留と、アプリなどが設定するシステム保留が併存することがあります。また、複数のフルフィルメントがある注文では、注文全体のフルフィルメント状況と、個別フルフィルメントの保留状態が一致しない場合があります。

そのため、解除前のチェックを次の順番に固定します。

1. 対象の注文ではなく、対象のフルフィルメント注文・出荷ロケーションを特定する
2. その出荷単位に設定されている保留と保留理由を確認する
3. 台帳上の未解決理由、確認根拠、解除権限を確認する
4. 自分の担当理由が解決済みでも、他の保留が残っていないか確認する
5. 解放後、3PLまたはWMSへ渡す方式と送信結果の確認担当を確認する
6. 送信成功を確認してから台帳を RELEASED に更新する

Shopifyの注文タグは、検索や担当振り分けには便利です。しかし、タグだけを出荷可否の正本にするのは避けます。タグには更新履歴、フルフィルメント単位の表現、送信成否の記録が十分でないためです。

使い分けは次のようにします。

• Shopifyの保留：フルフィルメントを止める実行制御
• 注文タグ：一覧の検索、担当チームの識別、通知条件
• 出荷解放台帳：理由、根拠、権限、期限、連携結果の監査記録
• 3PL／WMSの出荷指示状態：倉庫が受信し作業できる状態の記録

Shopify Flowは保留の設定と滞留検知に使う

Shopify Flowの公式アクション「Hold fulfillment order」は、注文またはフルフィルメント注文を起点に保留を設定でき、保留理由、メモ、店舗への通知を設定できます。たとえば、不正リスク、住所確認、在庫確認といった条件ごとに、保留理由と解除担当を対応付ける設計に利用できます。

Flowの設計は、次のように小さく分けると保守しやすくなります。

1. 保留設定用ワークフロー

   • 起点：注文またはフルフィルメント注文に関するイベント
   • 条件：自社で定義した確認条件
   • 実行：該当するフルフィルメント注文を保留し、理由・メモを設定
   • 補助処理：担当用タグまたは通知を追加し、台帳作成処理へ渡す

2. 保留滞留の検知用ワークフロー

   • 起点：定時実行
   • 実行：Flowの「Get fulfillment order data」で status:ON_HOLD のフルフィルメント注文を取得
   • 判定：台帳の保留開始時刻、理由、期限と照合
   • 通知：期限が近い、または超過した対象を担当キューへ通知

3. 解放後の連携確認用ワークフローまたは照合処理

   • 対象：READY に更新された出荷単位
   • 確認：3PL・ERP・WMS側の受信IDまたは処理結果
   • 記録：成功時のみ RELEASED とし、失敗・不明時は INTEGRATION_ERROR として再保留または例外キューへ戻す

提供資料で確認できるShopify Flowの公式根拠は、保留設定アクションと、status:ON_HOLD による保留中フルフィルメント注文の取得です。Flowによる解除処理を組む場合は、利用中ストアで利用可能なアクションと、各アプリ・3PLが保留解除をどう受け取るかを、公開前のテスト注文で確認してください。解除できたことと、倉庫へ再送または送信されたことは別々に検証します。

3PL・ERP連携では「解放イベント」の重複を前提にする

保留解除後に起きやすい運用上の問題は、送信漏れだけではありません。Webhookの再配信、連携ジョブの再実行、担当者の手動再送によって、同一出荷を二重に送る可能性もあります。

このため、3PLやWMSへ渡す出荷指示には、注文番号だけでなく、出荷単位を一意に識別する外部参照IDを持たせます。連携先が受信済みIDを返せるなら、その値を台帳に保存します。CSV連携の場合も、ファイル名・出力日時だけではなく、各行に識別子を含め、取込結果を照合できるようにします。

解放処理の最小ルールは次のとおりです。

• HOLD の出荷単位は通常の出荷送信対象から除外する
• READY になった時点では、未送信なのか送信中なのかを明示する
• 送信前に、同じ外部参照IDがすでに受信済みではないか確認する
• 送信後は、成功・失敗・結果不明を分けて記録する
• 結果不明は、安易な再送ではなく3PL・WMS側の受信履歴を確認してから処理する

「連携が成功したら保留を解除する」のか、「確認完了で保留を解除してから連携する」のかは、利用中の接続方式で変わります。前者は倉庫への不要な送信を抑えやすい一方で、連携障害時に保留が残り続けます。後者は出荷準備を進めやすい一方で、解放済みなのに未送信という中間状態を必ず監視する必要があります。どちらを採る場合も、RELEASED を「保留が外れた」ではなく「定義した送信結果を確認した」と定義すると混乱を減らせます。

日次照合は「保留一覧」と「送信済み一覧」を突き合わせる

自動化を導入しても、日次照合をなくすのではなく、照合対象を例外に絞ります。担当者が毎日確認する一覧は、少なくとも次の4群に分けます。

1. 期限超過の HOLD：保留理由、担当、次アクションが存在するか
2. 締め時刻が近い HOLD：当日出荷の要否と責任者判断が記録されているか
3. READY のまま残る出荷単位：送信処理が未実行・失敗・結果不明ではないか
4. RELEASED だが倉庫側結果がない出荷単位：3PL／WMSで受信・出荷処理が確認できるか

照合時には、件数一致だけで完了にしません。注文全体で件数が合っていても、複数ロケーションの一部が保留中というケースは残り得ます。比較キーを「注文番号」だけにせず、フルフィルメント注文IDまたは出荷グループIDまで含めます。

運用開始前には、少なくとも以下のテストケースを用意してください。

• 一つの注文・一つの出荷元で保留から解放するケース
• 一つの注文を複数ロケーションから出荷し、一方だけ保留するケース
• 保留理由が複数あり、一つだけ解決するケース
• 解放後の3PL送信が失敗するケース
• 送信結果が不明で、再試行が必要になるケース
• 注文確定後に商品マスタの梱包注意や同梱物が変更されるケース

テストの合格条件は「Flowが動いた」ことではありません。保留中の出荷が倉庫へ渡らないこと、解除済みの出荷が一度だけ正しく渡ること、履歴から判断根拠を追えることを確認します。

導入時は全理由を自動化せず、責任境界から固定する

出荷保留の運用は、最初からすべてを自動化する必要はありません。むしろ、審査結果や住所確認のように人の判断が残る業務を無理に自動解除すると、例外時の責任所在が不明確になります。

最初の導入範囲は、次の順番が現実的です。

1. 出荷単位、状態、保留理由、解除権限を定義する
2. 台帳の必須項目と、RELEASED の定義を決める
3. 手動保留・手動解除でも台帳が更新される運用を定着させる
4. Shopify Flowで保留設定、保留中一覧、期限通知を補助する
5. 3PL・ERPとの送信結果照合を自動化する
6. テスト結果を基に、自動解放の対象を限定的に増やす

既存のERPや3PLが独自の出荷保留状態を持つ場合、すべての状態をShopifyへ同期させることが常に正解とは限りません。双方向同期は状態の競合や再試行時の複雑さを増やします。どのシステムが「出荷指示済み」の正本か、どのシステムが「倉庫で作業可能」の正本かを決め、他方には必要最小限の状態だけを反映します。

出荷保留管理の目的は、確認作業を増やすことではありません。保留理由、解除条件、送信結果を出荷単位でつなげ、確認未了の出荷と、確認済みなのに止まる出荷の両方を見つけられるようにすることです。まずは台帳の一行を見れば「今止めている理由」「次に動く人」「倉庫へ渡ったか」が分かる状態を目標にしてください。

参考情報

• Shopify Help Center：Marking your order as on hold
• Shopify Help Center：Hold fulfillment order
• Shopify Help Center：Get fulfillment order data
• EC-CUBE GitHub：［4.4］受注管理用メモ — 実装設計 · Issue #6821
• Shopify Community：Fulfillment Workflow