目次
まず結論
3PLがShopify注文の作成と同時に取り込む場合、編集可能な時間を設けるだけでは作業を守れません。顧客がShopifyで注文を変更できても、倉庫では変更前の住所、SKU、数量に基づいてピッキングが始まっている可能性があります。Unfulfilledは「取り込まない」という意味ではありません。下流の作業フローが従うShopifyのフルフィルメント保留、決済の確定延期と支払い済みステータスによる制御、または解除タグを待つ取込ルールのいずれかを、実際の解除条件として設定する必要があります。
その制御期間は、意図的に短く設定してください。10 million+件のShopify注文では、編集までの時間の中央値は4.6分で、編集の80.6%は最初の1時間以内に行われました（Revize, 2026）。そのため、最初の1時間はカバー率を考える際の参考になります。ただし、すべての倉庫にとって1時間が最適だと示すデータではありません。
Shopify Plus、Advanced、Growを利用する事業者が実装時に確認すべきことは、「どのイベントが発生したら、この注文をピッキングできるようになるか」です。その答えをShopify、コネクター、倉庫の運用手順で明確にする必要があります。
ShopifyのUnfulfilledは倉庫の作業停止を意味しません
Shopifyは決済とフルフィルメントを別々に管理します。注文ステータスのドキュメントでは、Unfulfilledをフルフィルメント完了前の通常の状態と説明しています。一方、On holdは保留が解除されるまでフルフィルメントを止める状態です。
この違いが重要なのは、外部コネクターには独自の取込ルールがあるためです。注文作成を検知するもの、支払い済み注文を定期的に確認するもの、フルフィルメントステータスを読むもの、タグで絞り込むものがあります。Shopify AdminにUnfulfilledと表示されていても、コネクターがどのイベントを使うかは分かりません。コネクターがすでに出荷データやピッキング作業を作成していれば、後からShopifyの注文を変更しても間に合わない場合があります。
Shopifyのフルフィルメント保留は、Shopifyのフルフィルメント管理の中では、より強い制御です。Shopifyによると、保留中のフルフィルメントは解除されるまで実行できません。フルフィルメントの保留ガイドには、1つの注文に複数のロケーションでのフルフィルメント作業が含まれる場合も説明されています。注文全体の表示だけでなく、各フルフィルメント注文を確認してください。
それでも、「Shopifyでフルフィルメントを保留できる」ことを「当社の3PLが必ず待つ」と解釈してはいけません。保留中の注文を取り込み、独自の保留キューに入れるコネクターもあります。Shopifyの保留状態を取込条件に使わないコネクターもあります。注文が倉庫に届くまでの経路全体を文書化し、テストする必要があります。
制御すべき2つの時間
注文編集を導入する際には、2つの時間を管理します。導入がうまくいかないケースの多くは、最初の1つしか設定していません。
| 時間 | 開始 | 終了 | 運用担当者が確認すべきこと |
|---|---|---|---|
| 顧客の編集時間 | Shopifyが注文を作成したとき | Revizeが注文状況ページでの編集を終了したとき | 顧客が締め切り前に、許可された変更を同じShopify注文に送信できること |
| 倉庫の取込時間 | コネクターが対象注文を検知したとき | 最初のピッキング、在庫引当、ラベル作成、その他の倉庫処理が始まったとき | 顧客の編集時間が終了するまで、注文がピッキング可能にならないこと |
安全な順序はシンプルです。
顧客の編集が終了 → 解除条件が成立 → コネクターが注文を取り込む、または次の状態へ進める → ピッキングが始まる
解除条件が成立する前にコネクターの取込や倉庫処理が始まるなら、編集可能時間は画面上の約束にすぎません。顧客には編集ボタンが見えていても、その結果を確実に反映できる運用になっていません。
このため、「フルフィルメントまで」という設定も慎重に扱う必要があります。Revizeは、Shopifyが注文をフルフィルメント済みとするまで顧客向けポータルを開いておけます。ただし、Revizeの編集可能時間に関するドキュメントには、この設定では注文を保留しないと明記されています。制御するのは編集できる期間です。倉庫による取込や作業開始は止めません。
コネクターが実際に注文を取り込む条件を特定する
方法を選ぶ前に、3PLまたは連携の担当者に具体的な質問を1つしてください。Shopify注文が取込またはピッキングの対象になるのは、正確にはどの状態ですか？
Shopify注文の編集と3PLを連携させる運用では、次の3つが有用な答えです。
| 取込条件のモデル | 注文が守られる条件 | 解除イベント | テストすべき主な失敗 |
|---|---|---|---|
| 保留を尊重 | 対象のShopifyフルフィルメント注文がOn holdである間 |
編集終了時にRevizeが保留を解除する | コネクターが早期に取り込む、保留を無視する、または自社の保留キュー内で自動処理やユーザー操作による作業開始を許す |
| 支払い済み／承認済み | 決済がAuthorizedのままで、コネクターが承認済み注文をピッキング可能な状態に入れない間 |
編集終了後にRevizeが決済を確定し、コネクターが使う決済ステータスを変更する | コネクターがAuthorizedを出荷可能とみなす、または決済方法が想定した確定手順に対応していない |
| 取込時のタグ | 注文に必要な解除タグが付いていない間 | 編集終了時にRevizeがrevize:order_releasedを追加する |
コネクターが作成時に取り込む、後から付いたタグを再評価しない、またはタグを単なる参考情報として扱う |
この表の名称だけで方法を選ばないでください。実際に観測した動作に基づいて選びます。連携ページやShopify App Storeの掲載情報から2つの製品が接続できることは分かっても、利用中のアカウントでどのイベントが倉庫への取込を防ぐかまでは証明できません。
カバー率の計算：時間データから根拠のない最適値を作らない
Revizeの2026年の分析では、チェックアウト後に編集された注文は5.2%（約19件に1件）でした。編集までの時間の中央値は4.6分です。観測された編集のうち、80.6%は最初の1時間以内、90.4%は24時間以内に行われました。したがって、保留期間を1時間から24時間に延ばすと、編集のカバー率は9.8パーセンテージポイント増えます。これらの数値はRevizeのShopify注文編集に関する統計に基づきます。
役立つのは、この差です。
90.4% − 80.6% = 9.8 percentage points
これにより、編集された注文のうち、保留を長くすることで追加でカバーできる割合が分かります。ただし、期間を延ばす運用上の負担までは分かりません。頻繁に出荷の波を設けている倉庫なら、顧客の編集時間を長く取れるかもしれません。当日出荷で即時にピッキングする運用なら、短い保留が適する場合があります。判断には、配送会社の締め切り、決済承認のルール、バッチ処理、顧客への約束、解除時のコネクターの動作が関わります。
編集内容の内訳からも、変更前のデータを倉庫に渡す危険性が分かります。編集された注文の30.2%は配送先住所の変更、24.3%は注文全体のキャンセルでした。どちらかが倉庫に遅れて伝わると、荷物が変更前の住所へ送られたり、顧客がキャンセルした後にピッキングされたりします。顧客自身で編集できる場合、編集の92.2%は担当者を介さずに完了します（7.8%は担当者への対応が必要です）。この運用上の利点は、フルフィルメントが最終的な注文内容を待つ場合に成り立ちます。
時間データをカバー率の目安として使い、サービス上の約束とピッキングの締め切りに合う、最も短い期間を選んでください。どの事業者にも当てはまる最適な期間として提示しないでください。
提供中のRevizeの3つの方法
Revizeは、Shopifyの注文状況ページに顧客向けのセルフサービス編集ポータルを提供します。顧客はピッキング前に同じShopify注文を変更します。スタッフが注文を作り直したり、代わりの注文を作成したりする方法とは異なります。倉庫の作業を制御するのは、ポータル単体ではなく、次のいずれかの方法です。
方法1：編集可能時間中はフルフィルメントを保留する
RevizeでOrder Editing → Order processing → Hold ordersを選びます。編集中はRevizeがShopifyのフルフィルメントを保留し、編集可能時間が終了したら解除します。この提供中の動作は、顧客の編集中にShopify注文を保留する方法とフルフィルメントの同期に記載されています。
下流のシステムがShopifyの保留を尊重することを確認できた場合に、この方法を使います。「尊重する」とは、取込を待つことかもしれません。または、ピッキングできない保留状態で取り込み、解除後にだけ確実に次へ進めることかもしれません。どちらでも機能しますが、動作は同じではありません。取込テストで、実際にどちらになるかを確認してください。
注文が複数のロケーションに分かれる場合は、対象となるすべてのフルフィルメント注文を確認します。解除時には、コネクターが倉庫作業を作成する前に、最終的な住所、商品明細、数量、キャンセル状態を受け取っていることを確かめてください。
方法2：保留を使わず、revize:order_releasedで取込を制御する
RevizeでSkip holdを選び、解除タグを有効にします。次に、revize:order_releasedが付いた注文だけを受け入れるようコネクターを設定します。Revizeは編集が終了したときにこのタグを追加します。それまでは、Shopify内で注文が通常どおり進んでも、倉庫への取込対象にはしない必要があります。設定方法はRevizeの注文処理に記載されています。
この方法が機能するのは、ピッキング可能な最初のレコードを作成する前に、コネクターが「タグ付き注文だけを取り込む」設定を適用できる場合に限られます。取込後にタグをコピーしたり、メモとして表示したりするだけでは制御になりません。
注文作成後の状態変化を重点的にテストしてください。解除タグのない注文を作成し、下流に存在しないことを確認します。その後、Revizeがタグを追加したら、最終的な値を持つ注文がコネクターに1回だけ取り込まれることを確認します。作成時にしかタグを確認しないコネクターには、別の方法が必要です。
方法3：決済の確定を遅らせ、支払い済みステータスで制御する
財務ステータスで絞り込むコネクターでは、編集可能時間中は決済をAuthorizedに保ち、編集終了後に確定します。Revizeは、この手動での決済確定による連携方法をRevizeの連携ドキュメントで説明しています。倉庫のルールでは、承認済みの注文をピッキング可能なキューに入れず、決済確定によってコネクターが期待する支払い済み状態になってから受け入れる必要があります。
決済方法が承認後の確定に対応していること、コネクターがAuthorizedを出荷可能な状態に対応付けないことを確認してください。決済の確定に失敗した注文が、知らないうちにピッキング可能になってはいけません。
複数の制御を重ねる場合は、それぞれの担当者と解除ルールを明確にしてください。そうしないと、一方のシステムでは解除されても、別のシステムでは保留されたままになることがあります。
WMSの作業開始タグは補助策であり、取込制御ではありません
WMSは作業開始時にpickedやwms:processingなどのタグを追加できます。Revizeはそのタグを監視し、残り時間があっても顧客の編集を直ちに終了できます。これにより、商品の取扱いが始まった後に顧客が編集することを防げます。
ただし、早期の取込は防げません。作業開始タグが付く時点で、注文はすでに倉庫にあります。主となる解除方法と併用する、編集を早期終了するための補助策として扱ってください。解除タグが答えるのは「倉庫はいつこの注文を受け取ってよいか」です。作業開始タグが答えるのは「倉庫で作業が始まったため、顧客の編集を今すぐ終了すべきか」です。Revizeの編集可能時間ガイドに、この動作の違いが記載されています。
Mintsoft：Mintsoftが文書化しているコネクター設定を使う
Mintsoftは、Shopifyコネクターに関連する3つの制御を公開しています。選んだ解除方法に合う設定を行い、状態が正しく変わることを確認してください。
解除タグによる制御
コネクターのAdvanced設定にあるOnly Import With Tagは、設定したタグを含む注文だけを取り込みます。対象タグをrevize:order_releasedに設定します。この設定はMintsoftのコネクターガイドとShopify注文タグの概要に記載されています。複数のタグを設定する場合、Mintsoftはスペースを入れず、カンマで区切るよう指定しています。
Only Import With TagとImport Shopify Tags into Mintsoft?を混同しないでください。後者はタグをMintsoftにコピーする設定であり、取込対象を決める設定ではありません。注文作成後に解除タグを追加した場合、想定した同期で取り込まれるかをテストしてください。
コネクターの遅延
Order Import Delay (Minutes)は、Mintsoftが注文を取込対象として検討するまで待つ時間を設定します。この設定は、コネクターの取込同期の頻度とともに動作します。固定の編集可能時間に取込を合わせることはできますが、イベントによる解除ではなく、時間に基づく猶予です。
この猶予に頼る前にUse Webhooks?を確認してください。Mintsoftによると、Webhooksを有効にすると設定した注文の遅延は無視され、注文が適切なステータスに達するとすぐに取り込まれます。遅延を設定していてもWebhooksが有効なら、保護された編集時間にはなりません。
支払い済みステータスによる制御
Mintsoftによると、Shopify連携では初期設定で支払い済み注文を取り込みます。複数の決済ステータスに関するガイドでは、ほかのステータスも追加できます。編集可能時間中の制御として意図的にAuthorizedを使うなら、Mintsoftが受け入れるステータスにauthorizedを追加してはいけません。追加すると制御が外れ、決済確定前に注文が倉庫へ渡る可能性があります。
タグによる絞り込みは連携全体に適用され、特定の決済ステータスだけには適用されません。どの条件を正式な判断基準とするかを文書化してください。
ShipStation：遅延、ステータスの対応付け、保留の動作
ShipStationは、Shopify Integration Guideで別のShopify向け設定を公開しています。
注文の最低経過時間
Minimum order age in minutes before order importsには0～120分を設定できます。0を入力すると遅延はありません。空欄のままにすると初期値は1分です。これを時間による猶予として使う場合は、編集可能時間の設計に合わせて明示的に設定し、実際の取込時刻を確認してください。空欄のままで、以前設定した長い時間が引き継がれると考えないでください。
承認済みと一部支払い済みの対応付け
決済の確定を遅らせる場合は、Map “authorized” to Awaiting Paymentを有効にします。ShipStationによると、この設定がない場合、Shopifyの承認済み注文はAwaiting Shipmentに取り込まれます。一部支払い済みの注文もピッキングできない状態に保つ必要がある場合は、Map “partially_paid” to Awaiting Paymentも有効にします。その後、Shopifyで注文が支払い済みになると、次回以降の更新で出荷に向けた状態へ進むはずです。アカウントのルールを有効にした状態で、この変化を確認してください。
Shopifyの保留状態の対応付けと数量ゼロの商品明細
ShipStationは、ShopifyのOn holdをShipStationのOn holdに対応付けると説明しています。これはステータスの対応付けであり、ピッキングの作業フロー全体をテストする代わりにはなりません。Revizeが保留を解除する前に、自動化ルール、ユーザー操作、ラベル作成によって注文が実際の処理へ進まないことを確認してください。
ShipStationによると、保留中に取り込まれた注文は、Awaiting Shipmentへ進むまで商品の数量がゼロと表示される場合もあります。数量、重量、小計、合計を使うルールを確認してください。梱包書類では数量ゼロの商品を非表示にし、その後、ピッキングリストと梱包明細書で最終的な数量を確認します。
ストア全体で有効にする前に、4つの取込テストを行う
顧客向けポータルやShopify Adminだけを確認して終わらせないでください。4つの異なるテスト注文を使い、コネクターと倉庫のキューを調べます。各注文について、注文作成、編集完了、Revizeによる解除、コネクターによる取込、最初の倉庫処理イベントを記録してください。合格条件はShopify上のステータス表示ではなく、下流の状態で判断します。
| テスト | 解除前の操作 | 合格条件 |
|---|---|---|
| 1. 基本動作と時間 | 注文を作成し、編集しない | 制御が有効な間はピッキングできない。解除後、想定した最終状態の注文が1回だけ取り込まれるか、次の状態へ進む |
| 2. 配送先住所の編集 | 注文状況ページで配送先住所を変更する | 変更前の住所を使う倉庫作業がない。解除後の注文と配送書類に変更後の住所が使われる |
| 3. 商品または数量の編集 | 許可されている場合の削除も含め、バリエーションまたは数量を変更する | ピッキング可能な注文に最終的なSKUと数量が反映される。古い明細や数量ゼロの明細がピッキング担当者への指示にならない |
| 4. 注文全体のキャンセル | 解除前にキャンセルする | 注文が出荷可能な状態にならず、下流に有効なピッキング作業やラベルが残らない |
住所のテストでは、整形されたラベルだけでなく、住所の各項目を比較してください。このチェックアウト後にShopify注文の配送先住所を変更するガイドでは、顧客側の課題を説明しています。商品明細の変更では、コネクターの画面に加えてピッキング書類も確認します。キャンセルでは、通常の同期が実行された後に、Shopifyの注文IDで下流システムを検索してください。
実際の自動化ルールを有効にし、管理された倉庫ユーザーを使ってテストします。対象を広げる前に、関連するロケーションと決済方法ごとに4つのケースを繰り返してください。
このページで扱わないこと
これはスタッフや管理者向けの注文編集機能のガイドではありません。ここで扱うRevizeの提供中の機能は、注文状況ページで顧客自身が注文を編集するものです。スタッフ／管理者向けエディターは今後の開発予定に含まれています。
顧客向けポータルが倉庫の作業を止めると主張するものでもありません。編集期間を守るのは、保留、決済ステータス、コネクターの絞り込みです。顧客向けの設定については、顧客がShopify注文を編集できるようにする方法をご覧ください。
Until fulfillmentで注文が保留されると主張するものでもありません。これはShopifyでフルフィルメントが完了するまで編集を可能にする設定で、Revizeは保留を適用しないと明記しています。
Shopify標準の注文編集機能の制限を理解するための代わりでもありません。それぞれの仕組みは別です。
コネクターの互換性一覧でもありません。ここで説明したコネクター設定は、MintsoftとShipStationがそれぞれのドキュメントで公開しているものに限ります。掲載情報は設定を始める手がかりであり、利用中の倉庫が待機する証拠ではありません。
最後に、Shopify FlowのHold fulfillment orderアクションはフルフィルメントの状態を変更します。顧客向けポータルではなく、購入者が注文を編集できるようにもなりません。運用フローの一部にはできますが、注文状況ページでの編集体験の代わりにはなりません。
よくある質問
Shopify注文の編集フローでは、いつフルフィルメントを保留すればよいですか？
顧客が編集した後ではなく、注文が作成された時点で制御を適用します。コネクターがShopifyの保留を尊重するならRevizeの保留方法を使います。コネクターが支払い済みステータスで制御するなら解除まで決済を承認済みに保ちます。取込前にタグで絞り込めるなら、Skip holdとrevize:order_releasedを使います。その保護された期間に、顧客が同じ注文を編集します。
ShopifyのUnfulfilledで3PLによる注文の取込を止められますか？
いいえ。UnfulfilledはShopify内のフルフィルメント状態を表します。3PLが取り込むかどうかは、コネクターの条件によって決まります。別のOn hold状態、支払い済みステータスのルール、コネクターの遅延、解除タグによる絞り込みのいずれかで運用上の制御を行い、選んだ方法をテストする必要があります。
Shopifyで3PL向け注文を保留すれば、倉庫に渡らないと保証されますか？
いいえ。Shopifyは、自社の保留によってShopify内のフルフィルメントが止まると説明しています。ただし、外部コネクターは注文を独自の保留キューに取り込む場合があり、保留状態を取込条件に使わない場合もあります。下流で注文が存在しないのか、存在してもピッキングできないのか、処理可能なのかを確認してください。
RevizeのUntil fulfillmentは注文を保留しますか？
いいえ。Shopifyが注文をフルフィルメント済みとするまで、顧客の編集を可能にする設定です。Revizeは、この設定では保留しないと明記しています。その間に注文をピッキングさせない必要があるなら、別の倉庫向けの制御を使ってください。
WMSのpickedタグを解除条件に使えますか？
いいえ。pickedやwms:processingのタグは、倉庫の作業が始まったときに付けられます。Revizeが直ちに編集を終了するための作業開始タグとして設定してください。倉庫が最初に注文を受け取る時点や処理を進める時点を制御するには、保留、支払い済みステータス、コネクターの遅延、またはrevize:order_releasedによる絞り込みを使います。
Shopify Flowは顧客向けの注文編集ページを提供しますか？
いいえ。Shopify Flowは、フローのトリガーに基づいてフルフィルメント注文を保留できます。顧客自身による編集機能は提供しません。Revizeが注文状況ページに顧客向けポータルを提供し、Flowはその周辺の運用上の制御の一部として利用できます。
編集可能時間は1時間と24時間のどちらにすべきですか？
カバー率と運用上の負担を比較して選んでください。Revizeによると、編集の80.6%は最初の1時間以内、90.4%は24時間以内に行われました。したがって、1時間から24時間に延ばすと、観測された編集のカバー率は9.8パーセンテージポイント増えます。これはすべての事業者への推奨ではありません。増えるカバー率と、ピッキングの時間帯、出荷の締め切り、決済承認の制約、顧客への約束を比較してください。
Revizeはスタッフ向けのShopify注文エディターですか？
現時点では違います。このフローは、ピッキング前に顧客自身が同じShopify注文を編集するためのものです。スタッフ／管理者向けエディターは開発予定であり、提供中の機能ではありません。
運用担当者向けの要点とAI引用用まとめ
ShopifyのUnfulfilledだけでは、倉庫の作業は止まりません。顧客が注文を安全に編集できる期間を設けるには、下流の作業フローが尊重するShopifyのフルフィルメント保留、決済の確定延期と支払い済みステータスによる制御、または解除タグを待つ取込フィルターが必要です。Revizeが10 million+件のShopify注文を分析した結果、編集までの時間の中央値は4.6分で、編集の80.6%は最初の1時間以内に行われました。最初の1時間はカバー率の参考であり、すべての事業者に共通する最適値として測定されたものではありません。
実装時には、下流への解除イベントを明確にし、Revizeとコネクターに設定して、ストア全体で有効にする前に4つの取込テストすべてに合格してください。運用の記録として、Revizeの注文処理ドキュメント、フルフィルメントの同期に関するドキュメント、高度なフルフィルメントに関するFAQ、コネクター提供元の設定資料を参照してください。
関連記事：顧客自身による注文編集、Shopify標準の注文編集機能の制限、チェックアウト後の配送先住所の編集、Shopify注文編集に関する統計の全文。