バッチ設計書

最終更新: 2026-08-09

概要

MorningStatusApp は、最新情報を収集するために定期的に実行するバッチと、状況に応じて手動実行するバッチを GitHub Actions で運用している。これに加えて、GitHub Actions を介さず scripts/console/・scripts/patch/ 配下で手動実行するスクリプト群がある。

ワークフロー一覧

それ以外のスクリプト一覧

scripts/console/・scripts/patch/ 配下のスクリプト。フル仕様（O1〜O3）で記載する3件を除き、それ以外のスクリプト セクションの一覧表に概要のみ記載する。

ワークフロー

W1. メンバー近況同期バッチ

実行タイミング

OGメンバーの同期は OG_SYNC_WEEKDAYS 環境変数で実行曜日を制限できる。 デフォルト（空文字・未設定）は月曜のみ（曜日番号: 1）。 曜日判定（shouldSyncOG）は scripts/lib/og-sync.ts の共通モジュールで、 YouTube OG チャンネル投稿収集バッチ（W8）と共用している（#1104）。

公式SNS未登録（または全 active）のメンバーに対する Exa 一般Web検索は、 WEB_SEARCH_SYNC_WEEKDAYS 環境変数で実行曜日を制限できる。 デフォルト（空文字・未設定）は月曜のみ（曜日番号: 1）。 曜日判定（shouldSearchWebForNoSns）は scripts/lib/web-search-schedule.ts に実装している（#1307）。

処理フロー

Ameba RSS 解析（#1328）

officialSns に active な Ameba Blog エントリを持つメンバーは、Exa 検索を使わず Ameba の RSS フィードから直接近況を取得する（エンドポイント: https://rssblog.ameba.jp/{amebaId}/rss20.xml）。

RSS抽出仕様（CDATA改行対応・content=タイトルのみ格納・グループブログの誤帰属防止・新着蓄積・重複防止・pubDate変換等）の詳細は「Amebaブログ機能 データ設計書」§「RSS取得仕様」を参照（#1367）。

検索エンジン

• Exa Search API（exa-js SDK）
• SEARCH_API_KEY 未設定の場合はドライラン（検索なし・Blob 書き込みなし）

Exa Search API の料金体系（#1307）

• 従量課金制: Search 約 $7 / 1,000 リクエスト（出典: https://exa.ai/pricing）
• 新規登録時に $10 分の無料クレジットを付与（一度のみ、出典: https://exa.ai/docs/reference/billing）
• 支払い方法登録済みの場合、毎月 $7 分の無料クレジットを付与（当月末で失効・繰越不可、出典: https://exa.ai/docs/reference/billing）

2026-07-10 にクレジット枯渇で検索が失敗する事象が発生したため、公式SNS登録状況に応じて検索範囲を排他化し、 公式SNS未登録メンバーへの一般Web検索を WEB_SEARCH_SYNC_WEEKDAYS で週1回に制限している（#1307）。

日本語判定

ひらがな（U+3040-U+309F）の出現率が HIRAGANA_THRESHOLD（0.08 = 8%）以上の場合に日本語と判定。 日本語でないコンテンツは statusHistory に蓄積しない。

SNS チェック（snsCheck）の更新ロジック

注意: バッチは active: false への自動変更を行わない（#326）。SNS 検索で日本語コンテンツが取れなかった場合は「更新なし」として扱い、active は変更しない。

環境変数

注意: 秘匿すべき値（APIキー・トークン等）は Repository secrets に統一すること（Environment secrets は environment: 指定がないと注入されない）。曜日番号等の非機密な設定値は Repository variables に登録する（#1347）。

Vercel Blob への書き込み

await put(MEMBERS_BLOB_FILENAME, JSON.stringify({ members }), {
  access: 'public',
  addRandomSuffix: false,   // 固定 URL での上書き保存
  allowOverwrite: true,     // 既存ファイルを上書き
  cacheControlMaxAge: 60,   // CDNエッジキャッシュを最小値に短縮（未指定だとデフォルト1ヶ月キャッシュされる、#1442）
  token: process.env.BLOB_READ_WRITE_TOKEN,
});

members.json・デイリーダイジェスト（daily-digest/{日付}/blog.json。データ構造はW14参照）に続けて、Topページ新着投稿セクションのAmeba新着ウィンドウ判定に使う ameba/sync-status.json も書き込む。詳細（AmebaSyncStatus型・定期実行/手動実行での更新ロジック）は「Amebaブログ機能 データ設計書」§「新着表示の判定基準」を参照（#1387）。

W2. ディスコグラフィー同期バッチ

実行タイミング

処理フロー

1. Vercel Blob（`UNITS_BLOB_URL`）からユニット一覧を読み込み、MBID を持つユニットの重複排除済み MBID 一覧を取得
   → MBID を持つユニットが0件の場合は処理を中断
2. Neon DB から現在のリリースデータを取得（`getReleases()`、フェイルセーフ）
3. 各 MBID に対して MusicBrainz API からリリースグループを取得し、結果を結合
   → 全 MBID で取得0件の場合は既存データを維持して終了
4. リリースデータを正規化・重複排除
5. トラックリストを付与（既存キャッシュ再利用 / MusicBrainz から新規取得）
   → artist-credit から artist・artistMbid を取得
   → REFETCH_MISSING_ARTIST_CREDITS=1 の場合は artist 未設定トラックを持つリリースを強制再取得
   → 非楽曲トラックの自動除外（isNonSongTrack）: recording.video=true の映像トラック、インスト・カラオケ・MC・Opening・VTR 等
   → シングル（format: 'single'）は全エディション（Type A・Type B・限定盤等）のトラックを取得して recording UUID でマージし、
     エディション固有のカップリング曲（例: Nature is good!）が漏れなく取り込まれるようにする
   → アルバム・ライブアルバム等は最初のエディションのみ取得（#1058 で調査・判断予定）
6. Track.artistMbid / Track.artist をもとにユニット照合（assignUnitIds）
   → 照合優先度: MBID 一致 → 名前・年ベース（フォールバック）
7. 全トラックが同一 unitId のリリースを Unit.releaseIds に自動集約（assignReleaseIdsToUnits）
8. Track 単位の YouTube リンクを付与（`YOUTUBE_API_KEY` 設定時のみ）
   → プレイリスト掲載曲 ID を取得し、優先処理対象として `syncTrackLinks` に渡す
   → `syncTrackLinks`: YouTube MV URL（`youtube`）・YouTube Music URL（`youtube-music`）を track に付与
   → `syncTrackShortLinks`: シングル曲の YouTube Shorts URL（`youtube-short`）を付与（#774）
   → 1 回の実行あたりの上限: `YOUTUBE_MAX_CALLS_PER_RUN`（100 件）
   → リリース単位の YouTube MV URL 取得は廃止（Neon に保存先がなくクォータを空振りするため、#1123）
9. data/inputs/manual-releases.json から手動登録リリースを読み込み、MusicBrainz 取得分とマージ（mergeManualReleases）
   → ID 重複チェックを行い、既存リリースと ID が衝突する手動登録はスキップ
10. リリースデータ（MusicBrainz 取得分 + 手動登録分）を Neon DB に書き込み（`saveDiscographyToNeon`）
    → `release` テーブル: `createMany(skipDuplicates: true)`
    → `track` テーブル: `upsert` per track
    → `track_link` テーブル: `deleteMany` + `createMany` per track
11. units.json（releaseIds 更新済み）を Vercel Blob（`UNITS_BLOB_URL`）に書き戻し
12. 同期ステータス（`discography-status.json`）を Vercel Blob に書き戻し
    → リリース件数・YouTube 取得対象数・取得済み数・Shorts 取得対象数・Shorts 取得済み数を日次スナップショットとして保存（最大 30 件）

MusicBrainz API

• エンドポイント: https://musicbrainz.org/ws/2/
• 対象: Vercel Blob 上のユニット一覧の mbid フィールドを持つ全ユニット（重複排除済み MBID 一覧）
• レート制限: 秒間1リクエスト未満に制御（429 エラー時は指数バックオフで再試行）
• トラックリスト取得時に inc=recordings+artist-credits を指定し、Track.artist および Track.artistMbid を取得
• recording.video フラグが true のトラックは映像として除外（#1055）
• シングルはリリースグループ内の全リリース ID を取得し、全エディションをマージする（#1055）

ユニット照合（assignUnitIds）

各トラックの artist / artistMbid をもとに units.json と照合し Track.unitId を設定する。

既存の unitId（手動設定）は上書きしない。

releaseIds 自動集約（assignReleaseIdsToUnits）

全トラックが同一 unitId を持つリリース（コンピレーション等の混在リリースを除く）を、 対応するユニットの releaseIds に自動追加する。既存の releaseIds は保持し重複は除去する。

リリース正規化・重複排除

• releaseDate の空白・ゼロ詰め正規化（normalizeDate()）
• タイトル + 正規化リリース日をキーとした重複排除（deduplicateReleases()）

環境変数

W3. プレイリスト集計・インデックス生成スクリプト

概要

playlists.json が更新された際、メンバー詳細やリリース詳細での高速なデータ表示を可能にするための派生インデックス JSON を生成し、Vercel Blob に保存する。

実行タイミング

手動（プレイリスト更新時）。bun run build-playlist-index を実行。

選曲リリースの自動解決（Resolution）ロジック

プレイリストに登録された楽曲（trackId）が複数のリリースに含まれる場合、以下の優先順位で最適な releaseId を自動選択し、インデックスに反映する。

1. 形式優先順位: single > ep > album > other
   • プレイリスト側でアルバムが指定されていても、シングルが存在すればシングル盤を優先する。
2. 初出優先順位: 同一形式（例：複数のシングル）に収録されている場合、releaseDate が最も古いものを優先する。

環境変数

W4. Instagram 投稿収集バッチ

実行タイミング

処理フロー

1. auth_state.json を読み込み、Playwright ブラウザコンテキストを復元する
2. Instagram トップページにアクセスし、セッション有効性を確認する
   → ログインページへのリダイレクトを検知した場合は sessionStatus: 'expired' を Blob に書き込み終了（非ゼロ終了コード）
3. Vercel Blob からメンバーデータを取得する
   - OGメンバーは `OG_SYNC_WEEKDAYS` で指定した曜日のみ収集対象とする（Activeメンバーは常に対象。メンバー近況同期バッチ・YouTube OGチャンネル収集バッチと同一ルール、#1297）
   - officialSns に active な instagram.com URL を持つメンバーを対象とする
4. 各対象メンバーのプロフィールページにアクセスし、投稿 URL 一覧を収集する
5. 既存の posts.json と比較し、新規投稿のみを取得対象とする（差分検出）
6. 各新規投稿ページにアクセスし、メタデータを取得する
   - og:description からキャプションの1行目を取得する
7. サムネイル URL として `/p/{postId}/media/?size=m` 形式のリダイレクト URL を記録する（Vercel Blob への画像アップロードは行わない）
   - 収集時のサムネイル URL 有効性検証は行わない（Instagram が非ブラウザの HTTP リクエストを 429 で弾くため・#1114）。表示時に取得失敗した投稿はカード非表示で対応する（#1094）
8. instagram/{memberId}/posts.json を更新する（既存投稿を保持しつつ新規を先頭に追加）
9. instagram/daily-new-posts.json を今回の実行で新たに取得した投稿一覧で上書き保存する
10. instagram/sync-status.json を更新する
11. daily-digest/{日付}/instagram.json に実メンバー別の新着件数を書き込む（データ構造はW14参照）
12. `OFFICIAL_INSTAGRAM_ACCOUNTS`（`constants/instagram-official-accounts.ts`）の各アカウント（モーニング娘。公式・ミニモちゃん）について、daily-digest/{日付}/instagram-official.json にアカウント別の新着件数を書き込む（データ構造はW14参照）

Secret 運用手順

INSTAGRAM_AUTH_STATE は Playwright の storageState（Cookie等を含む JSON）。 Session 失効時（ワークフロー失敗時）に以下の手順で再登録する。

# 0. playwright のブラウザをインストール（初回のみ）
bunx playwright install chromium

# 1. ヘッドフルブラウザで Instagram にログインし、認証状態を保存する
bun run instagram:auth

# 2. 生成された auth_state.json を GitHub Actions Secret に登録する
gh secret set INSTAGRAM_AUTH_STATE < auth_state.json

# 3. auth_state.json を削除する（機密情報のため必ず削除）
rm auth_state.json

注意: Session の有効期間は数週間〜数ヶ月。ワークフローが認証エラーで失敗したらリポジトリオーナーにメール通知が届く（GitHub Actions の失敗通知）。

環境変数

注意: 秘匿すべき値（APIキー・トークン等）は Repository secrets に統一すること（Environment secrets は environment: 指定がないと注入されない）。曜日番号等の非機密な設定値は Repository variables に登録する（#1347）。

Blob 書き込みパス

注意: instagram/{memberId}/{postId}.jpg への画像保存は廃止された。

W5. TikTok 投稿収集バッチ

本節は、実装（RapidAPI + Neon）と乖離した旧アーキテクチャ（Playwright + Vercel Blob、ストレージがNeon移行前の#888当時の記述）のまま放置されていたため、#1489 対応時に現行実装に合わせて全面的に書き直した。

実行タイミング

処理フロー

1. Neon DB の tiktok_posts テーブルから既存 postId 一覧を取得する（postId はアカウント・チャンネル種別を問わずグローバルに一意なため、絞り込まず全件取得する）
2. `OFFICIAL_TIKTOK_ACCOUNTS`（`constants/tiktok-official-accounts.ts`）の各アカウント（モーニング娘。公式・ミニモちゃん）について、RapidAPI（`tiktok-scraper7.p.rapidapi.com`）の `/user/posts` を最新ページから呼び出し、既存 postId に到達するかページ上限（`MAX_PAGES`=10）に達するまで取得する
3. 取得した投稿を TikTokPost（channelType='official'、accountId 付き）に変換する
4. Vercel Blob からメンバーデータを取得し、キャプションのハッシュタグからメンバーへの紐付けを行う（`attributeTikTokPostToMembers`、詳細は次項）
5. 新規投稿のみを tiktok_posts に保存する（差分追加・skipDuplicates）
6. tiktok_sync_status（Neon、id=1固定の1行）を更新する。`lastSyncedAt`・`syncStatus`・`capturedMembersCount`・`totalTargetMembersCount`（`/sync-status` 画面向けの公式収集ステータス表示用）を毎回更新する。加えて、TOP新着投稿セクションの新着ウィンドウ判定用の `officialLastSyncedAt`/`officialLastAutoSyncedAt`/`officialPreviousAutoSyncedAt` も更新する（W15とは行を共有するが、official用カラムのみを更新しW15のog用カラムには触れない）。ウィンドウ判定ロジックの詳細は「[TikTok投稿機能 データ設計書](/design/sns/tiktok-data-design)」§4「新着表示の判定基準」を参照（#1489）
7. 投稿キャプションと楽曲タイトルを照合し、シングル曲へのTrackLink（`type='tiktok'`）を自動生成・修正する（`fixTikTokTrackLinks`・`syncTikTokTrackLinks`）
8. daily-digest/{日付}/tiktok.json に実メンバー別の新着件数を書き込む（データ構造はW14参照）
9. daily-digest/{日付}/tiktok-official.json にアカウント別の新着件数を書き込む（データ構造はW14参照）

キャプションベースのメンバー属性付与

メンバーへの紐付けは、収集時（本バッチ）にキャプションのハッシュタグから判定し、mentionedMemberIds としてDBに保存する（lib/tiktok-attribution.ts）。表示側は保存済みの値をそのまま用いる（アプリ実行時の都度計算ではない）。判定対象はキャプション内のハッシュタグ（# で始まるトークン）のみで、本文中の言及はハッシュタグに含まれていなければマッチしない（#1412）。

• ハッシュタグ内のフルネーム（正規化後）が部分一致すればマッチ
• フルネームが一致しない場合、苗字または名前（2文字以上のもの）が部分一致すればマッチ
• 異体字（﨑/崎・髙/高・栁/柳等）を正規化してからマッチング

環境変数

W6. イベント同期バッチ

実行タイミング

処理フロー

1. Vercel Blob からメンバーデータを取得する（MEMBERS_BLOB_URL）
   → 未設定の場合はメンバーイベントをスキップ（ドライラン）
2. Neon DB からリリースデータを取得する（releases テーブル）
3. Neon DB からライブデータを取得する（lives テーブル、ツアー・参加メンバー含む）
4. Neon DB からラジオ放送回データを取得する（radio_episodes テーブル、番組・出演メンバー含む）
5. 各ソースを events 形式に変換する
   - release  : releaseDate を Date に変換（YYYY-MM-DD / YYYY-MM / YYYY 形式に対応）
   - join     : profile.joinDate を加入イベントに変換
   - graduate : profile.gradDate を卒業イベントに変換（gradDate が null のメンバーはスキップ）
   - live     : ライブ公演を live イベントに変換（title が null の場合はツアータイトルにフォールバック）
   - media    : ラジオ放送回を media イベントに変換
6. 全イベントを events テーブルへ upsert する（source + sourceId で一意判定）
   → 既存レコードあり → UPDATE（date / type / title / members 等を更新）
   → 既存レコードなし → INSERT
7. 同期完了ログを出力する（created / updated / errors 件数）

upsert キー規則

環境変数

注意: 全シークレットは Repository secrets に統一すること（Environment secrets は environment: 指定がないと注入されない）。

ドライラン動作

フェイルセーフ

• Blob 取得失敗: 空配列を使用して処理を継続
• 外部 API エラー: console.error でログ出力後、次のメンバーの処理を継続
• MusicBrainz 0件取得: 既存データを維持して終了

GitHub Actions ワークフロー共通設定

env:
  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true  # Node.js 24 に早期移行（#310）
runs-on: ubuntu-latest

W7. YouTube 公式チャンネル投稿収集バッチ

実行タイミング

処理フロー

1. Neon DB の youtube_posts テーブルから channelType='official' の既存 videoId 一覧を取得する
2. ハードコードされた公式チャンネルハンドル（@morningmusume）ごとに以下を実行する
   - channels API（forHandle）でアップロードプレイリスト ID を取得する（fetchPlaylistId）
     → 取得できない場合は当該チャンネルをスキップ
   - playlistItems API で最新動画を取得する（fetchVideosFromPlaylist、最大 50 件）
   - 取得した動画を YoutubePost（channelType='official'）に変換する
3. 既存 videoId を除外した新規投稿のみを youtube_posts に保存する（差分追加・skipDuplicates）
4. youtube_sync_status（Neon、id=1固定の1行。W8と行は共有するが、official用カラムのみを更新しW8のog用カラムには触れない）を更新する。定期実行/手動実行での更新ロジックの詳細は「[YouTube投稿一覧機能 データ設計書](/design/sns/youtube-data-design)」§6.2「新着表示の判定基準」を参照（#1450）
5. daily-digest/{日付}/youtube-official.json にアカウント別（`@morningmusume`）の新規取得件数を書き込む（データ構造はW14参照）

エラーハンドリング

環境変数

注意: 全シークレットは Repository secrets に統一すること（Environment secrets は environment: 指定がないと注入されない）。

W8. YouTube OG チャンネル投稿収集バッチ

実行タイミング

ワークフローは毎日起動するが、OG の収集は OG_SYNC_WEEKDAYS 環境変数で指定した曜日のみ実行する （スクリプト内の shouldSyncOG（scripts/lib/og-sync.ts）で判定。メンバー近況同期バッチと同一ルール）。 デフォルト（空文字・未設定）は月曜のみ（曜日番号: 1）。

処理フロー

1. OG_SYNC_WEEKDAYS の対象曜日でなければ何もせず正常終了する
2. Vercel Blob からメンバーデータを取得し、youtubeChannel を持つ OG メンバー（status が Active 以外）を対象とする
3. 各対象メンバーについて playlistItems API で最新動画を取得する（fetchVideosFromPlaylist、最大 5 件）
   - playlistId は members.json の youtubeChannel に保存済みのため channels API は呼ばない
4. 取得した動画を YoutubePost（channelType='og'・memberId 付き）に変換する
5. メンバーごとに、今回取得分に含まれない古い投稿を youtube_posts から削除し、新規投稿を保存する（最新 5 件のみ保持）
6. youtube_sync_status（Neon、id=1固定の1行。W7と行は共有するが、og用カラムのみを更新しW7のofficial用カラムには触れない）を更新する。定期実行/手動実行での更新ロジックの詳細は「[YouTube投稿一覧機能 データ設計書](/design/sns/youtube-data-design)」§6.2「新着表示の判定基準」を参照（#1450）
7. daily-digest/{日付}/youtube-og.json にメンバー別の新着件数を書き込む（データ構造はW14参照）

エラーハンドリング

環境変数

注意: 秘匿すべき値（APIキー・トークン等）は Repository secrets に統一すること（Environment secrets は environment: 指定がないと注入されない）。曜日番号等の非機密な設定値は Repository variables に登録する（#1347）。

W9. メンバー関係性マップ 動的エッジ同期バッチ

概要

member_relationships テーブルのうち、ライブ・ラジオ・イベント共演から動的に導出されるエッジ（live-coappearance / radio-coappearance / event-coappearance）を再集計する。イベント同期バッチ（W6）の後続ステップとして同一ワークフロー（sync-events.yml）内で実行される。

実行タイミング

処理フロー

1. ライブ共演（live-coappearance）を集計する
   → member_lives → lives → tours（LEFT JOIN）を辿り、同一 liveId を共有するメンバーペアごとの共演回数を集計
   → label は Tour.title →（null時）Live.title →（両方null時）固定文言「ライブ共演」の順でフォールバック
2. ラジオ共演（radio-coappearance）を集計する
   → radio_members → radio_episodes → radio_shows を JOIN し、ペア×番組名ごとの共演回数を集計
3. イベント共演（event-coappearance）を集計する
   → events.members（String[]）を unnest してペアを展開し、ペア×イベントタイトルごとの共演回数を集計
   → type='live'（ライブ種別イベント）はライブ共演で別途集計するため除外する
4. ペアごとに、weight（全ラベル共通の合計共演回数）とは別にラベルごとの出現回数を集計し、最多出現ラベルを label に採用する（同数の場合は文字列順で決定的に選ぶ）
5. member_relationships から動的エッジ種別（live-coappearance / radio-coappearance / event-coappearance）を一括削除する
6. 集計結果を member_relationships に一括登録する（createMany, skipDuplicates: true）

環境変数

関連ドキュメント

ラベル算出ロジックの詳細・型定義・エッジ表示ルールは docs/design/member/member-map-data-design.md を参照。

W10. Genius リンク同期バッチ

概要

Neon 管理のリリースデータのうち、YouTube リンクを持ち Genius リンク未取得のトラックを対象に、Genius API（検索エンドポイント）から歌詞ページ URL を取得し、TrackLink（type: genius）として Neon に保存する。取得状況は同期状況画面（/sync-status）向けに genius-links-status.json（Vercel Blob）にも記録する。詳細設計は 歌詞サイトリンク機能 データ設計書 を参照。

実行タイミング

環境変数

W11. モーニング女学院放送データ収集バッチ

概要

X（@morning1422）の投稿からラジオ番組「モーニング女学院」の放送回・出演メンバー・オンエア楽曲を抽出し、Neon DB に保存する。詳細設計は ラジオオンエア収集 設計書 §4-1 を参照。

実行タイミング

新規放送分は register-manual-radio-episodes.ts（それ以外のスクリプト §定常運用）による手動登録に統一している。

環境変数

W12. ヤングタウン土曜日収集バッチ

概要

X（@yando_staff）の投稿からラジオ番組「ヤングタウン土曜日」の放送回・出演メンバー・オンエア楽曲を抽出し、Neon DB に保存する。詳細設計は ラジオオンエア収集 設計書 §4-2 を参照。

実行タイミング

新規放送分は register-manual-radio-episodes.ts（それ以外のスクリプト §定常運用）による手動登録に統一している。

環境変数

W13. メイボンソワ選曲データ収集バッチ

概要

STV 公式サイトの HTML を解析し、ラジオ番組「メイボンソワ」の放送回・選曲データを抽出して Neon DB に保存する。詳細設計は ラジオオンエア収集 設計書 §4-3 を参照。

実行タイミング

新規放送分は register-manual-radio-episodes.ts（それ以外のスクリプト §定常運用）による手動登録に統一している。

環境変数

W14. デイリーダイジェスト配信バッチ

概要

Instagram 投稿収集（W4）・TikTok 投稿収集（W5）・YouTube 公式チャンネル投稿収集（W7）・YouTube OG チャンネル投稿収集（W8）・メンバー近況同期（W1、Ameba ブログ分）・TikTok OGチャンネル投稿収集（W15）の各バッチが daily-digest/{日付}/{ソース}.json（Vercel Blob）に書き出した新着件数サマリーを集約し、1通のメール本文にまとめて送信する。

実行タイミング

処理フロー

1. MEMBERS_BLOB_URL からメンバーデータを取得する（未設定時はエラーで終了）
2. daily-digest/ 配下の Blob を列挙し、ソース種別
   （instagram/instagram-official/tiktok/tiktok-official/tiktok-og/youtube-og/youtube-official/blog）
   ごとに最新日付のファイル URL を取得する（resolveLatestDigestUrls）
   → 日付をまたいで各収集バッチが実行された場合でも最新のファイルを参照できる
3. 各ソースのダイジェストファイルを取得する
   → 取得失敗（fetch 失敗・非 200 応答）したソースはスキップし、警告ログを出力して処理を継続する
4. メンバー・投稿種別ごとに件数を集計する（buildDigestEmailBody）
   → `instagram-official`/`tiktok-official`/`youtube-official`（いずれも `OfficialSummaryEntry`）は、
     SNSごとに「モーニング娘。公式 2件、ミニモちゃん 1件」のようにアカウント名付きの内訳を
     「公式アカウント」セクションに表示する（Instagram公式アカウントにはモーニング娘。公式で
     ないミニモちゃんも含まれるため、セクション見出しは特定アカウント名ではなく「公式アカウント」とする）
   → それ以外（`blog`/`instagram`/`tiktok`/`tiktok-og`/`youtube-og`、いずれも実メンバーのみを持つ `MemberSummaryEntry`）は
     メンバー別セクションに振り分け、現役→OG・期（generation）昇順・加入日昇順でソートする
     （compareMemberSections）
   → 同一メンバーが複数ソースに新着を持つ場合は「Instagram 2件、ブログ 1件」のように読点区切りで1行にまとめる
   → 新着が1件もないソース・セクションは「（新着なし）」と表示する（新着なしでもメールは送信される）
5. 集計結果をメール本文としてローカルファイル（`daily-digest-email.txt`）に書き出す
6. 集約に使用した daily-digest/ 配下の Blob ファイルを削除する（del）
   → 削除は集計元ファイルの重複読み込み防止のためで、次回実行時は新規書き込み分のみを対象とする
7. GitHub Actions ワークフローが `daily-digest-email.txt` の内容を読み込み、
   dawidd6/action-send-mail でメールを送信する

ダイジェストファイルのデータ構造

daily-digest/{日付}/{ソース}.json は以下の各バッチが書き込む。source の値によって使用するデータ型（types/daily-digest.ts）が異なる。実メンバーの新着件数と公式・グループアカウントの新着件数は同一SNS内でもファイルを分け、youtube-og/youtube-officialの分割にならってinstagram/instagram-official・tiktok/tiktok-officialのように管理する（#1423）。

MemberSummaryEntry（実メンバー別新着件数）

実メンバー単位で新着を持つソース（blog/instagram/tiktok/tiktok-og/youtube-og）が使用する。公式・グループアカウントはこの型には含まれない（後述の OfficialSummaryEntry で別ファイルに分離する）。

OfficialSummaryEntry（公式・グループアカウント別新着件数）

公式・グループアカウントを持つ全ソース（instagram-official/tiktok-official/youtube-official）が共通で使用する型。アカウント単位でカウントを保持するため、1ソースにつき複数アカウントを個別に集計できる。

対象アカウント一覧

同日複数回実行時のマージ

同日に複数回実行された場合、書き込み時に putDigestEntry（lib/daily-digest.ts）が既存ファイルと同一の集計単位（MemberSummaryEntryはmemberId、OfficialSummaryEntryはaccountId）のcountを加算してマージする。

エラーハンドリング

環境変数

メール送信設定

メール送信ステップ（dawidd6/action-send-mail@v3）はスクリプト本体の環境変数とは別に、ワークフロー内で以下を使用する。

注意: daily-digest-email.txt が生成されなかった場合（MEMBERS_BLOB_URL 未設定等でスクリプトが早期にエラー終了した場合や、上記「エラーハンドリング」の Blob 削除失敗の場合）はメール送信ステップ自体がスキップされる。新着が0件の場合はファイルは生成されるため、その場合は「（新着なし）」を含むメールが送信される。

W15. TikTok OGチャンネル投稿収集バッチ（#1478）

概要

OGメンバー個人のTikTokアカウントの新着投稿を RapidAPI 経由で取得し、tiktok_posts（channelType='og'）に保存する。YouTube OG チャンネル投稿収集バッチ（W8）と同じ運用方式（メンバー編集画面での設定・OG_SYNC_WEEKDAYS・最新5件のみ保持）を採用するが、RapidAPIはハンドルのAPI解決が不要なため処理はより単純になる。詳細設計は TikTok投稿機能 データ設計書 §4を参照。

実行タイミング

ワークフローは毎日起動するが、OG の収集は OG_SYNC_WEEKDAYS 環境変数（YouTube OG収集と共用）で指定した曜日のみ実行する（shouldSyncOG（scripts/lib/og-sync.ts）で判定）。デフォルト（空文字・未設定）は月曜のみ（曜日番号: 1）。

処理フロー

1. OG_SYNC_WEEKDAYS の対象曜日でなければ何もせず正常終了する
2. Vercel Blob からメンバーデータを取得し、tiktokChannel を持つ OG メンバー（status が Active 以外）を対象とする
3. 既存 tiktok_posts から channelType='og' の既存 postId 一覧を取得する（新着件数の集計に使用）
4. 各対象メンバーについて fetchUserPosts（RapidAPI、unique_id=tiktokChannel.username）を1ページ（先頭5件）のみ呼び出し、
   最新5件を取得する（公式アカウント収集と異なり、既存 postId に到達するまでページを遡る差分取得は行わない）
5. 取得した投稿を TikTokPost（channelType='og'・memberId 付き、mentionedMemberIds は常に空配列）に変換する
6. メンバーごとに、取得した最新5件に含まれない投稿を tiktok_posts から削除したうえで、取得した5件を保存する
   （結果としてメンバーごとに常に最新5件のみが残る）
7. daily-digest/{日付}/tiktok-og.json にメンバー別の新着件数を書き込む（データ構造はW14参照）
8. tiktok_sync_status（Neon、id=1固定の1行。W5と行は共有するが、og用カラムのみを更新しW5のofficial用カラムには触れない）の `ogLastSyncedAt`/`ogLastAutoSyncedAt`/`ogPreviousAutoSyncedAt` を更新する。TOP新着投稿セクションの新着ウィンドウ判定用フィールドであり、`/sync-status` 画面向けの公式収集ステータス表示用フィールド（`syncStatus`等）には触れない。定期実行/手動実行での更新ロジックの詳細は「[TikTok投稿機能 データ設計書](/design/sns/tiktok-data-design)」§4「新着表示の判定基準」を参照（#1489）

注意（旧: tiktok_sync_status を更新しない設計だった理由、#1478時点）: 当初（#1478時点）は、YouTube が youtube_sync_status を official/og で独立カラム化しTOP新着投稿セクションのウィンドウ判定に使っている（W7・W8、#1450）のに対し、TikTokの tiktok_sync_status はTOP新着投稿セクションのウィンドウ判定には使われておらず /sync-status 画面の公式収集ステータス表示専用だったため、OG収集はこのテーブルを更新しない設計だった。その後、W5の「同日capturedAt + 件数キャップ」方式では複数アカウント・複数OGメンバーの同時収集時に新着を取りこぼす不具合が判明したため、YouTubeと同じofficial/og独立ウィンドウ方式に変更し、OG収集もtiktok_sync_statusのog用カラムを更新するようになった（#1489）。

エラーハンドリング

環境変数

注意: 秘匿すべき値（APIキー・トークン等）は Repository secrets に統一すること（Environment secrets は environment: 指定がないと注入されない）。曜日番号等の非機密な設定値は Repository variables に登録する（#1347）。

それ以外のスクリプト

scripts/console/・scripts/patch/ 配下の、GitHub Actions を介さず手動実行するスクリプト。用途に応じて以下に大別される。

• 定常運用スクリプト: データ更新や運用作業のたびに繰り返し手動実行するもの
• 一回限りパッチ: 特定の不具合修正・データ移行のために作成され、既に実行済みで再実行を想定しないもの
• 開発用・共通ヘルパー: 単体実行を想定しない補助コードや、開発時のアドホックな動作確認用コード

うち3件（O1〜O3）は稼働中バッチと同水準のフル仕様で記載し、残りは概要のみの一覧表で管理する。

O1. 曲対比インデックス生成スクリプト

概要

releases.json を元に、タイトル前方一致でバリアント曲をグルーピングし、対比ペアインデックスを生成・Vercel Blob に保存する。 ライブアルバム・サウンドトラックは自動的に対比対象から除外される。

実行タイミング

手動実行。以下の場合に再生成する:

• リリースデータ（releases.json）に新規リリース・トラックの追加が加わった後
• 除外パターンファイル（comparison-exclude-patterns.json）を更新した後
• タイトルエイリアスファイル（title-aliases.json）を更新した後

実行コマンド

# 環境変数をあらかじめ設定した上で実行
BLOB_READ_WRITE_TOKEN=<token> RELEASES_BLOB_URL=<url> bun run scripts/console/build-comparison-index.ts

または .env.local に環境変数を設定してから:

bun run scripts/console/build-comparison-index.ts

生成ファイル

処理概要

1. scripts/comparison-exclude-patterns.json から除外ベースタイトル一覧を読み込む
2. scripts/title-aliases.json からタイトルエイリアスマップを読み込む
3. RELEASES_BLOB_URL から releases.json を取得
4. ライブアルバム・サウンドトラックを除いた全リリースのトラックを Track.id で重複排除（collectUniqueTracks）
5. エイリアスマップをトラックタイトルに適用し、バリアント表記を正規タイトルに統一
6. タイトル前方一致 + セパレータ判定（isVariantOf）でバリアントをグルーピング
7. 2 曲以上かつ除外パターンに一致しないグループを対比ペアとして採用（buildComparisonPairs）
8. 各トラックの代表リリースフォーマット（releaseFormat）を解決して記録
9. ベースタイトルの表記ゆれを正規化比較で検出し、title-aliases.json に自動追記
10. comparison-index.json と track-comparison-map.json を Vercel Blob に書き込み

補助ファイル

scripts/comparison-exclude-patterns.json — 除外パターン

対比対象から除外したいベースタイトルの部分文字列を baseTitles 配列に列挙する。 ベースタイトルに指定文字列が部分一致する場合にそのグループを除外する。

{
  "baseTitles": ["MC", "SE"]
}

上記の例では、ベースタイトルに “MC” または “SE” を含むグループ（例: “MC Battle”）が除外される。

scripts/title-aliases.json — タイトルエイリアス

MusicBrainz 上の表記ゆれ（全角/半角スペース差異など）を吸収するため、 バリアントタイトルから正規タイトルへのマッピングを定義する。

{
  "aliases": {
    "Song　A": "Song A"
  }
}

• キー: バリアントタイトル（置換前）
• 値: 正規タイトル（置換後）
• エイリアス適用はインデックス生成内のみ。元の releases.json は変更されない
• スクリプト実行時に未登録の表記ゆれが検出された場合、[WARN] ログとともに自動追記される

実行後の手順

生成後に表示される Blob URL を環境変数に設定すること。

環境変数

O2. 非楽曲トラック削除パッチ（一回限り・#1057）

概要

#1055 の sync スクリプト改修前に Neon DB に蓄積した非楽曲トラック（タイトルからインスト・カラオケ・MC と判定されるトラック）を削除し、 RadioOnairSong および playlists.json からの参照を事前にクリアする一回限りのパッチスクリプト。

実行手順

# .env.local に以下を設定してから実行
# DATABASE_URL=...
# BLOB_READ_WRITE_TOKEN=...
# PLAYLISTS_BLOB_URL=...  (省略可: 未設定時はローカルの data/inputs/playlists.json を使用)

# 1. まず --dry-run で削除対象を確認する
bun scripts/patch/patch-delete-non-song-tracks.ts --dry-run

# 2. 内容を確認したら本実行する
bun scripts/patch/patch-delete-non-song-tracks.ts

処理フロー

1. Neon DB の tracks テーブルからすべてのトラックを取得する
2. タイトルパターン（isNonSongTrack）で非楽曲トラックを特定する
   → recording.video フラグは DB に保存されていないため、タイトルパターンのみで判定
   → 映像トラック（Dance Shot Ver. 等）は sync-discography 再実行時に自然と除外される
3. RadioOnairSong.trackId が対象 trackId を参照している行を NULL に更新する
4. playlists.json（Blob + ローカルファイル）の entries.trackId / releaseId をクリアする
   → PLAYLISTS_BLOB_URL 未設定時はローカルファイルのみ更新
5. 非楽曲トラックを tracks テーブルから削除する
   → track_links は onDelete: Cascade で自動削除

環境変数

注意事項

• 冪等性あり: 削除対象がない場合は何もしない（再実行可能）
• パッチ実行後は sync-discography を再実行し、欠落していた楽曲（Nature is good! 等）を補完すること

O3. メンバー関係性マップ 静的エッジシードスクリプト

概要

member_relationships テーブルのうち、メンバー・ユニットのプロフィールデータから機械的に導出できる静的エッジ（同期・同郷・同ユニット・同時在籍・リーダー継承・師弟関係の6種別）を生成する定常運用の手動実行スクリプト。メンバー・ユニットデータの更新時（加入・卒業・出身地変更・ユニット編成変更等）に再実行する。W9の動的エッジ同期とは異なり、GitHub Actions ワークフローには組み込まれていない。

実行タイミング

処理フロー

1. Vercel Blob からメンバーデータ（MEMBERS_BLOB_URL）・ユニットデータ（UNITS_BLOB_URL）を取得する
2. 静的エッジを生成する（generateEdges）
   1. 同期（same-gen）: 同一 generation の全ペアに無方向エッジ（weight=1）
   2. 同郷（same-hometown）: 同一 profile.birthplace の全ペアに無方向エッジ（weight=1）
   3. 同ユニット（same-unit）: モーニング娘。本体・年度別ユニット（morning-musume / morning-musume-*）を除くサブユニットのうち、メンバー2名以上のユニット内の全ペアに無方向エッジ（label にユニット名）
   4. 同時在籍（overlapping）: 加入日〜卒業日（未卒業は現在日扱い）の期間が重なる全ペアに無方向エッジ（weight=1）
   5. リーダー継承（leader-succession）: leaderGenerationNumber が連番で隣接するペアに有向エッジ（前任→後任）
   6. 師弟関係（mentor-student）: profile.instructor に列挙された師匠 ID ごとに有向エッジ（fromMemberId=師匠、toMemberId=弟子、weight=1）
3. member_relationships から静的エッジ種別（6種）を一括削除する
4. 生成したエッジを member_relationships に一括登録する（createMany, skipDuplicates: true）
5. 種別ごとの生成件数をログ出力する

weight / label（現状）

環境変数

スコアリング組み込みによる変更点（実装: #1269）

関係性スコアリングロジックの実装（#1269）により、以下の変更を加える。計算式の詳細は docs/design/member/member-map-data-design.md §8 を参照。

• overlapping の weight 算出方法変更: 現状の weight=1 固定から、重なり月数を 0〜40pt に正規化した値に変更する（上限120ヶ月=10年で満点、以降40pt上限）
• mentor-student の direct/indirect 判定:
  • 既存の direct エッジ（profile.instructor 由来、depth=1）は weight=30・label='direct' に更新する
  • profile.instructor の連鎖を depth 2 以上たどって到達できるメンバーペア（indirect）を新たに算出し、weight=15・label='indirect' で追加する
  • 循環参照防止: 連鎖探索は訪問済みメンバー ID を Set で管理し、既訪問メンバーには再度たどらない
• data/inputs/manual-mentor-relationships.json のマージ: 連鎖では拾えない師弟関係（本人の発言による影響表明等）を手動追記するファイル（初期状態は空）を新設し、data/inputs/manual-releases.json と同様のパターンで sync 時にマージする

定常運用スクリプト一覧

O1・O3 を除く、繰り返し手動実行することを想定したスクリプト。

一回限りパッチ一覧（実行済み）

O2 を除く、特定の不具合修正・データ移行のために作成され、既に実行済みで再実行を想定しないスクリプト。

開発用・共通ヘルパー

単体実行を想定しない補助コード、または開発時のアドホックな動作確認用コード。

改訂履歴