DEMO 人材管理システム MVP ／ 動作デモ　ココナラ募集 5188266 向けに作成（タク｜タクWebエンジニア） ※ 実データは扱いません。ブラウザ内のみで動作します。

管理者ログイン

人材管理システム（MVP デモ）

デモ用アカウント
メール admin@example.co.jp ／ パスワード demo1234
次の画面の 6 桁コードは 123456

ダッシュボード

登録データの概況（デモ用のダミーデータです）

0登録人材
0稼働中
0フランチャイジー
0未紐付けの人材
0操作履歴（本セッション）

このデモで確認できること

募集要項に挙げられていた MVP の機能を、実際に触れる形で再現しています。 左のメニューから各画面をご確認ください。

管理者ログイン／MFA／パスワード再設定ログイン画面・6 桁コード・再設定フロー（アカウント列挙対策込み）
人材情報の登録・編集・検索「人材管理」で追加・編集・削除、キーワード＋4 条件の絞り込み
ソート・複数条件検索見出しクリックで昇順／降順、条件は AND 結合
フランチャイジー管理・人材との紐付け紐付け人数の集計、未紐付け人材の抽出
管理者管理権限ロール（システム管理者／運用管理者／閲覧のみ）の付与
操作履歴・エラーログこの画面での操作が実際に記録されます（監査ログの設計確認用）
ご注意：これは提案時点の叩き台です。実際の画面設計・項目・権限区分は、要件整理のうえで御社のご要望に合わせて確定させていただきます。

人材管理

複数条件検索・ソート・登録／編集／削除

絞り込み条件（AND 検索）

検索結果

ID 氏名 カナ 職種 フランチャイジー ステータス 登録日 スキル操作

フランチャイジー管理

加盟店の一覧と、人材の紐付け状況

フランチャイジー一覧

コード名称エリア紐付け人材稼働中操作

未紐付けの人材

管理者管理

権限ロールの付与と、アカウントの有効／無効

管理者一覧

氏名メールアドレス権限ロールMFA最終ログイン操作

権限ロールの考え方（叩き台）

ロール人材の閲覧人材の編集FC 管理管理者管理操作履歴
システム管理者全社○○○○
運用管理者自 FC のみ○（自 FC）××自分の操作のみ
閲覧のみ自 FC のみ××××
設計上のポイント：「自 FC のみ」の制御はアプリ側の if 文ではなく、Supabase の RLS（行レベルセキュリティ）でデータベース側に持たせます。実装漏れがあっても他社データが返らない構造になります（「システム構成・設計」に方針を記載）。

操作履歴

このデモで行った操作が、実際にここへ記録されます

監査ログ

日時操作者操作対象内容

記録する項目（設計）

日時（UTC＋表示は JST）操作者 ID操作種別 対象テーブル・レコード ID変更前後の差分IP アドレス User-Agentリクエスト ID

方針：監査ログは追記のみ（UPDATE／DELETE を許可しない）テーブルとし、アプリ経由では改変できないようにします。エラーログと合わせて、リクエスト ID で突き合わせられるようにします。

エラーログ

発生したエラーの記録と、再現に必要な文脈の保持

ログ

日時レベルリクエスト ID発生箇所メッセージ

運用の考え方

Cloudflare Workers の実行ログはそのままでは短期間で消えてしまうため、ERROR と WARN はデータベース側にも永続化し、管理画面から追えるようにします。

個人情報はログに残さず（氏名・メールはマスク）、リクエスト ID と対象レコード ID で追跡できる形にします。

システム構成・設計

ご提示の想定技術（Cloudflare Workers／WAF／Supabase／TypeScript）に沿った構成案

構成図

[ 管理者のブラウザ ] │ HTTPS ▼ [ Cloudflare WAF ] ── 不正リクエスト遮断／レート制限／国別制御 │ ▼ [ Cloudflare Workers ] ── 画面配信＋API（TypeScript） │ ・セッション検証　・入力バリデーション　・監査ログ記録 │ ├──▶ [ Supabase Auth ] ── ログイン／MFA(TOTP)／パスワード再設定 ├──▶ [ Supabase Postgres ] ── 業務データ（RLS で行単位の権限制御） └──▶ [ Supabase Storage ] ── 履歴書等のファイル（署名付き URL・有効期限つき）
Cloudflare Workersサーバー管理が不要。世界中のエッジで動くため、拠点が増えても表示速度が落ちにくい構成です。
Cloudflare WAF攻撃の遮断・アクセス制限。管理画面は接続元 IP や国での制限も設定できます。
Supabase（Postgres）認証・MFA・データベースが一体。RLS により「他 FC のデータは DB が返さない」構造にできます。
TypeScriptフロントと API で型を共有し、項目の追加・変更時の修正漏れを機械的に検出します。
ひとつ確認させてください：募集ページの「開発言語」欄が Python、本文の想定技術が TypeScript（Cloudflare Workers／Supabase）となっており、記載が分かれておりました。
Cloudflare Workers 上では実質 TypeScript／JavaScript が前提となるため、本提案は TypeScript 構成で組み立てています。Python 側に必然性（既存資産・バッチ処理・分析用途など）がある場合は、その部分だけを切り出す構成もご提案できますので、初回のお打ち合わせでご確認させてください。

データモデル（叩き台）

-- 加盟店
franchisees(id, code, name, area, is_active, created_at)

-- 人材
talents(id, franchisee_id → franchisees.id, name, kana, job_type,
        status, email, phone, skills[], note, created_at, updated_at)

-- 管理者（Supabase Auth の users と 1:1）
admins(id → auth.users.id, name, role, franchisee_id, mfa_enabled,
       is_active, last_login_at)

-- 監査ログ（追記のみ）
audit_logs(id, actor_id, action, target_table, target_id,
           diff jsonb, ip, user_agent, request_id, created_at)

-- エラーログ（追記のみ）
error_logs(id, level, request_id, source, message, context jsonb, created_at)
RLS の考え方（一例）：
運用管理者は、自分の franchisee_id と一致する talents 行だけ SELECT／UPDATE できる
というルールを データベース側に置きます。API に実装漏れがあっても、他社データは返ってきません。

段階リリースのご提案

段階内容確認できること
第 1 段階要件整理・データモデル確定／Supabase Auth（ログイン・MFA・パスワード再設定）／人材の登録・編集・検索／Cloudflare への初回デプロイ実際に動く画面で、項目と操作感を確定
第 2 段階フランチャイジー管理・人材との紐付け／複数条件検索とソートの拡張／権限ロールと RLS権限まわりを実データで検証
第 3 段階操作履歴・エラーログ／WAF 設定／テスト・本番リリース／運用手順書運用開始と引き継ぎ
なぜ段階を分けるか：人材管理は「どの項目を持つか」で設計が大きく変わります。先に第 1 段階を動かして項目を確定させたほうが、後戻りが少なく、結果的に総額を抑えられます。

タイトル