毎晩消費する記事ネタを、毎晩補充する仕組みに変えた
この記事について
記事の自動起稿を毎晩動かしても、候補の補充が週1回なら、供給より消費が速くなりネタ切れする。候補を集める場所、起稿できる形に整える場所、記事を書く場所を分けたうえで、補充周期を消費周期に合わせた運用を記録する。
以下では、2026年7月に改修した供給経路の構成と運用上の数値を扱う。
週1回の補充では、毎晩の消費を支えられない
以前の供給側は、週次スクリーナーが最大3本を補充する形だった。一方、自動起稿は1晩に最大3本を使う。上限同士で単純に比べれば、補充は週3本、消費は週21本になり得る。候補を使い切るのは一時的な不運ではなく、周期と量から予測できる状態だった。
もう一つ、弾数の数え方にもずれがあった。drafts/ready/ と drafts/deploy/ に記事があれば、公開待ちの在庫としては余裕がある。しかしそれらは起稿前のネタではない。候補キューの 自動起稿: OK がゼロでも原稿在庫が多いことで、起稿用の弾切れが見えにくくなっていた。公開待ちの記事と、次に書くための候補は別の在庫として数える必要がある。
供給と起稿を別の工程にする
現在の経路は、候補の発見から記事の公開までを段階に分けている。
週次スクリーナー
→ ネタ元台帳
→ リポジトリ内の素材ミラー
→ 毎晩の弾込め（01:30）
→ 毎晩の自動起稿（02:30）
→ ready/ → deploy/ → 公開（07:30、1日1本）
週次スクリーナーはセッション履歴や記録から候補を拾い、ネタ元台帳を育てる。同期スクリプトが zashstudio 向けの素材をリポジトリ内の idea_ledger.md に写し、弾込めレッグがそれを candidate_queue.md に移す。起稿レッグは候補キューで 自動起稿: OK のものを使う。この分離により、起稿側が別の場所にある台帳を直接読みに行かず、素材確認の対象をリポジトリ内に保てる。
弾込めは毎晩01:30、起稿は毎晩02:30に動く。起稿は1回最大3本で、候補がある晩に先行して原稿在庫を積む。公開はその後の別レッグが1日1本ずつ担当する。候補の補充と記事の公開を同じ工程にせず、前者は起稿の材料を整え、後者は完成した在庫を少しずつ出す。
水位と鮮度を別々に見る
弾込めレッグの低水位は6本、補充目標は8本に設定されている。起稿が最大3本を使うため、6本は2晩分の目安になる。候補が十分ある日は、LLMを起動せず grep で数えるだけで終わる。必要になったときだけ素材から候補を補うため、毎晩の確認を置いても常時生成を走らせる設計にはならない。
水位だけでは、上流の停止を早く見つけられない。素材ミラーが豊富な間に週次スクリーナーが止まると、候補数が減り始めるまで時間がかかる。そのため、最終同期から14日以上経過した場合の鮮度監視を、水位に関係なく動かす。確認を在庫不足時の分岐より後ろに置くと、在庫が十分な間は実行されない。監視の配置そのものが、検出したい故障を見逃さない条件になる。
| 見る対象 | 条件 | 分かること |
|---|---|---|
| 候補数 | 自動起稿: OK が6本未満 | 起稿用の弾が減っている |
| 素材ミラーの鮮度 | 最終同期から14日以上 | 上流の同期が止まっている可能性 |
| 補充結果 | 補充後もOKが増えない | 素材不足または弾込めレッグの問題 |
やってみて分かったこと
公開記事や原稿の在庫があっても、次の記事を書く候補があるとは限らない。どの工程の在庫を測っているかを揃えないまま合算すると、起稿レーンに必要な材料不足が隠れる。候補、素材、原稿、公開待ちを別の段として数え、それぞれの周期に合わせた監視を置くことが、ネタ切れを運用上の偶発事象ではなく設計で扱う方法になる。
更新履歴
- 2026-10-08: 初稿。