Shopifyの下書き注文は見積ではない：それぞれが表す状態遷移

Shopifyの下書き注文は、支払いを待っている注文の記録です。状態は3つ、「未処理」「請求書送信済み」「完了」で、どれも価格がすでに合意されていることを前提にしています。見積は、価格がどう合意されるかの記録です。依頼、提案、修正、カウンターオファー、承認、そして承諾。

Shopifyには前者のオブジェクトはあり、後者のオブジェクトはありません。だから交渉が必要なB2B構築は、見積の状態をどこか別の場所でモデル化し、最後に下書き注文を作成する必要があります。

これが答えのすべてで、このページの残りはその根拠です。Shopifyの下書き注文が実際に何を表しているかをフィールド単位で確認し、次に、交渉に必要でありながら下書き注文のどのフィールドにも収まらない状態を確認し、最後に、両者を分けたうえで下書き注文がどこに収まるかを示します。B2Bの見積プロジェクトで最初に「下書き注文をそのまま使えばいいのでは？」と考えるエージェンシーの開発者に向けて書いています。それは良い直感です。下書き注文は正しい終点だからです。しかし、途中まで担わせようとすると高くつきます。

以下のShopifyに関する記述はすべて、2026年9月21日にAPIバージョン2026-07でShopifyの公式ドキュメントと照合しました。出典は末尾に載せています。QuotWayが状態をどうモデル化しているかを説明している箇所は、このパターンの実装例のひとつであり、独自開発でも同じパターンが成り立ちます。

下書き注文が表しているもの

Shopifyの列挙型 DraftOrderStatus には3つの値があり、その定義が「下書き注文は何のためにあるか」の最も短い説明です。OPEN：「下書き注文は未処理です。支払われておらず、請求書も送信されていません。」INVOICE_SENT：「下書き注文の請求書が顧客に送信されました。」COMPLETED：「下書き注文は支払われました。」4つ目の値はありません。価格が依頼される、提示される、修正される、断られるといったことを記述する値は列挙型のどこにもありません。このオブジェクトは、それらが終わった後に始まるからです。

ステータスの周りにあるフィールドも同じことを語ります。invoiceSentAt は請求書が最後にメール送信された時刻で、送信のたびに上書きされる単一のタイムスタンプです。completedAt は下書きから注文が作成された時刻。ready は下書きを完了できる状態かどうか。order は注文が存在するようになった時点でそれを指します。paymentTerms、deposit、amountDueNowSet、amountDueLaterSet は合意済みの合計をどう回収するかを記述します。anyVariantPricesOverridden は明細がカタログ以外の価格を持っているかを示します。価格が変更されたことは記録しますが、何から変更されたか、誰が変えたか、バイヤーが同意したかは記録しません。

さらに、下書き注文は一生を通じて変更可能です。draftOrderUpdate は完全な DraftOrderInput を受け取り、そこにあるものを置き換えます。明細は個別に修正されるのではなく、丸ごと入れ替わります。そして、請求書をすでに送った下書きの更新について、ドキュメントは何の制限も設けていません。あるのは、更新したらどうなるかの警告だけです。チェックアウト開始後に更新すると、そのチェックアウトとの紐付けが外れ、下書きが未処理のまま注文が作成されることがあります。下書きのタイムライン（events）はこれらの変更のひとつひとつを BasicEvent として記録し、その message フィールドは「イベントを説明する人間が読めるテキスト」です。編集があったという記録ではあっても、開き直せる番号付きバージョンではなく、編集前の明細を返すフィールドはありません。

B2B向けにShopifyは、企業間の注文に必要な部品を追加しますが、交渉に必要なものは相変わらずありません。下書き注文は管理画面から始まることも、ストアから始まることもあります。会社所在地を「すべての注文を確認用の下書きとして送信」（Shopifyのチェックアウト概要ページでは同じ設定を「チェックアウトで下書き注文のみ許可」と呼んでいます）に設定すると、その所在地のバイヤーはチェックアウトで支払いステップの代わりに承認のために送信ボタンを見ることになり、下書きは価格がロックされた状態でマーチャントの下書き注文ページに届きます。マーチャントは商品と数量を編集し、発注書番号を追加し、支払い条件と前受金を設定し、価格をロックまたは解除し、請求書を送信するか、注文を直接作成できます。価格ロックは正確に読む価値があります。「価格の引き上げを防ぎますが、自動的な引き下げも防ぎます」。つまり、下書きがすでに持っている価格を凍結するのであって、二者が合意した価格を記録するのとは別のものです。バイヤーが請求書のリンクから支払うと、下書きは「支払い済み」の注文になります。支払い条件がある場合、注文は「保留中」から始まり、Shopifyがスケジュールに沿って回収するにつれて「一部支払い済み」「支払い済み」へと進みます。そして、誰も1年間編集しない下書きは削除されます。編集のたびにタイマーはリセットされますが、これもまた、ゆっくり進む交渉の置き場所に下書きを使うべきでない理由のひとつです。

Shopify自身のチェンジログが、この順序を正確に示しています。下書き注文の請求書に支払い条件を持ち込んだ2024年7月の記事は、請求書によって顧客は「注文を確定する前に、交渉済みのカートと価格を確認する機会」を得ると書いています。交渉済み、つまり過去形で、下書き注文が確定する前です。交渉はどこか別の場所で行われたのです。

下書き注文が表せないもの

次の表は、B2Bの交渉が記録しなければならないものと、それぞれについて下書き注文が提供しているものを並べたものです。中央の列が正直な列です。下書き注文にフィールドがあればその名前を、なければ「ない」と書いています。

交渉が記録すべきもの	下書き注文	実際に必要なもの
バイヤーが依頼した価格	フィールドなし。明細には価格がひとつあるだけで、バイヤーと売り手のどちらが設定したかは分からない	提示価格・最終価格とは別に保持する、明細ごとの依頼価格
送信時点の売り手の提案	現在の明細。draftOrderUpdate が丸ごと置き換える	送信した瞬間にロックされる、番号付きのバージョン
修正の履歴	人間が読めるイベントテキストのタイムライン	開き直せるすべてのバージョンと、任意の2つの差分
バイヤーからのカウンターオファー	なし。下書きに対してバイヤーができるのは「請求書を支払う」か「何もしない」か	バイヤーが作成したバージョンと、明細ごとの依頼価格
提案を出す前のマーチャント側承認	なし。スタッフ権限が決めるのはどの注文を見られるかであって、提案を出してよいかではない	提案を止めるポリシーと、承認者名つきの判断
バイヤー側の承認チェーン	なし。「承認のために送信」はマーチャントにバイヤーの注文を承認してもらう機能	バイヤー側の承認者が動ける状態と、各ステップの記録
一部の明細だけ承諾し、残りを未決のままにする	なし。下書きは全体が支払われるか、まったく支払われないか	明細ごとの承諾。選ばれなかった明細は次のラウンドに向けて未決のまま残る
提案の有効期限	1年間の非アクティブ後の削除。これは整理のための期限で、商取引上の期限ではない	売り手が設定する有効期限。過ぎれば承諾もカウンターもできなくなる
送信後の不変性	なし。請求書送信済みの下書きも編集でき、進行中のチェックアウトとの紐付けが外れる	その場では編集できない送信済みバージョン。変更は新しいバージョンになる
各操作を誰ができるか	管理者ユーザーの権限	各遷移を名前のある主体（バイヤー、マーチャント、システム）に許可し、それ以外には拒否する
価格の出どころ	anyVariantPricesOverridden は上書きされたことを示すが、何からかは示さない	交渉の出発点となったカタログ価格。バイヤーの所在地向けに解決し、カタログIDを出所として保持する
終端状態	COMPLETED（支払い済み）か、削除	辞退、期限切れ、キャンセル、返金、クローズを別々の終わりとして持つ。報告も追跡も異なるため

これは下書き注文への批判ではありません。下書き注文は、明確な仕事のための明確なオブジェクトです。問題は、本来の仕事の前の仕事までやらせることにだけあります。

Shopifyにオブジェクトがない見積の状態

見積の状態遷移は大きくなくて構いませんが、明示的でなければなりません。それぞれの状態は、後で誰かが必ず尋ねる問いに答えるからです。この時点でバイヤーは何ができたか、マーチャントは何ができたか、そして誰が何をしたか。以下の状態はQuotWayが使っているものです。独自開発なら名前は変わるでしょうが、同じ一式が必要になります。

依頼済み。 バイヤーが依頼しました。明細、数量、希望する価格、メモ、発注書番号、カスタムフィールド、添付ファイル。マーチャントはまだ何もしていません。この状態があるのは、誰かが価格をつける前から依頼が記録として存在するためです。依頼そのものがShopifyには決して保持されないデータである理由は、アーキテクチャの記事で説明しています。

確認中。 マーチャントが開きました。ここでマーチャントは、バイヤーのカタログ価格（一覧からコピーしたものではなく、会社所在地向けに解決したもの）を起点に明細に価格をつけ、明細を追加または削除し、配送を加え、提案を書きます。

マーチャント承認待ち。 ポリシーが提案を止めています。合計金額、含まれる商品、会社、バイヤーのタグなど、提案の何かが条件に当たったためです。承認者が動くまで見積はバイヤーに渡らず、承認者の判断は名前つきで記録されます。Shopifyのスタッフ権限では「この金額を超える提案は送信前に責任者を通す」を表現できません。このルールが住む場所がこの状態です。

提案送信済み。 提案が出ました。番号付きのバージョンであり、このバージョンはロックされます。バイヤーが受け取った文書は商取引の記録であり、監査証跡は何が書かれていたかを言えなければなりません。変更は新しいバージョンであって、編集ではありません。ここからバイヤーは、承諾する、一部を承諾する、カウンターを出す、辞退する、自社の承認者に回す、のいずれかを選べます。

バイヤー承認待ち。 バイヤーの組織にも独自の決裁があります。上長や経理の担当者です。Shopifyの「承認のために送信」はこれではありません。あれはマーチャントにバイヤーの注文を承認してもらうものであって、バイヤーの上長に売り手の提案を承認してもらうものではありません。チェーンが終わると、見積はチェーンの判断を記録に残したまま提案送信済みに戻ります。

カウンター。 バイヤーが別の数字で応答しました。カウンターはそれ自体がひとつのバージョンで、バイヤーが作成し、明細ごとの依頼価格を持ちます。マーチャントがそれを開くと見積は確認中に戻り、次の提案はバージョンn+1になります。下書き注文はこの状態をまったく表現できません。下書きに対してバイヤーができるのは、支払うか待つかだけです。

一部承諾と全明細承諾。 バイヤーがすべての明細、または真部分集合を受け入れました。選ばれなかった明細は未決のままで、後のラウンドで承諾されるか、再提案されます。承諾された明細の価格はここで封印され、これ以降は何も価格を編集しません。Professionalプラン以上ではバイヤーが明細ごとに決めます（一部承諾の仕組み）。どのプランでも、提案全体の承諾はあります。

一部変換済み、全明細変換済み、請求書送信済み、注文完了。 ここで下書き注文が存在します。最初の下書き注文で見積は一部変換済みになります。承諾された部分集合が下書き注文になる一方で、残りは再交渉されうるからです。承諾されたすべての明細に下書き注文ができれば全明細変換済み、各下書きの請求書が送られれば請求書送信済み、Shopifyの orders/create Webhookが注文の存在を伝えれば注文完了です。これらの状態はShopifyの3つの状態と注文を映したもので、見積レイヤーの推測ではなくShopifyのイベントによって進みます。

辞退、期限切れ、注文キャンセル、注文返金、クローズ。 終わりです。別々になっているのは、報告のされ方が違うからです。辞退された提案は価格のシグナル、期限切れの提案はフォローアップのシグナル、返金された注文は経理の案件です。そして「クローズ」は、担当者が他のどの終わりも明示的にアーカイブするための状態です。

「承認のために送信」はマーチャントの確認であって、バイヤーの交渉ではない

Shopifyのネイティブ B2Bが「バイヤーがこれを欲しい」と「支払い済み」の間に状態を置く唯一の場所が、会社所在地の設定「すべての注文を確認用の下書きとして送信」です。見積ワークフローと誤解されやすいので、はっきり説明しておく価値があります。

この設定が有効だと、その所在地からの注文はすべて下書きとして届きます。バイヤーはカタログ価格でカートを作り、注文確定時に支払いが発生するというバナーを見て、承認のために送信を押します。下書きは価格がロックされた状態で現れます。マーチャントはそれを確認し、商品と数量を編集でき、支払い条件を設定でき、注文を作成するか請求書を送ります。有効化は所在地ごと、会社ごと、一括、あるいは所在地作成時のShopify Flowアクションで行えます。

これが表しているのは保留です。注文が確定する前にマーチャントが確認する機会です。バイヤーは価格について何も提案しません。価格はカタログのものです。マーチャントの編集は下書きに対して行われ、同意を求めて差し戻されることはありません。バージョンもカウンターも承諾ステップもなく、バイヤーの次の行動は支払いです。取引が「注文を確認して請求する」だけのマーチャントにとってはこれが正しい道具で、見積レイヤーは余計な負担になります。見積アプリを使うべきでないときは、このケースを他のケースとともに挙げています。取引に2つ目の価格が現れた瞬間、保留だけでは足りなくなります。

遷移はどう強制されるか

状態の一覧は、状態間の遷移が列挙され、それ以外がすべて拒否されるまでは状態遷移ではありません。これが見積レイヤーをステータス列と分ける工学的な細部であり、QuotWayの実装をパターンとして説明する価値があるのはここです。

許可された操作はひとつずつ表の行になっています。出発する状態、入る状態、誰が実行できるか（バイヤー、マーチャント、システム）、そして書き込むイベントです。「提案送信済み → カウンター」はバイヤーに許可され、カウンターイベントを書きます。「カウンター → 確認中」はマーチャントに許可され、確認イベントを書きます。「全明細承諾 → 一部変換済み」はマーチャントまたはシステムに許可されます。変換はログインユーザーのいないキューから実行されることがあるためで、変換グループ作成イベントを書きます。表にない遷移は例外を投げ、状態変更とそのイベントはひとつのデータベーストランザクションで書かれるため、例外は両方をロールバックします。見積が、履歴では説明できない状態に取り残されることはありません。

表には2つのワイルドカードのルールがあり、独自開発で最も忘れられやすいのがこの2つです。終端でないどの状態も、有効期限が過ぎれば期限切れに移れます。すべての状態に適用されるひとつのルールで、日次のスイープが実行するため、見積が珍しい状態にいることで期限切れを逃れることはありません。そして、どの終端状態も担当者のアーカイブであるクローズに移れます。終端状態は5つ、辞退、期限切れ、注文キャンセル、注文返金、クローズです。注文完了は意図的に終端に含めていません。Shopifyの orders/updated Webhookがキャンセルや返金をまだ報告しうるため、見積は注文の後を追えなければならないからです。

変換の状態も、このパターンが効くもうひとつの場所です。見積は draftOrderCreate を呼んだ時点で自分が「変換済み」だと決めません。下書き注文のIDを記録して待ちます。orders/create が届いた時点で注文完了に移ります。マーチャントが明示的に請求書を送る前にバイヤーが請求書URLから支払うケースも含まれ、状態遷移はこれを全明細変換済みからの直接遷移として許可しています。ShopifyのWebhookではなくAPI呼び出しの成功で自分の状態を進める構築は、いつか放棄されたチェックアウトに「注文完了」を表示することになります。

同じ表が、監査証跡に1年後の問いを答えさせるものでもあります。すべての遷移が主体を名指しし、イベントを書くため、「この価格を誰が承認したか」「バイヤーはバージョン2を見たのか」「この見積はなぜ期限切れなのか」は、調査ではなく参照になります。

下書き注文の置き場所

本来の仕事に限定すれば、下書き注文は設計の中で最も優れた部分です。回収はShopifyがやってくれるからです。パターンはこうです。承諾の時点で一度だけ作成し、交渉で決まったことをすべて載せる。

交渉済みの単価は、各バリアント明細に表示通貨の priceOverride として載せます。これで注文は承諾されたバージョンと1円単位で一致します。カスタム明細は自身の価格を持ちます。purchasingEntity（会社、所在地、担当者）がこれをB2Bの下書きにし、所在地の免税とチェックアウト設定が適用されます。取引で決まった支払い条件テンプレートは下書きに設定し、取引に前受金が含まれる場合（Shopify Plusストアで、QuotWayのProfessionalプラン以上、1〜99%）は前受金も下書きに載るため、チェックアウトが前受金を回収し、Shopifyが残額をスケジュールします。発注書番号とバイヤーのメモは下書きのフィールドに入ります。作成前に draftOrderCalculate で合計をプレビューし、提案以降の税、配送、在庫の変化を請求書で気づく前に検出して表示します。価格の受け渡しの詳細はアーキテクチャの記事で、マーチャント側の見え方は変換機能のページで扱っています。

一部承諾は、承諾された明細だけの下書き注文になります。未決の明細は次のラウンドに向けて見積に残り、後の承諾は2つ目の下書き注文になります。見積に一部変換済みという状態があるのはそのためで、変換が承諾された集合ごとに冪等であるのもそのためです。失敗した作成を再試行しても、同じ明細に対して2つの下書きができてはなりません。

ここから先はShopifyの状態遷移が自走します。draftOrderInvoiceSend で下書きは請求書送信済みになり、チェックアウトリンクがメールされます。バイヤーは支払うか、支払い条件に従って後日カスタマーアカウントから支払います。下書きは完了し、注文が保留中、一部支払い済み、支払い済みのいずれかの支払いステータスで存在します。見積レイヤーはそれを聞いて映します。送信後の下書きは編集しません。交渉は終わっており、編集は進行中のチェックアウトの紐付けを外すからです。そして、下書きを価格を開き直す場所として扱うことも決してありません。承諾後に価格を変えなければならないなら、それは見積上の新しい提案、新しい承諾、新しい下書き注文です。マーチャント側の操作はB2B向けShopify下書き注文に、下書き注文自体の落とし穴（既定で在庫を確保しない、500明細の上限、1年後の削除）は制限の記事にまとめています。

下書き注文が見積として使われている5つの兆候

エージェンシーが救済案件で目にするものを、早めに気づけるように挙げておきます。

1. 下書き注文ページがパイプラインになっている。 何十件もの未処理の下書き。数か月前のものもあり、「v3 - バイヤー待ち」のようなメモがついている。1年後の削除がいずれ最も古いものを消し、各件がどの段階にあるかのレポートは存在しません。オブジェクトに段階がないからです。
2. 価格がその場で書き換えられている。 4回の値引き交渉のために4回編集された下書き。タイムラインの「編集」という項目以外に、1回目から3回目の記録はありません。バイヤーが最終金額に異議を唱えたとき、以前に何を提示したかを誰も示せません。
3. 請求書が提案として送られている。 請求書が提案であり、「バイヤーが支払っていない」ことだけが承諾されなかったシグナルです。支払い条件があると事態は悪化します。Net 30の未払い請求書は、1か月間、辞退された請求書と見分けがつかないからです。
4. バイヤーのカウンターがメールで届く。 下書きにはバイヤーが作成する状態がないため、交渉は受信トレイで進み、下書きは後から手作業で更新されます。両者がずれた瞬間、注文は間違ったものになります。
5. 承認がSlackのメッセージになっている。 営業担当が上長に値引きの可否を尋ね、親指の絵文字をもらって下書きを編集する。承認と、承認された価格を結びつけるものは何もありません。

どれも、下書き注文が持てない状態が、代わりにどこか非公式な場所で保持されている姿です。解決策はより大きな下書き注文ではなく、その手前に置く見積オブジェクトです。

よくある質問

Shopifyで下書き注文と見積は何が違いますか？

下書き注文は、支払いを待つ注文のShopifyの記録です。状態は未処理、請求書送信済み、完了の3つで、明細はそれぞれ価格をひとつ持ちます。見積は、その価格に至る過程の記録です。バイヤーの依頼、売り手の番号付き提案、カウンターオファー、承認、承諾。Shopifyには見積オブジェクトがないため、見積レイヤーがこれらの状態を保持し、価格が合意された時点で下書き注文を作成します。

下書き注文をそのまま見積として使ってはいけないのはなぜですか？

下書き注文には、合意より前のことを入れるフィールドがないからです。依頼価格、カウンターオファー、ロックされたバージョン、承認の判断、明細ごとの承諾のどれも保持できず、明細は編集のたびに丸ごと置き換わり、タイムラインは開き直せるバージョンではなくテキストです。1ラウンドで終わる取引（バイヤーが送信し、マーチャントが確認し、バイヤーが支払う）なら収まりますが、2つ目の価格がある取引は収まりません。

Shopifyの下書き注文のステータスにはどんなものがありますか？

3つです。API 2026-07の列挙型 DraftOrderStatus にある OPEN（未払い、請求書未送信）、INVOICE_SENT（請求書が顧客にメール送信済み）、COMPLETED（支払い済み）です。完了後は、作成された注文が独自の支払いステータス（保留中、一部支払い済み、支払い済み、返金済みなど）を持ちます。

「承認のために送信」は見積ワークフローですか？

いいえ。会社所在地の設定で、その所在地からのすべての注文を、マーチャントが確定前に確認する下書きに変えるものです。バイヤーはカタログ価格のカートを送信し、マーチャントはそれを編集したうえで請求するか注文を作成します。バイヤーからの価格提案も、バージョンも、承諾ステップもありません。表しているのは注文の保留で、請求前に注文を確認したいだけのマーチャントにはまさに適切な機能です。

請求書を送った後の下書き注文は編集できますか？

できます。draftOrderUpdate には請求書送信済みの下書きに対する制限がなく、どんな編集も1年間の非アクティブ削除のタイマーをリセットします。ただしShopifyは、チェックアウト開始後の更新はそのチェックアウトとの紐付けを外すと警告しています。その場合、下書きが未処理のまま注文が作成されることがあります。この変更可能性こそが、下書き注文を提案の記録として不適切にするものです。送信した提案は、その場で編集できてはなりません。

下書き注文はいつ作成すべきですか？

承諾の時点で、一度だけです。交渉済み価格を明細の priceOverride に、購買主体、支払い条件、前受金があればそれも、発注書番号も載せた状態で作成します。提案の時点など早く作ると、変更可能で削除されうるオブジェクトが交渉の真ん中に置かれます。遅く作ると、バイヤーには支払う対象がありません。一部承諾なら、承諾された明細の下書きを作成し、残りは見積に未決のまま残します。

見積には有効期限がありますか？下書き注文には？

性質が違います。見積の有効期限は売り手が設定する商取引上の期日で、過ぎれば承諾もカウンターもできなくなり、バイヤーには新しい提案が必要です。下書き注文にある唯一のタイマーは整理用です。2025年4月1日以降に作成された下書きは、編集がないまま1年経つと削除されます。どちらも、もう一方の役割を担わせるべきではありません。

出典

Shopifyのページ。いずれも2026年9月21日、APIバージョン2026-07で確認：

• DraftOrderオブジェクト、DraftOrderStatus列挙型、BasicEvent
• draftOrderUpdate、draftOrderComplete
• B2Bアプリ向けの下書き注文
• 下書き注文でB2B注文を作成する、B2Bのチェックアウト設定を管理する
• B2Bの支払い条件を設定する、PaymentTermsオブジェクト、OrderDisplayFinancialStatus
• 下書き注文の請求書を送信する、下書き注文と請求書
• Flowアクション：会社所在地のチェックアウトを下書きに更新
• チェンジログ 2024年7月8日：支払い条件つきで下書き注文の請求書を送信

QuotWayの状態遷移、遷移ルール、変換の挙動はソースコードに基づいて記述しています。マーチャント向けの説明は提案を作成して送信する、承認の強制はどう働くか、見積を下書き注文に変換するにあります。プランごとの違いは料金ページをご覧ください。