当サイトは広告を設置しています

ローカルLLM で レシートOCR を運用しています

生成AI活用事例:ローカルLLM で レシートOCR を運用しています AI 活用事例

レシートを撮影して家計簿へ入力する。

一つひとつの作業は数十秒かもしれませんが、毎日続くと意外と面倒です。

そこで現在、僕は ローカルLLM と n8n を使い、レシートの読み取りからスプレッドシートへの記録までを自動化しています。

レシートを Google ドライブへアップロードすると、glm-ocr が文字認識を行います。

その結果を gpt-oss:20b が整理し、Google スプレッドシートへ自動で記録します。

2026年3月から運用を続けていますが、現在も日常的に利用している仕組みのひとつです。

この記事では、実際にどのような構成で運用しているのか、使ってみて感じたメリットや課題も含めて紹介します。

広告

レシートOCRを自動化したかった理由

ローカルLLM を触り始めた頃から、「日常のちょっとした作業を自動化できないか」ということをよく考えていました。

その中で目を付けたのがレシートです。

買い物をすると必ず発生する。

家計簿を付けようと思っても長続きしない。

入力自体は難しくないけれど、地味に面倒。

そんな作業です。

我が家では以前から家計簿サービスのレシート読み取り機能も利用していました。

撮影するだけである程度自動入力されるため便利ではあったのですが、

  • 将来的に有料化されるかもしれない
  • 広告が表示される
  • データを外部サービスへ預けることになる

といった点は少し気になっていました。

もちろん、それらが悪いという話ではありません。

ただ、ローカルLLM を触り始めた頃だったこともあり、「自分の環境だけで完結できないだろうか」と思うようになったのです。

さらに考えてみると、本当に面倒なのは入力作業そのものではなく、レシートを確認して家計簿へ反映するために使っている時間でした。

だったら、「レシートを撮影してアップロードするだけで記録できたら楽なのでは?」そう考えて、OCR による自動化に挑戦することにしました。

広告

現在の構成

現在は以下のような構成で運用しています。

  1. スマートフォンでレシートを撮影
  2. Google ドライブへアップロード
  3. n8n の定期実行でファイルを検知
  4. glm-ocr が文字認識
  5. gpt-oss:20b が必要な情報を整理
  6. Google スプレッドシートへ記録

OCR には Ollama 上で動作する glm-ocr を利用しています。

文字認識後は、gpt-oss:20b が OCR 結果を整理し、

  • 商品名
  • 数量
  • 単価
  • 金額
  • 店名
  • 登録番号

などの情報を抽出してスプレッドシートへ保存しています。

同じレシートを二重登録しないよう、Google ドライブのファイル ID も記録しています。

ローカルLLM + n8n レシートOCR ワークフロー
広告

実際の処理の流れ

日常的な運用はとてもシンプルです。

買い物が終わったら、スマートフォンでレシートを撮影します。

そのまま Google ドライブの指定フォルダへ保存するだけです。

あとは n8n が自動で処理を開始します。

文字認識結果はスプレッドシートへ記録され、家計簿データとして蓄積されていきます。

現在は割引や消費税の読み取りにも対応しています。

最初は単純な OCR だけでしたが、実際に運用しながら少しずつプロンプトを調整し、必要な情報を取り込めるよう改善してきました。

ローカルLLM + n8n レシートOCR ワークフロー 実際に Google ドライブにアップロードしたレシート
ローカルLLM + n8n レシートOCR ワークフロー 実際に スプレッドシートに書き込んだ例
広告

3ヶ月運用してみた結果

この仕組みは 2026年3月から運用を続けています。

途中でプロンプトの改善やワークフローの調整は行っていますが、現在まで大きなトラブルで処理が停止したことはありません。

もちろん OCR なので完璧ではありません。

読み取りミスもありますし、店名が少し違ったり、商品名が崩れることもあります。

それでも、「撮影してアップロードするだけ」という手軽さは非常に大きく、今では日常的に使う仕組みとして定着しています。

家計簿を付けるための心理的なハードルもかなり下がりました。

広告

家計簿としての運用方法

レシートを読み取って保存するだけでは、家計簿としては少し使いづらいと感じました。

そこで現在は、Google スプレッドシート側でもいくつか工夫をしています。

運用しているシートは以下の5つです。

  • 表示用
  • 月別支出
  • 分析
  • シート1
  • エラー

n8n が直接書き込むのは「シート1」です。

OCR の結果をそのまま蓄積する場所として使っており、日付、商品名、金額、単価、数量、店名などを保存しています。

そのデータを元に、他のシートでは QUERY 関数を使って見やすく整理しています。

表示用シート

表示用シートでは、登録されたデータを日付の新しい順に並べています。

レシートをアップロードした後に内容を確認したり、OCR の読み取り結果をチェックしたりするときに利用しています。

普段もっとも見ることが多いシートです。

ローカルLLM + n8n レシート読み取り スプレッドシートのクエリ文で読みやすく

月別支出シート

月別支出シートでは、登録されたデータを月ごとに集計しています。

例えば、

  • 2026年6月 7,732円
  • 2026年5月 39,264円
  • 2026年4月 39,754円

といった形で確認できます。

家計簿サービスのような細かな分析機能はありませんが、「今月はいくら使ったか」を確認するには十分です。

月単位の支出推移も見やすくなりました。

ローカルLLM + n8n レシート読み取り スプレッドシートのクエリ文で集計

分析シート

個人的に一番便利なのが分析シートです。

商品名を入力すると、過去の購入履歴を検索できます。

例えば「卵」と入力すると、

  • いつ購入したか
  • どの店で購入したか
  • いくらだったか

を一覧で確認できます。

最近値上がりしたのか。

どの店舗が安かったのか。

そんなことを簡単に振り返れるようになりました。

もともとは OCR の実験として始めた仕組みでしたが、使い続けているうちに「買い物の記録データベース」としても活用するようになっています。

ローカルLLM + n8n レシート読み取り スプレッドシートのクエリ文で分析

エラーシートも用意していますが、今のところ大きな問題は発生しておらず、ほとんど利用する機会はありません。

派手なシステムではありませんが、自分が確認したい情報だけを整理できるため、今では十分に家計簿として機能しています。

広告

OCR 精度はどれくらいか

現在の体感としては、文字認識の精度は8割程度です。

パソコンで印字された文字やレシートのような定型フォーマットは比較的高い精度で読み取れます。

一方で、

  • 店名の一部が崩れる
  • カタカナを誤認識する
  • レシートの印字状態によって結果が変わる

といったことは今でも発生します。

特に半角カナは苦手な印象があります。

実際に水道料金のお知らせを読み取った際には、氏名部分の半角カナが大きく崩れてしまうこともありました。

とはいえ、家計簿として利用する上では大きな問題にはなっていません。

商品名が多少違っていても、「何を買ったのか」は十分に判断できます。

金額や数量も概ね正しく取得できているため、日常利用では許容範囲だと感じています。

参考:glm-ocr の画像認識精度
参考:glm-ocr の画像認識精度

また、今回は glm-ocr を利用していますが、将来的には OCR 専用モデルにこだわらず、画像解析に対応したマルチモーダルモデルへ切り替えることも検討しています。

現時点ではまだ試せていませんが、画像全体の内容を理解しながら構造化データへ変換できるモデルであれば、認識精度がさらに向上する可能性もありそうです。

このあたりは今後の改善ポイントとして、引き続き実験していきたいと思います。

広告

AI に全部任せない運用

この仕組みを運用していて感じるのは、AI にすべてを任せる必要はないということです。

AI 関連の話題では、「完全自動化」が注目されることも多いですが、実際に運用してみると必ずしもそこを目指す必要はありません。

僕の場合、

  • レシートを撮影する
  • AI が自動で記録する
  • スプレッドシートで確認する

という流れにしています。

もし読み取りミスがあれば、その場(シート1)で修正すれば終わりです。

修正にかかる時間は数秒〜数分程度。

最初からすべて手入力することを考えると、圧倒的に楽です。

100%の精度を求めて延々と調整を続けるより、80%でも実用になる仕組みを作る。

その方が結果的に活用できるケースは多いように感じています。

広告

水道料金 OCR への応用

レシートOCR を運用しているうちに、「同じ仕組みで他の書類も読めるのでは?」と思うようになりました。

そこで試したのが、水道料金の検針票です。

基本的な流れはレシート OCR とほぼ同じです。

  • Google ドライブへアップロード
  • glm-ocr で文字認識
  • 必要な情報を抽出
  • スプレッドシートへ保存

という流れで処理しています。

抽出対象としては、

  • 検針日
  • 使用水量
  • 水道料金
  • 下水道使用料
  • 請求見込額

などを設定しました。

こちらも概ね期待通りに動作しています。

レシートOCR で作った仕組みを流用できたため、新しく構築する手間もそれほどかかりませんでした。

一度ワークフローを作ってしまうと、別の帳票や書類にも応用しやすい。

これは ローカルLLM と OCR を組み合わせる大きなメリットのひとつだと思います。

ローカルLLM + n8n 水道料金 ワークフロー 実際に スプレッドシートに書き込んだ例
広告

まとめ

このレシートOCR の仕組みは、現在も継続して運用している AI 活用事例のひとつです。

最初は「ローカルLLM で何か面白いことができないだろうか」という興味から始めた実験でした。

しかし実際に作ってみると、単なる OCR の検証ではなく、日常的に使える家計簿の仕組みになりました。

もちろん完璧ではありません。

OCR の読み取りミスもありますし、商品名が崩れることもあります。

それでも、

  • レシートを撮影する
  • Google ドライブへアップロードする
  • 自動で記録される

という流れができただけで、家計簿を付ける負担はかなり減りました。

また運用を続ける中で感じたのは、「AI に全部任せる必要はない」ということです。

80%程度の精度でも、最後に人が確認する前提であれば十分実用になります。

100%を目指して調整を続けるより、まず使える仕組みを作って運用してみる方が、自分には合っていました。

現在はレシートだけでなく、水道料金の検針票などにも応用しています。

一度ワークフローを作ってしまうと、他の帳票や書類にも展開しやすくなるのは、ローカルLLM と OCR を組み合わせる面白さのひとつです。

ローカルLLM は万能ではありません。

それでも、日常の少し面倒な作業を肩代わりしてくれる存在にはなっています。

今後も実際に運用している仕組みや、生活や仕事の中で役立った活用事例を、この実験室に記録していこうと思います。

これは現在も運用中の AI活用事例です。

タイトルとURLをコピーしました