【ITニュース解説】The invoice on the counter: a local-first cost reader for small restaurants

Notinhaは、ブラジルの小規模レストランが直面する、仕入れ伝票の処理と原価計算の課題を解決するために開発されたツールである。このツールは、スマートフォンのカメラで撮影した仕入れ伝票の写真を基に、その内容を読み取り、レストランで利用できる形式の原価計算スプレッドシートデータに変換する。

多くのレストラン、特にブラジルの小規模店では、仕入れ業者から受け取る紙の伝票に記載された情報を、毎週、あるいは毎日、手作業でスプレッドシートに入力する作業が発生している。この作業は閉店後の深夜に行われることも多く、レストランオーナーにとって大きな負担となっている。さらに、伝票に書かれている商品の単位と、実際に厨房で使われる単位が異なるため、手作業で単位変換と単価計算を行う必要がある。例えば、「12リットル入りのジュースのケースが89.90レアル」と書かれていても、厨房で必要なのは「1リットルあたりの単価7.49レアル」である。このような単位換算を、疲れた頭で手計算で行うため、ミスが発生しやすく、正確な原価を把握することが困難になり、結果として、提供する料理の利益率を正確に評価できないという問題があった。

Notinhaは、これらの課題に対し、二つの主要な機能で応える。一つ目は、伝票の写真を解析し、品目、数量、単価、合計金額といった表形式のデータを正確に読み取ること。二つ目は、読み取ったデータの中で、ケース単位や梱包単位で記載された商品を、厨房で消費される最小単位（リットル、キログラム、ロールなど）に自動で変換し、その単位あたりのコスト（原価）を計算することである。これにより、オーナーは手作業での入力や複雑な計算から解放され、すぐに正確な原価情報を得られるようになる。最終的には、これらの情報がCSVファイルとして出力され、既存の会計システムやスプレッドシートへのインポートが容易になる仕組みだ。

このツールの特徴として、「ローカルファースト」の設計思想がある。Notinhaは、インターネットを介して外部のサーバーにデータをアップロードしたり、APIキーを必要としたりすることなく、レストランオーナー自身のラップトップ上で完結して動作する。これを実現するために、オープンソースのAIモデルであるGemma 3が、同じくオープンソースの推論エンジンであるOllamaを通じて利用されている。この設計により、伝票一枚あたりの利用コストはゼロとなり、機密性の高い仕入れ情報を外部に送信する必要がないため、データプライバシーに関するオーナーの懸念を解消できる。また、コマンドライン操作に不慣れなユーザーのために、ドラッグ＆ドロップで伝票を読み込める簡単なウェブインターフェースも提供されている。

Notinhaの開発には、いくつかの技術的な工夫が凝らされている。AIモデルからの出力形式を厳密に制御するため、OllamaのJSON Schema機能が活用されている。これにより、モデルは開発者が定義した特定の構造を持つJSONデータのみを出力するように制約され、その後のデータ処理が安定し、効率的に行える。また、ブラジルの数値表記では、小数点と千の位の区切りが日本とは逆（例: 1.234,56）であるため、AIモデルに直接数値を解釈させると誤った結果を招く可能性がある。そこで、モデルには数値を「文字列」として読み取らせ、その後にPythonのコードで、ブラジル式の表記を正しく数値に変換する処理を実装している。これは、AIモデルには読み取りに徹してもらい、正確な計算はプログラムが行うという明確な役割分担を示している。

AIモデルは非常に強力だが、特に照明条件が悪かったり、傾いたりした写真から文字を読み取る際には、数字を誤認識する可能性が常に存在する。Notinhaでは、このモデルの限界を補うために、伝票の「数量 × 単価 = 合計金額」という基本的な数学的制約を利用した「検証レイヤー」を導入している。モデルが読み取ったこれらの三つの数値が、この等式を満たさない場合、その品目には「警告」が表示される仕組みだ。例えば、チーズの項目でモデルが数量と単価を誤って読み取った際にも、「⚠ 数量 x 単価 = 25.00, 伝票では486.25」のように具体的に誤りを指摘し、オーナーに確認を促す。

この検証レイヤーこそが、Notinhaを実用的なツールにしている最も重要な部分である。95%の精度で正しい情報を提供するだけでなく、残りの5%の誤りを明確に指摘してくれることで、ツール全体の信頼性が飛躍的に向上する。お金に関わる情報において、95%は正しいが5%の誤りを指摘しないツールは実用性に欠けるが、95%が正しく、残りの5%の誤りを明示してくれるツールは、オーナーがごく一部の項目だけを確認・修正すればよいため、作業時間の劇的な短縮につながる。読み取りミスがあった場合でも、その項目はCSV上で空欄となり、警告内容が記述されるため、会計システムへのインポートが拒否され、手動での確認を促す設計となっている。

さらに、ブラジルの卸売業者が使う「FD（打包）」「PÇ（個）」といった独自の略語への対応も重要である。これらの業界固有の用語は汎用的なAIモデルでは正確に認識しにくいため、Notinhaには約20行の専用辞書が組み込まれており、新しい略語が出現した際には、開発者が迅速に辞書を更新できる柔軟な体制がとられている。

Notinhaがオープンイノベーションとローカルファーストの原則を重視するのには、四つの大きな理由がある。第一に、請求書は機密性の高い税務書類であり、外部へのデータアップロードを避けるローカル処理は、レストランオーナーにとってデータプライバシー保護の観点から最も安心できる選択肢である。第二に、伝票ごとの利用コストがゼロである点だ。月間数十枚の伝票を処理する小規模レストランにとって、従量課金制のAPIサービスはコストがかさむ可能性があるが、ローカル実行であれば定額制の料金設定が可能となり、受け入れやすい。第三に、Notinhaは電波状況が不安定な倉庫などのバックヤードでもオフラインで動作するため、食材の搬入作業中に伝票処理を完結できるという現場での利便性が高い。第四に、前述の略語辞書のように、特定の市場や業界に特化した細かいカスタマイズが容易であり、汎用的な大手APIサービスでは対応が難しいニッチなニーズにも迅速に対応できる。

オープンソースの4BモデルをGPUなしのCPUで実行するため、現状では伝票一枚の読み取りに約1分40秒を要する。これは高速なクラウドAPIと比較すると遅いが、一度の納品につき一度実行するだけであれば、実用上問題ない速度である。また、モデルの精度が完璧ではないため、検証レイヤーという追加のエンジニアリングが必要となったが、このトレードオフは、データプライバシー、コスト、オフライン対応、カスタマイズ性といったローカルファーストのメリットを考慮すれば、十分に価値があるものと判断されている。この検証レイヤーこそが、Notinhaの実用性を担保する上で最も重要な部分であり、開発の大部分を占めているという。

Notinhaはまだ実際のレストランオーナーに提供されておらず、現在は意図的に品質を落とした合成データでのテストが中心である。今後は、実際にレストランで発生する、しわくちゃになった伝票を使ってのテストが計画されている。さらに、将来的には、電子請求書（NF-e XML）からのデータ読み取りへの対応や、複数月のデータから商品の価格変動を追跡し、「この商品の価格が先月から9%上昇した」といった分析情報を提供する機能も追加される予定だ。これらの機能は、レストランオーナーが本当に知りたい「なぜ原価が変動したのか」という問いに答えるための、重要なステップとなるだろう。