はじめに：ローカルOCRの群雄割拠時代
近年、ローカルPCのGPU上で動作するAIモデルの性能が飛躍的に向上しています。中でも「画像からテキストを抽出する」OCR（Optical Character Recognition）技術は、書類の自動整理からマンガの翻訳まで幅広い用途で活躍します。
しかし、様々なOCRエンジンが存在する中で、「どれを選べばいいのかわからない」「環境構築でエラーが出て動かない」という声も多く聞かれます。そこで本記事では、2026年現在注目を集める4つのローカルOCRエンジン（Baidu/Unlimited-OCR、EasyOCR、PaddleOCR、manga-ocr）を同一環境で詳細に比較。初心者向けの基本解説から、導入時に遭遇しやすい「注意点」とその解決コードまで、詳しく解説します。
1. 比較する4つのOCRエンジン
- Baidu/Unlimited-OCR (3B): 32Kトークンの長文を一括処理できる最新のVision-Language Model (VLM)。
- EasyOCR: PyTorchベースの超軽量で導入が簡単な定番OCR。
- PaddleOCR (PP-OCRv6): 高精度な日本語認識を誇る標準的OCRエンジン。
- manga-ocr (ViT+GPT2): 日本のマンガ（縦書きや手書き風フォント）に特化したモデル。
2. 総合性能比較テスト結果
NVIDIA GeForce RTX 3080 Ti (12GB VRAM) を搭載したWindows環境において、日本語の活字・表組み・マンガ風画像の認識テストを実施しました。
| 評価項目 | Baidu/Unlimited-OCR | manga-ocr | EasyOCR | PaddleOCR |
|---|---|---|---|---|
| 処理時間 | 約 9.06 秒 | 0.21 秒 | 0.68 秒 | 測定不能(エラー) |
| ピークVRAM | 8.2 GB | 450 MB | 708 MB | 測定不能 |
| 日本語活字精度 | 極めて優秀 (誤字率0%) | 不可 (全体画像非対応) | 普通 (細かな誤認あり) | 測定不能 |
| 表組み再現 | 完璧 (Markdown出力) | 不可 | レイアウト崩壊 | 不可 |
| マンガ/縦書き | 部分的に可 (幻覚あり) | 極めて優秀 (※切抜前提) | 不可 | 可 |
3. 実機検証で判明した「導入時の注意点」と技術的解決策
ローカル環境の構築では、単純な pip install だけでは解決できない環境依存のトラブルが多数発生します。ここでは、各エンジンで直面した具体的な「注意点」と、その回避方法をコードレベルで解説します。
注意点1：PaddleOCRのWindows+CPU環境でのOneDNN未実装エラー
PaddleOCR (v6) を導入した際、最新のPaddlePaddle（CPU実行時）の内部コンパイラにおいて、Windows特有のOneDNN変換エラー（NotImplementedError: ConvertPirAttribute2RuntimeAttribute not support）が発生しました。
環境変数でOneDNNを無効化（os.environ["FLAGS_use_onednn"] = "0"）しても、内部で強制ロードされるため回避困難です。安定稼働させるには、Windowsを避け Linux上のDockerコンテナ で構築するか、バージョンを固定したGPU環境を厳密に用意する必要があります。
注意点2：PyTorchの脆弱性とtransformersの強制遮断
Baidu/Unlimited-OCRやmanga-ocrはHugging Faceの transformers を利用しますが、最新版では CVE-2025-32434 という深刻な脆弱性対策のため、torch.load の実行が強制的にブロックされます。
ValueError: Due to a serious vulnerability issue in `torch.load`... we now require users to upgrade torch to at least v2.6
解決策: このエラーを回避するには、PyTorchを v2.6.0以上 にアップグレードする必要があります。パッケージ管理に uv を用いている場合、自動的にCPU版にダウングレードされるのを防ぐため、インデックスを明示して強制再インストールします。
uv pip install --upgrade --force-reinstall torch torchvision --index-url https://download.pytorch.org/whl/cu124
注意点3：manga-ocr は「画像全体」を読めない
マンガ画像の認識テストにおいて、manga-ocrにページ全体の画像を直接入力すると、支離滅裂なテキスト（幻覚）が出力されました。
これはバグではなく、モデルの設計思想の違いです。manga-ocrは「1つの吹き出しに切り抜かれた（Cropされた）画像」を入力する前提で構築されています。
したがって、実戦投入するには、事前に「Comic Text Detector」などの物体検出モデルで吹き出し領域を特定し、切り抜いた画像を順次manga-ocrに投げるパイプライン（前処理）の実装が不可欠です。
4. 【追記検証】長文PDFドキュメントの「一括転写」限界テスト
Unlimited-OCRの最大の特徴である「32Kトークン対応」を検証するため、Wikipediaの「人工知能」のPDF（冒頭3ページ）を高解像度で1枚の巨大な縦長画像に連結し、推論テストを行いました。
| 評価項目 | Baidu/Unlimited-OCR (3B) | EasyOCR |
|---|---|---|
| 推論時間 (3ページ分) | 59.89 秒 | 3.06 秒 |
| ピークVRAM | 8,253 MB (約8.2 GB) | 1,256 MB |
| テキスト認識精度 | 極めて優秀 | 不正確（誤字多発） |
検証結果と考察：
EasyOCRは非常に高速（3.06秒）でしたが、「『計算（computation）』という概念」を「『計算 (comzputation)』 という桃念」と出力するなど、英語と漢字が混在する長文では致命的な誤字・脱字が多発しました。
一方、Unlimited-OCRは、約60秒の推論時間で3ページ分の文章をほぼ完璧にテキスト化しました。従来のTransformerベースのVLMではページが長くなるにつれてKV Cacheが増大しVRAMが枯渇しがちですが、Unlimited-OCRのR-SWA機構により8.2GBのVRAM消費に抑えられたまま処理を完了させています。実務の長文ドキュメント処理において、この安定性は大きな武器となります。
5. ユースケース別推奨フローチャート
以上の検証を踏まえ、目的別に見るべき最適解をまとめました。
- 「論文や請求書を、表組みごとMarkdown化したい」
👉 Baidu/Unlimited-OCR (3B)。VRAMは喰いますが、構造化能力は圧倒的です。 - 「日本のマンガのセリフを正確に翻訳・テキスト化したい」
👉 manga-ocr。必ず吹き出しの切り抜きツールと併用してください。 - 「とりあえず文字だけ素早く読めればいい」
👉 EasyOCR。導入が1コマンドで済み、VRAMも1GB未満でサクサク動きます。 - 「高精度な日本語を大量にバッチ処理したい」
👉 PaddleOCR。ただしLinuxでの構築を強く推奨します。
まとめ
OCRモデルと一言で言っても、「レイアウト重視」「縦書き重視」「軽さ重視」など設計思想は大きく異なります。また、ローカルでAIを動かす以上、ライブラリの依存関係やセキュリティパッチによる不慮のエラーは避けて通れません。本記事の検証データと回避コードが、皆様の開発や環境構築の一助となれば幸いです。