Fincs

運営アドミン / ユーザー管理

運営アドミン / ユーザー管理

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

概要

運営アドミン向けの個別ユーザー管理機能群。受講者・講師を問わず、特定ユーザーに対するロール変更・投稿禁止・ID 変更・メール削除・テストフラグ操作・強制退会代行などを扱う。

主な対象操作:

  • 投稿禁止フラグの ON/OFF: 規約違反対応で当該受講者の投稿を抑制
  • テストユーザーフラグの ON/OFF: 社内検証用ユーザーとしてマーク
  • ロール変更: 受講者 ⇔ メイン講師の昇格・降格
  • 強制退会（契約単位）: 特定講座の契約を運営アドミンが代理で終了
  • ユーザー ID 変更: 旧 ID → 新 ID への移行と関連データの一括書換
  • メールアドレス削除: GDPR 等の個人情報削除要請対応
  • ダミーユーザー作成: メール送信テスト用などにダミーユーザーを一括作成
  • 個人課金アカウントの登録・紐付け: 個別の課金アカウント単位での運用
  • トークン参照: 認証トークンの確認用

主な利用想定は、CS 案件（投稿禁止解除依頼・ロール変更依頼・強制退会対応）、GDPR 対応の個人情報削除、テスト・障害対応でのユーザー作成、配信用横断軸とは別の個人課金アカウント運用など。

講師から受講者への投稿禁止操作は提供していない: 講師から受講者へ「この受講者を投稿禁止にしてほしい」要望があった場合、CS が運営アドミン経路で代行する運用。

強制退会と「ユーザー削除」は別物: 本機能の強制退会は契約単位の終了（end_date 設定）で、ユーザー本体は残る。ユーザー本体の物理削除・論理削除は提供していない。複数の講座を契約しているユーザーを退会させる場合は契約ごとに繰り返し実行。

ID 変更は重い処理: ユーザー ID を旧 → 新へ移行する操作は、契約・タグ・トーク（DM 相手）・関連メタ情報を一括書換するため、規模次第で時間がかかる。実行中の整合性破綻リスクもあるため、CS 対応で必要なケースに限定して使う運用。

凍結（手動アカウントロック）の経路は提供していない: 内部にアカウントロック日時のフィールドは存在するが、運営アドミン経路で手動ロックする経路は未提供。必要な対応は強制退会・投稿禁止フラグなどで代替する運用。

📝 レビュー観点:

  • 目的: 個別ユーザーへの運用・障害対応
  • 誰が使うか: 運営アドミン
  • どこで使うか: 運営アドミン汎用ツール（/admin/tool）
  • 隣接機能との関係: 講師管理（./owner.md）、契約・支払い（./contract.md）
  • CS 問い合わせで頻発する論点: 「投稿禁止解除依頼」「テストユーザー化」「強制退会の影響範囲」「ID 変更時の関連データ波及」
  • [本機能特有] ユーザー検索・一覧の専用経路は未実装: 検索は他の講師向け経路または直接 DB
  • [本機能特有] 退会代行は契約単位: ユーザー本体の物理／論理削除は未提供
  • [本機能特有] 投稿禁止フラグは運営アドミン専用: 講師には経路なし
  • [本機能特有] 凍結（手動 lock）の経路が未検出: account_lock_date_time カラムはあるが運営からの更新経路は確認できず

利用シナリオ

シナリオ 1: 投稿禁止フラグの ON / OFF

講師からの依頼や運営判断で、特定受講者を投稿禁止状態にする。投稿禁止状態では当該受講者のトーク投稿が抑制される。問題が解消した時点で OFF に戻して通常受講可能な状態へ復帰させる。

シナリオ 2: テストユーザー化（決済除外用）

社内検証で利用するユーザーをテストユーザーとしてマーク。テストユーザーフラグは、メール送信テストの除外条件・無料契約付与の前提条件など、運用上の判定で参照される。

シナリオ 3: ロール昇格 / 降格

受講者を講師に昇格、または講師を受講者に降格。新規講師立ち上げ時の初期昇格や、退任講師のロール戻しに利用。ロール変更は単体のフラグ変更だが、関連データ（講師レコード・配信主体紐付け等）は別経路で整理が必要。

シナリオ 4: 強制退会（特定講座契約の終了）

特定受講者の特定講座契約を運営アドミンが代理で終了。任意の終了日を指定可能（指定なしで当日扱い）。複数講座を契約しているユーザーの場合は契約ごとに繰り返し実行。

シナリオ 5: ユーザー ID 変更（移行）

旧 ID → 新 ID への移行が必要なケース（識別子の意図しない命名・ユーザー要望での変更等）に対応。契約・タグ・トーク（DM 相手）・関連メタ情報が一括で書き換わる。

シナリオ 6: メールアドレス削除（GDPR 対応）

個人情報削除要請に応じて、ユーザーのメールアドレスを内部的に削除（NULL 化）。法令対応用途。

シナリオ 7: ダミーユーザー一括作成

メール送信テストや表示確認等のために、ダミーユーザーを複数件一括作成。指定講座 / 料金プランで初期契約を付与した状態で作成可能。

シナリオ 8: 個人課金アカウントの登録・紐付け

受講者の個人課金アカウント（運営アドミン経路で利用される個別単位）を登録 / 名称変更 / 講師紐付け / 講座紐付け。

よくある失敗ケース

  • 対象ユーザー不在: 指定したユーザー ID が見つからない場合のエラー
  • テストユーザー条件違反: 無料契約付与等のテストユーザー前提機能でテストユーザー以外を指定するとエラー
  • フラグ二重操作: 既に投稿禁止 ON の状態に再度 ON、未 ON の状態に対して OFF 等は事前確認推奨
  • ID 変更時の処理時間: 関連データ一括書換のため規模次第で長時間化するケース
  • 強制退会後の更新フラグ漏れ: 自動更新フラグが OFF にならないケースは別経路で確認

権限別仕様

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

横断軸

操作 運営アドミン テストユーザー 投稿禁止 受講者 講師
投稿禁止フラグ ON / OFF ○ × × × ×
テストユーザーフラグ ON / OFF ○ × × × ×
ロール変更（受講者 ⇄ メイン講師） ○ × × × ×
強制退会（契約単位） ○ × × × ×
user_id 変更（旧→新） ○ × × × ×
email 削除 ○ × × × ×
ダミーユーザー作成 ○ × × × ×
トークン参照（access / refresh） ○ × × × ×
個人課金アカウント登録・紐付け ○ × × × ×

📝 レビュー観点:

  • 講師から受講者への投稿禁止経路は無い: CS 経由で運営アドミンが代行する運用
  • 強制退会と「ユーザー削除」の違い（前者は契約単位、後者は未実装）

機能詳細（ふるまい）

投稿禁止フラグ

  • 指定ユーザーに対して投稿禁止フラグを ON / OFF
  • ON にすると、当該ユーザーがトーク投稿しようとした際に内部判定で投稿が抑制される
  • 本人のプロフィール画面には自身の状態として表示されるが、講師からは見えない
  • 講師からの「特定受講者を投稿禁止にしたい」要望は、CS 経由で運営アドミンが代行する運用

テストユーザーフラグ

  • 指定ユーザーをテストユーザー（社内検証用）としてマーク
  • マーク済みユーザーは: メール送信テストの除外、無料契約付与の前提条件、決済関連代理操作の前提条件 等で参照される
  • ON / OFF を運営アドミンが切替

ロール変更

  • ロール昇格: 受講者 → メイン講師
  • ロール降格: メイン講師 → 受講者
  • ロール変更そのものはフラグの書換のみ。講師レコードや配信主体紐付け等の関連データは別経路（./owner.md）で整理が必要

強制退会（契約単位）

  • 指定ユーザーの指定講座契約を運営アドミンが代理で終了
  • 終了日（end_date）・有効期限を設定 + 自動更新フラグを OFF
  • ユーザー本体や他講座の契約は影響を受けない
  • 複数講座契約者の全退会は契約ごとに繰り返し実行

ユーザー ID 変更

  • 旧 ID → 新 ID への移行
  • 関連データ（契約・支払履歴・ユーザータグ・トークルーム内の DM 相手・関連メタ情報）が一括で書き換わる
  • 規模次第で処理時間がかかる重い処理
  • 実行中の整合性破綻リスクがあるため、CS 対応で本当に必要なケースに限定する運用

メールアドレス削除

  • ユーザーのメールアドレスを内部的に NULL 化
  • GDPR 対応や個人情報削除要請での利用
  • 削除後はメール認証経由の操作ができなくなる

ダミーユーザー作成

  • メール送信テスト・表示確認用に、ダミーユーザーを一括作成
  • 入力項目: メールアドレス（生成のベース）、対象講座、対象料金プラン、作成件数
  • 指定講座・料金プランで初期契約を付与した状態で作成
  • 作成件数の固定上限はないが、大量作成は運用負荷の観点から留意

個人課金アカウント

  • 受講者個別の課金アカウント（運営アドミン経路で扱われる単位）の登録・名称変更
  • 講師紐付け / 解除
  • 講座紐付け / 解除
  • 配信主体（./owner.md で扱う事業者単位の account）とは別軸で、個別ユーザー単位の課金管理用

📝 レビュー観点:

  • 入力 → 処理 → 出力: 経路入力 → 即時実行 → 影響範囲は表示なし（CS は影響範囲を別途確認）
  • エッジケース: 既に投稿禁止のユーザーに再度 ON、テストユーザーでないユーザーへの無料契約試行
  • エラー表示: ユーザー不在で user.not.exist、テストユーザー条件違反で user.not.test.user
  • [本機能特有] FE バリデーション無し: 汎用ツールから自由入力
  • [本機能特有] ID 変更の関連データ波及: 契約・タグ・トークルーム・Firestore まで及ぶ重い処理

admin 操作

本ページ全体が運営アドミン操作の集約。各操作の詳細は機能詳細セクション参照。

該当なし / 実装されていない

  • ユーザー検索・一覧の運営アドミン専用経路: 未実装（既存の他経路で代替）
  • アカウント凍結の手動経路: 未実装（自動 lock のみ）
  • メール受信設定の代理操作: 未検出
  • users 行自体の物理／論理削除: 未実装

📝 レビュー観点:

  • 検索専用経路の必要性
  • 凍結手動経路の運用要件

品質 / 約束事項

  • 応答性: 即時反映（ID 変更のみ関連データ書換のため数秒〜数十秒の可能性）
  • 信頼性: 各操作のトランザクション境界に依存。ID 変更は Firestore 同期も含むため部分失敗リスクあり
  • 制限値:
    • ダミーユーザー作成: 件数下限 1、上限なし（実質 BE 側に上限なし）
    • アカウント名: 英数字 + アンダースコアのみ、最大長未指定
  • データ保持: 投稿禁止・テストユーザー・ロール変更はフラグ書換のみ、論理削除なし

📝 レビュー観点:

  • [本機能特有] ダミーユーザー件数上限なし: 大量作成リスク → 改善課題
  • [本機能特有] ID 変更の整合性: Firestore 失敗時の DB 戻し挙動

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

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

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

📝 レビュー観点:

  • 過去の主要変更（投稿禁止フラグ追加 / テストユーザーフラグ追加 / 個人課金アカウント導入 等）

関連ドキュメント

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