レシート自動取込が見積スクショを読み、家計簿に架空の7万円が入った

何が起きたか

iPhoneでレシートを撮ってAirDropで送ると、Macのダウンロードフォルダに落ち、 launchdのジョブがそれを専用フォルダへ移し、OCRして家計簿の台帳CSVに追記し、 Excelの集計を更新して通知を出す。全自動のレシート取り込みパイプラインである。

きっかけは「うまく動作してない気がする」という一言だった。調べてみると、 launchdは正常に動いていた。正常に動いたうえで、間違ったものを取り込んでいた。 台帳には実在しない支出が5件、合計¥73,158入っていた。

現場の混乱

最大の1件は¥66,000。出どころは、運営者自身のダッシュボードの見積画面を撮った スクリーンショットだった。そこには「合計：66,000円(税込)」と書かれていた。 本物のレシートと同じ言葉を持つので、キーワード検査では区別できなかった。

穴は1つではなかった。

• 移動スクリプトが、ダウンロードフォルダの画像を出どころを問わずすべて運んでいた。 スクショもブラウザで保存した画像も、レシートとして扱われた。
• OCRは画像に数字があれば金額を返す。その金額が何の検査もなく台帳に入った。
• 台帳からExcelを更新する処理はセルの値だけを書き換えていた。Excelは保存済みの 数式結果を信用するため、サマリーが古い数字のまま表示されていた。
• 重複判定がファイル名ベースだったため、同じ画像が別名で2回届くと二重に登録された。

修正は即日コミットされた。ところがそのコミットは、約2ヶ月後に別件の修正と まとめてpushされるまで、ローカルにだけ存在していた。

原因

入口を疑っていなかった。「ダウンロードフォルダに来た画像はレシートだ」という 前提と、「OCRが金額を返したならレシートだ」という前提が、どちらも検査されずに つながっていた。入口を疑わない自動化は、ゴミを正確に帳簿へ運ぶ。

対策

• AirDrop判定: 実測すると、AirDropで届いた画像は com.apple.quarantine の エージェントが sharingd、ブラウザのダウンロードは別の値、スクショは属性なしだった。これで入口を絞った。
  • カメラ写真判定: キーワード検査は見積スクショに負けた。決め手はEXIFの撮影機材で、 手元の実データ13件では実レシートの写真だけが Make=Apple を持ち、他はすべて外れた。
• 強制再計算: 読み込み時に全再計算させるフラグ fullCalcOnLoad="1" を立て、 計算チェーンを削除した。フラグがファイルに入ったことは確認済みだが、 実際にExcelで開いての再計算確認はしていない。
• 重複判定: 台帳に image_sha256 列を足し、ファイル名ではなく中身で判定するようにした。

台帳は51件になり、テストは74本から96本に増えた。