目次
事業機会があるのは、チェックアウトからフルフィルメントまでの間です。 チェックアウト後の注文の編集が行われる時間の中央値は、注文から4.6分後です。購入者が自分で操作できる場合、編集の92.2%はサポート担当者を介さずに完了します（Revize, 2026）。代理店は、この短い時間帯の業務を、顧客体験、フルフィルメント方針、自動化、レポートを含む継続サービスにできます。
このガイドでは、Plusを扱う代理店がサービス範囲を定め、ルールを設定し、Shopify Flowを連携し、段階的に導入して、継続的な運用管理を提案する方法を説明します。
代理店が注文の編集をサービス化すべき理由
購入後の注文の編集は、5分で終わるアプリのインストールではなく、注文業務を支えるサービスとして販売すべきです。 ソフトウェアの導入は短時間でも、代理店の価値は、どの変更を許可するか、いつまで許可するか、確定した注文をいつフルフィルメントへ渡すかを決めることにあります。
多くのPlus代理店はすでに、移行、チェックアウトの拡張、企業間取引（B2B）、Shopify Flow、倉庫連携をサービスとして提供しています。一方、購入者自身による注文の編集を、名称のある運用サービスとして販売している例はまだ少数です。そこで、チェックアウト後からピッキング・梱包前までの運用を担うという明確な立ち位置を取れます。
クライアントが購入するのはボタンではありません。次の4つの成果です。
- 変更依頼の問い合わせ削減。 対象となる購入者が日常的な編集を自分で完了できます。
- 管理された編集期限。 任意のタイマーではなく、倉庫の締め時刻に合わせます。
- 明確な金銭処理の方針。 増額、減額、キャンセル、返金、ストアクレジットの扱いを定めます。
- 管理された注文の引き渡し。 サードパーティ物流事業者（3PL）や倉庫管理システム（WMS）が、ピッキング可能な注文を受け取れるようにします。
運用上の考え方は明快です。編集可能な期間は、フルフィルメントとの取り決めです。 これをストアの表示設定として扱うと、購入者、サポート窓口、倉庫の間で認識が食い違います。
代理店のサービスに含めるもの
注文の編集をサービス化するには、成果物と受け入れテストを定めた4つの層が必要です。 この構造がなければ、倉庫、プロモーション、クライアントの方針が変わるたびに、対応範囲の定まらないトラブルシューティングになります。
| サービスの層 | 代理店の成果物 | クライアントの受け入れテスト |
|---|---|---|
| 現状調査 | 注文変更の需要とシステム構成図 | 主な編集依頼とフルフィルメントの締め時刻が文書化されている |
| ルール設計 | 編集権限、対象外の条件、期限、返金方針 | すべての注文区分に明確なルールがある |
| 自動化 | Flowワークフロー、通知、タグ、データ連携 | テストで編集した注文が適切な後続システムに届く |
| 運用 | 段階的な導入、監視、月次レビュー | 例外対応の担当者と手順が決まっている |
現状調査では、サポートへの依頼を運用方針に変えます。 過去30～90日間の住所、サイズ、数量、キャンセル、割引に関する依頼を確認します。「注文はどこにありますか？」という問い合わせは注文変更に含めないでください。配送状況の追跡は別の分類です。
ルール設計では、編集の対象を定めます。 顧客向けポータルでは特定の機能を表示でき、ルールエンジンでは注文タグ、顧客タグ、メタフィールド、金額、配送先、配送方法、B2Bの状態、サブスクリプションの状態、店舗受け取り、販売チャネル、曜日、時刻に応じて異なる扱いを設定できます。
自動化では、編集結果を各所へ届けます。 Shopify Flowは配電盤のように機能します。購入者の操作を起点に、ワークフローが最新の注文データをフルフィルメント、顧客向けの連絡、分析、例外対応の窓口へ振り分けます。
第1段階：需要を調べ、ルールを定める
まず5.2%の編集需要を捉え、クライアントの実際の注文区分に合わせて設計します。 Plusを利用するファッションストア、予約販売ブランド、複数倉庫を持つ家電販売事業者に、同じプラットフォームを使っているという理由だけで同じ権限を適用してはいけません。
サポートのタグ、定型文、抽出した会話から変更依頼の一覧を作ります。依頼された操作、チェックアウトからの経過分数、注文元、フルフィルメントの状態、金銭的な影響、スタッフが対応したかどうかを記録します。分類は具体的にしてください。
- 配送先住所の修正。
- バリエーションまたは商品の交換。
- 数量の増加または減少。
- 商品の削除または一部キャンセル。
- 注文全体のキャンセルと返金。
- 適用し忘れた割引。
- 配送方法の変更。
- 連絡先情報の修正。
次に、クライアントの制限対象となる注文区分を整理します。返品・交換不可の商品には、明細単位の制限が必要かもしれません。リスクの高い注文では、編集機能をすべて非表示にする場合があります。B2B注文では住所の修正を許可し、キャンセルを禁止することもできます。サブスクリプションの編集は、元のサブスクリプション契約を変更せず、現在の注文だけに適用する場合があります。
編集可能期間のドキュメントには、固定の期間、任意の長さ、指定時刻の締め切り、フルフィルメントまでの編集が記載されています。時間指定の期間は5分から48時間です。倉庫の業務から逆算して期間を決めてください。 注文の変更に業務上のコストがかかり始める時点を特定し、その前に編集を締め切ります。
Proのルールエンジンでは、12種類の照合条件と6種類の期限設定を利用できます。ルールは優先順位に従って実行され、最初に一致したものが適用されます。一致しない注文には、ストア全体の編集可能期間が適用されます。優先順位の一覧はファイアウォールのルールと同じように扱ってください。広い条件を上位に置くと、その下にある限定的なルールが適用されなくなることがあります。
注意： タグによる制限には完全一致が必要です。Shopify Flowが
high-riskを書き込み、制限側がhigh_riskを指定している場合、その注文は編集可能なままです。
第2・第3段階：設定と連携
自動化に進む前に、設定で3つの点を決めます。購入者が何を変更できるか、代金をどう処理するか、いつフルフィルメントを進められるかです。 方針が承認されたら、代理店は購入者向けの操作をクライアントの業務システムに接続できます。
案件が40～60%まで進んだ時点で、購入者自身による注文の編集エンジンをインストールし、承認済みの方針を設定します。本番環境で試行錯誤しないでください。合意済みの運用一覧に含まれる購入者の操作だけを有効にします。
金銭処理の流れを設定する
編集後の合計金額は、増える、減る、変わらないのいずれかです。そのため、画面には「今すぐ支払う」「返金」「確認」のいずれかが表示されます。増額分はShopifyのチェックアウトで支払い、減額分はマーチャントが設定した返金方針に従います。
財務部門とカスタマーサポート部門のために、次の決定を文書化します。
- 返金方針を選ぶ。 ストア全体で選べる設定は、返金しない、元の決済方法へ返金する、ストアクレジットとして返金する、の3つです。ストアクレジットによる返金はProプランの機能です。
- 増額となる編集をテストする。 支払い前に、追加で必要な正確な金額が購入者に表示されることを確認します。
- 減額となる編集をテストする。 返金先、会計記録、購入者への通知を確認します。
- 支払いを途中でやめた場合をテストする。 未払いの追加分が、決済済みの注文としてフルフィルメントに進まないようにします。
倉庫への引き渡しを守る
推奨される処理方法では、編集可能な期間中、注文のShopifyフルフィルメントを保留し、編集が締め切られた時点で解除します。フルフィルメントの保留は、荷物を「待機中」と記した場所に置くことに相当します。倉庫システムは、まだピッキングしてはいけません。
保留を無視するシステムもあります。その場合は、ドキュメントに記載された手動売上確定の代替手段を使うか、revize:order_releasedタグが付いた注文だけをピッキングするよう3PLを設定します。フルフィルメント同期ガイドには、指定時刻の保留解除と、ピッキング開始時にWMSまたはFlowが書き込む停止タグも記載されています。
現行のShopify Flowを連携する
Shopify Flowはトリガー、条件、アクションを使います。GraphQL Admin APIは、ストアのデータを読み取り、変更するためのShopifyの構造化されたバックエンドインターフェースです。クライアントのストアで特定のバージョンを固定する前に、テスト用ワークフローで現在のAdmin APIバージョンを確認してください。
Revizeが提供しているトリガーには、Order edited、Shipping address updated、Email address updated、Phone number updated、Delivery date updated、Order cancelled、Support ticket created、Tax invoice generatedがあります。商品の追加、交換、変更を個別に扱う専用トリガーは、まだ開発予定です。
本番運用では、次の手順を使います。
- 提供済みのトリガーのうち、最も具体的なものから始める。 住所変更のワークフローには、範囲の広いOrder editedではなく、Shipping address updatedを使います。
- 最新の注文データを取得する前に10秒待つ。 更新後の明細がすぐに取得できない場合があるため、ドキュメントに記載された連携手順ではWaitの後にGet Order Dataを使います。
- 現在の注文を照会する。
id:{{order.legacyResourceId}}を使い、取得件数を1件、並び順をUpdated atの降順に設定します。 - 業務上のアクションを実行する。 倉庫への通知、監査用タグの追加、修正後の注文のKlaviyoへの送信、クライアントのサポートシステムへの例外の振り分けなどを行います。
- 重複する連絡を抑える。 短時間に複数回編集すると複数のイベントが発生するため、必要に応じて購入者向けの連絡に5分間の抑制期間を設けます。
Shopifyは、Flowの実行が長さを定められない時間だけ遅れる可能性があると注意しています。Flowの通知だけでフルフィルメントを止めようとしてはいけません。 安全のためにプラットフォームの保留機能または解除タグの取り決めを使い、Flowは振り分けと状況把握に使います。
独自の検証環境を作る場合、Shopifyは注文の編集を3段階の手順として説明しています。orderEditBeginを実行し、orderEditSetQuantityなどの変更処理を行い、orderEditCommitで確定します。住所や連絡先の単純な更新にはorderUpdateを使います。システム間で送信されるイベントメッセージであるWebhookでも、orders/editedのデータを受け取り、独立した監査ログを記録できます。
第4段階：倉庫業務に支障を出さずに導入する
初日からすべてのPlus注文で有効にせず、3つの対象グループに分けて導入します。 社内スタッフ、管理された購入者グループ、対象となる注文全体の順に広げるのが安全です。
- 社内での検証：
staffタグが付いた購入者に対してTest Modeを有効にします。Shopifyの下書き注文を使い、同額での交換、増額となる編集、返金、キャンセル、在庫切れのバリエーション、配送地域をまたぐ住所変更を確認します。 - 限定した対象グループ： 1つの地域、ブランド、またはリスクの低いフルフィルメント経路で利用を開始します。少なくとも7日間、または倉庫業務の1サイクルが完了するまでの、いずれか長い期間にわたって運用します。
- 対象となる注文全体： イベントの記録、決済結果、保留解除の動作について、財務、カスタマーサポート、フルフィルメントの各部門が承認した後に拡大します。
テストの合格には、購入者の画面が成功を示すだけでなく、後続システムへの反映を確認する必要があります。Shopifyで編集後の注文を確認し、タイムラインとタグを調べ、差額を検証し、3PL、企業資源計画システム（ERP）、顧客向け連絡プラットフォームが受け取った内容を確かめます。
導入計画書には、元に戻す条件も含めます。たとえば、倉庫が保留中の注文をピッキングする、購入者への通知が重複する、古い明細データが使われる、未払いの追加分がピッキング待ちの一覧に表示される、といった場合です。対応としては、サービス全体を取り下げる代わりに、Test Modeへ戻す、1つの機能を無効にする、特定のルールの期限を短くするなどが考えられます。
住所変更のテストには、Shopifyの配送先住所変更ガイドにある、配送地域の変更や、フルフィルメント開始が近い注文などの業務上のケースを使ってください。
継続契約として提供する方法
最も有効な販売形態は、固定範囲の4段階の導入と、継続的な運用管理契約を分けることです。 単発の設定費用は導入作業に充て、継続契約ではプロモーション、倉庫のスケジュール、アプリ、クライアントの成長に注文方針を合わせ続けます。
| 契約形態 | 含まれる作業 | 適した請求単位 |
|---|---|---|
| 導入パッケージ | 現状調査、ルール設計、設定、テスト、トレーニング | 固定料金のプロジェクト |
| 運用管理 | ルールの更新、ワークフローの監視、月次レポート | 月額の継続契約 |
| 複数ストア向けプログラム | 複数のクライアントストアに共通する基準 | 基本料金とストア数に応じた料金 |
作業時間だけで価格を決めないでください。ストアフロント、フルフィルメント経路、注文区分、有効な編集機能、Flowワークフローの数と、レビューの頻度を基準にします。注文量が同程度でも、3つの市場と2つの倉庫を持つクライアントでは、1地域だけのストアより運用管理の作業が多くなります。
月額の継続契約には、次を含めます。
- 失敗した編集、サポートへ引き継がれた編集、未払いの編集の確認。
- 新商品発売、返品・交換不可の商品を扱うイベント、予約販売キャンペーンに合わせたルール変更。
- アプリやデータモデルの変更後のFlowの監視と修復。
- フルフィルメントに大きな変更があった後のテスト注文。
- 単なる合計値ではなく、対応事項を記した30日間の運用レポート。
- 編集可能な期間が倉庫での作業確定より前に終わることの四半期ごとの確認。
サービスの範囲を明確にしてください。 このサービスが管理するのは、フルフィルメント前の注文変更です。配送状況の追跡と配達後の返品は、並行して提供できる別の業務です。
代理店がサービスを評価する方法
30日ごとに、需要、購入者自身による完了、サポートへの引き継ぎ、フルフィルメントの例外、維持できた注文金額という5つの運用指標を報告します。 業務を減らしながら管理を維持できていることを示すためです。
まずクライアント自身の導入前の数値を確認します。自社データの分析では、編集された注文のうち配送先住所の変更が30.2%、キャンセルが24.3%でした（Revize, 2026）。こうした分類別の参考値はテストの優先順位付けに役立ちますが、クライアント固有の測定に代わるものではありません。
次を追跡します。
- 編集画面を開いた、対象となる注文の数。
- 購入者が完了した編集の操作別件数。
- サポートへ引き継がれた編集の数。
- 解除が遅れた注文、またはピッキング開始後に処理を止めた注文の数。
- 支払われた増額分、返金された減額分、交換に切り替わったキャンセルの数。
- 重複した通知、古いデータが使われたイベント、取り消された未払いの編集の数。
推定したサポート費用の削減額を、実測した人件費の削減額として示さないでください。クライアントが金銭的な成果を求める場合は、実際に回避できた問い合わせ件数に、クライアント自身の諸経費を含む対応単価を掛け、前提を文書化します。信頼できるレポートでは、観測した事象と試算した価値を区別します。
よくある質問
2026年にこのサービスを提供する前に代理店が解決しておくべき、導入と販売に関する10の質問に答えます。
購入後の注文の編集は、単発のプロジェクトですか、継続契約ですか？
固定範囲の導入プロジェクトとして始め、運用管理の継続契約に移行すべきです。 導入には現状調査、設定、連携テスト、スタッフのトレーニングを含めます。継続業務には、新しいプロモーション、倉庫の変更、ルールの保守、ワークフローの障害、月次レポートへの対応を含めます。インストールだけを販売すると、後の業務変更についてサービス範囲を定めないまま代理店が対応することになります。
どのShopifyクライアントに適していますか？
注文変更の問い合わせが繰り返し発生し、フルフィルメント前の編集可能な期間を管理できる、注文量の多いPlus、Advanced、Growのマーチャントが最も適しています。 複数の倉庫を持つストアや、編集のたびに問い合わせで対応する方法が負担になるほど注文量の多いブランドは、運用管理から大きな効果を得られます（Revizeは100件でも100,000件でも注文を処理できるよう設計されています）。クライアントには、カスタマーサポート、財務、フルフィルメントの各部門で、1つの文書化された編集方針に合意する意思も必要です。
購入者が編集できる期間はどのくらいにすべきですか？
倉庫が取り消しの難しいピッキング作業を始める前に、編集可能な期間を終えるべきです。 固定の選択肢は通常15分、30分、60分から始まり、任意の期間は5分から48時間に設定できます。一括処理を行う場合は、指定時刻の締め切りも使えます。適切な長さはクライアントの実際のフルフィルメント経路によって異なるため、テスト注文で確認してください。
すべてのクライアントストアで同じルールを使えますか？
いいえ。各ストアの商品、購入者、決済、フルフィルメントの方法に合わせたルールが必要です。 ファッションのクライアントはサイズ交換を許可しながら、返品・交換不可の商品の削除を禁止する場合があります。B2Bマーチャントは住所の修正を許可し、キャンセルを制限する場合があります。代理店は方針のひな形を再利用できますが、現状調査の一覧を完成させずに、本番用のルールをストア間でコピーしてはいけません。
Shopify Flowだけで、すべての注文を安全に保留できますか？
Flowはフルフィルメントに関するアクションを実行できますが、編集可能な期間の時間管理をFlowだけに任せるべきではありません。 Shopifyはワークフローを可能な限り早く実行するとしていますが、完了までの時間は保証していません。アプリのドキュメントに記載された保留または解除タグの仕組みを、フルフィルメントに関する主な取り決めとして使います。Flowは通知、監査用タグ、例外の振り分け、後続システムへのデータ送信に適しています。
購入者が追加料金を支払う必要がある場合はどうなりますか？
増額となる編集は、Shopifyのチェックアウトで追加金額が支払われるまで完了しません。 購入者には、確定前に正確な差額が表示されます。代理店は、支払いの成功、決済の拒否、支払い途中での離脱、代金引換時の動作をそれぞれテストしてください。フルフィルメントのテストでは、未払いの追加分が通常のピッキング待ちの一覧に入らないことを確認する必要があります。
編集によって合計金額が減った場合はどうなりますか？
結果はマーチャントが設定した返金方針に従います。 ストアでは、減額を禁止する、差額を元の決済方法に返金する、必要なプランに対応している場合にストアクレジットを発行する、のいずれかを選べます。導入前に財務部門の承認を得てください。ポータルの確認画面だけに頼らず、Shopifyに残る記録と購入者への通知をテストします。
代理店は3PLとの互換性をどうテストすべきですか？
管理されたテスト注文を作成し、編集可能な期間の前、中、後に3PLが受け取る内容を調べます。 保留中の注文、解除された注文、住所の修正、商品の交換、キャンセル、未払いの増額をテストします。3PLがShopifyの保留を尊重するか、解除タグを必要とするかを確認します。観測した動作を、その連携に固有の受け入れテストとして記録してください。
商品の追加や交換に専用のFlowトリガーはありますか？
まだありません。商品の追加、交換、バリエーションの変更に対応する明細単位のトリガーは、2026年8月26日時点でドキュメントに記載された開発予定の機能です。 提供済みのOrder editedトリガーを使い、10秒待ってから現在の注文データを取得します。更新後の明細を比較するか、その変更を評価できるシステムへイベントを送ります。開発予定のトリガーを、利用可能な機能として案内しないでください。
このサービスで配達後の返品も扱えますか？
いいえ。このサービスは、フルフィルメント前の変更を目的として設計されています。 配達後の返品、返品承認、配送状況の追跡、配送会社への補償請求は別の業務分類です。代理店はそれらのツールを注文の編集と合わせて提供できますが、権限、指標、サポート手順は分けてください。範囲を明確にすることで、継続契約が対象の定まらない購入後サポート一式になるのを防げます。
今週取り組む、代理店向けの3ステップ
条件を満たす代理店なら、3回の作業セッションでこのサービスを検証できます。
- 需要を調べる： 最近の注文変更に関する問い合わせを50件抽出し、依頼内容、依頼の時点、フルフィルメントの状態を分類します。
- 方針を作る： 対象となる注文区分、編集機能、金銭処理、期限、倉庫への引き渡しルールを整理します。
- 試験導入する： Test Modeを設定し、代表的な注文を作り、すべての後続システムを確認したうえで、固定料金の導入と月額の運用管理を提案します。
目的は、すべての注文をいつまでも編集可能にすることではありません。業務上のコストが確定する前に、対象となる購入者がルールの範囲内で自分で変更できるようにすることです。
代理店がクライアントに提供するShopifyの購入後の注文の編集サービスは、購入者自身による操作に、管理された金銭処理のルール、フルフィルメントのタイミング、Flowによる自動化、継続的な運用責任を組み合わせることで、価値を明確に示せます。