ネイティブのShopify B2B、見積アプリ、独自開発、CPQ：判断ガイド

ShopifyでB2B見積を運用する4つの方法に勝者はいません。あるのは適合だけです。

ネイティブのShopify B2Bは、価格が標準的でバイヤーがそれに対して注文するときに適合します。見積アプリは、標準品の価格が案件ごとに決まり、その案件が履歴付きでShopifyの注文にならなければならないときに適合します。独自開発は、ワークフローそのものが製品であり、ストアが存在する限りShopifyの四半期ごとのAPIリリースに追随するエンジニアをマーチャントが抱えているときに適合します。CPQは、製品がルールから構成され、営業チームがすでにCRMの商談の中で働いているときに適合します。ほとんどのB2Bストアは、標準価格にはネイティブB2Bを使い、例外には残り3つのうち1つを使う形に落ち着きます。間違いは、どちらも価格を所有したがる2つを選ぶことです。

このガイドは、1つを推薦しなければならないエージェンシーやアーキテクトのためのものです。4つの選択肢を定義し、18の要件で採点し、5つの質問による決定木を示します。アーキテクチャの記事は所有のルールが重要な理由を、見積アプリを使うべきでないときは「ネイティブ」の葉の詳しい説明を、評価チェックリストは候補のアプリや開発に当てるべきものを、公開前テストプランは選んだ方法を本番に出す前に実行するものを扱っています。

4つの選択肢の定義

ネイティブのShopify B2B。 会社、会社所在地、連絡先。価格表、数量ルール、数量別価格を持つカタログ。チェックアウトでの支払い条件、保存済みカード、発注書番号。チェックアウトを下書き注文に変える「承認のために送信」。その下書き注文でのカスタム価格、価格ロック、在庫確保。Plusでは前受金と部分支払い。2026年4月2日から全プランで利用可能。価格の依頼、提案、カウンターオファー、承認、交渉履歴のオブジェクトはありません。運用するもの：Shopify。

見積アプリ。 ネイティブのオブジェクトの上に依頼、提案バージョン、カウンターオファー、承認、監査証跡を追加し、バイヤーのカタログ価格を起点として読み、価格が合意されたら下書き注文を作る公開アプリ。マーチャントがインストールし、削除します。APIのアップグレード、コンプライアンスのウェブフック、ストアの拡張機能はベンダーが担います。運用するもの：サブスクリプションとベンダーのロードマップ。

独自開発。 同じ見積レイヤーを1つのマーチャントのために書いたもの。Admin API上のカスタムアプリとして、独自のデータベース、テーマアプリ拡張機能、顧客アカウント拡張機能、ウェブフックを持ちます。あらゆる挙動をマーチャントの望みどおりにできます。運用するもの：ストアが取引を続ける限り動かし続けるアプリケーション。その義務は後述しますが、公開後に減ることはありません。

CPQ。 Configure-Price-Quoteソフトウェア。あるベンダーは「営業チームが製品を構成し、価格ルールを適用し、値引きと承認を管理し、正確な見積を生成するのを助けるソフトウェア」と定義しています。ルールからの製品構成、価格ガバナンス、ガイド付き販売、承認、文書、契約で、通常はCRMの商談から作成されます。ShopifyはCPQの本拠地ではありません。ストアフロント、顧客アカウント、下書き注文は、CPQプロジェクトが構築するか購入しなければならない連携です。運用するもの：席数課金のプラットフォームとその連携。

適合マトリクス

適合は、Shopify上のB2Bストアがその要件をどう満たすかで採点しており、抽象論ではありません。「部分的」は、回避策か2つ目のツールがあれば実現できるという意味です。

要件	ネイティブB2B	見積アプリ	独自開発	CPQ
会社別、所在地別の価格表	あり - カタログ	読み取る。所有はしない	読み取る。所有はしない	部分的 - 独自の価格帳をカタログへ同期
数量段階	あり - 商品ごとに最大10段階	読み取る	読み取る	あり - 独自ルール
バイヤーが条件付きで注文・支払い	あり	あり - 変換した下書き注文経由	あり - 自分で作る下書き注文経由	部分的 - 注文の取り込みが連携そのもの
注文前に1回の確認	あり - 承認のために送信	あり	あり	部分的
ゲストからの価格依頼	なし - 価格には会社連絡先が必要	あり	あり	なし - 見積はCRMのレコードから始まる
案件固有の交渉価格	オブジェクトなし	あり	あり	あり
バイヤーのカウンターオファー	なし	あり	あり	部分的 - 通常は営業担当主導
値引きの承認を強制	なし - スタッフ権限はアカウント範囲を決めるだけで価格は決めない	あり	あり。強制を自分で作れば	あり
独自の課税・配送フラグを持つカスタム明細やサービス明細	あり - 下書き注文で手作業	あり	あり	あり
オプションとルールから構成される製品	なし	なし - カスタム明細を保持するが計算しない	可能	あり - CPQの本領
BOM駆動の複雑なエンジニアリング製品	なし	なし	可能。ただし相応のコスト	あり
案件ごとの運賃	下書き注文で手作業	あり	あり	あり
複数通貨での表示	あり - Markets	あり。アプリが表示通貨で見積するなら	あり。作れば	部分的 - CPQの通貨とShopifyの通貨
注文への前受金	Plusのみ	Plusのみ。下書き注文経由	Plusのみ	Plusのみ。Shopifyに届いた後
顧客アカウント内の見積	下書き注文のみ	顧客アカウントUI拡張機能	顧客アカウントUI拡張機能	なし - CPQのポータルは別物
ERPが価格を所有	カタログへ同期	カタログを読む	カタログを読む	CPQとカタログへ独自に同期
CRMの商談から見積を作成	なし	部分的 - Flow経由のイベント	可能	あり - ネイティブ
最初の見積までの時間	数時間	数日	数か月	数か月
継続的なエンジニアリング	不要	ベンダー側	自社	ベンダー側に加えて自社の連携
データの所有と撤退	Shopify	Shopify + エクスポート	自社	ベンダー + Shopify

行ではなく列を読んでください。ネイティブは、交渉しないストアには「あり」が最も多く、交渉した瞬間に「なし」が最も多くなります。見積アプリと独自開発は列の形が同じで、違いは誰が運用するかです。CPQの列は他が最も弱いところ（構成とCRM）で最も強く、他が最も強いところ（Shopifyのストアフロントと注文）で最も弱くなります。

ネイティブのShopify B2B：それで足りるとき

すべてのバイヤー、すべての注文について質問1がイエスなら、答えはネイティブです。誰かが尋ねる前に価格は所在地のカタログにあり、段階はそのカタログの全員に適用される数量ブレイクで、マーチャントが望む唯一の確認は、注文になる前に下書き注文を一目見ることです。2026年4月2日以降、これはBasic、Grow、Advancedで利用でき、Plusは無制限のカタログ、会社や所在地へのカタログ直接割り当て、前受金、部分支払いを追加します。ネイティブがカバーする8つの状況を、それぞれカバーする機能と対応づけたものがShopifyの見積アプリを使うべきでないときにあります。

ネイティブで足りなくなるのは、最初の返答が来た時です。下書き注文はカスタム価格を持てますが、「バイヤーがもっと安くと言った」という状態も、バージョンも、承認も、やり取りの記録もありません。下書き注文で交渉を回そうとするマーチャントは、会話はメールに、下書き注文は古いまま、という状態になります。誰かが口に出したかどうかにかかわらず、その時点で残り3つの選択肢のどれかを選んでいるのです。

見積アプリ：適合するとき

見積アプリが適合するのは、Shopifyがすでに知っている商品について価格が案件ごとに決まるときです。バイヤーが尋ね、売り手がカタログ価格から提案し、片方または両方が動き、誰かが値引きを承認し、承諾されたバージョンが合意価格の下書き注文になる。ネイティブが対応できないバイヤー、つまり会社アカウントを持つ前に金額を知りたいゲストにも適合します。

独自開発ではなく見積アプリが正しい選択になる条件は実務的なものです。マーチャントが必要とするワークフローがアプリのモデル化しているワークフローであること。マーチャントにエンジニアリングチームがない、あるいはShopifyの四半期APIリリースを追いかけるよりやるべきことがあること。最初の見積までの時間が重要であること。そしてアプリが評価チェックリスト、とりわけネイティブ適合の質問を通過すること。独自の価格表を持つアプリは、解決するために購入した問題を再現しているからです。コストはサブスクリプションと、ベンダーのロードマップへの依存です。アプリがモデル化していない挙動はチケットではなく機能要望になります。

QuotWayはそうしたアプリの1つで、このサイトが語れる実例です。会社対応の見積はバイヤーの会社所在地のカタログ価格から提案を始め、すべての提案とカウンターをバージョン管理し、承認をサーバー側で強制し、承諾された明細を所在地の支払い条件付きのネイティブな下書き注文に変換します。Liteプランは月10件までこの一連の流れを無料で実行でき、ストアに見積の件数があるかどうかを確かめる方法として、他の3列のどれよりも安上がりです。他のアプリに対してするのと同じように、チェックリストを当ててください。

独自開発：正当化されるとき、そして動かし続けなければならないもの

独自開発が正当化されるのは、質問4の両方の半分が真のときです。どのアプリもモデル化していないワークフロー（調達ルール、業界固有の文書、契約独自の論理に従う価格交渉）があり、かつストアが取引を続ける限りアプリケーションを運用するエンジニアにマーチャントが資金を出すこと。前半は後半より多く、エージェンシーはたいてい前半の見積もりしか求められません。

Shopify上の独自の見積レイヤーが動かし続けなければならないもの。Shopify自身の義務のページから：

• Admin APIのバージョン。Shopifyの四半期周期でアップグレードする。各バージョンは最低12か月サポートされ、サポート外のバージョンへのリクエストは警告なしに最も古いサポート対象へ「繰り上げ」られる。誰も触っていない構築が13か月目に壊れるのはこの仕組みによる。新しいアプリはGraphQLのみで、REST Admin APIは2024年10月1日以降レガシー。
• 3つのコンプライアンスウェブフック（customers/data_request、customers/redact、shop/redact）と、構築が保存する氏名、メール、住所、電話番号に対する保護対象顧客データの保護措置。カスタムアプリは公開アプリのようにこのアクセスを審査されないが、要件は同じ。
• Shopifyの配信モデルに耐えるウェブフック処理。署名の検証、X-Shopify-Webhook-Id による重複の無視、再試行（4時間で8回、その後サブスクリプションは削除）、そして配信が「常に保証されるわけではない」ための照合ジョブ。
• レート制限を考慮したAPI利用。Standardで毎秒100ポイント、Advancedで200、Plusで1,000、クエリあたり1,000ポイントの上限。
• ストアフロント用のテーマアプリ拡張機能と、バイヤーのアカウント用の顧客アカウントUI拡張機能。それぞれにサイズ上限とアップグレード経路がある。ヘッドレスのストアフロントには3つ目の経路が必要。
• 下書き注文への冪等な変換。各明細に priceOverride で交渉済み価格、purchasingEntity に会社、draftOrderCalculate に対するずれのチェック。
• チェックアウトの挙動がワークフローの一部なら（発注書番号のルール、バリデーション）、Shopify Functions。そして「Shopify Plusプランのストアだけが、Shopify Functions APIを含むカスタムアプリを使える」。

独自開発に見えてそうではない近道が2つあります。見積をメタオブジェクトでモデル化すると、管理画面とStorefront APIにカスタムのレコード型ができますが、それはレコードであってワークフローではありません。状態も、バージョンも、承認も、強制もありません。Flowと下書き注文の組み合わせ（タグで下書き注文を動かすFlowの自動化）は、手順の増えた1回の確認にすぎず、ネイティブが止まるのと同じ返答で止まります。

構築の対象だったワークフローが、どの見積アプリもモデル化しているものだと判明したとき、独自開発の正当性は消えます。これは逆よりも頻繁に起こり、構築の後ではなく前に問う価値があります。アーキテクチャの記事はどちらの道でも満たすべき仕様であり、評価チェックリストは既存のアプリがすでにそれを満たしているかのテストです。

CPQ：正当化されるとき、そして過剰なとき

CPQが正当化されるのは、質問2がイエスで質問3もイエスのときです。価格が会話ではなく製品構成ルールから出てきて、見積を作る人が契約、更新、ガイド付き販売に囲まれたCRMの商談から仕事をしている。この世界ではShopifyは注文取り込みとフルフィルメントの面、CPQは見積の面であり、その間の連携（構成済み製品からShopifyの明細へ、CPQの見積から下書き注文へ、Shopifyの注文から商談へ）はCPQが提供しない独立したプロジェクトです。

製品が標準品で、価格が計算ではなく交渉で決まり、営業担当がCRMではなくShopifyの中で働いているストアにとって、フルCPQは過剰です。それがShopify B2Bストアの大半です。見分けるポイントは構成ルールです。提案の明細が交渉価格のバリエーションと、ときどきのカスタム明細であるなら、コンフィギュレーターが構成するものは何もなく、ストアは必要な2つの要素（承認と文書）のために、不要ないくつかと抱き合わせで席数課金を払うことになります。Shopify CPQの記事は2つの仕事を分け、QuotWayとエンタープライズCPQの比較は両者で迷うストアのための並列比較です。

中間のケース、つまり構成される製品はあるがCRMはない場合は、木の点線の葉です。製品オプションツールが構成済み価格を計算し、見積レイヤー（アプリか独自開発）がそれを交渉して変換します。2つの仕事だから2つのツールです。

組み合わせ

機能する組み合わせにはすべて、標準価格の所有者が1つだけあり、それはShopifyのカタログです。

• ネイティブ + 見積アプリ：標準価格と交渉による例外を持つストアの既定形。カタログがストアフロントと再注文の価格を決め、アプリはカタログ価格から見積して下書き注文を返す。
• ネイティブ + 独自開発：同じ形で、例外がどのアプリにもないルールに従うストア向け。
• ネイティブ + CPQ：CPQが構成とCRM側の見積を所有し、ERPかCPQが標準価格をカタログへ同期し、Shopifyが注文を取り込む。誰かが作らない限り、見積そのものは顧客アカウントには存在しない。
• 失敗する組み合わせ：どちらも価格表を持つ2つの選択肢。カタログの隣に独自価格を持つ見積アプリ、あるいは手作業で編集されるCPQの価格帳とカタログは、数週間のうちに1人のバイヤーに2つの金額を生む。

よくある質問

Shopify B2Bはアプリなしで交渉価格を扱えますか

1往復なら扱えます。所在地を注文の下書き送信に設定し、下書き注文で価格を調整してロックし、請求書を送ります。バイヤーの返答、2つ目のバージョン、承認のオブジェクトはないので、2回以上のやり取りがある交渉には何らかの見積レイヤー、アプリか独自開発が必要です。

Shopify Plusなしで見積依頼を実装できますか

できます。会社、カタログ、数量ルール、支払い条件、下書き注文は2026年4月以降すべてのプランにあり、見積アプリもAdmin API上のカスタムアプリもすべてで動きます。Plus依存はShopify側のものです。前受金と部分支払い、無制限および直接割り当てのカタログ、そして独自開発の場合、カスタムアプリに同梱するとPlusストアが必要になるShopify Functionsです。

ShopifyにCPQはありますか

ありません。あるのはカタログ、数量ルール、下書き注文、B2Bチェックアウトです。構成ルール、ガイド付き販売、CRMネイティブの見積はShopifyと連携するCPQプラットフォームから、標準品の交渉は見積アプリから来ます。ストアにどちらが必要かは決定木の質問2です。

独自開発のコストはどう見積もればよいですか

公開ではなく義務に値段を付けてください。四半期ごとのAPIアップグレード、コンプライアンスのウェブフックとデータ保護措置、ウェブフックとレート制限の処理、2つの拡張機能とそのアップグレード、変換ロジック。それぞれをストアの寿命の分だけ。公開で終わる構築見積もりは、安い方の半分の見積もりです。

どの選択肢がデータをShopifyに残しますか

ネイティブはすべてを残します。見積アプリや独自開発は交渉（依頼、バージョン、承認、監査証跡）を自分の保管場所に、それ以外をShopifyに置きます。これが正しい分割で、注文は常にShopifyのものです。CPQは見積をCPQに、注文をShopifyに置き、両者のつながりは連携の出来次第です。

見積アプリとCPQは共存できますか

明確な境界があれば共存できます。特定の商品ラインについて、提案を所有するのはどちらか一方です。同じバイヤーに両方が価格を提案できる2つのシステムは、2つの価格表の失敗の別の形です。

出典

Shopifyのページ。いずれも2026年9月20日に確認：

• プラン別のB2B機能とB2B for all - 発表、2026年4月2日
• チェックアウトとアカウントと下書き注文でB2B注文を作成する
• Shopify Functionsとメタオブジェクト
• APIのバージョニング、REST Admin API - レガシー通知、GraphQL Admin APIのレート制限
• プライバシー法への準拠 - 必須ウェブフックと保護対象の顧客データ
• ウェブフック - 配信の検証、タイムアウト、再試行とウェブフックの概要
• テーマアプリ拡張機能と顧客アカウントUI拡張機能
• B2B向けの下書き注文とDraftOrderLineItemInput
• ベンダー自身によるCPQの定義：What is CPQ? (Salesforce)