---
title: "記事収集AIエージェントの設計｜2軸スコアリングと月額180円で回す構成"
excerpt: "バズ記事・有料記事を効率よく収集しDiscord・Slackへ配信するエージェントを設計しました。「1日あたりのengagement速度」と「フォロワー規模比」の2軸スコアにLLMのテーマ適合スコアを乗算する仕組み、処理時間から逆算したGitHub Actionsの選定理由、モデル使い分けによる月額約180円のコスト試算をまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-04-15T00:00:00+00:00
verified_at: 2026-04-15T00:00:00+00:00
models: ["Claude"]
tools: ["GitHub", "Discord", "Slack"]
tasks: ["AIエージェント", "業務プロジェクト"]
domain: "マーケティング"
canonical_url: https://ai-katsu.jp/articles/note-article-analysis-agent
---
# 記事収集AIエージェントの設計｜2軸スコアリングと月額180円で回す構成

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2026年4月15日〜（検証中） |
| 使用予定ツール | note非公式API v3 / Python・httpx / Claude API（claude-sonnet-4-6）/ Discord Bot / Slack Webhook |
| やりたかったこと | 技術・AI・ビジネスジャンルでバズっている記事・有料記事・SEO上位記事を効率よく収集・分析し、DiscordとSlackへ自動配信する |
| 確定した設計 | **2軸のスコアリング式／GitHub Actionsによる定期実行／収集ハッシュタグ8種** |
| コスト試算 | **約180円/月**（毎日1回実行） |
| 状況 | 設計完了・実装前（API疎通は未実測） |

> 本記事は自社での検証記録です。外部サービスのデータ取得は、各サービスの利用規約と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つの選択肢を実行時間の観点で比較しました。

| 選択肢 | 実行時間上限 | 言語 | 無料cron頻度 | 評価 |
| --- | --- | --- | --- | --- |
| **GitHub Actions** | **6時間** | 何でも可 | 制限なし（Publicは完全無料） | **採用** |
| Cloudflare Workers | 30秒（無料）/ 15分（有料） | JS/TSのみ | 可 | 実行時間・言語がネック |
| Vercel | 10秒（無料）/ 60秒（Pro） | JS/TS主体 | 1日1回（無料） | 実行時間・コストがネック |
| Google Apps Script | 6分/回 | JSのみ | 可（無料） | JSのみ・6分制限がネック |
| Google Colab | セッション依存 | Python | 非対応（手動） | 自動化に不向き |

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

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

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

## コスト試算：月額約180円

| 項目 | 費用 |
| --- | --- |
| GitHub Actions（Publicリポジトリ） | $0 |
| Claude Haiku（テーマ判定 × 20件） | 約45円/月 |
| Claude Sonnet（通知文生成 × 10件） | 約135円/月 |
| **合計** | **約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活用の検証を日々行い、企業の情報収集・マーケティング業務の自動化を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。