Shopifyエージェンシー向け
Shopifyの見積アプリを使うべきでないとき
著者 Jahangir Alam · 2026年9月20日 · 約11分で読めます
- 最終確認日
- Shopify API
- 2026-07
- 対象読者
- B2B構築を検討するShopifyエージェンシーとマーチャント
- 範囲
- ネイティブのShopify B2B(カタログ、数量ルール、下書き注文のチェックアウト、アカウント申請)と見積ワークフローの境界
バイヤーが尋ねる前に価格が決まっていて、その後に誰も変えないなら、見積アプリは必要ありません。
ShopifyのネイティブB2Bはすでに各会社所在地をカタログから価格付けし、数量ルールと数量別価格で数量段階を扱い、設定1つでチェックアウトを確認用の下書き注文に変え、会社を自動で作成するフォームでアカウント申請を受け付けます。見積ワークフローが意味を持つのは、価格が案件ごとに決まるとき(交渉、仕様、運賃、誰かの承認によって)、そしてその合意が履歴をそのままに注文にならなければならないときだけです。
私たちは見積アプリを作っており、だからこそこのページがあります。クライアントのB2B構築を検討するエージェンシーは、何よりも先に「本当にRFQアプリが必要か」と問い、正直な答えはしばしばノーです。以下の8つの状況はノーになるケースで、それぞれをカバーするShopifyの機能と必要なプランを添えています。続いてイエスになる6つの状況、そして境界ケースを決める5つの質問です。
見積アプリを使うべきでないケース
1. 価格が常に事前に決まっている
すべてのバイヤーの価格が尋ねる前に決まっているなら(業者価格、契約価格、段階価格)、それはShopifyのカタログに置くべきもので、見積ではありません。カタログは商品の選択と価格表、数量ルール、数量別価格の組み合わせで、会社所在地に割り当てます。所在地は複数持てて、同じ商品が複数に含まれるときは最安の価格が表示されます。これは顧客別価格の完全なシステムです。Basic、Grow、AdvancedではB2Bマーケット全体で最大3件の有効なカタログ、Plusでは上限がなくなり、会社や所在地への直接割り当てもできます。
止まる場所:カタログ価格は標準価格です。「この注文で、この数量と納期なら、この金額」は表現できません。カタログのガイドでマーチャント側の設定を扱っています。
2. 数量段階が交渉のすべてである
「50個なら9ドル、200個なら8ドル」は交渉ではなく、段階付きの価格表です。Shopifyはこれをネイティブに扱います。数量ルールはバリエーションごとに最小、最大、増分を設定し、数量別価格は商品ごとに最大10段階の価格を追加して、バリエーション単位で適用します。どのプランでも使えます。数量別価格を有効にすると価格は固定され、その商品にはカタログ全体のパーセンテージ調整が適用されなくなります。段階価格表として正しい挙動です。
止まる場所:段階はそのカタログのすべてのバイヤーで同じです。あるバイヤーだけが他にはない段階を得た瞬間、それは見積です。数量別・段階別価格の記事でマーチャント側から同じ線を引いています。
3. バイヤーがカタログからそのまま注文できる
サインインしたバイヤーが自分の価格を見て、必要なものを追加し、所在地の支払い条件でチェックアウトできるなら、注文の経路は完成しています。ネイティブのB2Bチェックアウトは、Net 7からNet 90またはフルフィルメント時払いの条件、発注書番号の欄、所在地単位の保存済みクレジットカード、過去の注文を複製する簡単再注文、多数のバリエーションをまとめて追加するクイック注文リストを提供します。どれもアプリを必要とせず、前受金も同様です。Plusでは所在地や下書き注文に設定した前受金のパーセンテージがチェックアウトで回収され、残額は条件に従います。
止まる場所:これらの機能はどれも、明細の価格が正しいことを前提にしています。価格を運ぶものであって、価格を決めるものではありません。
4. 確認は1往復で十分
注文が確定する前に一度見たい(在庫を確認する、運賃を確定する、数量を修正する)、そのうえでバイヤーに支払ってもらいたい、というマーチャントもいます。Shopifyは見積オブジェクトなしでこれを実現します。会社所在地を「チェックアウトで下書き注文のみ許可」に設定すると、バイヤーのボタンは「承認のために送信」になり、注文は下書き注文ページに入り、マーチャントが注文を作成するかバイヤーが請求書を支払った時点で完了します。Spring ’26 Edition以降は、管理画面で下書き注文の明細価格を上書きし、カスタム割引を適用し、価格をロックし、在庫を確保し、会社連絡先に請求書を送れます。
止まる場所:下書き注文の状態は1つだけ、支払いまたは承認待ちです。依頼も、提案番号も、カウンターオファーも、何を求められて何を提示したかの記録もありません。バイヤーが「3行目、もう少し何とかなりませんか」と返した時点で、会話はShopifyの外に出ており、下書き注文は古くなっています。下書き注文ワークフローの記事で、それがどこから痛みになるかを示しています。
5. 誰が尋ねているかを知りたいだけ
「見積を依頼」のボタンの多くは、実は「アカウントを申請」です。Shopifyの会社アカウント申請フォームがこれをネイティブに行います。会社名とメールアドレスが必須で、ファイルアップロードを含むカスタム項目を追加でき、送信すると管理画面に会社、会社所在地、顧客が作成され、承認か却下を選べます。価格は関係しません。まだ必要ないからです。申請者は承認後にカタログを得ます。卸売アカウント申請の記事で、このフォームで何を尋ねるべきかを扱っています。
止まる場所:承認されたバイヤーはその後カタログ価格で注文します。最初の注文に案件固有の価格が必要なら、見積に戻ります。
6. 問い合わせフォームで十分
価格の問い合わせが年に数件で、メールで答えているなら、問い合わせフォームが正しい道具であり、見積ワークフローは運用するだけの件数がないプロセスです。テーマの問い合わせページや、顧客プロフィールを作るリード獲得フォームで依頼を受け、返信し、バイヤーは下書き注文の請求書で支払う。見積が稀なストアにとって、これは正当な構成です。
止まる場所:どの依頼が未対応か、どの提案をいくらで出したか、誰が値引きを承認したかを言えなくなった時点です。多くのストアでは、週に数件の依頼から、修正を求める最初のバイヤーが現れるまでのどこかでそうなります。フォームは集めるだけで、追跡も、バージョン管理も、承認も、変換もしません。
7. 本当の問題は製品の構成である
バイヤーがオプションとルールから製品を組み立て(寸法、素材、互換パーツ、組み合わせごとに価格が異なる)るなら、難しいのは構成であって、見積アプリはそれを解決しません。見積アプリは入力した価格のカスタム明細を保持できますが、オプションからその価格を計算はしません。それは製品オプションツールか、上位ではConfigure-Price-Quoteシステムの領域です。Shopify CPQの記事が両者を区別し、判断ガイドが4つの選択肢を18の要件で採点し、QuotWayとエンタープライズCPQの比較が、見積アプリを買うべきでない仕事を明確に述べています。
8. 価格が計測可能な入力から計算される
面積と色数で価格が決まる印刷、CADファイルから価格が決まる機械加工、寸法で価格が決まるサイン看板。バイヤーは人を介さず、入力から計算された数字を数秒で欲しがっています。これは即時見積エンジンであり、カタログでも見積ワークフローでもありません。即時見積か交渉見積かがその区別です。価格が数式から出てくるなら、まずそちらを読んでください。
シナリオ表
| 状況 | ネイティブでカバーするもの | プラン | 止まる場所 |
|---|---|---|---|
| すべてのバイヤーの価格が事前に分かっている | カタログ:会社所在地ごとの価格表、複数あれば最安が優先 | 全プラン(有効3件。Plusは無制限と直接割り当て) | 標準価格は案件価格にならない |
| 数量による段階 | 数量ルールと数量別価格、商品ごとに最大10段階 | 全プラン | 同じカタログのバイヤー全員に同じ段階 |
| バイヤーが条件付きで注文・支払い | B2Bチェックアウト、支払い条件、発注書番号、保存済みカード、再注文、クイック注文リスト | 全プラン。前受金と部分支払いはPlus | 価格を運ぶだけで、決めることはない |
| 注文確定前に1回の確認 | 「チェックアウトで下書き注文のみ許可」、下書きでのカスタム価格と割引、価格ロック、在庫確保、請求書 | 全プラン | 依頼、バージョン、カウンター、承認の状態がない |
| 誰が尋ねているかを知る | 会社アカウント申請フォーム:送信時に会社、所在地、顧客を作成 | 全プラン | 承認されたバイヤーも非標準の注文には価格が必要 |
| 年に数件のメールでの依頼 | 問い合わせフォームまたはリードフォーム、その後下書き注文の請求書 | 全プラン | 追跡、バージョン管理、承認、変換がない |
| 価格が製品の構成で決まる | 製品オプションまたはコンフィギュレーター。上位はCPQ | ツールによる | 見積アプリはカスタム明細を保持するが計算はしない |
| 価格が計測値の数式で決まる | 即時見積エンジン | ツールによる | そもそも交渉ではない |
見積ワークフローを使うべきケース
以下の6つの条件は、ネイティブB2Bにオブジェクトがないものです。1つ当てはまれば十分なことがほとんどです。
- 価格が案件固有である。金額はこのバイヤー、この数量、この月次第で、カタログの金額ではない。見積レイヤーは何が求められ、何が提示されたかを記録し、カタログ価格を置き換えるのではなくそこから交渉する。アーキテクチャの記事で、独自の価格表を決して持ってはいけない理由を説明している。
- 仕様が価格を変える。バリエーションではない明細(特注サイズ、サービス、セットアップ費用)は、独自の価格、課税フラグ、配送フラグを持つカスタム明細として提案に書き込み、そのまま下書き注文に届ける必要がある。
- 運賃が重要である。送料が案件ごとに決まり、ある明細に吸収され、別の明細では明示されるなら、提案はそれを明示的に運び、バイヤーが受け入れなければならない。運賃の記事はその判断について書いている。
- バイヤーが交渉する。カウンターオファーはメールではなく状態である。送信済み提案の明細はロックされ、バイヤーの一手はカウンター、売り手の一手は新しいバージョンになるため、双方はどの段階で何が合意されていたかを常に言える。
- 社内承認が重要である。しきい値を超える値引きはバイヤーに届く前に適切な人に届く必要があり、営業担当が回避できないように、チェックはサーバーで実行されなければならない。Shopifyのスタッフ権限は営業担当が見られる会社アカウントの範囲を決めるもので、価格を出してよいかは決めない。承認マトリクスの記事がポリシーを扱い、見積レイヤーがそれを強制する。
- 合意が履歴とともに注文にならなければならない。承諾されたバージョンは合意価格でネイティブの下書き注文に変換される。交渉済み単価が各明細に書き込まれ、バイヤーの支払い条件が適用され、発注書番号が引き継がれ、下書き注文IDと注文IDが見積に書き戻されるので、1年後も注文と、その元になった提案と、承認者が1つの記録になる。一部の明細を承諾し、残りを次のラウンドのために開いたままにするバイヤーにも、これが必要だ。
価格ではなくバイヤーに関する条件がさらに2つあります。アカウントを持つ前に金額を知りたいゲスト(ネイティブB2Bは会社所在地に紐づく連絡先にしか価格を見せません)、そして営業担当への振り分け、期限管理、リマインド、失効が必要な依頼です。自動化の記事は、それがいつ割に合うかを扱っています。
5つの質問
想像上の案件ではなく、実際に見ている案件について答えてください。
- バイヤーが尋ねる前に価格は決まっているか。すべてのバイヤーでイエスならカタログ。ほとんどでイエスならカタログに加えて残りのための見積経路。
- バイヤーが尋ねた後に誰かが価格を変えるか。まったくないなら質問1で終わり。ときどきあるなら、その変更には記録が必要。
- その変更に誰かの承認が必要か。イエスなら、メールのメモではなく、価格が出る前に実行される承認が必要。
- バイヤーは返答するか。カウンター、修正依頼、一部の承諾。イエスなら、バージョンとカウンターの状態が必要。
- 後で誰かが合意内容を証明する必要があるか。紛争、監査、退職した営業担当。イエスなら、Shopifyの注文に終着する変更不可の記録が必要。
イエスが0か1:ネイティブのShopify B2B、場合によっては問い合わせフォーム。2:例外のための見積ワークフローと、残りのためのカタログ。3以上:見積があなたの販売プロセスであり、専用のシステムを持つべきです。
多くのB2Bストアが行き着くハイブリッド
カタログだけ、見積だけというストアはごくわずかです。よくある形は、標準価格、再注文、支払い条件にはネイティブB2Bを使い、収まらない案件には見積経路を使うもので、その見積経路はカタログと戦うのではなくカタログを読みます。QuotWayの会社対応の見積はそう動きます。会社連絡先への提案はその所在地のカタログ価格から始まり、そこから交渉し、所在地の支払い条件付きの下書き注文に変換されます。見積ボタンの対象にならないバイヤーにはボタンが表示されず、無料のLiteプランは依頼から下書き注文までの一連の流れを丸ごと実行できるので、ストアは費用を払う前に見積の件数があるかどうかを確かめられます。四半期が過ぎてすべての依頼にカタログ価格で答えていたなら、答えは出ています。このページの冒頭に書いた答えです。
よくある質問
Shopifyに見積機能は組み込まれていますか
見積オブジェクトはありません。その周辺の部品はあります。顧客別価格のためのカタログ、チェックアウトを下書き注文に変える「承認のために送信」、下書き注文でのカスタム価格と割引、下書き注文からの請求書、会社アカウント申請フォームです。ないのは依頼、バージョン付きの提案、カウンターオファー、承認、つまり交渉そのものです。案件にそれらが関わらないなら、部品で足ります。
下書き注文を見積として使えますか
1回の確認往復なら使えます。バイヤーが送信し、あなたが調整して価格をロックし、請求書を送る。返答が伴うもの(カウンター、修正、承認)については、下書き注文にはそれを保持する状態がなく、両方を設定しない限り在庫の確保も価格のロックもされません。下書き注文は価格が合意された時に作るもので、価格を合意する場所ではありません。
「価格非表示と問い合わせフォーム」は見積ワークフローですか
いいえ。価格の非表示は誰が金額を見るかを決め、問い合わせフォームはメッセージを集めます。どちらも依頼を追跡せず、価格を付けず、バージョン管理せず、承認せず、変換しません。価格の非表示自体には知っておくべき2つの層があります。ストア上での見た目の非表示と、サインアウトした訪問者やクローラーが受け取るページソース、メタタグ、構造化データから価格を取り除く検索エンジン対応の非表示で、後者にはテーマの一度きりの編集が必要です。価格非表示のガイドが両方を扱っています。フォームに届く価格の問い合わせに手作業で答えているなら、その数を数えてください。それがあなたの見積件数です。
上記のネイティブ機能にShopify Plusは必要ですか
いいえ。2026年4月2日以降、会社、所在地、カタログ、数量ルール、数量別価格、支払い条件、保存済みカード、チェックアウトでの下書き注文、アカウント申請フォームはBasic、Grow、Advancedで使えます。Plusが追加するのは無制限のカタログ、カタログの直接割り当て、前受金、部分支払いです。プランマトリクスに全リストがあります。
見積アプリとカタログは共存できますか
共存すべきで、良いアプリの条件は独自の価格を決して保存しないことです。カタログは所在地の標準価格のままで、見積はそのバイヤーのためにその価格から始まり、合意価格はその1件の注文のために下書き注文の明細に載ります。アプリ内に価格表をインポートまたは維持するよう求めるアプリは、アーキテクチャの記事が警告する2つ目の価格システムです。評価チェックリストは、この質問と他の50の質問を、開発ストアで実行できるテストにしています。
月に数件しか依頼がありません。見積アプリは割に合いますか
その数件が売上の大半を占めるか承認が必要でない限り、まだ割に合わないでしょう。下書き注文とフォームで答え、件数を数えてください。卒業の合図は件数だけではありません。3週間前にバイヤーに何を提示したか言えなくなった、その最初の瞬間です。
出典
Shopifyのページ。いずれも2026年9月20日に確認:
関連記事
QuotWayがこれをあなたのストアでどう扱うかをご覧ください。