テキストPDFなら全部同じ、ではなかった
ここ最近、PDFをAIに読ませるための前処理について書いています。
前回までの大きな気づきは、PDF処理は単純なOCR精度の勝負ではない、ということでした。
文字をどれだけ正確に読めるかも、もちろん大事です。
ただ、会計事務所や士業実務で本当に困るのは、文字認識そのものよりも、
表の構造が崩れること
です。
試算表であれば、勘定科目と金額の対応関係が残るか。
申告書であれば、欄番号・項目名・金額・注記の位置関係が残るか。
決算書であれば、左右に並んだ資産と負債、当期と前期、科目と金額の関係が崩れないか。
AIに読ませる前提では、単に文字が読めるだけでは足りません。
AIが読める構造を残せるか
が重要になります。
前回の続き：文字データありPDFをどう分けるか
前回は、pdf-inspector のようなツールを使って、まずPDFを入口で判定する話を書きました。
ざっくり言えば、
文字データなし
→ OCRへ
文字データあり
→ テキスト抽出へという入口の振り分けです。
ただ、今回さらに分かったのは、ここから先です。
文字データありPDFだからといって、全部同じ処理でよいわけではありません。
テキストPDFにも、いろいろあります。
きれいな文章PDF。
罫線が明確な財務諸表。
決算短信や有価証券報告書。
法人税申告書のような複雑な帳票。
勘定式の貸借対照表のような左右に並ぶ表。
これらを全部同じツールで処理しようとすると、どこかで崩れます。
明確な罫線表は OpenDataLoader が強い
今回、OpenDataLoader と LiteParse を比較してみて、かなり面白い結果になりました。
OpenDataLoader は、罫線がしっかりしたグリッド表に非常に強いです。
たとえば、
決算短信
有価証券報告書の財務表
勘定科目内訳明細書
開示資料の表のように、明確な罫線で囲まれた表であれば、きれいなMarkdownテーブルに変換しやすい。
しかも速い。
これはかなり魅力的でした。
AIに渡すときも、Markdownテーブルになっていると読みやすいです。
余分なスペースも少ないので、トークン効率もよい。
つまり、OpenDataLoader は、
罫線が明確な表を、きれいなMarkdownテーブルにする
という用途でかなり強いと感じました。
ただし、申告書では崩れる
一方で、OpenDataLoader が苦戦したのが、法人税申告書のような帳票です。
申告書には、1桁ずつ区切られた細かい金額欄があります。
また、左右ブロック、欄番号、注記、入れ子状の罫線が混ざっています。
OpenDataLoader は、この細かいマス目を大量の小さな表として認識してしまい、数字がバラバラに分解されることがありました。
つまり、
罫線があるからといって、常にOpenDataLoaderがよいわけではない
ということです。
ここはかなり重要です。
会計事務所目線では、申告書を壊さずに読ませたい場面は多いです。
そのため、申告書のような複雑な帳票を、単純な表としてMarkdownテーブル化しようとすると、かえってAIが読みにくくなる可能性があります。
申告書や複数カラムは LiteParse が強い
法人税申告書、地方税申告書、所得税申告書、相続税申告書のような資料は、単純な表というより、複雑な帳票レイアウトです。
左右にブロックが並ぶ。
欄番号がある。
注記がある。
1桁ずつ区切られた金額欄がある。
こういうPDFを無理にMarkdownテーブル化すると、元の意味が崩れることがあります。
このような場合は、LiteParse のように、元のPDFの物理的な配置やアライメントを残す方が、AIに読ませやすいと感じました。
LiteParse は、きれいなMarkdownテーブルを作るというより、元のPDFの位置関係をできるだけ保ったまま出力する方向に強みがあります。
そのため、
法人税申告書
所得税申告書
相続税申告書
勘定式の貸借対照表
左右2カラムの財務資料
試算表のような資料では、OpenDataLoaderよりも LiteParse の方が向いている場面があります。
フローチャートにするとこうなる
現時点のPDF処理フローは、次のように整理できます。
ポイントは、
最強ツールを1つ決める話ではない
ということです。
PDFの種類によって、向いている処理が違います。
そして、その違いを最初に判定して、適切なルートに流す。
これが重要です。
会計事務所ではかなり効きそう
会計事務所では、日々いろいろなPDFを扱います。
決算書
試算表
総勘定元帳
法人税申告書
所得税申告書
相続税申告書
勘定科目内訳明細書
固定資産台帳
通帳明細
領収書
電子申告メール詳細
契約書
議事録これらを全部同じ方法で処理するのは無理があります。
OCRに回すべきものもあれば、テキスト抽出だけで十分なものもあります。
Markdownテーブル化した方がよいものもあれば、元の位置関係を残した方がよいものもあります。
だからこそ、最初にPDFを仕分ける発想が必要になります。
人間が毎回判断するのではなく、まず機械的に判定する。
そのうえで、難しいものだけ人間やLLMが確認する。
この流れにできれば、ローカルPC上でのPDF×AI処理がかなり現実的になります。
PDF処理はパイプラインで考える
PDFをAIに読ませる処理は、単に
OCRではありません。
これからは、
判定
↓
振り分け
↓
抽出
↓
構造維持
↓
AIレビューというパイプラインで考える必要がありそうです。
LiteParse、OpenDataLoader、Docling OCR、NDLOCR-Lite。
それぞれに得意分野があります。
だからこそ、どれか1つを選ぶのではなく、PDFの性質ごとに適切な処理ルートへ流す。
この「振り分け係」が、ローカルAI時代のPDF処理ではかなり重要な部品になりそうです。