記事収集AIエージェントの設計｜2軸スコアリングと月額180円で回す構成【AI活用検証vol.67】

情報収集を自動化するとき、最初に決めるべきは「どう集めるか」ではありません。何を「良い記事」と判定するかです。ここが曖昧なままだと、集まっても選べません。

この検証では、プラットフォーム上の記事を収集・分析してDiscordとSlackへ配信するエージェントを設計しました。2軸のスコアリング式と、月額約180円という運用コスト試算まで固めています。

この検証の概要

本記事は自社での検証記録です。外部サービスのデータ取得は、各サービスの利用規約とrobots.txtの範囲内で行う必要があります。

結論：「バズ」と「エンゲージメント率」の2軸で拾う

この設計の中核はスコアリングです。1つの指標では、拾えるものが偏ります。

# バズスコア: 1日あたりの engagement 速度
days = max((now - published_at).days + 0.5, 0.5)
engagement_weight = likes + comments * 2
buzz_score = (engagement_weight / days) * (1.2 if is_paid else 1.0)

# エンゲージメント率スコア: フォロワー規模比（無名クリエイターの良記事を拾う）
eng_score = (engagement_weight / max(creator_followers, 100)) * (1.2 if is_paid else 1.0)

# LLM テーマ判定でテーマ適合スコア 0.0〜1.0 を取得し乗算
final_buzz = buzz_score * theme_score
final_eng  = eng_score  * theme_score

# 各軸上位5件の Union（重複除去）→ 最大10件を配信

設計上のポイントは3つあります。

① 絶対数ではなく「速度」で見る

バズスコアは1日あたりのengagement速度です。公開からの日数で割ることで、古くて数字が積み上がっただけの記事を上位に押し上げないようにしています。

② フォロワー規模で割って、無名の良記事を拾う

エンゲージメント率スコアはフォロワー規模比です。反応数だけで並べると、フォロワーの多いアカウントが常に上位を占めます。規模で割ることで、フォロワーは少ないが刺さっている記事が浮かび上がります。

この2軸をそれぞれ上位5件取り、Unionで重複除去して最大10件を配信する構成です。片方だけでは見落とす層があります。

③ コメントを重く見る

engagement_weight = likes + comments * 2 という重み付けです。コメントはスキより行動コストが高いため、内容への反応をより強く反映します。

LLMをスコアリングに組み込む

数値だけでは「テーマに合っているか」は判断できません。

そこでLLMによるテーマ判定でテーマ適合スコア（0.0〜1.0）を取得し、両軸のスコアに乗算しています。バズっていてもテーマが違えば、スコアは下がります。

数値指標と意味判定を掛け合わせる構成です。数値だけでも、AIの判断だけでも、選別としては不十分になります。

データ取得方法の調査結果

RSS / 公式API / 非公式API / スクレイピングを比較し、非公式API v3をメインに採用しました。

• 公式APIが存在しないため、非公式API v3（https://note.com/api/v3/）が広く使われている
• 非公式API v3ではスキ数・有料フラグ・フォロワー数など豊富なデータが取得可能
• RSSはユーザー別のみで、タグ別・人気記事別のフィードは存在しない——収集用途には使えない
• robots.txtでは /n/*（記事）/m/*（マガジン）のクロールは許可されている
• 有料記事の本文は購入ユーザー権限が必要なため、タイトル・冒頭部分のみ取得可能

スクレイピングはフォールバック扱いです。利用規約で明示禁止はないものの、API優先で負荷を最小化する方針としました。レート制限対策として1〜3秒のディレイを設定します。

定期実行基盤：GitHub Actionsを選んだ理由

5つの選択肢を実行時間の観点で比較しました。

決め手は処理時間の見積もりです。このエージェントは「レートリミットのディレイ込みのAPIフェッチ（20件）＋ Claude API呼び出し」で1〜2分かかる見込みでした。

Cloudflare Workers（30秒）・Vercel（10秒）・GAS（6分）は実行時間がネックになります。GitHub ActionsはPublicリポジトリなら完全無料・Pythonネイティブ・6時間制限で余裕という判断です。

定期実行基盤の選定は、まず「1回の処理に何秒かかるか」から入ると迷いません。そこで大半の選択肢が落ちます。

コスト試算：月額約180円

注目すべきはモデルの使い分けです。件数の多いテーマ判定（20件）には軽量なHaikuを、件数の少ない通知文生成（10件）にはSonnetを使っています。

すべてを高性能モデルで処理する必要はありません。判定のような単純な処理と、文章生成のような品質が求められる処理を分けると、コストは大きく下がります。

収集対象

収集ハッシュタグは8種で確定しています。

#生成AI #ChatGPT #LLM #Claude #AI活用 #組織変革 #経営 #マーケティング

配信先はDiscord（個人向け）とSlack（チーム向け）の2系統です。同じ情報でも、読む相手によって必要な粒度が変わります。

残っている未確認事項

この検証は設計段階のため、実測が必要な項目が残っています。

• API v3の疎通確認（まだ実測していない）
• ビュー数フィールドの取得可否（実装時期によって不安定との報告あり）
• レート制限の実測値（1〜3秒ディレイで十分かは未確認）
• 有料記事の本文取得可否（購入権限が必要と推測）

非公式APIを使う以上、仕様が変わる前提で設計しておく必要があります。

よくある質問

なぜスコアを2軸にするのですか？

1軸だと拾える記事が偏るためです。反応数の絶対値だけで並べるとフォロワーの多いアカウントが上位を占めます。フォロワー規模比の軸を足すことで、無名でも刺さっている記事を拾えます。

RSSでは足りないのですか？

RSSはユーザー別のみで、タグ別・人気記事別のフィードが存在しません。テーマ横断で収集する用途には使えないため、API経由での取得が必要になります。

なぜGitHub Actionsを選んだのですか？

1回の処理に1〜2分かかる見込みだったためです。Cloudflare Workers（30秒）・Vercel（10秒）・GAS（6分）は実行時間がネックになります。GitHub ActionsはPublicリポジトリなら完全無料でPythonネイティブ、6時間制限で余裕があります。

運用コストはどのくらいですか？

毎日1回の実行で約180円/月の試算です。件数の多いテーマ判定に軽量モデル、件数の少ない通知文生成に高性能モデルを使い分けています。

まとめ

• 情報収集の自動化で先に決めるべきは、集め方より「何を良い記事と判定するか」
• スコアは「1日あたりのengagement速度」と「フォロワー規模比」の2軸。各軸上位5件のUnionで最大10件を配信
• 数値指標にLLMのテーマ適合スコア（0.0〜1.0）を乗算し、数値と意味判定を掛け合わせる
• 定期実行基盤は処理時間の見積もりから選ぶ。1〜2分かかる想定でGitHub Actionsを採用
• モデルの使い分けでコストは約180円/月。判定は軽量モデル、生成は高性能モデル
• 非公式APIを使う以上、仕様変更を前提に設計する

収集の自動化は、フィルタの設計がすべてです。何を上位に出すかを数式で表現できれば、あとは実装の問題になります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の情報収集・マーケティング業務の自動化を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。