この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、会員機能をどこまで作るか迷っている担当者
読了時間: 約12分
「会員登録できるようにしたい」——ECの要件定義で、ほぼ必ず出てくる一言です。ところがShopifyの管理画面で顧客アカウントの設定を開くと、見慣れない選択肢が並んでいます。「新しい顧客アカウント」と「クラシック顧客アカウント」。どちらを選ぶかで、購入者のログイン方法も、会員ページの中身も、後からカスタマイズできる範囲も変わります。
やっかいなのは、この選択があとから戻しにくいことです。切り替えた瞬間に顧客側のログイン手順が変わるため、既存会員がいるストアでは移行の告知まで含めた作業になります。にもかかわらず、制作の初期段階で「とりあえず標準で」と流されがちな項目でもあります。
この記事では、Shopifyストアを自分たちでも運営している立場から、新旧2つの顧客アカウントの違い、設定を切り替えたときに顧客側で実際に起きること、そして「会員機能がほしい」と言われたときに標準でどこまで足りて、どこからアプリやテーマ改修が必要になるのかの線引きを整理します。アプリの◯選ではなく、自分のストアの条件で判断できる状態を目指します。
Shopifyの顧客アカウントには2つの方式がある
まず用語を揃える
Shopifyの顧客アカウント（Customer accounts）は、購入者がログインして注文履歴や住所を確認できる機能です。ここに現在2つの方式が存在します。
| 新しい顧客アカウント | クラシック顧客アカウント | |
|---|---|---|
| 別名 | New customer accounts | Legacy / 従来型 |
| ログイン方法 | メールアドレスに届くワンタイムコード | メールアドレス＋パスワード |
| パスワード | 使わない | 顧客が設定・管理する |
| 会員ページの場所 | Shopify管理のドメイン配下 | 自ストアのドメイン（/account） |
| 見た目の変更 | 限定的（ブランディング設定の範囲） | Liquidテーマで自由に組める |
| 拡張 | 顧客アカウント拡張機能（アプリ経由） | テーマのコードを直接編集 |
「メール認証型」「パスワードレス」と呼ばれるのが新しい方式です。ログイン時にパスワードを入力するのではなく、メールアドレスを入れるとワンタイムコードが届き、それを入力して入る仕組みになっています。
なぜ2つあるのか
Shopifyは新しい顧客アカウントを標準の方向として押し出しています。パスワードの使い回しや流出リスクをストア側が抱えなくて済むこと、Shop Payやショップアプリとの連携がしやすいことが理由として説明されています。
一方で、クラシック側は「テーマの中に会員ページがある」という構造上の強みを持っています。ログインページも、マイページも、templates/customers/*.liquid としてテーマファイルの一部です。つまりデザインもロジックも自分たちの手の中にある。ここが実務上とても大きい違いです。
クラシック（テーマ内）
- URLは自ストアのドメイン
- Liquidで自由に組める
- 独自項目・独自セクションを足せる
- パスワード管理が発生する
新しい顧客アカウント
- URLはShopify側のドメイン
- 見た目の調整は設定の範囲内
- 拡張は専用の仕組み経由
- パスワードを持たない
判断の軸はほぼこの図に集約されます。会員ページを自分たちで作り込む予定があるかどうか。それが最初の分岐点です。
「新しい方が良い」とは限らない
制作側の本音を書くと、新しい顧客アカウントは要件が軽いストアほど向いています。注文履歴と住所さえ見られればいい、会員ページは実質「注文の確認場所」——この条件なら、パスワード運用の責任を持たない構成のほうが素直です。
逆に、会員ページに独自の情報を出したい、会員限定の導線を作りたい、といった要望があるストアでは、クラシック側のほうが手数が少なく済みます。
新しい方式には、ドメインが変わることで発生する副作用もあります。会員ページがストアのドメイン外に出るため、GA4などの計測をまたぐ設計が必要になり、ヘッダーやフッターの一貫性も設定の範囲でしか揃えられません。「ログインした瞬間に別サイトに来たように見える」という状態は、ブランドサイトとしては軽くない問題です。
ログイン方式の設定は管理画面のどこで変えるのか
方式の切り替えは、管理画面の 設定 → 顧客アカウント から行います。ここで新しい顧客アカウントとクラシックのどちらを使うかを選び、あわせて「ストアにログインリンクを表示するか」も指定します。管理画面の文言や並びは版によって変わることがあるので、最終的な位置は実機で確認してください。
設定を触るときに、同時に見ておくべき箇所が3つあります。
1. ヘッダーのログインリンク
テーマエディタ側にも「アカウントリンクを表示」に相当する設定があります。管理画面で顧客アカウントを有効にしても、テーマ側でリンクを出していなければ顧客からは入口が見えません。逆に、ログイン導線を意図的に出さない運用（ゲスト購入のみ）を選んでいるストアもあります。ここは管理画面とテーマの2箇所で決まる、という点だけ押さえておけば迷いません。
2. 通知メールのテンプレート
設定 → 通知 に、ログインコードやパスワードリセットの案内メールがあります。方式によって使われるテンプレートが変わるため、切り替えたら「実際に自分でログインしてみて、届いたメールの文面を読む」工程を必ず入れてください。差出人名やロゴが初期値のまま飛んでいるストアは珍しくありません。顧客がログインの直前に必ず見る画面なので、ブランドの印象に直結します。
3. チェックアウトとの関係
顧客アカウントの方式は、チェックアウト時に「ログインしている状態で買う」体験にも影響します。切り替えたら、ログイン済み・未ログインの両方で購入まで一度通してください。会員価格や会員限定商品をタグで制御している場合、ここが崩れると売上に直接効きます。
設定そのものは数クリックで終わります。時間がかかるのは、この確認と、次章の「顧客側に何が起きるか」への備えです。
切り替えると顧客側に何が起きるか
ここが最も見落とされる論点です。設定を切り替えるのは管理画面の数クリックですが、影響を受けるのは既存の会員全員です。
ログイン手順が変わる
クラシックから新しい顧客アカウントに切り替えると、次に来店した顧客はこうなります。
問題は3番目です。メールが受信できない顧客は、その場でログインできません。パスワード方式なら、ブラウザの保存パスワードで自動入力されて素通りできていた人が、メールアプリを開く手間を強いられることになります。
想定される詰まり方は具体的です。
- 会社の共有アドレスで登録していて、自分の端末でメールを見られない
- 登録メールが古いアドレスのまま（転職・キャリア変更で受信できない）
- 迷惑メールフォルダに振り分けられ、届いていないと思い込む
- キャリアメールでドメイン指定受信をしていて弾かれる
パスワード方式にも「忘れた」問題はありますが、忘れた人だけが再設定に回ります。メール認証型は全員が毎回メールを開く構造です。この差は、リピート購入が多いストアほど効いてきます。
逆方向（新しい→クラシック）はもっと注意が要る
新しい顧客アカウントで運用していた期間、顧客はパスワードを持っていません。ここからクラシックに戻すと、既存会員には「パスワードを設定してもらう」工程が発生します。案内メールを出し、再設定してもらい、それでも戻ってこない層が一定数出ます。
つまり切り替えは、どちらの方向でも「顧客に手間をかけさせる」イベントです。 リニューアルのタイミングで一度だけやる、と決めて計画に組み込むべきもので、思いつきで触る設定ではありません。
切り替え前にやっておくこと
実際に切り替えを含む案件を組むなら、この順番を守ると事故が減ります。
- 既存会員数と、直近1年でログインした会員数を数える（管理画面の顧客セグメントで出せます）。休眠がほとんどなら影響は小さく、能動的に使われているなら告知が必須です
- テーマ側で
/accountに依存している箇所を洗う。ヘッダーのマイページリンク、購入完了後の導線、会員限定表示のロジックなど - 切り替えの告知を先に打つ。メールとサイト内お知らせの両方。「次回から、届いたコードでログインします」を先に伝えるだけで、問い合わせは減ります
- 問い合わせ窓口を厚くする日を決めておく。切り替え直後の1〜2週間は必ず来ます
この4番目を計画に入れていない案件は、切り替え当日にサポートが回らなくなります。制作会社が言わないなら、発注側から確認してよい項目です。
「会員機能がほしい」の中身を分解する
要望としての「会員機能」は、実は複数の別々の機能が束になった言葉です。分解しないまま見積もりに入ると、標準で足りるものにまでコストが乗ります。
標準でできること・できないこと
| やりたいこと | Shopify標準 | 判定 |
|---|---|---|
| 注文履歴を見せる | ○ | 標準で足りる |
| 配送先住所を保存・編集させる | ○ | 標準で足りる |
| 再注文（同じ商品をもう一度） | ○ | 標準で足りる |
| 会員だけに販売する（限定商品） | △ | タグ＋テーマ改修、またはアプリ |
| 会員ランク別の価格 | × | アプリまたはPlus機能 |
| ポイント付与・利用 | × | アプリ |
| お気に入り／ウィッシュリスト | × | アプリ、または自前実装 |
| 会員限定コンテンツページ | △ | テーマ改修で組める |
| 登録時に独自項目を取る（会社名・業種など） | △ | 方式によって難易度が変わる |
| 卸価格・BtoB取引 | × | Plusの B2B 機能かアプリ |
○が並んでいる上3つは、要件定義で「会員機能」と言われたときの実態のかなりの割合を占めます。ここだけが目的なら、追加費用はほぼ発生しません。まずここを確認するのが、発注側にとって一番得な質問です。
判断のフローはこうなる
3番目の「データを持つ必要があるか」が、アプリとテーマ改修を分ける実務的な境目です。ポイント残高、ランク、購入回数に応じた特典——こういう状態を保存して増減させるものは、テーマのLiquidだけでは扱えません。アプリの領域です。
逆に、「特定タグの顧客にだけこのセクションを見せる」「会員なら価格の下に注記を出す」といった見せ方の分岐だけなら、テーマ改修で完結します。月額を積み上げずに済む領域です。
会員限定販売は「タグ運用の設計」が本体
△に入っている会員限定販売は、実装より運用設計のほうが重い機能です。組み方はおおむねこうなります。
- 対象顧客に
wholesalevipのようなタグを付ける - 商品側にも対応する印を持たせる（コレクション分け、またはメタフィールド）
- テーマ側で、顧客タグと商品の印が一致したときだけ購入ボタンを出す
- 一致しない場合の表示を決める（非表示にするか、「会員限定です」と出してログインへ誘導するか）
実装で詰まるのは3ではなく1です。誰が、いつ、どうやってタグを付けるのかが決まっていないと、公開後に「登録したのに買えない」という問い合わせが発生します。手動で付けるのか、特定の商品を買った人に自動で付くのか、申込フォームからの承認制にするのか。この運用フローを先に決めてから実装に入ると、テーマ側の分岐は素直に書けます。
アプリなしで組めるものもある
Shopifyストアを自分たちでも運営している側の実感として、アプリを入れる前に「これ自前で組めないか」を一度考える価値はあります。判断材料になるのは3つです。
- その機能が壊れたとき、売上が止まるか。決済や在庫に絡むならアプリ（保守を買う）。表示の補助程度なら自前でも十分
- データをストア外に置いていいか。顧客の行動ログが外部サービスに溜まる構造は、後で解約しにくくなります
- テーマのアップデートに耐えるか。自前実装は、Dawnの更新時に自分で追従する責任を負います
Dawnベースで改修を進めるときの方針は、別記事で詳しくまとめています。
たとえばお気に入り機能は、「後で見返したい商品を保存する」だけならブラウザ側に保存する方法でも成立します。ログイン不要で動くぶん、会員登録のハードルを上げずに済むという利点もあります。実装の具体はShopifyお気に入り（ウィッシュリスト）をアプリなしで実装する方法にまとめました。
アプリを選ぶときに見る場所
標準で足りないと判断したら、次はアプリです。ここで「機能一覧の比較表」だけを見て決めると、半年後に困ります。
機能の前に見る4項目
| 見る場所 | 何を判断するか |
|---|---|
| 最終更新日 | 長く更新が止まっているアプリは、Shopify側の仕様変更で壊れたときに直らない可能性がある |
| 対応言語 | 顧客に見えるボタンやメッセージが日本語化できるか。管理画面が英語なのは我慢できても、購入者に英語が出るのは事故 |
| サポート体制 | 日本時間で返ってくるか。チャットのみか、メールか。時差が大きいと1往復に丸1日かかる |
| テーマとの相性 | Dawnベース（Online Store 2.0）に対応しているか。旧世代のテーマ前提のアプリはアプリブロックが使えず、手動でコードを埋め込む形になる |
とくに最終更新日は、機能一覧のどこにも書いてありませんが、アプリストアのページ内で確認できます。「機能は多いが長く止まっている」より「機能は最小限だが直近で更新されている」ほうが安全という判断は、実務ではよくあります。
料金については、無料枠のあるものから月額課金のものまで幅があります。プランも金額も変わるため、最新の料金は必ず各アプリのページで確認してください。この記事で金額を断定しないのは、書いた時点で古くなるからです。
導入後に効いてくる4つの論点
アプリは「入れた日」より「1年後」のほうが問題になります。
1. 月額の積み上がり
1本ずつは小さくても、ポイント・レビュー・ウィッシュリスト・レコメンド・SNS連携……と積むと、月額が保守費と同じ規模に育ちます。年額に直して見る癖をつけてください。ホームページ全体の維持費の考え方は、こちらで項目別に分解しています。
2. 表示速度
アプリはたいていJavaScriptを読み込みます。5本入れれば5本分のスクリプトが商品ページで走ります。ECは表示速度がそのまま離脱率に効くので、「入れたが使っていない」アプリは残さず消すのが原則です。アンインストールしてもテーマにコードが残るケースがあるため、消したあとにテーマファイルを確認する工程まで含めて考えます。
3. 解約時に残るもの
ここが一番厄介です。アプリを解約すると、そのアプリが管理していたデータ（ポイント残高、会員ランク、レビュー本文）は基本的に取り出せないか、取り出しても他で使えない形式になります。「移行できないデータを作るアプリか」を導入前に確認する。エクスポート機能の有無は、機能一覧より先に見ていい項目です。
4. 管理画面を触る人の負担
アプリを増やすと、管理画面のメニューが増えます。日々の運用担当が「どこで何を設定するのか分からない」状態になると、機能は入っているのに使われません。運用する人が1人なのか、複数人で回すのかで、選ぶべきアプリの数は変わります。
設定を決める順番
実際の案件で、どの順に決めていくかを整理します。
新規構築の場合
- 会員ページを作り込む予定があるかを先に決める。あるならクラシック、無いなら新しい顧客アカウント
- 登録時に取りたい情報を洗い出す。名前とメール以外に必要なものがあるなら、その取り方を方式ごとに確認する
- 会員限定の販売をやるかを決める。やるなら、タグの付け方と付ける人を最初に決める
- ポイント等の「状態を持つ機能」は、初期リリースから外せないか検討する。あとから足せる領域なので、初期の予算を圧迫させない
4番目は制作側から積極的に提案すべき点です。ローンチ前は決めることが多すぎて、ポイント設計まで詰め切れないまま入れると、運用が回らないまま月額だけ払い続けることになります。
リニューアルの場合
既存会員がいる場合は、順番が変わります。
- 今の会員数と稼働率を数える
- 今の方式を続けるか切り替えるかを、稼働率を見て決める
- 切り替えるなら、告知計画と問い合わせ体制を工程表に入れる
- 移行するデータを確認する。顧客データ本体はShopifyに残りますが、アプリが持っているポイントやランクは別の話です
リニューアル全体の判断軸——作り直すか部分改修かの線引きについては、こちらでまとめています。
コーポレートサイトと兼ねる場合
Shopifyをコーポレートサイトと兼用する構成にしている場合、顧客アカウントの選択はさらに効いてきます。会社案内や採用情報と同じドメインの中で、ログインだけ別ドメインに飛ぶ構造をどう見るか、という判断が入るためです。兼用構成そのものの考え方はShopifyをコーポレートサイトと兼ねる構成の考え方で扱っています。あわせて読むと、ドメイン設計の全体像がつかみやすくなります。
見積もりを見るときのチェックポイント
顧客アカウント周りが見積もりに載ってきたとき、発注側が確認すべきことを挙げます。
「会員機能一式」で1行にまとまっていたら分解を頼む
前述のとおり、会員機能は複数の機能の束です。1行で計上されていると、標準で足りる部分にまで費用が乗っているのか、本当に作り込みが必要なのか判別できません。
聞き方：「この会員機能一式の内訳を、標準機能で対応する部分と、実装が必要な部分に分けて教えてください」
これは意地悪な質問ではなく、正しく答えられる会社なら数分で返せる内容です。返答の質で、その会社がShopifyをどれだけ理解しているかも見えます。
アプリ費用が見積もりに含まれているか確認する
制作費の見積もりに、アプリの月額が含まれていないケースがあります。制作費とは別に発生する固定費なので、年額に直した金額を別枠でもらうのが正確です。
切り替え作業の工数が入っているか
既存会員がいるリニューアルで顧客アカウント方式を変えるなら、切り替え作業そのものより告知・問い合わせ対応の工数が実質です。ここが見積もりに一切ないまま「切り替えます」と書かれていたら、当日に誰が対応するのかを確認してください。
制作会社とフリーランス、どちらに頼むかで、こうした運用フォローの厚みは変わります。判断の軸はこちらにまとめています。
よくある質問
新しい顧客アカウントとクラシック、どちらを選ぶべきですか
会員ページを自分たちで作り込む予定があるかで決まります。注文履歴と住所管理だけで足りるなら新しい顧客アカウントで問題ありません。会員限定の表示、独自セクション、ブランドに合わせたデザインを入れたいならクラシックを選んでください。あとから切り替えると既存会員に手間がかかるため、最初に決めるべき項目です。
顧客アカウントのログイン方式はどこで設定しますか
管理画面の 設定 → 顧客アカウント で、新しい顧客アカウントとクラシックのどちらを使うかを選びます。あわせてストアにログインリンクを表示するかも指定できますが、ヘッダーへの実際の表示はテーマエディタ側の設定にも左右されます。切り替えたら、設定 → 通知 でログインコードやパスワードリセットの文面を確認し、自分で一度ログインして購入まで通してください。
顧客アカウントを切り替えると、顧客データは消えますか
顧客データそのもの（メールアドレス、注文履歴、住所）はShopifyに残るため消えません。変わるのはログイン方法です。クラシックから新しい方式に切り替えるとパスワードが使われなくなり、逆方向に戻すと顧客にパスワードの再設定を依頼する必要があります。ただしアプリが独自に持っているポイント残高や会員ランクは別管理なので、そちらは個別に確認してください。
メール認証だと、顧客がログインできない事態は起きませんか
起きます。登録メールが古いまま、迷惑メール振り分け、共有アドレスで受信できない、といったケースは実際に発生します。切り替えるときは事前にメールとサイト内で告知し、切り替え直後の1〜2週間は問い合わせが増える前提でサポート体制を組んでください。リピート購入が多いストアほど影響が大きくなります。
ポイント機能や会員限定販売は標準で使えますか
ポイントの付与・利用はShopifyの標準機能に含まれないため、アプリが必要です。残高を保存して増減させる機能は、テーマのカスタマイズだけでは実装できない領域だと考えてください。一方、会員限定販売は顧客タグとテーマ改修で組めます。ただし実装より、誰がいつタグを付けるかという運用フローの設計のほうが本体です。
まとめ
Shopifyの顧客アカウントは、機能の優劣ではなく会員ページをどこに置くかの選択です。
- 新しい顧客アカウント：メール認証型。パスワード管理から解放されるが、会員ページはShopify側のドメインに置かれ、作り込みの自由度は限定される
- クラシック顧客アカウント：パスワード型。テーマの中に会員ページがあるため自由に組めるが、パスワード運用の責任を持つ
- 設定は 設定 → 顧客アカウント の数クリック。ただしテーマ側のログインリンク、通知メールの文面、チェックアウトの通しまで確認して初めて終わる
- 切り替えは顧客に手間をかけるイベント。どちらの方向でも、告知と問い合わせ体制を工程に入れる
- 「会員機能」は分解する。注文履歴・住所管理・再注文は標準で足りる。状態を保存する機能だけがアプリの領域
- アプリは最終更新日・対応言語・サポート・テーマとの相性を先に見る。金額は変わるので各アプリのページで確認する
- 導入後に効くのは、月額の積み上がり・表示速度・解約時に残るもの・運用担当の負担の4つ
最初に一度だけ丁寧に決めておけば、あとは触らずに済む領域でもあります。逆に、決めずに走り出すと、既存会員を抱えたあとで取り返しがつきにくくなります。要件定義の早い段階で、この記事の分解表を持ち込んでみてください。
