Skip to content

Latest commit

 

History

History
181 lines (145 loc) · 9.25 KB

File metadata and controls

181 lines (145 loc) · 9.25 KB

要件定義書 — AIシフト作成アプリ「ShiftCraft (Local-first)」

最終更新: 2026-04-06 ステータス: ドラフト v2.1 (Local-first 完全統合版) 設計方針: プライバシー重視・データ所有権の担保・実務ルールの完全統合


1. プロジェクト概要

  • プロジェクト名: ShiftCraft Local-first
  • 目的: 究極のセキュリティとプライバシーを確保しつつ、複数店舗のシフト作成を効率化する。
  • 背景: スタッフの個人情報は極めてデリケート。クラウドへのアップロードを躊躇するオーナーに対し、ローカル完結型+暗号化同期の安心感を提供する。

2. ターゲットユーザーと提供価値

  • ターゲットユーザー:
    • 個人情報保護を最優先する慎重なオーナー。
    • バックヤードのPC(大画面)と現場のスマホの両方で作業したい人。
  • 提供価値:
    • 100% プライバシー: クラウド運営者さえデータの中身を閲覧不能。
    • 超高速レスポンス: ローカルDBによる遅延ゼロの操作感。
    • オフライン動作: 電波の悪い店舗内でも制限なく作業可能。

3. 設計思想(Local-first)

原則 説明
Local-first オリジナルデータは手元のデバイスにのみ存在。クラウドは単なる同期の「土台」。
Zero Knowledge サーバー側には「誰が誰か」の情報は一切送らない(暗号化済み)。
匿名化AI処理 AI(Gemini)にはID化した「ポジション条件のパズル」のみを解かせ、個人情報は渡さない。
嫌われないUI 制約の強制ではなく警告ベース。最終判断は必ずオーナーが行う。

4. システム全体像

  • 利用者: オーナー(PCアプリ / スマホアプリ)
  • データ管理: 各端末の SQLite DB(WatermelonDB等)
  • 同期: Supabase (End-to-End 暗号化されたバイナリを中継)

4.1 技術スタック

レイヤー 技術 選定理由
PCアプリ Tauri (Rust + React) 軽量、セキュア、ローカルファイルへの高速アクセス。
スマホアプリ React Native (Expo) クロスプラットフォーム開発、ローカルDB操作の容易さ。
ローカルDB SQLite モバイル・デスクトップ両対応の標準的ローカルDB。
同期基盤 Supabase 暗号化データの同期、認証、匿名化APIのホスティング。
AI処理 Gemini API 匿名化された条件のみを受け取り、シフトを計算。

5. 機能要件 (詳細マスタ定義)

5.1 店舗管理

5.1.1 店舗マスタ

フィールド 必須 説明
店舗ID UUID 自動 システム自動採番
店舗名 text Yes 表示名
店舗カラー color Yes シフト表示時の色分け
営業時間 jsonb Yes 曜日別の営業開始・終了時間

5.1.2 ポジション設定

フィールド 必須 説明
ポジションID UUID 自動 レジ、キッチン等の役割定義
店舗ID UUID(FK) Yes 所属店舗
ポジション名 text Yes 表示名

5.1.3 時間帯別必要人員設定

フィールド 必須 説明
設定ID UUID 自動 システム自動採番
店舗ID UUID(FK) Yes 対象店舗
ポジションID UUID(FK) Yes 対象ポジション
日付 date Yes 適用日
時間枠 time(start-end) Yes 10:00-14:00 等
必要人数 int Yes 充足すべき人数

5.2 従業員マスタ管理

5.2.1 基本情報

フィールド 必須 説明
スタッフID UUID 自動 システム自動採番
表示名 text Yes ローカルDBのみ保存(本名)
匿名ID text 自動 API送信用 (staff_xxx)
夜勤可否 boolean No デフォルト true。false の場合、深夜帯(22:00-翌5:00)のシフトを割り当てない
出勤可能店舗 中間テーブル Yes staff_stores で管理(5.2.2参照)
対応可能ポジション 中間テーブル No staff_positions で管理(5.2.2参照)

5.2.2 出勤可能店舗・対応可能ポジション(中間テーブル)

テーブル FK 説明
staff_stores staff_id, store_id スタッフが出勤可能な店舗
staff_positions staff_id, position_id スタッフが対応可能なポジション

5.2.3 出勤条件・希望

フィールド 説明
曜日別出勤可否 専用テーブル (staff_availability) staff_id × 曜日(0-6) × 区分(○/△/×)
月間目標時間 decimal × 3 target_hours / min_hours / max_hours
連続勤務上限 int スタッフ個別に設定。未設定時はデフォルト5日で警告
休憩ルール - 6h超45m / 8h超1h(労基法準拠・システム固定)

5.2.4 絶対NG日

フィールド 必須 説明
ID UUID 自動 システム自動採番
スタッフID UUID(FK) Yes 対象スタッフ
日付 date Yes NG日
理由 text No メモ(ローカルのみ保存)

5.3 匿名化AIシフト生成(中核ロジック)

5.3.1 生成プロセス

  1. 匿名化: ローカルで「名前」を「匿名ID」に置換。
  2. AI送信: 匿名ID・対応可能ポジション・条件・店舗間競合禁止制約をAPIへ。
  3. 復元: AI回答をローカルで名前に戻して保存。

5.3.2 手動保護ルール

AI再生成時、is_manual_modified = true(オーナーが手動で編集済み)のシフトは上書きしない。

  • AI生成対象は未修正のシフトおよび新規枠のみ。
  • 手動保護されたシフトを再生成対象に含めたい場合は、オーナーが明示的に保護を解除する。

5.3.3 考慮優先度

優先度 条件 説明
1(絶対) 絶対NG日 / 二重配置禁止 休暇希望日および他店舗との重複を完全に防ぐ
2(高) 必要人員数 / 出勤可否 各時間帯の人数要件と、曜日・時間の○×を遵守
3(中) 希望労働時間 月間目標時間に近づける
4(低) スタッフメモ 人間関係や相性を考慮

6. 画面設計

6.1 画面一覧

画面名 説明
パスワード入力 秘密鍵の生成・復号。初回はパスワード設定、2回目以降はログイン
ダッシュボード 今週のシフトサマリー、充足率、警告数
店舗・スタッフ管理 各種マスタのCRUD(ローカル保存)
必要人員設定 新規追加。店舗・ポジション・曜日ごとの必要人数入力
シフトカレンダー メイン画面。月間/週間ビュー、D&D操作
シフト生成 条件確認 → 匿名化送信 → 生成
出力 PDF(A3横) / CSV エクスポート

6.2 主要UI要件

  • カレンダー: スタッフを左列、日付を横軸としたグリッド形式。
  • ドラッグ&ドロップ: シフトの移動・伸縮を直感的に操作。
  • 必要人員ライン: カレンダー上部に時間帯別の充足状況を表示。
  • 警告パネル: 画面下部にバリデーションエラーを一覧表示。

7. セキュリティ・同期仕様

7.1 エンドツーエンド暗号化 (E2EE)

  • 秘密鍵: ユーザーのパスワードから生成。サーバーには送信しない。
  • 暗号化: AES-256-GCM を使用。全てのマスタ・シフトデータを暗号化してクラウドに保管。
  • バックアップ: 秘密鍵のリカバリーフレーズ(24単語)をオーナーが物理的に保管。

7.2 データの境界線

  • ローカル(生データ): オーナーのPC・スマホのみ。
  • クラウド(暗号化): 同期用バイナリデータのみ。
  • AI(匿名化): ID化された条件データのみ。

8. フェーズ定義

Phase 1 — MVP(デスクトップ単体)

  • PC(Tauri)アプリのみ。同期なし・単一端末完結。
  • 店舗・スタッフ・ポジション・必要人員のマスタ管理(ローカルSQLite)。
  • 匿名化 AI シフト生成(休憩・二重配置・手動保護対応)。
  • リアルタイムバリデーション。
  • PDF/CSV出力。

Phase 2 — モバイル対応

  • スマホ(Expo)アプリの追加。
  • E2EE暗号化同期(Supabase経由)。
  • コンフリクト解決(LWWベース。詳細は設計書5.3節参照)。

Phase 3 — 運用最適化

  • 過去シフトの統計・分析ダッシュボード。
  • シフトテンプレート機能(曜日パターンによる必要人員の自動入力を含む)。
  • 秘密鍵のマルチデバイス共有機能のブラッシュアップ。