Public Preview公開・検証前の Blueprint です（「確認済み」ではありません）。

毎朝の情報収集・AI要約ダイジェスト（定期情報収集・AI要約システム）v2

複数の公開情報源を定期収集し、AIで重要点を要約し、保存して、毎日確認できる形で届ける。

Version 2独立システム N=9証拠レコード 60
自分の環境と比較する — 無料で StackLens を始める →

完成後にできること

この構成を作ると、実データで確認された範囲で次のことができます。

  • 1情報源を取得する
  • 2定期的に自動実行する
  • 3AIで要点をまとめる
  • 4収集結果を保存する
  • 5結果を受け取る

システム構成

役割による層（入力→処理→出力）。実データで観測された要素のみ。

入力情報の取得5
情報源の取得（いずれか1つ以上）
RSS取得（具体手段）RSS fetchers (Substack/blog/podcast/news) +4
X/Twitter 収集X/Twitter 収集X/Twitter timeline via Playwright + cookies +3
メール/ニュースレター収集email newsletters via IMAP / Gmail OAuth2 +1
YouTube 収集YouTube 収集YouTube transcripts via Supadata API +2
処理処理・保存5
定期実行スケジューラGitHub Actions cron (daily 09:00 Beijing) +7
AI要約処理Claude (Anthropic) via ANTHROPIC_API_KEY +8
永続保存Markdown files + dedup state.py +8
リレーショナルDB（Postgres/SQLite等）PostgreSQL +2
Vector DB + RAG（意味検索・Q&A）nomic-embed-text-v1.5 (768d) in PostgreSQL + pgvector; RAG via Claude Sonnet実例限定
出力配信・表示5
配信・表示（いずれか1チャネル以上）
配信・表示先（メール）HTML email +4
配信・通知（Telegram/Slack等）Telegram (README marks untested) +5
ダッシュボードUIweb dashboard (demo.rssbrew.com) +1
Notion 出力Notion 出力Notion daily database pages実例限定

接続線は構成レイヤー（役割の流れ）を示します。個々のツール間の正確な接続は、Evidence で確認できた場合のみ別途表示します。

使用ツール / 始める前に必要なもの

観測された実装と Blueprint の要件です。

  • 定期実行スケジューラ

    GitHub Actions cron (daily 09:00 Beijing) / APScheduler (ingest every 6h; daily briefing 09:00 IST) / daily/weekly digest (scheduler tool not named) / GitHub Actions cron (daily 07:30 UTC) / fetch interval (FETCH_DEFAULT_INTERVAL_MINUTES) + cron digests / central feed updated daily (scheduler tool not named) / cron-based daily jobs (SUMMARY_CRON_HOUR/MINUTE) / macOS launchd (7am/7pm daily)

  • AI要約処理

    Claude (Anthropic) via ANTHROPIC_API_KEY / Gemini Flash via OpenRouter (summary); Claude Sonnet (RAG) / OpenAI-compatible models (user configured) / litellm (OpenAI / Anthropic / Cohere) / OpenRouter free models (categorize + summarize, rule-based fallback) / AI summarization (provider not named in README) / OpenAI gpt-4-turbo-preview / Google Gemini 3 Flash / Google Gemini 2.5 Flash (via Vertex AI)

  • 永続保存

    Markdown files + dedup state.py / PostgreSQL (14-day rolling window) / database via Docker (technology not named) / local history/ cache + TOML files / PostgreSQL 17 + PgBouncer / local files (~/.follow-builders, reading history on machine) / SQLite (aiosqlite) data/x_monitor.db / SQLite ~/.xdigest/xdigest.db / local files (data/ JSON + data/batches)

  • RSS取得（具体手段）

    RSS fetchers (Substack/blog/podcast/news) / feedparser + httpx (10 official RSS/Atom + arXiv Atom API, no scraping) / RSS feed aggregation + custom filters / RSS (TOML config) + Google Scholar Alerts + newsletters via kill-the-newsletter / RSS/Atom (UI/OPML) + optional Mozilla Readability full-text

  • X/Twitter 収集

    X/Twitter timeline via Playwright + cookies / X/Twitter via official API (26 curated builders) / X API via XDK (official SDK), incremental fetch / Playwright (CDP mode) scraping of FOLLOW_ACCOUNTS + linked article text

  • 配信・表示先（メール）

    HTML email / SMTP email / Symfony Notifier email / HTML email via SMTP (Gmail/QQ) / HTML email via Gmail SMTP

  • 配信・通知（Telegram/Slack等）

    Telegram (README marks untested) / Telegram bot (daily briefing + on-demand RAG) / GitHub Releases (daily-digest-YYYY-MM-DD) / Symfony Notifier (Telegram/Slack/Discord/Pushover) / Telegram / Discord / WhatsApp / Telegram + Markdown report

  • リレーショナルDB（Postgres/SQLite等）

    PostgreSQL / PostgreSQL 17 / SQLite

  • メール/ニュースレター収集

    email newsletters via IMAP / Gmail OAuth2 / newsletters via kill-the-newsletter.com conversion

  • ダッシュボードUI

    web dashboard (demo.rssbrew.com) / DaisyUI dashboard + Mercure SSE

  • YouTube 収集

    YouTube transcripts via Supadata API / YouTube podcast transcripts via Supadata (6 podcasts) / YouTube Data API v3 (subscriptions, last 3 days)

  • Vector DB + RAG（意味検索・Q&A）

    nomic-embed-text-v1.5 (768d) in PostgreSQL + pgvector; RAG via Claude Sonnet

  • Notion 出力

    Notion daily database pages

必須（最初に用意）

  • ・情報源の取得（いずれか1つ以上）
  • ・定期実行スケジューラ
  • ・AI要約処理
  • ・永続保存
  • ・配信・表示（いずれか1チャネル以上）

後から追加

  • ・RSS取得（具体手段）
  • ・X/Twitter 収集
  • ・配信・表示先（メール）
  • ・配信・通知（Telegram/Slack等）
  • ・リレーショナルDB（Postgres/SQLite等）

必要になったら

  • ・メール/ニュースレター収集
  • ・ダッシュボードUI
  • ・YouTube 収集
  • ・Vector DB + RAG（意味検索・Q&A）
  • ・Notion 出力

なぜこの構成なのか

NOW — 最初に作る

まず動く最小構成。9システムの共通核（scheduler は 8/9）。

  • 情報源の取得（いずれか1つ以上）
  • 定期実行スケジューラ

    GitHub Actions cron (daily 09:00 Beijing) / APScheduler (ingest every 6h; daily briefing 09:00 IST) / daily/weekly digest (scheduler tool not named) / GitHub Actions cron (daily 07:30 UTC) / fetch interval (FETCH_DEFAULT_INTERVAL_MINUTES) + cron digests / central feed updated daily (scheduler tool not named) / cron-based daily jobs (SUMMARY_CRON_HOUR/MINUTE) / macOS launchd (7am/7pm daily)

  • AI要約処理

    Claude (Anthropic) via ANTHROPIC_API_KEY / Gemini Flash via OpenRouter (summary); Claude Sonnet (RAG) / OpenAI-compatible models (user configured) / litellm (OpenAI / Anthropic / Cohere) / OpenRouter free models (categorize + summarize, rule-based fallback) / AI summarization (provider not named in README) / OpenAI gpt-4-turbo-preview / Google Gemini 3 Flash / Google Gemini 2.5 Flash (via Vertex AI)

  • 永続保存

    Markdown files + dedup state.py / PostgreSQL (14-day rolling window) / database via Docker (technology not named) / local history/ cache + TOML files / PostgreSQL 17 + PgBouncer / local files (~/.follow-builders, reading history on machine) / SQLite (aiosqlite) data/x_monitor.db / SQLite ~/.xdigest/xdigest.db / local files (data/ JSON + data/batches)

  • 配信・表示（いずれか1チャネル以上）

NEXT — 動いた後に追加

反復して確認された要素（X収集はここ・4/9）。

  • RSS取得（具体手段）

    RSS fetchers (Substack/blog/podcast/news) / feedparser + httpx (10 official RSS/Atom + arXiv Atom API, no scraping) / RSS feed aggregation + custom filters / RSS (TOML config) + Google Scholar Alerts + newsletters via kill-the-newsletter / RSS/Atom (UI/OPML) + optional Mozilla Readability full-text

  • X/Twitter 収集

    X/Twitter timeline via Playwright + cookies / X/Twitter via official API (26 curated builders) / X API via XDK (official SDK), incremental fetch / Playwright (CDP mode) scraping of FOLLOW_ACCOUNTS + linked article text

  • 配信・表示先（メール）

    HTML email / SMTP email / Symfony Notifier email / HTML email via SMTP (Gmail/QQ) / HTML email via Gmail SMTP

  • 配信・通知（Telegram/Slack等）

    Telegram (README marks untested) / Telegram bot (daily briefing + on-demand RAG) / GitHub Releases (daily-digest-YYYY-MM-DD) / Symfony Notifier (Telegram/Slack/Discord/Pushover) / Telegram / Discord / WhatsApp / Telegram + Markdown report

  • リレーショナルDB（Postgres/SQLite等）

    PostgreSQL / PostgreSQL 17 / SQLite

LATER — 必要になったら検討

実例が限られる、または高度化用途。

  • メール/ニュースレター収集

    email newsletters via IMAP / Gmail OAuth2 / newsletters via kill-the-newsletter.com conversion

  • ダッシュボードUI

    web dashboard (demo.rssbrew.com) / DaisyUI dashboard + Mercure SSE

  • YouTube 収集

    YouTube transcripts via Supadata API / YouTube podcast transcripts via Supadata (6 podcasts) / YouTube Data API v3 (subscriptions, last 3 days)

  • Vector DB + RAG（意味検索・Q&A）

    nomic-embed-text-v1.5 (768d) in PostgreSQL + pgvector; RAG via Claude Sonnet

  • Notion 出力

    Notion daily database pages

最初の版では不要

永久に不要ではなく、初期版には不要。

  • 課金
  • 複雑な認証基盤
  • マルチテナント
  • 自動意思決定

FAQ

根拠（なぜこの構成か／実例限定の理由）から生成しています。

なぜ「scheduler」がこの構成に必要か？

なぜ定期実行が必要か：9システム中8がスケジューラで定期実行（youtube-digest のみ手動）。『毎朝の変化だけ』は定期実行が前提。（8/9 システムで確認・確度: 確認済み）

根拠:guo-yichen ↗Siddharth Surange ↗yinan-c ↗00sapo ↗tony-stark-eth ↗zarazhangrui ↗luoli523 ↗catburgg ↗

なぜ「persistent_storage」がこの構成に必要か？

なぜ保存が必要か：9/9が何らかの永続保存を持ち、重複排除・履歴・差分に使う。（9/9 システムで確認・確度: 確認済み）

根拠:guo-yichen ↗Siddharth Surange ↗yinan-c ↗00sapo ↗tony-stark-eth ↗zarazhangrui ↗luoli523 ↗catburgg ↗ssilambarasan ↗

なぜ「delivery_any」がこの構成に必要か？

なぜ最初は1つの出力先でよいか：配信は9/9だが特定チャネルは分散（メール6/9・chat/push6/9・ダッシュボード2/9）。初版は1チャネル（メール）で十分。（9/9 システムで確認・確度: 確認済み）

根拠:guo-yichen ↗Siddharth Surange ↗yinan-c ↗00sapo ↗tony-stark-eth ↗zarazhangrui ↗luoli523 ↗catburgg ↗ssilambarasan ↗

なぜ「rss_ingestion」がこの構成に必要か？

なぜ最初はRSSで核を作るか：情報源取得は9/9だが、RSSが5/9で最も低摩擦。X(4/9)は認証/API、YouTube(3/9)はtranscript手段が必要で実装が重い。（5/9 システムで確認・確度: ほぼ確実）

根拠:guo-yichen ↗Siddharth Surange ↗yinan-c ↗00sapo ↗tony-stark-eth ↗

なぜ「x_ingestion」がこの構成に必要か？

なぜXは初版必須でなくNEXTか：X収集は4/9に増え反復パターンになったが、official API / XDK / Playwright と実装が重い。核が動いた後の追加が妥当。（4/9 システムで確認・確度: ほぼ確実）

根拠:guo-yichen ↗zarazhangrui ↗luoli523 ↗catburgg ↗

なぜ「vector_rag」がこの構成に必要か？

なぜVector DBを後回しにできるか：9システム中Vector/RAGは1/9（BriefCastのみ）。意味検索・Q&Aが欲しくなってからで初版の必須でない。（1/9 システムで確認・確度: 推論）

根拠:Siddharth Surange ↗

「Vector DB + RAG（意味検索・Q&A）」はなぜ後回し/限定なのか？

実例が限定的なためです（1/9 システムでのみ確認・推定）。

「Notion 出力」はなぜ後回し/限定なのか？

実例が限定的なためです（1/9 システムでのみ確認・推定）。

この目的に対して証拠が限定的な範囲は？

YouTubeを標準入力とする判断（3/9・強化だがLATER） / Vector DB必須（1/9） / 特定providerが最適という断定（Persona完全一致とは表示しない。核＋X収集は裏付けが増えたが、YouTubeは3/9でLATER・Vectorは1/9で限定のまま。）

根拠（一次ソース・証拠レコード）

独立システム = 9。証拠レコード = 60。両者は別物です。

この構成が自分の環境で作れるか、確かめてみませんか？

サインアップすると、あなたの環境との比較と「次にやること」が使えます。

自分の環境と比較する — 無料で StackLens を始める →