クライアントの請求書や領収書をAIで自動仕訳したいものの、クラウドAPIにPDFを送るのは避けたい。そんな事情を抱えるフリーランスやスモールビジネスの開発者に向けて、ローカル実行型のAI構成で起きやすい落とし穴を整理します。
題材にするのは「LedgerLens」という個人開発のデスクトップアプリです。PDFや画像をドロップすると、Ollama（ローカルでLLMを動かすランタイム）上のGemma 3（Googleの軽量オープンモデル、4Bパラメータ版）が取引先名・日付・税額・明細を抽出し、SQLiteに履歴を残します。OpenAIやAWS Textractのようなクラウド型OCR・抽出サービスを一切使わない設計です。
何が起きるか：クラウド送信ゼロの引き換えに発生する制約
この種のローカルAI構成は、データが外に出ない安心感と引き換えに、いくつかの技術的な制約を抱えます。
一つ目はモデルサイズと精度のトレードオフです。Gemma 3の4B（40億パラメータ）版はノートPCでも動く軽さが売りですが、クラウドの大型モデルと比べると、フォーマットが崩れた請求書や手書き混じりの領収書での抽出精度は不安定になりやすい構成です。
二つ目はローカルOCR（文字認識）の限界です。LedgerLensはTesseract（オープンソースのOCRエンジン）を前段に使い、その出力をGemma 3のJSONスキーマ抽出に渡しています。Tesseractは言語やレイアウトへの依存が強く、インドのGST（物品サービス税）記載のような独自フォーマットでは、クラウド製品が「おもちゃ扱い」するという課題意識が開発動機そのものになっています。
三つ目はポート・ネットワーク設定の見落としです。フロントエンドはVite（高速なフロントエンドビルドツール）でlocalhost:5173、バックエンドはExpressで127.0.0.1:3001という構成です。ローカルループバック通信のみを前提にしているため、社内ネットワークやコンテナ環境にそのまま持ち込むと、ポート競合や到達性の問題が起きやすくなります。
なぜ起きるか：ローカルファースト設計が生む構造的な理由
これらの問題は偶然ではなく、設計思想そのものに起因します。
まずモデル選定の理由です。クラウドAPIならGPT-4クラスの大規模モデルを使えますが、ローカル実行では推論に使えるGPU・メモリが一般的なノートPC水準に制限されます。Gemma 3の4B版はその制約の中で現実的に動く選択肢であり、精度よりも「手元で動くこと」を優先したトレードオフです。
次にOCRとLLMの二段構成です。画像からテキストを取り出す処理（OCR）と、テキストから構造化データを取り出す処理（LLMによる抽出）を分離しているのは、クラウドのマルチモーダルモデルのように画像を直接読ませるコストが、ローカル実行では重すぎるためです。この分離設計が、OCR側の弱さをそのまま最終結果の精度に持ち越す構造を生んでいます。
さらにAPI境界の設計です。フロントエンドとバックエンドが別プロセス・別ポートで動く構成は、ReactベースのモダンなWebアプリでは一般的なパターンです。ただしローカル専用アプリの場合、この分離が「どのポートで何が待ち受けているか」を開発者自身が把握していないと、起動失敗の原因究明が難しくなる要因にもなります。
自分のプロジェクトが該当するか確認する方法
同様の構成（Ollama + ローカルLLM + OCR）を検討中、あるいはすでに組み込んでいる場合は、以下を確認してください。
- Ollamaのバージョンと導入済みモデルを確認する:
ollama listでpull済みモデルの一覧とサイズが表示されます - 対象モデルが要求するメモリ量を確認する:
ollama show gemma3:4bでパラメータ数・量子化方式が確認できます - バックエンドが想定ポートで待ち受けているか確認する:
curl http://127.0.0.1:3001/healthのようなヘルスチェックエンドポイントの有無をリポジトリのREADMEで確認します - OCR依存があるか確認する:
package.jsonやrequirements.txtにtesseract.js・pytesseractなどの記述がないか検索します
# Ollama側の状態確認の基本コマンド
ollama list
ollama show gemma3:4b
ollama psこれらのコマンドで、手元のマシンが要求スペックを満たしているか、どのモデルが実際にロードされているかを事前に把握できます。
対策の手順
精度とプライバシーのトレードオフを理解したうえで、実際に導入・評価する際の進め方を整理します。
1. 小規模モデルでの精度検証を最初に行う: 本番データに近いフォーマットの書類を5〜10件用意し、Gemma 3の4B版で抽出精度を目視確認します
2. OCR単体の出力を先に確認する: LLMに渡す前のOCRテキストを一度ログ出力し、文字化けやレイアウト崩れがないか確認します
3. JSONスキーマ抽出のバリデーションを入れる: LLMの出力が常に同じ構造のJSONになるとは限らないため、受け取り側でスキーマ検証を挟みます
4. 人間によるレビュー工程を省略しない: LedgerLensが採用している「抽出→人間が並べて確認→承認」というフローは、精度が完璧でない前提の設計として参考になります
5. ローカルストレージの保存先とバックアップ方針を決める: 同種の構成では %LOCALAPPDATA% や ~/.(アプリ名) 配下にSQLiteで履歴を持つ設計が一般的で、端末故障時のデータ消失リスクをどう扱うか事前に決めておきます
| 比較軸 | クラウドAPI型抽出 | ローカルLLM型抽出 |
|---|---|---|
| データ送信 | 外部サーバーに送信 | 端末内で完結 |
| 精度 | 大規模モデルで安定 | 端末性能に依存し不安定になりやすい |
| コスト構造 | 従量課金・月額課金 | 初期セットアップのみ |
| 運用負荷 | 低い（API呼ぶだけ） | モデル管理・OCR調整が必要 |
確認しておきたいポイント
ローカルLLMによる書類処理は、プライバシー要件が厳しい業務ほど魅力的に見えます。
ただし導入前には、使用するモデルのパラメータ数とバージョン、OCRエンジンの言語対応状況、保存先ディレクトリの設計を必ず確認してください。
ollama list と ollama show でモデルの実体を把握し、小規模な実データで精度検証を行ってから本番導入を判断する進め方が安全です。
人間によるレビュー工程を省略しない設計は、精度のばらつきを前提にした現実的な落としどころといえます。