OCRする前に、まずPDFを仕分ける時代かもしれない
前回、PDFをAIに読ませるための前処理について書きました。
そこで一番大きな気づきだったのは、
OCR精度だけを見ても、実務では足りない
ということです。
会計事務所や士業実務で扱うPDFでは、単に文字が読めればよいわけではありません。
試算表であれば、勘定科目と金額の対応関係が残るか。
申告書であれば、項目名・欄番号・金額・注記の位置関係が残るか。
通帳明細であれば、日付・摘要・入金・出金・残高の列が崩れないか。
契約書や判例であれば、文章の流れが自然に保たれるか。
つまり、AIに読ませる前提では、単なるOCR精度ではなく、
AIが読める構造を残せるか
がかなり重要になります。
前回の整理
前回の検証では、現時点の使い分けをざっくり次のように整理しました。
テキストPDFの試算表・決算書・申告書
→ LiteParse
文章PDF
→ PyMuPDF
罫線のある単純な表PDF
→ pdfplumber
スキャンPDFの表・試算表・申告書
→ Docling OCR
日本語スキャン文章
→ NDLOCR-Liteこの整理自体は、今でもかなり実務的だと思っています。
ただ、実際に大量のPDFを処理することを考えると、次の問題が出てきます。
そもそも、そのPDFがどの種類なのかを、最初にどう判定するのか。
ここです。
実務のPDFは、かなり混ざっている
会計事務所で扱うPDFは、きれいに分類されているとは限りません。
たとえば、法人税申告書一式でも、
申告書本体
法人税別表
勘定科目内訳明細書
事業概況説明書
電子申告メール詳細
固定資産台帳
消費税申告書
添付資料
手書きメモ
受領印付き控えのように、いろいろな資料が混ざります。
しかも、それぞれのPDFの性質も違います。
ソフトやe-Taxから直接出力されたテキストPDFもあれば、紙をスキャンした画像PDFもあります。
Excelから出した表形式のPDFもあります。
手書きメモをスキャンしただけのPDFもあります。
一つのPDFの中に、テキストページとスキャンページが混在していることもあります。
この状態で、
PDF
↓
とりあえず全部OCRとしてしまうと、かなり無駄が出ます。
テキストPDFなのにOCRにかけると遅い。
OCR不要なPDFまで重い処理に回してしまう。
逆に、スキャンPDFなのにテキスト抽出だけで処理しようとして、何も取れない。
こういうことが起きます。
必要なのは「PDF交通整理係」
そこで必要になるのが、PDFの入口判定です。
つまり、PDFをAIに読ませる前に、
これはテキストPDFなのか
これはスキャンPDFなのか
これは混在PDFなのかを先に判定する工程です。
最近気になっているのが、Firecrawlの pdf-inspector です。
これはOCRエンジンそのものではありません。
役割としては、PDFの中身を見て、そのPDFをどの処理ルートに流すかを決める「交通整理係」に近いものです。
PDFの内部に文字データがあるのか。
画像中心なのか。
テキスト抽出で足りるのか。
OCRに回す必要があるのか。
こうした判定を最初に行うことで、その後の処理をかなり最適化できそうです。
ツール比較より、ルーティングが大事になる
前回は、LiteParse、PyMuPDF、pdfplumber、Docling OCR、NDLOCR-Liteといった個別ツールを比較しました。
もちろん、それぞれのツールの性能は大事です。
ただ、実務で大量処理する場合、本当に重要なのは、
どのツールが一番強いかだけではありません。
むしろ、
どのPDFを、どのツールに流すかです。
たとえば、私の現時点のイメージでは、こうです。
PDF
↓
pdf-inspector で判定
↓
テキストPDFの表・帳票
→ LiteParse
↓
テキストPDFの文章
→ PyMuPDF
↓
罫線のある単純な表
→ pdfplumber
↓
画像・スキャンPDFの表・申告書
→ Docling OCR
↓
画像・スキャンPDFの日本語文章
→ NDLOCR-Liteもちろん、これだけで完全自動化できるわけではありません。
申告書のような複雑な帳票、表と文章が混在した資料、ページごとに性質が違うPDFでは、追加の判定や例外処理も必要になるはずです。
それでも、最初にPDFの性質を見て、
軽いテキスト抽出で足りるもの
重いOCRに回すべきもの
構造化を重視すべきものを分けるだけでも、かなり効きそうです。
会計事務所では特に効きそう
この「振り分け係」は、会計事務所や士業事務所ではかなり相性がよさそうです。
たとえば、AIに読ませたい資料としては、
決算書PDF
法人税申告書PDF
所得税申告書PDF
相続税申告書PDF
勘定科目内訳明細書
固定資産台帳
総勘定元帳
通帳明細
領収書
契約書
議事録
相続資料
スキャンされた証憑などがあります。
これらを毎回、人間が目で見て、
「これはLiteParse」
「これはPyMuPDF」
「これはDocling OCR」
「これはNDLOCR-Lite」
と判断するのは、なかなか大変です。
しかも、資料が増えるほど、処理ルートの選択ミスも起きやすくなります。
だからこそ、最初にPDFを判定する仕組みがあると、かなり実務的です。
人間が全部判断するのではなく、まず機械的に振り分ける。
そのうえで、難しいものだけ人間やLLMが確認する。
この流れの方が、事務所内で使うには現実的だと思います。
地味だけど、実務ではこういう部品が効く
PDF処理というと、どうしてもOCRエンジンやLLM本体に目が行きます。
どのOCRが一番正確か。
どのLLMが一番うまく読めるか。
どのツールが一番Markdown化しやすいか。
もちろん、それも重要です。
ただ、実務で大量に回すなら、その前段にある「判定」と「振り分け」がかなり重要になります。
いきなりOCRにかけない。
まずPDFの性質を見る。
テキストPDFなら軽い処理に流す。
スキャンPDFならOCRに流す。
表や帳票なら構造を残せる処理に流す。
文章PDFなら高速にテキスト化する。
この入口の交通整理があるだけで、PDF×AIの処理はかなり安定しそうです。
前回は、
OCR精度を競う時代は終わったかもしれない
と書きました。
今回、それに少し付け加えるなら、
OCRする前に、まずPDFを仕分ける時代になるかもしれない
という感じです。
AIにPDFを読ませる処理は、
OCRだけではなく、
判定
↓
振り分け
↓
抽出
↓
構造維持
↓
AIレビューというパイプラインで考えた方がよさそうです。
PDF処理の主役は、LiteParseやDocling OCRかもしれません。
でも、その前段にいる「PDF交通整理係」も、実務ではかなり重要な部品になりそうです。