CONTENT
ここから
第24章では、本番Squareアカウント、Vercelへのデプロイ、独自ドメイン、SSL、法務ページ、本番決済テストを整理しました。
ここから第8部では、本格ECへ拡張する方法を扱います。
この章では、会員機能を追加するかどうかを考えます。
会員機能とは、購入者がログインし、注文履歴や住所などを確認できる仕組みです。
会員登録
↓
ログイン
↓
マイページ
↓
注文履歴
↓
再購入
↓
住所保存
ただし、会員機能は便利な反面、ECを複雑にします。
ログイン、パスワード、個人情報、退会処理、セキュリティなど、考えることが増えます。
攻略本風に言えば、第25章は「常連客用のセーブデータを作るステージ」です。
25.1 会員機能は本当に必要か
まず最初に考えるべきことは、会員機能を入れるかどうかです。
ECを作るとき、つい最初から会員登録を入れたくなります。
しかし、小規模ECでは、最初から会員機能が必要とは限りません。
むしろ、会員登録が購入の邪魔になることもあります。
商品を買いたい
↓
会員登録してください
↓
面倒になる
↓
離脱
購入者にとって、会員登録は手間です。
メールアドレス、パスワード、認証メール、ログイン。
これらが増えるほど、購入までの距離が長くなります。
会員機能が向いているECは、次のようなケースです。
・リピート購入が多い
・定期購入がある
・注文履歴を見せたい
・住所保存を使いたい
・会員限定商品がある
・ポイントやランク制度がある
・BtoB取引がある
反対に、会員機能がなくてもよいケースです。
・単発購入が中心
・ギフト購入が多い
・商品数が少ない
・注文頻度が低い
・まずは早く販売開始したい
最初の小規模ECでは、次の順番がおすすめです。
1. ゲスト購入で販売開始
2. 注文データを蓄積
3. リピート購入が増える
4. 必要になったら会員機能を追加
会員機能は、最初から入れるものではなく、必要になったら追加するものとして考えても構いません。
売る前から複雑にしない。
売れてから必要な機能を足す。
これが、小規模ECでは現実的です。
25.2 ゲスト購入との比較
会員購入とゲスト購入の違いを整理します。
ゲスト購入とは、会員登録せずに購入できる方法です。
商品を選ぶ
↓
配送先を入力
↓
決済
↓
購入完了
会員購入では、ログインや会員登録が入ります。
商品を選ぶ
↓
ログインまたは会員登録
↓
配送先を選ぶ
↓
決済
↓
購入完了
それぞれのメリットを比べます。
ゲスト購入のメリット：
購入までが早い
初回購入のハードルが低い
ギフト購入と相性が良い
実装が比較的シンプル
会員購入のメリット：
注文履歴を見せられる
住所を保存できる
再購入しやすい
定期購入と相性が良い
顧客ごとの分析がしやすい
最初に重視すべきなのは、購入完了までの短さです。
初めてのお客様に、いきなり会員登録を求めると離脱しやすくなります。
初回購入：
ゲスト購入を優先
リピート購入：
会員登録を案内
おすすめは、ゲスト購入を残したまま、会員機能を追加する方法です。
購入方法：
[ゲストとして購入]
[ログインして購入]
これなら、急いでいる人はゲスト購入できます。
リピートしたい人は会員登録できます。
買いたい人を止めない。
便利に使いたい人には会員機能を用意する。
会員機能は、購入を強制する壁ではなく、便利にする選択肢として設計します。
25.3 Supabase Authを使う場合
Next.jsとSupabaseを使っている場合、会員機能にはSupabase Authを使う方法があります。
Supabase Authは、ユーザー登録、ログイン、認証状態の管理を行うための機能です。公式ドキュメントでは、メールとパスワード、マジックリンク、OTP、ソーシャルログイン、SSOなど複数の認証方法をサポートすると説明されています。(
)
Supabase Authを使うと、次のような機能を作れます。
・メールアドレス登録
・ログイン
・ログアウト
・パスワードリセット
・ログイン中ユーザーの取得
・ユーザーIDと注文の紐づけ
Supabase Authでは、ユーザーはAuth schema内にユーザーIDを持つ存在として扱われ、ログイン中のユーザーにはAccess Tokenが発行されます。このTokenを使うことで、RLSポリシーと組み合わせてユーザーごとのアクセス制御ができます。(
)
会員機能の基本構成は、次のようになります。
Supabase Auth：
ログイン情報を管理する
profilesテーブル：
表示名や連絡先などを管理する
ordersテーブル：
注文履歴を管理する
addressesテーブル：
配送先住所を管理する
Supabaseで重要なのが、RLSです。
RLSはRow Level Securityの略で、行単位でアクセス制御を行うPostgresの仕組みです。Supabaseでは、RLSをSupabase Authと組み合わせて、ユーザーごとに見られるデータを制限できます。(
)
たとえば、マイページでは、自分の注文だけ見えるようにします。
山田さん：
山田さんの注文だけ見える
佐藤さん：
佐藤さんの注文だけ見える
他人の注文：
見えない
RLSを設定しないまま注文テーブルを公開すると危険です。
危険な設計：
ログインユーザーなら全注文を見られる
安全な設計：
ログインユーザーは自分の注文だけ見られる
Supabaseで会員機能を作るときの基本方針は、次の通りです。
Authで本人確認する
↓
user_idで注文と紐づける
↓
RLSで自分のデータだけ見せる
Supabase Authは便利ですが、入れれば自動で安全になるわけではありません。
DB設計とRLS設計がセットで必要です。
25.4 顧客情報と注文履歴
会員機能を入れると、顧客情報と注文履歴を紐づけられます。
ゲスト購入では、注文ごとに名前や住所を入力します。
会員購入では、ユーザーIDを注文に紐づけます。
users
↓
orders
↓
order_items
注文テーブルには、会員ユーザーIDを持たせます。
type Order = {
id: string;
userId: string | null;
orderNumber: string;
status: OrderStatus;
totalAmount: number;
createdAt: string;
};
userIdをnullにできるようにしておくと、ゲスト購入にも対応できます。
userIdあり：
会員購入
userIdなし：
ゲスト購入
注文履歴で表示する情報は、次の通りです。
・注文番号
・注文日
・注文ステータス
・商品名
・合計金額
・配送ステータス
・再購入ボタン
マイページの注文履歴イメージです。
注文履歴
ORDER-0005
2026年7月6日
クラシック節ギフトセット
5,400円
発送済み
[詳細を見る]
[もう一度購入する]
注文履歴で大切なのは、過去の注文内容を後から確認できることです。
何を買ったか
いつ買ったか
いくらだったか
発送されたか
ただし、個人情報を必要以上に表示しないようにします。
特に、共有端末でログインしたままになる可能性もあります。
表示してよい：
注文番号
商品名
金額
配送状況
注意する：
住所
電話番号
詳細な個人情報
注文履歴は便利ですが、個人情報の表示範囲には注意します。
25.5 マイページ
マイページは、会員がログイン後に使う個人用ページです。
マイページの役割は、購入者が自分の注文や登録情報を確認できることです。
ログイン
↓
マイページ
↓
注文履歴
↓
住所管理
↓
再購入
最初に作るマイページは、シンプルで十分です。
・注文履歴
・登録情報
・配送先住所
・ログアウト
マイページの画面構成例です。
マイページ
山田 太郎 様
[注文履歴を見る]
[配送先住所を管理する]
[登録情報を変更する]
[ログアウト]
注文履歴ページです。
注文履歴
2026年7月6日
ORDER-0001
クラシック節ギフトセット
5,400円
発送済み
[詳細を見る]
[もう一度購入する]
マイページで注意すべきなのは、会員本人のデータだけを表示することです。
ログイン中ユーザーID
↓
そのユーザーの注文だけ取得
↓
表示
サーバー側でも確認します。
危険な設計：
URLのorderIdだけで注文詳細を表示
安全な設計：
orderIdに加えて、ログイン中のuserIdと一致するか確認
マイページは、便利さと安全性の両方が必要です。
購入者にとって便利でも、他人の注文が見える設計は絶対に避けます。
25.6 再購入ボタン
会員機能を入れる大きなメリットのひとつが、再購入ボタンです。
再購入ボタンとは、過去に買った商品をもう一度購入しやすくするボタンです。
注文履歴
↓
以前買った商品
↓
[もう一度購入する]
食品、日用品、消耗品では特に効果があります。
・だし
・お茶
・コーヒー
・調味料
・化粧品
・消耗品
再購入ボタンの流れは、次のようになります。
注文履歴を見る
↓
再購入ボタンを押す
↓
現在の商品情報を確認
↓
カートに追加
↓
決済へ進む
ここで注意すべきなのは、過去の価格や在庫をそのまま使わないことです。
過去の購入価格：
5,400円
現在価格：
6,000円
再購入時：
現在価格で計算する
再購入ボタンでは、現在の商品状態を確認します。
・商品が公開中か
・現在の価格はいくらか
・在庫があるか
・販売終了していないか
販売終了している場合は、関連商品へ案内します。
こちらの商品は現在販売終了しています。
同じ用途の商品はこちらからご覧いただけます。
再購入ボタンの考え方です。
過去の注文をコピーする
ではなく
過去に買った商品を、現在の条件で買いやすくする
これが安全です。
25.7 住所保存
会員機能を入れると、配送先住所を保存できます。
住所保存は、リピート購入を楽にする機能です。
初回購入：
住所を入力
2回目以降：
保存済み住所を選ぶ
住所保存で必要な項目は、次の通りです。
・氏名
・郵便番号
・都道府県
・市区町村
・番地
・建物名
・電話番号
・住所名
住所名とは、購入者が分かりやすく管理するための名前です。
自宅
会社
実家
ギフト用
住所テーブルの型イメージです。
type Address = {
id: string;
userId: string;
label: string;
recipientName: string;
postalCode: string;
prefecture: string;
city: string;
addressLine1: string;
addressLine2: string | null;
phoneNumber: string;
createdAt: string;
};
住所保存では、必ずログイン中のユーザーIDと紐づけます。
address.userId
=
ログイン中のuserId
他人の住所が見えないように、RLSやサーバー側チェックを入れます。
山田さん：
山田さんの住所だけ見える
佐藤さん：
佐藤さんの住所だけ見える
住所保存は便利ですが、個人情報の扱いが増えます。
そのため、最初から必ず必要とは限りません。
リピート購入が少ない：
住所保存なしでもよい
リピート購入が多い：
住所保存が便利
住所保存を入れるなら、削除機能も用意します。
住所を登録できる
住所を編集できる
住所を削除できる
保存できる情報は、消せるようにする。
これが基本です。
25.8 セキュリティと個人情報
会員機能を入れると、セキュリティの重要度が上がります。
なぜなら、ログイン情報と個人情報を扱うからです。
・メールアドレス
・パスワード認証
・注文履歴
・配送先住所
・電話番号
まず大切なのは、パスワードを自前で保存しないことです。
Supabase Authなどの認証基盤を使う場合、パスワード管理は認証基盤側に任せます。Supabase Authは、パスワードベース認証を安全に実装するための設定やベストプラクティスを提供しています。(
)
自社DBに次のような情報を保存してはいけません。
・平文パスワード
・パスワード確認用文字列
・認証Token
・セッションCookieの中身
Supabaseを使う場合でも、DB側のRLSが重要です。
Supabaseの公式ドキュメントでは、フロントエンドからData APIを使う場合、RLSを有効にし、適切なポリシーで最小権限にすることが推奨されています。(
)
会員機能で守るべきことは、次の通りです。
・自分の注文だけ見える
・自分の住所だけ見える
・他人のデータをURL変更で見られない
・管理者以外は全注文を見られない
・秘密情報をログに出さない
個人情報は、必要最小限にします。
必要：
配送に必要な住所
連絡に必要なメールアドレス
不要なことが多い：
生年月日
性別
職業
家族構成
また、会員情報の表示にも注意します。
マイページで住所を表示する場合：
必要な範囲で表示
管理画面で表示する場合：
権限がある人だけ表示
会員機能は便利ですが、持つ情報が増えるほど守る責任も増えます。
便利さ
＋
安全性
この両方を設計します。
25.9 退会処理
会員機能を入れるなら、退会処理も考えます。
退会とは、ユーザーが会員登録をやめることです。
会員登録
↓
利用
↓
退会
退会処理で難しいのは、注文履歴を完全に消してよいとは限らないことです。
ECでは、会計、配送、問い合わせ対応のために、注文記録が必要になる場合があります。
そのため、退会時には次のように分けて考えます。
ログインアカウント：
無効化または削除
注文履歴：
法務・会計・問い合わせ対応に必要な範囲で保持
住所情報：
不要なら削除または匿名化
退会処理の基本フローです。
退会申請
↓
注意事項を表示
↓
本人確認
↓
保存住所を削除
↓
会員プロフィールを無効化
↓
Authユーザーを削除または無効化
↓
退会完了
退会前には、購入者へ注意事項を表示します。
退会すると、マイページにログインできなくなります。
注文履歴の閲覧や保存住所の利用はできなくなります。
未発送の注文がある場合は、発送完了後に退会処理を行ってください。
未発送の注文がある場合は、退会を止めるか、管理者確認に回します。
未発送注文あり
↓
退会を一時停止
↓
発送完了後に退会
退会処理で避けたいのは、関連データを何も考えずに削除することです。
危険：
ユーザー削除
↓
注文履歴との紐づきが壊れる
↓
問い合わせ対応できない
安全な方法は、注文履歴は残しつつ、会員情報や住所情報を整理することです。
注文履歴：
必要な範囲で保持
会員プロフィール：
退会済みにする
保存住所：
削除または匿名化
退会処理は、会員機能の出口です。
入口を作るなら、出口も必ず用意します。
25.10 会員機能を入れない選択肢
最後に、会員機能を入れない選択肢も整理します。
本格ECというと、会員機能が必須に見えます。
しかし、小規模ECでは、会員機能なしでも十分に運用できます。
商品を見る
↓
ゲスト購入
↓
メールで注文確認
↓
LINEで再接点
↓
リピート購入
会員機能なしで使える導線は、次の通りです。
・ゲスト購入
・注文完了メール
・発送完了メール
・LINE登録
・Waiting List
・再入荷通知
・メールマガジン
・SNS導線
会員機能なしのメリットです。
・購入までが早い
・実装がシンプル
・個人情報管理が軽くなる
・ログイン関連の問い合わせが減る
・初回購入のハードルが下がる
一方で、できないこともあります。
・マイページ
・注文履歴表示
・住所保存
・再購入ボタン
・会員限定価格
・ポイント制度
小規模ECの初期段階では、会員機能なしで始めるのも十分に合理的です。
最初：
ゲスト購入だけ
次：
LINE登録、Waiting List
その後：
必要なら会員機能
会員機能を入れない場合でも、注文DBにはメールアドレスや注文履歴を残せます。
ただし、ログインして閲覧するマイページはありません。
購入者：
メールで注文内容を確認
店舗：
管理画面で注文を確認
会員機能なしでも、購入後の関係づくりはできます。
注文完了メール
↓
LINE登録
↓
再入荷案内
↓
季節商品案内
↓
リピート購入
会員機能は、便利な道具です。
しかし、必須ではありません。
ECの目的、商品特性、リピート頻度、運用体制に合わせて判断します。
第25章のまとめ
会員機能は、リピート購入や注文履歴、住所保存に役立つ便利な機能です。
しかし、最初から必ず入れる必要はありません。
購入者にとっては、会員登録が手間になることもあります。
この章で覚えておきたいポイントは、次の通りです。
1. 会員機能は便利だが、購入までのハードルにもなる
2. 初期ECではゲスト購入だけで始める選択肢もある
3. ゲスト購入と会員購入は併用できる
4. Supabase Authを使う場合は、Auth、profiles、ordersを分けて設計する
5. RLSで自分の注文や住所だけ見えるようにする
6. マイページでは注文履歴、住所管理、再購入を提供できる
7. 再購入ボタンでは、過去価格ではなく現在価格を使う
8. 住所保存は便利だが、個人情報管理が増える
9. 会員登録を作るなら退会処理も用意する
10. 会員機能を入れない設計も、小規模ECでは十分に現実的である
会員機能の判断は、次の一言にまとめられます。
会員機能は、売るための入口ではなく、続けて買ってもらうための仕組み。
初回購入を邪魔しない。
リピート購入を楽にする。
このバランスを取ることが大切です。
第26章では、リピート購入をさらに強化するために、定期購入・サブスクリプションの設計を学んでいきます。