Fincs

ユーザー / 認証

ユーザー / 認証

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

概要

Fincs サービスの入口となる 認証機能。新規登録・ログイン・パスワード再設定・メールリンク式（パスワードレス）の 4 経路を提供する。

主な使い方:

  • 新規登録: 通常パスワード式 + メールリンク式の 2 経路。受講者・講師（招待制）の入口
  • 通常ログイン: メールアドレス + パスワード（または外部認証経由）でログイン
  • メールリンク式（パスワードレス）: メールに送信される 4 桁認証コードでログイン（パスワード不要）
  • パスワード再設定: パスワードを忘れた際の復旧経路（メール認証コード経由で 3 段階）
  • 運営アドミンログイン: 運営アドミンには専用のログイン入口があり、通常ユーザーと別経路

ログイン状態は内部的にアクセストークンとリフレッシュトークンの組み合わせで維持され、ユーザーは一定時間ログイン状態が継続する。複数デバイスでの並行利用も可能（それぞれ独立のセッション）。パスワード認証で連続失敗するとアカウントが一定時間ロックされ、誤入力 / 不正アクセスを防止する仕組みがある。

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

  • 目的: Fincs サービスの入口として、ユーザーがアカウントを作成 / ログイン / 復旧する経路を提供する
  • 誰が使うか: 受講者・講師・運営アドミン（運営アドミンは別経路）
  • どこで使うか: 入口の各画面（ログイン / 新規登録 / パスワード再設定 / メールリンク式）と、流入元（直接 URL / メールリンク / 招待リンク）
  • 隣接機能との関係: メールアドレス変更（./email-management.md） / メール受信設定（./mail-preferences.md） / セッション制御の運用基盤（../platform/session.md） と何が違うか
  • CS 問い合わせで頻発する論点: 「ログインできない」「登録メールが届かない」「アカウントロックされた」等の根拠
  • [本機能特有] パスワード認証 vs Firebase idToken: パスワードカラムは残るが Firebase idToken 経由が主軸。レガシーパスワードログインの実運用上の扱い（dev 確認事項）
  • [本機能特有] メールリンク式（パスワードレス）のフロー: メール一時登録 → 4 桁認証コード → 本登録、の 3 段階

利用シナリオ

シナリオ 1: 新規ユーザーの登録 → 初回ログイン

新規ユーザーが登録画面でメールアドレス・パスワードを入力して登録。本登録完了後、自動ログイン状態となりサービスを利用可能。後続の入会フロー（../plan/join.md）で講座契約に進む。

シナリオ 2: パスワードを忘れた

ユーザーが「パスワードを忘れた方」リンクからパスワード再設定画面へ。メールアドレスを入力 → 受信した 4 桁認証コードを入力 → 新パスワードを設定 → 再ログインで復旧完了。

シナリオ 3: メールリンク式ログイン

パスワードを覚えていないが頻繁な再設定もしたくないユーザーが「メールアドレスでログイン」を選択。メールアドレスを入力 → 受信した 4 桁認証コードを入力 → ログイン完了（パスワード不要）。

シナリオ 4: 運営アドミンログイン

運営アドミンは通常ユーザーとは別の専用ログイン入口を使用してログイン。運営側のツール群へアクセスする。

よくある失敗ケース

  • 登録メールが届かない: 迷惑メール扱い・受信拒否設定の影響で認証コードが届かないケース。CS で再送依頼や受信設定確認を案内
  • 認証コード入力失敗 3 回: パスワード認証の連続失敗でアカウントが一時ロック。一定時間後に自動解除
  • 既登録メールアドレスでの再登録試行: 同じメールアドレスで再登録しようとするとエラー。パスワード再設定経路への誘導
  • アカウントロック中のログイン試行: ロック解除前は認証成功してもログインさせない

📝 レビュー観点:

  • 最頻出のユーザーパターンを 3-5 ケース 用意（新規登録 / 通常ログイン / パスワード再設定 / メールリンク式 / 運営アドミンログイン）
  • 受講者・講師・運営の 異なる立場 を最低 1 つずつ
  • 失敗ケース・エッジケース を最低 1 つ含める（メール届かない / 認証コード入力失敗 3 回 / 既登録 email で再登録 等）
  • [本機能特有] 自動ロック挙動: パスワード認証失敗時に発動する一時ロック、解除タイミング

権限別仕様

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

認証は講座スコープに依らないため、横断軸が中心。

講座権限軸

講座権限軸の差分はほぼ無し（認証自体は講座と独立）。ただし新規登録時に講師として作成するか受講者として作成するかは経路が分かれる（要確認）。

横断軸

操作 運営アドミン テストユーザー 投稿禁止
通常ログイン （通常と同じ + 専用経路あり） （通常と同じ） （通常と同じ、認証自体は可）
新規登録 ×（運営アドミン経由で作成） ×（運営アドミン経由で作成） ×
パスワード再設定 ○ ○ ○
メールリンク式登録 × （通常と同じ） （通常と同じ）

📝 レビュー観点:

  • 講座権限軸の差分: 認証は講座スコープ外で影響薄。「登録できない条件」（既に email 登録済み等）が論点
  • 横断軸: 運営アドミンは専用ログイン経路を使う点が重要
  • [本機能特有] テストユーザーフラグ: 認証成功後のセッションへの影響（あれば記述）
  • 講師として登録する経路 と 受講者として登録する経路 の差分（講師は招待制？）

機能詳細（ふるまい）

新規登録

新規登録は 2 経路:

  • 通常登録（パスワード式）: メールアドレス・パスワードを設定して登録。同時に外部認証連携（Firebase）でも本人確認が完了
  • メールリンク式登録: パスワードを設定せず、メールアドレスのみで登録 → 4 桁認証コードで本人確認 → 本登録完了の 3 段階フロー

新規登録経路は受講者向けで、講師アカウントは運営アドミン側で別途作成される（../admin/owner.md 参照）。同じメールアドレスで既登録がある場合はエラー扱い。

ログイン

ログインは 3 経路:

  • 通常ログイン: メールアドレス + パスワードで認証
  • メールリンク式ログイン: メールアドレスのみ → 4 桁認証コードで本人確認
  • 運営アドミンログイン: 運営アドミン専用の入口（一般ユーザーとは経路を分離）

パスワード認証に連続失敗すると一時的にアカウントロックがかかり、ロック解除待ち時間の間はログインできない（解除待ち時間と失敗許容回数は運用設定）。ログイン成功時には履歴が記録される。

パスワード再設定

3 段階フロー:

  1. 認証コード送付申請: メールアドレスを入力すると 4 桁認証コードがメール送信される
  2. 認証コード検証: 受信した認証コードを画面に入力して本人確認
  3. 新パスワード設定: 新しいパスワードを設定して完了 → 以後新パスワードでログイン可

認証コードには有効期限があり（運用設定）、期限切れの場合は再送付が必要。

メールリンク式（パスワードレス）

3 段階フロー:

  1. メール一時登録（未ログイン状態）: メールアドレスを入力すると認証コードが送信される
  2. 認証コード検証: 認証コード入力で本人確認
  3. 本登録 / ログイン完了: パスワード不要で利用開始

新規登録だけでなく、既存ユーザーのログイン経路としても利用される。

セッション維持・自動更新

ログイン後のセッションは内部的にアクセストークン + リフレッシュトークンで管理:

  • 一定時間ごとにアクセストークンが自動更新される（ユーザー操作不要）
  • リフレッシュトークンの有効期限が来るとログアウト状態となり、再ログインが必要
  • 複数デバイスでの並行利用が可能（PC とスマホで同時ログイン等）。それぞれ独立したセッション

📝 レビュー観点:

  • メール認証コードの仕様: 4 桁数字、有効期限（mailAuthExpireMinutes）、最大失敗回数 3 回（要確認）
  • セッション: 内部的にアクセストークンとリフレッシュトークンを組み合わせ、期限切れ時に自動更新（biz 上は「ログイン状態が一定時間維持される」程度の表現で）
  • 自動ロック: 失敗回数（account_lock_count）に達したら一定時間（account_lock_time_minutes）ロック。具体値は biz/CS 向けに公開すべきか要判断
  • [本機能特有] パスワード認証のレガシー残存: Firebase 経由を主軸としつつ、内部にパスワード照合ロジックが残る。実運用上どちらが使われているか dev 確認事項

admin 操作

できる操作

  • 運営アドミン専用ログイン: 運営アドミンには通常ユーザーとは別の専用ログイン入口があり、ここから運営側のツール群へアクセスする
  • ユーザーの代理ログイン用情報の取得: CS 対応等で必要な場合、運営アドミンがユーザーアカウントへのアクセス情報を取得できる経路がある（用途・運用ルールは運営側で管理）

実装されていない / 不明

  • パスワードリセットの代行送付: 運営アドミン側からユーザーへのパスワードリセット指示を直接送る経路は未確認 — 要確認
  • アカウントロックの強制解除: ロック中ユーザーを運営側で強制解除する経路は未確認 — 要確認

📝 レビュー観点:

  • 運営アドミン専用ログイン経路の存在を明記（通常ユーザーとは別の入口）
  • ユーザーアクセストークン / リフレッシュトークン取得操作（運営代理ログイン用途と推察、用途確認）
  • パスワードリセット代行が必要なケース（CS 連携、メールが届かない時の救済等）

品質 / 約束事項

  • 応答性:
    • ログイン・登録・パスワード再設定は同期処理で即時応答
    • 認証コード（4 桁）のメール送信は数秒以内（メール配信側の遅延次第）
  • 信頼性:
    • パスワード認証の連続失敗時は一定回数でアカウントを一時ロック（不正アクセス防止）
    • リフレッシュトークン管理に内部障害が発生した場合、ユーザーは再ログインが必要になる可能性
    • 複数デバイスでの並行ログインは独立セッションとして扱われ、片方のセッションが期限切れになってももう片方には影響しない
  • 制限値:
    • 認証コード: 4 桁数字、有効期限あり（運用設定）、最大失敗回数あり（運用設定）
    • アカウントロック: パスワード認証の連続失敗回数で一時ロック発動、解除は一定時間経過後の自動解除
  • データ保持:
    • ログイン履歴は内部的に記録されており、CS 対応や監査で運営アドミン側から参照可能
    • パスワード自体は安全な形式（ハッシュ化）でのみ保持される

📝 レビュー観点:

  • メール送信タイミング: 認証コード送信は同期 or 非同期、配信失敗時の挙動
  • セッション有効期限: アクセストークン / リフレッシュトークンの有効期限（具体値は内部設定から、biz 上は「数時間」「数日」程度）
  • 複数デバイス: 同じユーザーが複数デバイスで併用可、それぞれ独立したセッション
  • アカウントロック: ロック発動条件と解除条件、解除待ち時間
  • [本機能特有] 内部キャッシュ障害時: リフレッシュトークン管理が止まった場合のユーザー視点挙動（再ログインが必要になるか等）

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

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

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

📝 レビュー観点:

  • PSD 初版作成時は単一エントリで OK
  • 過去の主要変更（メールリンク式追加 / Firebase 認証移行 等）があれば追記候補

関連ドキュメント

このページの内容を AI に質問しますか？
関連 spec を自動抽出して ChatGPT / Claude などに渡せます。
AI Prompt で開く →