見出し画像

「スキ」の初動が気になって。Noteの反応を定点観測してみる話

最近、Noteに記事を投稿したあとの反応が、以前よりも少し遅くなっているような気がしていました。

投稿ボタンをクリックしてから、最初の「スキ」がつくまでの時間。 以前ならもう少し早かったはずなのに、今はなかなか通知が来ない。そんな曖昧な不安が、「気のせいだろうか?」という疑念に変わりました。

公式のダッシュボードでは週単位の動きは確認できますが、もっと短いスパン、つまり「今日、何が起きたか」をリアルタイムで知る術はありません。 そこで、Makeを使って特定記事の「スキ」の数を毎日自動で記録する、自分専用の「秤(はかり)」を作ってみることにしました。

技術の裏側にある、いつもの「割り切り」

仕組み自体は、Noteの特定ページから数字を拾ってきて、スプレッドシートに書き出すというシンプルなものです。

Makeのシナリオ画面。特定のノードが繋がっているシンプルな構成

構築の際、AIが提案する手順と実際の操作画面が食い違うという、いつもの壁にはやはり遭遇しました。以前なら「なぜ合わないのか」と立ち止まったかもしれませんが、今は「合わないならスクショを撮って聞き直せばいい」という、一種の割り切りで淡々と進めています。

私にとって、このツールは技術を磨くためのものではなく、あくまで「自分の知りたい数字」を手に入れるための道具に過ぎないからです。

自動化の洗礼:15分間隔の爆走

問題なく観測を始められたつもりでした。しかし、環境が整っていなかったことに気づかず、1つ失敗を経験しました。

1日1回指定時間に稼働する設定にしたつもりが、保存が反映されていなかったのか、初期設定の15分間隔で2日間「爆走」していたのです。スプレッドシートの異常な行数を見て気づきましたが、大量のクレジットを浪費してしまいました。

うっかりミスですが、「設定」と「実機確認」は別物。デジタルでも、最初の現場確認は必要らしいです。これをきっかけに、無駄にクレジット消費が起きないようにするための、いわば「ポカヨケ(うっかり防止)」を組んで運用することにしました。

ポカヨケを組み込んだMakeのシナリオ画面。同じ日に記録の取得があったかをチェックし、取得がなかったときだけ稼働するようにしました。

捨てきれない数字への「しこり」

今回、計測対象を「スキ」に絞ったのには理由があります。 AIや専門的な知見からは、「ビューは自分自身の閲覧も含まれるし、ノイズが多いので分析には向かない」とアドバイスを受けたからです。

確かに理屈では分かります。しかし、書き手としての本音を言えば、画面に表示されている「ビュー」という数字を完全に無視することへのしこりは、まだ消えずに残っています。

ノイズが含まれているとしても、その数字がそこにある以上、何らかの傾向を示しているのではないか。安易に「意味がない」と決めてしまうことへの抵抗感を抱えたまま、今はまず、確実に反応として現れる「スキ」だけを追ってみることにしました。

Googleスプレッドシート。日付とスキの数が淡々と並び始めている様子

結論は、1週間後の自分に預ける

この観測に、果たしてどれほどの意味があるのか。 正直なところ、今の私にはまだ分かりません。

1週間、毎日数字を積み上げてみて、初めて見えてくるものがあるかもしれないし、結局「やっぱりよく分からない」という結論になるのかもしれません。

意味があるかどうかを考える前に、まずは自分の直感が正しいのかを、数字という冷徹なフィルターに通してみる。 どんな結果となるのか楽しみでもあり、不安でもありますが、一旦様子を見続けていきたいと思います。


📎 過去の記事はこちら

整形は正解だったのか?立ち止まって考えた回
Vol.20:そもそも「データ整形」は必要だったのか?効率の裏側に残った違和感と、今の整理
https://note.com/toto_automake/n/ne21da7b736e8


📎 次の記事はこちら

同じ観測を、n8nでも組んでみることにした回
Vol.22:裏側の入り口「NUXT」を探し当てて。n8nで挑む、もう一つの定点観測
https://note.com/toto_automake/n/n089a94947b52


📎 リアルタイムの学習ログはこちら

Xでは、
作業中に感じた違和感や、
判断を引き受ける場面での引っかかりを、
メモや簡単な2コマとして残しています。

記事になる前の、
思考の途中経過を置いている場所です。
https://x.com/toto_automake


いいなと思ったら応援しよう!