ローカルLLMでOCR。機密書類を外に出さずPDF・帳票をテキスト化する現実解

請求書・契約書・診療記録・図面つき帳票。こうした機密書類こそテキスト化して活用したいのに、外部のクラウドOCRには出しにくい——この矛盾を解く選択肢が、ローカルで動くOCRモデルです。2025年後半から1B前後の文書読み取り特化モデルが急増し、GPU1枚どころかVRAM 8GB級でも実用になってきました。ただし結論から言うと、日本語の縦書きや複雑な帳票では万能ではなく、モデル選びとパイプライン設計、そして「読めない文字を捏造する」幻覚への対策が成否を分けます。本記事では2026年8月時点の現実解を整理します。

この記事の要点

2025年後半以降、DeepSeek-OCR・PaddleOCR-VL・olmOCRなど0.9B〜7B級のOCR特化モデルが急増し、VRAM 8〜12GBのローカル環境で文書のテキスト化が現実的になりました

日本語の実測比較では、印刷された請求書・見積書クラスは高精度になった一方、縦書きや複雑な表ではVLM系が苦戦し、日本語特化エンジンや従来型OCRとの併用が現実解です

最大のリスクは誤読ではなく「幻覚」です。VLMは読めない文字を「読めなかった」と言わず、もっともらしい数値や文字列を生成します。金額・数量を扱う帳票では検証工程が必須です

商用利用ではライセンスの確認が必須です。MIT／Apache 2.0系（DeepSeek-OCR、PaddleOCR-VL、olmOCR等）と、研究用・条件付きライセンスのモデルが混在しています

なぜ今「ローカルOCR」なのか

従来のOCR（文字認識）とLLM系のOCRは、できることが一段違います。従来型が「文字の位置と文字列」を返すのに対し、視覚言語モデル（VLM）ベースのOCRは、レイアウトを理解した上で見出し・段落・表の構造を保ったMarkdownやJSONを直接出力します。社内文書RAGの前処理として、そのまま使える形式です。

そして2025年後半、この分野の特化モデルが一気に小型化しました。代表的なものを整理します。

モデル	サイズ	ライセンス	特徴
DeepSeek-OCR	3B（MoE）	MIT	文書を視覚的に圧縮する設計。A100 1枚で20万ページ/日以上の処理をうたう
PaddleOCR-VL	0.9B	Apache 2.0	109言語対応で日本語を明示サポート。文書解析ベンチOmniDocBenchで上位常連
olmOCR 2	7B	Apache 2.0	PDF→Markdownツールチェーン込み。英語文書に最適化
dots.ocr	約3B	MIT	100言語対応の多言語型
Granite-Docling	258M	Apache 2.0	超軽量でCPUでも動く。ただし日本語は「実験的」対応
Qwen3-VL	2B〜235B	Apache 2.0	汎用VLM。OCR対応32言語で、読み取り以外の指示（要約・抽出）も同時にできる

商用利用の観点では、この表のモデルはいずれもMITまたはApache 2.0です。一方で、Qwen2.5-VL-3B派生のモデル（Nanonets-OCR2等）には研究用ライセンスのものがあり、また後述の日本語特化YomiTokuは非商用ライセンス（商用は別途契約）です。「OCRモデル」と一括りにせず、1つずつライセンスを確認してください。

日本語文書での実力（実測データ）

英語・中国語中心のベンチマークスコアは急伸していますが、日本語ではどうか。公開されている実測から見えている線を整理します。

日本語の見積書などを使った7モデルの文字レベルF1比較（2026年3月）では、OCR特化の小型モデルが0.9台後半に到達し、従来型のTesseract（0.74）を大きく引き離しました。一方、汎用VLMのQwen2.5-VL-7Bは0.79と、特化モデルに及びませんでした
2025年10月の日本語文書比較では、単純なレイアウトはどのモデルでも読める一方、複雑な表はVLMの入力解像度の制限で崩れやすく、縦書きは日本語特化エンジン（YomiToku）が圧倒的に優位という結果でした

ここから導ける実務の結論は次のとおりです。

印刷された横書きのビジネス文書（請求書・見積書・報告書）: OCR特化のローカルモデルで実用ライン
複雑な表・罫線の多い帳票: レイアウト検出と認識を分ける2段構成（PaddleOCR-VL型）か、従来型OCRとの併用
縦書き・手書き: 日本語特化エンジンの領域。YomiTokuは強力ですが非商用ライセンスのため、業務利用は商用契約かパイプライン設計での回避を検討

「1つの最強モデル」は2026年8月時点では存在しません。文書タイプごとの使い分けが現実解です。

必要なマシンスペック

OCR特化モデルは軽量です。目安を挙げます（量子化・条件で前後します）。

モデルクラス	必要メモリの目安	動く環境の例
0.9B級（PaddleOCR-VL等）	数GB	VRAM 8GBのGPU、メモリ16GBのMac
3B級（DeepSeek-OCR、dots.ocr）	8GB前後	VRAM 12GBのGPU
7B級（olmOCR 2、Qwen3-VL 8B）	Q4量子化で6〜10GB	VRAM 12〜16GBのGPU、メモリ32GBのMac

olmOCRのツールキットは公式にNVIDIA GPU 12GB以上を要件としています。手元のマシンで動くかどうかはローカルLLM必要メモリ診断で確認できます（VLMは画像処理分が上乗せされるため、余裕を見てください）。

PDF→Markdown→RAGのパイプライン

実務では「モデル単体」ではなく「変換パイプライン」で考えます。定番の構成は次のとおりです。

PDF・スキャン画像
    ↓ ページ分割・前処理
OCR/文書解析（olmOCR、MinerU、marker、PaddleOCR-VL など）
    ↓ 見出し階層・表・読み順を保持したMarkdown/JSON
チャンク分割 → 埋め込み → 検索（RAG）

ツールの使い分けの目安は、書籍・論文のような整った文書はmarker、日本語を含む自由形式の文書はMinerU（CJKレイアウト検出に定評）、精度最重視ならVLM系という整理が2026年時点の相場です。RAG側の設計は『社内文書RAGの作り方2026』で詳しく解説しています。RAGの精度はLLM本体よりこの前処理で決まるため、OCRの品質はそのまま検索の品質になります。

最大の落とし穴: VLMは「読めない」と言わずに捏造する

ローカルOCR導入で最も重要な注意点です。VLM系OCRの失敗は「文字化け」ではなく、もっともらしい嘘として現れます。

かすれた金額「¥138,500」を、自信満々に「¥135,800」と出力する（幻覚）
空白の多いページで同じ文字列を無限に繰り返す（繰り返しループ。モデルカード自身が注意書きしているモデルもあります）
表の行と列の対応がずれたまま、整ったMarkdownとして出力される

従来型OCRなら「認識率が低い文字」として検出できた失敗が、VLMでは検出しにくい形になります。金額・数量・日付を扱う帳票処理では、次の対策を最初から設計に入れてください。

数値の二重チェック: 従来型OCRやルール（合計値の検算、桁数チェック）とのクロスチェック
出力の暴走対策: トークン上限とタイムアウトの設定、繰り返しパターンの検知
人間の確認工程: 確信度の低い項目だけ人がレビューするワークフロー（全件目視に戻さないことが重要です）
元画像への遡及: 抽出値と元ページの対応を保存し、あとから検証できるようにする

「OCRの精度が99%」でも、残り1%が静かに混入する設計では帳票業務に使えません。検証できる仕組みごと導入するのがローカルOCRの正しい形です。

導入前チェックリスト

対象文書のタイプを棚卸しした（横書き印刷／複雑な表／縦書き／手書きで難易度が大きく変わります）
候補モデルのライセンスを確認した（MIT／Apache系か、研究用・非商用か）
数値・金額の検証工程を設計に入れた（幻覚は「読めなかった」と言ってくれません）
必要メモリを確認した（必要メモリ診断。VLMは画像分の余裕も見る）
RAGへつなぐ場合、見出し・表構造を保持できる出力形式（Markdown/JSON）を選んだ
秘密文書を扱う根拠（なぜローカルか）を整理した（守秘義務・営業秘密の観点は士業向け・製造業向けの記事で整理しています）

まとめ

機密書類を外に出さずにテキスト化する環境は、2025年後半のOCR特化モデル急増で「作れる」段階に入りました。VRAM 8〜12GBで動く選択肢が複数あり、印刷された日本語ビジネス文書なら実用水準です。一方で、縦書き・複雑帳票の限界と、数値を捏造する幻覚のリスクは残っており、モデル選定より検証工程を含むパイプライン設計が導入の本体です。

TodoONadaでは、文書のテキスト化からRAG構築、運用設計までを一貫して支援しています。「この帳票、外に出さずに処理できるか」という段階のご相談もどうぞ。