.
/ 2026/08/17 追記 STR
レシート読み込み自動化の検討
少し調べていくと、やはりレシートなどの読み込みに関しては、
汎用のマルチモーダルモデルよりも、
文字認識特化モデル「glm-ocr」 のほうがよさそうで、
「OCR (AI-OCR) 特化」のポイント
- 雑談やフワッとした質問には答えない（Prompt Limited）
- 「見落とし」や「嘘（ハルシネーション）」を極限まで減らしている
- 圧倒的に軽くて速い
端末のスペックは置いといて、試してみようとも思ってますが、
スマホ（Googleレンズ）での暫定運用案
並行してスマホ(googleレンズ)での文字起こしも試していたところ、
以下が思ったよりも快適で、識字間違いほぼなしでまわせたので、
ひとまずは運用してみようと思います
- スマホで、紙のレシートを撮影し、
- そのまま google レンズに共有して以下いずれかを指示：
「改行つきでコピーできるように文字起こしして」
「csv形式で改行つきでコピーできるように文字起こしして」 - 起こしたテキストを「共有」でメールに送信
( メールからスクリプト、ないしは直接スクリプトへ送信したら、
必要な箇所だけ整形して、スプレッドシートへ貼り付け、なんてこともできそうです )
/ 2026/08/17 追記 END
Local LLM がお手軽に試せる感じでしたので、
一般的な軽作業的ノートPCにメモリを増加して
Local LLM + レシート画像の読み込み、文字起こし
を試してみたのでメモです
各環境や処理状況によって結果は変わってくると思いますので、
「ふーん」くらいの感じで見てください
[ 00. メニュー ]
01. キッチン
02. 結論を先に
03. OCR なのか AI なのか
04. 仕込み
05. 調理1 (gemma4:e2b) / (gemma4:e4b)
06. 調理2 (qwen3-vl:30b)
07. デザート
[ 01. キッチン ]
・ intel core i5 1235U + 64GB ram
・ zorinos 18.1 core
・ よくあるコンビニやスーパーなどでもらう紙の縦長のレシート
・ $ ollama list
NAME SIZE
gemma4:e2b 7.2 GB
gemma4:e4b 9.6 GB
qwen3-vl:30b 19 GB
[ 02. 結論を先に ]
まずは結論を申しますと、
「動くけど、現実的ではない」
というところに落ち着きます
以下各モデルのテスト状況です
(各時間は、指示の開始から文字表示完了までの時間)
1. gemma4:e2b -> 01m 18s
-> 識字の間違いがひどい
2. gemma4:e4b -> 03m 13s
-> セクションごとの区分けがされたが、識字の間違いがひどい
3. qwen3-vl:30b (後述: qwen3-modal:latest) -> 18m 24s
-> 間違いはほぼなし、処理時間長がひどい
という状況で、スペック的に
(オンボードGPUでNPUなし、メモリを少し増やしただけ)
予測される結果(識字率、処理時間)でした
ちなみに、qwen3-vl:30b は、
テキストのみの場合でも、
(例：あなたの中での最新情報は何年何月分ですか？)
約 10 分後の回答と、長い処理時間でした
(最新情報は2023年10月までだそうです)
処理時間を無視した場合、
qwen3-vl:30b の識字はかなり秀逸でした
[ 03. OCR なのか AI なのか ]
今回の目的は、画像読み込み -> 文字起こし です
その指示として、あまり何も考えず、
「このレシートの画像から文字起こしをしてください」
というゆるい指示で試してみました
この場合、OCR としての処理になるのか、
AI としての処理なのか、ふと疑問に思いましたが、
gemma や qwen の画像認識対応モデルは、
「独立したAI-OCR機能」を内包しているわけではありませんので、
仕組みとしては「マルチモーダルな画像読み込み
(視覚表現によるテキスト変換) 」となります
======================================
「OCR」と「マルチモーダル」の画像読み込みの違い
A.OCR (AI-OCR) の画像読み込み
手法：画像内の文字の位置を検出して、
それぞれの文字をフォントパターンと照合して
テキストデータに変換する
特性：請求書や書類からの正確な文字起こし
【メリット】
・ハルシネーション (嘘) が起きない:
マルチモーダルは文脈から文字を「推測・生成」するため、
存在しない文字を捏造することがあります
一方、OCRは文字の形状をそのまま認識するため、
勝手な文章の創作が起きない
・非定型・脈絡のない文字列に強い:
型番、パスワード、ランダムな英数字、
意味を持たない記号の羅列など、
前後の「文脈」から推測できない文字列でも、
見たままを正確にテキスト化できる
・座標情報 (文字の位置) を取得できる:
どの文字が「画像のどこ (X座標・Y座標)
にあったか」をデータとして保持できるため、
請求書の「金額」や「日付」といった特定の
レイアウト位置から正確にデータを抽出する
業務自動化 (RPA) に最適
B.マルチモーダルの画像読み込み
手法：画像全体の「文脈・意味・状況」を総合的に理解する
特性：画像の解説、グラフの分析、矛盾の発見、デザインの評価
・ビジョンエンコーダーによる特徴量化:
入力された画像は、まず視覚を司る
ニューラルネットワーク (Vision Transformerなど)
によって、画像全体の意味や形状を示す
「特徴量 (ベクトルデータ) 」に変換される
・テキスト生成モデルによる言語化:
変換された画像の特徴量を、LLM (言語モデル部) が
直接読み込みます。モデルは「この画像の特徴の
並びからすると、次に来るべきテキスト (文字)
は何か」を確率的に予測し、文章として出力する
【メリット】
文脈の理解:かすれて見えにくい文字や、
手書きの癖が強い文字でも、前後の文章の流れ
(文脈) から「ここはおそらく〇〇という単語が入る」と
推測した(自動補正による)文字起こしをすることができる
======================================
[ 04. 仕込み ]
1. 取り込みのレシート画像
スマートフォンなどで撮影して
Local LLM を搭載する PC にあらかじめ転送しておきます
2. Local LLM 構築
テストを行う Local LLM モデルですが、
マルチモーダル的に画像読み込みに対応した以下のモデルにしました
1. gemma4:e2b 7.2 GB
2. gemma4:e4b 9.6 GB
3. qwen3-vl:30b 19 GB
構築に関しましてはみなさま色々と
記事にされてそうですので、ざっと記載します
※ 導入したいモデルごとに (容量も気にしつつ)
以下の、[B. モデルのダウンロードと起動] が必要です
※ linux (deb系) で使用した例です
==================================
A. ollama (Local LLM モデル管理ツール) のインストール
$ curl -fsSL https://ollama.com/install.sh | sh
==================================
B. モデルのダウンロードと起動 (例: gemma4:e4b)
$ ollama run gemma4:e4b
>>> send a message
が表示されれば成功です
-> ターミナル上でテキストのみで使うならこのままでも使用可能
日本の首都はどこですか？
などと入力すれば、
日本の首都は東京(とうきょう)です。
のように答えが返ってきます
======================================
[ ollama tips 1 ]
改行したい場合は Ctrl + Enter
(または Shift + Enter) を押します
======================================
[ ollama tips 2 ]
対話を終了して元の画面に戻りたいとき：
キーボードの Ctrl + D を押すか、
「/exit」と入力してEnterを押すと、ollama を終了できます
======================================
[ ollama tips 3 ]
再度、モデルを起動する場合、
ダウンロード時と同じ実行方法で、そのまま起動できます
$ ollama run gemma4:e4b
======================================
[ ollama tips 4 ]
現在 PC にダウンロードされているモデルの一覧を見たいとき：
$ ollama list
NAME ID SIZE MODIFIED
gemma4:e4b abcd12345678 9.6 GB 4 minutes ago
======================================
[ ollama tips 5 ]
LLM モデルの保存先を /home/ 側に変更する方法
標準では、
$ ollama run llama3.1:8b
などと実行した場合、LLM モデルは、システム側
/usr/share/ollama/.ollama/models/
に保存されますが、容量を圧迫してしまうので、
/home/ 側に DL されるようにします
設定手順
1. 新しい保存先フォルダを作成する
モデルを保存したい場所に新しいディレクトリを作成します
$ sudo mkdir -p /home/ollama_models
2. ディレクトリの所有権を変更する
ollama の標準インストールでは、ollama という
専用のシステムユーザーで実行されます
作成したディレクトリに ollama が書き込めるよう、
所有権を変更します
$ sudo chown -R ollama:ollama /home/ollama_models
3. ollama サービスの設定を編集する
$ sudo systemctl edit ollama.service
エディタが開いたら、
[Service]
の下に
Environment="ollama_MODELS=/home/ollama_models"
を追記して保存、なのですが、
ついでに、下方の「C-3c. モデル選択不可の場合」で
記載している no model available の対策として、
Environment="ollama_HOST=0.0.0.0"
Environment="ollama_ORIGINS=*"
も一緒に記述しておくとあとで楽です
[Service]
Environment="ollama_MODELS=/home/ollama_models"
Environment="ollama_HOST=0.0.0.0"
Environment="ollama_ORIGINS=*"
で、保存
-> Successfully installed edited file '/etc/systemd/system/ollama.service.d/override.conf'
確認：
$ cat /etc/systemd/system/ollama.service.d/override.conf
4. 設定を反映してサービスを再起動する
変更した設定をシステムに読み込ませ、ollama を再起動
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
-> 以降、新規 DL 分は、/home/ 側に保存される
5. 既存モデルの移行方法
すでに DL してしまっているモデルがある場合は、
手動で新しい場所に移動させることでそのまま使えます
$ sudo systemctl stop ollama
$ sudo mv /usr/share/ollama/.ollama/models/* /home/ollama_models/
$ sudo chown -R ollama:ollama /home/ollama_models/
$ sudo systemctl start ollama
$ ollama list
======================================
C. web上で使えるように「Open WebUI」を入れる
今回は、画像を読み込むので、ブラウザ(web)で
ChatGPTのように使える
「Open WebUI」をDocker等で導入します
C-1. Docker が入っていない場合は入れておきます
(※ 一例です)
$ sudo apt update && sudo apt install -y curl
$ sudo mkdir -p -m 755 /etc/apt/keyrings
$ curl -fsSL https://docker.com/linux/ubuntu/gpg | sudo gpg --dearmor --yes -o /etc/apt/keyrings/docker.gpg
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
C-2. Open WebUI のインストールと自動起動設定
$ sudo docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main
C-3. Open WebUI を web で実行
ブラウザ ( chrome や firefox など) を開き、
アドレスバーに以下を入力してアクセスします
http://localhost:3000
ブラウザ画面を開いた後の初期設定
C-3a. アカウント作成
最初にログイン画面が出ますが、これはローカル PC 内だけの管理用です
適当な名前、メールアドレス、パスワードを決めて
サインアップ (Sign Up) してください
name: onamae
email: watashi@ouchi.com
pass: tekitou
C-3b. モデル選択
C-3b1. 画面左上に[B. モデルのダウンロードと起動]
で DL した モデル(例：gemma4:e2b 等) が
リストに表示されるのでそれを選びます
(またはすでに選択されていればそのまま)
C-3c. モデル選択不可の場合
no model available (利用可能なモデルがありません)
と表示される原因は、Dockerコンテナ (Open WebUI) から、
OS 本体で動いている ollama (localhost) への
通信がブロックされている可能性が高いです
その場合は、以下の手順で、ollama 側の設定を変更して
通信を許可してあげると解決します
C-3c1. ollama の設定ファイルを編集する
以下のコマンドを実行して設定ファイルを開きます
$ sudo systemctl edit ollama.service
一番下の行に以下の3行をそのまま貼り付けてください
[Service]
Environment="ollama_HOST=0.0.0.0"
Environment="ollama_ORIGINS=*"
で、保存
C-3c2. ollama 再起動
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
C-3d. Open WebUIで確認する設定が完了したら、
ブラウザの Open WebUI 画面 (http://localhost:3000)
に戻り、ページを一度再読み込み (F5キー) してください
C-3e. 補足
「3. ollama サービスの設定を編集する」
の部分でも出てくる、
$ sudo systemctl edit ollama.service
の実行で、
/etc/systemd/system/ollama.service.d/override.conf
の新規ファイルが作成されます
(override.conf というファイルは、元の設定ファイル（ollama.service）を
書き換えるのではなく「指定した部分だけを上書き（追加）する」ためのファイル)
個人的には systemctl edit での編集は使いにくいので、
vi で修正しました
$ sudo vi /etc/systemd/system/ollama.service.d/override.conf
その場合は、事前に以下 mkdir が必要です
$ sudo mkdir -p /etc/systemd/system/ollama.service.d/
確認：
$ cat /etc/systemd/system/ollama.service.d/override.conf
[ 05. 調理1 (gemma4:e2b) / (gemma4:e4b) ]
Local LLM + Open WebUI 環境の構築後、
web上で + ボタン -> Upload Files にて
「転送しておいたレシート画像」
(例：スーパーのお買い物のレシート画像)を選択し、
「このレシートの画像から文字起こしをしてください」として実行
結果的に、以下の２つのモデルは
数値も2バイト文字も、間違いだらけでした
「gemma4:e4b」は少し向上している感じもしますが、
数値の間違いは問題が大きく、実用としては難しいです
======================================
「gemma4:e2b」
・登録番号 T4200001020808
-> T42000120808
・2026年07月14日(火)10:27 レジ0003
-> ○月14日(火)×10:27 料 ¥0003
・北海道牛乳 ¥198 -> 北海道税金 ¥198
(下方の税込、税合計などから推測されている形跡)
・小計：¥1,302 -> 文字起こしなし
・合計/ 9点 ¥1,406 -> ¥2062 (税込)
・(OK) 店No00122 -> 店No00122
など
======================================
「gemma4:e4b」
・店舗・日時情報（ヘッダー）
・購入品目リスト（アイテム）
・金額計算（トータルの部分）
・支払い情報・識別番号（フッター）
などの名目の区分けが記載された
(文字起こしとしては、その区分け行は不要)
・2026年07月14日(火)10:27 レジ0003
-> (OK) 2026年07月14日(火)10:27 レジ0003
・玉ねぎとおかかのサラダ ¥128
-> 玉ねぎとき あかかのサラダ ¥128
・(OK) 小計：¥1,302 -> 小計：¥1,302
・合計/ 9点 ¥1,406 -> (税込) 合計：¥5.46
・トランザクションID 071410283522914
-> トヨタクラウド：07141028352914
・(OK) 店No00122 -> 店No00122
など
======================================
[ 06. 調理2 (qwen3-vl:30b) ]
「gemma4:e2b」「gemma4:e4b」と同じように、
「qwen3-vl:30b」に切り替えて
同じように実行したところ、実行エラーになりました
qwen3-vl:30b
{"error":{"code":400,"message":"request (4270 tokens) exceeds the available context size (4096 tokens), try increasing it","type":"exceed_context_size_error","n_prompt_tokens":4270,"n_ctx":4096}}
このエラーは「送った画像と指示のデータ量が、
AIが一度に記憶できる制限 (コンテキストサイズ) を超えてしまった」というエラーで
ollamaのデフォルト設定ではこの制限が
「4,096トークン」に絞られているため、
画像1枚を投げただけで 4,270トークン に達してしまい、
制限オーバー (exceeds the available context size) で拒否されてしまいました
解消方法はいくつかあるようですが、ひとまず以下で解消しました
1. 設定ファイル（Modelfile）を作成する
$ echo -e "FROM qwen3-vl:30b\nPARAMETER num_ctx 16384" > Modelfile
2. 記憶容量を広げた新しいモデルを登録する
$ ollama create qwen3-modal -f ./Modelfile
（※ qwen3-modal としてますが、名前はなんでもよいです）
（※ 成功すると画面に success と表示されます）
3. Web画面を一度リロード（再読み込み）
http://localhost:3000
リロード（再読み込み）すると、モデルの選択肢に新しく
qwen3-modal:latest という名前のモデルが
追加されますので選択して使用
上記対応後、再実行しましたが、結論に記載のとおり、
「精度はかなりよいが、ものすごく処理時間がかかる」
でした
結果的に、1枚のレシートに18分かかるのは
問題が大きく、環境まわりなどを改善しないと、
今回の環境での実用は難しいです
======================================
「qwen3-vl:30b (qwen3-modal:latest)」
・1回目、2回目と同じ処理を実施しました
・処理時間はさほど変わらずです
1回目、以下以外はすべて画像通りの文字お起こし
・小計 (外8% タイショウ) ¥1,302
-> 小計 (外8% ダイシュオ) ¥1,302
2回目、以下以外はすべて画像通りの文字お起こし
・玉ねぎとおかかのサラダ ¥128
-> 玉ねぎとおかのかのサラダ ¥128
======================================
[ 07. デザート ]
結論としては、現状、運用するには、
「非力スペック環境では現実的ではない」
に尽きるのですが、
今後、環境は改善などするとして、
レシートの読み込みや、OCRなどは
ファクトチェック
(というか画像通りに文字起こしがされているか)
の確認は必要ですが、新たな学習は不要であり、
qwen3-vl:30b 同等レベルのモデルが快適に動けば
課金なしで、複数画像を一括で
バックグラウンド処理させっぱなしにして
DBに登録していくなどの仕組みを
考えていけそうな夢でした
まぁ快適に動く環境が実現できれば、ですが
最近の grok などのトークン節約志向にしても、
今後、必ずしもスペック増強一辺倒だけでは
なくなりつつあることを祈りつつ様子見です
.