add

concepts/ai-research-automation.md

@@ -0,0 +1,26 @@
+---
+title: AI Research Automation
+created: 2026-06-28
+updated: 2026-06-28
+type: concept
+tags: [llm, agent, automation, workflow, dev-tool]
+sources: [raw/articles/tokium-self-evolving-ai-researcher-2026.md]
+confidence: medium
+---
+
+# AI Research Automation
+
+AI まわりの変化を追う仕組みは、単に検索結果を集めるだけではすぐ古くなる。TOKIUM の事例では、育休中でも生成 AI の動きを追えるように、Web と社内 Slack から情報を集め、日次・週次・月次の報告を作り、Google Drive に置く流れを cron で動かしている。
+
+この事例の要点は「何を集めるか」も自動で見直すことにある。検索語、巡回先、Slack の場所、人という四つの軸を SQLite で管理し、候補発見、昇格、降格の段階を通して入れ替える。単なるヒット数ではなく、最終的な報告に採用されたかを評価に使うため、量よりも成果物への貢献で情報源を選べる。
+
+キーワード検索だけでは拾えない情報を、人や場所の観察で補う点も重要。ある Slack 投稿に直接 AI 関連語がなくても、共有された資料の中身が AI 駆動開発なら、場所や投稿者を手がかりに集めて LLM がふるい分ける。これは [[llm-wiki-pattern]] の raw source 収集にも近く、入口を固定しすぎないことで後から知識化できる素材を増やす。
+
+運用面では、手順書としての skill とシェルスクリプトを分けている。収集・報告・自動見直しの具体手順を Markdown に置き、スクリプトは実行順序、並列実行、再実行しやすさ、上限ターン数、部分失敗の許容を担当する。この分担は [[wiki-maintenance-loop]] と同じく、人間が毎回判断しなくても続く手入れの形である。
+
+## Open Questions
+
+- 報告に採用された回数を、短期の流行と長期の価値のどちらとして扱うか。
+- 社内 Slack のような閉じた情報源を使うとき、個人追跡や監視感をどう抑えるか。
+- 情報源の自動昇格が進むほど、同じ話題に偏らないための探索余地をどう残すか。
+- こうした仕組みを [[digital-gardening-cms]] や LLM Wiki に接続する場合、報告と永続ページの境界をどこに置くか。