経費精算の領収書入力を、クラウドのOCR（光学文字認識）サービスに投げずに自前で処理したい。そう考えるフリーランスや小規模開発チームは一定数います。
今回はOllama（ローカル環境でLLMを動かすためのランタイム）とオープンウェイトの視覚言語モデルを使い、領収書を自動で読み取る「ReceiptPilot」というOSSプロジェクトを題材にします。クラウドAPIを使うか、ローカルLLMを自前運用するか、あるいは既存のSaaSに任せるか。この判断で悩んでいるエンジニアの参考になれば幸いです。
どんな場面でこの選定が必要になるか
月に20〜200件程度の領収書を手入力している個人事業主や2人規模の事業者は、スプレッドシートへの手打ち作業に時間を取られがちです。店名、日付、通貨、小計、税額、合計を1件ずつ転記する作業は、件数が増えるほど負担になります。
ここで選択肢になるのが、クラウドOCR・クラウドLLM API・ローカルLLMの3方向です。特に財務書類という性質上、外部のクラウドサービスに画像をアップロードすることへの抵抗感を持つ利用者は少なくありません。ReceiptPilotはこの層を狙い、Gemma 3 4BというオープンウェイトモデルをOllama経由でローカル実行する設計を採っています。
判断軸1: データの機微性と送信先
領収書には取引先名、金額、場合によっては個人の行動履歴が写り込みます。これをサードパーティのクラウドに送信してよいかどうかは、業種や契約によって温度差があります。
クラウドAPI（Google Document AIやAWS Textractなど）を使う場合、画像は外部サーバーに送信され処理されます。一方ローカルLLM方式では、画像は手元のマシン内で完結し、外部には一切送信されません。ReceiptPilotはDockerコンテナとOllamaをローカルで起動し、ネットワーク越しの送信を発生させない構成です。
顧客との守秘義務契約がある士業や、会計事務所が複数のフリーランス案件を扱う場合は、この軸が決定打になりやすい判断軸です。
判断軸2: 処理精度と速度のトレードオフ
ReceiptPilotの開発過程では、gemma3:4bとqwen2.5vl:7b(Apache 2.0ライセンス)の2モデルが比較されています。40件の合成データによる評価では、Qwenのほうがやや精度が高く、Gemmaのほうが高速で省リソースという結果でした。
測定された処理時間の中央値は、1文書あたりGemmaが4.6秒、Qwenが6.4秒です。これはNVIDIA RTX 4060(VRAM 8GB)を搭載したノートPC上での数値であり、すべての環境で同じ性能が出るわけではありません。
手持ちのGPUがVRAM 8GB未満の場合、4Bモデルでも動作が重くなる可能性があります。導入前にnvidia-smiでVRAM容量を確認し、Ollamaの対応モデル一覧から現実的なサイズを選ぶのが安全です。
判断軸3: 検証ロジックをコードに持たせるか、プロンプトに任せるか
ReceiptPilotの設計で注目したいのは、金額の算術チェックをプロンプト(LLMへの指示文)ではなくコードで行っている点です。小計と税額を足した値と合計を、通常のプログラムロジックで突き合わせています。
金額は1.234,56や1,234.56のような異なる表記を厳密な10進数としてパースし、曖昧な日付や通貨記号抜きの金額はLLMに推測させず、人間に確認を求める仕様です。これはLLMの「もっともらしい出力」が時に誤りを含むハルシネーション(事実と異なる内容を自信ありげに生成する現象)への対策として理にかなっています。
自前でAI駆動の業務ツールを作る際、この「LLMに判断させる範囲」と「コードで検証する範囲」の線引きは、精度担保の観点で重要な設計判断になります。すべてをプロンプトエンジニアリングで解決しようとすると、エッジケースで再現性のないミスが発生しやすくなります。
判断軸4: 運用の手間と保守コスト
クラウドSaaSを使えば、モデルの更新やインフラの保守はベンダー任せにできます。一方でOllama+ローカルモデルの構成は、自分でDocker環境を立ち上げ、モデルファイルを管理し続ける必要があります。
ReceiptPilotはNext.js 16のフロントエンドとFastAPI(Pythonの軽量Web APIフレームワーク)のバックエンド、SQLiteまたはPostgreSQLのデータストアで構成されています。バックエンド・フロントエンドのテストに加え、Playwrightによるエンドツーエンドテストも用意されています。
この構成を自分で保守し続けられるか、あるいはOSSとして公開されている既存実装をそのまま使うかも、重要な判断材料です。
| 選択肢 | データ送信 | 精度 | 運用の手間 |
|---|---|---|---|
| クラウドOCR/API | 外部送信あり | 安定して高い | 低い(ベンダー任せ) |
| ローカルLLM(Ollama) | 送信なし | GPU依存で変動 | 高い(自前保守) |
| 手入力の継続 | 該当なし | 人間依存 | 作業時間が増える |
ケース別の推奨
月20件未満で機微性の低い領収書しか扱わないなら、クラウドOCR APIをそのまま使う方が開発工数に見合います。わざわざGPU環境を用意する価値は薄いです。
月50件以上を扱い、かつ顧客データの外部送信を避けたい契約条件があるなら、ReceiptPilotのようなローカルLLM構成を検討する価値があります。手元にVRAM 8GB以上のGPUがあることが前提条件です。
会計事務所など複数クライアントへ横展開したいなら、Dockerでパッケージ化されたローカル構成は配布がしやすく、マネージド導入の運用モデルとしても現実的です。
あえて見送るべき条件
GPUを搭載しないマシンしかない場合、CPU推論は速度面で実用に耐えないことが多く、無理に導入するとかえって作業時間が増えます。クラウドAPIへの切り替えを検討すべきです。
月間の処理件数が数件程度なら、環境構築の手間がリターンを上回ります。手入力を続けるか、軽量なクラウドOCRの無料枠で十分なケースです。
社内に継続的にDocker環境やモデルバージョンを保守できる担当者がいない場合も、ローカルLLM運用は長期的に負債化しやすいため見送る判断が妥当です。
導入前に確認すること
判断に迷ったら、まず手元のGPUのVRAM容量を確認し、ollama pull gemma3:4bでモデルを取得して実際の処理速度を試すのが近道です。
データの機微性、処理件数、保守体制の3点を自分の状況に当てはめれば、クラウドAPIかローカルLLMかの方向性は見えてきます。ReceiptPilotのソースコードはMITライセンスでGitHub上に公開されており、構成をそのまま参考にすることも可能です。
最終的には、金額の検証ロジックをコードとプロンプトのどちらに持たせるかという設計判断が、自作ツールの信頼性を左右する点として意識しておきたいところです。