Shopify B2B見積と基幹システム（ERP）・CRM・PIMの連携パターン

Shopify B2Bの見積レイヤーは、基幹システム（ERP）、CRM、PIMに直接つなぐものではありません。つなぐ先はShopifyであり、Shopifyがその先とつながります。見積は、それが変わった先の注文として基幹システムに届き、それが発するイベントとしてCRMに届き、PIMには一切届きません。見積レイヤーは、ストアの他のあらゆる部分と同じように、商品データをShopifyから読むからです。これは手抜きではありません。あらゆる項目に書き手が一つしかいない唯一の構成であり、ストアがすでに動かしているShopifyと基幹システムの連携が想定している構成でもあります。

このページは、連携の範囲を決めるエージェンシーのためにパターンをまとめます。どのシステムがどの項目を持つか、同期を走らせる前に決めるべき識別キー、いまの時点で見積がストアを出ていける三つの出口とそれぞれが運べるもの、見積レイヤーが依存する「基幹システムからShopifyへ」の価格リストの流れ、見積に固有の失敗パターン、そして要件定義で答えるべき十の質問です。扱うのはパターンであってコネクタではありません。どの製品も「連携済み」とは書かず、まだ存在しない機能はそう明記します。例に挙げるのは日本市場の検索データに現れるシステム、つまり基幹システム・販売管理システム、ネクストエンジンやロジレスのような受注・在庫連携ツール、スマレジ、NetSuite、freeeや弥生といった会計ソフト、SalesforceやHubSpotで、どれについても出来合いの連携があるとは主張しません。

以下のShopifyに関する記述はすべて、2026年9月22日にShopify自身のページに対してAPIバージョン2026-07で確認したものです。出典は末尾にあります。QuotWayが何を書き、何を公開しているかを述べる箇所は、このパターンの一実装であり、そのように明示しています。

誰が何を持つか

連携とは項目の一覧であり、各項目について、それを書くことを許された唯一のシステムを決めることです。プロジェクトの残り全部、つまり周期、転送手段、エラー処理はこの一覧から決まり、連携の障害の多くは書き手が二つある項目に行き着きます。見積レイヤーを載せたShopify B2Bストアなら、この一覧は表一つに収まります。

項目	書き手（正本を持つシステム）	Shopifyで着地する場所	読む側	典型的な周期
商品コンテンツ：タイトル、説明、メディア、属性	PIM（PIMがなければShopify自身）	Product、ProductVariant、メタフィールド	ストアフロント、見積レイヤー、SKU経由で基幹システム	バッチ、変更時
バリエーションの存在とSKU	PIMまたは基幹システムの商品マスタ	ProductVariant.sku	すべて	バッチ、変更時
基本価格	基幹システム	ProductVariant.price	ストアフロント、カタログ、見積レイヤー	バッチ、日次または変更時
顧客別価格と数量ルール	基幹システム	カタログの価格リスト（PriceList）、数量ルール	ログイン中の所在地向けストアフロント、開始価格としての見積レイヤー	バッチ、変更時
在庫	基幹システムまたはWMS・在庫連携ツール	ロケーションごとのInventoryLevel	ストアフロント、チェックアウト、変換前の事前確認	ほぼリアルタイム
会社、所在地、住所、税番号、免税、支払条件、チェックアウト設定	基幹システムの顧客マスタ	Company、CompanyLocation（externalId付き）、BuyerExperienceConfiguration	ストアフロント、チェックアウト、purchasingEntity経由の見積レイヤー	バッチ、変更時
担当者とその役割	CRMまたは基幹システムのどちらか一方	CompanyContact、Customer	ログイン、見積レイヤー	変更時
一件の商談で交渉した価格と条件	見積レイヤー：封印された承諾済みバージョン	変換時に作成する下書き注文	Shopifyのチェックアウト、その後は注文として基幹システム	承諾時に一度
注文とその状態	Shopify	Order	コネクタ経由で基幹システム、商談の結果としてCRM	イベント、orders/* Webhook
出荷と決済の状態	基幹システムまたはWMSがShopifyへ書き戻す	Fulfillment、トランザクション	顧客アカウント、通知	イベント
パイプライン：商談、ステージ、担当、予測	CRM	何もない。CRMに留まる	営業管理	イベント、見積イベントから

この表で働いているのは二つの点です。見積レイヤーが持つ行は一つだけ、双方が合意した内容の記録であり、それ以外はすべて読むだけです。そしてShopifyは他のすべての行の合流点です。PIMは商品をShopifyに書き、基幹システムは価格、在庫、会社をShopifyに書き、基幹システムは注文をShopifyから読みます。見積レイヤーに書き込むものはなく、見積レイヤーはShopify以外の何にも書き込みません。基幹システムが受け取るのは見積ではなく、注文です。

これは、このテーマの検索データに繰り返し現れる問いへの答えでもあります。Shopifyは基幹システムではありません。Shopifyは「販売される商品」「購入する顧客」「受け付けた注文」の正本を持つシステムであり、仕入、総勘定元帳、原価、生産については意図的に何も持ちません。基幹システムは価格、在庫、顧客の商取引上の身元の正本であり続け、上の表ではそれらをShopifyへ書く側にあります。逆方向は決してありません。

何よりも先に識別キー

「このShopifyの会社は、基幹システムのあの取引先である」と言えない同期は、誰も保守しない対応表に行き着きます。ShopifyはB2Bの各オブジェクトにまさにそのための項目を用意しているので、まずキーを決めます。

• 会社と所在地。 CompanyInput.externalIdは「会社に対する、外部から与えられた一意のID」であり、CompanyLocationInput.externalIdは所在地について同じものです。基幹システムの取引先コードを会社に、納品先・請求先コードを各所在地に置きます。companiesクエリはexternal_idで絞り込めるので、コネクタは自前の表なしに必要なレコードを見つけられます。基幹システムがID以外に必要とするもの、たとえば価格グループ、担当者コード、与信限度額にはメタフィールドを使います。COMPANYとCOMPANY_LOCATIONはメタフィールドの所有者タイプであり、同じクエリがmetafields.{namespace}.{key}で絞り込めます。
• 商品。 SKUで突き合わせるのは、基幹システムがエクスポートする全バリエーションでSKUの一意性を保証している場合だけにします。保証がなければ、基幹システムの商品コードをバリエーションのメタフィールドに持たせ、それで突き合わせます。見積の明細はShopifyのバリエーションを参照するので、基幹システムが商品に使うキーは、見積レイヤーが関わる前にバリエーションへ解決されていなければなりません。
• 見積から生まれた注文。 これは見積レイヤーが用意しなければならないキーです。Shopifyには、注文が見積由来であることを示すものが何もないからです。QuotWayは作成するすべての下書き注文に二つのタグ、quotwayとquotway-<参照番号>（たとえばquotway-QW-1042）を書き、Shopifyは「下書き注文から注文を作成すると」下書き注文のタグを注文に引き継ぎます。注文のタグは40文字以内、英数字とハイフンのみという制限があり、既定の参照番号はこれを満たします。参照番号の接頭辞を独自に設定する場合も、この制限に収めてください。下書き注文はさらに、バイヤーにも見える注文属性quotway_conversion_group_idを持ちます。QuotWay自身がorders/createのペイロードからこれを読み戻して注文を見積に結び付けているので、基幹システムで同じ目的に使うべきキーもこれです。

使ってはいけないキーが一つあります。sourceNameです。管理画面の下書き注文セクションから完了した注文はshopify_draft_orderを返し、同じ下書き注文をバイヤーが請求書から完了するとwebを返し、アプリが完了するとそのアプリのIDを返します。これはShopify自身によるこの項目の挙動の説明で、sourceNameで絞り込むと、誰がクリックしたかによって見積由来の注文の一部は見つかり、残りは漏れることを意味します。

三つの出口

いまの時点で、見積がストアを出ていける出口は三つです。それぞれ運べるデータの形が違い、要件に合わない出口を選ぶことが、ストアが支えられないものをプロジェクトが作ってしまう典型的な経路です。

出口1：基幹システムが注文を受け取る

基幹システムが見積を必要とする瞬間はただ一つ、出荷し請求する対象になったときで、その瞬間の見積はShopifyの注文です。だから基幹システムは、注文をすでに運んでいる経路でそれを受け取ります。認定コネクタ、ネクストエンジンやロジレスのような受注連携ツール、iPaaS、あるいはorders/create、orders/updated、orders/edited、orders/paid、orders/cancelled、orders/fulfilledのWebhook購読です。見積レイヤーはこの経路を何も変えません。付け加えるのは注文上の識別情報で、基幹システムが見積由来の注文をストアフロントの注文と区別し、商談に結び付けられるようにします。

QuotWayから生まれた注文に載るもの（API 2026-07で変換が作成する内容）：

注文上の項目	値	見える相手	基幹システムでの用途
タグ	quotway	管理画面、コネクタ	見積由来の注文を専用のフローへ振り分ける
タグ	quotway-<参照番号>、例：quotway-QW-1042	管理画面、コネクタ	見積番号をキーとして使う
メモ（マーチャントのみ）	QuotWay quote QW-1042 v3、続けて内部メモがあればその内容	管理画面、コネクタ	承諾されたバージョン番号、監査用
注文属性	quotway_conversion_group_id	バイヤーと管理画面	一回の変換の冪等キー。重複排除はこれで行う
注文属性	Special requests、続けて回答済みのフォーム項目をラベル: 値で	バイヤーと管理画面	バイヤーの指示と、フォームが集める項目（バイヤーが入力した参照番号など）
明細プロパティ	バイヤーが注記した明細のCustomer note	バイヤーと管理画面	明細ごとの指示
purchasingEntity	会社、所在地、担当者。会社を認識する見積の場合	コネクタ	所在地のexternalIdを通じた基幹システムの取引先
paymentTerms	下書き注文に適用された所在地の支払条件	コネクタ	期日と売掛
presentmentCurrencyCode、currencyCode、totalPriceSet	見積の通貨、ストア通貨、両方の合計	コネクタ	正しい通貨で計上する（失敗パターン参照）
poNumber	マーチャントが下書きに追加したか、バイヤーがチェックアウトで入力した場合のみ。変換は書かない	コネクタ	発注書番号の突合

この表について二点。見積レイヤーはpoNumberを設定しません。QuotWayの依頼フォームには発注書番号の組み込み項目があり、その値は見積に保持され管理画面に表示されますが、現時点で変換は下書き注文にそれを渡しません。DraftOrderInput.poNumberにも属性にも入りません。注文に届くのはカスタムフォーム項目だけで、そのラベルを付けた属性として届きます。Shopifyの注文に発注書番号が必要なマーチャントは、請求書を送る前に下書き注文へ追加し、基幹システム側のマッピングは見積からそれが来ると期待すべきではありません。そして注文属性は、QuotWayが自身の帳簿づけのために依存している仕組みそのものです。QuotWayのハンドラーはorders/createのペイロードからquotway_conversion_group_idを読んで見積を変換済みにするので、同じ属性で組んだ基幹システム側のマッピングは、アプリが本番で依存しているのと同じ挙動の上に立っています。

どのコネクタが注文を運ぶかはストアの判断であり、見積レイヤーの判断ではありません。ShopifyのGlobal ERP Programには現在、Dynamics 365 Business Central、Brightpearl by Sage、NetSuite ERP Connector、Acumatica Cloud ERP、Infor eCommerce Connectorの五つの認定アプリがあり、プログラム開始時の対象範囲は「在庫、商品、注文、顧客情報」と説明されています。日本市場では、検索データに現れる基幹システムや販売管理システム、ネクストエンジンやロジレスといった受注・在庫連携ツール、会計側のfreeeや弥生がこれに加わります。あるコネクタが会社、所在地、カタログの価格リストまで書くかどうかはコネクタごとの問題で、その答えによって、所有権の表の「基幹システムからShopifyへ」の行がコネクタ経由になるかAdmin API経由になるかが決まります。ShopifyがSpring '26エディションで示した「QuickBooksはB2Bの注文、発注書番号、会社情報を同期する」という一文は、コネクタを前提にする前にそのドキュメントで探すべき種類の記述です。

出口2：CRMがイベントを受け取る

CRMの対象は商談であり、商談はイベントで動きます。作成、提案送付、交渉中、成約、失注。これは見積のライフサイクルの形そのもので、Shopify Flowが運ぶものです。QuotWayはProfessionalプラン以上でFlowに十のトリガーを公開しています。送信、提案送付、カウンター、承諾、辞退、期限切れ、変換、承認依頼、承認、却下で、それぞれが見積単位の項目を持ちます。ID、番号、管理画面の見積へのディープリンク、状態、合計と通貨、誰がいつ操作したか、Shopifyの顧客ID（ゲストのリクエストでは空）、そして常に存在するバイヤーのメールアドレスです。特定のトリガーはさらに、ラウンド番号、承諾が全部か一部かと承諾合計、変換時の下書き注文ID、承認がマーチャント側かバイヤー側かを持ちます。

トリガーからワークフローがCRMに届く経路は二つです。Flow組み込みのコネクタ（Slack、メール、Google Sheets、アクションを登録したアプリ）は通知の用途を直接まかなえます。Flowのアクションを持たないCRMには、HTTPリクエストを送信がトリガーの項目を任意のエンドポイント、つまりCRMのAPIやiPaaSのWebhookへGET、POST、PUT、PATCH、DELETEで送ります。応答待ちは30秒、ステータス区分ごとの再試行ポリシーは最長24時間まで再試行できます。Flow自体はBasic、Grow、Advanced、Plusで無料ですが、HTTPアクションにはGrow、Advanced、Plusのいずれかが必要です。

CRM管理者が確認できる表としてのマッピング：

見積イベント	CRMでの効果
見積送信	商談を作成または更新。担当者はメールアドレスで、顧客IDがあればそれで紐付ける
提案送付	ステージ：提案。金額：提案合計
カウンター	ステージ：交渉。ラウンド番号を記録
承認依頼／承認／却下	商談上の活動。承認種別で分岐し、マーチャント側の承認チェーンとバイヤー側を区別する
見積承諾	ステージ：成約、金額：承諾合計。一部承諾は承諾された明細の成約で、残りは引き続きオープン
見積辞退、見積期限切れ	ステージ：失注、理由付き
見積変換	下書き注文IDを添付。注文番号はバイヤーの支払い後に出口1経由で届く

出口2が運べないのは明細です。トリガーには明細、数量、明細ごとの価格が含まれず、それを欲しがるワークフローには取りに行く先がまだありません。見積の明細を表示しなければならないCRMには、Flow上の回避策ではなく、後述のAPIが必要です。

出口3：経理がファイルを受け取る

要件の中には、連携ではなくレポートであるものがあります。経理は今月の見積を、状態と合計、そしてそれがどの注文になったかとともに欲しがり、BIツールはパイプライン金額の推移を欲しがります。QuotWayのアナリティクスのエクスポート（Professional以上）は、指標の背後にある見積を、適用中の期間とフィルターでCSVとしてダウンロードします。バッチであり、見積単位であり、月末までに誰もデータを必要としないなら正しい出口です。反対側で待っているのが人ではなくシステムなら、間違った出口です。

APIを待つもの

いまの時点でどの出口にも収まらない要件が三つあり、範囲決めでの誠実な答えは近似するのではなくそう言うことです。変換前に見積の明細を基幹システムへ送ること、基幹システムやCRM側から見積を作成すること、見積と商談の双方向の状態同期です。いずれも、システムが見積を読み書きできるAPIを必要とし、QuotWayには公開APIも外向きのWebhookもまだありません。それまでは出口1のマッピングが基幹システムと見積の接点であり、APIが来ても変えずに済むように設計する価値があります。見積番号、バージョン番号、変換グループIDは同じキーのままです。

価格リスト：基幹システムが書き、Shopifyが解決し、見積が読む

所有権の表でもっとも頻繁にこじれる行は顧客別価格です。三つのシステムがそれぞれ意見を持つからです。持ちこたえるパターンは一方向です。基幹システムがShopifyのカタログへ価格を書き、Shopifyがある所在地にどの価格を見せるかを解決し、見積レイヤーはその解決済みの価格を交渉の出発点にします。

Shopify側では、カタログは公開設定（どの商品か）と価格リスト（いくらか）の組み合わせです。価格リストはAdmin APIでバリエーションごとの固定価格を受け取ります。priceListFixedPricesAddは「PriceListの固定価格を作成または更新」し、商品単位の更新、削除、リスト管理の兄弟ミューテーションがあります。管理画面のCSVインポートも使えますが、これは固定価格しか運ばず、価格を空にした行をインポートするとそのバリエーションの固定価格が削除されます。固定価格はカタログのパーセント調整を上書きするので、顧客の価格グループを固定額でエクスポートし、パーセントのルールはShopifyに残す基幹システムなら、切り分けはきれいです。ある所在地が同じバリエーションに複数のカタログ経由で到達する場合、Shopifyはまず最も具体的なカタログを、次に最低価格を適用し、数量ルールと数量別価格は勝ったカタログに従います。Plus以外では、全B2Bマーケット合計で有効なカタログ三つが上限です。最新の行はShopify B2Bリファレンスにあります。

この行を安全にする規則は二つです。見積レイヤーに商品の価格を自前で持たせないこと。開始価格はログイン中のバイヤーにShopifyが見せる価格から導くべきで、そうすれば基幹システムの価格変更は二度目の同期なしにカタログ経由で次の見積に届きます。そして、交渉した価格を価格リストへ自動で書き戻さないこと。商談の価格は一件の商談の結果であり、それを顧客の定価に昇格させるジョブは、誰も決めていないのに営業担当者の譲歩を恒久的な値引きに変えてしまいます。

会社と所在地：顧客マスタは一方向で

書き手が二人になりがちなもう一つの行は会社です。Shopifyでは、マーチャントが管理画面やAdmin APIで会社を作成でき、ストアフロントの申込フローが同じオブジェクトを埋めることもあります。一方、基幹システムには採番、与信、支払条件を持つ顧客マスタがあります。どちらか一つを選びます。基幹システムが正本なら、externalIdを設定したCompanyと各CompanyLocationを作成し、所在地のtaxRegistrationId、taxExempt、taxExemptionsと、支払条件テンプレート、所在地の注文を確認用の下書きにするかどうか、バイヤーが一回限りの配送先を入力できるかを持つbuyerExperienceConfigurationを設定し、変更のたびに更新します。Shopifyが正本なら（アカウントが申込フローから来る場合に典型的です）、基幹システムはcompanies/create、company_locations/createとそれぞれのupdateトピックを購読し、Webhookから取引先を作成し、次のイベントを突き合わせられるように基幹システムのコードをexternalIdとして書き戻します。どちらにせよ、作るのは一つのシステムで、もう一方は反応するだけです。

担当者も同じ規則に従いますが、候補が変わります。人はCRMが持ち、取引先は基幹システムが持つことが多いからです。人を持つシステムがCompanyContactを書き、company_contacts/*とcompany_contact_roles/*のトピックがもう一方に何が起きたかを伝えます。会社を認識する見積を備えた見積レイヤーは、リクエスト時点でバイヤーの所在地を読み、purchasingEntityとして下書き注文に載せます。所在地の支払条件、税設定、身元が注文に届き、出口1を通って基幹システムに届くのはこの経路です。

見積に固有の失敗パターン

Shopifyと基幹システムの間の一般的な失敗、つまりWebhookの重複配信、順序の乱れ、項目を誤ってマッピングするコネクタは、ここでも他と同じように起こります。以下は見積が付け加えるものです。

失敗パターン	何が起きるか	設計
sourceNameで絞り込む	値は誰が下書きを完了したかで変わる。管理画面ならshopify_draft_order、請求書経由ならweb、アプリならアプリID	見積由来の注文はquotwayタグか参照番号タグで識別する
一つの見積、複数の注文	一部承諾と分割変換は変換グループごとに下書きを一つ作るため、承諾されなかった明細がオープンのまま、一つの見積が二つ以上の注文になりうる	重複排除は見積番号ではなくquotway_conversion_group_idで行う。参照番号一つにN件の注文を想定する
通貨を誤って計上	下書きは見積の通貨（presentmentCurrencyCode）で作成される。currencyCodeはストア通貨で、totalPriceSetは両方を持つ	基幹システムがどの通貨で計上するかを決め、金額セットのその側を読む。Shopifyの多通貨B2Bを参照
変換後に注文が編集される	マーチャントが注文を編集し、orders/editedが発火する。見積の封印されたバージョンは変わらない	変換後は出荷と請求について注文が真実。見積は合意内容の記録であり、突き合わせるべき二つ目のコピーではない
参照番号タグが拒否・切り詰められる	注文タグは40文字以内、英数字とハイフンのみ	独自の参照番号接頭辞はこの規則に収める
Webhookが二回、遅れて、あるいは届かない	配信は少なくとも一回で、4時間にわたり8回再試行される。順序は保証されない	注文IDをキーにした冪等なハンドラーと、Shopifyに問い合わせる突合ジョブ。変換そのものに必要な設計と同じ
下書き確認が有効な所在地	「すべての注文を確認用の下書きとして送信」の設定では、その所在地のストアフロント注文も、見積レイヤーが作る下書きと並んで下書きとして届く	タグで区別する。すべての下書きを見積として扱わない
ゲストの見積	Shopify顧客のないバイヤーからのリクエストは、Flowトリガーの顧客IDが空	CRMの担当者はバイヤーのメールアドレスで突き合わせる。トリガーは常にそれを持つ
会社が両側で作成される	Shopifyでの申込と、同じバイヤーについて基幹システムで作成された取引先	正本は一つ。もう一方は作成前にexternalIdを確認する
価格の再インポートが価格を消す	Fixed PriceとCompare Atの両方を空にしてインポートしたカタログCSVの行は、そのバリエーションの固定価格を削除する	インポート前にエクスポートする。部分的なファイルを往復させない
注文に発注書番号を期待する	変換はpoNumberを書かない。組み込みの発注書番号は見積に残り、カスタムフォーム項目だけが属性として届く	請求書の前に下書きへ番号を追加するか、カスタム項目として集めて属性をマッピングする

要件定義の前に答える十の質問

1. 所有権の表の各行について、どのシステムが書くか。クライアントは書面で同意しているか。
2. 取引先、納品先、商品それぞれの基幹システム側のキーは何で、それをShopifyのどの項目（externalId、メタフィールド、SKU）が持つか。
3. ストアが使っている、または使う予定のコネクタは、会社、所在地、カタログの価格リストまで書くか。それとも商品、在庫、顧客、注文だけか。
4. 顧客別価格は基幹システムからどう出てくるか。バリエーションごとの固定額か、パーセントのグループか、両方か。Plus以外での有効カタログ三つの上限に収まるか。
5. 基幹システムはどの通貨で計上し、見積レイヤーは所在地のマーケット通貨で見積を出すか。
6. 基幹システムは一つの見積参照番号に複数の注文が来ることに備えているか。重複排除は変換グループで行っているか。
7. CRMはどの見積イベントを必要とし、CRMにFlowアクションがない場合、ストアのプランは「HTTPリクエストを送信」を許可しているか。
8. 変換前に見積の明細を別のシステムで必要とする人はいるか。いるなら、それはAPIを待つ要件であり、要件定義書にそう書くべきである。
9. 会社の作成は誰が持ち、もう一方はそれをどう知るか。
10. 連携のためにローンチ前テスト計画に何を足すか。本番前に開発ストアで、出口ごとに見積を一件通すこと。

QuotWayはこのパターンにどう収まるか

上のパターンを具体的な何かに照らして確かめられるよう、一実装として明示します。QuotWayが持つのは封印された承諾済みバージョンだけです。Shopifyからバリエーション、カタログで解決された価格、そしてEnterpriseプランではバイヤーの会社所在地を読み、変換ごとに下書き注文を一つ書きます。タグと属性は出口1の表のとおりで、会社を認識する見積ではpurchasingEntityと所在地の支払条件を載せ、見積の通貨を表示通貨にします。変換は冪等で、突合されます。「一つの見積にN件の注文」という規則を安心して前提にできるのはそのためです。Professional以上で十のFlowトリガーを、Enterpriseで三つのアクションを公開し、Professional以上で見積のCSVエクスポートを提供します。自前の基幹システム・CRMコネクタは持たず、公開APIも外向きのWebhookもまだありません。プランは料金ページ、Flowの機能はShopify Flow機能ページ、トリガー項目のリファレンスはドキュメントにあります。

この記事のShopifyに関する事実はShopify B2Bリファレンスで最新に保っています。

よくある質問

Shopifyは基幹システム（ERP）ですか？

いいえ。Shopifyは「販売される商品」「購入する顧客」「受け付けた注文」の正本を持つシステムです。仕入、総勘定元帳、原価、生産のデータは持たず、それは基幹システムの役割です。B2Bストアでは、基幹システムが価格、在庫、顧客の商取引上の身元の正本であり続け、それらをShopifyに書きます。Shopifyは注文の正本であり続け、それを基幹システムへ渡します。

認定されたShopifyコネクタを持つERPはどれですか？

2026年9月22日時点で、ShopifyのGlobal ERP Programには五つの認定アプリがあります。Dynamics 365 Business Central、Brightpearl by Sage、NetSuite ERP Connector、Acumatica Cloud ERP、Infor eCommerce Connectorです。それ以外の基幹システムや販売管理システム、日本市場で検索されるネクストエンジンやロジレスのような受注・在庫連携ツールは、パートナー製アプリ、iPaaS、またはAdmin API経由でつながります。いずれかがB2Bの会社やカタログの価格リストまで書くかどうかは、コネクタごとにドキュメントで確認する必要があります。

見積はどうやって基幹システムやNetSuiteに入りますか？

それが変わった先の注文としてです。見積レイヤーは承諾済みの見積を、見積参照番号のタグを付けたShopifyの下書き注文に変換します。バイヤーが支払うかマーチャントが完了すると、注文はストアがすでに使っているコネクタで基幹システムへ流れ、基幹システムはタグで見積由来と認識し、参照番号で商談に結び付けます。オープンな見積を基幹システムへ押し込むものはなく、そうすべきでもありません。

Shopify FlowはHubSpotやSalesforceに見積データを送れますか？

はい、見積単位でなら送れます。Flowトリガーは送信、提案送付、カウンター、承諾、辞退、期限切れ、変換、三つの承認イベントで発火し、番号、状態、合計、通貨、バイヤーのメールアドレス、管理画面リンクを持ちます。Flowアクションを持つCRMは直接受け取り、それ以外のCRMはGrow、Advanced、Plusプランで「HTTPリクエストを送信」経由で受け取ります。明細はトリガーに含まれません。

基幹システムの価格リストをShopify B2Bに同期するには？

カタログの価格リストへ書き込みます。Admin APIの固定価格ミューテーションか、管理画面のカタログCSVインポートを使い、方向は一方向に保ちます。固定価格はカタログのパーセント調整を上書きし、インポート時に価格を空にすると固定価格が削除され、Plus以外では全B2Bマーケット合計で有効なカタログ三つが上限です。見積レイヤーは、Shopifyがその所在地に解決した価格を開始価格として使います。

これにShopify Plusは必要ですか？

パターンそのものには不要です。Flowは全プランで使え、「HTTPリクエストを送信」アクションにはGrow、Advanced、Plusのいずれかが必要で、Plus以外のカタログ上限は全B2Bマーケット合計で有効三つです。Plusでは、会社や所在地へのカタログの直接割り当て、有効カタログ数の無制限、デポジットが加わります。

PIMはどこに位置づけられますか？

Shopifyの上流であり、見積の近くではありません。PIMは商品コンテンツ、属性、メディアをShopifyの商品に書き、見積レイヤーはShopifyのバリエーションを参照して自前の商品データを持ちません。なお、日本市場の検索データにはPIMの語がほとんど現れません。商品マスタを基幹システムや販売管理システムが持つ構成でも規則は同じで、商品マスタを持つシステムがShopifyの商品を書きます。PIMや商品マスタと基幹システムの間であるバリエーションの存在について食い違いがあれば、Shopifyに届く前に解決しなければなりません。見積の明細は参照先のバリエーションを必要とするからです。

出典

Shopifyのページはすべて、特記のない限り2026年9月22日にAPIバージョン2026-07で確認しました。

• DraftOrderおよびOrderオブジェクト
• タグの使用
• CompanyInput、CompanyLocationInput、BuyerExperienceConfigurationInput、companiesクエリ、MetafieldOwnerType
• priceListFixedPricesAddおよびカタログによるB2B価格のカスタマイズ
• 一括インポート
• WebhookSubscriptionTopicおよびWebhook（2026年9月20日確認）
• Shopify FlowおよびHTTPリクエストを送信アクション
• Shopify、Global ERP Programを開始およびGlobal ERP Programコレクション
• 下書き注文によるB2B注文の作成およびB2Bのチェックアウト設定の管理
• source_name vs sales channel、Shopify Staff、Shopify Community、2022年9月28日
• Shopify Editions Spring '26、QuickBooksとMailchimpの連携について（2026年9月20日確認）

QuotWayが下書き注文に書き、注文から読み戻し、Flowに公開する内容はソースコードとテストから記述しています。マーチャント向けの説明は上にリンクしたドキュメントにあります。日本市場がこのテーマをどう呼ぶかは、2026年9月22日にサイトのキーワード調査で行ったオートコンプリート調査に基づきます。