TL;DR
| 項目 | 内容 |
|---|---|
| 入力 | 罫線・表組みを含む日本語帳票PDF |
| 出力 | 構造化データ（Excel / JSON） |
| GPU | RTX 3090 (24GB VRAM) 1枚 |
| 外部API | なし（すべてローカル） |
使用モデル
| Phase | モデル | VRAM | 役割 |
|---|---|---|---|
| Phase 0 | pdfplumber + OCRCorrector | CPU | テーブル構造抽出 + OCR誤変換補正 |
| Phase 0 (fallback) | fitz + PaddleOCR 2.7.3 | CPU | 画像PDFのテキスト抽出 |
| Phase 1 | Nemotron-Nano-9B-v2-Japanese (Q4_K_M) | ≈6GB | 軽量LLM 一次抽出 |
| Phase 2 | llm-jp-4-32b-A3B (Q4_K_M) | ≈21GB | 汎用LLM 詳細推論 |
| Phase 3 | Qwen-3-VL-Ricoh-8B (INT8) | ≈21GB | VLM 画像ベース抽出 |
PaddleOCRだけでは「建設改良費」が「建設改良荘」に、「償還金」が「憤還金」になる。本記事では、pdfplumber + OCR補正 → 軽量LLM一次抽出 → 汎用LLM詳細推論 → VLM画像抽出の多段パイプラインを、24GB VRAMの制約内で時分割実行する仕組みを解説する。すべてローカルで完結するため、機密文書を外部APIに送信する必要がない。
この記事が対象とする文書
本パイプラインは「罫線を含む日本語帳票PDF」全般を対象としている。以下はいずれもOCR単体では精度が出にくい文書の例である。
- 自治体の予算書・決算書 ── 款・項・目・節の4階層、千円単位の金額
- 企業の財務諸表・決算短信 ── 勘定科目、前期比較の複数列
- 医療機関の診療報酬明細 ── 点数・回数・金額の密な数値テーブル
- 不動産登記事項証明書 ── 枠線内に詰まった漢字・数字の混在
- 保険証券・約款 ── 細かい条件表、特約一覧
共通する問題は「OCRは文字を読めるが構造がわからない」「VLMは構造がわかるが文字を間違える」という相互補完的な弱点にある。
本記事の検証データは自治体の補正予算書（公会計PDF）を使用しているが、パイプラインの設計自体は上記いずれの文書にも適用可能である。
なぜ多段パイプラインが必要なのか
OCRだけでは精度が出ない
PaddleOCRは高い基本性能を持つが、帳票特有の問題がある。
- 罫線がテキスト領域の検出を妨害する
- 信頼度0.85前後の「微妙に間違っている」行が頻出する
- 「費」→「荘」、「償」→「憤」、「購入」→「職入」のような形態的に近い漢字への誤認識
これらは後処理のルールベース補正では対処しきれない。「建設改良荘」を「建設改良費」に直すには、「建設改良費」という語彙が存在することを知っている必要がある。
VLMだけでも精度が出ない
Qwen-3-VL-Ricoh-8Bにページ画像を直接投げて構造化する方法も試した。構造認識は優れているが、数値の転記ミスやハルシネーションが発生する。特にKVキャッシュが溜まった状態では、存在しない行が生成されることがある。
解決策：役割分担
テーブル抽出、OCR補正、LLMによるデータ抽出、VLMによる画像ベース補完をそれぞれ別のフェーズに分離し、各フェーズの弱点を次のフェーズが補う構成にしている。
アーキテクチャ
特徴的なのは、Phase 1でNemotron-Nano-9B（6GB）が先に処理し、そこで抽出できなかった項目だけをPhase 2のllm-jp-4-32b（21GB）にエスカレーションする点である。全データを大型LLMに投げるのではなく、「取りこぼし」だけを次に回す。
VRAMスケジューリング
RTX 3090の24GB VRAMを時分割で使い回す。これがこのシステムの核心部分である。
時間軸 →
Phase 0 [pdfplumber / PaddleOCR ─ CPU] ───── VRAM: 0GB
Phase 1 ......................... [Nemotron 9B] ──── unload VRAM: ≈6GB
Phase 2 ....................................... [llm-jp-4-32B] ── unload VRAM: ≈21GB
Phase 3 ......................................................... [Qwen-VL-8B] VRAM: ≈21GB
├──────────────────────────────────────────────────────────────────────┤
VRAM 0GB 24GB
Phase 2（21GB）とPhase 3（21GB）は同時にVRAMに載らない。フェーズ切り替え時には、現在のモデルをアンロードしてから次のモデルをロードする。
vLLM終了後のVRAM解放は即座には起こらない。プロセス終了後にnvidia-smiで使用量をポーリングし、解放を確認してから次のモデルをロードする。この待機処理を省略するとCUDA OOMで失敗する。
Phase 1のNemotron-Nano-9Bは6GBと軽量なため、Phase 0完了後すぐに起動できる。大半の定型項目はここで抽出が完了し、Phase 2のllm-jp-4-32b（21GB）をロードする頻度を減らせる。この「軽量モデルで先に大半を処理し、重量モデルのロード回数を最小化する」設計が、24GB制約下での実用的な処理速度を実現している。
Phase 0：テーブル抽出とOCR補正
pdfplumberによる構造抽出
pdfplumberでPDF内のテーブルを構造的に抽出する。罫線情報からセル境界を認識し、DataFrameとして取得する。
pdfplumberが有効でない場合、またはテーブルが検出されない場合（画像PDFなど）は、fitz（PyMuPDF）でテキストを取り出し、テキスト量が50文字未満ならPaddleOCR 2.7.3にフォールバックする。
OCRCorrector
Acrobat OCRやPaddleOCRが誤認識しやすいパターンをルールベースで一括補正するユーティリティである。主な補正内容は以下の通り。
- 全角数字・記号 → 半角 ── 「１２３」→「123」
- マイナス記号の正規化 ── 「△」「▲」はマイナス表記として保持、OCR誤読の「A」→「△」に補正
- 会計用語の誤認識修正 ── 「Go 腿」→「金額」、「補正類」→「補正額」
- 丸付き数字の保護 ── NFKC正規化で①が「1」に変換されるのを防ぐため、保護範囲（U+2460〜U+24FF等）を定義してプレースホルダに退避してから正規化を適用する
丸付き数字の保護は地味だが重要な知見である。NFKCを先に適用すると①②③が1, 2, 3に変換され、項目番号が本文の数値と区別できなくなる。正しい順序は「保護対象をプレースホルダに退避 → NFKC正規化 → プレースホルダを復元」である。
款・項・目・節の階層fill-down
予算書のテーブルでは、上位の款・項は最初の行にだけ記載され、以降の行は空セルになる。これをfill-down処理で補完し、各行が完全な階層情報を持つようにする。この処理がないと、LLMが科目名を正しくJSON化できない。
Phase 1〜2：LLMによるデータ抽出
Phase 0で取得したテキストを、款・項の境界で意味的にチャンク分割し、LLMに投げて構造化データ（JSON）を抽出する。
なぜ Nemotron 9B → llm-jp-4 32B の2段階なのか
- VRAMの節約 ── Nemotron 9B（6GB）で大半の項目を抽出できれば、llm-jp-4 32B（21GB）のロード回数を減らせる。21GBモデルのロードには数十秒かかるため、この差は大きい
- タスク特性の違い ── 定型的な項目（金額、年度、科目名）は9Bモデルで十分な精度が出る。文脈依存の推論が必要な項目だけを32Bモデルに回す
- 処理時間の短縮 ── 9Bモデルは高速なので、全チャンク×全項目を素早く走査できる
Phase 1で抽出できた項目はスキップされ、Phase 2では「取りこぼし」だけが処理される。実際の運用では、Phase 1で7〜8割の項目が抽出でき、Phase 2に到達するのは残りの2〜3割である。
プロンプト設計
LLMへのプロンプトには、帳票特有の指示を含める。
1. テキストから指定されたJSONスキーマの項目を抽出してください
2. 公会計書類の表はマトリクス構造です。「横の行（科目名）」と
「縦の列のヘッダー」を交差確認して数値を抽出してください
3. 「△」「▲」、OCR誤認識の「A」はすべてマイナスの数値として出力してください
4. 「Go 腿」→「金額」のようなOCRノイズは文脈から補正して解釈してください
特に重要なのは3と4である。予算書ではマイナス表記に「△」が使われるが、OCRが「A」に誤認識する。プロンプトでこれを明示しないと、LLMはAを英字として解釈してしまう。
重複検出とマージ
複数チャンクにまたがって同じ科目が出現する場合がある。duplicate_historyで重複を追跡し、同一キーに対する上書きをカウントする。これにより、後段の監査で「同じ科目が複数回抽出された」ことを検知できる。
Phase 3：VLMによる画像抽出
Phase 1〜2のテキストベース抽出でも取りこぼした項目がある場合にのみ、PDFのページ画像をQwen-3-VL-Ricoh-8B（INT8、21GB）に直接投げて抽出する。
Qwen-3-VL-Ricoh-8Bを選んだ理由は、Ricoh社が日本語文書認識に特化してファインチューニングしたモデルであり、罫線の多い帳票の構造認識に強いためである。
テキスト抽出とVLMの抽出を分離している理由は、VLMは画像全体を処理するためテキストベースより遅く、VRAMも21GBと大きく消費するからである。VLMは「最後の手段」として使い、テキストで取れるものはテキストで取る。
Phase 2（llm-jp-4-32b、21GB）とPhase 3（Qwen-VL-8B、21GB）は同じVRAMバジェットを使う。Phase 2をアンロードし、VRAM解放を確認してからPhase 3をロードする。
開発で踏んだ地雷
同種のパイプラインを構築する際の参考として、実際に遭遇した問題を記録しておく。
PaddleOCR 2.7.3固定
PaddleOCRはv3.x以降、paddlex経由でmodelscope依存が入る。modelscope→torchのDLL読み込みがWindows+WSL環境で競合し、インポート時にクラッシュする。v2.7.3では発生しない。EasyOCRは日本語の精度がPaddleOCRより明確に劣るため、代替にはならない。
vLLM終了後のVRAM残留
vLLMプロセスをkillした後、nvidia-smi上ではVRAMが即座に解放されない。CUDAコンテキストの解放にOSレベルの遅延があるためで、プロセス終了後にnvidia-smiをポーリングしてVRAM使用量が閾値以下になったことを確認してから次のモデルをロードする必要がある。これを省略するとCUDA OOMが頻発する。
NFKC正規化の順序
全角→半角の正規化にNFKCを使うが、これを丸数字（①②③）の除去より先に適用すると、①が「1」に変換されてしまい、項目番号の誤認識が発生する。OCRCorrectorでは保護範囲（U+2460〜U+24FF、U+3251〜U+325F等）を定義し、該当文字をプレースホルダに退避してからNFKCを適用している。
gemma-3とtorch.compile
gemma-3系モデルをvLLMで使う場合、torch.compileのウォームアップに約290秒かかる。--enforce-eagerで回避できるが、gemma-3アーキテクチャでは--enforce-eager自体が非互換で使えない場合がある。結果としてgemma-3系は採用を見送った。
△とAの混同
予算書のマイナス表記「△」はOCRで「A」に誤認識される。これをLLMプロンプトで明示的に指示しないと、LLMは「A179」をマイナス179千円ではなく意味不明な文字列として扱う。OCRCorrectorのルールベース補正とLLMプロンプトの両方で対処する二重防御が必要だった。
実際のOCR補正例
自治体の水道事業会計補正予算書での検証結果を示す。同様の誤認識パターンは企業の財務帳票にも共通して現れる。
LLMによる文脈ベース補正
| OCR結果 | 補正後 | 原因 |
|---|---|---|
| 建設改良荘 | 建設改良費 | 「費」→「荘」の誤認識 |
| 企業債憤還金 | 企業債償還金 | 「償」→「憤」の誤認識 |
| 受益青貞担金 | 受益者負担金 | 複数文字の連鎖誤認識 |
| 工事請負畳 | 工事請負費 | 「費」→「畳」の誤認識 |
| ３固定斉産購 | 3固定資産購入 | 全角数字 +「資」→「斉」 |
| 65-無形間定査産 | 65-無形固定資産 | 「固定」→「間定」の誤認識 |
| 企業情世還介 | 企業債償還金 | 多数文字の連鎖誤認識 |
これらはLLMが事前学習で「建設改良費」「固定資産」「企業債償還金」といった語彙を知っているからこそ可能な補正である。ルールベースでは「荘→費」のような変換辞書を文書ジャンルごとに用意する必要がある。
OCRCorrectorによるルールベース補正
| OCR結果 | 補正後 | ルール |
|---|---|---|
| Go 腿 | 金額 | 会計用語誤認識テーブル |
| 補正類 | 補正額 | 会計用語誤認識テーブル |
| A179 | △179 |
A + 数字 → △ + 数字 |
| １２３ | 123 | 全角数字 → 半角 |
| ，０００ | ,000 | 全角カンマ・数字 → 半角 |
これらはパターンが決まっているため、LLMに頼らずルールベースで処理する方が速く確実である。
ルールベースで処理できるものはルールベースで、文脈が必要なものはLLMで、という役割分担がこのパイプラインの設計原則である。
この設計が使えるケース、使えないケース
向いている文書
- 罫線・表組みを含む定型帳票
- 科目名・項目名など「LLMが知っている語彙」が多い文書
- 数値の正確性が求められる財務系文書
- 機密性の高い文書（外部APIに送信できないもの）
向いていない文書
- 手書き文書（PaddleOCRの認識精度が根本的に不足する）
- 写真中心の文書（テーブル抽出が意味をなさない）
- 多言語混在文書（本パイプラインは日本語に最適化している）
- 1ページあたりの情報量が極端に少ない文書（パイプラインのオーバーヘッドが見合わない）
まとめ
日本語の帳票PDFという「OCRが最も苦手とする文書ジャンル」に対して、テーブル抽出・ルールベース補正・LLM抽出・VLM画像抽出を多段で組み合わせることで、実用的な精度を達成した。
構築のポイントは4つ。
- pdfplumber + OCRCorrector ── テーブル構造はpdfplumberで、文字補正はルールベースで。LLMに到達する前にノイズを減らす
- Nemotron 9B → llm-jp-4 32B のエスカレーション ── 全データを21GBの大型LLMに投げるのではなく、6GBの軽量LLMで7〜8割を処理し、取りこぼしだけを大型LLMに回す。VRAMと処理時間の両方を節約する
- VRAMの時分割 ── 24GBの制約内でNemotron 9B（6GB）→ llm-jp-4 32B（21GB）→ Qwen-VL-8B（21GB）を切り替え、nvidia-smiポーリングでVRAM解放を確認してから次をロードする
- ルールベースとLLMの二重防御 ── OCRCorrectorで「A→△」「Go 腿→金額」を先に直し、LLMプロンプトでも同じ指示を重ねる。どちらか片方だけでは漏れる
すべてローカルで完結するため、機密文書を外部APIに送信する必要がない。RTX 3090一枚で、帳票PDFの読み取りとデータ抽出を自動化できる。
参考リンク
- PaddleOCR ── v2.7.3を使用
- pdfplumber ── PDFテーブル構造抽出
- Qwen-3-VL-Ricoh-8B ── Ricoh社による日本語文書特化VLM
- vLLM ── LLM/VLM推論エンジン
- llama.cpp ── GGUFモデル推論
- llm-jp-4 ── 日本語特化LLM
- PyMuPDF (fitz) ── PDF解析ライブラリ
関連記事
- RAGの次は「検索しないAI」かもしれない ― KRF（Knowledge Runtime Format）の実装と計測 — 本記事のPhase 0で抽出したデータの出力先となるKnowledge Unitフォーマット
- 日本語帳票PDFの構造抽出とOCR補正をCPUだけで実装する ― Knowledge Compilerの入口 — 本記事のPhase 0部分をコードと計測データで補完