■ 見つけた記事を、その場で呼ばない

屋敷には勝手口と切れ端がある。書かれたものは、あとからRSSで見つけ直せる。ならば新しいものを見つけしだいXへ流せばよさそうに見える。

けれど、屋敷にはすでに日常画像、糸くず、noteの知らせなどが通る待機列がある。RSSだけが別の近道から飛び出すと、同じアカウントの投稿間隔も、夜間に流さない決まりも崩れてしまう。

そこで弥七の記事再掲は、記事を選ぶ処理と、実際に流す処理を分けた。RSSは候補を見つけ、既存の X_POST_LOG に pending の一行を置く。即時投稿はしない。

■ 最初の案は、うまく動いているようで混線した

実装ログには、この役割を以前の入口に置いたままにしないため、RSS候補の所有者を投稿キュー側へ移した記録がある。旧 scheduledYashichiArticleQueue() は互換入口として残るが、RSS候補や投稿キューを書かない。毎日10時台に動く runItokuzuPostQueueOnce() が、RSS候補の追加と待機行の処理をまとめて受け持つ。

名前に「糸くず」とある関数へRSSまで集めるのは少し妙である。だが、投稿を急がせないことを最優先にするなら、すでに時刻・順番・重複を知っている待機列のそばに置くのが自然だった。

候補は /kirehashi/ と /okatte/ から選ぶ。同じURLは投稿後60日間はもう一度候補にしない。火曜と金曜だけ最大1件、設定シートの enabled=true のときだけ積む。これは記事を量産する仕組みではなく、屋敷の中にすでにある記事を、間を空けてもう一度差し出す仕組みである。

■ 待つために直したこと

記録では、短いRSS文を作るAPI呼出しが、推論トークンで本文の枠を使い切り、候補投入前に空になる事象があった。モデル呼出しを reasoning_effort=minimal、本文上限512へ整理したのは、文章を賢く見せるためではなく、待機列へ渡す本文を空にしないためだった。

その後、遠い未来の日常画像予約に引きずられず、同じアカウントの直近予約から6時間空けた最初の枠へ置く形に直した。タグも本文とURLの後へ置き、140字の中に収めた。どちらも投稿を増やす変更ではない。待機していたものが、ほかの暮らしを押しのけないための修繕である。

■ 今はどこで動くか

現行仕様では、runItokuzuPostQueueOnce() が毎日10時台の時間主導トリガーで実行され、RSS候補は火・金だけ最大1件を追加する。候補も既存の待機行も、09:00以上22:00未満、同一アカウントの6時間間隔、post_after 到達という条件を通るまで流れない。

これはリポジトリのruntime mapに「主確認」として残る現行トリガー設定である。ただし今回、このトリガーやX投稿を実行して確かめたわけではない。ここにあるのは、候補生成と実投稿を分け、RSSにも屋敷の待ち時間を持たせた経緯である。

読み物を見つけることと、今この瞬間に呼びかけることは別だった。弥七のRSSは、見つけてもまず列に並ぶ。