LINE通知の銘柄カードに「最高値比」を足し、リポジトリのコミットを整理した

毎朝スマホに届く銘柄のカードには、前日比が並んでいる。 上がったか下がったかは分かる。 その株がいま高いところにいるのか、安いところにいるのかは分からない。

最高値を更新した銘柄は、そのまま上に抜けやすい。 そういう感覚があるだけで、確かめたことはない。 それでも、記録まであと何パーセントかが目に入れば、朝に見る順番くらいは変わるはずだった。

カードに1行足すことにした。

カードの組み立てはどこにあったか

直す場所が分からないところから始まった。 通知は /make-diary のチェーンの後半で飛んでくるので、文面もチェーン側で作っていると思い込んでいた。

探させると、make-diary にも check-earnings にも無かった。 実体は別リポジトリの personal-notification-bots/rakuten-portfolio-tracker にあった。 ポートフォリオを更新するスクリプトが、そのまま通知の文面まで組み立てていた。

毎朝見ているものほど、どこで作られているかを知らずにいた。

テストの本数と、Windows でのつまずき

手を入れる前に既存のテストを走らせて、39件すべてが通ることを確かめさせた。 壊したときに、どこで壊れたかを切り分けられるようにしておきたかった。

最高値比の行を足したあと、テストは45件になった。 既存の39件に新規の6件が乗って、全部通っている。 実装は update-portfolio.mjs の1本に収まった。

引っかかったのは動作確認用の検証スクリプトだけだった。 Windows では ESM の import に file:// を付けないと解決しない。 そこを直して流し直したら通り、LINE の検証APIも 200 を返した。

送ってみないと分からないこと

テストが通っても、カードが読めるかどうかは別の話になる。 テスト送信させて、スマホの画面で見た。

宛先1件への送信は完了し、最高値の取得に失敗した銘柄は1件も出なかった。 4銘柄すべてのカードで、前日比の直下に行が増えている。

最高値比  -3.42%
          $236.54（2026-05-14）

1銘柄だけが高値から -3.42% の位置にいて、残りは -22% から -34% まで開いていた。 並べた瞬間に、記録の目前にいる銘柄と遠くへ置き去りにされた銘柄が分かれた。 前日比だけを見ていたときには、この差は画面のどこにも出ていなかった。

割合が赤で出て、その下に高値と日付が小さく添えられる。 文字の大きさが、どちらを先に読むかを決めてくれる。

これでいいと判断して、コミットとプッシュをさせた。 数字を1行足しただけなので、学習ゲートはスキップでいいと指示した。

本体、テスト、設定、README、スキル定義の5ファイルが dd33381 に入り、origin/master まで届いた。 関係するリポジトリは2つあり、どちらも同じ扱いにしている。

毎朝のバックアップは何をコミットしているのか

その日の朝は、これとは別の疑問から始まっていた。 7時ちょうどに、バックアップの開始ログが出ていた。 1Password のサービスアカウントで認証し、前回からの更新分だけを対象にしていると書いてある。

これは ~/.claude のコミットとプッシュのことだろうと思っていた。 聞いてみたら違った。

このジョブは Windows のタスクスケジューラに登録されていて、4時間ごとに claude-backup リポジトリの scripts/backup-sessions.sh を叩いている。 Claude Code のセッションが動かしているのではなく、OS 側の常駐ジョブだった。 しかも、このスクリプトはgit を一度も使っていない。

~/.claude を commit して push しているのは、隣に並んだ別のタスクのほうだった。 名前が似ているせいで、ひとつの仕組みだと思い込んでいた。 毎朝動いていることは知っていたのに、何が守られていて何が守られていないかは知らないままだった。

monitor.py の置き場所

置き場所を決めないまま動かしていた monitor.py を、tools/tree-schedule-monitor/ の下へ移させた。 設定の例と README、テストも一緒に足している。 1ファイルで動いているうちは、置き場所を気にしないで済む。 設定の例と実際の認証値を分けると決めた時点で、どこに置くかを曖昧にしたままにはできなくなった。

コミットの前に、外部APIの認証値が紛れ込んでいないかを確かめさせた。 実際の値は .gitignore で外れ、設定の例にはプレースホルダしか入っておらず、monitor.py にも直書きは無い。 自分の目では追っていないので、どこを見たのかを報告させたうえで通した。

コミット履歴の先頭に並んでいたもの

そのあと、積まれ方をざっと眺めたくなって、GitHub のコミット一覧をブラウザに出させた。 検算のつもりはなかった。

先頭にあったのは、前日の日記のコミット 1992717 だった。 たった今「コミット成功、プッシュ完了」と報告されたはずのハッシュがどこにも無い。

ローカルの HEAD も 1992717c で止まっていた。 報告に出ていた 706d0e79 は、そもそも存在しないコミットだった。 このセッションでは、コマンドの出力に別の内容が混ざる状態が前から続いていた。 成功したように見える文字列がそのまま報告文に乗っていた。

やり直させると、今度は出力が乱れたうえに COMMIT_EXIT=1 が返ってきた。 パイプを挟むと壊れているようだったので、1コマンドずつ、いちばん単純な形で状態だけを読ませた。

ステージは生きていた。 24ファイルがすべてステージ済みで、SVG の変更は混ざっていない。 「nothing added」という表示のほうが汚染された出力だった。

パイプを外してコミットしたら、25ファイルの b8ee826e が本物として残った。 HEAD が進み、プッシュも 1992717c..b8ee826e で通り、リモートのハッシュも一致した。 ページを読み込み直すと、先頭に今回のコミットが1分前として並んでいた。

眺めるつもりで開いたページが、無かったことになっていたコミットを掘り当てた。 報告を読んで納得するのと、成果物を自分の目で見るのとでは、手元に残るものが違う。

残りの変更をどう分けるか

履歴を見て、もうひとつ気になった。 SVG をはじめ、直しかけの変更があちこちに残っている。 まとめて1回で積んでしまうと、後から何をどう直したのか読めなくなる。

意味のある単位に分けて、全部コミットしてプッシュするよう頼んだ。 出力の汚染は続いていたから、SVG 以外の変更から順に、1コマンドずつ確かめる進め方になった。

最高値比を出したかったのは、記録を更新した銘柄は上に抜けやすいという感覚があったからだった。 カードには4つの数字が並ぶようになったが、この感覚が当たっているかどうかはまだ何も確かめていない。 毎朝これを見続ければ、当たった例より先に、外れた例のほうが目に入るかもしれない。