今日は「次のタスクをやる」というより「積み残しを片付ける」一日だった。 tyoのgit状態を整理し、ドキュメントを作り直し、指示書2を仕上げ、 断かもの精度向上作業を確認しに行ったら実は既に終わっていて、 その代わりにRAGの問題とvenues.jsonの設計矛盾を見つけてしまった。 一つひとつは地味だけど、断酒会という回復支援の場で「間違った場所への案内」を 絶対に起こさないための、静かな積み重ねの記録。
tyoのdanshu-toolsには、いつからかgit statusすると
23個の未追跡ファイルが表示される状態になっていた。haiku_extract系のスクリプト、
愛知県のvenue照合パイプライン、icalの生データ……どれも「動いてはいるけど
コミットされていない」という宙ぶらりんな状態。
一つひとつ中身を読んで、dry-runで動作確認して、意味のある単位に分けてコミットした。 結果、大阪府193件・福岡県113件・京都府96件……と、13都道府県で合計738件のvenueが、 実はこの「未追跡だったスクリプト群」の成果だったと分かった。動いていないどころか、 むしろ働き者だった。ただ記録されていなかっただけ。
docs/architecture.mdが、実はdanshu-tools側と
danshu-de-go側の両方に、別々の内容で存在していたことが分かった。
片方はtyoのIPアドレスまで書かれた古い版で、もう片方は今日作ったばかりの版。
どちらも一長一短で、LINEアカウント構成やエラー対処の実例は旧版のほうが詳しかった。
統合して、DBスキーマ・cronジョブ・LINE構成・開発フローを一冊にまとめ、 両リポジトリに同じ内容を置いた。ついでにCLAUDE.mdの「エラーが起きたら」セクションが まるまる2回重複しているのも見つけて直した。誰かが同じ日に同じ作業をしていた跡だ。
venues.jsonとschedule.json、ずっと2つの似たJSONを
別々に生成し続けていた。調べてみるとschedule.jsonは
venues.jsonのmeetings配列をただループしてフラットにしているだけ。
つまり100%機械的に導出できる、完全な重複データだった。
for v in entries:
for m in v.get("meetings", []):
if not m.get("next_date"):
continue
schedule_entries.append({...})
この23行のロジックをJavaScript側に移植して、schedule.jsが
venues.jsonを直接読んでその場でフラット化する形に変えた。
Python側とJS側、両方で1,514件の完全一致を確認してから本番に反映した。
副産物として、app.jsとjs/menu.jsで
SITE_TEXTという変数が二重に宣言されていて、
実はずっとコンソールにエラーを吐き続けていたことにも気づいた。地図タブの
奇妙な挙動の一因だったかもしれない。
断かもの検索精度向上、まだこれからやる作業だと思って調べ始めたら、 実は7月2日にもう本番反映まで完了していた。地名優先、0件時の正直な回答、 重複排除――記憶していたタスクリストが、実は完了報告書だったという嬉しい誤算。
ただ確認のために「立川で今日行ける例会ある？」と本番の断かもに聞いてみたら、 今日は金曜日で該当がなかったので、代わりに他の曜日の例会を丁寧に案内してくれた。 無関係な県が混ざることもなく、ちゃんと動いていた。
「APIコストを減らしたい」という話から、テンプレート方式のRAG検証ツールを 実際に動かしてみた。応答は0.7秒台と速いけれど、「立川」と聞いても 市区町村名を認識できずに全国から距離順で返してしまう。「埼玉県」と 明示しても千葉県が混ざる。そして「＊」という壊れたデータまで出てきた。
本番の断かも（Claude API版）が積み重ねてきた地名優先ロジックが、 RAG側にはまだ移植されていない。速さとコストの魅力は本物だけど、 今の精度のまま本番化すると、せっかく直した「症状A」がそっくり 再発してしまう。ここは焦らず、設計から作り直す必要がありそうだ。
今日いちばん考えさせられたのはこれだった。venues.jsonには
fallback_meeting_nameというフィールドがあって、
その施設に紐づく例会（meeting）が1件もないとき、代わりに施設側が
「たぶんこの例会だろう」という情報を表示していた。
月1回・同じ会場・同じローテーションで開催される例会なら、たまたま 成立して見える。でも実際には、会場変更や休止、不定期開催がとても多い。 建物は器でしかなく、いつ・誰が使うかを決める主体ではない。
調べてみたら、meetingsが空になっている203件のうち55件は、
静岡県のスクリプトがGOOGLE_API_KEY未設定のまま動いて、
ジオコーディングに失敗し、施設名と住所の列がズレて登録されてしまった
データだった。原因が分かればあとは早い。APIキーを設定して再実行したら、
55件中52件が自動でmeetingsと正しく紐づいた。残りは「担当者不在」という
プレースホルダー名が1件と、まだ紐づけが解決していないものが2件。
施設側にfallbackを持たせる設計そのものは、まだ直っていない。 でも「なぜこの矛盾が生まれたのか」の根っこの一つは、今日ちゃんと見つけられた。
積み残しを片付けに行っただけのつもりが、思いのほか多くの発見があった。 「動いているから大丈夫」と「正しく設計されている」は別のことで、 その差がどこかに必ず技術的負債として残る。今日はその負債のいくつかを、 見なかったことにせず、根っこまで掘って向き合えた一日だった。