メンバー データ設計書

最終更新: 2026-09-17

1. 概要

members.json に格納される Member（メンバー）エンティティのデータ設計。 Member は他の全機能（リリース紐付け・プレイリスト・ユニット・ライブ・関係性マップ・タイムライン等）から参照される最も基盤的なエンティティだが、専用のデータ設計書がこれまで存在しなかった（#1379）。

2. 背景・目的

3. 型定義

Member インターフェース（types/member.ts）

export const MemberSchema = z.object({
  id: z.string().min(1),
  name: z.string().min(1),
  ruby: z.string().min(1),
  status: z.string().min(1),
  generation: z.number(),
  color: z.string().regex(/^#[0-9a-fA-F]{6}$/).optional(),
  colorName: z.string().optional(),
  leaderGenerationNumber: z.number().int().positive().nullable().optional(),
  nickname: z.array(z.string()).optional(),
  joiningRoute: z.string().optional(),
  latestStatus: StatusEntrySchema,
  officialSns: z.array(SnsEntrySchema).optional(),
  statusHistory: z.array(StatusEntrySchema).optional(),
  snsCheck: SnsCheckSchema.optional(),
  youtubeChannel: YoutubeChannelSchema.optional(),
  tiktokChannel: TikTokChannelSchema.optional(),
  profile: z.object({
    dob: z.string(),
    joinDate: z.string(),
    gradDate: z.string().nullable(),
    family: z.string(),
    birthplace: z.string().optional(),
    instructor: z.array(z.string()).optional(),
  }),
});
export type Member = z.infer<typeof MemberSchema>;

フィールド詳細

StatusEntry インターフェース（Member.latestStatus / Member.statusHistory の要素）

export const StatusEntrySchema = z.object({
  content: z.string(),
  lastUpdated: z.string(),
  sources: z.array(z.string()),
});

SnsEntry インターフェース（Member.officialSns の要素）

export const SnsEntrySchema = z.object({
  url: z.string(),
  active: z.boolean(),
});

SnsCheck インターフェース（Member.snsCheck）

export const SnsCheckSchema = z.object({
  status: z.enum(['ok', 'error', 'skipped', 'unknown']),
  hasRecentUpdate: z.boolean(),
  lastCheckedAt: z.string(),
  reason: z.string().optional(),
  lastPostAt: z.string().optional(),
});

YoutubeChannel インターフェース（Member.youtubeChannel、types/youtube.ts）

export const YoutubeChannelSchema = z.object({
  handle: z.string().min(1),
  playlistId: z.string().min(1),
});

TikTokChannel インターフェース（Member.tiktokChannel、types/tiktok.ts）

export const TikTokChannelSchema = z.object({
  username: z.string().min(1),
});

TikTok は RapidAPI（tiktok-scraper7.p.rapidapi.com）が unique_id（username）を直接指定して投稿取得できるため、YouTube の playlistId のようなサーバー側 API 解決は不要（§5参照）。詳細 → TikTok投稿機能 データ設計書

4. データファイル

members.json（Vercel Blob）

• Vercel Blob（MEMBERS_BLOB_URL）で管理。ローカルにフリーズドコピーは持たない（読み取りは Blob URL への fetch）
• 更新経路: PUT /api/members（メンバー詳細画面の編集フォーム）、sync-members ワークフロー（近況自動検索・Ameba同期）、各種 scripts/patch/patch-*.ts（愛称・加入ルート・メンバーカラー・リーダー代・師匠情報等の一括投入）

5. /api/members の設計

app/api/members/route.ts が Vercel Blob（members.json）への読み書きを一元的に担う。

5-1. GET /api/members: 一覧取得とキャッシュ戦略

• fetch(blobUrl, { next: { revalidate: 3600 } }) で取得したBlobの生JSON（{ members: Member[] }）をそのまま返す。getMembersFromBlob()（lib/blob.ts）と同じ revalidate: 3600 を使い、Blobアクセス経路間でキャッシュ戦略を統一している（もともと PUT の cache: "no-store" 設定を流用していたが#1296で是正した経緯がある）
• /member-map（クライアント側 fetch）・/members（メンバー一覧、TanStack Queryの useQuery、#1640）の2画面がこのエンドポイントをクライアント側から参照する
• Issue #1569 で導入した UnifiedFeedItem 判別共用体パターン（SNS4種の異なる形状を統合する型）とは異なり、Member は元々単一形状のドメイン型として types/member.ts に存在するため、本エンドポイントに新規の判別共用体スキーマは導入しない。既存の Member 型をそのまま利用する
• /members 画面はサーバー側 page.tsx で prefetchQuery（クエリキー ['members']）→dehydrate→HydrationBoundary を行い、初回表示のちらつきを回避する（#1569と同じ構成）。一覧描画部分はクライアントコンポーネントへ切り出し、useQuery で取得したレスポンスの .members を参照する

PUT /api/members はクライアントから送信されたペイロードの一部フィールドをサーバー側で上書き・算出する。クライアント値に依存しない。

5-2. PUT /api/members: statusHistory の保持ルール

• latestStatus.content が既存値から変化した場合のみ、新しい StatusEntry を statusHistory の先頭に追加する
• 変化の有無に関わらず、保存前に以下の2条件でフィルタする（早い方を適用）:
  • 30日以内（lastUpdated が現在日から30日以内）
  • 100件以内（slice(0, 100)）
• latestStatus.lastUpdated は JST（Asia/Tokyo）でサーバー側が生成する。クライアントが送った値は無視される（#141）

5-3. PUT /api/members: youtubeChannel の解決ロジック

5-4. PUT /api/members: tiktokChannel の解決ロジック（#1478）

6. Neon 側「出身地照合用メンバー」（Member）

ライブ機能の「ご当地ライブ」判定でのみ使用される、Blob Member とは別の Prisma モデル。

model Member {
  memberId   String  @id @db.VarChar(50)
  birthplace String? @db.VarChar(255)

  @@map("members")
}

• memberId は Blob Member.id と同値を Neon 側に複製したもの（DB レベルの FK 制約はない）
• birthplace のみを保持する部分的なミラーであり、Blob Member の完全な複製ではない
• 詳細 → ライブ・フェス機能 テーブル設計書

7. ER 図

→ ER 図 を参照すること。Member はコア音楽データ・ライブ/フェス・メンバー関係性マップの各セクションに登場する。

8. 関連設計書

改訂履歴