--- title: "卸売顧客をShopifyの会社へ移行する：代理店のプレイブック" description: "移行経路は2つあり、APIがあるのは片方だけです。制約、作業順序、顧客2万件の実際のコスト、そして取り消せる範囲。" url: "https://www.quotway.com/ja/blog/migrate-wholesale-customers-to-shopify-companies" type: "blog post" category: "For Shopify agencies" published: "2026-09-23" verified: "2026-09-23" shopify_api_version: "2026-07" audience: "タグ運用や旧システムの卸売からネイティブの会社機能への移行を見積もるShopify代理店と開発者" scope: "既存顧客をShopifyの会社へ移行する作業をAPI 2026-07時点で扱う：管理画面からの移行とその制約、orderCreateによる注文インポート、会社・ロケーション・担当者・ロール・カタログの連鎖、レート制限下のスループット、ID の突合、パイロットと巻き戻し" locale: "ja" source: "QuotWay - B2B Quote & Negotiation App for Shopify" --- # 卸売顧客をShopifyの会社へ移行する：代理店のプレイブック 卸売顧客がShopifyの会社になる道筋は2つあり、その違いが計画のすべてを決めます。注文がすでにD2C注文としてShopifyの中にあるなら、経路は管理画面です。一度に250人まで、1人の顧客の注文履歴は全部か全く無しか、行き先は会社ロケーション1つだけ。そしてこの操作にAPIはありません。実行するミューテーションがShopify内部のものだからです。注文が旧システムにあるなら、`orderCreate` に会社ロケーションを添えたインポート注文として入ります。こちらはスクリプト化できますが、会社・ロケーション・担当者・ロールが先に存在していることが条件です。 失敗する移行計画のほとんどは、1つ目の経路にAPIがあると仮定しています。ありません。そしてそれを要件定義書に署名したあとで知るのは高くつきます。 このページは、その移行を見積もる代理店のためのプレイブックです。2つの経路とその見分け方、作業順序を決める依存関係の連鎖、要件定義書に貼れる制約の表、各プランのレート制限で見込めるスループット、パイロットの回し方、そして取り消せるものと取り消せないもの。見積もりレイヤーが移行中にどう振る舞うかを述べる箇所は実装の話であり、そう明示しています。 以下のShopifyに関する記述は、2026年9月23日にShopify自身のページでAPIバージョン2026-07を対象に確認しました。出典は末尾にあります。 ## 2つの経路 判断を決めるのは1つの問いです。会社に紐づけたい注文はすでにShopifyの注文なのか、それとも別の場所にあるのか。前者の経路は管理画面を通り、スクリプト化できません。後者は `orderCreate` を通り、スクリプト化できます。 > **注文がどこにあるかが移行経路を決める** > > 判断のフロー図です。左の問いは「卸売の注文は今どこにあるか」。すでにShopify内のD2C注文であれば、経路は管理画面からの移行です。最大250人の顧客を選んで会社に追加すると、注文履歴の全体が1つの会社ロケーションへ移ります。移行ミューテーションがShopify内部のものであるため、公開APIはありません。旧システムや他プラットフォームにあるなら、経路は注文インポートです。先に会社・ロケーション・担当者・ロールを作成し、履歴の注文ごとに companyLocationId と customer.toAssociate を付けた orderCreate を呼びます。こちらはスクリプト化できます。2つの経路は同じ最終状態、すなわちカタログ・支払条件・履歴を備えた会社ツリーに合流します。3つ目の枠は、どちらの経路でもできないことを挙げています。B2B注文を会社間で移すこと、履歴の一部だけを移行すること、履歴を複数ロケーションに分けること、キャンセル済みまたは削除済みの注文を移行することです。 > > 問いは1つ、そこで計画が決まります。2つの経路は同じ会社ツリーに行き着きますが、スクリプト化できるのは片方だけで、しかも多くの計画が想定している側ではありません。 **経路A ― 注文がすでにShopifyのD2C注文である場合。** 通常の顧客アカウントでビジネス購入者に販売し、価格はタグや割引コードで代用してきたストア（[Wholesale Channelを置き換えた形](/blog/shopify-wholesale-channel)）が、会社機能に移りたいというケースです。Shopifyの管理画面はこれに対応しています。顧客ページで顧客を選び ―「一度に最大250人のB2B顧客を選択するか、それより小さいバッチに分けて実行」― 新規または既存の会社に追加します。過去のD2C注文は顧客について移ります。 見積もりの前に知っておくべきこと。**この操作に公開APIはありません。** Shopifyのスタッフが2025年12月に開発者フォーラムで確認しています ―「`CompanyLocationMigrateOrdersMutation` と `CompanyLocationRevertMigratedOrders` は内部専用で、公開APIには公開されていません」。B2Bプロダクトチームに確認済みとのことです。会社・ロケーション・担当者はAdmin APIでいくらでも作れますが、注文履歴を運ぶ工程だけは人が管理画面で操作するもので、しかも250人ずつです。 **経路B ― 注文が別の場所にある場合。** 旧ERP、以前のプラットフォーム、廃止した卸売チャネル。ここではShopifyの中で移行するのではなくShopifyへ取り込むので、APIは*あります*。`orderCreate` に `companyLocationId` と `customer.toAssociate` を付ける形で、Shopifyが履歴注文データ向けに明示的にドキュメント化しています。実装がつまずく要件はこれです ―「顧客は指定した会社ロケーションにロールの割り当てを持っている必要があります。持っていない場合はエラーが返ります」。より広くは ―「B2B事業者は、B2B注文をインポートする前に、関連するすべての会社、会社ロケーション、会社担当者、商品をShopifyにインポートまたは作成しておく必要があります」。 実際の案件はたいてい混在です。Shopifyに履歴がある取引先、旧システムに履歴がある取引先、両方ある取引先。順序を決める前にリストを経路で仕分けてください。2つの経路はスループットも担当者も故障モードも違います。 ## 依存関係の連鎖 各工程が次の工程をブロックします。だから並列化した移行は孤児レコードを生みます。 1. **会社ツリーを決める。** 購買組織ごとに会社を1つ。独自の価格、支払条件、税ステータス、配送先を持つ拠点ごとにロケーションを1つ。あとから変えるのが最も高くつく判断です。カタログも条件も注文も、すべてロケーションにぶら下がるからです。 2. **会社とロケーションを作成する。** 両方に `externalId` を入れ、値は元システムの取引先IDと配送先IDから取ります。このフィールドが旧データへの唯一の結合キーであり、以降の同期・照合・監査はすべてここにぶら下がります。 3. **担当者を紐づける。** `companyAssignCustomerAsContact` は既存のShopify顧客を会社担当者に変えます。以後「顧客は会社を代表して注文できる会社担当者となり、その会社のロケーションに設定されたカタログ、価格、支払条件にアクセスできます」。`companyCreate` は会社・ロケーション1件・担当者1件を1回の呼び出しで作成でき、新規ツリーではこちらが効率的です。 4. **ロケーションにロールを割り当てる。** 注文のみか、ロケーション管理者か。これがないと下流は何も動きません。購入も、注文インポートもです。 5. **カタログを紐づける。** 購入者が価格を見るには、ロケーションにカタログが必要です。Plus以外ではB2Bマーケット経由で、有効なカタログは全マーケット合計3つが上限。Plusではカタログを会社またはロケーションに直接割り当てられます。ログイン中の購入者に対してカタログがどう解決されるかは[見積の開始価格はどこから来るのか](/blog/shopify-b2b-quote-starting-price)にまとめています。 6. **支払条件と税を設定する。** どちらも*ロケーション*にあります。本社が60日、支社が30日という設定は回避策ではなく通常の構成です。列挙されている種別と注文上での挙動は[ShopifyのBtoBの支払条件](/blog/shopify-b2b-payment-terms)をご覧ください。 7. **そのうえで履歴。** 該当する経路で。最後にするのは、部分的に取り消せない唯一の工程だからです。 この順序が購入者側にもたらす意味。工程1から6まで終わった時点で、B2Bストアはもう動いています。履歴の注文が1件も動く前に、価格も条件も購入も機能します。これは切り替え計画上の重要な点です。履歴はレポートであって、機能ではありません。 ## 要件定義書に書く制約 | 制約 | 内容 | 計画への影響 | | --- | --- | --- | | 移行できる注文 | D2C注文のみ。「B2B注文は作成された会社に紐づいたままで、別の会社へは移行できません」 | 会社の割り当てを間違えても再移行では直りません。ツリーを先に正しく作ること | | 履歴の範囲 | 「顧客の注文履歴は全体のみを会社に追加でき、部分的な移行はサポートされません」 | 直近2年だけ持ってくることはできません。顧客単位で全部か無しか | | 履歴の行き先 | 「注文を複数のロケーションに分割することはできません」 | 3拠点分を発注していた顧客も、行き先は1ロケーション。どれにしたかを記録すること | | 対象外の注文 | 「キャンセル済みまたは削除済みの注文は移行できません」 | 先に除外しておかないと、照合件数が元データと合いません | | バッチサイズ | 「一度に最大250人のB2B顧客」 | 顧客2万人なら管理画面で80バッチ、手作業です | | 自動化 | 移行と巻き戻しのミューテーションはShopify内部 | 経路Aではスクリプト工数ではなく管理画面の作業時間を見積もること | | 顧客について移るもの | 過去の注文、免税設定、「顧客が任意の住所に配送できるようにする」、「すべての注文をドラフトとして送信しレビューする」、支払条件 | これらは移行される設定です。可能なら元の顧客レコード側で整えておくこと | | 移らないもの | 「税を徴収するをオフにする形で設定された免税は移行されません」 | ロケーション側で正式な免税として設定し直すこと | | 巻き戻し ― 新規会社 | 会社を削除する | 会社が新規でB2B注文がない限り、きれいに戻せます | | 巻き戻し ― 既存会社 | 顧客を削除し、そのとき「移行した元の注文を削除するオプション」が出る | 巻き戻しは顧客単位で、注文単位ではありません | | 前提条件 | 管理画面に既存のD2C顧客がいること | Shopifyの顧客だったことがない取引先に経路Aは使えません | ## スループット：顧客2万件の実際のコスト 経路ごとに答えが違います。 **経路Aは人の作業であって、スループットではありません。** 1バッチ250人が唯一のレバーです。顧客2万人なら管理画面を80回通ることになり、その都度誰かが正しい顧客を選び正しい会社を指定します。つまり本当の制約はShopifyの速度ではなく、対応表をどれだけ整えておけるかです。対応表は表計算で作り、会社に入れたのと同じ `externalId` をキーにし、1バッチが1社分の顧客だけになるよう並べ替えます。そうすれば操作は判断の繰り返しではなく機械的な作業になります。 **経路Bはレート制限です。** 会社系のミューテーションはバルク操作の対応リストに入っていません。つまり会社用のJSONLインポートは存在せず、プランのポイント予算に対する通常のAPI呼び出しになります。GraphQL Admin APIの回復レートは **Standardで毎秒100ポイント、Advancedで200、Plusで1,000、Commerce Componentsで2,000** で、単一クエリは1,000ポイントを超えられず、予算超過は `429 Too Many Requests` を返します。会社1件あたりのコスト ― ロケーションと担当者も作る `companyCreate`、ロール割り当て、カタログ割り当て ― を数え、件数を掛け、回復レートで割る。これで計画に載せられる根拠のある数字になります。それ以上の精度は、自分のミューテーションのコストを開発ストアで実測するまでは推測です。 経路Bの注文インポートも1注文あたり同じ算数で、注文こそが大きい数です。顧客2万件で5年分の履歴があるストアなら数十万レコードのインポートになります。数日がかりのジョブとして計画し、元システムの注文IDに基づく冪等性を持たせて、再実行が二重書き込みにならないようにします。 ## IDの突合：誰も見積もらない部分 移行はAPIの案件の顔をしたデータクレンジングの案件です。期間を決める問いは3つあり、どれも技術的な問いではありません。 - **何を1つの会社とするか。** 元システムの顧客レコードは、たいてい組織・支社・配送先が混ざっています。「これは4ロケーションを持つ1社か、4社か」の答えが、カタログも支払条件もレポートも変えます。構築前に事業者側の経理と営業と決めてください。 - **誰が担当者で、どのロケーションに属するか。** 同じ人が複数拠点向けに購買することはよくあります。Shopifyのモデルでは担当者はロケーションにロールを持てますが、元データが「この人はどのロケーション向けに買うのか」を言えるかどうかは早めに確かめるべき点です。ロールの割り当ては注文インポートの前提条件だからです。 - **どの重複が本物か。** 同じメールアドレスの2件は同一人物です。同じ会社名でメールが違う2件は、2つの支社かもしれないし、支社1つと打ち間違いかもしれません。名前の近さではなく元システムの `externalId` で解決し、却下した突合候補はファイルに残しておいてください。必ず聞かれます。 やり直しを防ぐ実務上の原則 ―**人が決めるべきことを移行スクリプトの中で決めない。** スクリプトは対応表に書かれたものを作るだけ。判断は対応表の中にあり、取引先を知っている人がレビューできます。 ## パイロット、それから切り替え パイロットは **ロケーションを2つ以上持ち、その両方向けに購買する担当者がいる会社1社** で回します。このテストケース1つで表の制約が全部効いてきます。履歴は2つのうち片方にしか置けず、条件はロケーションごとに違い得て、担当者は両方にロールが要り、巻き戻しは注文がすでに動いた状態から試すことになります。 まず開発ストアで、次に本番の実在するが取引量の少ない取引先で実施します。確認は次の順で。購入者がログインして自分の価格を見られる。テスト注文に正しい支払条件が付く。履歴の注文が正しいロケーションに表示される。巻き戻しで顧客と移行済み注文が戻る。そしてキャンセル済みと削除済みを除外したうえで、照合クエリの件数が合う。 そのあとで初めてバッチを流します。どの顧客がどのバッチでどの会社に移ったかの記録を残してください。管理画面はそれをくれませんし、3か月後に「この取引先の履歴が短く見えるのはなぜか」と聞かれたときに必要になるのはその記録です。 ## この間、見積もりレイヤーはどこに位置するか 実装の話として明示します。顧客リストの複製を自分で持たずShopifyを読む見積もりレイヤーは、片側では移行の影響を受けず、もう片側では依存します。会社固有の価格を出すには会社ツリーとカタログ（工程1から6）が必要で、履歴の工程からは何も必要としません。つまり見積もりはID と価格が整った時点で本番投入でき、それは管理画面の最後のバッチより何週間も前であることがよくあります。 QuotWayはこの形で動きます。ログイン中の会社担当者に提示する見積もりは、その会社ロケーションのカタログ価格からリクエスト時に解決して始まり、承認された見積もりは `purchasingEntity` とそのロケーションの支払条件を持つ[ドラフト注文](/features/convert-to-orders)に変換されます。自前の顧客リストも価格表も保持しないので、QuotWay側に移行するものはありません。会社に紐づく見積もりはEnterpriseプランです。専用ページは[Shopify B2B見積もり機能のページ](/features/b2b)、この設計の背景は[Shopifyに置くものと見積もりレイヤーに属するもの](/blog/shopify-b2b-quote-architecture)、プランは[料金ページ](/pricing)にあります。 この記事のShopify関連の事実は[Shopify B2Bリファレンス](/reference/shopify-b2b#migration)で最新に保っています。 ## よくある質問 ### 卸売顧客をShopifyの会社へAPIで移行できますか 会社・ロケーション・担当者はAdmin APIで作成できますが、顧客の既存のShopify注文履歴を移すことはできません。移行と巻き戻しのミューテーションが内部専用で公開されていないことを、Shopifyのスタッフが2025年12月に確認しています。この工程は管理画面で、一度に250人までです。Shopifyの外から来る履歴注文は別の作業で、そちらにはAPIがあります ―注文に会社ロケーションを付けた `orderCreate` です。 ### 顧客を会社担当者にすると注文履歴も付いてきますか 意図的に移行した場合だけです。管理画面からの移行で顧客を会社に追加すればD2C注文履歴が移りますが、APIで顧客を担当者として割り当てるだけでは履歴は動きません。B2B注文は会社間を移ることはありません。 ### 顧客の履歴の一部だけを移行できますか できません。Shopifyのドキュメントは明示的です ―「顧客の注文履歴は全体のみを会社に追加でき、部分的な移行はサポートされません」。キャンセル済みと削除済みの注文は完全に対象外です。 ### 1人の顧客の履歴を2つの会社ロケーションに分けられますか できません。注文を複数ロケーションに分割することはできず、3拠点向けに発注してきた購入者の履歴も1ロケーションに入ります。どれを選びどういう理由かを記録してください。そうしないと、ストアを引き継いだ人にはロケーション別レポートが間違って見えます。 ### 卸売顧客2万件をどう移行しますか まずリストを経路で仕分けます。注文がすでにShopifyのD2C注文である取引先は、管理画面で250人ずつ80バッチ。作業の本体は、各バッチを機械的にこなせる対応表を用意することです。履歴が旧システムにある取引先はスクリプト化します。プランのレート制限内でAdmin APIによりツリーを作り、そのあと `orderCreate` で注文をインポートし、元システムの注文IDで冪等にします。 ### 移行は取り消せますか 部分的には可能です。新規に作成した会社は削除でき、顧客と移行済み注文が戻ります。既存の会社から顧客を削除する場合は、移行した注文も一緒に戻すオプションが出ます。どちらも注文単位の巻き戻しではなく、だからこそ履歴を最後に回します。 ### 会社へ移行するにはShopify Plusが必要ですか いりません。[B2BはすべてのShopifyプランで使え](/blog/shopify-b2b-without-plus)、会社・ロケーション・担当者・支払条件はプランを問わず利用できます。Plusが変えるのはカタログ側です ―有効なカタログ数が無制限で、会社またはロケーションへ直接割り当てられます。Plus以外はB2Bマーケット全体で有効なカタログ3つまでです。そしてプランはAPIのレート制限も決めるので、スクリプトによるインポートの速度もここで決まります。 ## 出典 Shopifyのページ。別記がない限り、すべて2026年9月23日にAPIバージョン2026-07で閲覧： - [顧客をB2Bへ移行する](https://help.shopify.com/en/manual/b2b/getting-started/migrating-customers) ―D2C限定の規則、履歴は全部か無しか、ロケーション分割不可、250人バッチ、顧客について移るもの、2つの巻き戻し経路、キャンセル済みと削除済みの除外 - [Historic orders linking to Company / Customer](https://community.shopify.dev/t/historic-orders-linking-to-company-customer/26587) ―Shopifyスタッフ、2025年12月2日：移行と巻き戻しのミューテーションは内部専用 - [B2B注文のインポート](https://shopify.dev/docs/apps/build/b2b/import-orders) ―`companyLocationId` と `customer.toAssociate` を付けた `orderCreate`、およびロール割り当ての要件 - [companyCreate](https://shopify.dev/docs/api/admin-graphql/latest/mutations/companyCreate) と [companyAssignCustomerAsContact](https://shopify.dev/docs/api/admin-graphql/latest/mutations/companyAssignCustomerAsContact) - [Start building for B2B](https://shopify.dev/docs/apps/build/b2b/start-building) ―作成順序とカタログの前提条件 - [GraphQL Admin APIのレート制限](https://shopify.dev/docs/apps/build/apis/graphql-admin/rate-limits) ―プラン別の回復レートと1クエリ1,000ポイントの上限 - [バルクインポート](https://shopify.dev/docs/api/usage/bulk-operations/imports)（2026年9月22日閲覧）―対応ミューテーションの一覧。会社系のミューテーションは含まれていません - カタログ・支払条件・税の規則：[Shopify B2Bリファレンス](/reference/shopify-b2b#migration)、2026年9月22日と23日に再確認 移行中のQuotWayの挙動は、自社のアーキテクチャと上記のドキュメントに基づいて記述しています。