Shopify「新しいお客様アカウント」へ移行する前の監査手順｜Liquid・アプリ・ログイン導線・CS案内を切り替え前に確認する

従来のお客様アカウントから新しいお客様アカウントへの切り替えは、管理画面で設定を変えるだけの作業ではありません。アカウントページをテーマのLiquidで拡張しているか、アプリがどこに画面を表示しているか、顧客向け・CS向けの案内がどの認証方式を前提としているかで、影響範囲が変わります。

新しいお客様アカウントは、メールに届く6桁の認証コードを使うパスワードレス方式です。従来のお客様アカウントにあったパスワード入力、パスワード再設定、/account テンプレートへのLiquid追加を前提に、画面や運用を組み立てている場合は、切り替え前に代替可否を判断しなければなりません。仕様確認日：2026年9月10日。

この記事では、移行を急ぐための手順ではなく、「いま提供している会員向け体験を何として残すか」を確定する監査手順を扱います。互換性が確認できない機能を抱えたまま切り替えず、機能ごとに継続・代替・廃止・見送りを決められる状態を目指します。

まず把握する：切り替えで変わる対象と、変わらない対象

最初に、変更対象をアカウント画面だけに限定しないことが重要です。従来のお客様アカウントでは、テーマ内の顧客用テンプレートを起点に、Liquid、アプリのUI、リンク、メールやFAQがつながっていることがあります。

新しいお客様アカウントでは、ログイン時に登録済みメールアドレスへ6桁の認証コードが送られます。そのため、以下は「画面上の文言を差し替えれば済む」と決めず、実際の利用経路を確認します。

• パスワード入力、会員登録、パスワード再設定へのリンク
• ヘッダー、フッター、LP、メール、広告遷移先に置いたログインURL
• アカウント画面内に表示する注文履歴、ポイント、定期購入、返品受付、会員ランクなど
• 会員限定ページと、そのページへのリダイレクト処理
• CSのマクロ、ヘルプセンター、受注メールにあるログイン案内
• 顧客セグメント、既存のワークフロー、自動化
• 外部サービスへのSSO。特にMultipassを使う構成

Multipassは新しいお客様アカウントではサポートされません。PlusストアなどでMultipassを利用している場合、これは単なる互換性テストではなく、認証連携の方式を再設計する論点です。先に対象機能、外部システム、契約上の要件を整理し、代替案が成立するまで移行日を確定しないほうが安全です。

監査の起点は「会員ができること」の一覧にする

テーマファイルやアプリ一覧から調べ始めると、購入者への影響を見落としやすくなります。まず、現在のアカウントで購入者が実行できる行為を列挙し、その後で実装箇所をひも付けます。

監査台帳の項目

スプレッドシートなどに、次の列を用意します。担当者だけでなく、確認した画面・URL・テスト結果を残すことが、切り替え可否を再確認するときに役立ちます。

この台帳では、「未確認」を可否判定に含めないことがポイントです。未確認のまま移行することは、実質的に「当該機能がなくても許容する」という判断になり得ます。売上や問い合わせに与える影響を予測で大きく見せる必要はありませんが、少なくとも機能の所有者が判断できる状態にします。

調査対象を洗い出す順序

1. 購入者が使う機能を、注文前・注文後・継続購入・問い合わせの流れに沿って書き出す
2. 管理画面のアプリ一覧から、会員機能に関係しそうなアプリを候補化する
3. テーマの顧客向けテンプレート、スニペット、カスタムJavaScript、メニューを確認する
4. サイト内検索とヘルプセンター検索で、「ログイン」「パスワード」「マイページ」「会員登録」を検索する
5. CRMメール、フローの通知、CSマクロ、社内手順書も同じ語句で検索する
6. 機能ごとに提供元へ新しいお客様アカウント対応を確認し、回答日と参照URLを台帳へ記録する

特に、担当者の記憶だけに依存しないでください。以前の制作会社やアプリ提供元が追加したリンク、条件分岐、埋め込みコードが残っている場合があります。

Liquidとアプリは「表示できるか」ではなく操作完了まで確認する

従来のお客様アカウントの顧客用Liquidページに依存するアプリは、新しいお客様アカウントを利用するストアでは動作しないと、Shopify Developer Communityで案内されています。これは、旧来の/accountテンプレートへコードを追加して画面を作る前提を、そのまま持ち込めないことを意味します。

ただし、アプリ名だけで非対応と結論付けることも避けます。アプリ提供元が新しいお客様アカウント向けの対応や、アプリブロックなどの代替表示方法を提供している可能性があるためです。確認はアプリごと、さらに購入者の操作ごとに行います。

テーマ側で確認する項目

テーマコードを編集できる担当者は、顧客関連のテンプレート、セクション、スニペット、JavaScriptを確認します。確認対象には、次を含めます。

• customers/account、ログイン、登録、パスワード再設定に関連するテンプレートやコード
• 顧客タグ、ログイン状態、顧客情報を条件にしたLiquidの表示分岐
• account、login、register、recover を含むリンクやリダイレクト
• 会員限定ページのアクセス制御、ログイン後の戻り先指定
• アプリが自動挿入したスニペット、埋め込みスクリプト、アプリブロック

削除作業は、移行前に急いで行う必要はありません。まずは「新しいお客様アカウントで使われない旧コード」と「通常のストア表示にも影響するコード」を分けます。テーマの複製を作成し、プレビュー環境で検証してから変更を反映します。

アプリ提供元に確認する質問

アプリのヘルプページに「対応」と書かれていても、自社で使う機能が対象かは別です。問い合わせる場合は、次のように具体化します。

• 新しいお客様アカウントで、アカウント内のどの画面・操作に対応しているか
• 従来の顧客アカウントLiquidやテーマ埋め込みへの依存があるか
• 切り替え前後に必要な設定変更、再インストール、データ移行があるか
• 注文履歴、契約変更、ポイント利用、返品申請など、自社が使う操作を完了できるか
• テストストアまたはテーマプレビューで検証する方法はあるか
• 非対応の場合の代替機能と制約は何か

回答は「対応しています」だけで完了にせず、対象画面、必要な設定、確認したバージョンや回答日を残します。アプリ変更が必要なら、データ移行、契約、デザイン調整、CS教育も移行コストとして比較します。

ログインURLとCS案内を、認証コード方式に合わせて作り直す

新しいお客様アカウントへの移行では、購入者が最初に迷う場所がログイン導線になりやすいため、サイトとCSの文言を同時に監査します。旧方式の「パスワードを忘れた場合」「会員登録後にパスワードを設定」といった案内は、認証コード方式と整合しません。

Shopifyの開発者ドキュメントでは、お客様のサインインリンクとリダイレクトに関する実装情報が提供されています。独自のログインボタン、固定URL、ログイン後の遷移制御がある場合は、見た目だけではなく、実際に目的ページへ戻れるかまで確認します。

書き換え対象の例

• ヘッダー、フッター、マイページ案内バナーのログインリンク
• 商品詳細、カート、チェックアウト前後に置く会員向け案内
• 注文確認・発送通知・休眠顧客向けメールのログイン文言
• FAQのログイン、会員登録、パスワード再設定に関する記事
• チャットボットの回答、有人CSの定型文、電話対応スクリプト
• 社内の受注確認、返品対応、本人確認の手順書

CSには、認証コードが届かない場合の切り分けも用意します。ただし、メール未着の原因や対応を一般論で断定せず、Shopifyの現行ヘルプ、ストア側のメール設定、顧客が入力したメールアドレスを確認する手順として整備します。本人確認を要する注文変更や個人情報照会は、ログイン可否とは別に、社内の本人確認ルールに従います。

また、ログインページへ送るURLをメールや広告で固定している場合、リンク切れだけでなく、ログイン後の遷移先もテストします。会員限定コンテンツ、定期購入管理、返品画面など、リンク元ごとに意図したページへ到達できることを確認してください。

顧客セグメント・自動化は複製して、条件と結果を比較する

Shopify公式のアップグレードガイドでは、顧客セグメント、既存のワークフローや自動化も制限事項として確認するよう案内されています。これらはアカウント画面に表示されないため、テーマ監査だけでは漏れます。

移行前には、既存の設定を一覧化してから複製し、移行後に同じ条件で意図した結果になるか確認します。いきなり本番の自動化を編集するより、比較対象を残したほうが差分を追いやすくなります。

確認対象は次のとおりです。

• 顧客セグメントの条件、対象顧客数、利用先
• Shopify Flowを含むワークフローのトリガー、条件、アクション
• 顧客タグの付与・削除、メール配信対象、外部CRMへの連携
• ログインやアカウント状態を前提にしたカスタム処理
• アプリ経由で動く自動化と、そのアプリ側の新アカウント対応状況

テストでは、既存顧客と新規顧客を分け、可能なら異なる状態のテスト顧客を用意します。たとえば注文履歴のある顧客、対象セグメントに入る顧客、会員限定機能の対象顧客です。実顧客のメールアドレスをテストに使わず、テスト用に管理できるメールアドレスを用意すると、CSへの誤案内や通知混入を避けやすくなります。

切り替え前テストと、30日以内の戻し判断を運用に組み込む

Shopify公式のアップグレードガイドでは、設定の複製、アプリブロックへの置換、プレビューとテストを行い、移行後30日以内は復元できる手順が案内されています。仕様確認日：2026年9月10日。復元可能だからといって監査を省けるわけではありませんが、移行計画には戻し判断の期限として明記できます。

最低限の受け入れテスト

台帳に載せた各機能について、少なくとも以下を確認します。

1. ログアウト状態からログインリンクを押し、認証コードを受信してログインできる
2. 主要なリンク元ごとに、ログイン後の遷移先が意図どおりである
3. 注文履歴と注文詳細を閲覧できる
4. 会員向けアプリの画面が表示されるだけでなく、主要操作を完了できる
5. 会員限定ページのアクセス制御と案内文が整合している
6. CSマクロ・FAQの手順を使い、テスト担当者が迷わず案内できる
7. 関係するセグメント・自動化が意図しない対象へ実行されない

テスト結果は「OK」だけで終えず、操作したアカウント、URL、日時、結果、証跡の保存先を記録します。不具合が出た場合は、重要度を「購入完了に関わる」「注文後セルフサービスに関わる」「案内修正で回避できる」など、自社の運用基準で分類します。

切り替え判断の基準を先に決める

移行可否を会議で曖昧にしないために、切り替え前に基準を合意します。たとえば、以下の状態なら見送りまたは延期を検討する、という条件です。

• 代替のない会員向け機能があり、事業側が廃止を承認していない
• 主要アプリの対応可否または設定方法を確認できていない
• CSが認証コード方式と問い合わせ時の案内を検証していない
• SSOやMultipassに関する代替設計が未決定である
• 戻す判断をする責任者、判断期限、連絡手順が定まっていない

反対に、すべての機能を残せることだけを成功条件にすると、不要な独自実装やアプリ変更を選びやすくなります。利用実態、運用負荷、契約コストを踏まえ、機能を廃止する判断も台帳に残します。その際は、購入者への告知要否、代替の問い合わせ窓口、CSの対応期限まで決めておきます。

新しいお客様アカウントへの移行は、認証方式の変更をきっかけに、会員機能と運用を整理する作業でもあります。テーマ、アプリ、導線、CS、自動化を一つの監査台帳で扱えば、「どこまで確認したか」と「未解決のまま残る影響」を分けて判断できます。設定変更の前にこの状態を作ることが、切り替え後の修正を減らす現実的な準備になります。

参考情報

• 従来のお客様アカウントからお客様アカウントへのアップグレード（Shopify ヘルプセンター）
• Customer accounts（Shopify Help Center）
• Customer sign-in links and redirects（Shopify Dev）
• Legacy customer accounts: Availability update（Shopify Developer Community）
• For those who have migrated to Shopify’s New Customer Accounts, what compatibility issues did you encounter?（Shopify Community）