ランダム短歌 — メールログイン & メルマガ(設計)¶
- ステータス: 設計のみ(実装は別ブランチ
cursor/email-auth-newsletter-eae0想定) - 前提: ログインなしでも今までどおり遊べる
- 関連:
random-tanka-smtp.md(SMTP 設定済みが前提)
なぜ別フェーズか¶
| いま(Phase 1) | 次(Phase 2) |
|---|---|
| ルーム単位の任意メール | アカウントに紐づく通知 |
| 端末 localStorage でアドレス記憶 | 端末をまたいで同じ履歴 |
| 合成時に1通 | メルマガ + 自分の短歌一覧 |
ログイン・履歴・分析は DB スキーマとセッションが要るので、ゲーム本体 PR とは分けるのが安全。
コンセプト¶
- 遊ぶ — 今と同じ(ニックネームだけで参加)
- 任意でメール登録 — マジックリンクで「本人確認」
- ログイン後 — 参加したルーム・できた短歌を横断で見る(同日分から)
- メルマガ — プロダクト便(新機能・お題)+ 自分が参加したルームの合成通知
UX 案¶
未ログイン¶
- ホームに「メールでログイン(任意)」
- ルーム内「結果をメールで受け取る」— 現状どおり(localStorage で次ルームにも引き継ぎ済み)
ログイン¶
- メール入力 → 6桁コード or リンク → セッション Cookie
- 「自分の短歌」画面: 今日 / 7日 / 全部(ルーム TTL に合わせる)
- 新ルーム参加時、ログイン済みなら メール通知を自動 ON(上書き確認なしでよいか要確認)
メルマガ¶
| 種類 | 既定 | 内容 |
|---|---|---|
| 参加ルーム通知 | ON(ログイン時) | 合成・再合成(今の mail.ts と同等) |
| お知らせ便 | OFF | 新モード・メンテ(月1〜程度) |
データ設計(案)¶
CREATE TABLE users (
id TEXT PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
created_at TEXT NOT NULL,
newsletter_product INTEGER NOT NULL DEFAULT 0
);
CREATE TABLE auth_tokens (
token_hash TEXT PRIMARY KEY,
user_id TEXT NOT NULL,
expires_at TEXT NOT NULL
);
-- participants に追加
user_id TEXT NULL REFERENCES users(id)
-- 合成通知用(ルーム参加と独立)
CREATE TABLE room_subscriptions (
user_id TEXT NOT NULL,
room_id TEXT NOT NULL,
notify INTEGER NOT NULL DEFAULT 1,
PRIMARY KEY (user_id, room_id)
);
フロー:
- ログイン後
participants.user_idを紐付け(参加時 or 後から) - 合成時:
participants.emailまたはusers.email(ログイン済み)へ送信 - 「同日の句を一覧」:
users.id→participants→rooms.tanka_json(composed のみ)
認証¶
- マジックリンク(おすすめ):
POST /api/auth/request-link→ メール →GET /api/auth/verify?token= - セッション: HttpOnly Cookie +
SESSION_SECRET(webapp と同パターン) - パスワードなし(短歌パーティ向け)
将来(Phase 3)— 言葉分析¶
- ログインユーザーの
phrase_pool/ 参加カードから「よく使う音・語尾」 - プライバシー: 本人のみ閲覧、匿名 pool とは分離
- 実装重いので Phase 3
実装順(提案)¶
-
users+ マジックリンク + Cookie - 参加時
user_id紐付け + 合成メールを user email に - 「自分の短歌」一覧ページ(今日 / 7日)
- メルマガ opt-in / 管理用 send(手動 or Cron)
- 言葉分析(将来)
ブランチ方針¶
| ブランチ | 内容 |
|---|---|
cursor/async-mode-mvp-eae0 |
非同期・退室・ルームメール |
cursor/vercel-smtp-setup-eae0 |
Vercel env・SMTP ドキュメント |
cursor/email-auth-newsletter-eae0 |
上記 Phase 2 実装 |
結論: ログイン・メルマガ横断は 膨らんでいるので別ブランチが正解。SMTP とルーム通知だけ先に本番へ。