Shopify B2Bの会員申請・承認を新しいお客様アカウントで作り直す｜必要書類・担当者追加・ログイン後導線の再設計台帳

新しいお客様アカウントへの移行で確認すべきなのは、ログインできるかだけではありません。B2Bでは、取引を開始するまでに「申請を受ける」「取引条件を審査する」「必要書類を回収する」「会社・拠点・担当者を紐付ける」「初回発注へ案内する」という複数の工程があります。

旧来のLiquidベースの会員ページに申請フォーム、マイページ、担当者向けメニュー、独自の遷移処理を集約していた場合、新しいお客様アカウントへの切り替えを機に、その責務を分けて設計し直します。本記事では、画面を以前の見た目に近づけることではなく、誰が何を確認し、どの記録を正とするかを決める方法を扱います。

Shopifyの公式開発ドキュメントでは、新しいお客様アカウント向けのCustomer Account UI Extensionにより、プロフィール、注文一覧、注文詳細などを拡張できると案内されています。B2Bのプロフィール画面には、会社情報、拠点住所、支払方法、スタッフ管理に関連する拡張ポイントがあります。一方で、これらの拡張ポイントがあることは、審査ワークフロー、書類保管、社内の承認権限までを標準で代替することを意味しません。用途ごとに担当レイヤーを決める必要があります。

まず取引開始フローを画面ではなく状態で分解する

会員申請・承認フローは、画面の一覧ではなく状態遷移として棚卸しします。最低限、次の状態を自社の運用に合わせて定義してください。

1. 申請前：取引条件、申請に必要な情報、問い合わせ先を確認する段階
2. 申請受付：申請者と会社情報を受け取り、受付番号または案件IDを発行した段階
3. 確認待ち：営業・CS・経理などが取引可否、請求条件、提出物を確認する段階
4. 差戻し：不足情報や書類の再提出を依頼している段階
5. 承認済み・発注準備：会社、拠点、担当者、利用条件を設定し、発注可能な状態にする段階
6. 発注中：注文、請求、配送先変更、担当者変更などを通常運用する段階
7. 停止・再確認：取引停止、条件変更、担当者退職などにより再確認が必要な段階

このとき、「顧客アカウントが存在する」と「取引を承認した」を同じ状態として扱わないことが重要です。申請の連絡先としてアカウントが存在しても、会社・拠点への紐付け、取引条件の設定、必要書類の確認が終わるまで注文を受けない設計はありえます。反対に、既存取引先への担当者追加では、会社自体の審査を再度行わず、追加担当者の本人確認や権限確認だけを行うケースもあります。

状態ごとに、次の4点を決めます。

• 状態を変更できる担当部署・担当者
• 顧客に見せる文言と次の行動
• Shopify、外部フォーム、社内台帳のどこに記録するか
• 変更後に送る案内と、発注可否の判定者

たとえば「必要書類の確認待ち」であれば、顧客には提出方法と不足項目を案内し、社内では書類受領日時・確認者・判定を台帳に残します。書類そのものをどこに保存するか、誰が閲覧できるかは、Customer Account UI Extensionの表示可否とは別に決めるべき事項です。

標準画面・拡張・外部ワークフローを混同しない

新しいお客様アカウントの設計では、機能を次の3層に分けます。分ける目的は、すべてをShopify内に集約することではなく、変更時の責任範囲を明確にすることです。

Shopify Developerの資料では、Customer Account UI Extensionは新しいお客様アカウントを対象とし、既存画面の拡張に加えてフルページの追加もできるとされています。B2Bプロフィール向けには、会社情報、拠点住所、支払方法、スタッフ管理の周辺で利用できるターゲットが案内されています。

ここで有効なのは、プロフィール画面に「審査中」「書類の追加提出が必要」「担当者追加を申請する」といった案内を置き、顧客の次の行動を一つに絞ることです。ただし、案内を表示する拡張と、申請内容を受け付けて承認履歴を保管する仕組みは別物です。Extensionから外部の申請ページや問い合わせ窓口へ遷移させる場合も、どのIDで申請と顧客・会社・拠点を照合するかを事前に定めます。

「表示」と「更新」と「承認」を別の要件にする

要件定義では、各項目に対して次の3つを個別に記載します。

• 表示：顧客に現在の状態や登録内容を見せるか
• 更新依頼：顧客が変更を申し出られるか
• 確定・承認：誰が最終的に情報を反映し、取引可否を決めるか

たとえば配送先住所では、「既存住所を表示する」「新住所を申請させる」「審査後に拠点情報へ反映する」は別々の処理です。顧客による即時変更を許容するのか、社内確認を必須にするのかは、商材、与信、配送、請求の条件に応じて判断します。

会員申請と必要書類は、受付IDを軸に設計する

申請フォームをShopifyのログイン前に置くか、ログイン後に置くかは、申請者の属性と照合方法で決めます。未取引の事業者が申請する導線なら、ログイン前に公開する申請ページまたは外部フォームが必要になる場合があります。既存取引先の担当者追加や拠点変更なら、ログイン後のプロフィール画面から申請させるほうが、対象会社を特定しやすくなります。

どちらの場合でも、申請ごとに受付IDを付け、以下を同じ台帳行または連携レコードで結びます。

• 申請者の氏名、メールアドレス、連絡先
• 法人名、部署、所在地など、自社が審査に使う会社情報
• 対象となる会社・拠点・担当者の識別子
• 申請種別（新規取引、担当者追加、担当者削除、拠点変更、書類更新など）
• 提出を求める書類の種類、受領日時、確認状態
• 審査担当、承認者、判定日時、差戻し理由
• Shopify側の設定実施者と実施日時
• 顧客へ送った案内の種類と送信日時

必要書類については、ファイルアップロードの利便性だけで保管先を決めないでください。書類に含まれる情報、社内の閲覧者、保存期間、削除手順、再提出時の版管理を確認します。顧客プロフィールに「提出済み」と表示する場合も、ファイルそのものを表示するのか、書類名と確認状態だけを表示するのかを分けて検討します。

書類未提出の状態でログインを認める場合は、注文や価格表示をどこまで許可するかも明記します。「閲覧のみ」「カート追加は可能だが注文は不可」「特定拠点への発注のみ可」といった判定があるなら、顧客案内、CSの回答、テストケースで同じ言葉を使います。実現方法はストアの設定、導入アプリ、独自実装によって異なるため、要件だけで実装可能と判断せず、対象環境で検証してください。

担当者追加・削除は、会社の承認と分けて扱う

B2Bの担当者運用では、法人取引の承認と、個人の利用権限の付与を区別します。会社が取引可能であっても、申請者がその会社を代表して発注できるとは限りません。このため、担当者追加の申請には、少なくとも次の確認項目を用意します。

• 追加先の会社・拠点
• 追加する担当者の氏名とメールアドレス
• 依頼者が既存担当者か、社内の誰が依頼を確認したか
• 担当者に許可する操作と、対象拠点の範囲
• 有効開始日・終了日が必要か
• 退職・異動・誤登録時の削除または利用停止の手順

ShopifyのB2Bプロフィール向けExtensionにはスタッフ管理に関する拡張ポイントが案内されています。これは、ログイン後の導線として担当者管理の案内や申請機能を検討できる根拠になります。ただし、自社のストアで顧客がどのスタッフ情報を閲覧・変更できるか、また誰が承認するかは、利用する機能、権限設定、実装によって確認が必要です。

担当者自身が追加を実行できる設計にする前に、「追加者が誤って別会社・別拠点の担当者を招待できないか」「退職者が残った場合に誰が検知するか」「CSが依頼を受けた際に正しい会社を特定できるか」を受入テストに入れます。即時反映を採る場合でも、操作履歴、通知先、取り消し手順を台帳に残せるようにします。

ログイン後導線は、戻り先より次の業務を優先する

新しいお客様アカウントへの移行では、従来テーマのログイン後リダイレクト処理を前提にしていた導線を、そのまま再現できるとは限りません。コミュニティ上には、新しいお客様アカウント移行時の互換性や、B2B利用時のログイン後遷移についての個別相談があります。これらは仕様の一般化や実装可否の根拠ではありませんが、自社の導線を画面単位で検証する必要を示す材料にはなります。

設計時は「ログイン後にどのURLへ遷移するか」だけでなく、状態別に最初に見せるべき情報を決めます。

プロフィール画面へのExtensionやフルページ追加を用いる場合、ここで定義した「状態」と「次の行動」を表示する候補になります。一方、ログイン画面そのものへの独自要素の追加可否と、ログイン後画面の拡張可否は同一ではありません。ログイン前の申請案内は、ログインページ内への追加を前提にせず、ストアの公開ページ、ヘルプページ、営業案内メールなども含めて設計してください。

CS・営業・開発で行う受入テスト

本番切り替え前には、管理者アカウントだけで確認せず、役割と状態を変えたテストを実施します。テスト結果は、成功・失敗だけでなく、想定と異なる場合の一次対応者まで台帳に残します。

申請・審査のテスト

• ログイン前の申請者が、必要事項と問い合わせ先を確認できる
• 申請受付後、顧客と社内で同じ受付IDを参照できる
• 不足書類がある場合、顧客に不足内容を案内できる
• 差戻し、再提出、承認、否認の各状態で、社内の担当者が判定履歴を確認できる
• 承認前に発注させない条件がある場合、その条件どおりの画面・操作になる

会社・拠点・担当者のテスト

• 対象会社・対象拠点と申請内容が正しく照合される
• 担当者追加、変更、削除の依頼が、意図しない会社・拠点へ紐付かない
• 担当者が見られる情報と実行できる操作が、設計した権限範囲に収まる
• CSが問い合わせから、対象の会社・拠点・申請IDを特定できる
• 担当者の利用停止後、ログイン・注文・変更依頼の挙動が想定どおりである

導線と障害時対応のテスト

• 申請中、承認済み、停止中の各顧客が、ログイン後に必要な案内へ到達できる
• Extensionまたは外部フォームが利用できない場合、代替の問い合わせ先が案内される
• 顧客への案内文、CSの返信テンプレート、営業の説明資料で状態名が一致している
• 旧会員ページへのリンク、旧フォーム、旧メールテンプレートが残っていない

B2B会員再設計台帳のひな型

最後に、移行プロジェクトで共有する台帳の列を示します。スプレッドシート、チケット管理ツール、業務システムのいずれで管理しても構いませんが、顧客対応の記録と設定変更の記録が分断しないようにします。

台帳は、すべての情報をShopifyへ複製するためのものではありません。むしろ、どの情報がShopify上の取引設定に必要で、どの情報が審査・書類保管・社内連絡として別管理されるかを明確にするためのものです。新しいお客様アカウントの画面拡張を検討する前にこの台帳を作ると、開発要件を「画面に何を出すか」ではなく、「顧客の状態をどう判定し、誰が更新責任を持つか」として渡せます。

参考情報

• Shopify Developer: Building apps for customer accounts
• Shopify Developer: Profile page (B2B)
• Shopify Community: For those who have migrated to Shopify’s New Customer Accounts, what compatibility issues did you encounter?
• Reddit r/shopify: Shopify Plus redirect to home page after login
• Shopify Developer Community: Customizing New Customer Accounts Login Page: Redirect link using UI Extensions