---
title: "見積とShopifyの注文が食い違うとき：変換後にずれるもの"
description: "変換後、見積・下書き注文・注文・基幹システムは文書化された19の経路でずれます。それぞれの検出と修復の方法、どの項目を誰が持つかを整理します。"
url: "https://www.quotway.com/ja/blog/quote-to-order-out-of-sync"
type: "blog post"
category: "For Shopify agencies"
published: "2026-10-09"
verified: "2026-10-09"
shopify_api_version: "2026-10"
audience: "変換後も見積レイヤー、Shopify、基幹システム（ERP）やCRMの内容を一致させ続けるShopifyエージェンシーと開発者"
scope: "API 2026-10時点の変換後に起きること：下書きの編集とチェックアウトの紐づけ解除、削除・自動削除された下書き、未払いの請求書、取りこぼした注文のWebhook、注文の編集、バイヤーが依頼する編集、キャンセル、返金とフルフィルメント、分割された取引、通貨、紐づけのキーとタグの上書き、識別情報の変更、項目の所有権、EventsとWebhookの比較、そして突合ジョブ"
locale: "ja"
source: "QuotWay - B2B Quote & Negotiation App for Shopify"
---

# 見積とShopifyの注文が食い違うとき：変換後にずれるもの

Shopifyで見積が変換されると、同じ取引を4つのレコードが表すことになります。承諾された見積、下書き注文、注文、そして基幹システム（ERP）やCRMが持つものです。この4つが食い違うパターンは、文書化されている少数のものに限られます。変換後に編集された下書き、注文ができた後も開いたままの下書き、削除された、あるいは1年後に自動削除された下書き、編集・キャンセル・返金された注文、バイヤーが依頼した変更、コネクタに上書きされたタグの一覧です。どのずれも特定の2つの項目を比べれば検出でき、各項目の持ち主は1つだけです。突合（reconciliation）とは、その持ち主を決め、項目の組を定期的に確認することです。

このページは、下書きが存在した*後*にずれるものの一覧です。各ケースの検出方法と修復方法、そして変換以降どの項目を誰が持つかを扱います。下書きをちょうど1件だけ作る方法は[承諾された見積1件を、Shopifyの下書き注文ちょうど1件にする方法](/blog/idempotent-draft-order-creation)で、変換の*時点*で壊れるものは[17の失敗パターン](/blog/quote-to-draft-order-failure-modes)で、最初から誤っていた価格の診断は[見積が誤った価格で変換される理由](/blog/quote-converts-at-wrong-price)で扱っています。ここでいう「突合」は見積と注文のデータのことで、入金（ペイアウト）や銀行口座の照合のことではありません。

以下のShopifyに関する記述はすべて、2026年10月9日にShopify自身のページでAPIバージョン2026-10を対象に確認しました。出典は末尾にあります。

## 4つの比較
> **4つのレコードと4つの比較**
>
> 横一列に並ぶ4つの箱。承諾された見積、下書き注文、注文、基幹システムまたはCRMです。隣り合う箱の間には、ずれを検出する比較が示されています。見積と下書きは変換時に保存した合計で、下書きと注文は下書きのorder項目で、注文はそれ自体の元の合計と現在の合計で、注文と基幹システムは変換属性またはタグと表示通貨の金額で比べます。
>
> 下の表のずれはすべて、この4つの比較のどれかに現れます。

## 何がずれ、どう捕まえるか
起きる時期ごとにまとめています。「正本」は、変換以降に優先されるレコードです。

### 注文ができる前
| # | ずれるもの | Shopify側の原因 | 検出 | 修復 | 正本 |
| --- | --- | --- | --- | --- | --- |
| 1 | 下書きの明細や合計が、承諾された内容と食い違う | 変換後にスタッフが下書きを編集する。`tags` を更新すると一覧全体が上書きされる | `draft_orders/update` のペイロードの合計を、変換時に保存した合計と比べる。`DraftOrder.tags` を、自分が書いたタグと比べる | 取引条件の変更は新しい提案かカウンターオファーと新しい下書きで行い、古い下書きは削除する。物流上の変更は記録する | 支払いまでは承諾されたバージョン |
| 2 | 注文があるのに、下書きが開いたまま | チェックアウトの途中で更新が行われ、チェックアウトとの紐づけが外れた。注文は作成され、「注文が作成された後も下書きは開いたままになります」 | 注文に自分の変換属性があるのに、`DraftOrder.order` がnull、またはステータスが `COMPLETED` でない | 属性で注文を紐づける。古い下書きは人が削除する | 注文 |
| 3 | 見積が、もう存在しない下書きを指している | スタッフが削除した | `draft_orders/delete`。最後の備えとして、`draftOrder(id)` が何も返さないこと | 下書きを失われたものとして記録し、属性を持つ注文がないことを確かめてから、作り直すか閉じる | Shopify |
| 4 | 同じことが1年後に起きる | 2025年4月1日以降に作成された下書きは、編集がないまま1年経つと削除される | `draftOrder(id)` が何も返さない。この自動削除で削除のWebhookが送られるかどうかは、Shopifyが文書化していない | 1年が来るずっと前に、取引を失注とするか再見積するかを決める | Shopify |
| 5 | 請求書を送ったが、支払われていない | 注文ができるのは、下書きが支払われるか完了したときだけ | `draftOrders(query: "tag:… status:invoice_sent")` と経過日数 | 催促する、延長する、または下書きを削除して見積を閉じる。後者は必ず両方同時に | 下書きのステータス |
| 6 | 見積は期限切れなのに、下書きはまだ支払える | 下書きには自動削除以外の期限がない | 見積が期限切れで、`DraftOrder.status` が `OPEN` または `INVOICE_SENT` | 見積の期限切れと同時に下書きを削除する。または、請求書を送った後は見積を期限切れにしない | どちらかを選ぶ。ただし1つだけ |
| 7 | 見積レイヤーや基幹システムが知らない、支払い済みの注文 | Webhookの配信は保証されていない | `draftOrder.order` が設定されているのに注文IDが保存されていない。または `orders(query: "tag:… updated_at:>…")` を保存済みのIDと比べる | 同じWebhookハンドラーで再生する（[突合ジョブ](/blog/idempotent-draft-order-creation#sweep)） | 注文 |

### 注文ができた後
| # | ずれるもの | Shopify側の原因 | 検出 | 修復 | 正本 |
| --- | --- | --- | --- | --- | --- |
| 8 | 注文の明細や合計が、承諾されたバージョンと食い違う | マーチャントや別のアプリが注文を編集する。Shopifyによれば、アプリが作成した下書きから生まれた注文は「Shopify管理画面で、また他のアプリによって編集できます」 | `orders/edited`、`Order.edited`、`originalTotalPriceSet` と `currentTotalPriceSet` の比較 | 理由を注文に記録する。見積は書き換えない。基幹システムは注文に従う | フルフィルメントと請求は注文、合意した内容は見積 |
| 9 | 基幹システムや倉庫が把握していない、保留中のバイヤーの変更 | 2026-10から、バイヤーは未フルフィルメントの明細の削除を依頼できる | `requested_order_edit/*` Webhook、`Order.requestedOrderEdits` | 保留中はフルフィルメントを止める。承認か却下かを決める。承認された依頼は注文の編集として届く | 注文 |
| 10 | 見積は進行中の取引に見えるが、注文はキャンセル済み | キャンセルは「元に戻せません」 | `orders/cancelled`、`cancelledAt` | 注文ごとに記録する。見積は記録として残し、再見積は新しい見積にする | 注文 |
| 11 | 返金や返品の後の金額 | 明細ごと、送料ごとの返金、そして返品 | `refunds/create`、`returns/*`、`currentSubtotalPriceSet` | 基幹システムのクレジットノートは、見積からではなく返金から作る | 注文の返金 |
| 12 | フルフィルメントの状態が複数の場所に複製される | 倉庫や基幹システムがShopifyにフルフィルメントを書き込む | `fulfillments/*`、`displayFulfillmentStatus` | フルフィルメントを見積レイヤーに複製しない | Shopifyを通じて、倉庫または基幹システム |

### 取引の形とキー
| # | ずれるもの | 原因 | 検出 | 修復 | 正本 |
| --- | --- | --- | --- | --- | --- |
| 13 | 「この見積の注文は1件だが、2件あるはず」 | 一部承諾や分割変換では、グループごとに下書きが1件できる。後回しにした明細は未決定のままで、辞退されたわけではない | 変換済みのグループを保存済みの注文IDと比べる。各注文の小計を、承諾された明細と比べる | グループごとに突合する。未決定の明細は欠落ではない | どの明細が未決定かは見積レイヤー、何が購入されたかは注文 |
| 14 | 見積の合計が基幹システムの金額と合わない | 下書きと注文は表示通貨で、`shopMoney` は換算後の金額 | 見積とは `presentmentMoney` だけを比べる | どちらの側で計上するかを意図して決める | 表示通貨の金額 |
| 15 | 注文が見積から来たものだと分からなくなる | 一覧全体の書き込みでタグが上書きされた。属性やメモが編集された | `orders(query: "tag:…")` を保存済みのIDと比べる。Eventsの `order.tags` と `order.customAttributes` のトリガー | 見積の記録から復元する。連携はタグを一覧の書き換えで扱わず、必ず `tagsAdd` で追加する | キーを一度だけ書いた見積レイヤー |
| 16 | 変換後にバイヤーの識別情報が変わった | 連絡先の削除、所在地の削除や変更、顧客の統合 | `company_contacts/delete`、`company_locations/delete`、`customers/merge` を保存済みのIDと比べる | 支払い前なら、正しい所在地で下書きを作り直す。支払い後は、注文ではなく顧客マスタを直す | 基幹システムの顧客マスタかShopify。どちらか一方 |
| 17 | 見積レイヤーが持つ項目をコネクタが書き換える | 1つの項目に書き手が2人いる | 項目単位のEventsトリガー。見積レイヤーが書いた内容との差分 | コネクタを自分の項目だけに制限する | 項目ごとに書き手は1人 |
| 18 | 連携が見積レイヤーのイベントを取りこぼした | 少なくとも1回（at-least-once）で順不同の配信。エンドポイントの停止 | イベントの連番の欠け。送信側が配信をあきらめたもの | まずイベントフィードから、次にAPIから再生する | 見積レイヤーのイベントログ |
| 19 | 突合ジョブが古い注文について「問題なし」と報告する | `read_all_orders` がないアプリから見えるのは、直近60日の注文だけ | ジョブの対象範囲を注文の経過日数と比べる | `read_all_orders` を申請するか、その期間内で突合する | - |

## 変換後、どの項目を誰が持つか
[基幹システム・CRM・PIMの連携パターン](/blog/shopify-b2b-erp-crm-pim-integration-patterns#ownership)には、連携の全期間を通じた所有権の表があります。こちらの表は、下書きが存在した時点から始まります。

| 項目 | 変換後の持ち主 | それ以外のシステム | 理由 |
| --- | --- | --- | --- |
| 合意した明細、数量、単価、条件、バージョン | 見積レイヤー。封印された承諾済みバージョンで、編集しない | 監査のために読む | 合意の記録だから。送信済みの提案はロックされている |
| 未決定のままの明細 | 見積レイヤー | CRMはパイプラインとして読む | 変換されておらず、失われてもいない |
| 支払いまでの下書きの内容 | 見積レイヤーが一度だけ書いた。スタッフの編集は記録すべき例外 | 基幹システムは下書きを無視する | 下書きは支払える状態にあり、変えれば取引が変わる |
| 注文の明細、数量、合計 | Shopifyの注文 | 基幹システムと倉庫が読む。見積レイヤーは複製しない | 編集、返金、返品は注文の上で起きる |
| 支払いと返金 | Shopify | 基幹システムは返金から計上し、見積レイヤーは最終状態だけを記録する | お金は注文の上で動く |
| フルフィルメント | Shopifyに書き込む倉庫または基幹システム | 見積レイヤーは何もしない | 書き手は1人 |
| 請求書、元帳、クレジットノート | 基幹システムまたは会計システム | - | Shopifyは元帳ではない |
| 紐づけのキー（見積のタグ、変換属性、メモの行） | 見積レイヤーが一度だけ書く | ほかのシステムは `tagsAdd` で追記する | `tags` の更新は一覧を上書きする |
| 会社、所在地、連絡先 | 基幹システムの顧客マスタかShopify。どちらか一方 | 見積レイヤーは読む | 書き手は1人 |
| 変換後の見積のステータス | Shopifyの注文イベントから導出する見積レイヤー | 連携は読む | 導出するもので、逆方向にはしない |

ここから導かれる規則は、注文の変更を見積に書き戻さないことです。見積は合意した内容で、注文はフルフィルメントと支払いが行われているものです。両者が違うときは、その理由を注文に記録します。

## Eventsか、Webhookか
ShopifyのEventsはAPI 2026-10で一般提供となり、従来のWebhook（classic webhooks）の後継と位置づけられています。従来のWebhookも引き続き動作します。Eventsには注文、返金、返品、フルフィルメントオーダー、会社、顧客のトピックがあり、個々の項目に対するトリガーを持ちます。`order.tags`、`order.customAttributes`、`order.lineItems.quantity` などがあり、表の8、15、17行目に向いています。ただし**下書き注文のトピックはない**ため、1〜6行目には引き続き従来の `draft_orders/*` Webhookが必要です。ShopifyはEventsの配信保証を文書化していないので、どちらを使う場合も、下の突合ジョブは残してください。

## そのまま使える突合ジョブ
保存済みのIDを対象に、注文にアクセスできる期間内で、定期的に実行します。

1. **自分が作成し、まだ支払いを確認していない下書き。** `draftOrders(query: "tag:<your-tag> updated_at:>…")`。それぞれの `status` と `order` を見ます。注文があるのにIDが保存されていなければ7行目、下書きがなければ3行目か4行目、古い `INVOICE_SENT` の下書きは5行目か6行目です。
2. **自分のキーを持つ注文。** `orders(query: "tag:<your-tag> updated_at:>…")`。`originalTotalPriceSet` と `currentTotalPriceSet` を比べ（8行目）、`cancelledAt` と支払いステータス（10、11行目）、`requestedOrderEdits`（9行目）、そしてタグと変換属性がまだ残っていること（15行目）を確認します。
3. **外部システム。** 注文ごとに、基幹システムの金額を `presentmentMoney` と（14行目）、注文の件数を変換済みのグループの数と（13行目）比べます。
4. **対象範囲。** `read_all_orders` がなければ、見えるのは直近60日の注文だけです（19行目）。

作成側、つまり結果が不明な変換を見つける突合ジョブは、[冪等な変換の記事](/blog/idempotent-draft-order-creation#sweep)にあります。

## QuotWayの動作
一実装として、現在の動作を説明します。

- **何で照合するか。** QuotWayが作成するすべての下書きには、`quotway` と `quotway-<quote reference>` のタグ、見積参照とバージョンを記したマーチャント専用のメモ、そして注文をその変換グループへ紐づける変換属性が1つ付きます。QuotWayは作成した後の下書きを編集、完了、削除することはなく、注文を編集することもありません。
- **何を記録するか。** 変換済みの下書きの合計が変わると、変更前と変更後の金額とともに見積の履歴に記録します。見積が**注文完了**になった後は、その注文がキャンセルされたとき、または全額返金されたときに、見積に記録します。一部返金、返品、注文の編集、フルフィルメントはShopifyの注文の側に残るので、それらは注文で確認してください（[下書き注文への変換](/docs/converting-to-orders/convert-a-quote-to-a-draft-order)）。
- **分割変換と一部変換。** 承諾された各グループが、それぞれ独自の下書きと注文になります。バイヤーが後回しにした明細は見積の上で未決定のまま残り、後から変換できます（[一部承諾と分割変換](/docs/converting-to-orders/partial-acceptance-and-split-conversion)）。
- **取りこぼした注文のWebhook。** 突合ジョブが、請求書を送ってから7日経っても注文のない見積を確認し、Shopifyに注文があれば同じハンドラーで再生します。
- **連携向け。** Enterpriseプランでは（14日間の無料トライアル中も含みます）、APIの見積オブジェクトに見積のShopify下書き注文IDと注文IDが含まれ、30日分のイベントフィードが取りこぼしたWebhookを回復する手段になります（[イベントフィード](/docs/api/events)）。プランは[料金ページ](/pricing)に、変換については[見積を注文に変換する](/features/convert-to-orders)にあります。

## よくある質問

### 顧客が支払ったのに、Shopifyの下書き注文が開いたままなのはなぜですか？

チェックアウトの途中で下書きが更新され、チェックアウトとの紐づけが外れたためです。注文は作成されますが、「注文が作成された後も下書きは開いたままになります」。`DraftOrder.order` を確認し、自分のキーで注文を紐づけ、古い下書きを削除してください。

### 下書き注文が支払われたときのWebhookはありますか？

下書き注文の「支払い済み」というトピックはありません。支払いによって注文が作成されるので、`orders/create` を購読し、自分の属性やタグで下書きと照合します。下書きの `status` は `COMPLETED` になり、`order` 項目が設定されます。下書きへの変更は `draft_orders/update` で分かります。2026-10の時点で、ShopifyのEventsに下書き注文のトピックはありません。

### 注文が編集されたら、見積も変えるべきですか？

いいえ。見積は合意した内容の記録で、注文はフルフィルメントと支払いの対象です。編集の理由は注文に記録し、基幹システムは注文に従わせます。

### 基幹システムのために注文の編集を検出するには？

`orders/edited` Webhook、注文の `edited` 項目、そして `originalTotalPriceSet` と `currentTotalPriceSet` の差です。Eventsでは、`order.lineItems.quantity` のトリガーが数量について同じ役割を果たします。

### バイヤーが依頼する注文の編集とは何ですか？

API 2026-10から、バイヤーは注文から未フルフィルメントの明細の削除を依頼できます。依頼は `requested_order_edit/*` Webhookとして届き、`Order.requestedOrderEdits` で確認できます。保留中はフルフィルメントを止めてください。承認された依頼は、通常の注文の編集になります。

### 未払いの下書き注文に期限はありますか？

2025年4月1日以降に作成された下書きは、編集がないまま1年経つと削除されます。それ以外に下書きを失効させるものはないので、それより早く見積が期限切れになっても、下書きを削除しない限り、下書きは支払える状態のまま残ります。

### 突合ではShopify EventsがWebhookに取って代わりますか？

Eventsは従来のWebhookの後継で、従来のWebhookも引き続き動作します。ただし下書き注文のトピックがないため、下書きには引き続き `draft_orders/*` が必要です。ShopifyはEventsの配信保証を文書化していないので、どちらにしても突合ジョブは残してください。

### 基幹システムの合計が見積と合わないのはなぜですか？

見積、下書き、注文はバイヤーの表示通貨で、`shopMoney` は換算後の金額です。返金や注文の編集は、注文の現在の合計を変えます。見積は、注文の表示通貨の金額とその元の合計と比べてください。

## 出典

Shopifyのページ。2026年10月9日にAPIバージョン2026-10で確認しました。

- [draftOrderUpdate](https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/draftOrderUpdate)：更新は進行中のチェックアウトとの紐づけを外し、下書きは開いたままになる
- [DraftOrder](https://shopify.dev/docs/api/admin-graphql/2026-10/objects/DraftOrder)と[DraftOrderInput](https://shopify.dev/docs/api/admin-graphql/2026-10/input-objects/DraftOrderInput)：ステータス、`order`、タグ
- [下書き注文](https://help.shopify.com/en/manual/fulfillment/managing-orders/create-orders)：2025年4月1日以降に作成された下書きは編集がないまま1年経つと削除される。支払いによって注文が作成される
- [Order](https://shopify.dev/docs/api/admin-graphql/2026-10/objects/Order)：元の合計と現在の合計、`edited`、`cancelledAt`、`requestedOrderEdits`
- [既存の注文の編集](https://shopify.dev/docs/apps/build/orders-fulfillment/order-management-apps/edit-orders)：アプリが作成した注文は管理画面と他のアプリから編集できる。注文の60日の期間
- [orderCancel](https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/orderCancel)：キャンセルは元に戻せない
- [tagsAdd](https://shopify.dev/docs/api/admin-graphql/2026-10/mutations/tagsAdd)：上書きせずにタグを追加する
- [Webhookのトピック](https://shopify.dev/docs/api/admin-graphql/2026-10/enums/WebhookSubscriptionTopic)と[HTTPSでのWebhook配信](https://shopify.dev/docs/apps/build/webhooks/subscribe/https)：トピック。配信は保証されない
- [Eventsの一般提供開始](https://shopify.dev/changelog/next-generation-events-are-now-generally-available)と[EventsとWebhook](https://shopify.dev/docs/apps/build/events-webhooks)：トピック、項目単位のトリガー、従来のWebhookの継続
- [リリースノート 2026-10](https://shopify.dev/changelog/release-notes/2026-10)：バイヤーが依頼する注文の編集

QuotWayの動作は、2026年10月9日に確認した公開ドキュメントとアプリのソースに基づいて説明しています。