購入者の「この商品を外して」が API で扱えるリソースになった

図解 ： 購入者からの注文編集リクエスト API（RequestedOrderEdit） Developer / API 2026-10 購入者の「この商品を外して」が API で扱えるリソースになった 購入者は未発送の商品を注文から外すリクエストを出せるようになった。そのリクエストは RequestedOrderEdit として GraphQL Admin API・Customer Account API・3 つの新しい Webhook から見える。マーチャントやアプリはこれを確認して、対応済みにするか、却下できる。 このページの構成 そもそも何が変わるのか（30秒で理解） ライフサイクル図解 ： リクエストから決着まで GraphQL Admin API の追加点 Customer Account API と Webhook の追加点 2026-07 と 2026-10 の比較 影響を受けるアプリと必要スコープ 対応は必要か 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまでは購入者が購入後に注文を変えたくても、 API から見える記録が何も残らなかった 。購入者は API の外（Shopify の仕組みの外）でマーチャントに連絡し、マーチャントが手作業で注文を編集していた。 API バージョン 2026-10 からは、購入者の編集リクエストが RequestedOrderEdit という独立したリソースとして API に出てくる。 2026-07 まで ： 手作業でしか追えない リクエストは API の外でやり取りされるだけ。アプリはリクエストを見ることも、処理することもできない。発送前の保留中の変更を ERP や WMS に反映することもできない。 2026-10 から ： API 上のリソースになる リクエストの作成・計算・対応済み化・却下が API でできる。進行状況は Webhook で届く。アプリは自分のワークフローに保留中のリクエストを表示し、自動で判断できる。 購入者がリクエストできる内容は 未発送の商品（line item）を注文から外すこと として説明されている。数量の追加や商品の差し替えについては記載なし。 2 ライフサイクル図解 ： リクエストから決着まで リクエスト経由の注文編集は 既存の注文編集モデル の上で行われる。新しく加わったのは、リクエスト自体を API で見て処理できる層。 requestedOrderEditResolve の説明は「リクエストを手動で対応済みにする」。このミューテーションを呼ぶと注文の中身が自動で変わるのかどうかは記載なし。 3 GraphQL Admin API の追加点 Object RequestedOrderEdit 購入者のリクエスト 1 件を表すオブジェクト。ステータス、要求された変更、リクエストが作成・対応済み化・却下された日時を持つ。 Order の新フィールド connection requestedOrderEdits 注文に紐づくリクエストの一覧 field displayRequestedEditStatus 注文全体のリクエスト状態を画面表示用にまとめた値 Mutation 作成 requestedOrderEditCreate リクエストを作成する（マーチャントや購入者の代わりにアプリが実行できる） 対応済み requestedOrderEditResolve リクエストを手動で対応済みにする 却下 requestedOrderEditDecline リクエストを却下する Query / 検索 query requestedOrderEditCalculate リクエストを作成する前に、金額面の結果を計算して返す filter requested_order_edit_status orders クエリの検索フィルタ。マーチャントの対応待ちリクエストがある注文を探せる 4 Customer Account API と Webhook の追加点 Customer Account API（購入者側） mutation orderRequestEdit 購入者が編集リクエストを送信する query requestedOrderEditCalculate 金額面の結果をプレビューする 冪等性 @idempotent ディレクティブでべき等キーを任意で付けられる リトライしても重複は作られず、最初に作成されたオブジェクトが返る 新しい Webhook トピック（3 つ） created requested_order_edit/created resolved requested_order_edit/resolved declined requested_order_edit/declined ペイロードの中身 ： リクエストのステータス、 order_id 、要求された line item の変更（確定した数量つき）。 5 2026-07 と 2026-10 の比較 項目 API 2026-07 API 2026-10 購入者のリクエスト API の外 マーチャントへ直接連絡 API で扱える orderRequestEdit で送信 API から見える記録 なし あり RequestedOrderEdit アプリによる処理 リクエストを見ることも処理することもできない 作成／対応済み化／却下をミューテーションで実行 外部システムとの同期 発送前の保留中の変更を ERP・WMS に反映できない Webhook 3 種で進行状況を受け取れる 対応待ちの注文を探す — requested_order_edit_status フィルタ 金額の事前確認 — requestedOrderEditCalculate （Admin／Customer 両方） 6 影響を受けるアプリと必要スコープ 注文管理・ERP 注文を読み取る・管理するアプリ。 フルフィルメント・3PL 発送処理と連携するアプリ。 カスタマーアカウント体験 購入者向けのアカウント画面を作るアプリ。 クエリ read_orders GraphQL Admin API でリクエストや注文を読み取るのに必要。 ミューテーション write_orders GraphQL Admin API でリクエストを作成・対応済み化・却下するのに必要。 Customer Account API 側で必要なスコープ、対応プラン、対応国は記載なし。 7 対応は必要か 必須の対応はない。 購入者からの注文編集リクエストに対応したい場合は、アプリが使う GraphQL Admin API・Customer Account API・Webhook を最新バージョン（2026-10）に上げる。 8 技術者が押さえるべき5つのポイント 1. REQUESTED で発送を保留できる 記事では、ステータスが REQUESTED の注文の発送を止めることがユースケースに挙がっている。3PL や WMS に渡す前のゲートとしてステータスを確認する設計が組める。 2. 購入者側は @idempotent で安全にリトライ orderRequestEdit にべき等キーを付ければ、通信エラーでリトライしても最初のオブジェクトが返り、重複リクエストは作られない。モバイル回線の多いアカウント画面では付けておくのが無難。 3. 先に Calculate で金額を確認 requestedOrderEditCalculate は Admin と Customer Account の両方にあり、作成前に金額面の結果を返す。購入者への確認画面や、社内の承認判断に使える。 4. ポーリング用の検索フィルタと Webhook の両方がある リアルタイム処理は Webhook 3 種で、取りこぼし対策や一括処理は orders クエリの requested_order_edit_status フィルタで、と使い分けられる。 5. 「対応済み」の意味と範囲を自分で確かめる リクエストで行われる編集は既存の注文編集モデルを通り、 requestedOrderEditResolve の説明は「手動で対応済みにする」となっている。Resolve を呼ぶと注文の中身が自動で変わるのか、別に注文編集 API を呼ぶ必要があるのかは記載なし。対象も 未発送の商品の削除 に限られる。導入前に開発ストアで実際の動きを確認すること。 9 業務に活かせる3つのユースケース USE CASE 1 3PL／WMS 連携で「キャンセル希望の商品の誤出荷」を防ぐ 課題 購入者から「この商品は外して」と連絡があっても、倉庫には変更前の注文データが渡っていて、そのまま出荷されてしまう。 打ち手 requested_order_edit/created を受けたら、WMS 側でその注文の出荷を保留にする。resolved／declined の Webhook を受けたら保留を解除する。 効果 誤出荷・返品・返金の手間が減る。CS と倉庫の電話やメールでのやり取りもなくなる。 技術メモ Webhook の取りこぼしに備えて、出荷直前に requested_order_edit_status で対応待ちの注文がないかもう一度確認する。スコープは read_orders 。 USE CASE 2 ERP 側で編集リクエストの承認フローを回す 課題 受注データは ERP で管理しているのに、注文変更の判断は Shopify 管理画面とメールでばらばらに行われていて、記録が残らない。 打ち手 Webhook で ERP にリクエストを取り込み、担当者の承認画面に表示する。判断結果を requestedOrderEditResolve ／ requestedOrderEditDecline で Shopify に返す。 効果 変更依頼の受付から決着までの記録が 1 か所にまとまる。対応漏れや二重対応を防げる。 技術メモ ミューテーションには write_orders が必要。承認画面には requestedOrderEditCalculate で計算した金額の変化を出すと判断しやすい。 USE CASE 3 アカウント画面に「商品を取り消す」セルフサービスを追加 課題 注文直後に「1 点だけ取り消したい」という問い合わせが CS に集まり、メールでやり取りしながら手作業で対応している。 打ち手 カスタマーアカウント画面に、未発送の商品を選んで取り消しをリクエストできる UI を置く。 requestedOrderEditCalculate で金額の変化を見せてから orderRequestEdit で送信する。 効果 問い合わせの受付と内容確認が自動化され、CS はリクエストを判断するだけになる。購入者も連絡の手間が減る。 技術メモ @idempotent のべき等キーを付けて、ボタンの連打やリトライによる重複を防ぐ。対象は未発送の商品の削除だけ。 10 提案で使える1行サマリ 「購入者の『この商品を外して』が、API 2026-10 から RequestedOrderEdit として API と Webhook に出てくる。 発送の保留・ERP での承認・アカウント画面のセルフサービスまで、手作業だった注文変更をアプリで自動化できる。 必須対応はなく、使いたいアプリだけ 2026-10 に上げればよい。」 source ： shopify.dev/changelog/new-apis-for-buyer-requested-order-edits Developer Changelog ／ 公開日 2026-10-01