【2026年】Shopify新しいお客様アカウントへの移行ガイドと日本ストアへの影響

【2026年】Shopify新しいお客様アカウントへの移行ガイドと日本ストアへの影響

1. はじめに

2026年2月26日、ShopifyはChangelogで「従来のお客様アカウント(Legacy customer accounts)」の非推奨化を正式に発表しました。最終廃止日は2026年後半に別途アナウンスされる予定で、現時点(2026年4月18日)ではまだ猶予期間の最中ですが、機能アップデートと技術サポートはすでに停止しています。つまり、今お使いの環境は「動いてはいるが、今後は改善も修正もされない」状態に入っています。

今回の変更は全世界共通のShopifyプラットフォーム変更ですが、日本のストアに対しては固有の影響が特に大きい内容になっています。LINEログインの事実上の利用停止、会員登録時の属性取得の導線変更、ログインドメインのブランディング影響など、グローバル向けの解説記事ではほとんど触れられない論点が複数存在します。

本記事では、Shopify公式の一次情報をベースに、次の内容を順に解説します。

  • 2026年2月26日の発表内容と、従来アカウントの現在地
  • 従来と新しいお客様アカウントの違い(比較表)
  • メリット・デメリットと、日本のストアで特に影響が大きい4つの論点
  • 移行前チェックリストと、具体的な移行手順
  • 単純な切り替えで終わらせないための、戦略的な移行の視点

対象読者はShopifyストアを運営するマーチャントの方です。

なお、Shopify公式の正式名称は「お客様アカウント」(「新しい」という修飾は付きません)ですが、本記事では従来バージョンとの区別を明確にするため、読者の分かりやすさを優先して「新しいお客様アカウント」という表記を使用します。

2. 何が起きたか:2026年2月26日の発表

2026年2月26日、Shopifyは開発者向けの公式アナウンス「Shopify Changelog」で、従来のお客様アカウント(Legacy customer accounts)の非推奨化を発表しました。発表タイトルは「Legacy customer accounts are deprecated」です。

重要なのは、この発表が「将来こうなります」という予告ではなく、発表と同時にすでに段階的な利用制限が始まっている点です。自ストアがどの状態にあるかによって、取れる選択肢が変わります。

ストアの状態別の現在地

ストアの状態は、以下の3つに分類されます。

  • 新規ストア:従来のお客様アカウントは最初から選択できません。新しいお客様アカウントが標準です。
  • 既存ストアで従来のお客様アカウントを使用していない:従来バージョンへの切り替えはできません。こちらもすでに新しいお客様アカウントが標準です。
  • 既存ストアで従来のお客様アカウントを使用中:当面は引き続き利用可能です。ただし、機能アップデートと技術サポートはすでに停止しています。不具合が出ても修正されず、新機能も追加されません。

つまり、現時点で従来のお客様アカウントを「新たに選ぶ」ことはどのストアでもできず、「使い続けている」ストアだけが時限的な猶予期間の中にいる状態です。

最終廃止日(Sunset)について

最終廃止日は2026年後半に別途アナウンスされる予定で、本記事の執筆時点(2026年4月18日)ではまだ具体的な日付は確定していません。

ただし、Shopifyの公式見解は一貫しています。「早急に新しいお客様アカウントへのアップグレードを強く推奨する」というスタンスで、Changelogおよびヘルプセンターの複数ページで繰り返し表明されています。

最終廃止日が発表されてから動き出すと、後述するチェックリスト項目(LINEログインの代替検討、Liquidカスタマイズのアプリ再構築、SSO連携の移行など)に時間が足りなくなる可能性があります。本記事の第7章以降を読み、自ストアの影響範囲を今のうちに把握しておくことをおすすめします。

3. 従来と新しいお客様アカウントの違い

従来のお客様アカウントと新しいお客様アカウントの違いを、マーチャントが判断に使う観点別にまとめました。項目は、影響範囲の大きいものから順に並べています。

項目 従来のお客様アカウント 新しいお客様アカウント
認証方式 メール+パスワード メール+6桁ワンタイムコード(パスワードレス)
ログインセッション保持 任意設定 最大365日
会員登録の概念 あり(登録フォームから作成) なし(ログイン時に自動作成)
ソーシャルログイン 非対応 Google・Facebook対応(2025年8月〜)
Shopでログイン 非対応 対応
カスタマイズ方法 Liquid(テーマ編集) アプリブロック/Customer Account UI extensions
ログインページのドメイン ストア独自ドメイン Shopify側ドメイン(サブドメイン接続は可能)
セルフサービス返品 非対応 対応
ストアクレジット表示 非対応 対応
B2B対応 非対応 対応
Multipass 対応 非対応
独自IDプロバイダー(SSO) 非対応 対応(Shopify Plus限定)
従来と新しいお客様アカウントの主な違い(2026年4月18日時点)

全体を俯瞰すると、変更は大きく3つの方向性に整理できます。

  • 認証とログイン体験の刷新:パスワードからワンタイムコードへ、セッションの長期化、ソーシャルログイン・Shopでログインへの対応など、ログイン周りが全面的に置き換わります。
  • カスタマイズ手段のプラットフォーム化:テーマLiquidでの自由編集から、アプリブロックとCustomer Account UI extensionsという規格化された仕組みへ移行します。自由度は下がりますが、Shopifyのアップデートを受け続けられる利点があります。
  • 標準機能の拡充と、一部機能の切り捨て:セルフサービス返品・ストアクレジット・B2Bなど、これまでアプリで補っていた機能が標準装備になる一方、MultipassやLiquidベースの会員登録フォームは利用できなくなります。

それぞれの項目がメリットなのかデメリットなのかは、ストアの運用方針によって変わります。次章からは、この表をベースに「どこを活かすべきか」「どこに注意すべきか」を具体的に掘り下げていきます。

4. 新しいお客様アカウントのメリット

新しいお客様アカウントは、単に新しくなったというだけでなく、Shopifyが今後の機能追加・改善の主戦場と位置付けているバージョンです。マーチャント目線で見た主なメリットを整理します。

  • セキュリティ向上:メール+6桁ワンタイムコードによるパスワードレス認証のため、パスワード使い回しによる乗っ取りリスクがなくなります。なりすましの温床だった「弱いパスワード」の問題を、仕組みごと排除できます。
  • パスワード関連サポートの削減:「パスワードを忘れた」「リセットメールが届かない」といった問い合わせがなくなります。カスタマーサポートの工数削減に直結する変化です。
  • ログイン体験の改善:最大365日のセッション保持により、リピート顧客が毎回ログインし直すストレスが大幅に減ります。再訪時のログイン離脱は、CVR低下の地味だが大きな要因です。
  • 標準機能の充実:セルフサービス返品、ストアクレジット、B2B対応、Shopでログインといった機能が、追加アプリなしで利用可能になります。これまで外部アプリで実装していたストアは、アプリ費用と管理工数を削減できる可能性があります。
  • ノーコードカスタマイズ:アプリブロックを使ったカスタマイズは、テーマアップデートで壊れるリスクがなく、専門知識がなくても設定変更できます。Liquidでの自由度は失いますが、保守性は大幅に上がります。
  • Shopifyの継続的アップデート対象:今後追加される新機能は、すべて新しいお客様アカウントに実装されます。従来のお客様アカウントは機能アップデートが停止しているため、時間が経つほど両者の機能差は広がります。

特に最後の項目は、本記事全体を通して最も重要な論点です。従来のお客様アカウントに留まるという選択は、単なる「現状維持」ではなく、「今後のShopifyの進化から取り残されることを受け入れる」という選択を意味します。

5. デメリット・制約(グローバル共通)

前章でメリットを整理しましたが、新しいお客様アカウントには既存ストアが直面するデメリット・制約もあります。ここでは全世界のストアに共通する制約を扱い、日本のストアに特有の影響は次章で扱います。

  • Liquidカスタマイズは引き継がれない:テーマに加えたアプリやLiquidのカスタマイズは、新しいお客様アカウントには移行されません。マイページや登録フォームを独自にカスタマイズしているストアは、アプリブロックまたはCustomer Account UI extensionsで再構築する必要があります。
  • Shopify Flowの一部トリガーが機能停止:「お客様アカウントが有効になったとき」のような従来アカウント専用のトリガーは、新しいお客様アカウントでは動作しません。このトリガーを使ったオートメーション(初回ログイン時のクーポン配布など)を運用しているストアは、「お客様が作成されたとき」などの別トリガーで設計し直す必要があります。
  • 顧客セグメントの一部が機能停止customer_account_status フィルターを含むセグメントは動作しません。新バージョン向けの代替フィルターは、2026年4月18日時点で提供されていません。このフィルターでセグメントを切っていたストアは、別の条件での代替設計が必要です。
  • マーケットごとのカスタムドメイン非対応:複数のインターナショナルドメインを持つストアでも、お客様アカウントのドメインは全マーケット共通の1つのみです。マーケットごとにブランドを分けて運用しているストアには影響が出ます。
  • Multipass非対応:外部システムとの認証連携に使われてきたMultipassは利用できません。代替手段として、Shopify Plusであれば独自IDプロバイダー接続(SSO)で似たことが実現できますが、Plus以外のプランではMultipassに依存した連携は廃止せざるを得ません。
  • サインインページへのカスタマイズブロック追加不可:ログイン画面のUIに独自の要素を追加することはできません。ログイン前にキャンペーン告知や利用規約同意を出していたストアは、表示タイミングの再設計が必要です。
  • マイページ上のアプリ機能の再構築が必要:サブスクリプション管理、ポイント表示、独自の注文履歴UIなど、従来のマイページ上で動作していたアプリ機能は、新しいお客様アカウント対応版への切り替えが必要です。アプリ側が未対応の場合、該当機能は一時的に利用不能になります。

これらの制約は、新しいお客様アカウントが「プラットフォーム規格として統一されたカスタマーアカウント基盤」へと生まれ変わったことの裏返しでもあります。自由度が下がる代わりに、Shopifyのアップデートに乗り続けられる――そのトレードオフを受け入れるかどうかが、移行判断の論点になります。

なお、ここまでは全世界共通の制約ですが、日本のストアにはさらに固有の影響があります。次章で詳しく見ていきます。

6. 日本のストアで特に影響が大きい点

前章までは全世界共通の話題でしたが、日本のストアには海外向けの解説記事では触れられない固有の論点があります。ここでは日本のストアで特に影響が大きい4つのポイントを取り上げます。

6-1. LINEログインは事実上使えない

日本のストアにとって最大のデメリットと言えるのが、LINEログインの事実上の利用停止です。

Shopifyは2025年8月のChangelogで、新しいお客様アカウントにソーシャルサインイン機能を正式追加しましたが、対応プロバイダーはGoogleとFacebookのみです。LINEへの対応予定は、2026年4月18日時点で公式アナウンスされていません。

さらに問題なのは、代替策で回避することも難しい点です。考えられる代替策ごとに、なぜ使えないかを整理します。

  • サインインページにLINEボタンを自前で追加する:不可。第5章で触れた通り、サインインページにはカスタマイズブロックを追加できません。
  • Shopify PlusのカスタムIDプロバイダー機能(SSO)でLINEを選ぶ:用途が違います。この機能は「お客様アカウントのログインフロー全体を自社のIdPに置き換える」仕組みで、「GoogleやFacebookと並ぶ選択肢としてLINEを追加する」ものではありません。また、Plus限定の機能です。
  • LINE連携アプリで代替する:これらはログイン認証ではなく、ログイン後にShopify顧客とLINEユーザーIDを紐付けるCRM機能であり、本質的に別物です。ログイン自体をLINEで行う用途には使えません。

つまり、現状「新しいお客様アカウントでLINEログインを実現する手段」は存在しません。LINEログインによる会員獲得や、LINE経由のリピーター囲い込みをCVR設計の中心に据えていたストアは、施策の根本的な見直しが必要になります。

この論点は、日本のECにおけるLINEの位置付けの重さを考えると、影響範囲が非常に大きいものです。アパレル・コスメ・食品・サブスク型ECなどLINE会員を主要なリピートチャネルとして運用してきたストアほど、移行判断は慎重にならざるを得ません。

さらに、LINEログイン経由で獲得した顧客にはデータ消失のリスクがあります。見落としがちですが、移行前に必ず棚卸ししておくべき論点です。

LINEログインを自前実装せず、サードパーティーアプリ経由で実現している場合、顧客データの一部や認証状態はアプリ側に保持されており、Shopify本体の顧客レコードには完全に反映されていないことがあります。これが移行時にリスクとして顕在化します。

特に注意が必要なのは、Shopify顧客レコードにメールアドレスが登録されていないケースです。LINEログインではメールアドレスの取得は任意で、以下のいずれかに該当するとShopify側にメールが存在しない状態になります。

  • LINE Developers側の「Email address permission」が未申請
  • 顧客のLINEアカウントにメールアドレスが連携されていない
  • アプリが独自の識別子(LINE IDやダミー値)で顧客レコードを作成している

新しいお客様アカウントはメールアドレス+OTPが認証の絶対前提です。メールアドレスが登録されていない顧客は、移行後はOTPコードの送信先がないため認証できず、Shop/Google/Facebookログインもメールによる顧客レコードの突き合わせが必要なため、どの認証手段でもログイン不能になります。これは事実上の顧客消失であり、過去の購入履歴やLINE ID紐付けが顧客からは永久に参照できなくなる可能性があります。

このリスクを回避するため、移行前に以下の棚卸しをおすすめします。

  • 顧客レコードのメールアドレス登録率を確認する:管理画面の顧客一覧をエクスポートし、メール欄が空欄、またはダミー値(line_xxx@example.com などのパターン)の顧客の割合を確認します。
  • LINEログイン経由で獲得した顧客を特定する:顧客タグ・顧客メタフィールドから、LINEログイン経由で作成された顧客レコードを抽出できるか確認します。
  • 必ずアプリ開発元に確認する:自ストアで利用中のLINEログイン関連アプリが、新しいお客様アカウントにどのように対応するのか、アプリ側だけに保持されているデータの扱いはどうなるのかを、開発元に確認することは必須です。アプリごとにデータ保持の仕組みと移行時の挙動が異なるため、一般化した情報で判断せず、必ずベンダーの公式見解を取得してください。

棚卸しの結果、「メールアドレス未取得の顧客が一定数いる」ことが判明した場合は、移行前にメールアドレス取得キャンペーンを実施することを強くおすすめします。LINE公式アカウントから「重要な変更のお知らせ」として配信し、マイページまたは専用フォームでメール登録してもらうことで、移行後も認証可能な状態に引き上げることができます。

この作業はボリュームが大きくなりがちで、最終廃止日のアナウンス後に着手するのでは間に合わない可能性があります。現時点(2026年4月18日)では最終廃止日は未確定ですが、LINEログインを利用しているストアにとっては、メール取得キャンペーンこそが移行準備の最優先タスクになります。

上記のデータ消失リスクへの対策を前提とした上で、移行後のLINEログイン顧客の認証設計について、現実的な選択肢は概ね次の3つです。

  • LINEログイン依存を下げ、Shopログイン・Googleログインへと顧客の認証手段をシフトさせる:日本でもShop Payの利用は着実に広がっています。新規顧客には最初からShop/Googleでのログインを促し、既存のLINEログイン顧客には移行タイミングで別認証への乗り換えを案内する方針です。
  • ログイン認証とCRMを分離し、LINEは「ログイン後の顧客接点」として使い倒す:ログインはメール+OTP・Google・Shopで行い、LINE連携アプリを使ってメッセージ配信・クーポン配布・カスタマーサポートのチャネルとしてLINEを活用する方針です。多くのストアにとって現実解になります。
  • Shopify Plusに移行し、LINEをIdPとして接続する:技術的には可能ですが、Plusのコストと実装工数を考えると、LINEログインのためだけの移行はほぼ非現実的です。Plus検討の他要因と組み合わさった場合に限り、選択肢になり得ます。

いずれにせよ、LINEログインを前提にしていたストアは、「既存のLINEログイン顧客をメール取得で救済した上で、どの認証手段に誘導するか」を移行計画の最上位課題として設計する必要があります。

6-2. 会員登録時の属性取得の導線変更

日本のストアでは、会員登録時に誕生日・性別・電話番号などの属性を取得し、誕生月クーポンや属性別のセグメント配信に活用するケースが非常に多く見られます。新しいお客様アカウントでは、この導線が根本から変わります。

従来は customer/register.liquid をカスタマイズすることで、会員登録フォームに任意の入力項目を追加し、登録時に一括で属性を取得することが可能でした。新しいお客様アカウントでは、そもそも「会員登録」という概念がほぼ消滅します。顧客の体験は次のように変わります。

  1. メールアドレスを入力
  2. 6桁のワンタイムコードを受信・入力
  3. アカウントが自動作成され、そのままログイン状態に

登録フォームを挟む余地がなく、従来の「登録時一括取得」は成立しません。属性収集はログイン後のマイページで行う後追い方式に切り替える必要があります。

後追い方式への切り替えには、主に次のアプローチがあります。

  • Customer Account UI extensionsで自作する:アプリ開発の知識が必要ですが、マイページに独自の入力フォームを追加できます。
  • マイページ拡張アプリを導入する:属性取得フォームをマイページに追加できるアプリが複数存在します。開発リソースがない場合の現実的な選択肢です。各アプリの対応状況や料金、サポート範囲はアプリごとに大きく異なるため、必ずアプリ開発元に確認した上で選定してください。
  • チェックアウトで取得する:Checkout UI extensionsを使えば、購入時に追加属性を取得することもできます。ただし購入しない顧客からは取得できない点に注意が必要です。

設計上の本質的な変化は、「新規会員獲得のタイミングで全属性を揃える」前提が崩れることです。顧客属性を時間をかけて集めていく運用を前提に、マーケティング施策を組み立て直す必要があります。誕生月クーポンなどの既存施策を運用しているストアは、属性が未収集の顧客が一定割合発生することを織り込んだ設計に切り替えることになります。

6-3. 利用規約・プライバシーポリシー同意取得フローの変更

日本のストアでは、会員登録時に利用規約・プライバシーポリシーへの同意チェックボックスを設置し、同意ログを残す運用が一般化しています。新しいお客様アカウントでは、この仕組みにも影響が出ます。

従来はLiquidで会員登録フォームにチェックボックスを設置し、同意を取得できました。新しいお客様アカウントでは、サインインページにカスタマイズブロックを追加できないため、ログイン直前での同意取得という設計自体が成立しません。

代替となる同意取得のタイミングは、主に以下のいずれかになります。

  • マイページ内での初回同意取得:初回ログイン時に、マイページに同意取得用のブロックを表示し、同意が未取得の顧客からチェックを取る方式です。Customer Account UI extensionsで実装するか、同様の機能を提供するアプリを活用します。
  • チェックアウト時の同意取得:購入プロセスの中で同意を取る方式です。Checkout UI extensionsで実装可能です。購入しない顧客からは取得できないため、購入を伴う同意に絞られます。
  • ストア内の利用規約ページへの誘導:フッター等に「ログイン・購入により利用規約に同意したものとみなす」旨を明記し、包括的同意として扱う方式です。同意ログが必要な業種・用途には不十分な場合があります。

同意取得は法務上の論点を含むため、自社の利用規約・プライバシーポリシー・個人情報の取扱いとの整合を取った上で、代替フローを設計してください。特に初回ログイン時のマイページ同意取得は、導入ハードルが比較的低く、ログ保全の観点でも優位なため、第一候補として検討する価値があります。

6-4. ログインドメインがShopify側になるブランディング影響

従来のお客様アカウントでは、ログインページ・マイページは yourdomain.com/account/login のようにストア独自ドメイン配下に表示されていました。新しいお客様アカウントでは、デフォルトではShopify側のドメインに遷移します。

ストア独自ドメインでの一貫したブランド体験を重視してきた場合、顧客がログインボタンを押した瞬間にドメインが切り替わる挙動は違和感を与えます。特にラグジュアリーブランドや、独自の世界観を重視するD2Cブランドでは、影響を受けやすい変更です。

対応策としては、オンラインストアのプライマリードメインに基づくサブドメインを接続する方法が公式に用意されています。例えば yourdomain.com がプライマリードメインであれば、account.yourdomain.com のようなサブドメインをお客様アカウントに紐付けることで、顧客の視覚的な違和感を緩和できます。

ただし、これはあくまで「サブドメインとして自社ドメイン配下に見せる」工夫であり、パスも含めて完全に従来と同じURL体系にすることはできません。完全な一致を求めるのではなく、ブランド体験として許容できる範囲に調整するという割り切りが必要です。

設定手順については公式ヘルプセンターの「お客様アカウントの設定と管理」に詳しく記載されています。移行作業の一環として、サブドメイン接続は必ず実施することをおすすめします。

7. 移行前のチェックリスト

以下の項目に1つでも該当するストアは、切り替え前に対応方針を決めておく必要があります。該当項目が多いほど、移行作業の工数と調整範囲が大きくなります。

  • マイページ(customers/account.liquid 等)をLiquidでカスタマイズしている
  • 会員登録フォームに独自項目(誕生日・性別・電話番号など)を追加している
  • LINEログインを利用している(アプリ経由を含む。メール未取得の顧客がいる可能性にも注意)
  • Multipassを利用して外部システムと認証連携している
  • SAML/OIDC等によるSSO連携を行っている(Shopify Plus)
  • Shopify Flowで「お客様アカウントが有効になったとき」等の従来アカウント系トリガーを使用している
  • customer_account_status フィルターを含む顧客セグメントを運用している
  • マーケットごとに異なるドメインでお客様アカウントを運用している
  • 独自のログイン・登録ページ(ポップアップ/モーダル含む)を構築している
  • マイページ上で動作するアプリ(サブスクリプション管理・ポイント表示等)を利用している

各項目の対応方針の概略は以下の通りです。

  • Liquidカスタマイズ系(マイページ・登録フォーム・独自ログインページ):アプリブロックまたはCustomer Account UI extensionsでの再構築が必要です。再現が難しい場合は、機能を絞って優先順位を付ける判断が求められます。
  • LINEログイン:第6-1章で述べた通り、代替策の検討が必要です。加えて、顧客レコードのメールアドレス登録率を必ず事前確認し、未取得顧客が一定数いる場合はメール取得キャンペーンの実施を最優先タスクとして計画に組み込みます。
  • Multipass・SSO:Plusプランで独自IDプロバイダー接続への移行を検討します。Plus以外のプランでMultipassに依存している場合は、連携そのものの廃止または別手段での再構築が必要です。
  • Shopify Flow・顧客セグメント:代替トリガー・代替フィルターで設計し直します。完全な代替がない場合は、施策そのものの再設計を含めて検討します。
  • マーケットごとの独自ドメイン:お客様アカウントは単一ドメインになる前提で、マーケティング導線を調整します。
  • マイページ上のアプリ:アプリベンダーに新バージョン対応状況を確認し、未対応アプリについては代替アプリへの切り替えまたは機能廃止を判断します。

このチェックリストは、移行スケジュールを見積もる際の最初のインプットになります。該当項目の棚卸しと影響範囲の確認を、先延ばしせずに進めることをおすすめします。

8. 移行手順

チェックリストでの棚卸しが終わり、対応方針が固まったら、実際の切り替え作業に入ります。ここではShopify管理画面での操作手順と、切り替え前後の重要ポイントを整理します。

管理画面での切り替え操作

切り替えは管理画面から数クリックで完了します。

  1. Shopify管理画面で [設定] > [お客様アカウント] を開きます。
  2. [リンクするお客様アカウントのバージョンを選択] で [お客様アカウント](=新しいお客様アカウント)を選びます。
  3. [お客様アカウントに切り替える] をクリックします。

切り替え後、以下の設定を順に確認・調整していきます。

  • ログインリンクの表示:テーマのヘッダー・フッター等に設置しているログインリンクが、新しいお客様アカウントの正しいURLに向いているかを確認します。
  • サブドメインの接続:第6-4章で触れた通り、ブランド体験の一貫性のため account.yourdomain.com のようなサブドメインを接続します。
  • ブランド設定:管理画面の [設定] > [ブランド] で、ロゴ・カラー・フォント等を設定します。お客様アカウントページにも反映されます。
  • 差出人メールアドレス:OTPメールを含む認証関連メールの差出人アドレスが、自社ドメインで設定されていることを確認します。未設定の場合は迷惑メール判定のリスクが高まります。

切り替え前後の重要ポイント

公式ヘルプセンターの記載に沿って、特に押さえておくべきポイントを整理します。

  • 30日以内なら従来のお客様アカウントに戻せる:切り替え後30日以内であれば、管理画面から従来バージョンに戻すことが可能です。本番環境でも、期間内であれば検証目的の切り替えが現実的に行えます。
  • 切り替え前に公式推奨ステップを完了させる:Shopifyは移行前の準備として、①従来のカスタマイズの把握、②重要なカスタマイズのアプリ再構築、③ブランド設定の確認、④サブドメインの接続、⑤差出人メールアドレスの確認、の5つを推奨しています。
  • 既存顧客は再登録不要:顧客データは維持され、既存のメールアドレスでそのままログインできます。顧客への事前アナウンスでは、「ログイン方法が変わる(パスワードから6桁コードへ)」点を伝えれば十分です。
  • 切り替えタイミングは繁忙期を避ける:ログイン方法が変わるため、問い合わせが一時的に増える可能性があります。セール・繁忙期直前の切り替えは避け、比較的落ち着いたタイミングを選ぶのが安全です。

切り替え作業自体は短時間で済みますが、本当の作業は切り替え後の「顧客への説明」「アプリ・連携の動作確認」「マーケティング施策の再設計」にあります。30日の巻き戻し期間は、このあたりの確認を走らせるための猶予として活用するのがおすすめです。

9. よくある誤解・注意点

移行検討の過程でよく出る誤解・質問をQ&A形式で整理します。

Q. 切り替えると顧客データは消えるのか?

A. 消えません。認証方式(パスワードからOTPへ)とマイページUIが変わるだけで、顧客プロフィール・注文履歴・住所・メモ等のデータはそのまま保持されます。

Q. 既存顧客は再登録が必要か?

A. 不要です。既存のお客様プロフィールに紐付いているメールアドレスでログインすれば、過去の注文履歴等にアクセスできます。顧客に求められるのは「パスワードの代わりにメールで届く6桁コードを入力する」という動作の変更のみです。

Q. パスワードでログインし続けたい顧客はどうなるのか?

A. 選択肢はありません。新しいお客様アカウントでは全顧客がOTP方式になります。パスワードを使い続けるオプションは用意されていません。

Q. 「お客様アカウントが有効になったとき」Flowトリガーの代替は?

A. 現時点で直接の代替トリガーは提供されていません。「お客様が作成されたとき」トリガー等を組み合わせて代替設計を行うことになります。従来トリガーに依存していたオートメーション(初回ログイン時のクーポン付与など)は、トリガー・条件・タイミングのすべてを設計し直す必要があります。

Q. Shop Payを使っている顧客との関係は?

A. Shop Payを利用している顧客には「Shopでログイン」が優先表示されます。Shop Payが有効なストアでは「Shopでログイン」が自動的にオンになる挙動のため、有効化のための追加設定は基本的に不要です。

Q. 切り替え後もテーマのログインフォームはそのまま使える?

A. テーマ上のログインリンクは新しいお客様アカウントのURLにリダイレクトされます。ただし、テーマを独自にカスタマイズして「テーマ内で完結するログインフォーム」を組み込んでいた場合、そのフォームは動作しなくなります。ログイン動線はShopify側で提供されるサインインページに集約される前提で、テーマを見直してください。

10. 戦略的に移行するための視点

ここまで技術的な変更点と対応方針を解説してきました。しかし、本記事で最も伝えたいのは、本章で述べる「移行を単なる技術作業として処理しないほうがいい」という視点です。

単純な切り替えでは日本のストアはデメリットが上回るリスクがある

日本のストアで単純な切り替えを行うと、LINEログイン非対応・属性取得の導線変更・ブランディング影響などのデメリットが、目に見えやすい形で顕在化します。一方で、新しいお客様アカウントがもたらすメリット(セキュリティ向上、セルフサービス返品、ストアクレジット、長時間セッション、B2B対応など)は、すぐには数字に現れにくい性質のものが多く、マーチャントの実感として「失った機能」の方が強く印象に残りがちです。

この非対称性は重要です。何も手を打たずに切り替えると、デメリットだけが目立ち、メリットは埋もれる結果になりやすいからです。

Shopifyの新機能が示す「LTV重視」へのシフト

ここで視点を変えて、新しいお客様アカウントが標準搭載した機能群を改めて眺めてみます。

  • セルフサービス返品
  • ストアクレジット表示・利用
  • B2B対応
  • 最大365日のセッション保持
  • パスワードレス認証による離脱削減
  • Shopでログインによるワンタップ認証

これらはいずれも、新規獲得ではなく既存顧客のLTV(顧客生涯価値)を高めるための機能です。返品ハードルを下げてリピートを促し、ストアクレジットで次回購入に誘導し、セッションと認証の摩擦を下げて再訪時のCVRを守る。B2Bはアカウントあたりの継続売上の伸ばし方そのものです。

つまりShopifyは、新しいお客様アカウントへの移行を通じて、マーチャントに対して暗に「新規獲得偏重からLTV重視の運営へとシフトせよ」というメッセージを発していると解釈できます。移行に伴い従来から機能を削ったのも、この方向性への思想的な整合を取るためと見ることができます。

新機能を活用する具体的な戦略例

この視点に立つと、移行は「失う機能の後始末」ではなく、「新たに手に入る機能を使った施策設計」の機会になります。具体的には次のような戦略が考えられます。

  • セルフサービス返品で返品摩擦を下げる:返品時の問い合わせを減らし、「返品しやすいから安心して買える」というメッセージを購入ページで訴求することで、購入時のCVR向上にもつなげます。
  • ストアクレジットを返金・補償の基本手段にする:現金返金ではなく店内クレジットで還元することで、資金をストア内に留め、次回購入率を引き上げます。キャンセル・配送トラブル時の代替補償にも活用できます。
  • 最大365日のセッション保持を前提に、マイページを「常時表示される販促面」として使い倒す:再訪ごとにログインさせる設計から、「常にログインされている前提で、マイページをパーソナライズ販促の場として設計する」方向に切り替えます。
  • B2B機能で法人顧客向け施策を強化する:Plus以外でも、B2B機能は一部利用可能になっています。法人顧客と個人顧客を同じストアで扱っていた場合、体験を分離し、法人向け価格・決済条件を正しく出し分けるだけでも効果があります。
  • パスワードレス化を「ログイン離脱削減」施策として数値で捉える:ログイン画面での離脱率を移行前後で比較し、効果を計測します。新規会員獲得率の改善に寄与する可能性が高い領域です。

いずれも、移行作業とセットで1〜2つを選んで導入するだけで、「失う機能」の心理的インパクトを相殺できる施策です。

おすすめの移行の進め方

以上を踏まえた、現実的な進め方を整理します。

  • 影響度の定量評価:LINEログイン経由の会員比率、そのうちメールアドレス未取得の顧客比率、誕生日属性を使った施策の貢献売上、Liquidカスタマイズの利用頻度など、失う機能の実際の影響を数字で把握します。特にLINEログイン経由の顧客のうちメール未取得の割合は、移行時の顧客消失リスクに直結するため、他に先んじて確認することをおすすめします。
  • LTV施策を1〜2つ選ぶ:セルフサービス返品・ストアクレジット・長時間セッションの活用のうち、自ストアのビジネスモデルに合うものを選びます。
  • 移行と施策導入を同時にアナウンスする:顧客向けの告知を「ログイン方法が変わります」ではなく、「より使いやすいマイページに生まれ変わります」と、新しい便益とセットで打ち出します。
  • 30日の巻き戻し期間を検証に使う:切り替え後30日以内であれば戻せるため、本番データでA/Bに近い検証が行えます。CVRの変化・問い合わせの増減・アプリ連携の動作を集中的に確認します。

新しいお客様アカウントへの移行は、避けられない技術的イベントです。同じ工数をかけるのであれば、「従来機能の再現」にリソースを集中させるより、「新機能を活かしたLTV施策」にリソースを寄せたほうが、移行後のストアの体質を強くしやすいと考えます。

11. まとめ

本記事の要点

最後に、本記事の要点を整理します。

  • 2026年2月26日、Shopifyは従来のお客様アカウントの非推奨化を発表。最終廃止日は2026年後半に発表予定で、先延ばしできない状況に入っています。
  • 新しいお客様アカウントはセキュリティ・UX・標準機能の面で優れており、今後のShopifyの新機能はすべてこちらに実装されていきます。
  • 一方で、日本のストアにはLINEログイン非対応・会員登録時の属性取得の導線変更・ブランディング影響など固有の論点があり、単純な切り替えではデメリットが目立つ結果になりがちです。
  • 30日以内なら従来バージョンに戻せるため、本番環境での検証もしやすくなっています。
  • 移行はLTV重視のストア運営へとシフトする機会として捉え、セルフサービス返品・ストアクレジット・長時間セッションなどの新機能を施策とセットで導入することをおすすめします。

Shopifyのプラットフォーム変更は、単なる技術的アップデートであると同時に、プラットフォームが示す「次の運営のあり方」でもあります。自ストアの現状を棚卸しし、戦略とセットで移行計画を立てていくことが、結果的に最も負担の少ない進め方になるはずです。

参考リンク(公式)

本記事で参照したShopifyの公式情報は以下の通りです。移行検討時は、最新情報を必ず一次ソースで確認してください。

著者
ARMERIA Editorial Department
監修
ARMERIA (Shopify App Development / E-commerce Consulting)
最終更新
Back to blog