はじめに
「サービスをリリースしたけど、最初の登録フォームで離脱率が高い…」
「ユーザーに価値が伝わる前に、確認メールのステップで諦められてしまう…」
こうした“初回体験の壁”を越える打ち手としての ゲストログイン。
そのための要所をまとめたメモです。
1. なぜゲストログインか
理由は単純で、価値が見える前に離脱されないために。
まず触ってもらい、雰囲気と初期価値を体験してもらう。そこで「データを保存したい」「続きをやりたい」という自然な本登録への動機を生みます。
2. 設計の三原則
-
1クリックで開始
押した瞬間に体験が始まること。 -
権限は薄く（乱用されない）
読み取り中心。CSVや画像/動画など重量級APIは不許可。 -
本登録へ1アクション昇格（データはそのまま）
同一user.idのままrole: guest → memberに切替える設計を推奨。
3. 最小設計セット
3.1 入口：APIとトークン発行
POST /api/auth/guest_login
HTTP/1.1 201 Created
Authorization: Bearer <JWT>
Content-Type: application/json
{
"message": "Guest user created successfully",
"user_id": "guest_uuid_12345"
}
3.2 JWT の運用
-
発行：アプリ側のエンコーダで JWT を生成（例：
Warden::JWTAuth::UserEncoder相当） - 寿命：短寿命（数十分〜数日）。ポリシーに合わせて設定（現状運用が長めでもOK）
- 更新：リフレッシュなし（期限切れ→再ログイン or 本登録へ）
-
判定：DBのロール（
role: "guest"）を正とする
（任意）JWT ペイロードにscope/scp: "guest"を付与し、ゲートで早期判定できると運用が楽
3.3 ユーザーモデルと権限
-
ロール管理：
roleをguest | memberの2値で持つ -
許可方式（現実解）：まずは ルートのホワイトリスト（guest が通ってよいAPIのみ許可）
（任意）バックエンドの認可ポリシーでも拒否して二重化
4. セキュリティ：最低限の脅威対策
-
大量作成（枯渇）
→/api/auth/guest_loginに IP × ルート単位の強いレート制限（任意でデバイス指紋併用） -
権限昇格の穴
→ ルートはホワイトリスト。重量級APIは明示的に403（任意でポリシー二重化） -
トークン漏洩
→ 短寿命 + リフレッシュなし。必要に応じて JTI 失効（任意） -
データ汚染（スパム）
→ ゲストに PIIを持たせない／入力長・禁止語・サニタイズで衛生管理
5. 本登録へ
-
フロー：ゲスト利用中に「本登録」→ メール＋パスワード入力
（メール確認を挟む場合は202 Acceptedを返し、確認後に適用） -
最重要：新しい
user.idを作らず、同一IDでroleをmemberへ
技術的制約で難しい場合は、欠落しやすいデータ（下書き/お気に入り等）に対して移行ロジック＋テストを必ず用意
まとめ
ゲストログインは、価値体験までの最短距離をつくるための仕組み。
まずは入口API、JWT発行（短寿命・リフレッシュなし）、ロールでの判定を土台に、
重量級APIのガード → 昇格の同一ID設計 → レート制限強化の順で現実的に固めるのが良さげ