交渉中にカタログ価格が変わったら：見積はどの価格を使うべきか

見積が進行中のあいだにカタログ価格が変わっても、バイヤーが手にしているオファーが変わってはなりません。変わるべきなのは、販売者に表示される内容と、次の販売者バージョンをチェックする基準です。そのためには明細ごとに4つの価格が必要で、それぞれが1つの役割を持ちます。明細が見積に入ったときに取り込んだカタログ価格、バイヤーが今日支払うことになる現在の価格、バイヤーの希望価格、そして提示価格です。提示価格は送信した時点で固定されます。現在の価格は販売者が送信するたびにサーバー側で解決し直し、バージョンに保存します。バイヤーのカウンターオファーはそれを変えずに引き継ぎ、送信済みのバージョンの価格は付け直しません。承諾された見積がShopifyの下書き注文になるときは、承諾された価格を明示的に送ります。

この記事はその設計を、簡略化したコードとともに説明します。送信済みのバージョンを編集しない理由は見積のバージョンを書き換えないで、下書き注文の側は見積が間違った価格で変換される理由で扱っています。この記事が扱うのはその間、交渉が続いている期間です。QuotWayを例にする箇所は現在の動作として説明し、それ以外は推奨であることを明記しています。

以下のShopifyに関する事実は、2026年10月31日にAPIバージョン2026-10でShopify自身のページと照合しました。出典は末尾にあります。

Shopifyの価格が動くところ

Shopifyでは「カタログ価格」は1つの数字ではありません。バイヤーの価格はいくつかの入力の結果であり、それぞれが独立して変わります。

変わるもの	バイヤーの価格への影響	Webhookで通知されるか
バリエーションの価格	既定の価格と、割合調整で設定された価格リストの価格がすべて動く	products/update - 商品が注文されたときにも発生する
価格リストの固定価格	そのバイヤーの、そのバリエーションの価格だけが動く	価格リストを名指しするトピックはない
価格リストの割合調整	固定価格も数量別価格もないリスト上のすべてのバリエーションが動く	価格リストを名指しするトピックはない
固定価格の削除	リストの割合調整に戻る	価格リストを名指しするトピックはない
数量別価格と数量の段階	しきい値を超える数量の価格が変わる。商品に数量別価格を設定すると、その商品にはカタログの割合調整が適用されなくなる	数量の段階を名指しするトピックはない
バイヤーへの別のカタログの割り当て	価格が変わることがある。「より具体的な価格が使われ」、どちらのカタログもより具体的でない場合は低いほうの価格	記載なし
マーケットの為替レート	換算後の価格は、手動レートや国際固定価格を使わない限り「マーケットの為替レートに合わせて自動的に変わる」	なし

この表から、設計の残りを決める2つの結論が出ます。第一に、BtoBの価格変更を網羅する購読可能なイベントはないので、見積レイヤーは通知を待って価格を最新に保つことができません。重要なタイミングで価格を解決し直す必要があります。第二に、バリエーション自体の価格は、BtoBのバイヤーにとって正しい数字ではありません。正しい数字は、そのバイヤーにとって、その数量で、すべての調整を適用したあとの価格です。

4つの価格、4つの役割

各明細は4つの価格を持ちます。どの判断にどれを使うのかを問うまでは、重複しているように見えます。

価格	役割	書き込むとき	読み直すとき
取り込み時のカタログ価格	履歴：依頼したときにバイヤーが見ていた価格	明細が見積に入ったときに1回	読み直さない
現在の価格（基準価格）	判断の基準：値引き率、下限価格のチェック、承認のしきい値	販売者が送信するたびに、サーバー側で	エディターを開いたとき（表示用）、販売者が送信するたび
希望価格	バイヤーの要望	バイヤーが依頼を送信したとき、またはカウンターオファーを出したとき	読み直さない - カウンターオファーは新しいバージョン
提示価格	オファー	販売者がバージョンを送信したとき	読み直さない - 次のオファーは新しいバージョン

取り込み時の価格と現在の価格は、意図して分けています。1つにまとめると、履歴（依頼したときにバイヤーは何を見ていたか）か、判断の根拠（この値引きは今日の時点でどれほど深いか）のどちらかが失われます。オファーを3週間前のカタログ価格と比べる下限価格のルールは、間違った値引きをチェックしています。

解決し直すタイミング、解決し直さないタイミング

現在の価格は決められたいくつかのタイミングで読み取り、それぞれの目的は異なります。

タイミング	現在の価格を解決し直すか	理由
受付 - バイヤーが依頼を送信する	バイヤーが見ていた価格を記録する。判断に使う前にサーバー側で解決する	ストアフロントはバイヤーに表示した価格を送信でき、それは正しい履歴になります。ただし、ブラウザーから送られた価格は、サーバーが解決するまでカタログと照合できないので、確認しないまま判断の基準にすべきではありません。
エディターを開く - 販売者が見積を開く	はい、表示用に	販売者はオファーを書く前に、何が変わったかを見るべきです。何も保存しません。
販売者の送信 - 新しいバージョンを送る	はい、正式な値として。バージョンに保存する	下限価格と承認のチェックはこの数字で行います。保存しておけば、あとから判断を説明できます。
バイヤーのカウンターオファー	いいえ - バージョンの基準価格を引き継ぐ	バイヤーはあるバージョンに答えています。その下で価格を付け直すと、バイヤーが答えた問いが変わってしまいます。
承認の再評価	いいえ - 保存した基準価格を使う	承認者は、より新しい価格ではなく、実際に送られる数字で判断します。
バージョンの送信後	決して解決し直さない	送信済みのバージョンは文書です。変わった価格は、次の販売者バージョンのための情報です。
下書き注文への変換	いいえ - 承諾された価格を強制する	価格を明示しなければ、Shopifyは明細に現在のカタログ価格を付けます。

最後の行は最も見落とされやすいもので、見積が間違った価格で変換される理由で詳しく扱っています。バリエーションの明細では priceOverride がカタログ価格を置き換えます。バリエーションを指定した場合、カスタム明細用の価格フィールドは無視されます。

contextualPricingで現在の価格を解決する

ShopifyのAdmin APIは、バイヤーの価格を1つのフィールドで解決します。その背後にあるカタログ、価格リスト、数量ルールの連鎖はShopifyのB2B見積は何を起点にすべきかで順に説明しています。ProductVariant.contextualPricing はコンテキスト（BtoBのバイヤーなら companyLocationId、マーケットなら country）を受け取り、「すべての調整を適用したあとの最終価格」、数量の段階、数量ルール、そして「最終価格を決めるために使われた調整を、適用された順に」記録する auditTrail を返します。

query CurrentPrices($ids: [ID!]!, $location: ID!) {
  nodes(ids: $ids) {
    ... on ProductVariant {
      id
      contextualPricing(context: { companyLocationId: $location }) {
        price { amount currencyCode }
        quantityPriceBreaks(first: 10) {
          nodes { minimumQuantity price { amount currencyCode } }
        }
        auditTrail { priceAdjustments { __typename } }
      }
    }
  }
}

数字が正しいかどうかは、3つの点で決まります。

明細の数量で解決する。 price は1単位の価格です。500単位のBtoBの明細は数量の段階を超えていることがあり、その場合のバイヤーの本当のカタログ価格は段階の価格です。オファーを1単位の価格と比べると、どの値引きも実際より深く見え、必要のない商談で下限価格と承認が作動します。数量の段階はバリエーションごとに適用され、バリエーションをまたいで合算されません。スケッチ（推奨）：

// 指定した数量でのバイヤーのカタログ価格：数量が届いている最も高い段階、
// なければ基本のcontextual価格。
function priceAtQuantity(cp: ContextualPricing, quantity: number): Money {
  const reached = cp.quantityPriceBreaks.nodes
    .filter((b) => b.minimumQuantity <= quantity)
    .sort((a, b) => b.minimumQuantity - a.minimumQuantity)[0];
  return reached ? reached.price : cp.price;
}

出所を残す。 数字の隣に、それがどこから来たかを保存します。使ったコンテキスト、時刻、そして判別できるならカタログです。「42.00に対して18%の値引き」は、42.00が何だったかを言えて初めて検証できます。監査証跡は価格がどのように決まったかの説明に役立ちますが、カタログや価格リストの名前は含まず、Shopifyが完全な証跡を返せない場合は空になります。

失敗が何を意味するかを決めておく。 Shopifyがタイムアウトすることも、スコープが足りないこともあります。現在の価格がわからないからといって下限価格のチェックを黙って飛ばすと、障害がそのまま価格の抜け穴になります。最後に保存した基準価格に戻して明細にフラグを立てるか、基準価格がまったくない明細は送信を止めます（推奨）。どちらも筋が通りますが、「基準価格がないのでチェックしない」は通りません。

何が変わったかを販売者に伝える

エディターを開いたときに解決し直しても、販売者が結果を見なければ意味がありません。販売者がオファーを書く前に、明細ごとに取り込み時の価格、現在の価格、その差を表示します。そうすれば、対応は偶然ではなく判断になります。価格が変わったとき、誠実な選択肢は3つです。

• オファーを守る。 バイヤーは古い価格の送信済みバージョンを手にしています。有効期限まで守ります。有効期限は、あなたが選んだ価格保証の期間です。その期間の決め方は見積の有効期限はどれくらいにすべきかにまとめています。
• 見積を出し直す。 新しい価格の新しい販売者バージョンを、理由とともに送ります。古いバージョンは手を加えずに履歴に残ります。
• 失効させる。 そのうえで現在の価格から始め直します。

価格が下がる場合にも注意してください。現在の価格が進行中のオファーより下がると、バイヤーはストアでその低い価格を見ることができます。値上がりと同じようにこのケースにもフラグを立てます。バイヤー自身のカタログ価格より高いオファーは、利益率の問題であるだけでなく、信頼の問題です。

通貨：為替レートも価格の一部

バイヤーの通貨で出す見積では、為替レートも動く入力の1つです。Shopifyは、ストアが手動レートを使わない限り価格を「マーケットの為替レートに合わせて自動的に」換算し、「国際固定価格は常に手動の換算レートより優先されます」。

これを扱いやすくするルールは2つです（推奨）。見積の通貨は見積を作成したときに固定し、送信済みのオファーは換算しません。現在の価格が見積と異なる通貨で返ってきたら、記録したレートで換算し、どのレートを使ったかも記録します。「価格が上がった」と「レートが動いた」では、バイヤーとの会話がまったく違うからです。下書き注文の側で、別の通貨で下書きを作成または編集したときにShopifyが何をするかは、為替レートの節で扱っています。

決して動かないもの

• 送信済みのバージョンの価格。送信後のカタログの変更はオファーに影響しません。
• 承諾された明細。承諾は対象のバージョンを名指しし、その価格を記録します。
• 下書き注文の明細の価格。承諾されたバージョンから明示的に送るので、現在のカタログ価格に置き換わることはありません。

最初の2つが成り立つ理由は見積のバージョンを書き換えないで、3つ目を重複なしに実現する方法は下書き注文をちょうど1回だけ作るで説明しています。

自分で作るときのテストケース

1. 見積を送信したあとでバリエーションの価格を上げる。送信済みのオファーとバイヤーの画面は変わらない。
2. 価格を上げてから、新しい販売者バージョンを送る。新しいバージョンに新しい現在の価格が保存され、下限価格のチェックにそれが使われる。
3. BtoBの価格リストの固定価格を変える。Webhookがなくても、次にエディターを開いたときに変更が表示される。
4. 価格リストの割合調整を変える。固定価格のないバリエーションはすべて動き、固定価格のあるバリエーションは動かない。
5. 100で段階があるバリエーションを500単位で見積もる。基準価格は1単位の価格ではなく段階の価格になる。
6. 価格が変わったあとでバイヤーにカウンターオファーを出させる。カウンターオファーはバージョンの基準価格を引き継ぎ、何も取得し直さない。
7. 価格の解決を失敗させる。送信は止まるか、フラグ付きの保存済み基準価格で進む。下限価格のチェックなしで進むことはない。
8. 価格を進行中のオファーより下げる。販売者に値下がりが表示される。
9. 承諾し、カタログ価格を変え、それから変換する。下書き注文は承諾された価格を持つ。

QuotWayでの位置づけ

会社に紐づく見積では、QuotWayは販売者が送信するたびに、エディターのコピーからではなく、サーバー側で contextualPricing と見積の会社所在地を使って会社所在地の価格を解決し直します。その価格をバージョンの各明細に保存し、解決に使ったカタログをバージョンに記録し、下限価格と値引き承認の基準価格として使います。バイヤーのカウンターオファーは、取り込み時のカタログ価格とその基準価格の両方を、どちらも取得し直さずに引き継ぎます。提案エディターは各明細のカタログの参照元を表示し、商品がバイヤーの会社所在地のカタログに含まれていない場合は警告します。送信済みのバージョンの価格が付け直されることはなく、承諾された見積を変換するときは、Shopifyの下書き注文のすべての明細に承諾された価格を送ります。

会社に紐づく見積には、EnterpriseプランとB2Bを利用するShopifyストアが必要です。ShopifyのB2B見積、交渉、料金をご覧ください。

よくある質問

カタログ価格の変更は、送信済みの見積に影響しますか？

影響すべきではありません。送信済みのバージョンは自分の価格を保存しているので、バイヤーが手にしているオファーは送信したときのままです。変更が意味を持つのは、下限価格と承認のチェックに現在の価格を使うべき次の販売者バージョンと、変換のときです。変換では承諾された価格を明示的に送らなければ、Shopifyは現在のカタログ価格を使います。

値引き承認と下限価格には、どの価格を使うべきですか？

その明細のバイヤーの現在の価格です。販売者が送信するときにサーバー側で、明細の数量で解決し、バージョンとともに保存したものです。何週間も前かもしれない、明細が見積に入ったときに取り込んだ価格でも、ブラウザーから送られた価格でもありません。

BtoBの価格リストの変更を知らせるShopifyのWebhookはありますか？

価格リストを名指しするものはありません。APIバージョン2026-10のWebhookトピックには、バリエーションが変わったとき（と商品が注文されたとき）に発生する products/update がありますが、価格リスト、カタログ、数量の段階を名指しするトピックはありません。イベントに頼らず、見積が価格を必要とするタイミングで解決し直してください。

Admin APIで会社所在地の価格を取得するには？

商品バリエーションの contextualPricing を context: { companyLocationId: ... } で照会します。すべての調整を適用したあとの最終価格、数量の段階、数量ルール、適用された調整の監査証跡が返ります。明細の数量に合う段階の価格を選んでください。

バイヤーのカウンターオファーは、現在のカタログで価格を付け直すべきですか？

いいえ。カウンターオファーは特定のバージョンに答えるものなので、そのバージョンの価格と基準価格を引き継ぎます。バイヤーの下で価格を付け直すと、バイヤーが答えた問いが変わってしまいます。新しい価格は、販売者が次のバージョンを送るときに取り込みます。

見積が進行中にカタログ価格が下がったら？

販売者にフラグで知らせます。バイヤーの現在のカタログ価格より高いオファーは、バイヤーがストアで気づくことができます。販売者は新しいバージョンとして低い価格で見積を出し直すことも、オファーを維持して理由を説明することもできます。どちらにしても、チェックアウトで発覚するものではなく、判断であるべきです。

出典

2026年10月31日に参照したShopifyのページ（APIバージョン2026-10）：

• WebhookSubscriptionTopic：products/update と、存在するトピック
• ContextualPricingContextとProductVariantContextualPricing：コンテキストのフィールド、最終価格、数量の段階、監査証跡
• PricingAuditTrailとQuantityPriceBreak
• PriceListとPriceListPriceOriginType：固定価格と相対価格
• Build a catalog：割合調整、固定価格の削除、contextualPricing による価格の確認
• Catalogs with Markets：「より具体的な価格が使われる」、どちらのカタログもより具体的でない場合は低いほうの価格
• Currency conversions and exchange rates：マーケットのレート、手動レート、国際固定価格

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