---
title: "ディスコグラフィー機能 要件整理メモ（Issue #56）"
---

最終更新: 2026-03-03

## 1. 背景と目的

- 目的は、モーニング娘。メンバー詳細体験に「リリース情報」を加え、近況情報に加えて活動の文脈を把握できるようにすること。
- Issue #56 の成果物として、実装前の要件を固定し、後続Issueへ分割可能な状態にする。
- 本メモは要件整理に限定し、実装・移行・API仕様の最終確定は行わない。

## 2. スコープ

### In Scope

- MusicBrainz を一次ソースとしたリリース情報の自動取得要件
- メンバー在籍期間による自動紐づけ要件
- メンバー詳細画面でのリリース表示要件
- リリース一覧/詳細導線の要件
- 品質・運用・失敗時挙動の要件

### Out of Scope

- `types/member.ts` や既存コンポーネントの実装修正
- `scripts/sync-status.ts` への統合実装
- 新規 API ルートの実装
- 永続化形式の最終決定
- 個人名義リリースや派生ユニットの初期対応

## 3. ユースケース

- 利用者はメンバー詳細画面で、当該メンバーに関連するシングル/アルバムを時系列で確認できる。
- 利用者はリリース項目からリリース詳細画面へ遷移できる。
- 運用者は定期同期により最新リリース情報を自動反映できる。
- 運用者は自動判定が曖昧な紐づけを手動補正できる。

## 4. データ取得要件（MusicBrainz）

- 一次データソースは MusicBrainz とする。
- 取得対象は初期版ではモーニング娘。本体リリースを優先する。
- 取得時は以下を最低限保持できること。
  - リリースID
  - タイトル
  - リリース日
  - フォーマット（single/album/other）
  - 取得元識別子
  - 取得元URL
- データ取得処理は「取得」「正規化」「紐づけ」「表示」の4境界を分離する前提で設計する。
- 一時的な取得失敗時は既存表示を維持し、再実行可能であること。

## 5. メンバー紐づけ要件（在籍期間ベース）

- 初期の自動判定ルールは以下とする。
  - `joinDate <= releaseDate <= gradDate` の場合に紐づけ対象とみなす。
  - `gradDate` が `null` の場合は上限なしとして扱う。
- 自動判定で確定できないケース（例: 日付欠損・表記ゆれ・重複）は低信頼として扱い、手動補正対象にする。
- 補正結果を反映可能な仕組み（例外補正テーブル相当）を将来実装前提とする。

### 追加インターフェース方針

#### `Release` 概念

| フィールド | 必須 | 説明 |
| --- | --- | --- |
| `id` | 必須 | リリース識別子 |
| `title` | 必須 | リリース名 |
| `releaseDate` | 必須 | 発売日（ISO日付想定） |
| `format` | 必須 | リリース種別 |
| `source` | 必須 | データソース名（初期は `musicbrainz`） |
| `sourceUrl` | 必須 | 取得元参照URL |

#### `MemberReleaseLink` 概念

| フィールド | 必須 | 説明 |
| --- | --- | --- |
| `memberId` | 必須 | メンバーID |
| `releaseId` | 必須 | リリースID |
| `linkType` | 必須 | 紐づけ種別 |
| `confidence` | 必須 | 判定信頼度 |
| `reason` | 必須 | 判定/補正理由 |

- `linkType` は最小セットとして以下を採用する。
  - `primary_member`
  - `group_member`
  - `support_member`
  - `unknown`
- `confidence` は3段階を採用する。
  - `high`
  - `medium`
  - `low`

## 6. 画面要件（メンバー詳細とリリース画面）

- メンバー詳細画面に「関連リリース」セクションを追加できる設計にする。
- 関連リリースは発売日順で閲覧できること。
- 各リリースは詳細画面への導線を持つこと。
- リリース画面は、最低限タイトル・発売日・種別・関連メンバーを表示できること。
- データ欠損時は UI 崩壊を起こさず、欠損状態を明示できること。

## 7. 非機能要件（精度・更新頻度・運用）

- 精度
  - 自動紐づけの判定根拠を `reason` として追跡可能にする。
  - 曖昧ケースは `confidence=low` で識別可能にする。
- 更新頻度
  - 定期同期ジョブ統合を前提に、再実行可能な取得フローとする。
- 運用
  - 外部APIの一時障害時は機能全体を停止させず、前回反映済みデータで継続表示する。
  - エラー時は再試行可能な運用手順を用意できる構造とする。

## 8. 既知リスクと回避方針

- MusicBrainz の表記揺れ・欠損
  - 回避: 正規化層と低信頼判定を導入し、手動補正フローへ送る。
- 同名/類似タイトルの重複判定
  - 回避: 正規化時に重複排除ルールを導入する。
- 在籍期間のみでは表現しきれない参加形態
  - 回避: `linkType` と補正テーブルで例外運用を可能にする。
- 外部依存による同期失敗
  - 回避: フェイルセーフ（既存表示維持）と再実行可能性を優先する。

## 9. 後続Issue分割案

1. 取得アダプタ実装（MusicBrainzクライアント）
2. 正規化・重複排除ロジック
3. 在籍期間リンクロジック + 例外補正テーブル
4. 表示UI（メンバー詳細/リリース一覧）
5. 定期同期ジョブ統合
6. テスト整備（unit/integration）

## 10. 受け入れ基準

- 取得正常系
  - MusicBrainzレスポンスから必要項目を欠落なく抽出できる要件が明記されている。
- 紐づけ正常系
  - `joinDate <= releaseDate <= gradDate/null` の判定ルールが明記されている。
- 例外系
  - 日付欠損・表記ゆれ・重複時に `confidence` が低下し、手動補正対象になる方針が明記されている。
- UI要件
  - メンバー詳細で関連リリース一覧を表示し、リリース詳細へ遷移する要件が明記されている。
- 運用要件
  - 取得失敗時に既存表示を壊さず、再実行可能である方針が明記されている。

## Issue #56 追記用メモ（コメント草案）

```md
要件整理メモを追加しました。
- docs/design/discography-requirements.md

方針:
1. 自動取得前提（一次ソース: MusicBrainz）
2. 在籍期間ベースの自動紐づけ + 例外手動補正
3. 実装は未着手（要件整理のみ）

後続Issue分割案:
1) 取得アダプタ
2) 正規化/重複排除
3) 紐づけ + 補正テーブル
4) 表示UI
5) 定期同期統合
6) テスト整備
```