■ 天気が取れない朝がある

ふかのすけの毎日の投稿には、その日の気配が混ざっている。空模様は小さな材料だが、毎日使う材料なので、取れない朝が一度あるだけで困る。

以前の屋敷では、天気を取りに行く入口を増やすこと自体が目的になりかねなかった。けれど欲しかったのは、たくさんの予報ではない。外のサービスが少し沈黙しても、ふかのすけの一日まで空白にしないことであった。

そこで現行のGASは、日付ごとにまずOpen-Meteoを読む。取れなかったときは直近のcacheを見て、それでも足りなければ天気ICSを読む。最後まで決まらなければ、季節と日付seedから再現できる控えの気配を選ぶ。主経路は open_meteo > weather_ics > fallback と、コードにも記録にもはっきり残してある。

■ 増やしたのは予報ではなく、失敗の名前

作業ログには、天気ICSが取れない場面を一つの「失敗」にまとめず、未設定、HTTP失敗、空本文、HTML、VCALENDARではない本文、空のVCALENDAR、例外まで分けたとある。

これは細かいが大事だった。空が読めなかったとき、次に直す人が「サービスが落ちた」のか「URL設定がない」のかを区別できなければ、屋敷は同じ場所を何度も掘ることになる。

現行コードは WEATHER_OPEN_METEO_*、WEATHER_ICS_RESULT、FUKA_WEATHER_SOURCE をLoggerへ残す。投稿文を組む側にも weather_source とfallbackの有無を渡す。見た目の文章だけを残し、どこから来た気配かを忘れないための印である。

控えの気配は、毎回同じ「晴れ」ではない。季節別・雨寄り・中立の候補から日付で選ぶので、同じ日を調べ直せば同じ結果へ戻れる。もっともらしく当てるためではなく、外部取得の失敗をランダムな創作で隠さないためだ。

■ 今はどこで使われているか

この処理は fukanosuke_code.js の週次・日次の気配づくりから使われる。Spreadsheetの列や投稿処理そのものを増やさず、天気を渡す手前で吸収する形にした。そのため、天気の入口を直しても、画像生成や投稿の正本を別に作り直さずに済んだ。

現行仕様には、Open-Meteo、cache、天気ICS、deterministic fallbackの順と、各段階のログ名が残っている。一方で、このリポジトリだけからは本番GASの実行ログや外部取得の当日の成否までは読めない。この記事が記すのは、現行実装とそのローカル検証であって、特定日の本番天気取得を再現した記録ではない。

屋敷の自動化は、いつも正しい答えを言うためだけにあるのではない。取れなかった朝にも、取れなかったと分かる形で、次の朝まで灯りを残すためにある。