ユーザー / メールアドレス変更

本ページは 2 段構成。上段が biz/CS 向け（ユーザー提示可）、下段（## 🔧 実装詳細 以降）が dev 向け。biz/CS がユーザーへ提示・転用してよいのは上段のみ。

概要

ログイン中のユーザーが自分のメールアドレスを変更する機能。Fincs からのメール通知（配信メール・認証メール・通知メール 等）の届け先を最新に保つために使用。

主な仕様:

• mypage > メールアドレス画面から、現アドレスを確認 → 新アドレスを入力 → 即時更新
• 入力後の確認メール送信や旧アドレスへの通知は現状なし（認証なしの即時変更）
• 既に他ユーザーで使われているメールアドレスへの変更はエラー（重複防止）
• 変更後もログインセッションは維持される（再ログイン不要）

主な使い方:

• 受講者: アカウントのメールアドレス変更
• 講師（メイン講師）: mypage の「メールアドレス」メニューは表示されないことがある（運用設計次第）
• 運営アドミン: 個別ユーザーのメールアドレスの削除経路はあるが、運営側からの直接変更経路はなし。CS で「他のユーザーに使われているアドレスに変更したい」場合は、運営が削除して本人に再登録を依頼する運用となる

📝 レビュー観点（draft 段階の記述ヒント、完成時に削除）:

• 目的: ユーザーがメールアドレスを変更する経路。Fincs からのメール通知の届け先を更新する
• 誰が使うか: 受講者・講師（受講者以上）
• どこで使うか: mypage > メールアドレス
• 隣接機能との関係: 認証（./auth.md） / メール受信設定（./mail-preferences.md） — 本ページはアドレスそのものの変更に絞る
• CS 問い合わせで頻発する論点: 「メール変更したのに旧アドレスに届く」「変更後ログインに使う email はどっち」
• [本機能特有] 認証なしの即時変更: 旧アドレスへの確認 / 新アドレスへの認証メールは実装上存在するが 現行 FE は認証なし即時変更の一択。認証付きフロー（/user/update_email_auth）は BE に残るが FE から呼ばれていない（デッドコード化の可能性、要 dev 確認）
• [本機能特有] 変更後のセッション: メール変更時にセッション無効化・再ログインは発生しない

利用シナリオ

シナリオ 1: メールアドレスを変更する

ユーザーが mypage > メールアドレス画面を開くと現在のアドレスが表示される。新しいアドレスを入力して保存すると即時に新アドレスへ切り替わる。確認メール等は送信されず、ログインセッションは維持される。

シナリオ 2: 重複したアドレスへの変更を試みる

既に別のユーザーで使用されているメールアドレスへ変更しようとするとエラー表示。CS で「先に他のユーザーが使っているアドレスを使いたい」相談時、運営アドミンによる旧側のアドレス削除を経て本人で再登録する運用。

シナリオ 3: メール形式エラー

メール形式に合わない文字列を入力するとフォームバリデーションでエラー表示。形式が正しくないと送信できない。

よくある失敗ケース

• 「変更したのに旧アドレスにメールが届く」: 変更前に既に送信された配信メールは旧アドレスに届く（送信時点のアドレスが対象のため）。変更後の新規配信メールは新アドレスに届く
• 「ログインに使う email はどっち」: 変更後は 新アドレス がログインに使うアドレスになる
• 「再認証メールは届くか」: 現状の変更フローでは確認メールは送信されない（即時変更）

📝 レビュー観点:

• 受講者がメールアドレスを変更する典型例
• 既に他ユーザーが使っている email への変更（重複エラー時の挙動）
• メール変更後にログインで使う email がどちらになるかの確認

権限別仕様

権限定義は ../user-roles.md 参照。用語は ../terminology.md。

講座権限軸

メールアドレス変更は講座スコープ外のため、講座権限軸の差分はなし。

横断軸

操作	運営アドミン	テストユーザー	投稿禁止
自身のメールアドレス変更	（通常と同じ）	（通常と同じ）	（通常と同じ）
メールアドレスの運営アドミン削除	○（メール削除のみ、変更は不可）	×	×

📝 レビュー観点:

• 運営アドミンは 削除のみ可能（変更経路はない）。CS で「他のユーザーに使われている email に変更したい」場合は、まず削除してもらってから本人で変更する流れ
• mypage > メールアドレスの項目は オーナー以外にしか出ない（要確認）

機能詳細（ふるまい）

メールアドレス変更フロー（現行）

mypage > 「メールアドレス」画面を開くと:

1. 現アドレスが表示される（編集不可、確認用）
2. 新しいアドレスを入力（メール形式バリデーション + 100 文字以内）
3. 保存ボタン押下で即時に変更が確定。サーバー側の重複チェックで新アドレスが他ユーザーで使われていないことを確認した上で更新する
4. 変更後は新アドレスがログイン時の認証アドレスになる

確認メール・旧アドレスへの通知メールは送信されない（認証なしの即時更新方式）。

バリデーション

• 新アドレスは現アドレスと異なること
• メール形式（loginEmailRules）
• 100 文字以内
• 重複チェック（既登録 email との衝突）

変更後の挙動

• ログインセッションは維持される（再ログインは不要）
• 次回 mypage 取得で新メールが反映される

📝 レビュー観点:

• 入力 → 処理 → 出力: 即時更新で同期処理
• エラー表示: 重複時のメッセージ、形式不正時のメッセージ
• 編集・削除の挙動: 変更後の通知は発火しない（旧アドレスへの確認メールは送られない）
• [本機能特有] 認証付きフロー（旧実装）: BE に残る認証コード付き 2 段階フロー（/user/update_email → 認証コード入力 → /user/update_email_auth）の現役性確認

admin 操作

できる操作

• メールアドレスの削除（null 化）: DELETE /admin_master/user/{user_id}/email、運営アドミンが削除する場合の用途は CS 対応（他ユーザーに使われた email の解放等）

実装されていない

• 運営アドミンによるメールアドレスの直接変更: 専用操作経路なし。削除して本人に再登録してもらう運用 — 今後の改善課題（必要性があれば）

📝 レビュー観点:

• メール削除と退会の関係（./account-lifecycle.md と整合）
• 削除後のユーザーがログイン経路を失わないか（パスワード認証も同時に無効化されるか）

品質 / 約束事項

• 応答性: 変更は同期処理で即時反映
• 信頼性: 変更失敗時はバリデーションエラーで明示
• 制限値:
  • メールアドレス: 100 文字以内（FE）
• データ保持: 旧アドレスは保持されず、新アドレスで上書き

📝 レビュー観点:

• 応答性: 即時反映、他デバイス・他タブの同期挙動
• [本機能特有] 旧アドレスへの通知の有無: 現行は旧アドレスへの確認メールなし。セキュリティ観点で要件を整理する余地

変更履歴（リリースノート候補）

v2.29.2: 2026-05-01（PSD 初版）

• [PSD 追加] 本ドキュメント初版作成。v2.29.2 時点の実装を起こし。機能追加・変更は含まない

📝 レビュー観点:

• 認証付きフロー → 認証なしフロー への切替の経緯があれば追記候補

関連ドキュメント

• 権限定義: ../user-roles.md
• 用語辞書: ../terminology.md
• 関連 PSD:
  • ./auth.md — 認証
  • ./mail-preferences.md — メール受信設定
  • ./account-lifecycle.md — アカウントライフサイクル

---