プロF YouTube投稿 管理ツール 設計書v2

📌 ナツミ新要件（2026-07-07 03:31・急ぎ）：DBじゃなくWebの管理ツール。「Webの管理画面で、KPIが表示されてるのはもちろん、投稿後24時間とか決まった時間の再生数（サムネごと）をLINEで通知」。 v1（2026-07-06_youtube_manage_page_design）のNotion推し段階案は却下し、Webダッシュボード（v1のC案）を本線に据えて再設計。データ項目定義（パイプライン11項目・KPI10項目）はv1から流用する。

確定済み前提（v1のQ1〜Q3回答済み）

• 対象：めぐみさんのYouTubeチャンネル1本
• 利用者：チーム共有（ナツミ・めぐみさん・陽子P・みどりさん）
• 範囲：パイプライン管理＋KPI測定の両方
• 新要件：Web管理画面＋決まった時間（投稿後24h等）の再生数をサムネごとにLINE通知

1. 全体アーキテクチャ

┌─────────────────────┐
│ YouTube Data API v3 │  videos.list（statistics + snippet.thumbnails）
│                     │  channels.list（登録者数）
└─────────┬───────────┘
          │ 取得（毎時 cron・1コールで最大50動画まとめ取り）
          ▼
┌─────────────────────────────────────────────┐
│ Cloudflare Workers（1プロジェクトに集約）      │
│                                             │
│  ① cron trigger（毎時 0分）                  │
│     ├ 再生数・登録者数を取得                   │
│     ├ D1 に時系列スナップショット保存           │
│     └ 通知条件チェック（24h/72h/1週/1ヶ月到達） │
│         └ 未通知なら → LINE push（サムネ付き）  │
│                                             │
│  ② fetch handler                            │
│     ├ /api/*  … D1読み書きAPI（画面用）        │
│     └ 静的アセット配信（管理画面HTML/JS）       │
│         └ パスコード保護ミドルウェア             │
│           （n-youtube の _middleware.js 方式移植）│
└──────────┬──────────────────┬───────────────┘
           │                  │
           ▼                  ▼
┌──────────────────┐  ┌─────────────────────┐
│ Cloudflare D1     │  │ LINE Messaging API   │
│ videos            │  │ push（Flexメッセージ： │
│ snapshots（時系列）│  │ サムネ画像＋再生数＋   │
│ notifications     │  │ 動画リンクボタン）      │
└──────────────────┘  └─────────────────────┘
           ▲
           │ 閲覧・手入力（パイプライン・CTR等）
┌──────────┴──────────────────────┐
│ Web管理画面（チーム共有）          │
│ ・パスコード保護（30日cookie）     │
│ ・noindex,nofollow 必須           │
│ ・ダッシュボード／動画詳細／        │
│   パイプライン管理                 │
└─────────────────────────────────┘

構成の要点

• Pages＋Workersの2プロジェクトに分けず、Workers 1本に集約する
  • 理由①：Pages Functions は cron trigger 非対応。定期取得には Workers が必須
  • 理由②：Workers は静的アセット配信に対応済み（プロF実績：project-f-competitor-research が Worker＋assets 構成）。画面もAPIもcronも1つの wrangler.jsonc で完結し、D1バインディングも1箇所
• パスコード保護は n-youtube（_deploy/youtube_site/functions/_middleware.js）で実績ある cookie 方式をWorkerのfetch handlerに移植（パスコード照合→30日cookie発行→以降素通し）。パスコードはハードコードせず Workers Secrets に置く（n-youtube はベタ書きだったので今回改善）
• noindex：全HTMLに <meta name="robots" content="noindex,nofollow">（cloudflare-noindex ルール準拠）
• サムネ画像：YouTube CDN（https://i.ytimg.com/vi/<videoId>/hqdefault.jpg）のURLをそのまま画面・LINE通知の両方で使う。自前ホスティング不要

cron頻度：毎時を推奨（15分毎にしない理由）

• 通知条件「投稿後24時間」は毎時チェックで最大59分の遅れ。通知の性質上（初速レポート）この遅れは実害なし
• VPH算出も毎時スナップショットで十分な解像度
• APIクォータ・D1書き込み量・無料枠すべてに余裕が生まれる
• 初速を分単位で追いたくなったら「公開後6時間だけ15分毎」等の細分化をv1以降で足せる

2. LINE通知の実装選択肢

本命：LINE Messaging API（push）

• 仕組み：LINE公式アカウント（Messaging APIチャネル）を新規作成 → botを通知先に参加させ → Workers cron から push message を送信
• 通知先の2択（要決定）：
  • a. プロF運営グループLINEに bot を招待 → グループの groupId に push（チーム全員が見える。おすすめ）
  • b. ナツミ個人 → userId に push（まず個人で試して、後からグループに広げる段階案も可）
• メッセージ形式：Flexメッセージ（hero画像＝サムネ、body＝タイトル・24h再生数・拡散率・VPH、footer＝動画リンク＋管理画面リンクのボタン）。サムネ画像つき通知の要件をこれ1通で満たす
  • 代替：image message（originalContentUrl＝サムネURL）＋text message の2通構成でも可。ただしFlexの方が1通で済み見た目も情報量も上
• 無料枠：LINE公式アカウントのフリープランは月200通。週2本投稿×4通知（24h/72h/1週/1ヶ月）でも月40通弱で余裕
• 注意：LINE Notify は2025年3月にサービス終了済みのため選択肢に入らない。Messaging API一択

代替案：Discord webhook（工数比較用）

• 工数：webhook URL発行だけで即動く（チャネル作成・審査・bot招待すべて不要）。実装30分レベル
• 見た目：embed にサムネ画像・タイトル・数値を載せられる（要件の見た目はほぼ同等に作れる）
• 難点：めぐみさん・チームはLINE運用が主軸。Discordはナツミの個人環境なので「チームに届く通知」という要件を満たさない
• 結論：本番はLINE。ただし開発中の動作確認用にDiscord webhookを併設する（クロちゃん側で即テストでき、LINEチャネル準備待ちの間もv1実装を止めない）

準備物と役割分担

• LINEチャネル作成：LINE Developersコンソールで Messaging APIチャネルを作成。誰のLINEビジネスIDで作るかを要決定（ナツミのビジネスIDで作る＝ナツミ管理が楽／めぐみさん側の公式アカウントに紐づける＝プロF資産になる。運用主体がナツミなので前者を推奨、ただしめぐみさんに一言確認）
• トークンの置き場：
  • 実行時：wrangler secret put LINE_CHANNEL_ACCESS_TOKEN（Workers Secrets。コードにもgitにも残さない）
  • 手元バックアップ：~/.claude/secrets/ 相当のローカル秘匿領域（gitリポジトリ外）
  • YouTube APIキー・管理画面パスコードも同じ扱い（Secrets：YOUTUBE_API_KEY / DASHBOARD_PASSCODE）

3. 画面設計（3画面＋登録フォーム）

画面①：ダッシュボード（トップ /）

KPI表示のメイン。動画ごとのサムネカードを新しい順に並べる。

┌──────────────────────────────────────────────┐
│ プロF YouTube 管理  [ダッシュボード][パイプライン] │
│ チャンネル登録者: 12,345（前週比 +123）           │
├──────────────────────────────────────────────┤
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │[サムネ画像]  │ │[サムネ画像]  │ │[サムネ画像]  │ │
│ │動画タイトルA │ │動画タイトルB │ │動画タイトルC │ │
│ │公開 7/05    │ │公開 7/01    │ │公開 6/24    │ │
│ │▶ 現在 8,900 │ │▶ 現在 25,600│ │▶ 現在 41,200│ │
│ │24h: 3,200   │ │24h: 6,100   │ │24h: 5,800   │ │
│ │72h: —(未達) │ │72h: 14,300  │ │72h: 13,900  │ │
│ │VPH: 133     │ │VPH: 85      │ │VPH: 24      │ │
│ │拡散率 0.7x   │ │🔥拡散 2.1x  │ │🔥拡散 3.3x  │ │
│ │ ∿∿∿ 推移    │ │ ∿∿∿ 推移    │ │ ∿∿∿ 推移    │ │
│ └────────────┘ └────────────┘ └────────────┘ │
│ [＋動画を登録]                                  │
└──────────────────────────────────────────────┘

• カード要素：サムネ／タイトル／公開日／現在再生数／24h・72h・1週・1ヶ月の節目再生数／VPH（直近1時間の伸び）／拡散率バッジ（再生数÷公開時登録者数、2倍以上で🔥拡散判定＝もえぞう基準）／再生推移スパークライン
• 並び替え：公開日順（デフォルト）／拡散率順／VPH順

画面②：動画詳細（/video/:id）

┌──────────────────────────────────────────────┐
│ ← 戻る                                        │
│ [サムネ大]  動画タイトルA                       │
│            公開: 2026-07-05 20:00 ・ ▶YouTube  │
├──────────────────────────────────────────────┤
│ 📈 再生数推移グラフ（時系列・毎時スナップショット）│
│    （24h/72h/1週の節目に縦線マーカー）           │
├──────────────────────────────────────────────┤
│ 節目KPI：24h 3,200 ／ 72h — ／ 1週 — ／ 1ヶ月 —│
│ 拡散率 0.7x ／ VPH推移 ／ 高評価 210 ／ コメ 45  │
├──────────────────────────────────────────────┤
│ ✍️ 手入力KPI（YouTube Studioから転記）          │
│  CTR [   ]% ／ 平均視聴維持率 [   ]% ／         │
│  流入内訳 [ブラウジング_%/検索_%/関連_%]／       │
│  LINE誘導数 [   ]                              │
├──────────────────────────────────────────────┤
│ 🔔 通知履歴：24h通知 7/06 20:05 送信済 ✅        │
└──────────────────────────────────────────────┘

• 自動KPI（再生数・高評価・コメント・VPH・拡散率）と手入力KPI（CTR・維持率・流入内訳・LINE誘導数）を明確に分ける。後者はYouTube Data APIでは取れない（→ §7 制約）

画面③：パイプライン管理（/pipeline）— v2で実装

v1で定義したパイプライン11項目（動画ID・企画名・企画タイプ・ターゲット層・タイトル案・サムネ・台本ステータス・撮影日・編集担当・公開予定日・公開URL・ステータス）をステータス列のカンバン風テーブルで置く。

┌──────────────────────────────────────────────┐
│ パイプライン  [＋新規企画]                       │
│ ステータス: [企画][台本][撮影済][編集中]          │
│            [サムネ待ち][予約済][公開済]           │
├──────────────────────────────────────────────┤
│ YT-2026-004 │すてきた5  │台本レビュー中│みどり... │
│ YT-2026-005 │ロードマップ│サムネ待ち   │ナツミ... │
│  → 行クリックで編集フォーム（11項目）             │
│  → 「公開済」にした時にYouTube URLを紐づけると    │
│    KPI自動取得の対象に入る（videos に昇格）       │
└──────────────────────────────────────────────┘

• 置き場所の判断：パイプラインは独立画面にする（ダッシュボードは「公開後の成果を見る場」、パイプラインは「公開前の進行を回す場」で、見るタイミング・更新する人が違うため）。ダッシュボード上部に「進行中◯本」のリンクバッジだけ出して行き来できるようにする

登録フォーム（v0の入口）

• ダッシュボードの「＋動画を登録」→ YouTube URLを貼るだけ。Worker が videoId を抽出し videos.list でタイトル・サムネ・公開日時を自動取得してD1へ登録

4. データモデル（D1テーブル定義案）

⚠️ workspace内にD1の既存利用はゼロ（今回が初）。wrangler d1 create prof-youtube から始める。

-- 動画マスター
CREATE TABLE videos (
  id            INTEGER PRIMARY KEY AUTOINCREMENT,
  video_id      TEXT UNIQUE,            -- YouTube videoId（パイプライン段階はNULL可）
  internal_id   TEXT UNIQUE NOT NULL,   -- 例: YT-2026-001
  title         TEXT,
  thumbnail_url TEXT,                   -- i.ytimg.com のURL
  published_at  TEXT,                   -- ISO8601（公開後にセット）
  subs_at_publish INTEGER,              -- 公開時点の登録者数（拡散率の分母）
  -- パイプライン11項目（v2で使用・v0では大半NULLでOK）
  plan_name     TEXT,                   -- 企画名
  plan_type     TEXT,                   -- ①マス向け中尺 / ②教育系完全攻略
  target        TEXT,                   -- ターゲット層
  title_drafts  TEXT,                   -- タイトル案（JSON配列）
  thumb_status  TEXT,                   -- サムネ：案/確定/担当
  script_status TEXT,                   -- 未着手/執筆中/レビュー中/確定
  shoot_date    TEXT,
  editor        TEXT,
  publish_plan  TEXT,                   -- 公開予定日
  status        TEXT NOT NULL DEFAULT '企画',
                -- 企画/台本/撮影済/編集中/サムネ待ち/予約済/公開済
  -- 手入力KPI（Data APIで取れない分）
  ctr           REAL,
  retention     REAL,
  traffic_mix   TEXT,                   -- JSON: {browse, search, suggested}
  line_leads    INTEGER,
  created_at    TEXT NOT NULL DEFAULT (datetime('now')),
  updated_at    TEXT NOT NULL DEFAULT (datetime('now'))
);

-- 時系列スナップショット（毎時cronが追記）
CREATE TABLE snapshots (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  video_id    TEXT NOT NULL,            -- YouTube videoId
  fetched_at  TEXT NOT NULL,            -- ISO8601
  view_count  INTEGER NOT NULL,
  like_count  INTEGER,
  comment_count INTEGER,
  subscriber_count INTEGER              -- 取得時点のチャンネル登録者数
);
CREATE INDEX idx_snapshots_video ON snapshots(video_id, fetched_at);

-- 通知の重複防止＋履歴
CREATE TABLE notifications (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  video_id    TEXT NOT NULL,
  milestone   TEXT NOT NULL,            -- '24h' / '72h' / '1w' / '1m'
  sent_at     TEXT NOT NULL,
  view_count  INTEGER,                  -- 通知時点の再生数（節目KPIとして画面表示に使う）
  channel     TEXT NOT NULL DEFAULT 'line',  -- 'line' / 'discord'
  UNIQUE(video_id, milestone, channel)  -- 同じ節目は1回だけ
);

• 節目KPI（24h/72h/1週/1ヶ月）の求め方：notifications.view_count に節目時点の値を記録（通知＝節目記録を兼ねる）。グラフは snapshots から描画
• VPH：直近2スナップショットの差分から算出（保存せず都度計算）
• 拡散率：最新view_count ÷ subs_at_publish（公開検知時に subs_at_publish を確定保存）

cron判定ロジック（毎時）

1. videos から published_at IS NOT NULL の動画IDを収集（公開1ヶ月超は取得対象から外して節約）
2. videos.list（50件/1コール）＋ channels.list → snapshots にINSERT
3. 各動画で now - published_at が 24h/72h/168h/720h を超え、かつ notifications に該当行がなければ → LINE push → notifications にINSERT

5. 段階実装プラン＋工数見積もり

v0：今週作れる最小（手動登録＋API取得＋画面表示）

• 内容：Workers＋D1新規セットアップ／URL貼り付け登録／「更新」ボタンで手動スナップショット取得／ダッシュボード（サムネカード・現在再生数・拡散率バッジ）／パスコード保護＋noindex
• 通知なし・cronなし・パイプラインなし
• 工数：1日（6〜8h）。D1が初利用なのでセットアップ・ローカル検証に2h程度のバッファを含む正直見積もり。画面はプレーンHTML＋fetchで作る（フレームワーク導入しない）
• 前提：YouTube APIキーとチャンネルIDがあれば着手できる（LINE不要）

v1：cron自動化＋LINE通知

• 内容：毎時cron trigger／節目判定→LINE Flexメッセージpush（サムネ・24h再生数・拡散率・リンク）／動画詳細画面（推移グラフ・通知履歴・手入力KPIフォーム）／Discord webhook併設（開発検証用）
• 工数：1〜1.5日（8〜12h）。内訳：cron＋判定ロジック 3h／Flexメッセージ設計・送信テスト 3h／詳細画面＋グラフ 4h／結合テスト 2h
• ⚠️ 別途待ち時間：LINEチャネル作成〜グループ招待の段取り（作業自体は30分だが、誰のIDで作るか・どのグループに入れるかの決定待ちが発生しうる）

v2：パイプライン管理＋チーム編集

• 内容：パイプライン画面（11項目CRUD・ステータスカンバン）／公開済み昇格フロー（URL紐づけ→KPI対象化）／編集の同時更新対策（updated_at楽観チェック程度）
• 工数：1.5〜2日（10〜16h）。フォームUI・入力バリデーション・チーム向けの使い勝手調整が地味に時間を食う

合計目安：3.5〜4.5日（連続ではなく段階リリース。v0を今週出し、LINE準備が整い次第v1、運用が始まってからv2）

6. 必要なものリスト（ナツミ／めぐみさん側で用意）

1. YouTube Data APIキー：Google Cloud Consoleで発行（ナツミのGoogleアカウントでOK・無料）→ v0着手の必須条件
2. めぐみさんのチャンネルID：チャンネルURLから確認（UC... 形式）→ v0必須
3. LINE Messaging APIチャネル：LINE Developersで新規作成。誰のLINEビジネスIDで作るか要決定（推奨：ナツミ管理・めぐみさんに一言確認）→ v1必須
4. 通知先の決定：プロF運営グループにbot招待（推奨）or ナツミ個人。グループなら招待後に groupId を取得 → v1必須
5. 管理画面パスコードの決定：チーム共有用の文字列1つ（n-youtube方式・30日cookie）→ v0必須
6. （任意・後回し可）YouTube Analytics API用のOAuth承認：CTR・視聴維持率・流入内訳まで自動化したい場合のみ。めぐみさん本人のGoogleアカウントでの承認操作が必要。当面は手入力運用とし、辛くなったら検討 → v3以降の話

7. リスク・制約（正直ベース）

• APIクォータ：videos.list は1コール=1ユニット（50動画まで同梱可）。毎時cron＋channels.list でも 1日50ユニット未満 vs 上限10,000/日。まったく問題なし
• CTR・視聴維持率・流入内訳はData APIでは取れない：これらはYouTube Analytics API（チャンネル所有者のOAuth必須）の領域。v2までは手入力欄で対応する設計にした（§3画面②）。ここを「全自動」と期待されるとギャップが出るので先に共有しておくのが安全
• 非公開動画：APIキーでは公開・限定公開のみ取得可。予約投稿（公開前は非公開扱い）は公開されるまで統計が取れない。→ cron側で「予約済ステータスの動画は公開検知（取得成功）した時点で published_at・subs_at_publish を確定」するフローにして吸収
• 登録者数非表示設定：チャンネルが登録者数を非公開にしていると subscriberCount が取れず拡散率が計算不能。めぐみさんチャンネルは公開想定だが要確認
• LINEのサムネ画像配信：Flex/imageメッセージの画像URLは https必須・JPEG/PNG。YouTubeサムネ（i.ytimg.com・https・JPEG）はそのまま条件を満たすため画像の再ホスティング不要。ただしYouTube側がサムネ差し替えされた場合、通知時点のURLは最新サムネを指す（過去サムネの保存はしない割り切り）
• LINE無料枠：フリープラン月200通。想定通知量（月40通前後）では余裕だが、将来「毎時レポート」のような使い方に広げると枯渇するので、高頻度通知はDiscord側に逃がす
• D1初利用：workspace内に前例がないため、ローカル開発（wrangler d1 execute --local）〜本番反映の手順確立に初回だけ時間がかかる。v0見積もりにバッファ込み
• 削除・非公開化された動画：videos.list のレスポンスから消える。cronは「取得できなかった動画」をエラーにせずスキップ＋画面上に「取得停止」表示

関連ファイル

• 設計v1（データ項目定義の出典・Notion案は却下）：2026-07-06_youtube_manage_page_design
• もえぞうさんYouTube運用メモ（拡散率2倍基準・VPH）：natsumi_memos
• プロF YouTubeマスターindex：index_prof_youtube
• パスコード保護の実装前例（n-youtube）：_deploy/youtube_site/functions/_middleware.js（コード参照用）
• Worker＋静的アセット構成の前例：30_departments/02_CTO/codex_claude_collab/projects/competitor_research/src/wrangler.jsonc（コード参照用）
• Cloudflare noindexルール：cloudflare-noindex
• プロFチーム関係者：reference_prof_team

改訂履歴

• 2026-07-07：v2初版作成。ナツミ新要件（Web管理ツール＋LINE通知・7/7 03:31）を受け、Notion案を却下しCloudflare Workers＋D1＋LINE Messaging API構成で再設計。アーキテクチャ・LINE通知比較・画面3面ワイヤー・D1テーブル定義・段階実装プラン（v0/v1/v2）・必要物6件・リスク8項目を定義。