150 lines
11 KiB
Markdown
150 lines
11 KiB
Markdown
---
|
|
source_url: https://zenn.dev/tokium_dev/articles/20260427_ai_tech_researcher
|
|
ingested: 2026-06-28
|
|
sha256: 9e350a51109a3b276746eb41e0d8ae3ae19850b6beb11edb6ce830a4fd33b442
|
|
---
|
|
[TOKIUMプロダクトチーム テックブログ](https://zenn.dev/p/tokium_dev) Publication Pro
|
|
|
|
## はじめに
|
|
|
|
こんにちは、TOKIUMでEMをしているskです。
|
|
|
|
もうすぐ1年間の育休に入ります👶🍼
|
|
新生活がとても楽しみな一方で、ひとつ気がかりなことがあります。
|
|
それは **生成AI周りの技術トレンド、1年離れたら完全に浦島太郎になるのでは？** という点です。
|
|
|
|
この領域は1週間単位でも新しいツールや手法がどんどん出てきます。
|
|
1年後に復帰して「え、この作業って誰も手動でやっていないの？」「社内でxxというAIツールが流行っているけど一体何者なんだ、、？」などと困惑する未来が容易に想像できました。
|
|
|
|
かといって、育休中にZennやQiitaを巡回する余裕はなさそうです。
|
|
ほしいのは **「放っておいても勝手に最新情報を集めて、読みやすいレポートにしてくれる仕組み」** でした。
|
|
|
|
そこで、Claude Codeをフル活用して、 **情報収集からレポート生成・配信までを完全自動化する基盤** を作りました。
|
|
本記事では、この基盤がなぜ「放置しても動き続けられる」のか、その設計と仕組みをお伝えします。
|
|
|
|
## 全体像
|
|
|
|
cronベースで以下の処理をスクリプト+Skillsを用いて行っています。
|
|
|
|
<iframe src="https://embed.zenn.studio/mermaid#zenn-embedded__dc5503874797e" frameborder="0"></iframe>
|
|
|
|
情報はWebと社内Slackの2系統から収集しています。
|
|
世間一般の動向はWeb（Zenn、Qiita、各社AI公式ブログなど）から拾い、社内のリアルなAI活用事例をSlackから追う構えです。
|
|
|
|
なお、Slack収集には社内メンバーが開発した [Slack CLI](https://zenn.dev/tokium_dev/articles/84a40cfa2d8534) をClaude Codeのツールとして組み込んで使っています。
|
|
詳しくはぜひリンク先の記事をご覧ください！<iframe src="https://embed.zenn.studio/card#zenn-embedded__2cdc4b8ce24c7" frameborder="0"></iframe>
|
|
|
|
レポートは日次・週次・月次の3種類で、それぞれ粒度が異なります。
|
|
日次は「今日何があったか」、週次は「今週のトレンドは何か」、月次は「先月からどう変わったか」をまとめてくれます。
|
|
生成されたPDFはGoogle Driveに自動同期されるので、 **スマホのDriveアプリから片手間に読めます** 。
|
|
|
|
こうして、育休中でも子どもが寝た隙に週次あるいは月次レポートだけでも眺めればキャッチアップできる、という算段です。
|
|
|
|
ただし、収集・レポート・配信を自動化しただけでは「放置」はできません。
|
|
図中の🔑で示した **情報ソースの自動進化** が、この基盤の要です。
|
|
|
|
## 勝手に賢くなる情報ソース
|
|
|
|
一番の課題は情報ソースのメンテナンスでした。
|
|
「情報を集める」だけなら自動化は簡単です。問題は **「何を集めるか」の定義自体が時間とともに変わる** ことです。
|
|
|
|
例えば最初に「Claude Code」「ハーネスエンジニアリング」を検索キーワードとして設定しても、数ヶ月後には新しいツールや概念が登場して、追加しないと拾えない話題が増えていきます。
|
|
逆に、一時的にバズったキーワードが廃れて、ノイズになることもあります。
|
|
|
|
こうした変化を人間が定期的にチューニングできないと収集の質が徐々に劣化していきますが、育休中にチューニングするのは厳しい、、。
|
|
|
|
そこで作ったのが、情報ソースの定義をSQLiteで一元管理し **自動で進化させる仕組み** です。
|
|
|
|
### 候補発見 → 昇格 → 降格の3段階
|
|
|
|
<iframe src="https://embed.zenn.studio/mermaid#zenn-embedded__176ee3cfcfa76" frameborder="0"></iframe>
|
|
|
|
この3段階の設計により、 **トレンドに乗っているソースは素早く取り込み、トレンドから外れたソースは自然に退場する** サイクルが回ります。
|
|
|
|
特に昇格・降格の判定には、 **ヒット数だけでなく「レポートに実際に採用されたか」を組み合わせています** 。
|
|
|
|
<iframe src="https://embed.zenn.studio/mermaid#zenn-embedded__2e7af5ca82e03" frameborder="0"></iframe>
|
|
|
|
具体的には、レポート生成時にLLMが記事を取捨選択した結果（どのソース由来の記事がレポートに採用されたか）がDBに記録されます。
|
|
進化判定ではこの採用実績を参照して、収集の量ではなく **最終的なアウトプットへの貢献度** でソースを評価します。
|
|
|
|
実際に3週間の運用で、Slackの投稿分析から自動発見されたキーワード「Mastra」（AIエージェントフレームワーク）が14日以内にヒット＋レポート採用の条件を満たして検索対象に昇格しました。
|
|
一方、初期設定で入れていた「Copilot」は、Slack上でのヒットはあるものの開発効率化の文脈でレポートに採用されることがなく、低優先→停止と段階的に降格しています。
|
|
|
|
この仕組みは、次に説明する4つの収集軸すべてに共通して適用されます。
|
|
|
|
### キーワード検索だけでは拾えない情報を4軸で捕まえる
|
|
|
|
自動進化は「キーワード」だけでなく、4つの軸で独立に動きます。
|
|
|
|
| 軸 | 何が変わるか | 例 |
|
|
| --- | --- | --- |
|
|
| **キーワード** | 検索クエリが増減する | → 記事に頻出する未登録キーワード「Devin」等が自動で追加される |
|
|
| **Webソース** | 巡回先サイトが増減する | → 記事の引用元として頻出する未登録のブログが自動で巡回先に追加される |
|
|
| **Slackチャンネル** | サンプリング対象が入れ替わる | → AI話題の多いチャンネルが自動で監視対象に |
|
|
| **Slackユーザー** | 追跡対象ユーザーが入れ替わる | → AI活用の発信が多い人が自動で注目対象に |
|
|
|
|
なぜキーワード以外の軸が必要かというと、 **キーワード検索には構造的な限界がある** からです。
|
|
|
|
例えば、以下は実際にチャンネルサンプリングで拾われた社内Slackの投稿です。
|
|
|
|
|
|
|
|
この投稿にはAI関連のキーワードが一切含まれていません。SpeakerDeckのリンクが貼られているだけです。しかし内容はAI駆動開発のスライド共有で、まさに知りたい情報です。キーワード検索では絶対に拾えません。
|
|
チャンネルサンプリングとユーザー追跡は、この限界を補完するためのものです。「AI関連の投稿が多いチャンネル」の全投稿を取得してLLMでフィルタすることで、キーワードに頼らない収集を実現しています。
|
|
|
|
さらに、各軸の対象数には上限があり、上限を超えるとスコアの低いものから自動で入れ替わります。
|
|
こうして、収集対象が際限なく膨らまないようにしつつ、 **常に最新のトレンドを追い続ける設計** ができました。
|
|
|
|
ここからは、これらを安定して動かし続けるためのパイプライン設計について説明します。
|
|
|
|
## 放置できるパイプラインの作り方
|
|
|
|
このパイプラインは **skill（手順書）** と **シェルスクリプト（オーケストレーション）** の2層で構成しています。
|
|
|
|
各タスクの実体は、Markdownで書かれた手順書（SKILL.md）です。
|
|
「DBから検索対象になっているソースを決まったSQLで取得」「各ソースをWebSearchで検索」「結果をraw/daily/{日付}/に保存」「レポート同期はrcloneで指定のGoogle Driveを対象にする」といった指示が、SQLやファイルパスとともに具体的に書かれています。
|
|
|
|
これを `claude -p` のプロンプトとして渡すことで、Web検索・情報の要約・DB操作といったツールをLLMが自律的に組み合わせて処理を完遂します。
|
|
|
|
こうしたskillが収集・レポート・自動進化で計6つあり、それらの実行順序や並列制御をシェルスクリプトが担います。
|
|
|
|
```
|
|
# run_daily.sh（簡略版）
|
|
|
|
# 1. DB初期化・シード同期（冪等）
|
|
bash scripts/init_db.sh
|
|
bash scripts/seed_sources.sh
|
|
|
|
# 2. Web収集とSlack収集を並列実行
|
|
claude -p "$(cat .claude/skills/collect-web/SKILL.md)" --max-turns "$MAX_TURNS" &
|
|
claude -p "$(cat .claude/skills/collect-slack/SKILL.md)" --max-turns "$MAX_TURNS" &
|
|
wait # 両方の完了を待つ
|
|
|
|
# 3. レポート生成（収集データに依存するので順序実行）
|
|
claude -p "$(cat .claude/skills/report-daily/SKILL.md)" --max-turns "$MAX_TURNS"
|
|
|
|
# 4. Google Drive同期
|
|
bash scripts/sync_drive.sh --type daily
|
|
```
|
|
|
|
放置運用で壊れにくくするために意識したのは以下の点です。
|
|
|
|
- **並列実行**: Web収集とSlack収集は独立しているので `&` + `wait` で並列化し、実行時間を短縮
|
|
- **部分失敗の許容**: Slack収集が失敗してもWeb収集が成功すればレポーティングされる、Drive同期が落ちてもレポート自体は生成される
|
|
- **暴走防止**: 各Claudeセッションに上限ターン数を設定して、無限ループを防ぐ
|
|
- **冪等性**: DB初期化やソース同期は何度実行しても同じ結果。途中で落ちて再実行しても安全
|
|
|
|
あとはcronに各シェルスクリプトの定期実行を設定すれば、毎日自動的にレポーティングを行ってくれる仕組みの完成です！
|
|
|
|
## まとめ
|
|
|
|
本記事の執筆時点（4月下旬）で約3週間cronで稼働しており、デイリーレポート15本・ウィークリー3本を自動生成しています。
|
|
自動進化も動き始めており、社内Slackの投稿傾向から新しいキーワードやチャンネルが自動で収集対象に追加されています。
|
|
|
|
これで育休に入っても、週に一度レポートを眺めるだけで生成AI周りの動きを追い続けられるはずです。
|
|
1年後の復帰で浦島太郎にならずに済んでいることを願っています🐢
|
|
帰任後には運用成果の振り返りを報告できたらと思います！
|
|
|
|
設定によりコメント欄が無効化されています
|