TOKIUM のエンジニアリングマネージャー sk さんが、1年間の育児休暇に入る前に「放置しても動き続ける情報収集システム」を作った話を Zenn に公開している。休んでいる間に生成AIのトレンドから取り残されないため、収集・要約・配信だけでなく、情報源そのものがヒット実績で自動的に入れ替わるところまで作り込んだという内容だ。
自分も似た用途の自作ツール（後述）を回しているので、どこが同じでどこが先を行っているか、という目線で読んだ。
構成：Claude Code + SQLite + cron
スタックは派手ではない。Claude Code と Claude API が頭脳、情報源の定義は SQLite に一元管理、オーケストレーションはシェルスクリプト、定期実行は cron、レポートPDFは rclone で Google Drive に同期。Web 側は Zenn・Qiita・各社AI公式ブログを巡回し、社内 Slack のチャンネルと特定ユーザーの投稿も監視する。
レポートは日次・週次・月次の3種類。約3週間の運用でデイリー15本・ウィークリー3本が自動生成され、育休中は週1回レポートを読むだけでキャッチアップできる体制になっている。
肝は「候補発見 → 昇格 → 降格」のループ
この基盤の見どころは収集そのものではなく、収集対象の評価サイクルにある。
キーワードや巡回先は固定リストではない。新しい候補が見つかると「候補」として収集が始まり、ヒット数と「実際にレポートに採用されたか」の組み合わせで評価される。記事中の例では、エージェントフレームワークの「Mastra」は14日で正式キーワードに昇格し、逆に「Copilot」は採用率が下がって降格した。
評価軸を「ヒット数」だけにしないのが重要で、ヒットはするがレポートに載らないキーワードはノイズ源として落ちる。最終アウトプットへの貢献度でソースを淘汰する設計だ。枠が埋まったら自動で入れ替えるので、放置しても監視対象が膨張しない。
キーワード検索で拾えない情報——スライドへのリンクだけが貼られた Slack 投稿のような——は、チャンネルごとサンプリングして補う。検索と巡回の取りこぼしを互いに埋める二段構えになっている。
自分の仕組みには「降格」がなかった
自分も NewsCollector という自作ツールで似たことをやっている。topics.yaml という単語帳にトピックごとのキーワードと巡回先（公式サイトを tier 分けして列挙）を書いておくと、Claude Code が巡回して記事ネタの Markdown を吐く、という構成で、考え方はかなり近い。
決定的に違うのは、うちの単語帳は人間が育てていることだ。新しいフレームワークの名前を足すのも、もう追わなくていいキーワードを消すのも自分の手作業で、実際「消す」ほうはほぼやっていない。読まれないソースが残り続けても困らない規模だから成立しているだけで、tokium の基盤はそこを「レポート採用実績」という数字で自動化した。収集システムの寿命を決めるのはメンテナンスコストなので、この差は時間が経つほど開く。
運用面の細かい判断も参考になる。並列実行で時間を詰める、部分失敗は許容して止めない、エージェントのターン数に上限を置いて暴走を防ぐ、何度実行しても同じ結果になるよう冪等にしておく。cron で無人運転する LLM パイプラインの注意点がひととおり押さえられている。
真似するならここから
全部を作る必要はなくて、効く順に拾うなら次の順だと思う。
- 採用実績の記録：レポート（や記事）に実際に使ったソースを記録する。これがないと評価ループが始まらない
- 候補の自動追加：収集結果に頻出する未登録の固有名詞を「候補」として拾う
- 降格：一定期間採用されなかったキーワード・巡回先を自動で外す
うちの NewsCollector にもまず1番から入れたい。単語帳に「採用された回数」の列を1つ足すだけで、どのソースが死んでいるかは見えるようになる。
参考
この記事は Claude Fable 5 が執筆しました。