ユーザー / アカウントライフサイクル
ユーザー / アカウントライフサイクル
本ページは 2 段構成。上段が biz/CS 向け(ユーザー提示可)、下段(
## 🔧 実装詳細以降)が dev 向け。biz/CS がユーザーへ提示・転用してよいのは上段のみ。
概要
ユーザーアカウント全体(プラットフォーム単位)のライフサイクル管理を扱うページ。離脱・凍結・データ削除等の状態遷移を整理する。
重要: 現時点で全プラットフォーム退会機能は提供していない。CS で「Fincs を退会したい」相談を受けた場合、現状の運用では:
- 個別講座ごとの退会(
../plan/cancel.md)を全講座について実施することで、実質的に「全ての契約を持たない状態」になる - ただしユーザー登録自体は残る(
usersレコードは保持される) - 完全削除や法定の右忘却対応は現時点で未実装
その他、本ページが扱う関連状態:
- 自動ロック: パスワード認証で連続失敗するとアカウントが一時的にロックされる仕組み
- 投稿禁止フラグ: 運営アドミンが個別ユーザーに対して設定し、トーク投稿を入口で弾く
- メールアドレス無効化(運営側): 運営アドミンがユーザーのメールアドレスを削除すると、そのユーザーはログイン不可となる(実質的なアカウント無効化手段)
退会・凍結・削除のいずれも構造的には未整備で、CS 連携で発生する典型的な要望(「アカウントを完全に消したい」「個人情報を消去してほしい」)には現状応えられない。今後の改善課題として記録。
📝 レビュー観点(draft 段階の記述ヒント、完成時に削除):
- 目的: ユーザーが Fincs プラットフォーム自体から離脱する経路、およびシステムによる凍結・自動ロック挙動
- 誰が使うか: 受講者・講師(離脱)、運営アドミン(凍結対応)、システム(自動ロック)
- どこで使うか: 全体退会画面は実装不在。個別講座退会は別(
../plan/cancel.md)- 隣接機能との関係: 個別講座退会(
../plan/cancel.md)/ セッション管理(../platform/session.md)/ 運営アドミンによる強制凍結・データ削除(../admin/user.md)- CS 問い合わせで頻発する論点: 「退会したい」「アカウントロックされた」「個人情報を消してほしい」「再登録できない」
- [本機能特有] 重要: 全プラットフォーム退会機能は実装不在:
users.delete_flagカラムは存在するが、書き込みするコードパスが application 内に 存在しない。CS で「退会したい」相談時、現状は「個別講座を全部退会する」運用しかない。biz 上段では「現状サービス全体からの退会機能は提供していない」旨を明記する判断- [本機能特有] 自動ロック: パスワード認証失敗時に発動する時間ベースの一時ロック
- [本機能特有] 投稿禁止フラグ: 運営アドミンが操作する
is_post_prohibited、トーク投稿の入口で弾く
利用シナリオ
シナリオ 1: 「Fincs を退会したい」CS 相談
ユーザーが CS に「Fincs プラットフォーム自体を退会したい」と問い合わせ。CS は現状「全プラットフォーム退会機能は提供していない」旨を案内し、代わりに:
- 個別講座をすべて退会する(
../plan/cancel.md) - 配信メールが不要なら受信拒否設定(
./mail-preferences.md)
を案内する。users レコードは残るが、契約・配信メール経路は実質的に止まる。
シナリオ 2: パスワード認証失敗で自動ロック
ユーザーがパスワードを忘れて何度も入力し連続で失敗すると、アカウントが一定時間ロックされる。ロック中は正しいパスワードでもログインできない(時間経過で自動解除)。CS で「ログインできない」相談時、まず自動ロック中でないかを確認する。
シナリオ 3: 運営アドミンが投稿禁止フラグを設定
不適切な投稿を繰り返すユーザーに対し、運営アドミンが投稿禁止フラグを設定。以降、そのユーザーはトーク投稿の入口で弾かれる(既存投稿の閲覧やプロフィール編集等には影響しない)。
シナリオ 4: メールアドレス無効化(実質的な無効化)
運営アドミンが個別ユーザーのメールアドレスを削除すると、そのユーザーはログイン不可になる(メールアドレスは認証の起点のため)。同一メールアドレスで別の新規ユーザーを作ることも可能になるが、旧ユーザー ID 配下のデータは引き継がれず残置される。
よくある失敗ケース
- 「アカウント完全に消してほしい」: 現状未実装。法務観点で必要な場面では別途運用対応
- 「再登録したら過去のデータが見えない」: 旧アカウントを無効化した後、同じメールアドレスで再登録すると別ユーザー扱いになり、過去の契約・履歴は引き継がれない
- アカウントロック中にログイン試行: 一定時間が経つまでは自動解除されない
📝 レビュー観点:
- 「退会したい」CS 問い合わせのフロー(個別講座退会で代替)
- パスワード認証失敗による自動ロックの典型例
- 運営アドミンが投稿禁止フラグを設定する例
権限別仕様
権限定義は ../user-roles.md 参照。用語は ../terminology.md。
講座権限軸
全体ライフサイクルは講座スコープ外のため、講座権限軸の差分はなし。
横断軸
| 操作 | 運営アドミン | テストユーザー | 投稿禁止 |
|---|---|---|---|
| 全プラットフォーム退会 | 実装不在 | 実装不在 | 実装不在 |
| 個別講座退会(参考、別 PSD) | ○(../plan/cancel.md) |
○ | ○ |
| 自動ロック(パスワード失敗時) | (適用される) | (適用される) | (適用される) |
| 投稿禁止フラグ設定 | ○(運営アドミンが他ユーザーに対して操作) | × | × |
| 運営アドミンによる強制凍結 | 実装不在(内部削除フラグの書き込み経路が未実装) | 実装不在 | 実装不在 |
| メールアドレス削除(実質的なロック) | ○(運営アドミンが email を null 化、ログイン不可化) | × | × |
📝 レビュー観点:
- 全体退会・凍結・削除のいずれも実装不在の旨を biz 上段で明示
- 投稿禁止フラグはトーク投稿の入口で弾くだけで、閲覧・他機能には影響しない(
../talk/post.mdの権限別仕様と整合)- メール削除がほぼ唯一の運営アドミンによる「アカウント無効化」手段
機能詳細(ふるまい)
全プラットフォーム退会(実装不在)
- 個別講座退会は
../plan/cancel.mdで対応 - プラットフォーム全体からの退会経路は 現状提供していない
- ユーザーが Fincs 自体を離脱したい場合、個別講座をすべて退会する ことで実質的に近い状態になるが、
usersレコードは残存
自動ロック(パスワード認証失敗時)
パスワード認証で連続失敗するとアカウントが一定時間ロックされる仕組み:
- 失敗回数の閾値・ロック時間は運用設定値で管理
- ロック中は正しいパスワードを入力してもログインできない
- 一定時間経過後に自動解除される(ユーザー操作不要)
- ロックの目的は不正アクセス(総当たり攻撃)の抑止
投稿禁止フラグ
運営アドミンが個別ユーザーに対して設定するフラグで、設定すると:
- そのユーザーはトークルームへの新規投稿が入口で弾かれる
- 既存投稿の閲覧・他機能(リアクション・ブックマーク・プロフィール編集等)には影響しない
- 不適切な投稿を繰り返すユーザーへの運用対応として利用される
- フラグの ON / OFF は運営アドミン側で操作(
../admin/user.md参照)
メールアドレス無効化(運営アドミン操作)
運営アドミンが個別ユーザーのメールアドレスを削除する経路がある(実質的なアカウント無効化手段):
- ユーザーのメールアドレス情報を削除すると、そのユーザーはログインできなくなる
- 削除されたメールアドレスは「使用中」扱いから外れるため、同じメールアドレスで新規ユーザーを別途作成可能になる
- 旧ユーザー ID 配下のデータ(契約・トークルーム所属・支払履歴等)は引き継がれず残置される
- 完全削除ではないため、必要時には運営側で旧ユーザーのデータを参照可能
📝 レビュー観点:
- 入力 → 処理 → 出力: 各操作の挙動
- エッジケース: メール null 化後の再登録挙動(同 email で新規ユーザーを作れる、旧データは旧 user_id 紐付けで残る)
- [本機能特有] 「退会済みユーザー」状態の不在: フラグでも論理削除でも管理されていない、新規退会フロー実装時の方針確定が必要
admin 操作
できる操作
- メールアドレス削除:
DELETE /admin_master/user/{user_id}/email、users.emailを null 化(DeleteUserEmailUseCase) - 投稿禁止フラグ設定:
PUT/DELETE /admin_master/post_prohibited/{user_id}、トーク投稿の入口で弾く - 権限変更:
PUT /admin_master/change_role/{owner|user}/{user_id}、メイン講師付与・受講者降格 - テストユーザーフラグ:
PUT/DELETE /admin_master/test_user/{user_id} - userId 変更:
PUT /admin_master/change_user_id/{user_id}
詳細は ../admin/user.md 参照。
実装されていない
- 全プラットフォーム退会: 実装不在 — 重要な未実装機能(
../admin/user.mdと整合) - アカウント全体凍結:
users.delete_flagの書き込みパスが application 内に不在、UI も不在 — 今後の改善課題 - データ削除(GDPR 右忘却対応): 実装不在、retention バッチも不在 — 今後の改善課題
📝 レビュー観点:
- 法務・コンプライアンス観点で全体退会機能の必要性を確認(
../platform/compliance.mdと整合)- 「退会済み」状態をどう表現するかの方針(フラグ追加 / 論理削除 / 物理削除)
品質 / 約束事項
- 応答性: 個別講座退会は同期処理(
../plan/cancel.md参照) - 信頼性: 自動ロックは時間経過で自動解除されるため、CS が手動解除する必要はない(運用上もロック解除の手段は限定的)。投稿禁止フラグの設定・解除は運営アドミン側のみで実行可能
- 制限値:
- 自動ロックの失敗許容回数・ロック時間: 運用設定(具体値は社内基準で管理)
- データ保持: 退会時のデータ保持ポリシーは未確立(個別講座退会後も
usersレコードは残存)。法務要件(個人情報保護・金融商品関連の保管義務)と合わせた整理は今後の課題
📝 レビュー観点:
- 全体退会機能を提供する場合のデータ保持期間・物理削除タイミング
- 法定保管義務(金融商品・個人情報)との整合
- 再登録時の旧データの取り扱い方針
変更履歴(リリースノート候補)
v2.29.2: 2026-05-01(PSD 初版)
- [PSD 追加] 本ドキュメント初版作成。v2.29.2 時点の実装を起こし。全プラットフォーム退会機能は実装不在の旨を明記
📝 レビュー観点:
- 過去の主要変更(自動ロック追加 / 投稿禁止フラグ追加 等)があれば追記候補
関連ドキュメント
- 権限定義:
../user-roles.md - 用語辞書:
../terminology.md - 関連 PSD:
./auth.md— 認証(自動ロックの起点)./email-management.md— メールアドレス変更../plan/cancel.md— 個別講座退会../platform/session.md— セッション制御../platform/compliance.md— コンプライアンス(GDPR 等)../admin/user.md— 運営アドミンによるユーザー管理