ネタが思いつかない、というより、ネタを探している時間そのものがもったいない。個人で発信を続けていると、そう感じる瞬間が増えてくる。
GitHubを見て、Hacker Newsを見て、ついでにSNSものぞいて、気づけば小一時間。それで結局、書き始めるのは翌日にずれ込む。書く前の「探す」で一番エネルギーを使ってしまう、というのが個人発信のわかりにくい消耗ポイントだと思う。
そこで私は、ネタを探しに行くのをやめた。代わりに、GitHubとHacker Newsを毎日自動で見張って、AIに「これは使えそうか」をざっくり振り分けさせ、候補だけが手元にたまっていく仕組みを作った。私はこれを「Radar（レーダー）」と呼んでいる。
ただし、最後にどれを記事にするかは自分で選ぶ。AIが集めて、人間が決める。この線だけは動かしていない。今回は、その仕組みと、作りながら決めた運用の話を書いていく。
「探す」が、いちばんの消耗だった
ブログや発信を続けるうえで、意外と語られないのが「ネタ探しのコスト」だと思う。記事を書く時間より、何を書くか決めるまでの時間のほうが長い、ということが普通に起きる。
しかも探し方が毎回その場任せになりやすい。今日は気が向いたからGitHubを眺める、昨日はたまたまタイムラインで見かけた、という具合だと、拾えるネタが日によってブレる。良いネタを見逃した日があっても、見逃したことにすら気づけない。
この「探す作業が属人的で、しかも重い」という状態を、どうにかして自分の手から外したかった。書くこと自体は嫌いではない。嫌だったのは、書く前の助走で消耗することのほうだった。
GitHubとHacker News、この2つを見張ることにした
見張る対象は、あえてGitHubとHacker Newsの2つに絞った。理由はシンプルで、この2つはAI周りの「これから来そうなもの」が早めに表に出てくる場所だからだ。
GitHubは、新しいツールやライブラリといった「作られたもの」が集まる場所。Hacker Newsは、それについて「どう受け止められているか」という技術トレンドや議論が集まる場所。役割は違うが、どちらも自分にとってはネタの供給源という意味で同じだ。だから今回は、GitHub側とHacker News側の2つの仕組みを、まとめて「Radar」という1本の話として整理している。
逆に、対象を無限に広げないことも意識した。あれもこれも見張らせると、結局また情報が多すぎて選べなくなる。「まず見るべき2つ」に絞ったほうが、拾ったものを見る側の負担も軽くなる。
「探す」から「集まってくる」へ
Radarの考え方は、ひとことで言えば「探しに行く」を「集まってくる」に反転させることだ。
やっていることはそれほど複雑ではない。毎日決まったタイミングで一度だけ、GitHubとHacker Newsから新しいものを取ってくる。そのまま全部を目に入れると多すぎるので、次にAIに「これはFutureGearLabで扱う価値がありそうか」をざっくり判断させる。判断は「残す」か「見送る」かの2択にしていて、残ったものだけが候補として手元にたまっていく。
この判定は、手元のマシンで動かしているローカルのAIにやらせている。外部のサービスに毎回投げるわけではないので、気軽に毎日回せるのが個人には合っている。完璧な選別ではないが、「明らかに関係なさそうなもの」をふるい落としてくれるだけでも、見る量はかなり減る。
大事なのは、この一連の流れが自分の操作なしで毎日動くことだ。私が忘れていても、気が向かなくても、候補は静かにたまっていく。「探しに行く」をやめられたのは、この「勝手に集まってくる」を作れたからだった。
拾うところまではAI。選ぶのは自分
ここが今回いちばん伝えたいところなのだが、Radarがやるのは「拾って、ざっくり仕分けする」までだ。どれを実際に記事にするかは、最後は自分で決めている。
AIが「残す」と判断した候補が正解とは限らない。自分のブログの流れに合うか、実際に手元で試せそうか、読んでくれる人に説明できるか。そういう最終的な判断は、機械に丸投げしないほうがいいと考えている。逆に、AIが見送ったものの中に、自分の視点では面白いものが混じっていることもある。
だから私は「AIが集めて、人間が決める」という線を意識的に残している。全部を自動化して、AIが記事化まで勝手に決める形にはしていない。集める作業は手放していいが、何を発信するかという判断だけは自分の手元に置いておきたい、という運用方針だ。
通知漬けにはしなかった
作り始めた頃は、候補が見つかるたびに通知を飛ばす形にしていた。ネタが見つかったらすぐ知りたい、という気持ちがあったからだ。
ただ、しばらく使ってみて、これは自分には合わないと感じた。通知が来ても、その場ですぐ手を動かせるわけではない。結局あとで見るなら、通知が来るたびに気を取られるぶんだけ邪魔になる。ネタ探しの消耗を減らしたくて作ったのに、今度は通知で気が散っていては本末転倒だ。
そこで今は、通知を常に飛ばすのはやめて、候補は静かにためておき、自分が見たいタイミングでまとめて確認する形に落ち着いている。毎日自動で拾ってはいるが、それを常時見張るわけではない。「集めるのは自動、見るのは自分のペース」というバランスが、個人でやるにはちょうどよかった。
3台のマシンと、ためておく場所
このRadarは、3台のマシンを役割で分けている中の一部として動いている。以前に、監視役のMac miniと、司令塔のMacBook Airと、重い処理を回すGPUマシンで役割を分けている、という話を書いた。Radarを毎日動かしている担当は、そのうちの常時稼働している監視役のマシンだ。
常に起動しているマシンに見張り役を任せているので、自分が使う作業用のマシンを閉じても、ネタ集めは止まらない。ここは「一台で全部やろうとして詰まる」を避けるために役割を分けておいてよかった部分だと思う。
拾った候補は、そのまま自分の知識をためている場所（私はSecond Brainと呼んでいる）に流れ込むようにしている。集めたネタが一箇所にたまっていくので、後からまとめて見返したり、記事にするときの材料として使い回したりしやすい。集めて終わりではなく、たまった先で使える状態にしておく、というところまでを含めて「仕組み」だと考えている。
まとめ：探すのをやめて、選ぶことに集中する
ネタ探しは、続けるほどじわじわ効いてくる負担だ。だからこそ、そこを仕組みに任せて、自分は「どれを書くか選ぶ」ことと「実際に書く」ことに集中したかった。GitHubとHacker Newsを毎日自動で見張り、AIにざっくり仕分けさせ、残ったものだけを自分のペースで見る。やっていることはそれだけだが、書く前の助走がずいぶん軽くなった。
ポイントは、自動化する範囲を欲張らなかったことだと思う。集めるのは自動、選ぶのは人間。この線を引いておくと、AIに任せていても発信の中身は自分のものとして残る。
今回のRadarは、以前書いた「監視役のMac mini・司令塔のMacBook Air・重い処理を回すGPUマシンで役割を分けている」という全体像の中で、情報収集を担う部分にあたる。全体像のほうもあわせて読んでもらうと、なぜこの分担にしているのかが伝わると思う。また、こうして拾った候補が本当に反応されているかをXで裏取りする話や、そもそも拾ったネタをどう選ぶかについては、別の記事で書いている。ネタを集める入口がこのRadarで、その先の「選ぶ・確かめる」につながっていく、という位置づけだ。
コメント