レシートは、印刷されたとおりには読まれない

近所のパン屋のレシートは、紙の上では完璧でした。 108円と198円で小計306円、消費税24円を足して合計330円。 どこにも矛盾がありません。 それをアプリで撮ったら、品目がひとつも取れませんでした。 3つの数字のどれひとつ、読んだ文字を品目と金額に分ける部分まで届いていなかったのです。

レシートを撮って割り勘するアプリを作っています。 読み取りがうまくいかなかったとき、ユーザーが「読み取りを報告」を押すと、 そのときの生の読み取り結果がこちらに届く仕組みにしてあります。 その報告が5枚たまりました。5枚とも、正確には解析できていませんでした。

うまくいかなかった理由が、想像していたのと違いました。 正直に言えば、精度の問題だと思っていました。字が薄いとか、影が入ったとか。 実際に起きていたのは別のことです。

5枚のうち4枚は、いまは正しく読めます。 残る1枚は、読めない理由が分かったうえで読めないままです。 何が起きていて、何をどう直したのかを書きます。

スキャナは、隣の字を返す

パン屋のレシートで何が起きていたか、読み取り結果をそのまま並べます。

※ は軽減税率の対象を示す記号です。 これが %% になったり 章 になったりする。 そして合計の最後の 0 が、数字のゼロではなく英字の O として返ってきていました。

人間の目には、どれも読み間違えようがありません。 でもスキャナは字を「認識」しているのではなく、 形の近いものの中から一番それらしいものを返しているだけです。 0 と O は形が近い。※ と % も近い。 それだけの話です。

読み間違いより厄介なもの

字が化けるのは、まだ分かりやすいほうでした。 残りの報告で起きていたのは、正しく読めているのに、買ったものではないという問題です。

レシートには、買ったものと同じ見た目で、買っていないものがたくさん印刷されています。 受付番号、呼び出し番号、電話番号、登録番号、会員番号。 どれも数字で、多くは金額と同じ列に並びます。

いちばん厄介だったのはコンビニの1枚です。 合計 というラベルの 計 が縦に割れて 言 と 十 になり、 合計行が合計だと認識されなくなりました。 その結果、合計行が「もう1つ買ったもの」として品目リストに並びました。 2品しか買っていないレシートが、3品になったわけです。

直したもの、直せていないもの

5枚とも回帰テストに固定して、品目と金額に分ける部分を直しました。 いまの結果です。

美容室の1枚だけ、まだ正しく読めません。 品目は取れるようになりましたが、合計が0のままです。 理由は単純で、このレシートには合計のラベルが印刷されていないからです。 「合計」も「お会計」も無い紙から合計を取るには、 印字された金額の関係を推測するしかありません。 それは読み取りの修正ではなく別の設計なので、 いまは「読めないレシート」として記録に残してあります。

設計を変えたこと

最初の、読んだ文字を品目と金額に分ける部分は、レシートに「理想的な字」が印刷されている前提で書かれていました。 合計 と書いてあれば合計、数字が並んでいれば金額。 その前提が、実物の前で崩れました。

いま入っているのは、こういう考え方です。

• 字が化ける前提で照合する。合計 は 合 言十 でも合計として扱う
• 数字に見えるものを、すぐ金額だと思わない。まわりに何が書いてあるかを見る
• 直せない紙は、直せないままテストに固定する

レシートは、規格の決まった帳票ではありません。 店ごとに違う紙に、店ごとに違う並びで、店ごとに違う記号が印刷されています。 その上をスキャナが通ると、印刷されたとおりの字は返ってきません。 当たり前のことなのですが、実物の報告が5枚たまるまで、 自分は理想的な字を前提にコードを書いていました。

• 同棲・夫婦の生活費、4つの分け方と、続かなくなる理由 完全折半・収入比・費目別・共通口座。方式を選ぶ手前で落ちているものの話。
• 1円のズレは、誰が負担するのか 3対7で割ると、必ず1円未満の端数が出ます。1000回のシミュレーションで200円ずれた実測と、その直し方。