📰

自分専用RSSリーダーの構築方法

に公開

自分専用RSSリーダーの構築方法

はじめに

日本と海外のLLM関連ニュースを効率的に追いかけたい――技術の進化が目まぐるしいAI分野では、複数の情報源を日々クロールするのは時間の無駄でした。特に英語サイトの記事を一つ一つ開いて内容を確認するのは非効率的です。

たとえば、Hugging FaceやOpenAI、Anthropicなどの公式ブログ、AI専門ニュースサイト、研究論文アーカイブなど、多くの情報源があります。これらを手動でチェックするのは大変です。

そこで、RSSフィードから自動収集し、英語記事は日本語に翻訳して一元管理できるシステムを構築しました。さらに、RSSを提供していないサイトにも対応するため、ウェブスクレイピング機能も組み込んでいます。

demo

このシステムのアーキテクチャ設計と、その背景にある設計思想を紹介します。

実現したこと

  • 多様なRSSフィードの自動収集(15分間隔)
  • 英語記事の自動翻訳(AWS Bedrock)
  • RSSがないサイトへのウェブスクレイピング対応
  • S3静的ウェブホスティングによる低コスト運用
  • マイクロサービス的なコンテナ分離

システムアーキテクチャ全体像

システムは RSS収集・翻訳システムRSSリーダーUI の2つで構成されています。

設計の狙い:

  • 収集と表示の分離: データ収集システムと閲覧UIを完全に分離し、独立した開発・運用を可能に
  • S3を介した疎結合: RSSファイルをS3に配置することで、システム間の依存を最小化
  • コスト最適化: UIは静的ホスティングで月数円のランニングコスト

コア設計:3層コンテナアーキテクチャ

収集システムは3つのコンテナで構成され、それぞれが明確な責務を持ちます。

コンテナ 責務 役割
web フロントエンド ニュース閲覧、フィード管理、各種連携機能
feeds_worker バックエンド処理 定期収集、翻訳、スクレイピング、RSS生成
redis データ層 セッション管理、既読管理、キャッシュ

設計の狙い:

  • 単一責任の原則: 各コンテナが1つの責務に集中
  • スケーラビリティ: webコンテナを水平スケール可能
  • 独立したライフサイクル: コンテナごとに異なる更新・再起動が可能

データフロー設計

記事収集から配信までの処理フローは、RSSフィードウェブスクレイピングの2つの入口を持ち、共通パイプラインで処理します。

設計の狙い:

  • 共通パイプラインパターン: 入口(RSS/スクレイピング)が異なっても、後続処理は統一
  • 条件分岐による効率化: 英語記事のみ翻訳を実行し、コストを最小化
  • 非同期処理: 収集と配信を分離し、UIへの影響を排除

主要な設計判断

1. 英語記事の自動翻訳

海外のAI研究ブログやニュースサイトを効率的にキャッチアップするため、英語のタイトルと概要を日本語に自動翻訳します。

技術選択:

  • AWS Bedrock: 高速・低コスト(モデルによる)
  • リトライとスロットリング対応で安定性確保
  • 品質フィルタで誤翻訳を検出

設計の狙い:

  • ブラウザを開かずに概要把握
  • 日本語で統一された閲覧体験
  • 情報収集時間の大幅短縮

2. ウェブスクレイピング統合

RSSを提供していないサイトにも対応するため、BeautifulSoupでスクレイピングし、共通パイプラインに流す設計を採用しました。

設計の狙い:

  • 情報源の制約を受けない柔軟性
  • 設定ファイルでセレクタを指定し、サイトごとの構造差異を吸収
  • RSSデータと同じフォーマットに変換し、後続処理を共通化

3. S3静的ウェブホスティングによるコスト最適化

RSSリーダーUIは、S3の静的ウェブホスティング機能で配信しています。

コスト面での判断:

  • サーバーレスでEC2/ECS不要
  • 個人利用なら月数円程度の従量課金
  • 高可用性(99.99%)をAWSインフラで担保

設計の狙い:

  • ランニングコストをほぼゼロに
  • メンテナンスフリーな運用
  • システムの持続可能性を確保

4. 認証設計

個人利用を前提に、シンプルな認証を採用しています。

認証方式の選択肢:

  • Amplifyで設定可能なBasic認証:最もシンプル(個人利用向け)
  • Amazon Cognito:本格的なユーザー管理(複数ユーザー向け)
  • 多要素認証:セキュリティ強化が必要な場合

設計の狙い:

  • 用途に応じた柔軟な選択
  • 開発コストと運用負荷のバランス

5. データ抽出の柔軟性

RSSフィードの構造は千差万別です。設定ファイル(JSON)でフィードごとに抽出ルールを定義できる設計にしました。

{
  "非標準フィード": {
    "title": "カスタムフィールド名",
    "description": "カスタム説明フィールド",
    "published": "カスタム日時フィールド"
  }
}

設計の狙い:

  • コード変更なしで新規フィードに対応
  • 非標準的なフィード構造にも対応可能

アーキテクチャの利点

このアーキテクチャ設計により、以下を実現しています:

  1. 責務の分離: 収集、処理、表示が独立し、それぞれを最適化可能
  2. 拡張性: 新しい情報源やデータ処理を容易に追加
  3. コスト効率: S3静的ホスティングでランニングコストを最小化
  4. 柔軟性: RSS/スクレイピング両対応、設定ベースの拡張
  5. 保守性: コンテナ分離により影響範囲を限定

まとめ

LLMニュースを日本語で一元管理するためのRSS収集・翻訳システムのアーキテクチャを紹介しました。

設計の核心:

  • マイクロサービス的な責務分離
  • 共通パイプラインによる処理統合
  • 英語記事の自動翻訳でキャッチアップ効率化
  • S3静的ホスティングでコスト最適化
  • 設定ベースの柔軟な拡張性

このような設計により、日本・海外のLLMニュースを日本語で効率的に収集・閲覧でき、情報収集時間を大幅に短縮できました。同様の課題を抱える方の参考になれば幸いです。

参考リンク

Discussion