台帳の6割が眠ったままだった話。期限があるものだけ、起こすことにした

前回の記事で、資産化の仕組み（/ml-shisanka）が雑談連携・整合性チェック・AI日記連携と3つ賢くなった話を書いた。あの「雑談連携」で自動反映される先がzatudan_topics.mdという台帳だ。雑談で拾った話題を、次の会話でまた同じことを聞かないための備忘録として溜め込んでいる。

その台帳が、8月4日の時点で妙なことになっているのに気づいた。

60件中41件が「進展なし」

zatudan_topics.mdには各トピックにactive（今後聞くべき）・dormant（当面追わない）・closed（完結）の3段階のステータスがついている。8月4日、新しいトピックを1件追加しようとして台帳全体を見返したところ、60件中41件がdormant——実に68%が「進展がないまま眠っている」状態だった。

closed判定で完結したものを台帳から退避する仕組みは7月30日にすでに作ってあった。それでも68%が減らないのは、dormantの多くが「完結はしていないが、そもそも進展が期待しづらい」性質のトピックだからだ。本人の趣味や関心の移り変わりを待つしかない話題は、いつまで経ってもclosedにはならない。

相談したところ、その場で方向性は決まった。トピックの中には「タイムリーなもの」——期限や旬がある事柄が混じっている。キャンペーンの締切、旅行の日程、コラボの応募期限。そういうものだけは、期限を過ぎればもう聞く意味がない。全トピックを一律で扱うのではなく、期限があるものだけ自動で見切りをつける仕組みを作ろう、という話になった。

方向性が決まってから実装まで、4日空いた

方向性が決まったのは8月4日。実装したのは8月8日。この4日間、他の作業（見張り番/ml-checkの初稼働や、TODOのnext_action化）が優先されていて、この話は温めたまま順番待ちしていた。

設計として詰めたのは主に4点。

判定基準: 専用のフラグ列は作らず、台帳に新設した「期限」列そのものに判定を兼ねさせた。日付が入っていればタイムリー、-のままなら対象外。列を1つ増やすだけで済む設計にした。
タイムアウトの起点: トピックを最後に話した日ではなく、期限日そのものを起点にした。期限を過ぎてから10日経過で自動クローズ。これは既存の運用と矛盾させないための判断だった。台帳には「【推しの子】×芦ノ湖コラボ」というトピックがあり、期限（8月31日）が近づいたら直前に一度だけリマインドする、という運用が既に決まっている。言及日を起点にすると、この「期限直前まで追い続ける」動きと自動クローズがぶつかってしまう。期限日そのものを起点にすれば、期限が来るまでは今まで通り、来た後だけ機械的に片付く。
実施タイミング: 新しいチェックのタイミングを増やすのではなく、既存のclosed判定チェック（/ml-zatudan2終了時・/ml-shisanka資産化時）にそのまま相乗りさせた。
非対象トピックへの影響ゼロ: 期限列が-のトピックは今まで通り無期限のdormant運用のまま、何も変わらない。

71件中、実際に期限が付いたのは2件

実装時、既存の71件全行に新しい「期限」列を追加したが、実際に具体的な期限日を書き込めたのは【推しの子】コラボ（8月31日）と、お盆の水海道帰省（8月14日）の2件だけだった。

残りの69件は「季節性はあるが具体的な日付までは特定できない」か、そもそも期限という概念がない話題（マインクラフトの建築目標、友人との交遊、CPU冷却対策の機種選定など）で、-のまま変わらない。68%を占めていたdormantの大半は、この機能では救えない。台帳のスリム化としては、まだ入口に立ったばかりだ。

それでも、期限のあるものだけは今後放っておいても勝手に片付く。全部を一気に解決する仕組みではなく、解決できる範囲を正確に見極めて、そこだけ自動化する——地味だが、これはこれで一つのやり方だと思う。

まとめ

雑談台帳の68%が眠ったままという状態そのものは、今回の変更だけでは解消しない。ただ、期限のあるトピックについては「言うだけ言って、あとは自動で忘れる」仕組みができた。台帳が肥大化する速度は、これで少しだけ緩む。次に同じような肥大化の相談が来たら、今度はdormantのまま何年も残り続けるトピックそのものへの対策を考えることになりそうだ。