目次
チェックアウト後の注文の編集は、2つの時間との競争です。お客様が部屋番号の入力ミスに気づくまでの時間と、倉庫管理システムがその注文をピッキングリストに載せるまでの時間です。チェックアウト後の編集が行われるまでの時間の中央値は、注文から4.6分です（Revize, 2026）。余裕がありそうですが、連携が整った3PLでは1分以内に注文が処理キューに入ることもあります。間に合わなければ、修正できたはずのミスが再配送、返品、返金につながります。
このガイドでは、フルフィルメント保留の仕組み、編集可能時間をピッキングの予定に合わせる方法、注文を保留すべき場合と通常どおり流すべき場合、そして配送のSLAを守る方法を説明します。3PLとの連携を担当する運用責任者と、設定を担う制作会社のエンジニア向けの記事です。
なぜ3PLとの時間競争が起きるのか
支払い済みの注文は数分で倉庫に届く一方、お客様はチェックアウトを終えたところで入力内容の確認から離れます。 この数分のずれが、避けられるはずのフルフィルメントミスを生みます。
1,000万件を超えるShopifyの注文のうち、約19件に1件（5.2%）がチェックアウト後に編集されています（Revize, 2026）。見過ごされがちな割合ですが、月間20,000件の注文があれば、変更を希望する注文は毎月約1,000件です。購入後の編集で最も多いのは配送先住所の変更で、編集された注文の30.2%を占めます（Revize, 2026）。住所変更は、配送ラベルが印刷された瞬間に手遅れになる編集でもあります。
フルフィルメントの仕組みが速いほど、この問題は深刻になります。夜間にまとめて注文データを出力するストアには、自然な猶予が数時間あります。リアルタイムで3PLと連携するストアでは、猶予は数秒です。倉庫へ速く注文を送れることは通常、運用上の利点です。しかしここでは、数クリックで済んだ修正が配送業者への配送差し止め依頼に変わります。
ヒント： 設定を始める前に、3PLへ2つ確認してください。Shopifyが送信した注文は、何分でWMSに表示されますか。また、注文を取り戻せる最後の時点はいつですか。この2つの答えで、使える編集可能時間が決まります。
Shopifyのフルフィルメント保留の仕組み
フルフィルメント保留は、注文がフルフィルメントへ進まないよう一時停止する状態です。3PLによる処理が始まる前の時間を確保できます。 注文は引き続き存在し、支払い済みのままShopify Adminにも表示されます。ただし、ピッキングの対象にはなりません。 早すぎるピッキングを防げるのは、下流システムがShopifyの保留を尊重するか、解除タグを待つ設定になっている場合だけです。
簡単に言えば、注意書きを貼って出荷準備エリアに置かれた荷物と、すでにトラックに積まれた荷物の違いです。どちらも「倉庫にある」荷物ですが、変更できるのは前者だけです。
Revizeのドキュメントでは、注文処理の段階で明確に選択します。docs.revize.app/setup/order-processingによると、次の2つのモードから選べます。
- Hold orders： 編集可能時間中は注文を保留し、編集が終了したらフルフィルメントに進めます。ドキュメントでは、3PLが早すぎるタイミングで注文をピッキングするのを防ぐための設定と説明されています。
- Skip hold： 注文は通常どおり各システムを流れます。代わりに、保留解除タグを使って連携を調整します。
システムが実際に対応する方法を選びます。Shopifyの保留、支払いを手動確定してPaidだけを取り込む方法、解除タグによる絞り込みです。Skip holdには下流システムとの連携が必要で、それだけではピッキングを止められません。
フルフィルメント環境に合う保留方法はどれか
| 方法 | 適した環境 | 確認する制約 |
|---|---|---|
| Shopifyのフルフィルメント保留 | フルフィルメントシステムがShopifyの保留を尊重する場合。 | 編集中は注文を保留し、期間終了時に解除します。保留を無視するシステムでは、早い段階でピッキングされる可能性があります。 |
| 支払いの手動確定 | システムがPaidの注文だけを取り込む場合。 | 編集中の支払いはAuthorizedのままです。期間終了時の確定により、Paidを待つシステムが注文を取り込めます。 |
解除タグ revize:order_released |
システムが解除タグを待てる場合。 | このタグが付いた注文だけを処理するよう設定します。 |
| 停止タグ | WMSやShopify Flowが処理開始時にタグを付ける場合。 | 注文編集の制限にそのタグを登録すると、残り時間があっても編集を即時終了できます。 |
| Until fulfillment | フルフィルメントの開始時刻を管理できる場合。 | ストア全体の設定では注文は保留されません。すべての締め切りモードで保留アクションを使えるわけではありません。 |
| 未払いの編集 | 編集による追加料金が未払いの場合。 | 精算まで保留しますが、代金引換の注文は例外です。Reverse Unpaid EditsはProの機能で、初期設定では無効です。 |
| ShipStationの遅延設定 | ドキュメントに記載された遅延設定を使う場合。 | 上限は120分で、この設定だけではそれより長い期間に対応できません。削除した商品が伝票に表示される場合は「Hide 0 quantity items」を有効にします。 |
環境ごとの設定は連携ドキュメントを参照してください。連携先として名前が掲載されていても、すべての導入環境が同じ保留・解除方法を使うとは限りません。テスト注文で設定した流れを確認してください。
ピッキング時間に合わせて編集可能時間を決める方法
編集可能時間は、余裕がありそうな長さではなく、3PLから注文を取り戻せる最後の時点を基準に決めます。 10分以内にピッキングする倉庫で24時間の編集可能時間を設けても、お客様に守れない約束をすることになります。
編集可能時間は保留とは別に設定します。docs.revize.app/setup/edit-windowによると、チェックアウト後にお客様が注文を編集できる時間を設定できます。一定の時間または任意の長さを選ぶほか、フルフィルメントまで編集を受け付ける設定や、ピッキング時間に合わせた締め切りの設定も可能です。
最後の選択肢は、多くの運用担当者が見落としがちです。倉庫が継続的ではなく決まった時間帯にまとめてピッキングするなら、その時間帯に合わせた締め切りは、注文ごとに一定時間を設けるより適しています。早朝の注文には長い編集可能時間を、締め切り直前の注文には実際に守れる短い時間を設けられます。平均時間を推測する必要もありません。
| 編集可能時間の設定 | お客様が編集できる期間 | 適している3PL | 推奨する組み合わせ |
|---|---|---|---|
| 一定時間 | すべての注文で同じ時間 | 1日を通して継続的にピッキングする | Hold orders |
| 任意の時間 | 自分で指定した時間 | ピッキングまでの待ち時間が既知で安定している | Hold orders |
| フルフィルメントまで | 注文がフルフィルメントされるまで | 自社で管理する単位でまとめてフルフィルメントする | Skip hold |
| 予定時刻で締め切り | 指定したピッキング時刻まで | 毎日またはシフトごとに決まった時間帯にピッキングする | Hold orders |
右端の列は運用上の提案であり、互換性の保証ではありません。ストア全体のUntil fulfillment設定は注文を保留しません。Proのルールエンジンでは対応する締め切りモードのみHold fulfillmentを使えますが、Until fulfilledモードはHold fulfillmentとTag ordersを無効にします。ルールドキュメントで、モードと解除方法を合わせて確認してください。
編集の80.6%は最初の1時間、90.4%は24時間以内に行われます（Revize, 2026）。この時間分布をピッキング締め切りと合わせて検討してください。長い保留が店舗に適していると証明する数字ではありません。
すべての注文を編集可能にすべきではない
編集を許可するかどうかはルールで決めるべきです。支払い後に変更すると問題が生じる注文もあります。 ギフトカード、受注生産品、当日配送に向けてすでに準備された商品などは、通常、編集対象から外すべきです。予約注文とサブスクリプション注文はRevizeで編集できるため、一律に禁止せず個別に判断してください。
Revizeでは、コードではなくタグで制御できます。docs.revize.app/setup/order-edit-restrictionsによると、注文タグと商品タグを使って特定の注文や商品の編集をブロックできます。アプリがタグを自動で読み取り、編集をブロックします。入力欄を空白にすると、すべての注文を編集できる点もドキュメントに記載されています。公開前に確認しておきましょう。
制作会社にとって、これは連携しやすい仕組みです。既存のタグ付け自動化で、すでにさまざまな理由から注文や商品にタグを付けているはずです。編集制限はそのタグを読み取るだけです。どのSKUを受注生産品として扱うかを商品担当者が変更しても、タグによる制限ならコードのデプロイは不要です。特定の配送先や注文金額に応じて保留するなど、注文ごとのポリシーが必要な場合は、Proのルールエンジンを利用できます。
編集可能時間と保留を一致させるべき理由
保留と編集可能時間は1つの約束を成り立たせるための設定です。お客様がまだ編集できると考えている間に保留を解除すると、問題が起きます。 お客様には編集完了の確認が表示されたのに、倉庫からは変更前の注文が出荷されるという、最も避けたい結果につながります。
編集で未払いの追加残額が発生した場合、支払いが完了するまで注文はPending Paymentsの下でフルフィルメント保留のままです。 Revizeのドキュメントには、Shopifyが残額の支払い完了を確認した後にのみフルフィルメント保留を解除すると明記されています。代金引換の注文は、ドキュメントに記載された例外です。Reverse Unpaid Editsを有効にすると、Revizeは設定した猶予期間の後に注文を最後の支払い済みの状態へ戻します。この機能はProで利用でき、初期設定では無効です。例外用に差し戻しを行わないタグも設定できます。詳細はdocs.revize.app/setup/reverse-unpaid-editsをご覧ください。
この順序が重要です。編集完了時点で保留を解除すると、追加分が支払われていない注文を出荷しかねません。残額の支払い確認後に解除してこそ、保留が役割を果たします。
大規模な運用でこの仕組みを使う理由は、その結果に表れています。誤った配送先住所48,742件が出荷前に見つかり（Revize, 2026）、購入後の編集の92.2%はサポート担当者を介さず、お客様自身が完了しています（Revize, 2026）。
制作会社向けの導入手順
次の順番で設定してください。各手順には、前の手順で得た数値が必要です。 最初に編集可能時間を決めてしまうと、倉庫の運用と矛盾する設定になりがちです。
- 実際のピッキングまでの時間を測ります。 通常の営業日のさまざまな時間にテスト注文を行い、注文作成からWMSに表示されるまでの時間を記録します。平均ではなく最短の測定値を使ってください。問題を起こすのは最も速いケースです。
- 3PLに注文を取り戻せる時点を確認します。 どの段階から注文をキャンセルできなくなるかを具体的に尋ねます。ピッキングの一斉開始まで変更できる場合も、個別のピッキング開始までの場合も、配送ラベルの作成までの場合もあります。
- 連携先システムのリリース条件を設定します。 選んだリリース条件を満たすまでWMSやミドルウェアが待機するように設定し、編集期間中はピッキングが始まらないことをテスト注文で確認します。
- 注文を取り戻せる時点から安全のための余裕を差し引き、編集可能時間を設定します。 ピッキングが11:00に始まるなら、10:30を締め切りにするのは妥当です。一律4時間という設定は適切ではありません。
- 公開前に除外対象へタグを付けます。 ギフトカード、受注生産品、当日配送のSKUなど、編集を禁止すると決めた対象に先にタグを付けます。そうすれば初日から制限が有効になります。
- 追加分が未払いのままになるケースを意図的にテストします。 注文金額が増える編集を開始し、支払いを途中でやめます。注文がPending Paymentsの下で保留されたままであることを確認します。ProでReverse Unpaid Editsを有効にした場合は、設定した猶予期間の後に最後の支払い済みの状態へ戻ることも確認します。
- 実際のテスト注文で一連の流れを確認します。 本番の注文に対して有効にする前に、1件の注文が保留、編集、保留解除、フルフィルメントへと進む様子を最後まで確認します。3PL連携の挙動はそれぞれ少しずつ異なります。自社の連携について確実に判断できるのは、実際のテスト注文の結果だけです。
手順7は省けません。保留に対するプラットフォームや連携ツールの挙動は、連携ごとに異なります。自社の構成について信頼できるのは、自社の環境で確認した結果だけです。
重要なポイント
大規模なチェックアウト後の注文の編集は、使いやすさ以前に時間の問題です。フルフィルメント保留は、その時間を確保する仕組みです。 編集可能時間と保留が一致していれば、編集は通常の業務として処理できます。一致していなければ、編集のたびにサポートチームが手作業で対処する例外が生じます。
運用責任者は、倉庫から注文を取り戻せる最後の時点を設定の基準にしてください。また、編集の80.6%が最初の1時間以内に行われること (Revize, 2026)も判断材料になります。長い編集可能時間は必要ありません。実際に守れる時間を設定することが大切です。
制作会社にとって、連携で設定する項目は少数です。注文処理のモード、編集可能時間、タグの組み合わせです。価値が出るのは設定画面の操作より、時間の測定とテストです。
今週は、過去30日間の住所変更に関する問い合わせを確認し、注文後1時間以内に届いた件数を数えてください。次に3件のテスト注文で、注文からWMSに届くまでの実際の時間を測ります。その結果に合う編集可能時間を1つ設定してください。お客様自身で注文を編集できるようにするなら、RevizeはShopify App Storeから利用できます。
よくある質問
Shopifyのフルフィルメント保留とは何ですか？
フルフィルメント保留は、管理画面に注文を残したまま、Shopifyでの出荷処理を一時停止する状態です。お客様による編集では、解除前に許可された変更を行う時間を確保します。連携先の動作は別途確認してください。注文データが取り込まれているだけでは、倉庫がピッキングを止めた証拠にはなりません。
すべての注文を保留すると、配送のSLAに影響しますか？
出荷処理が遅れる場合があります。配送SLAへの影響は、編集期限、解除スケジュール、ピッキングの締め切り次第です。次の一括ピッキング前に解除されれば、既存の予定に収まる場合もあります。解除時刻を指定すると編集終了後も待機が続くため、編集期間と同じ長さだと仮定せず、待機時間全体を測定してください。
チェックアウト後の編集可能時間は、どれくらいにすべきですか？
3PLから注文を取り戻せる間だけにし、1分も長くしないことです。 編集の80.6%はチェックアウト後1時間以内に行われるため（Revize, 2026）、短い時間でも実際の需要のほぼすべてをカバーできます。編集可能時間に関するドキュメントによると、Revizeでは一定の時間、任意の時間、フルフィルメントまで編集を受け付ける設定、ピッキング時刻に合わせた締め切りを利用できます。
フルフィルメント保留をすると、3PLには注文が見えなくなりますか？
3PL連携の仕組みによって異なるため、テスト注文で確認してください。 フルフィルメント可能な注文だけを取得し、保留中の注文はまったく見えない連携もあります。一方、注文データをすぐに同期し、保留状態を別に扱う連携もあります。本番の注文で保留を有効にする前に、最も優先して確認すべき点です。
「Hold orders」と「Skip hold」はどう違いますか？
Hold ordersはRevizeの初期設定の推奨モードで、編集中にShopifyのフルフィルメント保留を適用します。Proは不要です。Skip holdはShopifyの保留を適用しません。解除タグと併用する場合は、倉庫がrevize:order_releasedを受け取るまでピッキングしないよう設定してください。
一部の注文だけ編集を許可できますか？
はい。注文タグと商品タグで設定できます。 注文の編集制限に関するドキュメントによると、ブロックしたいタグを入力してShopifyで同じタグを付けると、アプリが自動で読み取ります。入力欄が空白だとすべての注文を編集できるため、公開後ではなく公開前に除外対象を設定してください。
お客様が注文を編集した後、追加分を支払わなかった場合はどうなりますか？
未払いの追加残高がある注文は、Pending Paymentsの状態でフルフィルメント保留が続きます。代金引換は文書化されている例外です。Proでは、初期設定でオフのReverse Unpaid Editsを有効にすると、設定した猶予期間後に最後の支払い済みの状態へ戻せます。解除には、未払い残高がないとShopifyが確認する必要があります。
時間を設定せず、フルフィルメントまで編集可能にすべきですか？
「フルフィルメントまで」は、出荷処理の時刻を管理でき、編集が閉じる動作をテスト済みの場合に使ってください。この設定では保留は作成されません。随時ピッキングする3PLでは編集できる時間が非常に短い場合があるため、実際の締め切りに合わせた期限と保留・解除の仕組みを使いましょう。
実際に編集される注文はどれくらいありますか？
1,000万件を超えるShopifyの注文に基づくと、約19件に1件、つまり5.2%です（Revize, 2026）。 住所変更は編集の30.2%を占め、最も多い種類です。注文数が少なければ無視できるように感じるかもしれません。しかし月間20,000件の注文があれば、変更を希望する注文は約1,000件です。そのうち住所変更は、ラベルの印刷後に修正できなくなるものです。
住所変更には本当に保留が必要ですか？
住所変更こそ、保留が最も必要な編集です。配送ラベルの印刷後では変更が間に合わないためです。 商品の交換や数量変更なら、後続の工程で調整できる場合があります。配送先住所ではそうはいきません。荷物にラベルが貼られ、配送業者へ引き渡す記録が作成されると、お客様による数クリックの修正では済まず、配送業者への配送差し止め依頼や全面的な再配送が必要になります。この手順について詳しくは、チェックアウト後に配送先住所を変更する方法をご覧ください。
実際の注文に影響を与えずにテストするには、どうすればよいですか？
実際の注文に設定を適用する前に、テスト注文で一連の流れを確認してください。 保留、Paidによる絞り込み、解除タグのいずれかが早すぎるピッキングを防ぐことを確かめます。合計額が増える編集を行い、未払い残高がある間は保留されることを確認します。代金引換はドキュメントに記載された例外です。ProでReverse Unpaid Editsを有効にする場合は、猶予期間と取り消しもテストします。その後、差額を支払い、解除と3PLに届く修正後の注文を確認してください。
設定の責任者は運用担当者と制作会社のどちらですか？
数値は運用担当者、連携の設定は制作会社が担当します。 注文を取り戻せる時点、ピッキングの予定、編集できないSKUの一覧は、ストアのチームだけが把握している運用上の事実です。制作会社が価値を発揮するのは、測定方法、タグ付けの自動化、一連の流れのテストです。役割を逆にすると、倉庫の実態ではなく推測に基づく編集可能時間になってしまいます。