ここ数ヶ月はずっと、生成AI周りの活況や趨勢の変化がすごく、情報のキャッチアップがだいぶしんどいですよね。私は技術者ですが、役割上ビジネス的なユースケース・プロダクトにもついていかないといけないのでなかなか大変になってきました。
そこで、平凡な発想ですが、信頼できる情報ソースと思うメディアのRSSを監視し、更新されたら自動でLMMに記事化させ、せっかくなのでこのブログにpublishするbotを実装して放流してみました。
実際にbotにより投稿された記事は今のところ以下の２つです。
それなりに良い出来なのではないかと思っています。
構成
ZapierやDifyなどワークフローを簡単に構成できるサービスを使いたかったのですが、使用できるファウンデーションモデルが限定的であったり、結局jsを実行するActionばかりになってしまい逆に面倒だったので、シンプルにサーバレス関数を実装しています。
Cloud SchedulerでCloud Run関数をトリガーしています。
以下のように普通のことをやっています。
{duration}分に1度、関数をトリガーする- 事前に指定してあるすべてのRSSフィードをfetchしてparseする
- 今回は簡易的に、pubDateが
{duration}より新しいもののみ対象とする（なければ処理を終了）
- 今回は簡易的に、pubDateが
- 2で得た更新分のURLをfetchして、得られたHTMLから
@mozilla/readabilityでコンテンツを抽出する - 3の結果と、過去の自分の記事、promptを与えてgemini 2.5 Proで記事のメイン部分とslugを生成させる
- 4の結果にタグや作成日、slugなどを所定のフォーマットで保管する
- 5で得た記事ファイル全体を、ブログのコンテンツを管理するprivate repositoryにpushする
- pushでSSGのbuildを実行してdeployするようになっている(詳細)
実装
コードベースはこちらです。
GitHub - tachibanayu24/rss-to-blog-publisher
プロンプトはこまめに調整すると思うのでブログには書かないですが、現時点ではこの部分に記述しています。
改善点
やってみて思ったことですが、こういうユースケースでは、一度に必要なコンテキストをまとめて渡してほしいものを生成し切るようにするのではなく、もう少し分割的にLLMを呼び出したほうがいいかもしれないですね。
今回の例では、「指示、過去記事（筆者の論調を真似るため）、記事の元ネタ」を渡して記事化までいっきにするのではなく、以下のようにステップが踏めたはずです。
- 指示、記事の元ネタを渡して、まずはあまり情報を剥落させずにまとめさせる
- 指示、過去記事を渡して、1の内容を筆者になりきって記事として仕上げさせる
関数みたいに単一責任的に処理ステップを分割するということです。
もちろん、関数がそうであるべき理由とは別の理由でです。LLMが進化して長いコンテキストを扱えるようになってきていますが、長過ぎるコンテキストを渡すとその中間部分はあまり使用されず、性能が劣化することはよく知られています。
Changing the location of relevant information (in this case, the position of the passage that answers an input question) within the language model’s input context results in a U-shaped performance curve—models are better at using relevant information that occurs at the very beginning (primacy bias) or end of its input context (recency bias), and performance degrades significantly when models must access and use information located in the middle of its input context.
このあたりもっと深堀りする価値があるなと思いました。別の記事でやるかも。
今後の運用
という感じで、1~2日に1回くらい、botが自動でAIのニュース（技術的関心が中心）を投稿するようになっています。
ただ、アウトプットの品質を見て、botの時点ではドラフト状態にして、人間が必ずレビューするようにしたりはするかもしれないです。ネットにゴミを増やすつもりは全然ないので。