はじめに
Mac の launchd で、夜のうちに情報を集めるジョブをいくつか回している。Anthropic の公式発表と changelog を集めるもの（step7）、生成AIまわりのモデル・リポジトリ・論文を集めるもの（step9）、集めたものに点数を付けて並べるもの。出力はどれも Obsidian の Vault に Markdown で書き出し、あとで Claude Code のセッションから参照するつもりでいた。
ある日、これらのジョブを棚卸しした。ログはどれも毎日 exit 0 で終わっている。失敗の記録は無い。
そこで見方を1つ変えた。ジョブが成功したかではなく、書いたファイルを誰かが読んでいるかを数えた。
出力ファイル名で grep する
やり方は単純で、出力ファイルの名前でスクリプト置き場をまとめて grep する。
grep -rl "anthropic-updates.md" ~/.claude/scripts ~/Projects/*/scripts
ヒットしたファイルのうち、そのファイルを書いている側（書き手）を除いて、残りが読み手になる。読み手が0本なら、そのファイルは書かれるだけで、どこにも渡っていない。
棚卸しの時点の結果はこうだった。
| 出力 | 書き手 | 書き手以外 |
|---|---|---|
anthropic-updates.md（step7） |
収集スクリプトと起動シェル | 0 |
genai-YYYY-MM-DD.md（step9） |
同上 | 0 |
signal-radar.md（点数付け） |
同上 | 週次ジョブ（step8）1本 |
唯一の読み手だった step8 は、その4週間前から止まっていた。止まった日、launchd から起動した claude -p の作業ディレクトリが合わず、memory への書き込みが拒否されて、そのまま plist ごと無効になっていた。収集の側は毎日成功していたので、ログを見ても異常は出ていない。
その4週間に memory（Claude Code に覚えさせている知見のファイル）は89件更新されていた。全部、対話しているセッションの中で手で記録したもので、自動収集から上がってきたものは0件だった。
積んだだけの受け皿も、読まれなかった
読み手を作ればいい、という話でもなかった。
別の棚卸しで、会話の記録から決めごとを機械的に抜き出して _inbox_decisions.md に積むジョブも見た。こちらには読み手がいた。Claude Code のセッションが始まるときに、受け皿に溜まった件数を知らせるフック（session_start.py）が読んでいた。
それでも、3か月レビューされないまま691行に溜まっていた。1行ずつ見て採否を決めるには多すぎて、通知が出るたびに後回しになる。結局、書き手ごと止めて退避した。いまの session_start.py には、その跡が1行残っている。
# [… 削除] _inbox_decisions.md（decision_miner）は3か月未消化のため停止・memory/_archive/ へ退避。
積むものを絞った
step9 は棚卸しのその日に作り直した。集めたものを全部積むのをやめて、手元で使っているツールや進行中の案件に関係するものだけを、提案として受け皿（_inbox_proposals.md）に積む。関係するかどうかは手元で使っているツールの名前との突き合わせで決め、役に立つかどうかの判定だけをローカル LLM に任せた。
作り直した日に通しで流した結果はこうだった。
収集 70件 → 新着 3件 → 関係あり 2件 → 提案ファイルに追記 + macOS の通知
70件のうち、受け皿に入ったのは2件。受け皿は新しく作らず、セッション開始のフックが件数を知らせる既存の仕組みに相乗りさせた。
2か月後に数え直した
しばらくして、同じ grep をもう一度流した。今度はスクリプト54本を Python で読んで、出力名ごとに参照しているファイルを並べた。
anthropic-updates.md
fetch_anthropic_updates.py ← 書き手
night_step7_anthropic.sh ← 書き手（起動とフォールバック）
genai-
fetch_genai_ecosystem.py ← 書き手
night_step9_genai.sh ← 書き手
signal-radar.md
signal_scorer.py ← 書き手
night_step7_anthropic.sh ← 書き手
night_step8_weekly.sh ← 読み手
_inbox_proposals.md
proposal_judge.py ← 書き手
proposal_notify.py ← 書き手（通知）
session_start.py ← 読み手（件数の通知）
step7 の anthropic-updates.md と step9 の genai-*.md には、いまも書き手しかいない。step9 は提案の受け皿のほうに読み手ができている。step7 は、提案に変える配線をまだしていない。
読み手ができた _inbox_proposals.md の中身も数えた。
grep -c "^- \[ \]" _inbox_proposals.md
# 14
未レビューの提案が14件。古いものと新しいものは、2か月ほど離れている。
- [ ] **huggingface/diffusers v0.40.0** — …
- [ ] **comfyanonymous/ComfyUI v0.36.0** — …
- [ ] **mflux 0.19.2** — …
...
- [ ] **mflux 0.23.0** — …
積む量は 70件から2件まで絞った。それでも、2か月で14件、1件もチェックが付いていない。セッション開始のたびに件数は出ているはずで、出ていても、その場の作業が先に来る。
数え方の決まり
いまは、収集のジョブを足すときに次の2つを同じ作業の中でやっている。
- 出力ファイル名で grep して、書き手以外のヒットが1本以上あることを確かめる
- その読み手が、出力を読んで何をするのか（人に何を見せるのか）を書いておく
1 は機械で確かめられる。2 は確かめられない。今回の数え直しで分かったのは、1 を満たしても、2 の先にいる人が読まなければ、出力はやはり溜まっていく、ということだった。
毎日 exit 0 で終わるのを見て、動いていると思っていた。動いていたのは書くほうだけで、読むほうは、最初からいなかったか、いても後回しにされていた。