以前の記事で、AIや開発まわりの情報を集めるために、Notionへ「AI Research Radar」を作っていると少しだけ書きました。
🌱 
Astro × NotionのBlogを、もう少しちゃんと使っていきたい
なお、このAI Research Radarは、 ベク（@beku_AI）さん がXで公開されていた仕組みを参考にさせてもらっています。
そこから、自分が追いたい情報源や「自分への活かし方」、Blogまでの流れを足しながら、Notion上で少しずつ自分用に変えてきました。
そのときはBlogを書く流れの中で、ほんの少し触れるくらいのつもりでした。
でも、その後も毎日使っているうちにDBが増えて、Blog Pipelineまでつながって、、気づけば思っていたよりちゃんとした仕組みになってきました・・！
そもそも、気になったAIニュースを保存するだけなら、ブックマークでもNotionの1つのDBでも十分です。
私が欲しかったのは、そこからもう一歩だけ進んで、 「これ、自分なら何に使う？」まで残せる場所 でした。
OpenAIやAnthropic、GitHub、Notionの公式情報。Hacker NewsやReddit、Product Hunt、GitHub Trending、海外メディアなど。
見ようと思えば、本当にいくらでも出てきます。
全部を追うのはたぶん無理なので、今は「見つける」「残す」「今日の分を見る」「記事候補へ送る」をNotionの中で分けています。
Radarを支える4つのDB
今は、こんな4つに分かれています。
- Sources ：どこを見るかを管理する
- Signals ：残しておく価値がある情報だけを保存する
- Daily Briefs ：その日の要点を1件にまとめる
- Blog Pipeline ：記事に育てたいものだけを送る
最初から4つに分けて設計したわけではなく、使っているうちに少しずつ増えました。
我ながら、こういうものを作り始めるとDBが増えていくのは、いつものパターンです。。
でも今回は、それぞれに役割があるので今のところ散らかった感じはあまりありません。
むしろ「保存したけど、その後どうするんだっけ」が減ったのが一番大きかったです。
Signalsは1日5〜15件だけ
一番最初に決めたのは、見つけた情報を何でもSignalsへ入れないことです。
毎日の調査では、原則として直近24〜72時間くらいを見ています。
その中でも、自分が普段触っているものや、今のプロジェクトに近い話を優先しています。
- AIモデル
- Codex / Claude Code
- Notion
- 開発ツールや自動化
- 個人開発
- SaaSや収益化
同じニュースを別メディアが書いているだけなら、基本は重複扱いです。
一次情報があるものは、できるだけOpenAIやAnthropic、GitHub、Notionなどの公式を先に見ます。
そうすると、Signalsへ残るのはだいたい1日5〜15件くらい。
このくらいなら後から見返せますし、「たくさん集めた」より「自分に関係あるものだけ残った」の方が、今の自分には合っています。
「自分への活かし方」がSignalsの中心
Signalsには、トピック名やURLだけではなく、いくつか自分用の項目を持たせています。
たとえば、
- 重要度
- アクション
- なぜ重要か
- 自分への活かし方
- 発信切り口
- 信頼度
あたりです。
特に気に入っているのが、 「自分への活かし方」 です。
ニュースの内容を短くまとめても、数日後には「で、これ何が気になったんだっけ」となりがちです。
そこで、たとえば新しいCoding Agentの機能なら「このrepoのQAで使えそう」、Agentのsecurity問題なら「CodexやClaude Codeの権限設定を見直す」といった形で、自分の作業へ戻すところまで残します。
アクションも、
- 発信候補
- 試す
- 実装候補
- 監視
- 読む
のように分けています。
ここまで残しておくと、Signalsはニュース一覧というより、少しToDoに近くなります。
あとで見たときに「これ、何のために保存したんだっけ」が減るのが地味に助かっています。
情報より先に、取りに行く道を管理する
情報源はSources DBに分けています。
海外メディア、Hacker News、Product Hunt、中国圏、GitHub Trending、Reddit、note、公式一次情報などを登録して、毎日見るものと数日おきでいいものを分けています。
取得しにくくなった情報源は、状態を「取得困難」や「代替経路」に変えます。
ここは、Radarを毎日回すようになってから気になり始めたところです。
情報そのものはあるのに、いつも通りの方法では取りにくい。そんなことも普通にあります。
同じURLやAPI、RSSがずっと使えるとは限らないので、Sources側に「稼働」「代替経路」「取得困難」を残すようにしました。
ニュースより先に、取りに行く道の方を気にすることになるとは思っていませんでした。。
Daily Briefは、その日のRadarの1枚版
Signalsが増えると、今度は一覧を見るだけでも大変になります。
そこでDaily Briefsを作りました。
その日に保存したSignalsから、
- 今日の要点
- 今すぐやる価値があること
- 発信に使えそうなもの
- 取りこぼした情報源
を1件にまとめます。
毎日すべてのSignalsを読み返すのは、たぶん続きません。
なので「今日は何があった？」となったときに、まずDaily Briefだけ見れば大体分かるくらいにしています。
細かいところが気になった日だけSignalsへ戻る。
今のところ、このくらいの距離感が一番見やすいです。
ニュースをそのまま記事にはしない
最近は、Signalsの中でBlogに育てられそうなものだけ、Blog Pipelineへ送るようにもしています。
ただし、ニュースを見つけたらすぐ記事にするわけではありません。
今は、
Radar → Blog候補 → 自分のメモ → AIで下書き → 自分で確認 → 公開
という流れにしています。
このRadarから実際に、
- Notion SkillとMCPの使い分け
- AIに保守作業をPRまで任せる使い方
- 自分用のAI benchmark
といったテーマが記事候補になりました。
この3つが実際に下書きまで進んだのを見て、ようやくRadarが「情報を集める場所」から、 自分の制作へ入っていく入口 になってきた感じがしました。
公開前に残す人間レビュー
ここは今のところ、自動公開にはせず、あえて止めています。
Radarの調査や整理はAIにかなり任せていますが、Blog記事を勝手に公開したり、Xへ自動投稿したりはしません。
記事候補になっても、本人の体験が必要なものは「本人メモ待ち」にします。
まだ試していないことを「試してみました」にしないためです。
もちろん、ここまでつながると「公開まで全部自動にできるのでは？」とも思います。
でも、そこまでやると今度は、自分が何に引っかかったのかまで薄くなりそうで。。
調査や整理はかなり任せる。
一方で「これは自分に関係ある」「ここは実際に試した」「これはまだ分からない」は、自分で残す。
今は、その少し中途半端なくらいがちょうどよさそうです。
Radarの役割：「情報収集」から「自分への変換」
AI Research Radarは、まだ完成という感じではありません。
情報源が取りにくくなることもありますし、Signalsの項目も使いながら変えています。
たぶん、これからもDBや項目は少しずつ変わると思います。
それでも毎日使っていると、その中から実際の開発やBlogにつながるものが出てくるようになりました。
最初は「AIの情報を追う場所」くらいのつもりでしたが、今はむしろ、 外から入ってきた情報を、自分の作業へ持ち帰る場所 という方が近い気がしています。
次の記事では、このRadarで見つけた情報をきっかけに気になった、Notion SkillとMCPの使い分けについて書く予定です。
こうやってRadarで拾ったものをひとつずつ実際に試して、使えたものだけまた残していく。
しばらくは、そんな使い方を続けてみようと思っています。