--- title: "Shopify B2Bの技術的負債：あとから高くつく判断と廃止期限" description: "技術的負債は2種類。Shopifyが取り消しにくいと明言する判断と、期限のあるもの。checkout.liquid、Shopify Scripts、従来の顧客アカウント、APIバージョン。" url: "https://www.quotway.com/ja/blog/shopify-b2b-technical-debt" type: "blog post" category: "For Shopify agencies" published: "2026-09-24" verified: "2026-09-24" shopify_api_version: "2026-07" audience: "BtoB構築の見積もり、監査、引き継ぎを行うShopifyエージェンシーと開発者" scope: "取り消しにくい構造上の判断（ストアの種類、会社ツリー、価格の置き場所、IDキー、商談の状態、Plusへの依存）、Shopifyの廃止期限がある機能（checkout.liquid、Scripts、従来の顧客アカウント、APIバージョン）をAPI 2026-07時点で扱う。サーバー側での強制と引き継ぎ用の台帳" locale: "ja" source: "QuotWay - B2B Quote & Negotiation App for Shopify" --- # Shopify B2Bの技術的負債：あとから高くつく判断と廃止期限 Shopify B2B構築の技術的負債には2種類あり、扱い方が異なります。1つ目は**構造上の負債**です。Shopify自身があとから戻しにくいと言っている判断で、D2CとB2Bを1つにまとめた併用ストアにするかB2B専用ストアにするか、購入者を会社と所在地にどう分けるか、定常の価格をどこに置くか、どのIDキーでShopifyと基幹システム（ERP）を結ぶか、がこれにあたります。2つ目は**期限のある負債**です。Shopifyが公表したスケジュールで廃止する機能の上に作ったコードで、checkout.liquid（2024年8月13日と2025年8月28日）、Shopify Scripts（2026年6月30日に無効化）、従来の顧客アカウント（2026年2月26日に非推奨）、そして最低12か月ずつサポートされるすべてのAPIバージョンが該当します。 構造上の負債は、データが1件もないうちに決めることで返せます。期限のある負債は、日付を書き出し、それを見張る担当者を決めることで返せます。どちらも構築が始まる前にShopifyがドキュメントに書いています。高くつくのは、構築が終わってからそれに気づくことです。 このページは、構築を見積もる、あるいは引き継ぐエージェンシーのためのものです。あとから高くつく判断とその理由、期限のある機能を1つにまとめたカレンダー、ルールの強制をどこに置くべきか、構築が失敗する7つのパターン、そしてプロジェクトと一緒に引き渡す負債の台帳を扱います。見積レイヤーについて述べる箇所は1つの実装の話であり、そう明示しています。 以下のShopifyに関する記述は、別の日付を記していない限り、2026年9月24日にShopify自身のページでAPIバージョン2026-07を対象に確認しました。出典は末尾にあります。 ## 2種類の負債 | 観点 | 構造上の負債 | 期限のある負債 | | --- | --- | --- | | 何か | ほかのすべてがぶら下がるモデリング上の判断 | Shopifyが廃止を告知した機能の上に作ったコード | | 例 | ストアの種類、会社ツリー、価格の置き場所、IDキー、商談の状態の置き場所、Plusへの依存 | checkout.liquid、Shopify Scripts、従来の顧客アカウント、APIバージョンと非推奨フィールド | | 安く済むとき | 最初の会社、カタログ、注文が存在する前 | 期限の前。Shopifyは何か月も前に公表します | | 高くつく理由 | データがぶら下がる：注文、カタログ、支払い条件、履歴 | 期限が過ぎるとコードが動かなくなる。気づかないうちに、ということもある | | 返し方 | 意図して決め、理由を書き残す | 機能と期限の台帳を作り、それぞれに担当者を置く | 2つは互いを大きくします。卸売価格をShopify Scriptsに置いていたストアは、構造上の負債（価格が一度もカタログに入っていない）の上に期限のある負債（Scriptsは2026年6月30日に終了）を抱えていました。前者を返すことは、後者を返すことでもありました。 ## あとから高くつく判断 判断は6つあり、それぞれに変更を難しくしているShopify側の制約があります。最初の会社を作る前に、この順番で決めてください。 **1. 併用ストアか専用ストアか。** Shopify自身のガイダンスは率直です。「あとから変更するのは簡単ではないため、慎重に決める必要があります。一方の種類でストアを設定したあとでもう一方に切り替えたい場合は、会社、カタログ、オンラインストアのカスタマイズを含め、設定作業の大部分をやり直す必要があります」。B2B専用ストアは別のストアです。「既定ではB2Bの注文と顧客の在庫は別になり」、アプリは「もう一度設定し、もう一度料金を支払う」必要があり、拡張ストア同士では「ストアの設定、商品、コレクション、在庫は同期されません」。その同期はアプリか基幹システムの仕事になります。Plusの組織では、拡張ストアの規則に契約ごとに無料のB2Bストア1つが含まれます。どれも間違いではありません。継続的なコストを伴う選択であり、卸売が昔からそう運用されてきたからではなく、事業として別のストアフロントが必要だから選ぶべきものです。 **2. 会社ツリー。** 何を1つの会社とし、何を所在地とするか。カタログ、支払い条件、免税、配送先はすべて所在地にぶら下がり、履歴は容赦しません。「B2B注文は作成された会社に紐づいたままで、別の会社へは移行できません」。さらに、1人の顧客の移行済み注文を複数の所在地に分けることもできません。どのレコードが組織でどれが支社かを決めないまま、旧システムの顧客リストを1対1で写したツリーは、注文を移行し直しても直りません。ツリーを作り直すしかありません。これを避ける作業順序は[移行プレイブック](/blog/migrate-wholesale-customers-to-shopify-companies)にまとめています。 **3. 定常の価格をどこに置くか。** 2026年4月2日から会社、カタログ、支払い条件はすべてのShopifyプランで使えるようになり、卸売価格を顧客タグや割引コード、「卸売用」の複製商品に置いておく理由はなくなりました。こうした回避策には、それぞれ固有の保守が付いてきます。複製商品は構造上、在庫とレポートのレコードが別になり、タグのロジックはチェックアウトが読むものではなくテーマやアプリの中にあります。B2Bのチェックアウト、数量ルール、数量別価格が読むのはカタログです。カタログの数は最初に設計してください。Plus以外では、有効なカタログはすべてのB2Bマーケット合計で3つが上限なので、顧客ごとに1カタログを前提とする計画はPlusの計画です。価格の面は[SKUを複製しない卸売価格と小売価格](/blog/wholesale-vs-retail-pricing-without-duplicate-skus)、優先順位の規則は[リファレンスのカタログの行](/reference/shopify-b2b#catalogs)をご覧ください。 **4. IDキー。** `Company.externalId` と `CompanyLocation.externalId` は1つの目的のために存在します。Shopifyのレコードを基幹システムの取引先番号・配送先番号と結ぶ「外部から与えられる一意のID」で、companiesクエリはこれで絞り込めます。初日に設定すればコストはゼロです。1年後に追加するとなると、何千件ものレコードを名前で突き合わせることになり、その間に作った同期はすべて別のキーを使っています。どの項目をどのシステムが持つかは[基幹システム・CRM・PIMの連携パターン](/blog/shopify-b2b-erp-crm-pim-integration-patterns)にまとめています。 **5. 商談の状態をどこに置くか。** 下書き注文は、支払いか承認を待っている合意済みの注文です。ステータスは3つ（`OPEN`、`INVOICE_SENT`、`COMPLETED`）で、バージョンはなく、`draftOrderUpdate` は入力を丸ごと置き換えます。2025年4月1日以降に作成された下書きは、1年間編集がないと削除されます。交渉 ― 依頼、カウンター、誰が何を提示したかの履歴 ― を下書き注文に置く構築は、それを保持することも残しておくこともできない場所に置いていることになります。下書きの状態と交渉に必要な状態の対比は[Shopifyの下書き注文は見積ではない](/blog/shopify-draft-order-vs-quote)をご覧ください。 **6. Plusへの依存。** B2Bの機能の一部はShopify Plusのものです。会社や所在地へのカタログの直接割り当て、無制限の有効カタログ、前受金、分割払い、フルフィルメントごとの支払い請求、そして見落としやすいのが**Shopify Function APIを含むカスタムアプリ**で、ShopifyはこれをPlusのストアでのみ使えるとしています（Functionsを含むApp Storeの公開アプリはどのプランでも動きます）。どれも間違いではありません。いずれも構築をプランに縛るものであり、事業者はそれに依存する前に知っておくべきです。プランの違いは[BtoBにShopify Plusは必要か](/blog/shopify-b2b-without-plus)で1行ずつ確認できます。 ## 期限のある負債 Shopifyは廃止の日付を何か月も前に公表します。負債は古い機能そのものではありません。構築がそれを使っていると知らないことです。 > **Shopify B2Bの負債カレンダー（2024年8月〜2026年10月）** > > 既存のコードを負債に変える、日付の決まったShopifyの変更の年表です。2024年8月13日：checkout.liquidが情報、配送、支払いのステップで動作しなくなる。2024年10月1日：REST Admin APIがレガシーになる。2025年4月1日：新しい公開アプリはGraphQL Admin APIで構築しなければならなくなる。2025年8月28日：Plusでサンクスページと注文状況ページのcheckout.liquidと追加スクリプトが終了し、追加スクリプトの欄は閲覧専用になる。2026年2月26日：従来の顧客アカウントが非推奨になる。もともとB2Bには対応していなかった。2026年4月2日：B2Bがすべてのプランで使えるようになり、タグによる卸売は必要ではなく選択になる。2026年4月15日：Shopify Scriptsの編集と公開ができなくなる。2026年6月30日：Shopify Scriptsが非推奨になり、公開中のスクリプトが無効化される。2026年7月1日：API 2026-07でDraftOrderInput.customerIdがpurchasingEntityに置き換わる形で非推奨になり、gramsフィールドが削除される。2026年8月26日：Plus以外のストアがサンクスページと注文状況ページをアップグレードする期限。2026年10月1日：API 2026-10が安定版になる。各バージョンは最低12か月サポートされる。 > > オレンジ：機能が停止した、または非推奨になった。青：APIの規則が変わった。ティール：回避策を選択肢に変えたプラットフォームの変更。 | 機能 | 日付 | 何が起きたか | 置き換え先 | | --- | --- | --- | --- | | checkout.liquid、チェックアウト内のステップ | 2024年8月13日 | 情報、配送、支払いのステップで動作しなくなった | チェックアウトの拡張性（Checkout Extensibility） | | checkout.liquidと追加スクリプト、サンクスページと注文状況ページ（Plus） | 2025年8月28日 | 終了。追加スクリプトの欄は閲覧専用に | チェックアウトの拡張機能、ブロック、ウェブピクセルとアプリピクセル | | サンクスページと注文状況ページ（Plus以外） | 2026年8月26日 | アップグレードの期限 | 同上 | | REST Admin API | 2024年10月1日にレガシー。新規公開アプリは2025年4月1日から | 新しい公開アプリはGraphQLのみ | GraphQL Admin API | | 従来の顧客アカウント | 2026年2月26日に非推奨。終了日は今後発表 | 新規ストアでは使えず、更新もない。もともとB2Bに非対応 | 顧客アカウントとそのUI拡張 | | Shopify Scripts | 2026年4月15日に編集終了。2026年6月30日に無効化 | 公開中のスクリプトは「動作しなくなった」 | Shopify Functions | | `DraftOrderInput.customerId`、`marketRegionCountryCode` | 2026-07で非推奨 | まだ受け付けられるが、削除に向かっている | `purchasingEntity`（顧客または購入する会社） | | `DraftOrderLineItem.grams` | 2026-07で削除 | なくなった | `weight` | | すべてのAPIバージョン | 四半期ごと。各バージョン12か月以上サポート | サポート外のバージョンは、最も古いアクセス可能な安定版へ警告なしに「繰り上げ」られる | 四半期ごと、少なくとも年に1回アップグレード | B2Bに限って言えば、2つの行はもう一度見ておく価値があります。**checkout.liquidはB2Bのチェックアウトではもともと動きませんでした。** ShopifyはB2Bが対応しないものの中にcheckout.liquidのカスタマイズを挙げています。ですからB2Bストアがこの負債を抱えたことはありませんが、併用ストアのD2Cチェックアウトは抱えているかもしれず、その修正は両方に関わります。そして**APIバージョンの行こそ、静かに効いてくる行です。** Shopifyがサポートを終えたバージョンを指定したカスタムアプリは失敗しません。Shopifyはまだサポートしている最も古いバージョンで応答し、その間に非推奨になったフィールドは単にそこから消えることがあります。App Storeの公開アプリにはもっと厳しい期限があります。「アップグレードの期限を過ぎてもアプリがサポート外のリソースを使い続けている場合、Shopify App Storeから掲載を外されます」。新規インストールも最低7日間止められます。 Scriptsの行は、2種類の負債が同時にやってきた最近で最もわかりやすい例です。卸売の割引やB2Bの配送ルールをScriptsに置いていたストアは、2026年6月30日までに移す必要がありました。Functionsへの移行は、その価格はむしろカタログに入れるべきではないかを問う機会でもあり、それは構造上の問題です。見積もる際はFunctionsのプラン規則に注意してください。Functionsを含む**カスタム**アプリはPlusでしか動かないため、Scriptsを置き換えるPlus以外の事業者は、公開アプリかネイティブ機能かを選ぶことになります。割引Functionsについてドキュメントにある下書き注文の注意点は、[下書き注文の制限の記事](/blog/shopify-draft-order-limits)で扱っています。 ## 強制はサーバー側に置く 最も目立たない負債は、強制されているように見えて実はされていないルールです。テーマのコードは購入者のブラウザで動きます。ボタンを表示したり隠したりはできますが、意図のある購入者、キャッシュされたページ、2つ目のストアフロントはそれを実行しません。お金に関わるルールは、Shopifyがチェックする場所に置く必要があります。 Shopifyにはサーバー側の場所が3つあります。**カタログ**は、ログイン中の会社の所在地に表示される価格を決めます。**数量ルール**（バリアントごとの最小、最大、増分）は表示されるだけでなく、カートとチェックアウトで強制されます。そして**カートとチェックアウトの検証Function API**は「顧客が先に進む前に注文が特定の条件を満たしていることを確認する」ためのサーバー側チェックを実行します。対象はB2Bのチェックアウトと、管理画面およびチェックアウトでの下書き注文で、関数からは購入者の `purchasingCompany` を参照できます。1つのストアで有効にできるのは25個までです。 届かない場所が2つあることも知っておいてください。検証APIはCreate Order APIでも注文編集でも実行されません。`orderCreate` で直接注文を書き込む連携 ― 基幹システムからのインポートや移行スクリプト ― は、購入者に課されるルールを迂回します。そのルールは連携の側でも強制する必要があります。これは欠陥ではなく、要件定義書に書いておくべき設計上の注意点です。 ## BtoB構築が失敗する7つのパターン いずれもこのページの制約から導いたパターンであって、測定した頻度ではありません。そうした数字を公表している人はおらず、私たちも順位は主張しません。どれも上に挙げた判断のどれかを、遅れて、あるいは成り行きで決めたものです。 1. **立ち上げの速さでストアの種類を選んだ。** 卸売は昔からそうしてきたからと専用ストアにし、ストアがある限り、在庫の同期、アプリの二重課金、分断されたレポートが続く。Shopifyは、切り替えるには会社、カタログ、カスタマイズをやり直すことになると言っています。 2. **会社ツリーが旧顧客リストの写しになった。** 支社が会社になり、あるいは組織が所在地になり、注文は会社間を移れないので直せない。 3. **カタログが来たあとも価格がタグに残った。** 回避策がその理由（2026年4月2日以降、B2Bは全プラン）より長生きし、チェックアウトがすでに読んでいるカタログの仕組みの横で、独自の保守が必要になっている。 4. **誰も `externalId` を設定しなかった。** 基幹システムとの同期が名前やメールアドレスをキーにし、重複が1件出るたびにサポートチケットになる。 5. **交渉が下書き注文の中にあった。** バージョンもカウンターもなく、更新は入力全体を置き換え、放置された下書きは1年後に削除される。 6. **チェックアウトのロジックが廃止予定の機能の上にあった。** Scripts、checkout.liquid、追加スクリプト。期限はわかっていたのに追跡していなかった。 7. **APIのアップグレードに担当者がいなかった。** カスタムアプリが固定していたバージョンがあとで繰り上げられ、読んでいたフィールドがもうなかった。 どれもShopifyのバグではありません。いずれも構築前にドキュメント化されていて、構築後に発見された制約です。 ## 引き渡す負債の台帳 最も安い返済は、引き継ぎ資料の中に、各判断とその理由を書いた1ページを入れることです。構築の最後に1時間かかるだけで、次のチームがそれを発見し直す手間を省けます。 - **ストアの種類** ― 併用か専用か、そして事業上の理由。専用なら、ストア間で何を何によって同期するか。 - **会社ツリーの規則** ― 何を1つの会社とし、何を1つの所在地とするか。事業者側で誰が合意したか。 - **各価格の置き場所** ― カタログ（どれか、そしてプランの上限に対する有効数）、数量ルール、数量別の価格帯、まだタグや割引に残っているものとその理由。 - **IDキー** ― 会社と所在地の `externalId` の体系と、それぞれが対応する元システムの項目。 - **商談の状態の置き場所** ― 依頼、提案、カウンター、承認をどのシステムが持ち、Shopifyに何を渡すか。 - **Plusへの依存** ― 構築の中でPlusにしかない機能のすべて。プラン変更のコストがわかるように。 - **Shopifyの期限がある機能** ― 構築が依存する拡張、Function、スクリプト、テーマブロック、APIのうち、非推奨が告知されているものとその日付。 - **APIバージョン** ― 各カスタムアプリが固定しているバージョン、そのバージョンのサポートが終わる日付、四半期ごとのアップグレードの担当者名。 - **強制のマップ** ― どのルールがカタログ、数量ルール、検証Functionで強制され、どれがテーマの中だけにあるか。 - **チェックアウトを迂回する連携** ― `orderCreate` で注文を書き込むものすべてと、それが購入者のルールをどこで適用し直すか。 対になるのが[50テストの公開チェックリスト](/blog/shopify-b2b-launch-test-plan)です。台帳は何を決めたかを記録し、テスト計画はそれが動くことを証明します。 ## 見積レイヤーの位置づけ 1つの実装の話として明示します。見積アプリは商談の記録システムを1つ加えるので、それ自体が負債を加えることもあります。その量を決める問いは**何を保存するか**です。Shopifyのレコードへの参照か、そのコピーか。コピーした顧客リストや価格表は、誰かが同期し続けなければならない2つ目の正本です。参照なら、必要なときにShopifyから読みます。 QuotWayは参照を保存します。見積には、顧客、会社、所在地、担当者、商品、バリアントのShopify ID、バージョンごとの商品タイトルのスナップショット、そして交渉した価格 ― カタログの基準価格、購入者の希望額、提示額、最終価格 ― が入ります。定常の価格表は持ちません。会社担当者への提案は、リクエストが届いた時点で解決したその会社の所在地のカタログ価格から始まります。交渉の状態は見積の中にとどまります。バージョン、カウンター、承認、そして明細がロックされた送信済みの提案です。変更は編集ではなく、新しいバージョンかカウンターになります。[下書き注文](/features/convert-to-orders)になるのは合意した結果だけで、非推奨の `customerId` ではなく `purchasingEntity` で作成され、Enterpriseプランでは所在地の支払い条件も付きます。会社に対応した見積はEnterpriseプランです。プランの内容は[料金ページ](/pricing)に、会社に対応した機能は[Shopify B2B見積機能のページ](/features/b2b)にあり、この分担の背景にある設計は[Shopifyに置くものと見積レイヤーに属するもの](/blog/shopify-b2b-quote-architecture)で説明しています。 どのアプリを評価するにしても、保存の問いを直接尋ねてください。[Shopify B2Bアプリの評価チェックリスト](/blog/shopify-b2b-app-evaluation-checklist)には、この問いがほかの52項目と一緒に載っています。 この記事のShopify関連の事実は[Shopify B2Bリファレンス](/reference/shopify-b2b#api-versions)で最新に保っています。 ## よくある質問 ### Shopify B2B構築における技術的負債とは何ですか？ 2つあります。Shopifyが戻しにくいと言っている構造上の判断 ― 併用ストアか専用ストアか、会社ツリー、定常の価格の置き場所、IDキー ― と、checkout.liquid、Shopify Scripts、従来の顧客アカウント、APIバージョンのように、廃止日が公表されている機能の上のコードです。前者は早く決めることで、後者は日付を追跡することで返します。 ### 別の卸売ストアから1つの併用ストアへ、あとから切り替えられますか？ できますが、設定変更ではなく作り直しです。Shopifyのストアの種類に関するガイダンスは、この選択は「あとから変更するのは簡単ではない」とし、切り替えるには「会社、カタログ、オンラインストアのカスタマイズを含め、設定作業の大部分」をやり直すことになると述べています。拡張ストア同士では、設定、商品、コレクション、在庫は同期されません。 ### Shopify ScriptsはBtoBの価格設定にまだ使えますか？ 使えません。Shopify Scriptsは2026年6月30日に非推奨になり、公開中のスクリプトは無効化されました。編集は2026年4月15日にすでに終わっていました。置き換え先はShopify Functionsです。Functionsを含むカスタムアプリはPlusのストアでしか動きません。Functionsを含むApp Storeの公開アプリはどのプランでも動きます。 ### checkout.liquidの非推奨化はB2Bに影響しますか？ B2Bのチェックアウト自体には影響しません。もともとcheckout.liquidのカスタマイズに対応していなかったからです。影響を受けるのは併用ストアのD2Cチェックアウトです。checkout.liquidは2024年8月13日に情報、配送、支払いのステップで、Plusでは2025年8月28日にサンクスページと注文状況ページで動作しなくなりました。Plus以外のストアは、この2つのページを2026年8月26日までにアップグレードする必要がありました。 ### カスタムアプリが古いAPIバージョンを使っているとどうなりますか？ 最初は目に見えることは何も起きません。各安定版は最低12か月サポートされ、その後はそのバージョンを指定したリクエストが最も古いアクセス可能な安定版へ「繰り上げ」られるため、その間に削除されたフィールドは返されなくなります。サポート外のリソースを使い続ける公開アプリはApp Storeから掲載を外され、インストールが最低7日間止められます。バージョンを固定し、四半期ごとのアップグレードを誰かの担当にしてください。 ### タグによる卸売価格は、もう技術的負債ですか？ もともとの理由がなくなった回避策です。2026年4月2日から会社とカタログはすべてのShopifyプランで使え、B2Bのチェックアウト、数量ルール、数量別価格が読むのはカタログです。タグによる設定は今も動きますが、ネイティブの仕組みの横で保守する余分なロジックです。次に価格に手を入れるときに移し、Plus以外では有効なカタログ3つの上限を前提にカタログ数を計画してください。 ### B2B注文を別の会社へ移せますか？ 移せません。Shopifyは、B2B注文は「作成された会社に紐づいたままで、別の会社へは移行できません」と明記しています。だからこそ会社ツリーは、注文が1件もないうちに正しく決めておくべき判断なのです。 ## 出典 Shopifyのページ。別記がない限り、すべて2026年9月24日にAPIバージョン2026-07で閲覧： - [BtoBビジネスのストアの種類を選ぶ](https://help.shopify.com/en/manual/b2b/getting-started/store-type) ―併用ストアと専用ストアの違い、および「あとから変更するのは簡単ではない」 - [拡張ストア](https://help.shopify.com/en/manual/organization-settings/expansion-stores) ―B2Bストアの種類と、ストア間で同期されないもの - [checkout.liquid](https://shopify.dev/docs/storefronts/themes/architecture/layouts/checkout-liquid)、[2024年8月13日のchangelog](https://shopify.dev/changelog/checkout-liquid-will-no-longer-work-for-in-checkout-pages-starting-august-13-2024)、[サンクスページと注文状況ページのアップグレード](https://help.shopify.com/en/manual/checkout-settings/checkout-extensibility/checkout-upgrade) - [Shopify Scriptsの要件と制限](https://help.shopify.com/en/manual/checkout-settings/script-editor/limitations) ―2026年6月30日に非推奨。2026年4月15日の編集終了は[changelog](https://changelog.shopify.com/posts/shopify-scripts-can-no-longer-be-edited-or-published)から（2026年9月22日閲覧） - [Shopify Functions](https://shopify.dev/docs/apps/build/functions) ―Functionsを含むカスタムアプリのプラン規則 - [カートとチェックアウトの検証Function API](https://shopify.dev/docs/api/functions/latest/cart-and-checkout-validation) ―対応する画面、`purchasingCompany`、1ストア25個まで - [APIのバージョン管理](https://shopify.dev/docs/api/usage/versioning) ―リリース周期、12か月のサポート、繰り上げ、掲載取り下げ - [REST Admin API](https://shopify.dev/docs/api/admin-rest) ―2024年10月1日以降レガシー（2026年9月20日閲覧） - [Legacy customer accounts are now deprecated](https://changelog.shopify.com/posts/legacy-customer-accounts-are-now-deprecated) と [B2Bのログインと顧客アカウント](https://help.shopify.com/en/manual/b2b/customer-login-and-accounts)（2026年9月20日〜22日閲覧） - [DraftOrderInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/DraftOrderInput) と [2026-07のリリースノート](https://shopify.dev/release-notes/2026-07)（2026年9月20日〜22日閲覧） - [顧客をB2Bへ移行する](https://help.shopify.com/en/manual/b2b/getting-started/migrating-customers)（2026年9月23日閲覧） - [CompanyInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/CompanyInput) と [CompanyLocationInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/CompanyLocationInput)（2026年9月22日閲覧） - プラン、カタログ、下書き注文、制限に関する規則：[Shopify B2Bリファレンス](/reference/shopify-b2b)、2026年9月20日〜23日に再確認 QuotWayの保存モデルは、QuotWay自身のデータスキーマに基づいて記述しています。