顧客アカウントの上にShopify B2Bポータルを作る前に知っておくこと

Shopify B2Bのバイヤーポータルは、アカウントを持つバイヤーにはShopifyの顧客アカウントの上に、持たないバイヤーには独自の面の上に作ります。判断はそれだけです。エージェンシーがいまだに口にする問い、「新しい顧客アカウントか、従来のアカウントか」は、Shopifyが従来アカウントを非推奨にした2026年2月26日に問いではなくなりました。そもそもB2Bの問いだったこともありません。B2Bは従来アカウントの上で動いたことがないからです。残る判断は、四つの面のどれがポータルのどの部分を担うかで、その答えはバイヤーに関する二つの事実で決まります。顧客アカウントを持っているか、そしてそのアカウントが会社所在地に紐づいているかです。

このページは、B2B構築のバイヤー側の範囲を決めるエージェンシーのためのものです。顧客アカウントがいま何であり、ログイン済みのB2Bバイヤーがアプリなしで何を得ているか。ポータルが使える四つの面と、それぞれが担えるものを、判断を決めるプラットフォームの制限とともに。顧客アカウント拡張で何ができて何ができないか。ゲストのバイヤーをどこに置くか。ヘッドレスは何を変えるか。バイヤーは下書き注文を見られるか。そしてアカウントモデルの誤解から生まれる失敗パターン。QuotWayが見積をアカウントの中に置く方法を述べる箇所は、一つの実装であり、そのように明示しています。

以下のShopifyに関する記述はすべて、2026年9月22日にShopify自身のページに対してAPIバージョン2026-07で確認したものです。出典は末尾にあります。

顧客アカウントはいま何か

Shopifyには、新規ストア向けの顧客アカウントシステムが一つと、非推奨になったものが一つあります。現行のアカウントは、メールアドレスとそこへ送られるワンタイムコードでバイヤーをログインさせます。「パスワードは不要」で、B2Bではそのメールアドレスが会社所在地のものなので、ログインは同時に会社の確認でもあります。複数の所在地に紐づくバイヤーは、カートに何かを入れる前に、どの所在地として購入するかを選びます。アカウントはストア自身のドメインのサブドメイン、たとえばaccount.yourstore.jpに置け、ストアはOAuth 2.0またはOpenID Connectで自前のIDプロバイダーを接続できます。Spring '26エディションではAuth0、Ping Identity、Azure IDからのプロフィールとタグの同期、そして最長365日のセッションが加わりました。

従来の顧客アカウントは2026年2月26日付で非推奨です。新規ストアでは利用できず、今後の更新もなく、終了日は「2026年後半に発表」されます。そしてShopifyのB2Bドキュメントは明確です。「従来の顧客アカウントはB2Bの顧客と注文には使用できません」。従来アカウントの分岐をまだ抱えている構築計画は、存在しえないストアのための計画です。

ログイン済みのB2Bバイヤーがアプリなしでアカウントから得られるものは、構築側が想定するより多いことがあります。

いまアカウントにあるもの	内容
注文	バイヤーの所在地をまたいだ注文履歴、追跡、過去の注文を複製しての再注文、返品依頼
支払条件	支払条件付きの注文には「今すぐ支払う」ボタン、期日、期限を過ぎた後の「期限超過」表示。バイヤーは期日前ならいつでも支払える
デポジット	デポジットの金額と残額の期日を、チェックアウト、サンクスページ、アカウントで表示（デポジットはPlusの機能）
会社	会社と所在地の情報、保存された支払方法。住所の編集にはロケーション管理者の権限が必要
権限	「注文のみ」は自分の注文を見る。「ロケーション管理者」はその所在地のすべての注文を見て、住所を編集する

ないのは、見積に関するすべてです。依頼も、提案も、バージョンも、カウンターも、承認もありません。その空白をポータルが埋め、下の四つの面がそれを埋められる場所です。

四つの面

各行を決める制限とともに示すマトリクス：

	標準の顧客アカウント	顧客アカウントUI拡張	ホスト型ポータル（アプリ）	ヘッドレスのストアフロント
誰が使えるか	ログイン済みの顧客。B2Bの挙動は会社所在地に紐づいている場合のみ	同じ。拡張はアカウントの中に描画される	リンクを持つ全員：ゲスト、アカウントのないバイヤー、現行アカウントのないストア	ストアフロントがCustomer Account APIでログインさせたバイヤー
ログイン	メール＋ワンタイムコード。任意でOIDCプロバイダー	Shopifyのもの。すでに完了している	アプリ独自：マジックリンクと、同じ受信箱へのコード	Customer Account APIの認可フロー
どこにあるか	Shopifyのホスト、またはaccount.yourstore.jp	アカウントの中。フルページはメニュー項目と独自のルートを持つ	アプリのドメイン	自社のドメイン
UIの自由度	エディター以外なし	Shopifyのウェブコンポーネントのみ。隔離されたワーカーで動作。拡張ごとに64 KB、フルページは128 KB	完全	完全
ブランディング	ストアのアカウントテーマ	ストアのアカウントテーマ。拡張はそれを継承	アプリのもの。対応していればストアのロゴと色	自社のもの
アプリが届くデータ	-	api_accessでStorefront APIの読み取り（商品、コレクション、メタオブジェクト）。network_access＋セッショントークンでアプリ自身のバックエンド。認証済みアカウントのpurchasingCompany	アプリのバックエンドが持つもの	Customer Account API＋バイヤーコンテキスト付きStorefront API
バイヤーが標準で見るもの	注文、支払条件、デポジット、再注文、返品、会社情報	それに加えて拡張が足すもの	アプリが描画するものだけ	自分が描画するものだけ
下書き注文・請求書	請求書リンク経由。支払条件付きの注文には今すぐ支払う	Customer Account APIがinvoiceUrl付きのdraftOrdersを公開するので、ページで一覧化できる	アプリがリンクするもの	拡張と同じAPI
見積	なし	あり。アプリのバックエンドから	あり	あり。自分で作れば
失敗の起きる場所	Shopify側	バンドル上限、ターゲットの規則、CORSとトークン検証	メールの到達性、二つ目のドメイン	ログインを含むすべて

列は競合ではなく分業として読んでください。会社のバイヤーに対応する構築は見積ページをアカウントの中に置きます。そのバイヤーはすでにそこで請求書を支払っているからです。同じ構築がホスト型の面も残します。ゲスト、アカウントがまだ会社に紐づいていないバイヤー、現行アカウントに移行していないストアは、いずれも拡張の届く範囲の外にあるからです。ヘッドレスは、ストアフロントを自前で持つストアでは最初の二列を置き換えますが、三列目については何も置き換えません。

アカウント拡張で何ができて何ができないか

拡張は、多くの構築が両方向に過小評価する面です。メニューのリンク以上のことができ、ページ以下のことしかできません。

どこに描画できるか。 マーチャントがアカウントのナビゲーションに加えるフルページ（customer-account.page.render、「特定の注文に紐づかない」）。返品のようなフローのための注文に紐づくページ。注文一覧と注文ステータスページのブロックとお知らせ。モーダルで開く注文アクション。プロフィールのブロック。そこにはB2B専用のもの、つまり会社情報、所在地の住所、所在地の支払方法、所在地のスタッフ一覧の後に描画されるターゲットが含まれます。フッターの枠。Shopify自身の規則は、「フルページのターゲットは、一つの拡張の中で他の拡張ターゲットと組み合わせられない」です。したがって見積ページと、注文ページの「見積を見る」リンクは二つの拡張になり、ストアがエディターから両方を一緒に追加できるようにするには、二つ以上の拡張を必要とするエディター拡張コレクションでまとめます。

何の中で動くか。 「顧客アカウントページや他のUI拡張から切り離された隔離サンドボックス」、つまりWeb Workerの中で、独自のHTMLとCSSではなく、「Shopifyのデザインシステムに従うネイティブなUI要素」であるShopifyのウェブコンポーネントを描画します。コンパイル後のバンドルは「64 KBを超えられず、フルページの顧客アカウント拡張では128 KB」です。拡張は「機密性の高い決済情報や顧客アカウントページそのもの」にアクセスできません。この三つの制約を合わせると、拡張は薄いクライアントです。見積の状態、規則、書類はバックエンドにあり、ページは取得して描画するだけです。

何に届くか。 api_accessではStorefront APIの「商品、コレクション、商品タグ、販売プラン、メタオブジェクトへの未認証の読み取りアクセス」が得られます。商品データと、ストアごとの文言やルートのスラッグといったアプリ所有のメタオブジェクトを読むには十分です。network_accessではアプリ自身のバックエンドに届きますが、Shopifyが明記する二つの条件があります。レスポンスはAccess-Control-Allow-Origin: *を返さなければならず、「リクエストはインターネット上のどこからでも発生しうる」。セッショントークンが証明するのは顧客の身元であって、呼び出しがShopifyから来たことではありません。だからバックエンドはリクエストごとにトークンを検証し、送信元を信用しません。認証済みアカウントから拡張は顧客を取得し、法人のバイヤーならpurchasingCompanyも取得します。それ以外では値はundefinedで、これが「そもそも会社のバイヤーか」の判定です。

できないこと。 ゲストに描画すること。Shopifyのトークンの外で見た目を作ること。大きなクライアントを持つこと。アカウントページのDOMを読むこと。従来アカウントの上に存在すること。どれも、マトリクスにホスト型の列が残る理由です。

ゲストの見積と会社の外のバイヤー

拡張から見えないバイヤーが二種類あり、ポータルの計画はその行き先を決めておく必要があります。

一つ目はゲストです。ログインせずに商品ページから見積を依頼するバイヤーです。Shopifyにはその依頼を表すオブジェクトも、それを表示するアカウントページもありません。そのバイヤーを会社にするネイティブな入口は会社アカウント申請です。Shopify Formsのフォーム（インラインまたはポップアップ）で、送信すると管理画面に会社、会社所在地、顧客が「自動的に作成され」、マーチャントが承認するまで「注文未承認」に置かれます。承認までは「オンラインストアで注文できず、B2B価格にもアクセスできません」。アカウントが欲しいバイヤーにはこれが正しい道です。金曜日までに価格が欲しいバイヤーに強いるには間違った道で、だからこそ見積レイヤーにはメールアドレスだけで動く面が必要です。

二つ目は、ログインはしているが会社所在地に紐づいていないバイヤーです。Shopifyのヘルプは率直です。そのような顧客はログインしていても一般消費者として扱われます。purchasingCompanyはundefinedで、カタログは適用されず、B2Bのプロフィールブロックは描画されません。拡張はそのバイヤーの見積を顧客IDで一覧化できますが、管理者が所在地に紐づけるまで、会社の価格も支払条件も存在しません。

QuotWayの両者への答えを、一つの実装として示します。ゲストへの提案は、既定で7日間有効なマジックリンクでホスト型ポータルへ届き、同じ受信箱へ送られる1時間で失効するワンタイムコードで保護されます。後からアカウントを持ったゲストは、ワンタイムパスコードで見積をアカウントに取り込めます。提案を知らせるメールは、ストアが現行の顧客アカウントを使い、かつバイヤーがログイン済みの顧客である場合にだけアカウントページにリンクし、それ以外はポータルにリンクします。二つの面は同じ操作、つまり承諾、カウンター、辞退、メッセージ、バイヤー側の承認を、すべてのプランで備えています。

ヘッドレスが変えるのはログインであって、モデルではない

Hydrogenや独自のストアフロントでは、バイヤーはCustomer Account APIで認証し、B2Bの文脈はストアフロントが明示的に運ぶものになります。顧客の会社担当者情報を照会して購入できる所在地を見つけ、複数あれば選択肢を出し、顧客アクセストークンとともにcompanyLocationIdをStorefront APIクエリの@inContext(buyer: …)に渡します。これでその所在地のコンテキスト価格、数量ルール、数量別価格が返ります。そしてcartCreateまたはcartBuyerIdentityUpdateで、カートのbuyerIdentityとして渡します。Shopify自身のページにある注意点が二つ。既存のカートのバイヤーアイデンティティを変更すると、そのバイヤーに公開されていない商品が削除されることがあります。そしてCustomer Accountのアクセストークンは「カートのバイヤーアイデンティティの更新にしか使えず」、Storefront APIで顧客を照会するには使えません。

ポータルにとってこれは、アカウント拡張の列が消えることを意味します。拡張すべきShopify描画のアカウントがないからです。見積のUIは自分のものになり、拡張が使うのと同じバックエンド契約と、同じ身元確認を使います。バイヤーが選んだ所在地が見積の対象の所在地であり、開始価格はバイヤーコンテキストが返す価格です。

バイヤーは下書き注文を見られるか

変換された見積はバイヤーが支払うまで下書き注文なので、この問いはあらゆる範囲決めの場で出ます。標準のアカウントは注文を表示します。下書き注文はShopifyが送る請求書リンクとしてバイヤーに届き、支払条件付きの注文になれば「今すぐ支払う」と期日付きで表示されます。その下で、Customer Account APIはcustomer.draftOrdersを公開しています。それぞれにstatus、「請求書メールで顧客に送られる」invoiceUrl、purchasingEntity、deposit、明細があり、拡張のページやヘッドレスのストアフロントはバイヤーの未処理の下書きを見積の隣に一覧化し、チェックアウトへ直接リンクできます。Shopify自身のアカウントUIが下書きをセクションとして一覧表示するかどうかは、ヘルプページには書かれていません。一覧が必要な構築は、標準ページにあると仮定せず、APIから描画する計画にすべきです。

面を決める

もし	ならば
バイヤーが、すでにアカウントで請求書を支払っている会社の担当者である	見積はアカウントの中に置く。メニューにフルページ拡張、注文一覧にそこへ導くブロック
アカウントを持つ前、または会社が承認される前に見積を依頼するバイヤーがいる	メールで到達するホスト型の面と、アカウントができた後の取り込みステップ
ストアが現行の顧客アカウントに移行していない	ホスト型の面が唯一の面。移行はShopifyの設定であってプロジェクトではない
ストアフロントがヘッドレスである	ログインにCustomer Account API、すべてのクエリとカートにcompanyLocationId、同じバックエンドの上に自前の見積UI
ポータルがShopifyではなくブランドのように見える必要がある	ホスト型かヘッドレスの面。拡張はアカウントのテーマを継承する
状態を持つリッチなバイヤーUIが求められる	拡張の外に置く（64 / 128 KB、Shopifyコンポーネントのみ）。拡張は入口、バックエンドが状態
バイヤーが会社アカウントをセルフサービスで作るべきである	Shopify Formsの会社アカウント申請。承認ステップをオンボーディングに織り込む

失敗パターン

失敗パターン	何が起きるか	設計
計画に従来アカウントの分岐がある	B2Bが使えず、Shopifyが終了させる面に工数を使う	分岐を削除する。「現行アカウントなし」は「ホスト型の面のみ」として扱う
ゲストを「まず登録」として計画する	登録の壁で依頼が失われる	メールアドレスで動く面。取り込みは後から
ログイン済みだが未紐づけのバイヤーをB2Bとして扱う	purchasingCompanyはundefined、カタログ価格は適用されず、支払条件は存在しない	purchasingCompanyを確認して振り分ける。所在地への紐づけをオンボーディングの作業にする
フルページとブロックを一つの拡張に入れる	プラットフォームの規則で拒否される	兄弟の拡張とエディター拡張コレクション
拡張にリッチなクライアントを入れる	64 / 128 KBの上限を超えるか、コンポーネントセットと格闘する	薄いクライアント。状態はバックエンドに
バックエンドが送信元を信用する	誰でもエンドポイントを呼べる。Shopifyはリクエストがどこからでも来ると言っている	呼び出しごとにセッショントークンを検証する。CORS *は必須なので、認可はトークンであって送信元ではない
複数所在地のバイヤーが誤った所在地で見積を依頼する	バイヤーがチェックアウトしないカタログに対して提案が値付けされる	依頼時にアカウント（またはヘッドレスのセレクター）から選択中の所在地を取り、見積に載せる
マジックリンクのメールが迷惑メールに入る	ゲストがポータルに届かない	送信ドメインにSPFとDKIM。ポータル自身からコードを再送
二つ目のドメインのポータルにバイヤーが戸惑う	信頼が下がり、サポートに「これは御社のものですか」と問い合わせが来る	ポータルにストアのロゴと色。価格を示さず名前だけのメール

QuotWayはどうしているか

上の制約を実際に作られたものに照らして確認できるよう、一つの実装として示します。QuotWayは三つの顧客アカウント拡張を提供しています。customer-account.page.render上のフルページ「マイ見積」、注文一覧上でストア固有の/account/pages/…ルートへディープリンクする「見積を見る」ブロック（スラッグはapi_accessでアプリ所有のメタオブジェクトから読みます）、そしてマーチャントが両方を一度に追加できるエディター拡張コレクションです。この分割は上のプラットフォーム規則によるもので、好みではありません。ページはnetwork_accessの下で、Authorizationヘッダーにセッショントークンを付けてアプリのバックエンドを呼びます。その中でログイン済みのバイヤーは、見積の一覧、提案の閲覧、承諾、カウンター、辞退、メッセージ、バイヤー側の承認ステップの処理、ゲスト見積の取り込み、クイックオーダーを行えます。ゲスト、現行アカウントのないストアのバイヤー、振り分け規則から外れる全員は、同じ操作を備えたホスト型ポータルをマジックリンクで、すべてのプランで利用できます。マーチャント向けの説明はバイヤーポータルの機能ページとゲスト見積とアカウントへの取り込みのドキュメントに、プランは料金ページに、アカウント・所在地・ログインのローンチテストは50項目のローンチテスト計画にあります。

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

よくある質問

Shopify B2Bは従来の顧客アカウントで動きますか？

いいえ。一度も動いたことがありません。ShopifyのB2Bドキュメントは、従来の顧客アカウントはB2Bの顧客と注文には使えないと述べています。従来アカウントは2026年2月26日付で非推奨で、終了日は2026年後半に発表されます。B2Bの構築は現行の顧客アカウントを対象にし、まだ従来アカウントのストアは、B2Bを使う前に設定で切り替えます。

B2Bバイヤーはパスワードでログインできますか？

Shopifyの顧客アカウントではできません。バイヤーは会社所在地のメールアドレスと、そこに送られるワンタイムコードでログインします。パスワードはありません。自前のIDプロバイダーを持つストアはOAuth 2.0またはOpenID Connectで接続でき、セッションは最長365日続きます。

アプリはShopifyの顧客アカウントにページを追加できますか？

できます。フルページのターゲットを持つ顧客アカウントUI拡張は、マーチャントがアカウントのメニューに加えるページを作り、他のターゲットは注文、注文ステータス、プロフィールの各ページにブロックを加えます。拡張はサンドボックスで動き、Shopifyのコンポーネントを描画し、64 KB（フルページは128 KB）が上限で、セッショントークンでアプリのバックエンドに届きます。フルページは他のターゲットと同じ拡張を共有できません。

バイヤーはShopifyのアカウントなしで見積を依頼できますか？

Shopifyには依頼のオブジェクトがないので、これは完全に見積レイヤーの仕事です。ゲストには、メールで到達するホスト型のページ、つまりマジックリンクとワンタイムコードで対応でき、後から見積をアカウントに紐づけられます。ゲストを会社のバイヤーにするネイティブな方法は会社アカウント申請フォームで、会社、所在地、顧客を作成してマーチャントが承認します。

バイヤーはアカウントで下書き注文を見られますか？

請求書リンク経由と、API経由で見られます。Customer Account APIは顧客の下書き注文を、状態、請求書URL、購入主体、デポジット、明細とともに公開しているので、拡張やヘッドレスのストアフロントで一覧化できます。支払条件付きの注文はアカウントに「今すぐ支払う」ボタンと期日付きで表示されます。

B2BバイヤーポータルにはShopify Plusが必要ですか？

不要です。B2BはShopifyの全プランで使え、現行の顧客アカウントも全プランにあり、顧客アカウントUI拡張はそれを持つどのストアでも動きます。Plusが加えるのはデポジット、有効カタログ数の無制限、カタログの直接割り当てで、ポータルそのものはどれにも依存しません。

出典

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

• B2Bのログインと顧客アカウントおよびB2Bの支払条件の設定
• 会社アカウント申請および会社の担当者と権限
• 顧客アカウントの設定と管理
• 顧客アカウントUI拡張、そのターゲットと機能、Authenticated Account APIとSession Token API
• Customer Account API：CustomerおよびDraftOrder
• ヘッドレスのB2BおよびHydrogenでのCustomer Account API
• 従来アカウントの非推奨とSpring '26のID関連の追加：Shopify B2Bリファレンス、2026年9月20日確認

QuotWayの拡張、振り分け、ポータルの挙動はソースコード（拡張の設定、拡張のAPIクライアント、バイヤーリンクのリゾルバー）と上にリンクしたドキュメントから記述しています。