news_reminder パイプライン再設計

作成日: 2026-04-07 | 種別: アーキテクチャ設計書 | 対象: ops/news_reminder/

1. 現状の課題

news_reminderには「AIニュース」と「金融ニュース」の2つの異なる目的のパイプラインが1つのパッケージに同居している。機能追加や修正のたびに、関係ない方に影響が出ないか気を遣う状態になっている。

2. パッケージ分離方針（3案比較）

AIニュースと金融ニュースをどう分けるかについて、3つの案を検討した。

案A: 同一パッケージ内でサブパッケージ分離

ops/news_reminder/
├── shared/          ← 共通基盤（新設）
│   ├── claude.py    ← Claude CLI呼び出し統一
│   ├── slack.py     ← Slack通知共通
│   ├── retry.py     ← リトライ・レート制限
│   └── data.py      ← データライフサイクル管理
├── ai_news/         ← AIニュース（scanner.pyを分割）
│   ├── fetcher.py
│   ├── evaluator.py
│   └── config.py
├── finance/         ← 金融ニュース（pipeline/を移動）
│   ├── fetcher.py
│   ├── summarizer.py
│   ├── notifier.py
│   └── config.py
├── dashboard/       ← 地政学ダッシュボード
│   └── interpreter.py
└── data/            ← データファイル（共用）

案B: 完全に別パッケージに分離

ops/ai_news/         ← AIニュース専用パッケージ（新設）
├── app/
├── data/
└── pipeline/

ops/finance_news/    ← 金融ニュース専用パッケージ（新設）
├── app/
├── data/
└── pipeline/

ops/shared/          ← 共通基盤（新設、ops全体で使う）

案C: 共通基盤のみ分離、ニュース系は統合維持

ops/news_reminder/
├── shared/          ← 共通基盤のみ切り出し
├── app/             ← 既存構造を維持（scanner.pyのリファクタのみ）
├── pipeline/        ← 既存構造を維持
└── data/

比較表

3. 再設計案の詳細

3.1 ディレクトリ構成

ops/news_reminder/
├── shared/                  ← 共通基盤
│   ├── __init__.py
│   ├── claude_caller.py     ← Claude CLI統一呼び出し
│   ├── slack_poster.py      ← Slack投稿ヘルパー
│   ├── retry.py             ← HTTP リトライ（exponential backoff）
│   ├── json_parser.py       ← LLM出力からのJSON安全抽出
│   └── data_store.py        ← データファイルのライフサイクル管理
│
├── ai_news/                 ← AIニュース系統
│   ├── __init__.py
│   ├── config.py            ← AIニュース用設定
│   ├── fetcher.py           ← RSS / HN / arXiv 取得（ソースタイプごとに関数分割）
│   ├── evaluator.py         ← Claude Haiku による記事評価
│   ├── reporter.py          ← Slack投稿 + バッチサマリー生成
│   └── prompts/             ← プロンプトテンプレート（.txt）
│       ├── relevance.txt
│       ├── geopolitical.txt
│       └── batch_summary.txt
│
├── finance/                 ← 金融ニュース系統
│   ├── __init__.py
│   ├── config.py            ← 金融ニュース用設定（保有銘柄管理含む）
│   ├── fetcher.py           ← Google News RSS取得
│   ├── summarizer.py        ← Claude による要約
│   ├── notifier.py          ← Slack投稿
│   └── sync.py              ← OneDrive Excel同期
│
├── dashboard/               ← 地政学ダッシュボード
│   ├── __init__.py
│   └── interpreter.py       ← Playwright取得 + Claude解釈
│
├── thread.py                ← スレッド管理（既存を維持）
│
├── pipeline/                ← CLIエントリポイント
│   └── cli.py               ← コマンド振り分けのみ
│
├── data/                    ← データファイル
│   ├── sources.json
│   ├── scanned.json
│   ├── holdings.json
│   ├── fetched.json
│   └── notified.json
│
└── tests/                   ← テスト（新設）
    ├── conftest.py
    ├── test_fetcher_ai.py
    ├── test_evaluator.py
    ├── test_fetcher_finance.py
    ├── test_summarizer.py
    ├── test_claude_caller.py
    └── test_data_store.py

3.2 共通基盤の設計

claude_caller.py — Claude CLI統一呼び出し

現在3箇所でバラバラに実装されているClaude CLI呼び出しを1つに統一する。

retry.py — HTTPリトライ共通化

現在arXivだけリトライ3回、他は未対応。全HTTPフェッチに共通のリトライ方針を適用する。

data_store.py — データライフサイクル管理

3.3 scanner.py の分割

現在974行あるscanner.pyを3つの責務に分割する。

プロンプトの外部ファイル化

現在scanner.pyに埋め込まれている長いプロンプト文字列（RELEVANCE_PROMPT等）をprompts/ディレクトリに.txtファイルとして分離する。

• プロンプトの修正にPythonコードの変更が不要になる
• プロンプトだけのdiffが見やすくなる
• 読み込みは起動時に1回だけ（パフォーマンスへの影響なし）

3.4 IF層連携の改善

現在の問題: relevant記事が5件あれば、IF層のClaude CLIを5回連続で呼ぶ。1回120秒かかると最大10分。

3.5 エラーハンドリング方針

3.6 テスト戦略

外部依存が多いため、モック戦略が重要。以下の方針で進める。

4. 再設計後のフロー図

4.1 AIニュース パイプライン

4.2 金融ニュース パイプライン

4.3 共通基盤の依存関係

┌─────────────┐   ┌──────────────┐   ┌─────────────────┐
│  ai_news/   │   │  finance/    │   │  dashboard/     │
│  fetcher    │   │  fetcher     │   │  interpreter    │
│  evaluator  │   │  summarizer  │   │                 │
│  reporter   │   │  notifier    │   │                 │
└──────┬──────┘   └──────┬───────┘   └────────┬────────┘
       │                 │                     │
       └────────────┬────┴─────────────────────┘
                    │
          ┌─────────▼─────────┐
          │     shared/       │
          │  claude_caller    │  ← Claude CLI統一呼び出し
          │  slack_poster     │  ← Slack投稿共通化
          │  retry            │  ← HTTPリトライ共通化
          │  json_parser      │  ← JSON抽出共通化
          │  data_store       │  ← データローテーション
          └───────────────────┘

5. 移行計画

一度に全部やると壊れたときの切り分けが難しい。3フェーズに分けて段階的に移行する。

各フェーズの所要期間目安