Shopifyの購入者による注文編集依頼：APIの設定

Shopifyはバージョン2026-10でこれらのAPIを追加しました。注文管理やフルフィルメントの連携で、販売者が処理する前に顧客の対応待ちのキャンセル依頼を確認する必要がある場合に採用してください。

送信できる依頼を未フルフィルメントの商品削除に限定する#

対応している変更は削除です。2026-10では、orderRequestEditのlineItems入力に含まれるのはremovalsだけで、それぞれにlineItemIdと依頼する数量を指定するquantityが含まれます。数量の一部だけを指定することもできます。追加やバリエーション交換の依頼タイプはなく、住所、配送、割引の変更も対象外です。

標準の顧客アカウントのフローでは、購入者は対象の注文でCancel itemsを選択します。従来の顧客アカウントには対応していません。Shopifyの設定要件では、Settings > Customer accountsでの有効化について説明しています。ストアがまだ従来のアカウントを使用している場合は、顧客アカウントの移行ガイドを参照してください。

購入者向けのインターフェースを構築する際は、Order.requestedEditInformationを読み取ってください。その対象条件のオブジェクトは、hasEditableLineItems、editableLineItems、ineligibleLineItemsを提供します。そのレスポンスを基に、依頼できる数量を表示してください。未フルフィルメントだからといって、すべての数量を新しい依頼の対象にできるとは想定しないでください。

標準のセルフサービス依頼は、B2B注文にも適用されます。サブスクリプション注文の依頼を処理しても、サブスクリプション契約は有効なままです。マーケットごとに有効化するには、AdvancedまたはPlusに加え、checkout and accounts editor内の早期アクセス版の注文アクション設定を利用できる必要があります。そのオプションがないストアでは、すべてのマーケットで依頼を有効化します。

APIと権限を設定する#

2026-10のリファレンスを使用してください。依頼のリソースはRequestedOrderEditです。そのステータス列挙型には、REQUESTED、RESOLVED、DECLINEDが含まれます。REQUESTEDは、販売者の対応待ちであることを意味します。APPROVEDという状態はありません。

Admin APIのクエリには、read_ordersを要求してください。作成のリファレンスに記載されているとおり、3つのAdmin APIミューテーションにはwrite_ordersとスタッフのedit_orders権限が必要です。計算を伴う販売者側の編集ワークフローには、別途write_order_editsが必要です。

購入者側のミューテーションには、customer_write_pre_authenticatedを要求してください。ユーザーには、customer_write_ordersアクセス、または注文への事前認証済みアクセスも必要です。購入者向けのプレビュークエリでは、アプリにcustomer_read_pre_authenticatedが必要です。また、プレビューを提供する前に、ユーザーがcustomer_read_ordersアクセス、またはその特定の注文への事前認証済みアクセスを持っている必要があります。OrderRequestedEditInformationの読み取りには、customer_read_ordersが必要です。

orderRequestEditで@idempotentを使用し、同じ送信を再試行する際はキーを再利用してください。Shopifyは別の依頼を作成せず、元の依頼を返します。

販売者が確認する間はフルフィルメントを保留する#

対応待ちの依頼に対する自動保留は、ドキュメントに記載されていません。Shopifyの変更履歴では、フルフィルメントの保留は、REQUESTEDステータスの注文に対してアプリが実行できる処理として説明されています。

3つの依頼のWebhookトピック、requested_order_edit/created、requested_order_edit/resolved、requested_order_edit/declinedを購読してください。それぞれに、read_orders、read_marketplace_orders、read_buyer_membership_ordersのうち少なくとも1つが必要です。ペイロードには、注文と依頼された削除の情報が含まれ、quantityとresolved_quantityも含まれます。サンプルのWebhookステータスは小文字です。GraphQLの列挙値は大文字です。

販売者が確認中のピッキング停止を希望する場合は、次の手順を連携に組み込んでください。

1. /createdを受信したら、現在の注文と依頼を取得します。倉庫側の注文に対応付けて依頼IDを記録します。
2. 連携側で管理しているフルフィルメント保留、または倉庫の作業停止の仕組みを適用します。倉庫がすでに注文を取り込んでいる場合は、依頼対象の数量分のピッキングが停止したことについて、倉庫からの確認を必須とします。
3. /resolvedまたは/declinedを受信したら、注文に残っている依頼と現在の数量を取得します。対応待ちの依頼と必要な返金処理がすべて完了してから、連携側の保留を解除します。

すべての依頼を確認してください。1つの注文に複数の依頼が存在する場合があり、displayRequestedEditStatus = REQUESTEDは、少なくとも1つの依頼で販売者の対応がまだ必要であることを意味します。1つの/resolvedイベントだけで保留を解除しないでください。

自動解除を有効にする前に、停止の確認方法について合意してください。フルフィルメント保留の連携ガイドでは、その後の工程の制御について説明しています。

依頼を閉じる前に商品削除を処理する#

Shopify管理画面で、OrdersをCustomer requestで絞り込みます。依頼は注文のバナーに表示されます。確認を行う担当者にはOrders権限が必要です。

支払い済みの注文では、Remove itemsを選択すると、依頼対象の商品が指定された返金ページが開きます。返金する商品を選び、金額と在庫に戻すオプションを確認してから、Refundをクリックしてください。Shopifyが依頼を完了済みにします。未払いの注文では、Remove itemsを選択すると、代わりに在庫に戻すためのページが開きます。

完了処理は依頼の記録を閉じます。requestedOrderEditResolveのリファレンスでは、依頼を完了済みとして記録する処理と説明されています。入力は依頼のidだけで、数量、返金、在庫に戻すためのフィールドはありません。商品削除と返金は別途実行し、実装側の実行記録に両方の処理を残してください。

送信前に、requestedOrderEditCalculateを使って、依頼された削除による金額への影響をプレビューしてください。financialSummaryと計算後の商品明細が返されます。プレビューでは金銭の精算は行われません。注文編集APIガイドでは、既存のbegin、stage、commitのワークフローと、別途必要な精算処理について説明しています。

依頼を拒否するには、requestedOrderEditDeclineを呼び出します。任意のdeclineNoteは、購入者への通知メッセージで、最大500文字です。一方、Shopify管理画面のManage request > Mark as resolvedは、注文を変更せず、顧客にメールも送信せずに依頼を閉じます。販売者が削除を拒む場合は、依頼を拒否してください。商品を削除して返金した後、または別の方法で依頼に対応した場合にのみ、完了済みにしてください。

リリース前にドキュメントに記載のない状態遷移を検証する#

Shopify管理画面では、依頼対象の商品を返金すると依頼が完了済みになり、注文をキャンセルした場合も同様です。一方、商品を削除して返金を後で行う場合は、依頼が未完了のままになります。Shopifyは、refundCreate、または依頼対象の数量を削除するorderEditCommitによって、API経由でも依頼が完了済みになるかどうかをドキュメントに記載していません。その動作を前提にする前に、使用するAPIの処理経路が管理画面と同じように動作するか、開発ストアでテストしてください。

未フルフィルメントの明細の数量の一部について依頼を作成し、requestedOrderEditResolveを呼び出さずに、予定している返金または編集の処理経路でその数量を処理してください。処理後の依頼ステータスとresolvedQuantityを、注文の残りの数量や返金取引と併せて確認します。どの依頼のWebhookが届くかを記録してください。

同じ注文で、対象条件を満たす別の数量分の依頼を作成し、1つの依頼が対応待ちのままの状態で、解除ハンドラーを動かしてください。販売者が確認すべき依頼が残っている間は、倉庫の作業をブロックしたままにします。削除または返金が失敗した場合は、販売者に分かる形で例外を表示し、注文をブロックしたままにしてください。

復旧のために、フィルターrequested_order_edit_status:requestedを使い、ページネーション付きのordersクエリを実行してください。一致する各注文のrequestedOrderEditsコネクションを取得し、依頼の記録と照合します。連携側で保留している注文もIDで照合してください。最後の依頼が閉じた際のWebhookを取りこぼした注文は、その検索の対象から外れるためです。定期照合の実行間隔は、倉庫の再開ルールに基づいて設定してください。

変更を実行する担当を決める#

追加は購入者依頼API以外の方法で処理してください。Shopifyの販売者による編集フローでは、フルフィルメント前に商品を追加できます。

販売者が設定した編集期間内に、顧客がバリエーション交換、住所の修正、商品の追加を行う必要がある場合、ストアはRevizeなどのセルフサービス編集アプリを利用します。RevizeのHold orders設定はFulfillment while editingにあり、時間ベースの編集期限が終了するまでフルフィルメントを保留し、その後、設定された解除タイミングと支払い条件に従って解除します。Until fulfillmentの期限では、Revizeは保留を設定しません。

倉庫と調整してFulfillment while editingを設定してから、顧客向けの編集フローを利用できるようにしてください。購入者向けのキャンセル手順として、顧客にはキャンセルガイドを案内してください。

よくある質問#

依頼はRESOLVEDですが、商品が残っています。APIが失敗したのでしょうか？#

ステータスだけでは、削除された証拠にはなりません。requestedOrderEditResolveは依頼を完了済みとして記録し、受け取るのは依頼のidだけで、数量、返金、在庫に戻すためのフィールドはありません。サポート担当者は、処理が完了したと購入者に伝える前に、実際の注文と返金記録を確認してください。

購入者はこれらのAPIでサイズ交換を依頼できますか？#

いいえ。2026-10の依頼の入力が対応しているのは、未フルフィルメントの商品の削除だけです。サイズ変更は、ストアの販売者による編集、または顧客のセルフサービス編集のワークフローで処理してください。

依頼完了のWebhookは、その注文のすべての依頼が閉じたことを意味しますか？#

いいえ。倉庫側の注文の作業再開を許可する前に、requestedOrderEditsを取得するか、displayRequestedEditStatusを確認してください。注文レベルの値がREQUESTEDの場合、少なくとも1つの依頼で販売者の対応がまだ必要です。

フルフィルメントオーダーのキャンセル通知の購読は続けるべきですか？#

フルフィルメントサービスの連携で必要な場合は、継続してください。fulfillment_orders/cancellation_request_*トピックは、販売者またはアプリからフルフィルメントサービスへの依頼に関するものです。購入者による編集依頼はrequested_order_edit/*を使用するため、専用の処理が必要です。

関連記事#

• Shopify注文の個別商品をキャンセルする
• Shopifyで一部返金を処理する
• 3PLがピッキングを開始した後の変更に対応する