【要約】RSS収集とSQLiteによる差分検知の設計 — ローカルLLMを利用した自分専用ニュースbot開発記 #2 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者は、ニュースbotを実用的なツールにする過程で、同じ記事を繰り返し通知してしまう問題に直面した。RSSフィードは実行のたびに全件を返却するため、既読状態を管理しなければ通知が重複する。また、以下の課題も考慮する必要があった。
- ・RSS以外のソース（HTML等）を追加した際に、既存のロジックを書き換える手間が発生するリスク。
- ・差分検知の処理が、データ本体の保存やLLMの分析処理と密結合し、複雑化する懸念。
- ・フィード形式の差異（IDの欠如など）による、判定精度の低下。
// Approach
開発者は、将来の拡張性と判定の高速化を両立するため、以下の設計アプローチを採用した。
- ・
Itemdataclassによるインターフェースの固定。収集元がRSSでもHTMLでも、後続処理には同一の型を渡す設計とした。 - ・SQLiteにおける2テーブル構成の採用。既読判定用の軽量な
seen_itemsと、データ保持・キュー用のitemsを分離した。 - ・依存方向の一方向化。
diff.pyがstorage.pyを呼ぶ構造を徹底し、循環参照を回避した。 - ・堅牢な収集ロジックの実装。
feedparserで吸収しきれないID欠如に対し、linkをキーとするフォールバックを実装した。
// Result
開発者は、AWS What's Newフィードを用いて設計の正当性を検証した。1回目の実行で100件の新着を検知し、2回目の実行では新着0件となることを確認した。具体的な成果は以下の通りである。
- ・
seen_itemsテーブルに、item_keyとSHA-256によるcontent_hashが正しく記録された。 - ・
itemsテーブルに、LLM分析待ちの状態を示すpendingステータスでデータが蓄積された。 - ・設計通り、重複通知のない実用的な差分検知ロジックが実現できた。
Senior Engineer Insight
> インターフェースを先に固める設計思想が極めて実戦的だ。
Item型による抽象化は、将来のHTML監視追加時のコストを劇的に下げる。また、DBを「判定用」と「キュー用」に分ける設計は、スケーラビリティと責務の分離の観点から高く評価できる。SQLiteを利用しているが、この設計であれば将来的にPostgreSQL等への移行も容易だろう。ただし、大規模トラフィックを扱う場合は、seen_itemsのインデックス設計や、DBのI/O負荷に注意が必要だ。