「同期すべてOK」と書いたのは、作業した本人だった — 監視メールが1か月ウソをついていた — 制作日誌 #23

毎朝7時に、自分宛てに家計の集計メールが届く。自分で組んだ自動処理が、いくつかの明細を集めて1通にまとめる仕組みだ。

そのメールの片隅に、小さな警告マークが出ていた。ずっと出ていた。私はそれを1か月近く見ていて、1か月近く放っていた。

調べた結果、欠陥は1つではなく3つあった。しかもいちばん重い1つは、私が自分で仕込んだものだった。

見つかった穴を、重い順に

数字の並びだけ見ると2番が重そうに見える。実際に効いたのは1番だ。1番があるせいで、2番は「気づく機会」を2回失っている。

1. 報告を書いていたのは、作業した本人だった

この仕組みには、その日の作業結果を記録する小さなファイルがある。何が成功して何が失敗したかを書いておき、朝のメールはそれを読んで組み立てる。

問題は、そのファイルの一部を自動処理の親玉（AIの手順書）が手で書いていたことだった。外部サービスを叩く処理を呼び出したあと、「たぶん通っただろう」という前提で結果欄に「ok」と書き込む。実際に通ったかどうかは、誰も確認していない。

結果、失敗している日にも堂々と「同期 すべてOK」と書かれたメールが届いた。2日ぶん、私はその嘘を読んで安心していた。

例えるなら、荷物を運んだ人が自分で受領印を押しているようなものだ。運んだ本人は「届けたつもり」なので、玄関先に置き忘れていても書類上は完了になる。受領印は、受け取った側が押さないと意味がない。

直し方は素直だった。

• 結果欄は、実際に叩いた処理が自分で書く。 手書きは禁止にし、手順書にもその一文を足した
• 書くのは「ok / ng」だけでなく、接続先ごとの最終同期日時と、失敗していればその画面に出ていた原因の文章そのもの
• メール側にも関所をもう1つ置いた。結果欄が「ok」でも、最終同期日時が当日でなければ赤札を出す

2番目の関所が肝心だ。1つ目の関所を通る嘘は必ず出てくる。嘘をつけない情報（日時）で、もう一度照合する。

2. 切れていた接続は、ログインし直すだけで戻った

外部サービスの画面には、更新に失敗した理由がこう出ていた。カード会社側で確認事項があり、利用分の決済を停止している、と。

文面だけ読むと「カードが止められた」ようにしか読めない。実際にはカードは止まっていない。普通に使えている。

原因は、カード会社の会員ページに解約済みの古いカードが1枚残っていたことだった。外部サービス側は、そのカード会社の3枚を1つの口座としてまとめて掴んでいる。そのうち1枚が無効なので、束ごと失敗扱いになっていた。

厄介なのは、無効な1枚だけを外すことができない点だ。設定画面にはこう出る。すでに明細を取得しているため設定は変更できない、変更したければ口座を作り直せ、と。作り直すと過去の明細との繋がりが切れる。割に合わない。

効いた手順は拍子抜けするほど短かった。

1. カード会社の会員ページに1回ログインする
2. 外部サービスの失敗画面で**「更新」を押す**

数分後に同期が通った。ログイン情報の入れ直しも、口座の作り直しも不要だった。同じ症状が出たらこの2手を最初に試す、と手順書に書いた。

そして、この31日間で家計の数字が欠けていたわけではなかった。ここは調査中に私自身が一度読み違えている。当初は「今月の支出にカード分が丸ごと入っていない」と判断したが、実際には集計側は別の経路を見ており、欠落はなかった。外部サービスの画面に出ていた「未登録の明細が大量にある」という表示に引きずられただけだ。警告の数と、被害の大きさは比例しない。

3. 手順書には書いてあった。コードには無かった

ついでに調べていて、3つ目が出てきた。

取引の履歴をダウンロードする処理が、手順書には「前の手順のログイン状態をそのまま使って取る」と書いてある。ところが実際のコードは、その前の段階でブラウザを閉じていた。誰も続きを実行できない。

最後に取れていたのは7月15日。約2か月、誰も気づかないまま止まっていた。手順書は日本語で書かれた願望で、コードが現実だった。手順書とコードがずれた時、動くのは常にコードの方だ。

実装して走らせたら、抜けていた4日ぶんの取引がそのまま入った。穴は埋まった。

順番を入れ替えても直らなかった

ここで1つ、地味だが引っかかった現象がある。

ダウンロード処理を保有一覧の後ろに置くと、「対象のページはすでに閉じられている」というエラーで落ちる。では前に移せばいいかというと、今度は後ろに回った保有一覧側が同じエラーで落ちる。

つまり順番の問題ではなく、先にダウンロードした方が、そのページを道連れにして閉じてしまうのが本体だった。数日前に別件で見た「保存だけ失敗して、中身が一時ファイルのまま残る」という症状も、たぶん同じ現象の別の顔だ。

対処は、ページが閉じていたら作り直して元の場所に戻る、という復旧処理を挟むこと。ただしこれはまだ実地で検証していない。同じ日に4回もログインするのを避けたためで、翌朝の自動実行が初回の検証になる。ここは「直したつもり」の段階だと、自分で書き残しておいた。

失敗した時に、古い数字を消さない

もう1つ、調査の途中で自分が壊したものがある。

処理を途中で止めた時、その日の残高欄が空っぽで上書きされた。数時間前の実行ではちゃんと取れていたのに、あとから来た失敗が、成功していた記録を塗り潰した形だ。

失敗時の処理に「その日すでに取れている値があるなら、それを残す」を足した。失敗は、何も書かないのが正解で、空白を書くのは間違いだった。

締めに、分類の話

同じ日に、明細の自動分類も回した。判別できない項目が19件から8件に減り、本人（私）に聞いて残りを潰して2件になった。残る2件は2024年の個人名の送金で、これはもう思い出せない。

1つだけ、ここでも危ない間違いをした。店名から業種を当てて分類したら、それが実は返金だった。支出として名前で分類すると、収入の側に計上されてしまう。金額の符号を見ずに、店名だけで分類してはいけない。

この日に学んだ一行

3つの欠陥は互いに無関係だったが、共通点が1つだけあった。**どれも「動いているように見えていた」**ことだ。

• 報告文は出ていた。中身が実態と違っただけ
• 同期は毎朝走っていた。1つの口座だけ失敗していただけ
• 手順書は完成していた。コードが対応していなかっただけ

自動化で本当に怖いのは、止まることではない。止まったのに止まったと言わないことだ。だから結果欄は作業した本人に書かせず、嘘をつけない情報でもう一度照らす。今回入れた関所は、それだけの話だった。

毎朝の警告マークを1か月見逃した件については、言い訳がない。小さく出しすぎたのが悪い、とも言えるが、それは次の設計の話にしておく。