情報収集を全自動化する方法 ― RSS・LLMキュレーション・チャット配信の実装ガイド

エンジニアチームが抱える情報収集の4つの壁

ソフトウェア開発の世界は変化が激しい。毎日のように新しいツールやフレームワークがリリースされる。とりわけ2024年以降はAI関連の進歩が加速しており、1週間キャッチアップを怠ると動向を見逃しかねない。

弊社のエンジニアチームも、この問題に長く悩んでいた。

個人依存の情報収集 — 各メンバーが独自のやり方で情報を追い、チーム全体への共有が薄い
時間の問題 — 業務時間中にRSSリーダーやHacker Newsを巡回する余裕がない
英語の壁 — 一次情報の大半は英語。全員が均等にアクセスできるわけではない
情報の偏り — 個人の関心領域に引っ張られ、チームとして押さえるべき技術動向にムラが出る

毎日15分で技術トレンドをチーム全員がキャッチアップできる仕組みが欲しい。その声をきっかけに、情報収集パイプラインの全自動化に取り組んだ。

では、RSS収集からLLMキュレーション、チャットツールへの配信までを一気通貫で自動化した仕組みと、数ヶ月の運用で得た知見を順に見ていく。

自動化パイプラインの全体像

構築したパイプラインは3つのフェーズで動く。

[収集フェーズ]          [キュレーションフェーズ]        [配信フェーズ]

 RSS Feeds ─────┐
                 ├─→ Markdown ─→ LLM(Claude Haiku) ─→ Discord / Slack
 GitHub Trend ──┘    ファイル      10〜15件に厳選         サマリー配信
       │
    DeepL API
   (英→日翻訳)

まず、それぞれの役割を整理する。

収集 (rss_collector.py) — 複数のRSSフィードとGitHubトレンドから記事を取得し、英語記事はDeepL APIで翻訳。Markdownファイルとして出力する
キュレーション (news_distributor.py) — LLMが記事を評価・厳選し、チームにとって価値の高い10〜15件を選ぶ
配信 — DiscordやSlackに通知なしで投稿。サマリーと個別記事の2段構成にする

すべてPythonで実装し、日次のスケジュール実行で完全に自動化している。

収集の仕組み ― 複数ソースからの情報集約

RSSフィードの選定

収集元のRSSフィードは、チームの技術スタックと関心領域に合わせて選んでいる。

# フィード設定の例（実際のコードを簡略化したもの）
feeds = [
    # 主要テックメディア
    "https://hnrss.org/newest?points=100",         # Hacker News (100pt以上)
    "https://www.infoq.com/feed/",                  # InfoQ
    "https://techcrunch.com/feed/",                 # TechCrunch

    # AI/LLM特化
    "https://openai.com/news/rss.xml",              # OpenAI News
    "https://rsshub.app/anthropic/news",            # Anthropic (RSSHub経由)

    # 開発ツール・クラウド
    "https://github.blog/feed/",                    # GitHub Blog
    "https://aws.amazon.com/blogs/aws/feed/",       # AWS Blog

    # 日本語ソース
    "https://zenn.dev/feed",                        # Zenn
    "https://b.hatena.ne.jp/hotentry/it.rss",       # はてなブックマーク IT
]

ここでのポイントは hnrss.org の活用だ。Hacker News本体にはフィルタ付きRSSがない。だが、hnrss.orgを使えば ?points=100 のようにスコアで足切りでき、ノイズを大幅に減らせる。

加えて、Anthropicのようにネイティブなフィードを提供していないサイトもある。こうしたケースではRSSHubなどのコミュニティツールを使ってフィードを生成する。フィード収集の安定性を考えると、各ソースのRSS提供状況は定期的に確認したほうがいい。

GitHubトレンドの収集

RSSだけでは拾いきれない今まさに注目されているリポジトリを把握するために、GitHubのトレンドページからも情報を引いている。新しいOSSツールやライブラリの早期発見に役立ち、チーム内で面白いリポジトリを見つけたという会話のきっかけにもなる。

DeepL APIによる翻訳処理

一次情報の多くは英語で出てくる。チーム全員がストレスなく読めるように、英語記事はDeepL APIで日本語に翻訳している。

# 翻訳処理の概要
def translate_if_needed(article):
    if detect_language(article.title) == "en":
        article.title_ja = deepl_translate(article.title, target="JA")
        article.summary_ja = deepl_translate(article.summary, target="JA")
    return article

DeepL APIを選んだのは、技術文書の翻訳精度が高く専門用語の扱いが自然だからだ。2024年7月に発表されたDeepLの次世代言語モデルは、ブラインドテストでChatGPT-4比1.7倍、Google翻訳比1.3倍の品質評価を得ている。とりわけ日英間の翻訳ではニュアンスの再現に強みがある。

翻訳にLLMを使う選択肢も検討した。しかしコストとレイテンシの両面でDeepLが勝った。DeepL API Freeプランは月50万文字まで無料で使える。Proプランに移行しても月額基本料5.49ドルに加え、100万文字あたり約25ドルで済む。日次パイプラインの翻訳量ならFreeプランの範囲内で収まるケースも多い。

Markdownへの出力

収集した記事はMarkdownファイルとして保存する。日付ごとにファイルが生成され、次のキュレーションフェーズへの入力になる。

## 2026-02-17 収集記事一覧

### [1] Anthropic Releases New Model with Enhanced Coding Capabilities
- URL: https://example.com/article1
- ソース: Anthropic
- 翻訳タイトル: Anthropic、コーディング能力を強化した新モデルを発表
- サマリー: ...

では、集めた記事をどう絞り込むか。次のキュレーションフェーズが肝になる。

LLMキュレーションの実装 ― AIが読むべき記事を選ぶ

キュレーションが必要な理由

RSSフィードから集まる記事は、1日あたり数十件から百件を超えることもある。これを全部チャットに流すと、情報過多で誰も読まなくなる。

実際に試した。キュレーションなしでそのまま流したところ、通知が多すぎて見なくなったというフィードバックが1週間で返ってきた。

だからといって人間が毎日手作業で選定するのは続かない。単純なキーワードフィルタでは文脈を踏まえた取捨ができない。そこでLLMによるキュレーションを導入した。

選定基準の設計

LLMに渡すプロンプトでは、選定基準を明確に記述している。

curation_prompt = """
以下の記事リストから、ソフトウェア開発チームにとって価値の高い記事を
10〜15件選定してください。

## 選定基準（優先度順）

1. AI/LLM動向: 新モデル、新サービス、実用的なユースケース
2. 開発ツール: 生産性を向上させるツールやサービスのアップデート
3. SaaS/クラウド: 主要クラウドプロバイダーの新機能、料金変更
4. GitHubリポジトリ: 実用的で注目度の高いOSSプロジェクト

## 除外基準

- 初心者向けチュートリアル
- 基礎的すぎる内容（チームの技術レベルに合わない）
- 広告色の強いプレスリリース
- 古い情報の焼き直し

## 出力形式
選定した記事ごとに、選定理由を1行で添えてください。
"""

ここで重視したのは除外基準の明示だ。LLMは指示がなければ記事を落とすことに慎重になりがちで、件数が膨らむ。除外条件を具体的に書くことで、厳選の精度が上がった。

Claude Haikuを採用した理由

キュレーションにはClaude 3 Haikuを使っている。

コストが低い — 日次で回すため、ランニングコストの低さは外せなかった。Claude 3 Haikuは入力100万トークンあたり0.25ドル。後継のClaude 3.5 Haikuでも1ドルに収まる
タスクに対して十分な精度 — 記事の選定と要約にはHaikuクラスで十分な品質が出る
応答が速い — 収集から配信までのパイプライン全体を高速に回せる

さらに高性能なモデルを使うことも検討した。ただ、キュレーションは判断の正確さより大外しをしない安定感が求められるタスクだ。コスト対効果でHaikuがベストバランスだった。

運用で得た知見 ― ハルシネーション対策

LLMキュレーションで最も注意すべき点がハルシネーションだ。

弊社の運用でも、ソース情報がURLのみの場合にLLMが記事内容を推測し、実際とは異なるサマリーを生成するケースが発生した。たとえばURLのドメインとパス名だけから、おそらくこういう内容だろうと補完してしまう。

対策として3つの施策を実施した。

1. メタデータの事前取得

URLだけでなく、ページタイトルやog:descriptionを事前にフェッチしてLLMに渡す。これだけでハルシネーション率が大幅に下がった。

def enrich_article_metadata(article):
    """URLからメタデータを取得し、LLMへの入力を充実させる"""
    metadata = fetch_url_metadata(article.url)
    article.title = metadata.get("og:title", article.title)
    article.description = metadata.get("og:description", "")
    return article

2. アンチハルシネーション指示の追加

プロンプトに「提供された情報のみに基づいて要約してください。推測や補完は行わないでください」と明記する。LLMは指示があれば分からないと答えられる。指示がなければ補完しようとする。この差は大きい。

3. 後処理でのバリデーション

出力結果に対して、元記事のタイトルやキーワードとの整合性をチェックする。完全な自動検証は難しいが、明らかな逸脱は検出できる。

この3つの対策を組み合わせたことで、キュレーション結果の信頼性が安定した。では、厳選した記事をどうチームに届けるか。

チャットツールへの配信設計 ― 業務を邪魔しない情報共有

通知なし配信という設計判断

配信先としてDiscordとSlackに対応している。ここで最も大事にした設計判断は通知なしで配信することだ。

技術ニュースは今すぐ読まなければならない情報ではない。手が空いたときに目を通せばいい。それなのに通知が鳴るたびに集中が途切れては本末転倒だ。

# Discordへの配信（silent=Trueで通知を抑制）
async def post_to_discord(channel, message):
    await channel.send(
        content=message,
        suppress_embeds=False,
        silent=True  # SUPPRESS_NOTIFICATIONSフラグを設定
    )

discord.py 2.2以降では silent=True パラメータが使える。内部的には MessageFlags.SUPPRESS_NOTIFICATIONS フラグが設定され、プッシュ通知やデスクトップ通知を抑制する。チャンネル内のメッセージ自体は通常どおり表示される。

Slackでも同様に、unfurlは有効にしつつメンションや通知トリガーを含めない形で投稿している。

メッセージの構成

配信は2段構成にしている。

1. サマリーメッセージ

その日の厳選記事の概要を一覧で示す。忙しい日はこれだけ見ればいい。

本日のテックニュース（2026/02/17）12件

1. Bun 1.3リリース — GC改善でアイドルCPU消費を100分の1に削減
2. GitHub Copilot Workspace がGA — AIペアプロの新しい形
3. AWS Step Functions、Express Workflowsの同時実行上限を5倍に拡張
4. shadcn/ui にRTLサポートが追加
...

2. 個別記事メッセージ

各記事について、LLMが生成した要約と元記事のURLを投稿する。

Bun 1.3リリース — GC改善でアイドルCPU消費を100分の1に削減

JavaScriptランタイムBunの1.3がリリースされた。
GCをイベントループに統合し、アイドル時のCPU消費を
100分の1に削減。メモリ使用量も40%減少。
組み込みSQLクライアントやRedisクライアントも追加された。

https://bun.sh/blog/bun-v1.3

Discord配信時のレート制限対策

Discordへの配信では、APIのレート制限に気をつける必要がある。短時間に大量のメッセージを送ると制限に引っかかる。メッセージ間に待機時間を入れて回避している。

# レート制限対策
for article in selected_articles:
    await post_article_message(channel, article)
    await asyncio.sleep(0.3)  # 300msの間隔を確保

0.3秒のインターバルは実運用で安定する最小値だった。10〜15件の配信でも合計5秒以内に完了するため、体感上の遅延はない。

導入効果 ― 数ヶ月の運用を経て

パイプラインの運用を始めて数ヶ月が経過した。定量と定性の両面から振り返る。

定量的な効果

指標	導入前	導入後
チーム全体の情報キャッチアップ率	まばら	毎日15件を全員が閲覧可能
情報収集にかかる個人の時間	30分〜1時間/日	ほぼゼロ（閲覧のみ）
英語記事へのアクセシビリティ	個人差あり	全員が日本語で閲覧
運用コスト	日次の手動作業	完全自動（月1回程度のメンテ）

とりわけ情報収集にかかる時間の変化が大きかった。1人あたり毎日30分として、5人チームなら月に約50時間の工数削減になる。

定性的な効果

雑談の質が変わった。 昨日のニュースで流れてたあのツール、使ってみた？という会話が自然に生まれるようになった。同じ情報を全員が見ているからこそ起きる変化だ。

技術選定の引き出しが増えた。 新しいOSSやサービスを早い段階で認知できるため、プロジェクトの技術選定で選択肢が広がった。

英語記事へのハードルが下がった。 翻訳付きで配信されるので、英語が得意でないメンバーも一次情報に触れられるようになった。結果として、チーム内の情報格差が縮まった。

受動的な学習効果があった。 自分からは検索しなかっただろう分野の情報にも触れる機会が増えた。知らないことを知らない状態が減り、技術的な視野が広がる実感がある。

予想外だった効果

導入前はテック系の情報を追うツールという位置づけだった。ところが運用を続けるうちに、チーム内の技術的な共通言語が増えていくという副次的な変化が見えてきた。全員が同じニュースを読んでいるため、議論の前提をそろえやすい。技術的な意思決定のスピードが上がったのは、この共通基盤のおかげだと感じている。

構築時のつまずきポイントと対処法

自動化パイプラインの構築は順調ではなかった。実際にぶつかった問題とその対処法を共有する。

RSSフィードの不安定さ

RSSフィードは提供元の都合で突然フォーマットが変わったり、配信が止まったりする。テック企業のブログはサイトリニューアルでURLごと変わることがある。

そのため、フィードごとにエラーハンドリングを入れ、取得失敗時はスキップして他のフィードの処理を続行する設計にした。加えて、フィードの死活監視を週次で走らせ、応答がないフィードを検出できるようにしている。

LLMの出力形式のブレ

LLMの出力は毎回微妙に異なる。JSONで返すよう指示しても、Markdownで返ってきたり余計な前置きが付いたりする。

ここでは、パース処理に柔軟性を持たせることで対処した。正規表現でJSONブロックを抽出する処理に加え、箇条書き形式もフォールバックとして受け付ける多段パーサーを用意している。

翻訳の精度とコスト管理

DeepL APIの翻訳は高品質だが、長文記事を丸ごと翻訳するとコストが膨らむ。タイトルとサマリー、最大300文字程度のみを翻訳対象とすることで、品質を保ちつつコストを抑えた。

予想FAQ

Q1. パイプライン全体の構築にどのくらい時間がかかりましたか？

最初のプロトタイプは2日で動いた。ただし、ハルシネーション対策やレート制限への対応、出力パーサーの改善など、安定稼働させるまでの調整に2週間ほどかかっている。

Q2. LLMのキュレーション精度はどの程度ですか？

体感では8割以上の満足度だ。なぜこの記事を選んだ？と思うこともたまにあるが、致命的な選定ミスはほぼない。プロンプトの選定基準を具体的に書くほど精度は上がる傾向にある。

Q3. DeepL API以外の翻訳手段も検討しましたか？

Google Cloud Translation APIとLLMによる翻訳を比較した。Google翻訳はコストが安いが技術用語の訳が不自然なケースがあった。LLM翻訳は品質が高いがコストとレイテンシに課題があった。総合的にDeepLのバランスが良かった。

Q4. フィードの追加や削除はどう管理していますか？

フィード一覧はYAMLファイルで管理している。追加や削除はYAMLを編集してデプロイするだけで反映される。月に1回程度、フィードの見直しを行い、ノイズが多いフィードの閾値調整や新規フィードの追加を実施している。

Q5. 他のチャットツールにも対応できますか？

配信部分はチャットツールごとにアダプタを実装する設計にしている。現在はDiscordとSlackに対応しているが、Microsoft TeamsやGoogle Chatへの対応もアダプタの追加だけで可能だ。

Q6. 類似のツールやサービスとの違いは？

RSSリーダーにAIフィルタを組み合わせたサービスは増えている。Feedly AIやInoreaderのAIアシスタントなどが代表的だ。ただ、チーム固有の選定基準をプロンプトで細かく制御できる点、配信先やフォーマットを自由にカスタマイズできる点が自前パイプラインの強みになる。既製品で足りるケースももちろんあるので、チームの規模や要件に合わせて選ぶとよい。

まとめ

RSS収集、LLMキュレーション、チャット配信。この3つのフェーズを組み合わせて、情報収集パイプラインを全自動化した。

技術的に特別なことはしていない。RSSパーサー、翻訳API、LLM API、チャットBot。既存の技術を組み合わせただけだ。ただ、これらを1つのパイプラインとしてつなぎ、日次で安定稼働させることで、チーム全体の情報力を底上げできた。

今後は収集した情報をナレッジベースとして蓄積する仕組みや、社内のQ&Aシステムとの連携にも取り組んでいく。

記事をシェアする

一覧に戻る