OCR精度を競う時代は終わったかもしれない
士業実務で本当に重要なのは、AIが読める構造を残せるかだった
最近、ローカル環境でPDF処理ツールの比較をしています。
目的はシンプルです。
会計事務所や士業実務で扱うPDFを、できるだけ安全に、ローカルPC上で処理したい。
試算表、決算書、申告書、通帳明細、有価証券報告書、契約書、相続資料。
こうした資料をAIに読ませる前に、PDFからテキストや表をきれいに取り出す必要があります。
ただ、実際に検証してみると、思っていたよりずっと面白い結果になりました。
一番大きな気づきは、これです。
OCR精度の勝負ではなかった。
最初の仮説
当初は、こう考えていました。
日本語OCRとしては、NDLOCR-Liteがかなり強い。
日本語の文字認識精度が高いなら、士業実務のPDF処理でも本命になるのではないか。
実際、NDLOCR-Liteの文字認識精度はかなり高かったです。
漢字、かな、数字の読み取りは非常にきれいでした。
Tesseractと比べると、実務で使いたくなるレベルがかなり違います。
ところが、試算表のような表データを処理すると、問題が出ました。
文字は読めている。
でも、表の構造が崩れる。
これが致命的でした。
士業実務で本当に困ること
たとえば、試算表ではこういう情報が必要です。
売上高 1,000
売上原価 700
販管費 200ところが、OCR結果がこうなると困ります。
売上高
売上原価
販管費
1,000
700
200文字認識としては、かなり正しいかもしれません。
でも、会計実務では使いにくい。
なぜなら、勘定科目と金額の対応関係が壊れているからです。
AIに読ませる場合も同じです。
人間なら、元のPDFを見ながら補正できるかもしれません。
でも、AIに渡す前処理としては、行と列の対応関係が崩れると一気に価値が落ちます。
逆に、多少文字の誤認識があっても、
売上高 | 1,000
売上原価 | 700
販管費 | 200という構造が残っていれば、AI側でかなり補正できます。
ここが今回の一番面白い点でした。
OCR精度ではなく、AI前処理性能を見る
従来のOCR評価は、主に「文字をどれだけ正確に読めるか」でした。
もちろん、それは今でも重要です。
ただ、AIに読ませる前提では、それだけでは足りません。
重要なのは、
AIが解釈できる構造を保ったまま取り出せるか
です。
つまり、評価軸が少し変わっています。
従来は、
OCR
↓
文字認識率でした。
でも、AI時代のPDF前処理では、
OCR / PDF抽出
↓
構造維持精度
↓
AIが読めるかになります。
士業実務でいうと、特に重要なのは次のような点です。
勘定科目と金額の対応関係が残るか
表の行と列が維持されるか
空白セルを勝手に詰めてしまわないか
金額列が縦にバラバラにならないか
AIが後続処理できるMarkdownやCSVにできるか
ここを見ないと、単純なOCR精度だけでは実務評価を誤ります。
今回の検証結果
今回、ローカルCPU環境で複数のPDF処理ツールを比較しました。
対象は、テキストPDFの試算表・有価証券報告書、さらにそれを画像化したスキャンPDFです。
ざっくり結果をまとめると、こうなりました。
テキストPDFの本命は LiteParse
テキストPDF、特に試算表や決算書、所得税・法人税・相続税等の申告書などでは、LiteParseが非常に強い結果でした。
処理速度が速く、表や帳票のアライメントも比較的きれいに残ります。
PyMuPDFは圧倒的に速いのですが、そのままテキスト抽出すると、表の横並びや帳票内の位置関係が崩れやすい。
一方でLiteParseは、PyMuPDF系の速さを活かしながら、表や帳票の構造補正に寄せている印象です。
したがって、きれいなテキストPDFのうち、試算表・決算書・申告書のような表や帳票形式の資料であれば、まずLiteParseを使うのがよさそうです。
文章PDFなら PyMuPDF
契約書、判例、通達、稟議書のようなベタ書きの文章PDFであれば、PyMuPDFはかなり有力です。
とにかく速いです。
表構造を厳密に取りたい場面には向きませんが、文章を素早くテキスト化する用途では非常に使いやすい。
士業実務では、文章PDF用の高速抽出エンジンとして十分に使えます。
罫線のある単純な表なら pdfplumber
pdfplumberは、明確な罫線で囲まれた表に強いです。
通帳明細、一覧表、定型帳票のように、表の枠線がはっきりしていて、構造が比較的単純なPDFでは有効です。
ただし、試算表や決算書、所得税・法人税・相続税等の申告書などは、罫線はあっても、左右ブロック・入れ子・欄番号・注記が混在した複雑な帳票レイアウトなので、pdfplumberでCSV化すると崩れやすい。
使いどころを選ぶツール、という印象です。
スキャンPDFの現時点の本命は Docling OCR
画像PDF、つまりスキャンPDFでは、Docling OCRがかなり強い結果でした。
特に驚いたのは、表構造の保持です。
文字認識そのものは、NDLOCR-Liteのほうがきれいな場面もあります。
ただ、試算表のような資料では、Docling OCRのほうが行と列の関係を保ったままMarkdownやCSVに近い形で出力しやすい。
これは実務上かなり大きいです。
もちろん課題もあります。
ローカルCPUだと重い。
1ページあたり数秒から十数秒かかるため、日中に大量処理するには少し厳しい。
ただ、夜間バッチで処理するなら十分に現実的です。
NDLOCR-Liteは「将来有望株」
NDLOCR-Liteは、文字認識精度だけ見ると非常に優秀でした。
日本語の読み取りはかなりきれいです。
処理速度も比較的速いです。
ただし、試算表のような表では、読み順の整序が逆に効きすぎて、列ごとにテキストをまとめてしまうことがありました。
その結果、勘定科目と金額の対応関係が壊れる。
これでは、そのままAI前処理として使うには危険です。
ただし、NDLOCR-Liteには大きな可能性があります。
それは、座標情報です。
OCR結果に、文字や単語のboundingBox、つまり位置情報が残っています。
これを使えば、
スキャンPDF
↓
NDLOCR-Lite
↓
座標情報を取得
↓
行ごとに再整列
↓
CSV化
↓
AIレビューという処理ができる可能性があります。
もしこれがうまくいけば、かなり面白いです。
日本語に強い。
CPUで動く。
ローカルで完結する。
しかも表構造も復元できる。
つまり、士業実務向けの強力なローカルPDF前処理基盤になるかもしれません。
現時点の使い分け
今回の検証をもとに、現時点ではこう整理しています。
テキストPDFの試算表・決算書
→ LiteParse
文章PDF
→ PyMuPDF
罫線のある単純な表PDF
→ pdfplumber
スキャンPDFの表・試算表
→ Docling OCR
将来有望
→ NDLOCR-Lite + 座標再構築特に士業実務では、PDFの種類ごとに処理ルートを分けるのが大事です。
すべてを1つのツールで処理しようとすると、どこかで無理が出ます。
きれいなテキストPDFなのか。
スキャン画像なのか。
表なのか。
文章なのか。
罫線があるのか。
スペースで列が表現されているのか。
この分類を最初に行い、そのうえで処理ツールを選ぶ。
これが実務的には一番安全です。
まとめ
今回の検証で、PDF処理に対する見方が少し変わりました。
OCRの価値は、単に文字を読むことではありません。
少なくともAIに読ませる前提では、重要なのは、
AIが解釈できる形で構造を残せるか
です。
文字認識率が高くても、表の行と列が壊れれば、実務価値は大きく下がります。
逆に、多少の誤認識があっても、構造が保たれていれば、AIで後補正できます。
その意味で、これからのPDF処理は、
OCR精度だけでなく、
AI前処理性能で評価する必要がありそうです。
今回の第1ラウンドの私の結論は、こうなりました。
テキストPDF
→ LiteParse
画像・スキャンPDF
→ Docling OCRこれは単なるツール比較ではなく、士業実務における「AI時代のPDF前処理」の研究テーマになりそうです。
次は、NDLOCR-Liteの座標情報を使って、試算表の行と列を自動復元できるかを試してみたいと思います。