Shopifyエージェンシー向け
会社、所在地、カタログ、そしてShopify B2Bの見積はどの価格から始めるべきか
著者 Jahangir Alam · 2026年9月21日 · 約15分で読めます
- 最終確認日
- Shopify API
- 2026-07
- 対象読者
- Shopifyエージェンシー、開発者、ソリューションアーキテクト
- 範囲
- API 2026-07におけるShopify B2Bの会社、所在地、B2Bマーケット、カタログ、価格表、数量ルールと数量別価格、そして見積の明細をどの価格から解決すべきか
Shopify B2Bの見積は、バイヤーがすでに見ている価格から始めるべきです。つまり、Shopifyがそのバイヤーの会社所在地に対して、依頼された数量で、そのマーケットの通貨で、依頼した日に解決する価格です。この数字は保存されるものではなく導出されるものであり、見積レイヤーの仕事は、依頼の時点でそれを読み取り、出所とともに記録し、そこから交渉することです。自前のコピーを持つことでは決してありません。
導出は、会社 → 所在地 → 該当するカタログ → 価格表の固定価格またはパーセント調整 → 数量ルールと数量の価格帯 → ひとつのコンテキスト単価、という順に進みます。この連鎖のどの環も、結果の数字を変えうるのです。
このページは、その導出を書き下したものです。どのShopifyオブジェクトが連鎖の上にあるのか、ひとつの所在地に複数のカタログが該当するとき何が起きるのか(ルールは文書化されており、「最安」だけではありません)、誰かが交渉する前に数量が価格をどう変えるのか、そして見積レイヤーはその結果をどう保持すべきなのか。「見積アプリはカタログと衝突しないか?」「会社に交渉済みのカタログ価格があるなら、見積依頼はどの価格から始めるべきか?」と尋ねられるエージェンシーのために書いています。この2つの問いが、B2B構築の価格表が1つになるか2つになるかを決めます。
以下のShopifyに関する記述はすべて、2026年9月21日にAPIバージョン2026-07でShopify自身のページと照合しました。出典は末尾にあります。QuotWayが価格をどう解決するかを説明している箇所は、このパターンの実装例のひとつです。
連鎖を、オブジェクトごとに
会社と会社所在地。 会社はアカウントで、所在地が実際に販売する相手です。カタログ、支払い条件、税設定、チェックアウト設定はすべて所在地に紐づくため、バイヤーが見る価格は、どの会社に属しているかではなく、どの所在地のために注文しているかで決まります。同じ会社の2つの所在地のために注文する担当者は、同じSKUに2つの価格を見ることがあります。見積が会社IDだけでなく所在地IDを持たなければならない理由は、アーキテクチャの記事で説明しています。
B2Bマーケット。 どのプランでも、所在地は条件を満たすB2Bマーケットに属します。「すべての地域のすべての会社所在地」、「特定の地域内のすべての会社所在地」(所在地の配送先住所で照合され、新しい所在地は自動的に一致します)、または「特定の会社所在地」です。マーケットは通貨を決め、カタログを紐づけます。Plus未満では、これがカタログが所在地に届く唯一の経路であり(Basic、Grow、AdvancedはすべてのB2Bマーケット合計で有効なカタログ3件まで)、所在地のないマーケットはB2B価格をまったく提供しません。所在地は複数のマーケットに一致することがありますが、これは機能というより設計上の危険信号です。Shopifyは、バイヤーの体験は一致したマーケットに従うとしか述べていません。
カタログ。 カタログは2つのものからできています。所在地がどの商品を見られるかを決める公開と、その商品がいくらかを決める価格表です。どちらの半分も欠けることがあり、その場合に何が起きるかをドキュメントは正確に述べています。価格表がなければ、所在地は「バリアントの初期価格をマーケット通貨に換算したもの」を受け取り、公開がなければ、「B2Bアカウントにログインした顧客には、その所在地の商品は何も表示されません」。Plusではカタログを会社や所在地に直接割り当てることもでき、1つの所在地は最大25件、1つのストアは最大10,000件まで持てます。
価格表。 その中で、商品の価格は、全バリアントに対する固定価格か、基本価格に対するパーセントの増減である全体調整の結果のどちらかです。両方があれば固定価格が勝ちます。比較価格は引き継ぐことも無効にすることもできます。数量別価格と数量ルールもここに、バリアントごとに存在します。
数量ルールと数量別価格。 バリアントには最小、最大、増分を設定でき、価格帯は最大10段階で、それぞれ最小数量から適用されます。どちらもバリアントごとで、バリアント間で合算されることはありません。見積にとって重要な帰結が2つあります。商品に数量別価格を設定した時点でその商品の価格は固定され、カタログの全体調整はその商品には適用されなくなります。そして複数のカタログが該当する場合、数量ルールと価格帯は「バリアントごとに最安のカタログ」から来ます。
解決。 Shopifyは以上のすべてを、バリアントごと、コンテキストごとに1つの数字にまとめます。Liquidでは variant.price で、「顧客のローカル(表示)通貨で出力され」、quantity_price_breaks は「現在の顧客コンテキストにおけるバリアントの」価格帯です。Admin APIでは ProductVariant.contextualPricing(context: { companyLocationId }) で、price(「すべての調整を適用した後の最終価格」)に加えて、その所在地の quantityRule と quantityPriceBreaks を返します。これが見積の出発点となる数字です。
複数のカタログが該当するとき
「最安が勝つ」は誰もが覚えている文ですが、ルールの半分でしかありません。ShopifyのMarketsドキュメントは2つのルールを示しており、順序が重要です。第一に、「会社所在地に割り当てたカタログと、一致するB2Bマーケットに割り当てたカタログが同じ商品を異なる価格で含む場合、B2Bストアはその商品について最も具体的な価格、つまり会社所在地に割り当てたカタログの価格を表示します」。直接割り当てがマーケット割り当てに勝ちます。第二に、「同じ会社所在地に割り当てたカタログが同じ商品を異なる価格で含む場合、B2Bストアはその商品の最も低い価格を表示します」。同じ階層のカタログ同士では最安が勝ちます。数量ルールと数量別価格はそのうえで「バリアントごとに最安のカタログ」に従います。
次の表は、エージェンシーが出会う構成と、それぞれでバイヤーが見るものを並べています。これ以外から始まる見積は、バイヤーが一度も見せられていない価格から始まっています。
| 構成 | その所在地のバイヤーが見るもの | 出典 |
|---|---|---|
| 所在地のB2Bマーケット経由で割り当てられたカタログが1つ | そのカタログの価格、マーケット通貨で | ヘルプ:B2BとMarkets |
| 同じ商品を含むマーケットのカタログが2つ | 2つのうち低い方の価格。数量ルールと価格帯は安い方のカタログのもの | ヘルプ:Marketsのカタログ |
| 同じ商品を含む、マーケットのカタログと所在地への直接カタログ(Plus) | 直接カタログの価格(「最も具体的」)。マーケットのカタログの方が安くても同じ | ヘルプ:Marketsのカタログ |
| 同じ商品を含む、所在地への直接カタログが2つ | 低い方の価格 | ヘルプ:Marketsのカタログ |
| 公開はあるが価格表のないカタログ | バリアントの基本価格をマーケット通貨に換算したもの | shopify.dev:カタログの管理 |
| 価格表はあるが公開のないB2Bカタログ | その所在地には商品が一切表示されない | shopify.dev:カタログの管理 |
| 所在地のどのカタログにも公開されていない商品 | 表示されず、ストアから注文できない | shopify.dev:カタログの管理 |
| 1つの商品に固定価格と全体調整の両方 | 固定価格 | ヘルプ:B2B価格のカスタマイズ |
| 商品に数量別価格を設定 | その商品の価格は固定され、カタログの全体調整は適用されなくなる。到達した価格帯がバリアントごとに適用される | ヘルプ:数量ルールと数量別価格 |
| どのB2Bマーケットにも属さず、直接カタログもない所在地 | B2B価格なし。「会社所在地のないB2Bマーケットは、B2B価格を提供しません」 | ヘルプ:MarketsでのB2B管理 |
| 2つのB2Bマーケットに一致する所在地 | Shopifyは、体験は「一致したマーケットのカスタマイズによって決まる」とだけ述べている。マーケットの条件を重ならないようにして回避する | ヘルプ:MarketsでのB2B管理 |
エージェンシーが引き継ぐサポートチケットの大半は、このうち2行から生まれます。「公開はあるが価格表がない」行は「カタログを割り当てたのに小売価格が表示される」を生み、「価格表はあるが公開がない」行は「カタログを割り当てたのに何も表示されない」を生みます。どちらも半分が欠けたカタログであり、どちらも見積レイヤーから見れば完全に有効なコンテキスト価格に見えます。
誰かが交渉する前に、数量が価格を変える
500個の依頼は、単価での依頼ではありません。バリアントに数量別価格があるなら、バイヤー自身のストアはすでに500個でより低い価格を見せており、単品価格から始まる見積は、Shopifyが無料で出したはずの数字まで値下げ交渉させることになります。
だから開始価格は依頼された数量で解決します。Liquidでは、ストアがバイヤーのコンテキストにおけるバリアントの quantity_price_breaks を持っています。APIでは contextualPricing(companyLocationId) が quantityPriceBreaks を返し、それぞれ minimumQuantity と「最小数量に到達した後の」price を持ち、quantityRule も一緒に返ります。数量Qの明細の基準は、Qが最小数量に到達する最も高い価格帯であり、該当する価格帯がなければコンテキスト単価です。そして数量ルールは、Qがそもそも注文可能かを示します。最小未満、最大超過、増分に合わない場合、その明細は変更なしには下書き注文の明細になれず、マーチャントが価格をつける前に見積がそれを伝えるべきです。
Shopifyの「バリアントごと」のルールから2つの細かい点が導かれます。価格帯はバリアント間で合算されないため、青300個と赤200個ではどちらも500個の価格帯に届きません。それらを合算する見積は、カタログにない価格を提示しています。そして商品に数量別価格があるとその価格は固定されるため、カタログ全体の20%調整はその商品には黙って適用されなくなります。バイヤーはその商品で隣の商品より高い単価を見ているかもしれず、見積はカタログの見出しの調整が示唆するものではなく、バイヤーが見ているものから始めるべきです。
3つの数字を分けて持つ
見積明細には3つの価格が必要で、見積レイヤーを第二の価格表に変えてしまう失敗は、そのうち1つしか保存しないことです。
基準価格は上で述べたコンテキスト価格です。所在地に対して、依頼数量で、マーケット通貨で、依頼時点で解決されたもの。カタログのIDと日付とともに保存するため、1年後の記録は「これは9月21日にカタログが示していた価格」と語り、「これが価格」とは決して語りません。これは編集されません。
依頼価格は、バイヤーが希望を出したならその希望です。カタログではなくバイヤーについてのデータであり、基準価格を上書きしてはなりません。マーチャントは両方を見て、双方の隔たりを知る必要があります。
提示価格はマーチャントの答えで、提案のバージョンごとに設定されます。カウンターは次のバージョンでそれを置き換え、前のバージョンは自分の値を保持します。承諾されたバージョンの提示価格が、表示通貨でバリアント明細の priceOverride として下書き注文に届く価格であり、承諾後にそれを編集しない理由は下書き注文の記事で扱っています。
3つを分けて持つことは、見積レイヤーをカタログの領分から遠ざけることでもあります。価格表に書き込むことはなく、会社別価格の表を持つこともなく、明細ごと、依頼ごとに1つの数字を読み取って記録するだけです。来週カタログが変わっても、見積は自分がどこから始まったかを知っていて、ストアは新しい価格を表示します。どちらも相手のコピーではないので、両者が食い違うことはありません。
通貨はマーケットに従う
コンテキスト価格は所在地のマーケット通貨で届き、見積もその通貨に留まるべきです。Shopifyは価格表のないカタログでは基本価格をマーケット通貨に換算し、価格表の固定価格はその価格表自身の通貨です。いずれにせよバイヤーが見る数字はひとつの通貨であり、そこから始まる見積も同じ通貨でなければなりません。基準価格をストアの基本通貨で保存し、後で再換算する見積レイヤーは、その日のレートと丸めでずれていき、「表示通貨で」priceOverride を設定して作られる下書き注文は、バイヤーが承諾した提案と一致しなくなります。
実務上のルールはこうです。見積の通貨は作成時に所在地のマーケットから確定し、見積上のすべての価格はその通貨で、レポートのために見積レイヤーが必要とする為替レートは価格に適用するのではなく、一度だけスナップショットとして保存します。
見積レイヤーは連鎖のどこに位置するか
上の連鎖はコンテキスト価格まで完全にShopifyの内部で進み、見積レイヤーとの契約は3つの読み取りと1つの書き込みです。
価格を読み取ります。ストアでは、依頼がすでにそれを運んでいます。ログイン済みの会社担当者に対するLiquidの variant.price は、コンテキスト価格そのものです。バイヤーが見た価格を送信する見積ボタンは、API呼び出しなしで正しい基準価格を送信しています。バイヤーに代わって管理画面で作成する見積にはストアのコンテキストがないため、レイヤーはAPIに尋ねなければなりません。バリアントごとに contextualPricing(context: { companyLocationId }) を呼ぶのです。さもなければ、既定のバリアント価格を基準にしてそれをカタログ価格と表示することになり、これこそ「なぜ見積が私の価格表より高いのか」を生むバグです。
表示可否を読み取ります。所在地の各カタログは公開を持ち、商品はそのうち少なくとも1つに公開されていれば所在地のカタログにあることになります。これは価格とは別の問いです。contextualPricing.price はnullにならず、カタログ価格がなければ基本価格にフォールバックするため、価格が返ってきたことは商品がカタログにあることの証明にはなりません。「価格がある」から「カタログにある」を推論するレイヤーは、バイヤーが見られない商品を見積もり、下書き注文には所在地に権限のなかった明細が載ることになります。
数量ルールと価格帯を読み取ります。上述の通りです。
一度だけ書き込みます。承諾された価格を priceOverride として下書き注文の明細に、所在地の支払い条件と税設定が適用されるよう purchasingEntity とともに書きます。価格表、カタログ、公開、マーケットに書き込むことは決してありません。評価チェックリストはこれらを一つずつ質問として挙げています。正しい答えはこのような形をしています。
QuotWayはどう解決するか
QuotWayの会社を認識する見積(Enterpriseプラン、B2Bが有効なストア)は、説明した連鎖をコンテキスト単価まで辿ります。その単価が明細ごとに依頼数量の隣に記録される基準価格であり、その数量でバイヤーがすでに持っている価格帯は、第二の解決済みの数字ではなく、エディターでのマーチャントの入力です。実装の3つの細部は述べておく価値があります。独自開発がたいてい手を抜くのがそこだからです。
ストアからの依頼はLiquidの価格を運びます。見積ボタンはバイヤーのコンテキストで product.selected_or_first_available_variant.price を読み、数量と依頼価格(あれば)の隣に明細のカタログ価格として送信するため、バイヤーが送信した見積は、バイヤーが見たものを基準にします。会社所在地のために管理画面で作成した見積は、同じ数字をバリアントごとに contextualPricing(companyLocationId) で解決します。以前のバージョンでは管理画面の見積を既定のバリアント価格で基準化し、それを「カタログ」と表示していました。このリゾルバーは、まさにそのバグを防ぐために存在します。提案の送信時に、基準価格は所在地の通貨で明細ごとに、出所としてのカタログIDとともに保存されます。そのIDは所在地の最初のカタログのもので、ベストエフォートの目印として記録されます。contextualPricing は勝者を名指しせずに、すべてのカタログを横断して実効価格を解決するからです。
カタログ外の検出には、価格ではなく公開を使います。見積もられた各商品について、レイヤーは所在地のいずれかのカタログ公開に公開されているかを尋ね、どれにも公開されていない商品は提案エディターと変換時の両方で警告します。所在地にカタログ公開がまったくない場合、表示可否は販売チャネルに委ねられてテストは判定不能になるため、レイヤーは誤って警告するよりは警告しません。価格は所在地ごとに数分間キャッシュされるため、40明細の提案が40回の往復を生むことはなく、すべてのリゾルバーはフェイルオープンです。Shopifyに到達できなければマーチャントは送信された価格をそのまま使い、見積作成が止まることは決してありません。
レイヤーがしないことも同じくらい重要です。価格の表を持ちません。提案エディターは基準価格をラベルとして表示し、マーチャントが提示価格を入力します。依頼価格はその両方の隣にあります。マーチャント向けガイドは管理画面側から同じことを示し、B2B機能ページは会社を認識する見積が見積に何を載せるかを一覧しています。
連鎖が短くなるようにカタログを設計する
導出は決定的ですが、エージェンシーはそれを追いやすくも追いにくくもできます。4つの設計ルールが連鎖を短く保ちます。
- プランが許す限り、所在地ごとにカタログを1つ。 Plusでは、直接割り当てが「最も具体的」ルールにすべての仕事をさせます。直接カタログが1つだけの所在地には、解決すべき衝突がありません。Plus未満では、各所在地がちょうど1つのB2Bマーケットに入るようにマーケットの条件を組み、3件の上限を重ならないマーケットに使います。
- カタログの2つの半分を意図せず分けない。 同じ所在地に価格だけのカタログと公開だけのカタログを置くのは、規模を扱うためにサポートされたパターンですが、「価格が違う」チケットの大半の背後にあるパターンでもあります。使うなら、どのカタログが表示可否を持ち、どれが価格を持つかを文書化し、上の表の該当2行をテストしてください。
- 数量別価格は交渉のない場所に置く。 価格帯のある商品は固定価格になり、カタログ全体の調整はもう触れません。価格帯はすべてのバイヤーが得る常設の段階に使い、案件固有の数量は見積に任せます。見積なら、マーチャントはバイヤーがすでに持つ価格帯を見たうえで、意図的にそれより下の価格をつけられます。
- 基準価格をマーチャントに見せる。 見積レイヤーが何を解決しようと、提案に価格をつける人は「カタログ:この所在地、この数量でX」をバイヤーの希望の隣に見なければなりません。基準価格が見えないマーチャントは、バイヤーがすでに持っていたカタログ価格を再提示するか、知らずにそれを下回るかのどちらかになります。
よくある質問
Shopify B2Bの見積依頼はどの価格から始めるべきですか?
バイヤーが見ている価格です。Shopifyがその会社所在地に対して、依頼数量で、マーケット通貨で、依頼時点で解決する価格です。Liquidではバイヤーのコンテキストにおける variant.price、Admin APIでは ProductVariant.contextualPricing(context: { companyLocationId }) と、依頼数量に対するその quantityPriceBreaks です。カタログIDと日付とともに記録し、バイヤーの依頼価格は別のフィールドに保持し、そこから交渉します。
会社所在地に複数のカタログがあるとき、どれが適用されますか?
順に2つのルールです。所在地に直接割り当てたカタログ(Shopify Plus)は「最も具体的」で、B2Bマーケット経由で所在地に届くカタログに勝ちます。同じ商品を含む同じ階層のカタログ同士では最安が勝ち、数量ルールと数量別価格はバリアントごとに最安のカタログに従います。
見積アプリはShopifyのカタログと衝突しますか?
価格表を一切保存しなければ衝突しません。衝突は、アプリが独自の会社別価格の表を持ち、ストアのカタログがそれから乖離したときに起きます。依頼時に明細ごとにコンテキスト価格を読み、日付つきの基準価格として記録し、合意した価格を priceOverride として下書き注文に書く見積レイヤーは、カタログに手を触れず、カタログと食い違うこともありません。
カタログを割り当てたのに、B2Bバイヤーに小売価格が表示されるのはなぜですか?
たいていはカタログに公開はあるが価格表がないためです。その場合Shopifyは「バリアントの初期価格をマーケット通貨に換算したもの」を表示します。逆に価格表はあるが公開がない場合、バイヤーには商品が一切表示されません。カタログの両方の半分を確認し、次に所在地が実際にB2Bマーケットに入っているか(Plus未満)、または直接割り当てられているか(Plus)を確認してください。
数量別価格は見積の開始価格を変えますか?
はい。依頼数量が到達する価格帯がバリアントにあれば、バイヤーはすでにその低い価格を見ており、見積はそこから始めるべきです。価格帯はバリアントごとで、バリアント間で合算されません。また、商品に数量別価格を設定するとその価格は固定され、カタログの全体パーセント調整はその商品に適用されなくなる点にも注意してください。
商品がバイヤーのカタログにないことを、アプリはどう知りますか?
価格ではなく、公開への所属で判断します。contextualPricing.price はnullにならず基本価格にフォールバックするため、返ってきた価格は何も証明しません。商品は、所在地のいずれかのカタログ公開に公開されていれば所在地のカタログにあります。所在地に公開がまったくなければ、表示可否は販売チャネルから来るため、カタログからはこの問いに答えられません。
Shopify B2Bで顧客別の価格を設定するには?
カタログを使います。商品の選択と価格表を組み合わせ、どのプランでもB2Bマーケットに、Shopify Plusでは会社や所在地に直接割り当て、固定価格またはパーセント調整と、任意で数量ルールと数量別価格を設定します。マーチャント向けのカタログガイドが手順を説明しています。このページが扱うのは、その結果を見積がどう扱うべきかです。
出典
Shopifyのページ。いずれも2026年9月21日、APIバージョン2026-07で確認:
- B2Bのカタログと価格、カタログでB2B価格をカスタマイズする、数量ルールと数量別価格
- B2BとMarkets、MarketsでB2Bを管理する、MarketsでB2Bカタログを作成・管理する
- B2Bカタログを管理する(アプリ向け)
- PriceList、ProductVariantContextualPricing、QuantityPriceBreak、ContextualPricingContext
- DraftOrderLineItemInput
- Liquidのvariantオブジェクト、ストアに数量ルールと数量別価格を表示する
- プラン別のShopify B2B機能
QuotWayの解決とカタログ外の挙動はソースコードに基づいて記述しています。マーチャント向けの説明は会社を認識するB2B見積とカタログのガイドにあります。プランごとの違いは料金ページを、カタログに関する事実の最新状態はShopify B2Bリファレンスをご覧ください。
関連記事
QuotWayがこれをあなたのストアでどう扱うかをご覧ください。