仕組み¶
パイプライン全体図¶
公開ニュースソース(RSS、Yahoo Finance、...)
│
│ 20 分ごとの共有インジェスト(Celery Beat)
▼
┌─────────────────────────────────────────────────────────┐
│ ユーザー別ファンアウト │
│ │
│ 各アクティブユーザーについて: │
│ 1. そのユーザーのウォッチリストのエイリアスに対し │
│ raw item をフィルタ(安価なローカルキーワード照合)│
│ 2. 通過した各 item に対し合成エンジンが 5 つの │
│ エージェントを並列実行 │
│ 3. 集計 + Reflexion でトップシグナルを生成 │
│ 4. Signal 行を永続化(Postgres、RLS スコープ) │
│ 5. ユーザーの ChromaDB コレクションへ埋め込み │
│ *(計画中 — `embedding_worker` は 2026-04-22 時点 │
│ でスタブ。Claw チャットは現在 BM25 のみで取得)* │
│ 6. Redis チャネル signals:<user_id> に発行 │
│ 7. FLASH + ALERT を Telegram に配信(連携済みの場合) │
│ 8. FLASH + ALERT を Web Push に配信(購読済みの場合) │
└─────────────────────────────────────────────────────────┘
│
▼
あなたのダッシュボード(WebSocket 経由リアルタイム)、スマホ、デスクトップ。
キーアイデア¶
共有インジェスト、ユーザー別合成¶
公開ニュースのスクレイピングはグローバルに 1 度だけ行います——そうしないと NVDA をウォッチしている 10 人のユーザーそれぞれが Yahoo を 10 回叩くことになってしまいます。一方で LLM 負荷の高い合成ステップは (user, news-item) ペアごとに 1 度実行されるので、スコアリングとティッカーインパクトは「あなたの」ウォッチリストの文脈を反映した、画一的ではないスコアになります。
1 つの巨大プロンプトではなく 5 つの専門エージェント¶
「このニュースは重要か、なぜか」を 1 つの大きなプロンプトに聞くのではなく、5 つの小さく絞り込んだエージェントを並列実行します——それぞれに独自のレーン(ティッカーレベルの事実、マクロコンテキスト、セクターダイナミクス、リテールセンチメント、規制)があります。各出力を加重平均して最終シグナルにまとめます。エージェント を参照。
信頼度の低いドラフトに対する Reflexion¶
集計スコアがボーダーラインのときは、エンジンが Reflexion パスを実行します:ドラフトを批判して書き直す 2 回目の LLM 呼び出しです。各シグナルの エージェント内訳 パネルでどの程度の頻度で発動しているか確認できます。
データベース層のロウレベルセキュリティ¶
ユーザー所有のすべてのテーブル(signals、watchlists、user_settings、rag_query_logs、...)には PostgreSQL の RLS ポリシーが設定されています:user_id = current_setting('app.current_user')。FastAPI セッションは Postgres ロール authenticated で動作し——スーパーユーザーではなく——RLS がアクティブに強制されます。クロスユーザーのデータ漏洩はアプリケーションコードではなく Postgres 自身によってブロックされます。
次へ¶
- エージェント — 5 つのエージェントが何をするか
- スコアリング — 緊急度ティア、インパクト / 信頼度、リンクタイプ
- Claw チャット(RAG) — 自由形式の質問が自分のシグナルからどう回答されるか