レシートをローカルLLMでマネーフォワードCSVまで作る前に知っておきたい4つの失敗

はじめに

レシート画像をローカルLLMで読み取り、マネーフォワード（会計ソフト）のインポート用CSVまで自動生成するシステムを構築しました。

この記事では、Phase 1（OCR + テキストLLM方式）で実際にハマった4つの失敗を紹介します。同じことを試そうとしている方の参考になれば幸いです。

この記事で伝えること

• レシート画像 → ローカルLLM（OCR + テキストLLM）→ マネーフォワードCSV を試した結果の教訓
• 同じことをやる人向けの「やっておくべきこと／避けるべきこと」
• 技術選定の判断基準

アンチパターン①: OCRの誤認識をLLMのプロンプトでカバーしようとする

現象

PaddleOCRでレシートを読み取った際、以下のような誤認識が発生しました：

これらの誤認識テキストをそのままLLMに渡した結果：

{
  "store_name": "FamilyMart",
  "date": "2024-01-05",
  "time": "09:38",
  "items": [{"name": "青NO", "price": "999"}],
  "total": "4497",  // 実際は108円
  "tax": "5248",    // 実際は8円
  "payment_method": "クレジット"
}

実際の金額は108円（税込）だったのに、4,497円と認識されてしまいました。

なぜ失敗したか

1. プロンプトで誤認識を修正しようとした

   • 「半は¥の誤認識の可能性がある」とプロンプトに書いた
   • しかし、LLMは文脈から推測するしかなく、確実な修正はできない

2. 2段階処理で誤差が累積

   画像 → OCR → テキスト → LLM → JSON
          ❌誤認識      ❌誤解釈
   

   • OCRの誤認識がLLMの誤解釈を引き起こす
   • レイアウト情報（どこに何が書かれているか）が失われる

推奨: 入力品質を先に固める

• OCR精度を上げる: 画像の前処理（コントラスト調整、ノイズ除去）を実施
• OCRをスキップする: Vision LLMで画像から直接構造化データを抽出（Phase 2で採用）
• 確実な修正ルール: LLMに期待せず、プログラムで確実に修正する

# 推奨: OCR誤字の確実な修正（プロンプトに頼らない）
def correct_ocr_errors(text):
    """OCR誤字を確実に修正"""
    corrections = {
        '半': '¥',
        'ギ': '¥',
        '米': '¥',
    }
    for wrong, correct in corrections.items():
        text = text.replace(wrong, correct)
    return text

アンチパターン②: 「表示サイズ3GB」＝「8GB PCで動く」と思い込む

現象

Vision LLMモデルを選定する際、以下のような誤解をしていました：

「3GBのモデルだから8GB PCで動く」と思い込んでいましたが、実際には実行時メモリが8GBを超えてエラーになりました。

エラーメッセージ例

RuntimeError: CUDA out of memory. Tried to allocate 2.5GB (GPU 0; 4.0GB total capacity; 1.2GB already allocated; 2.8GB free; 4.0GB reserved in total by PyTorch)

なぜ失敗したか

1. 表示サイズ ≠ 実行時メモリ

   • モデルファイルのサイズと、実際にメモリに展開されるサイズは異なる
   • 推論時の一時メモリも必要

2. 量子化の重要性を理解していなかった

   • llama3.2-vision:11b（Q4_K_M量子化）なら8GB RAMで動作
   • 量子化により、モデルサイズを約1/4に圧縮できる

推奨: 量子化と実機検証を必ず実施

• 量子化モデルを使用: Q4_K_M、Q8_0などの量子化版を選ぶ
• 実機で検証: 実際のPC環境でメモリ使用量を確認する
• 余裕を持った選定: 表示サイズの2-3倍のメモリが必要と考える

# 推奨: 量子化モデルを使用
ollama pull llama3.2-vision:11b-q4_k_m  # 量子化版

アンチパターン③: 細長いレシートをそのままVision LLMに渡す

現象

コンビニの細長いレシート（アスペクト比が大きい）を処理した際、以下の問題が発生しました：

アスペクト比が3以上の細長いレシートで、JSONエラーまたは長時間のハングが発生しました。

エラーメッセージ例

Error: JSON parsing failed. Model output was not valid JSON.

または、処理が5分以上かかり、最終的にタイムアウト。

なぜ失敗したか

1. Vision LLMは「普通の写真」用に学習されている

   • レシートのような細長い画像は想定外
   • アスペクト比が極端だと、モデルが混乱する

2. 前処理をしていなかった

   • 画像をそのままモデルに渡していた
   • パディングやリサイズなどの前処理が必要

推奨: 前処理で比率を抑える

• アスペクト比の調整: 3:4や4:3などの標準比率にパディング
• 画像の分割: 細長いレシートは上下に分割して処理
• ドメイン特化のファインチューニング: レシート専用モデルを作る（Phase 3で予定）

# 推奨: アスペクト比の調整
from PIL import Image

def adjust_aspect_ratio(image_path, target_ratio=0.75):
    """アスペクト比を調整（パディング追加）"""
    img = Image.open(image_path)
    width, height = img.size
    current_ratio = height / width
    
    if current_ratio > target_ratio:
        # 高さが長すぎる場合、左右にパディング
        new_width = int(height / target_ratio)
        new_img = Image.new('RGB', (new_width, height), (255, 255, 255))
        new_img.paste(img, ((new_width - width) // 2, 0))
        return new_img
    return img

アンチパターン④: 「ローカル＝無料＝正義」で終わりにしない

現象

「全部ローカルで完結させたい」という理想を追い求めましたが、現実は以下の通りでした：

月100枚のレシートを処理するのに、ローカルでは8時間以上かかることが判明しました。

なぜ失敗したか

1. 処理時間を軽視していた

   • 「動けばいい」と思っていた
   • しかし、実務では「待てる時間」が重要

2. 無料APIの存在を無視していた

   • Google Vision APIは月1,000枚まで無料
   • 無料枠内で速度・精度が圧倒的に高い

3. 「ローカル必須」の要件を再確認していなかった

   • プライバシー要件が本当に必要か？
   • 無料枠で足りるなら、クラウドも選択肢に入れるべき

推奨: 要件で判断基準を決める

• ベースラインを数字で取る: 店舗名・日付・金額の正解率、1枚あたり時間を測定
• 要件を明確にする: 「ローカル必須か」「無料枠で足りるか」を要件で決める
• 表で比較する: コスト・速度・精度を表にして、判断材料にする

やるべきこと・判断の目安

1. ベースラインを数字で取る

測定すべき項目:

• 店舗名の正解率
• 日付の正解率
• 金額の正解率（最重要）
• 1枚あたりの処理時間

測定結果の例（Phase 1の結果）:

2. プロンプトとファインチューニングの役割を分けて考える

• プロンプト = 応急処置: 簡単な調整は可能だが、根本的な精度向上は難しい
• ファインチューニング = 根本治療: 実用的な精度を出すには、専用モデルの学習が必要

3. 「ローカル必須か」「無料枠で足りるか」を要件で決める

判断フローチャート:

プライバシー要件が厳しい？
├─ Yes → ローカル必須（Vision LLM + ファインチューニング）
└─ No → 無料枠で足りる？
    ├─ Yes → クラウドAPI（Google Vision API等）
    └─ No → ローカル + クラウドのハイブリッド

まとめ: 技術選定チェックリスト

レシートをローカルLLMで処理する前に、以下を確認してください：

ハードウェア要件

• メモリ: 8GB以上（量子化モデル使用時）
• GPU: 必須ではないが、あると処理速度が向上
• ストレージ: モデルファイル用に5-10GBの空き容量

処理要件

• 処理枚数: 月何枚を想定しているか
• 待てる時間: 1枚あたり何秒まで許容できるか
• 精度要件: 金額の正解率は何%必要か

プライバシー要件

• ローカル必須か: データを外部に送信できないか
• 無料枠で足りるか: 月1,000枚以下なら無料APIが使える

技術選定の選択肢

おわりに

Phase 1（OCR + テキストLLM方式）では、上記の4つの失敗を経験しました。

現在はGoogle Vision API（OCR） + Ollama（ローカルLLM）のハイブリッド構成に移行し、実用的な速度と精度を実現しています。

「全部ローカルで」という理想は素晴らしいですが、ユーザー体験を優先して技術選定することが重要だと学びました。

同じことを試そうとしている方の参考になれば幸いです。

参考リンク

• ReceiptAnalyzer（GitHub）
• PaddleOCR
• Ollama
• Google Cloud Vision API

次回予定: Phase 2（Vision LLM方式）の検証結果も記事にする予定です。