ID戦略: 手動採番（例: aoshiro-fujisawa）　用途: 店舗の基本情報・マッチングポリシー・QRトークンを管理

ID戦略: テーブル番号を文字列IDとして使用（例: "1", "2"）　用途: 各店舗のテーブル設定。多店舗間の番号衝突を避けるためサブコレクション採用（F1）

F1: 多店舗間でテーブル番号が重複するためサブコレクション採用。

ID戦略: Firebase Auth UID（Anonymous）をドキュメントIDとして使用（Auth と 1:1）　用途: 不変のユーザープロフィール情報を保持（5項目: name/age/gender/photoURL + uid/createdAt/updatedAt）　ライフサイクル: 登録 Submit 時に作成。プロフィール更新時に updatedAt 更新。所属やステータス管理は groups コレクションで完結（groups.memberUids が単一の真実）　v1差分: nickname/ageGroup/mood/wantToDo/message を廃止。さらに v2 で運用系（shopId/tableNumber/status/registeredAt/releasedAt/lastActiveAt）も廃止し、プロフィール情報＋createdAt/updatedAt のみに簡素化

ユーザーの所属グループは groups where memberUids array-contains uid でクエリする（groups.memberUids が単一の真実の源）。店舗別ユーザーカウントは users ではなく各グループの memberUids.length の合計で算出する（A4ダッシュボード。Firestore は array-length をクエリで直接使えないため、クライアント側で集計）。

ID戦略: Firestore auto-id（F2: 可読性よりコリジョン安全性を優先）　ライフサイクル: 1人目登録で waiting 生成 → グループ確定で active → マッチ成立で matched。waiting/active のまま TTL 超過で expired（G-3）。案内完了は matches.status（guided）で管理。

G-3: TTL 超過で expired 化（TTL は shops.matchingPolicy.sessionTtlMinutes、既定: 60分）。G-4: マッチ成立直後の同テーブル新規登録は新規 group として生成。G-5: active 状態はメンバー追加可。matched 以降は不可。

ID戦略: doc ID = auto-id（Firestore自動採番）。likeIdフィールドにも同値を保持（F3）　ライフサイクル: いいね操作で生成 → 相互いいね成立時に matchedAt を更新

F3: 送信先グループのサブコレクションとして配置。doc IDはauto-idで採番（ビジネスIDをdoc IDにせず、将来の再いいね等の拡張に備える）。G-7: いいね取り消しはPhase 1では不要。G-8: 受信いいね（片想い）は「あなたにいいねしたグループ」タブで表示。クエリは shops/{shopId}/groups/{自分のID}/likes を list。送信いいねは collectionGroup('likes').where('fromGroupId','==',自分のID)。マッチ成立判定はA→B作成時に逆方向 shops/{shopId}/groups/{A}/likes where fromGroupId == B を limit(1) でクエリ。

ID戦略: {groupAId}_{groupBId} の辞書順ソート済み複合ID（重複防止）　ライフサイクル: 相互いいね成立で pending_guidance 生成 → 店員が案内開始で guiding → 案内完了で guided

A3 案内待ち画面クエリ: shops/{shopId}/matches where status in ['pending_guidance', 'guiding'] order by matchedAt asc。店舗横断統計は collectionGroup('matches') を使用。

ID戦略: Firebase Auth UID（Email/Password）をドキュメントIDとして使用　用途: 管理画面ログインユーザーの情報・ロール・担当店舗を管理

G-10: Custom Claims 遅延対策として、重要操作は adminAccounts ドキュメント参照で二重チェック。