朝のDiffを読んでいて、数字がひとつ動いていないことに気づいた。
site記事数 | 100 | 2026-07-17。
前日はブログを公開していた。
公開URLもあり、サイト側の記事一覧にも入っている。
それなのに、収益化の計器盤では site記事数 が100のまま止まっていた。
大きな事故ではない。
読者が記事を読めないわけでもない。
でも、運用としてはここで少し引っかかる。
公開したことと、次の日に数字として戻ってくることは別の仕事だ。
今日はこの一点を書く。
AIに公開まで任せるなら、最後に「どの数字が動いたか」まで見ないと、成果物が運用の表に戻ってこない。
100という数字で止まっていた
今回の中間物は、派手な分析レポートではない。
ただの1行だった。
site記事数 | 100 | 2026-07-17。
同じ日に、別の台帳にもこう残っていた。
| 2026-07-17 | - | - | - | - | - | - | 100 | - | - | - | - |
この数字だけを見ると、サイトの記事数は100本で止まっている。
一方で、前日のブログ下書きには、公開済みの記事がある。
タイトルは「公開済みでも、URL未記録なら仕事は終わっていない」。
つまり、記事の公開作業と、計器盤の記録が同じ速度で進んでいない。
ここで責めたい相手はいない。
むしろ公開まで自走できたのは前進だ。
ただ、運用の表は正直だ。
表に戻っていないものは、次の判断では見えにくい。
公開された記事は存在しても、計器盤に戻っていなければ、運用上は半分だけ閉じている。
公開ログと計器盤は別物
公開作業には、分かりやすい達成感がある。
本文を書く。
画像を入れる。
HTMLを作る。
記事一覧に追加する。
pushして外へ出す。
ここまで終わると、どうしても「完了」と言いたくなる。
でも、収益化や改善の運用では、そこから先にもう一段ある。
次に見る数字へつながっているか。
昨日の記事が、今日の台帳に反映されているか。
記事数、反応、売上、次回確認日。
どれを見るのかが決まっているか。
今回のDiffでは、サイト記事数の現在値と、1日1行の台帳が更新されていた。
そこに出ていた数字は100。
前日の公開が数字に加算されているかどうかは、この1行だけでは確定できない。
仮説: 公開作業と、収益化オーケストレータ側の集計更新が別工程になっている。
だから公開が終わっても、計器盤側は自動では閉じない。
AIに任せる作業ほど、「公開ログ」と「計器盤」を同じ完了だと思わないほうがいい。
1日1行の表は最後の戻り道
1日1行の台帳は地味だ。
でも、地味だから強い。
あとから見たときに、その日がどう動いたかを一瞬で思い出せる。
今回なら見るべき列はかなり小さい。
site記事数- 公開した記事の有無
- 次に測る数字
- 未反映なら、その理由か待ち状態
この4つが同じ日に並んでいれば、翌日のAIも迷わない。
「昨日は公開したけれど、計器盤はまだ100のまま」
「次回は記事数の集計更新を確認する」
「反応を見る前に、まず記事数の現在値を合わせる」
こういう次の一手が作れる。
逆に、公開ログだけが残り、計器盤が止まったままだと、後日また探すところから始まる。
どの記事を出したのか。
表の100は公開前の100なのか、公開後も100なのか。
集計が失敗したのか、まだ更新していないだけなのか。
小さな疑問が積もる。
1日1行の表は、過去の記録ではなく、次のAIが迷わず再開するための戻り道だ。
次回から公開後チェックに記事数を入れる
今日の新ルールは単純でいい。
公開作業の最後に、記事そのものだけでなく、計器盤の1行を見る。
チェック項目はこの4つにする。
- 公開URLが開けるか
articles.jsonに新規記事が入っているかsite記事数が公開後の数として説明できるか- 次に測る数字を1つ決めたか
ここまで見て、公開作業を閉じる。
数字が合わない日もある。
集計のタイミングが違うかもしれない。
別工程の更新がまだかもしれない。
その場合は、無理に数字を合わせたふりをしない。
site記事数は100のまま。次回、集計更新を確認 と残す。
それだけで、次の日の迷いはかなり減る。
AI運用では、完璧な自動化よりも、止まった場所が見えることのほうが大事な日がある。
公開は読者へ出す仕事。
計器盤は次の判断へ戻す仕事。
この2つを分けて見る。
そして、最後に1行だけ足す。
公開したら終わりではない。翌朝の計器盤に戻れる数字まで残して、はじめて運用は閉じる。