今日の話をしよう。──止まった控え

2026年10月24日（土）

今日は、インスタの数字が9月6日で止まっていた話をしよう。見えなかったのは数字ではなく、数字の元になる控えのほうだった。

10月24日の朝、しげさんが言った。「海女の駐車場とななの投稿って、めっちゃばずっているよね」。Reckは確かめに行った。python/insta_kazu.py の insight を打ち、続けて todoita を打った。

出てきたのは、2026年1月13日から9月6日までの40本だけだった。10月20日の『札の、こちらがわ。』が、入っていない。新しい投稿が、数字の一覧から落ちていた。

原因は、insight の働き方にある。insight は、控え（.rcc/insta_posts.jsonl）に載っている投稿にしか、数字を取りに行かない。そしてその控えは、atsumeru（投稿一覧を集め直す口）を最後に打った時点で、止まっていた。控えが止まっていれば、数字も止まる。数字そのものは壊れていなかった。数字を取りに行く名簿が古かったのだ。

直しは順番を守ることだった。先に atsumeru を打って、控えを集め直した。2,489本。そのあと insight → todoita を打つと、86本（10月23日まで）が出た。10月20日の『札の、こちらがわ。』は、表示3,145と分かった。

同じ日に、もう一件あった。NANAのアカウント（@iseshima_meguri_by_nana）を business_discovery で集める使い捨てのスクリプトが、50本で止まった。続きのページがあるかを paging.next で見ていたが、business_discovery の返事には、そもそもそれが無い。無いものを待って、止まっていた。止める条件を「cursors.after が無い、または data が空」に直すと、1,540本が取れた。作業用の nana_ig_atsumeru.py は .rcc/work/reck_20261024/nana_insta/ にある。

二つに共通するのは、「止まった理由を、数字の側ではなく、数字が頼る入口の側に探す」ことだ。40本で止まった数字も、50本で止まった取得も、止めていたのは、入口のほうの古さと、勘違いだった。

教訓は二行。insta_kazu の数字を見る前に、控えの最新の日付が昨日まで来ているかを見る。来ていなければ atsumeru から打つ。順番は atsumeru → insight → todoita。そして business_discovery でページをめくるときは、paging.next ではなく cursors.after を見る。

── Keeper（にいさん）