画面設計書

概要

MorningStatusApp は Next.js App Router をベースとした Web アプリケーション。 以下の38画面で構成される。

画面一覧

機能別の詳細設計書:

• プレイリスト画面
• 曲対比画面
• ユニット画面
• ライブ機能画面
• YouTube投稿一覧画面
• タイムライン画面
• イベント詳細画面
• メンバー関係性マップ画面
• メンバー関係性マップ レーダーチャート画面
• 平均年齢の変遷グラフ画面
• 世代マトリックス画面
• ラジオオンエア データ（UI設計セクションあり）
• Amebaブログ機能（UI設計セクションあり）

画面遷移図

Topページが全ドメインのハブとなり1枚の図に収まらないため（#1435）、「TOP画面内遷移図」「外部遷移図（タイムライン・年表・関係性マップ系列）」「外部遷移図（リリース・ライブ・ラジオ等イベント系列）」の3図に分割する。

TOP画面内遷移図

Topページから各セクション一覧への一次遷移のみを示す。各セクション内部の詳細な遷移は後続の外部遷移図を参照。

外部遷移図（タイムライン・年表・関係性マップ系列）

EVENT（イベント詳細画面）の詳細設計はイベント詳細画面 設計書を参照（実装Issue: MorningStatusApp#1583）。

外部遷移図（リリース・ライブ・ラジオ等イベント系列）

音楽コンテンツ・ライブ／フェス・ラジオ・SNS投稿の4クラスタに分けて表示する。クラスタをまたぐ遷移（例: ライブ詳細→メンバー詳細）も存在する。

既知の制約: メンバー詳細（曲詳細も一部）が他クラスタと相互に繋がる実質的なハブになっているため、1枚の図にまとめるとMermaidのレイアウトエンジンが4クラスタを横に並べて配置し、図全体の実寸幅が広くなりすぎて何を見ているか把握しづらくなる（#1435, #30）。クラスタ単位、さらにクラスタ内でも関連の薄いグループ単位で図を分割し、他グループへの遷移先は接続先ノード（メンバー詳細・曲詳細等）のみを示す形にすることで、1図あたりのサイズを読める範囲に抑えている。接続先ノードの内部遷移は、そのノードが属する図を参照。

音楽コンテンツ

メンバー・リリース・曲・ユニット

プレイリスト・対比

ライブ・フェス

ライブ

フェス

ラジオ

SNS投稿

Instagram

TikTok・Ameba

YouTube

各画面の設計

1. Topページ（/）

概要: ナビゲーション・新着投稿ダイジェストを表示するトップ画面。メンバーカード一覧は「2. メンバー一覧画面（/members）」に分離されている。

備考: タイトル要素（下表）は、世代マトリックス画面（/generational-matrix）への隠し単語タップシーケンス入力も兼ねる。タイトルを構成する単語（Hello!／Project／History）そのものをタップ対象として使うため、このページのタイトル文言を変更する際は 世代マトリックス 画面設計書 §5-1aの仕様（タップ対象の単語構成・順序）に影響しないか必ず確認すること。

表示コンテンツ

新着投稿セクション

• 表示条件: 各ブロック内の各SNSサブセクション（見出し・一覧画面へのリンク）は新着の有無に関わらず常時表示する。新着が0件のSNSは中身を「本日の新着投稿はありません」に差し替える（#1404の原則をブロック単位でも維持。以前は0件のSNSはリンクごと非表示になり、全SNSが0件の日はセクション全体が非表示だったため、一覧画面への導線が失われる不具合があった）
• 参照日ヘッダー: {参照日の JST 日付} の新着投稿（詳細は後述の「参照日ヘッダー」を参照）
• 著作権表記: 「（Instagram/TikTok/YouTubeの各画像は参考表示：権利はすべて投稿者に帰属しています）」。TikTok画像の参考表示期限切れ時はリンクのみの表示になる旨を併記
• ブロック構成（#1514）: SNS別の4ブロック構成（Instagram→TikTok→YouTube→Amebaの固定順）から、投稿主体（公式アカウント／現役メンバー本人／OGメンバー本人）による3ブロック構成に再編する

• TikTok・YouTubeに「現役」ブロックが無いのは、収集対象外にしているためではなく、現役メンバーが個人でTikTok・YouTubeチャンネルを運用していないため（現役メンバーが自ら発信するSNSはAmebaブログ・Instagramのみ。TikTok・YouTubeでの現役メンバーの登場は公式チャンネル動画への出演・言及としてのみ間接的に確認できる。詳細は本ドキュメント「3. メンバー詳細画面」のTikTok投稿セクション・YouTube動画セクションを参照）
• Amebaに「公式」ブロックが無いのは、グループ公式のAmebaブログという概念自体が存在しないため（個人ブログのみ。詳細は Amebaブログ機能 データ設計書 を参照）
• 各ブロック内のSNSサブセクションの並び順: そのブロックにおける各SNSの最新投稿日時（下表「並び順の算出方法」列を参照）を比較し、新しい投稿があるSNSから順に表示する。SNSサブセクション自体の見出し・グリッド・カードデザインは変更しない
• タイブレーク（同日・比較不能時）のフォールバック順: ブロックごとに固定の順序へフォールバックする（詳細ページの並び順に関する既存知見: 開発ノート「UI/UX設計」#5 に準拠）
  • 公式ブロック: YouTube → TikTok → Instagram
  • 現役ブロック: Ameba → Instagram
  • OGブロック: Ameba → Instagram → TikTok → YouTube
• SNSサブセクション内の個々の投稿の並び順・表示内容は現行のまま変更しない（下表を参照）

参照日ヘッダー

• 表示条件: 新着投稿の参照日（当日の新着日時、なければメンバーデータの最終更新日時）が取得できる場合に表示。新着が全SNSで0件の日も、メンバーデータの最終更新日を参照日として表示する
• 日付ラベル: {参照日の JST 日付} の新着投稿
• 出来事表示: 参照日と月日が一致するメンバーの記念日を表示

2. メンバー一覧画面（/members）

概要: 全メンバーのカードを現役・OG に分けて表示する一覧画面。

表示コンテンツ

MemberCard の表示内容

SNSステータスバッジの状態

3. メンバー詳細画面（/members/[id]）

概要: 特定メンバーのプロフィール・近況・ディスコグラフィーを表示し、データ編集もできる画面。

動的レンダリング: generateStaticParams() でルートを定義し、リクエスト時に Vercel Blob から最新データを取得する（getMembersFromBlob() が cache: "no-store" でフェッチするため SSR として動作）。

表示コンテンツ

備考: データ型名（Member.latestStatus/statusHistory、StatusEntry）は「Ameba」等の個別SNS名を冠さない汎用名のままとしている。Amebaブログを開設していない・SNSで自ら発信しないOGメンバーも同じ仕組み（Exa検索によるWeb上の言及収集）で近況を表現する必要があり、データ構造をAmeba固有の名称にできないため（#1513）。表示側の見出し（「Ameba投稿」/「Exa検索結果」）はエントリごとの実際の情報源に応じて動的に決まる。

SNS 投稿部の並び順（#1513）

「Ameba投稿/Exa検索結果」「Instagram 投稿」「TikTok 投稿」「YouTube 動画」の4セクションは固定順ではなく、各セクションの最新日時を比較し新しい順に並べる。投稿が0件のセクションは従来通り非表示（並び順の計算対象から除外）。ページ内リンクも同じ順序に追従する。

同日・比較不能などのタイブレーク時は、固定順「Ameba投稿/Exa検索結果 → Instagram 投稿 → TikTok 投稿 → YouTube 動画」にフォールバックする（詳細ページの並び順に関する既存知見: 開発ノート「UI/UX設計」#5 に準拠）。

区切り線（#1615）: 各セクションの先頭には区切り線（<hr>）を1本表示する。区切り線は並び替え対象の各セクション自身が描画する責務を持ち、MemberDetailView側に共通の区切り線を重ねて持たない。並び替えにより先頭に来るセクションが変わるため、区切り線をコンテナ側と特定セクション側の両方に置くと、そのセクションが先頭に来たときだけ区切り線が二重表示になってしまうため。

備考: 旧実装ではAmeba投稿/Exa検索結果セクションのみ自前の先頭区切り線を持たず、コンテナ側の共通区切り線に依存する作りだった（元々このセクションが常に先頭という前提で書かれたため）。#1513で並び替えが導入された後、Instagram/TikTok/YouTubeのいずれかが並び替えで先頭に来ると、自前の区切り線とコンテナ側の共通区切り線が連続して二重表示される不具合があった（#1615で修正）。

これらのセクションより後ろに続く所属ユニット・関連リリース・選曲した楽曲・関連ライブの各セクションは、この並び替えの対象外で従来通りの固定順のまま。

編集モード

前/次ナビゲーション順序: 世代・加入日昇順でソートしたメンバーリストの前後インデックス。

Ameba投稿 / Exa検索結果セクション（#1513）

• 表示条件: 常に表示する。latestStatusは全メンバーが必須で持つデータのため、Instagram/TikTok/YouTube投稿セクションのような「対象0件ならセクション非表示」の概念はない。ただし直近30日以内の更新が無い場合は本文を表示せず「近況なし」バッジのみ表示する（#1503）
• 表示位置: SNS 投稿部内。他の3セクションとの並び順は前述「SNS 投稿部の並び順」を参照（固定位置ではない）
• データソース: member.statusHistory（未設定時はmember.latestStatus）
• 見出し判定ロジック: 表示中エントリのsourcesに、本人がofficialSnsへ公式登録しているAmebaブログのURLと一致するURL（hasOfficialSnsSourceMatchで判定）が含まれる場合は「Ameba投稿」、それ以外（Instagram Blob由来・他SNSドメイン限定Exa検索由来・一般Web検索Exa由来を含む）は「Exa検索結果」を見出しに表示する（#1513、判定ロジックはMorningStatusApp#1628で修正）
  • 備考: 旧実装（#1513当初〜#1628修正前）はsourcesのURLが単にameblo.jpドメインかどうか（extractAmebaIdで判定）だけを見ており、投稿者本人のブログかどうかを検証していなかった。公式Amebaブログを登録していないメンバーが一般Web検索（Exaのドメイン制限なし検索）で近況を収集した際、検索結果にたまたま他人のameblo.jp URLが混ざると「Ameba投稿」と誤表示される不具合があった（MorningStatusApp#1628）

Instagram 投稿セクション

• 表示条件: officialSns に instagram.com を含む active: true の URL が登録されているメンバーのみ表示。条件を満たさない場合はセクション自体を非表示にする
• 表示位置: SNS 投稿部内。他の3セクションとの並び順は前述「SNS 投稿部の並び順」を参照（#1513、固定位置ではない）
• データソース: Vercel Blob の instagram/{memberId}/posts.json（InstagramPost[] 型）
• 表示件数: 最新12件（capturedAt 降順）
• レイアウト: 3カラムグリッド

• データ未取得時: Instagram URL は登録されているが Blob に posts.json が存在しない場合は「まだ投稿データが取得されていません」を表示する（セクションは表示する）

TikTok 投稿セクション（#1513）

• 表示条件: 対象投稿が1件以上ある場合のみ表示する。対象は「公式チャンネル動画でのタグ付け（mentionedMemberIds に一致、主に現役メンバー）」または「自身のTikTokチャンネル投稿（channelType === 'og' かつ memberId 一致、OGメンバー）」のいずれか。現役メンバーは前者、OGメンバーは後者が中心となる（TikTokは現役メンバー自身のチャンネルを収集していないため）
• 表示位置: SNS 投稿部内。他の3セクションとの並び順は前述「SNS 投稿部の並び順」を参照（固定位置ではない）
• データソース: Neon tiktok_posts（getTikTokPosts()）
• 表示件数: 上限なし（対象条件に一致した全件、createdAt 降順）
• レイアウト: グリッド（auto-fill, minmax(140px, 1fr)）

• 参考表示に関する注記: 画像はあくまで参考表示であり権利は投稿者に帰属する旨、および参考表示の有効期限切れ時はリンクのみの表示になる旨を注記する

YouTube 動画セクション（#9）

• 表示条件: 公式チャンネル動画のタイトルにメンバーのフルネームが一致する動画が1件以上ある場合のみ表示する。officialSnsの登録有無やメンバー自身のYouTubeチャンネル登録有無は問わない（言及ベースの表示のため）。現役・OGを問わず公式チャンネル動画への言及のみが対象で、OGメンバー自身のYouTubeチャンネル（channelType: 'og'）の投稿はメンバー詳細画面には表示されない（TikTok投稿セクションと異なる点。ホーム画面の新着投稿セクションではOGメンバー個人チャンネルの動画も収集対象だが、メンバー詳細画面への導線はない。#1513時点では現状維持）
• 表示位置: SNS 投稿部内。他の3セクションとの並び順は前述「SNS 投稿部の並び順」を参照（固定位置ではない）
• データソース: Neon youtube_posts（channelType = 'official'）をgetAllOfficialYoutubePosts()で取得し、attributeYoutubeVideoToMembers()でフィルタする（詳細は youtube-data-design.md §6.1）
• 表示件数: 上限なし（マッチした全件）
• レイアウト: グリッド（TikTok投稿セクションと同様のパターン）

• 判定結果の保存: DBには保存せず、表示のたびに都度計算する（詳細は youtube-data-design.md §6.1）

4. リリース一覧画面（/releases）

概要: モーニング娘。（年号付き含む）のディスコグラフィーをフォーマット別（シングル・アルバム・EP・その他）に分けて表示する画面。サブユニット専用リリース（タンポポ・ミニモニ。・W 等の Unit.releaseIds に含まれるもの）は除外する。

表示コンテンツ

フォーマットラベル（ReleaseBadge）

5. リリース詳細画面（/releases/[id]）

概要: 特定リリースの詳細情報とメンバーを表示する画面。

表示コンテンツ

収録曲一覧セクション

• 配置場所: ソース URL とメンバーの間に配置する
• 表示項目:

• ゼロ件時: tracks フィールドが存在しない、または空配列の場合はセクション自体を非表示にする（「収録曲なし」等のメッセージは表示しない）
• マルチディスク構成: Track.discNumber が複数値を持つ場合は、ディスク番号ごとにグループ化して見出し（「Disc 1」「Disc 2」等）を表示する。全曲が同一ディスクの場合はグループ見出しを省略する
• ソート順: discNumber ASC, trackNumber ASC（discNumber が省略された場合は 1 として扱う）

6. 曲詳細画面（/songs/[id]）

概要: 特定楽曲（recording）の詳細情報・収録リリース・外部リンク・プレイリスト掲載情報を表示する画面。

URL パラメータ: [id] = Track.id（MusicBrainz recording UUID）

データソース: Neon DB（releases / tracks テーブル）を全走査し、Track.id が一致するトラックを特定する。同一 recording UUID は複数リリースに存在し得る（例: シングル収録後にアルバムにも収録）。

動的レンダリング: force-dynamic で Neon DB から最新データを取得する（getMembersFromBlob() / getReleases() を使用）。

表示コンテンツ

収録リリース一覧セクション

• 収録リリースが複数ある場合はリリース日昇順（古い順）で表示する
• 収録リリースが必ず1件以上存在することを前提とする（Track.id に一致するリリースが見つからない場合は notFound() を返す）

外部リンクセクション

• YouTube MV・YouTube Shorts はインライン表示のためこのセクションには含めない
• youtube・youtube-short・genius 以外のリンクが存在する場合のみセクションを表示する
• Track.links が空またはフィールド自体が存在しない場合はセクション自体を非表示にする

対比候補セクション

• 該当 track.id を持つ対比グループが存在する場合のみセクションを表示する
• 存在しない場合はセクション自体を非表示にする

プレイリスト掲載情報セクション（#366 完了後に実装）

• このトラックを選曲しているプレイリストが存在しない場合はセクション自体を非表示にする

リリース詳細画面からのリンク仕様

• リリース詳細画面（/releases/[id]）の収録曲一覧に表示される各曲名を、/songs/[Track.id] へのリンクにする
• Track.id が空文字列の場合はリンクなしでテキストのみ表示する（後方互換）
• リンクはインラインリンク（<Link>）で同一タブ遷移

7. 同期状況画面（/sync-status）

概要: 各種バッチ同期ジョブの最終実行状況・取得進捗をまとめて確認するデスクトップ専用画面。

アクセス制限: デスクトップモードでのみ表示。

データソース

表示コンテンツ（共通）

近況同期セクション

Instagram同期セクション

データが存在しない場合は「データがありません。Instagram同期を実行後に表示されます。」を表示。

Genius リンク同期セクション

データが存在しない場合は「データがありません。Genius リンク同期を実行後に表示されます。」を表示。

ディスコグラフィー同期セクション

データが存在しない場合は「データがありません。ディスコグラフィー同期を実行後に表示されます。」を表示。

DiscographyStatusChart 仕様

• Shorts 系列が表示される場合、棒の幅は 24px に縮小（非表示時は 40px）
• チャート上部の説明文: Shorts 系列あり → “YouTube / Shorts 取得進捗（過去 N 日分）”、なし → “YouTube リンク取得進捗（過去 N 日分）”（#836）

8. 楽曲リンク修正画面（/link-editor）

概要: シングル曲トラックの TikTok・YouTube・Genius リンクを手動で確認・編集するデスクトップ専用画面。

アクセス制限: デスクトップモードでのみ表示。

データソース

表示コンテンツ（共通）

トラック選択肢の絞り込み（isVersionTrack）

Instrumental・カラオケ等のバージョン違い楽曲を選択肢から除外する。以下のいずれかに該当するトラックは対象外:

• タイトル末尾が角括弧（< > / ＜ ＞）で終わる
• タイトル末尾の丸括弧（( ) / （ ））内に既知のバージョンキーワード（instrumental / off vocal / インスト / カラオケ / tv mix 等）を含む

TikTokタブ

YouTube／Geniusタブ

保存

• 追加・削除いずれかの変更がある場合のみ「保存」ボタンが活性化する
• PATCH /api/link-editor に { trackId, type, addUrls, removeUrls } を送信し、TrackLink を差分更新する（removeUrls を deleteMany した後、addUrls を create）
• 更新成功後、revalidateTag('releases', 'max') でデスクトップアプリ自身のキャッシュを無効化する。さらにデスクトップモードかつ APP_URL/REVALIDATE_TOKEN が設定されている場合、本番Web側のData Cache（getReleases()）も POST /api/revalidate 経由で無効化する（revalidateCache、lib/revalidate-cache.ts、#1600）
• 保存成功後は router.refresh() でサーバー側データを再取得する
• TikTok / YouTube / Genius の各タブは独立した保存状態（idle / saving / success / error）を持つ

API エンドポイント

アクセス制限: PUT はデスクトップモード（DESKTOP_MODE=1）でのみ許可し、それ以外は403を返す。

備考: 従来はサーバー側のアクセス制限が無く、編集ボタンの非表示（クライアント側の表示制御）のみに依存していた。本番Web環境に対して直接 PUT リクエストを送るとメンバーデータを書き換えられる状態だったため、他の編集系API（PATCH /api/link-editor・PUT/DELETE /api/tracks/[id]/youtube-link等）と同様の requireDesktopMode() ガードを追加した（MorningStatusApp#1603）。

PUT リクエストボディ

{
  "id": "string",
  "latestStatus": {
    "content": "string",
    "lastUpdated": "YYYY-MM-DD",
    "sources": ["url"]
  }
}

PUT 成功時: statusHistory に新エントリを蓄積（最大 100 件）、revalidatePath でデスクトップアプリ自身のキャッシュを無効化する。さらにデスクトップモード（DESKTOP_MODE=1）かつ APP_URL/REVALIDATE_TOKEN が設定されている場合、本番Web側のData Cacheも POST /api/revalidate 経由で無効化する（revalidateCache、lib/revalidate-cache.ts、#1600）。

備考: 従来は revalidatePath のみを呼んでおり、これはデスクトップアプリ自身の standalone サーバープロセスのキャッシュしか無効化しなかった。本番Webは別プロセス・別デプロイで独立したData Cache（getMembersFromBlob() の fetch(..., { next: { revalidate: 3600 } })）を持つため、デスクトップで編集・保存しても本番Webには最大1時間古いデータが表示され続ける不具合があった（#1600）。

youtubeChannel の解決（#1105）: youtubeChannel.handle が空・未指定の場合はフィールドを削除、既存と同一の場合は解決済 playlistId を引き継ぎ（API 呼び出しなし）、新規・変更時は YouTube Data API（fetchPlaylistId）でプレイリストIDに変換して保存する。変換できない場合は 422 を返し保存を中断する。

改訂履歴