運営アドミン / 全体像・認証認可
運営アドミン / 全体像・認証認可
本ページは 2 段構成。上段が biz/CS 向け（ユーザー提示可）、下段（
## 🔧 実装詳細以降）が dev 向け。biz/CS がユーザーへ提示・転用してよいのは上段のみ。
概要
運営アドミン（フィンクス社内の運営担当者）は、CS 対応・障害対応・データ整合性メンテナンスの起点として、運営アドミン専用ロールでログインし、運用操作を実行する役割を担う。本ページは運営アドミン全体像と認証認可の仕組みを扱う。
主な利用想定は、ユーザーからの問い合わせ対応（投稿禁止 / 強制退会 / プラン代理操作 等）、障害発生時の暫定復旧（データ整合性メンテナンス・コンテンツ強制非公開 等）、月次運用作業（料率設定・配信代理 等）、事業者運用（法人講師の登録・紐付け 等）。各機能の詳細はカテゴリ内の他ページに分けて記載する。
専用 UI の整備状況: 各操作ごとの専用管理画面は未整備で、現時点では汎用ツール画面 1 枚から操作経路と内容を手入力して実行する運用となっている。誤操作リスクの抑制と効率化は今後の改善対象。
運営アドミンの権限粒度: 運営アドミンロールは 1 種類のみで、現状「読み取り専用」「特定領域のみ操作可」といった細分化は提供していない。運営アドミンは事実上のスーパーロールとして全運用操作を行える。
操作監査の仕組み: 専用の操作監査ログテーブルは未提供で、操作トレースは各データテーブルの監査列（最終更新者カラム）から逆引きする運用となっている。CS 対応で「いつ・誰がこの変更をしたか」を確認したい場合は、対象テーブルの監査列を直接参照する形になる。
📝 レビュー観点:
- 目的: CS 対応・障害対応・データ整合性メンテナンスの起点
- 誰が使うか: 運営アドミン のみ
- どこで使うか:
/admin/tool画面、Firebase 認証経由の運営ログイン- 隣接機能との関係: 各 運営アドミン 機能ページ（user / plan / contents / talk / contract / 講師 / master / system）
- CS 問い合わせで頻発する論点: 「運営アドミンログイン経路」「権限ロール定義」「監査ログの所在」
- [本機能特有] 専用 UI 未整備: 操作ごとの専用画面は無く、汎用ツールから API URI を手入力
- [本機能特有] 監査ログテーブル不在: 操作トレースは created_by/updated_by ベース
- [本機能特有] 運営アドミンは事実上のスーパーロール: 助言会社系・講師系の認可マッチャもすべて通過
利用シナリオ
シナリオ 1: 通常運用での CS 対応
ユーザーからの問い合わせを受けて運営アドミンが、対象ユーザーの状態確認・データ修正・契約調整・投稿禁止フラグの ON/OFF などを汎用ツール画面から実施。各機能の詳細手順はカテゴリ内の機能別ページを参照。
シナリオ 2: 障害対応での緊急操作
特定の機能で不具合や整合性破綻が見つかった場合、運営アドミンが緊急で配信ロック・整合性メンテナンス・データ強制更新などを実施。専用 UI が未整備のため、汎用ツール画面で操作経路を手入力する運用となる。
シナリオ 3: 月次・定期の運用作業
料率設定の更新、法人講師（事業者所属の講師）の登録・紐付け、月次集計の補正など、定期的な運用作業を運営アドミンが実施。
よくある失敗ケース
- 権限不足: 運営アドミンロール以外のユーザーが運営操作経路にアクセスしてもエラー
- 誤操作リスク: 専用 UI が未整備のため、汎用ツールで誤った経路や内容を入力すると意図しないデータ更新が発生する可能性。慎重なオペレーションが必要
- 操作トレースの追跡: 監査ログ専用テーブルがないため、過去の操作を「誰がいつ何をしたか」で網羅的に追うのが難しいケースあり
権限別仕様
権限定義は ../user-roles.md 参照。用語は ../terminology.md。
横断軸
| 操作 | 運営アドミン | テストユーザー | 投稿禁止 | 受講者 | 講師 |
|---|---|---|---|---|---|
| 運営アドミンログイン | ○（Firebase 経由） | × | × | × | × |
| 運営アドミン操作経路へのアクセス | ○ | × | × | × | × |
| 操作対象データの参照・編集 | ○（全テーブル横断） | × | × | × | × |
📝 レビュー観点:
- 運営アドミンの権限粒度はロール 1 種類のみ（細分化されていない）。biz レビューで分割の必要性確認
機能詳細（ふるまい）
運営アドミンログイン
- 運営アドミン専用のログイン経路を経由してログイン
- 一般受講者・講師とは別の認証ルートで、内部認証基盤と連携している
- ログイン後、運営アドミン操作経路へのアクセスが許可される
運営アドミン操作画面
- 単一の汎用ツール画面が現時点での操作 UI
- 操作対象の経路と送信内容を手入力して実行
- 操作別の専用画面（プラン管理画面 / ユーザー管理画面 等）は未整備
- 各操作の詳細は機能別の運営アドミン PSD ページで記載
操作監査
- 専用の操作監査ログテーブルは未提供
- 各データテーブルが持つ「最終更新者」「最終更新日時」のカラムから操作主体を逆引きする運用
- CS で「過去の特定変更を遡りたい」要望があった場合は、対象テーブルを個別確認
権限昇格・代理ログイン
- 通常の運営アドミンロールで全操作が可能なため、追加の権限昇格手段は不要
- 受講者・講師としての代理ログイン機能は提供していない（運営は運営アドミンとして直接操作）
📝 レビュー観点:
- 入力 → 処理 → 出力: 汎用ツールで URI 入力 → 直接 API 実行 → レスポンス表示
- エッジケース: URI 誤入力で意図しないテーブルを更新するリスク
- エラー表示: 一般的な HTTP エラー（権限不足・データ不在等）はそのままユーザーに表示
- [本機能特有] 操作ガード皆無: 確認ダイアログ・許可リスト等の UI ガードは無し
admin 操作
該当なし / 実装されていない
- 操作監査ログの専用テーブル: 未実装
- 運営アドミンロールの細分化: 未実装（1 ロールで全操作可）
- 代理ログイン: 未実装
📝 レビュー観点:
- 監査ログ整備の優先度
- 操作ロールの権限分離（読み取り専用ロール等）の必要性
品質 / 約束事項
- 応答性: 汎用ツール経由の操作は同期実行（即時反映）
- 信頼性: 各操作のトランザクション境界に依存
- 制限値: 特になし（通信レイヤの制限のみ）
- データ保持: 操作トレースは各テーブルの監査列（created_by / updated_by）でのみ保持
📝 レビュー観点:
- [本機能特有] 操作トレースの粒度: 監査ログ未整備により「いつ・誰が・何を」の即時把握が困難
変更履歴（リリースノート候補）
v2.29.2: 2026-05-04（PSD 初版）
- [PSD 追加] 本ドキュメント初版作成。v2.29.2 時点の実装を起こし。機能追加・変更は含まない
📝 レビュー観点:
- 過去の主要変更（運営アドミンログイン経路導入、ロール定義変更 等）
関連ドキュメント
- 権限定義:
../user-roles.md - 用語辞書:
../terminology.md - 関連 PSD（運営アドミンカテゴリ各ページ）