申込時パスワード登録パターン

例：イベント申込・資料請求システム

一般ユーザーがWebサイトからイベントに申し込む、または資料を請求する。

適用する原則: 登録はその場で行う、状態と操作を分離する

要件

• 初めて利用するユーザーが多い
• 申込後にマイページで履歴を確認したい
• 次回以降もログインして利用できるようにしたい

---

典型

典型パターン：申込フォームにパスワード欄 別タブで開く ↗

GET    /events/:id/apply              メールアドレス入力
POST   /events/:id/apply/send-link    認証リンク送信
GET    /events/:id/apply?token=xxx    申込フォーム（パスワード欄含む）
POST   /events/:id/apply              申込実行（アカウント作成 + 申込登録）
GET    /events/:id/apply/complete     完了画面

起きる問題

• 設計上の矛盾: メールリンクで認証済みなのに、さらにパスワードを求める
• 関心事が混在: 「申し込み」と「アカウント作成」が1つのフォームに
• バリデーションエラーが増える: 文字数・確認入力・強度チェックなど失敗しやすい
• パスワード疲れ: 利用頻度が低いのに、また1つパスワードが増える

---

再設計

再設計パターン：パスワード不要で申込 別タブで開く ↗

GET    /events/:id/apply              メールアドレス入力
POST   /events/:id/apply/send-link    認証リンク送信
GET    /events/:id/apply?token=xxx    申込フォーム（トークン検証後）
POST   /events/:id/apply              申込実行
GET    /events/:id/apply/complete     完了画面

POST   /account/set-password          パスワード設定（任意・別導線）

設計のポイント

• 認証はメールリンク: 典型と同じ方式（ここまでは共通）
• パスワードを申込から分離: 認証済みなのにパスワードを求めない
• パスワードは任意: password_hash が NULL でも利用可能
• 申込フォームがシンプルに: 本当に必要な項目だけ

---

比較

観点	典型	再設計
認証方法	メールリンク（共通）	メールリンク（共通）
フォーム項目	申込 + パスワード	申込のみ
パスワード	必須	任意（後から設定可）
バリデーションエラー	起きやすい	減る
次回ログイン	パスワード入力	メールリンク or パスワード

---

補足

パスワードレスの選択肢

方式	特徴
メールリンク	ログインリンクを送信
SMS認証	認証コードを送信
OAuth	Google等の既存アカウント
Passkey	生体認証・デバイス認証

利用頻度が低いサービスほど、パスワードレスが有効。