ブログ一覧

技術ニュースの自動収集を月 1ドル未満でも止めた

更新: Web開発者向け

毎朝 8時に技術ニュース 15件のまとめが Slack に届いていました。各記事に自分が使っている言語やサービスとの関係を 1行ずつ添えた物です。私はこのまとめを開かずに流していました。自動で届くまとめを読まなくなったとき、頻度や体裁を直せばよいのか、止めるべきなのか。

私は個人で開発と運用をしていて、コードを書く作業の多くを Claude Code(Anthropic のコーディング用 AI エージェント)に任せています。このまとめは自分で作った仕組みで、7か月動かし、費用は月 1ドル未満でした。

結論から書くと、読まなかった理由は頻度でも体裁でもなく、読んだ後にすることが無かったからです。同じ Slack でも、承認や対処が要る通知は読んでいました。費用に問題は無く、読まれないので止めて片付けました。

月 1ドル未満で動いたが、要約は浅かった

仕組みは単純です。技術ニュースを 1日 3回集め、gpt-4o-mini(OpenAI の安価な言語モデル)で記事ごとに自分の使っている技術に関係するかと重要度を付けます。毎朝 8時にまとめを、月曜に週次のレポートを Slack に送り、AWS のサーバーレスで動かしていました。

残っていた 9週分の集計では、1週あたりの数は次のとおりです。

  • 集めた記事: 約 15,300件
  • 自分の使っている技術に関係する物: 約 120件
  • 重要度が高いと判定された物: 3〜11件(ほぼすべてがセキュリティ情報と障害情報)

費用は OpenAI が週 0.04〜0.07ドル、AWS が月 1ドル未満で、合わせても月 1ドルに届きません。ただ、要約の一文は「v16.2.0-canary.102が登場!」「Qwenの動向に注目!」といった水準でした。

頻度と体裁を直しても、開かなかった

開かないまとめを一度手直ししています。

  1. 記事ごとにすぐ届く通知をやめる
  2. 取得を 1日 3回にする
  3. まとめの件数を 50件から 15件に絞る
  4. 各記事に、自分の使っている技術との関係を 1行添える

狙いどおりに届くようにはなりましたが、それでも開きませんでした。半年を振り返っても、このまとめがきっかけで何かをしたことは一度もありません。

読んでいた通知には、次にすることがあった

同じ Slack に届く通知でも、読んでいる物がありました。

  • X(旧 Twitter)への投稿案が届き、承認のボタンを押す通知
  • 対処が要る監視のアラート

どちらも、読んだら次にすることが決まっています。技術ニュースのまとめは、読んでも読まなくても何も変わりませんでした。

そもそも積極的に技術の流れを追う必要が無くなっていた

振り返ると、私はもう以前のように積極的に技術の変化を追っていませんでした。理由は 4つです。

  1. コードを書く作業を Claude Code に任せていて、関心が技術そのものより、何を作るか、いくらかかるか、どう使われるかに移った
  2. 変化が速すぎて、追いつける量ではない
  3. 脆弱性は、知った時点でもう修正版が出ている
  4. 大きな事件は SNS のトレンドで耳に入る

取りこぼすと困る脆弱性や事件は、これで足ります。7か月で重要度が高いと判定された約 380件も、大半は Dependabot(依存パッケージの更新や脆弱性の修正を GitHub が自動で PR にする機能)と GitHub のセキュリティ勧告で拾える物でした。

まとめで解決したい困りごとが無いので、頻度や体裁をいくら直しても読まないと考え、まとめを作り直して使い続ける案を捨てました。

関心が移った先の「何を作るか」に合わせて、まとめを作り直す案も捨てました。何を作るかの答えは自分の案件と自分のシステムから出てくる物で、外の記事を集めても見つかりません。情報は多いほどいいと思って集めていましたが、集め方で見直すべきだったのは量ではなく、自分の仕事にどれだけ近いかでした。

送るのを止めるだけでなく、全部片付けた

最初は Slack に送るのだけを止め、収集と保存は続けました。残した収集と保存にも使い道が無くなったので、クラウドの資源を消し、リポジトリは GitHub でアーカイブしてコードだけを残しました。データも、要る数字だけを抜き出して消しています。依存パッケージの更新と脆弱性は Dependabot に任せています。

収集だけを止めて仕組みを残す案は採りませんでした。使い道が無いのに、依存パッケージの更新や認証情報の手入れだけが残るからです。データも、判断に使われたことが一度も無いので残していません。

通知を残すかどうかは、読んだ後にすることで決める

いまは次の基準で判断しています。

  • 読まれない通知は、頻度や体裁より先に「読んだ後、私は何をするか」を問う。「承認する」「対処する」のように答えられない通知は、直しても読まれない
  • 道具を残すかは費用ではなく、出力が読まれて行動につながったかで決める
  • 使わなくなった道具は止めるだけでなく片付け、コードと要る数字だけを残す
  • 情報は自分の仕事と使っている技術に近い物を集める

関連

この記事をシェア