クラウドAPIなしでローカルAIモデルを使ってPDFデータ抽出を自動化する方法

最も信頼性の高いローカルPDF抽出ワークフローは、通常、単一のAIプロンプトではなくパイプラインです：まず、PDFから信頼できるテキストとレイアウトを復元し、次にローカルモデルにそのコンテンツを厳格なスキーマにマッピングさせ、最後にフィールドを保存する前に検証します。すべてのPDFページを直接ビジョンモデルに送信することは機能する場合がありますが、ネイティブPDFテキストやOCRで十分な場合と比較して、多くの場合、速度が遅く、ハードウェア負荷が高く、監査が困難になります。

この区別は、「クラウドAPIなし」が目標である場合に重要です。ドキュメントの内容をホストされたサービスに送信せずに、自分のマシン上のローカルAPI（例えば、localhost上のOllamaのHTTPエンドポイント）を使用できます。Ollamaは、モデルがローカルで実行されている場合、プロンプトと応答がOllamaに送信されないことを明記しており、クラウド機能を無効にするローカル専用モードを提供しています。Doclingも同様に、リモートサービスをデフォルトで無効にしていますが、オフライン使用のために事前に取得しない限り、セットアップ中にモデルファイルをダウンロードする必要がある場合があります。

適切なスタックはPDFによって異なります。選択可能なテキストを含むデジタル生成の請求書は、スキャンされた領収書、複雑な財務テーブル、または画像が多いフォームとは異なるアプローチが必要です。このガイドでは、これらのオプションを比較し、請求書、契約書、発注書、申請フォーム、レポート、その他の反復的なドキュメントに適用できる4段階の自動化パターンを示します。

クイック推奨事項：ドキュメントタイプでパイプラインを選択する

万能な勝者はありません。ドキュメントが予測可能で埋め込みテキストを含む場合、パーサーと小さなローカル言語モデルは、コスト、速度、再現性において、はるかに大きなビジョンワークフローを上回る可能性があります。テキストの位置が意味の一部である場合（例えば、結合セルのあるテーブルや、ラベルと値が空間的にペアになっているフォーム）、レイアウト認識処理の価値が高まります。

ステップ1：OCRまたはAIを選択する前にPDFを分類する

まず、ドキュメントがすでに使用可能なテキストを含んでいるかどうかを判断します。デジタル生成とは、PDFがソフトウェアから生成され、通常、選択およびコピー可能なテキストオブジェクトを含んでいることを意味します。スキャンPDFはページ画像のみを含んでいる場合があり、通常のテキストパーサーはほとんどまたは何も返しません。

PyMuPDFの公式ドキュメントでは、page.get_text()による直接テキスト抽出を示しています。最小限のローカルテストは次のようになります：

import pymupdf

def extract_native_text(pdf_path: str) -> str:
    pages = []
    with pymupdf.open(pdf_path) as doc:
        for page in doc:
            pages.append(page.get_text())
    return "\f".join(pages)

text = extract_native_text("invoice.pdf")
print(text[:1000])

公式PyMuPDF基礎を参照してください。PyMuPDFは、プレーンなPDFテキストが自然な読み取り順序で表示されない場合や、予期しない改行が含まれる場合があることも警告しています。これはパーサーの制限であり、必ずしもAIの問題ではありません。

最適な用途：テキストのコピー/貼り付けがすでに機能し、近くのラベルからフィールドを簡単に識別できる請求書、明細書、レポート、フォーム。

注意点：ページには、小さなテキストレイヤーと大きなスキャン画像が含まれている場合があります。したがって、「いくつかのテキストが存在する」かどうかを確認するだけでは、完璧なスキャン検出器にはなりません。本番自動化では、単一のユニバーサルな文字数しきい値に頼るのではなく、代表的なドキュメントを検査してください。

アクション：20〜50個の代表的なPDFを取り、デジタル生成、スキャン、混在、レイアウト重視のグループに分類します。パイプラインは、ファイル拡張子だけでなく、ドキュメントの挙動によってルーティングする必要があります。

ステップ2：ローカルでテキストを抽出する、または必要な場合のみOCRを実行する

オプションA：クリーンなデジタルPDF用のPyMuPDF

テキストレイヤーが信頼できる場合、直接抽出が通常最もシンプルなルートです。これにより、OCRの遅延を回避し、すでに正しくエンコードされたテキストにOCR文字エラーを導入することを避けます。長いドキュメントの場合、ページ区切りを保持し、ドキュメント全体を一度にモデルに渡す代わりに、ページグループまたは論理セクションを処理できます。

トレードオフ：プレーンテキストは安価で高速ですが、テーブル、多段組ページ、ヘッダー、フッター、読み取り順序には追加の処理が必要な場合があります。これらの関係がターゲットフィールドにとって重要であれば、貧弱なソーステキストにプロンプト指示を積み重ねるのではなく、レイアウト認識表現に移行してください。

オプションB：スキャンページ用のOCRmyPDFとTesseract

TesseractはオープンソースのOCRエンジンです。現在のユーザーマニュアルは5.xシリーズと、個別の学習済みデータファイルを介した多くの言語のサポートを記載しています。OCRmyPDFは、スキャンページが検索可能なテキストレイヤーを取得できるように、PDF固有の処理の周りにOCRをラップします。

一部のページがすでにテキストを含んでいる混在ドキュメントの場合、現在のOCRmyPDFバージョンはskipモードをサポートしています：

ocrmypdf --mode skip input.pdf searchable.pdf

公式OCRmyPDF高度なドキュメントは、--mode skipが既存のテキストがあるページをそのままにし、必要なページのみをOCRすることを説明しています。同じドキュメントでは、検出された以前のOCRを置き換えるためのredoと、すべてのコンテンツをラスタライズしてOCRするためのforceについても説明しています。forceは、ラスタライズによりベクターの利点が失われ、インタラクティブコンテンツがフラット化される可能性があるため、慎重に使用してください。

Tesseractのインストール、言語、コマンドラインの挙動については、公式Tesseractユーザーマニュアルを使用してください。OCR言語は重要です。例えば、請求書に英語とドイツ語が含まれている場合、デフォルトの英語モデルが両方を同等に処理できると仮定するのではなく、適切な言語データをインストールして設定してください。

オプションC：構造が重要な場合のDocling

Doclingは、レイアウト、テーブル、OCR、ローカルビジョン言語処理オプションを備えたドキュメント変換用に設計されています。そのプロジェクトドキュメントは、高度なPDF理解、テーブル構造、OCR、ロスレスJSON/Markdownスタイル出力をリストしており、機密およびエアギャップワークフロー向けにローカル実行を意図しています。

基本的なPython変換は次のように小さくできます：

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
doc = converter.convert("input.pdf").document

markdown = doc.export_to_markdown()
structured = doc.export_to_dict()

公式Doclingクイックスタートを参照してください。Doclingはまた、ローカルVLMパイプラインと複数のOCRバックエンドをサポートしています。その高度なオプションは、リモートサービス呼び出しには明示的なオプトインが必要であることを説明しており、モデルアーティファクトはオフライン使用のために事前取得できます。

最適な用途：複雑なテーブル、見出し、多段組レポート、混在スキャン、またはプレーンテキストダンプの代わりに再利用可能なドキュメント表現が必要なケース。

トレードオフ：パイプラインは単純なPDFパーサーよりも重くなります。単にコンポーネントが多いからではなく、追加の構造が抽出精度を向上させるために使用してください。

アクション：ターゲットスキーマが必要とする情報を保持する最も軽い抽出方法を選択してください。クリーンな埋め込みテキストをOCRしないでください。レイアウトが意味を決定する場合にレイアウトを破棄しないでください。

ステップ3：ローカルモデルを使用して復元されたコンテンツを厳格なスキーマにマッピングする

信頼できるソースコンテンツを取得したら、ローカルモデルを得意なことに使用します：セマンティックマッピング。「この請求書からすべてを抽出して」と尋ねる代わりに、実際に必要なフィールドを定義します。

例えば：

from pydantic import BaseModel
from typing import Optional

class LineItem(BaseModel):
    description: str
    quantity: Optional[float]
    unit_price: Optional[float]
    amount: Optional[float]

class Invoice(BaseModel):
    invoice_number: Optional[str]
    invoice_date: Optional[str]
    vendor_name: Optional[str]
    currency: Optional[str]
    subtotal: Optional[float]
    tax: Optional[float]
    total: Optional[float]
    items: list[LineItem]

Ollamaの現在の構造化出力ドキュメントは、formatフィールドを介してJSONスキーマを渡し、Pydanticで応答を検証することをサポートしています。ローカル呼び出しは次のようになります：

from ollama import chat

schema = Invoice.model_json_schema()

prompt = f"""
Extract the invoice into the supplied schema.

Rules:
- Use only information present in the source.
- Use null when a field is not found.
- Do not infer missing invoice numbers, dates, tax, or totals.
- Preserve line items individually.

SOURCE:
{text}
"""

response = chat(
    model="gpt-oss",
    messages=[{"role": "user", "content": prompt}],
    format=schema,
    options={"temperature": 0},
)

invoice = Invoice.model_validate_json(response.message.content)

これは、より決定論的な構造化完了のためにゼロなどの低い温度と再利用可能なスキーマを推奨する、Ollamaの公式構造化出力ドキュメントのパターンに従っています。

上記のモデル名は、Ollama自身の構造化出力ドキュメントからの例であり、すべての抽出ジョブに最適なモデルであるという主張ではありません。明確なラベルのある反復的な請求書には小さなモデルで十分かもしれません。曖昧な契約書や一貫性のないレイアウトには強力なモデルが役立つ可能性がありますが、一般的により多くのメモリと処理時間が必要になります。

テキストモデルかビジョンモデルか？

パーサー/OCR出力がすでに必要なフィールド関係を保持している場合は、テキストモデルを使用します。視覚的な位置が不可欠であるか、テキスト変換が一貫して構造を失っている場合は、ビジョン対応のローカルモデルを使用します。Ollamaの公式ビジョンドキュメントは、ローカルビジョンモデルへの画像入力をサポートしており、その構造化出力機能はビジョン対応モデルと組み合わせることができます。

ただし、すべてのページを画像にレンダリングするとトレードオフが変化します：

• より多くのピクセルを処理する必要があります。
• 高解像度ページはより多くの計算リソースとメモリを消費します。
• 長いPDFではページのバッチ処理が重要になります。
• 視覚モデルは依然としてフィールドを捏造したり、数値を誤読したりする可能性があります。
• 抽出された値をページまたはソース領域に遡及する方法が必要です。

アクション：パーサー/OCRテキストとスキーマ制約付きローカルLLMから始めてください。すべてのページにビジョンコストを支払う代わりに、難しいページタイプのみをローカルVLMにエスカレーションしてください。

ステップ4：JSON、CSV、Excel、またはデータベースに書き込む前に検証する

スキーマ有効なJSONは、自動的に事実的に正しいわけではありません。モデルは間違った値で有効なフィールドを生成する可能性があります。したがって、最後の段階では、可能な限り決定論的なチェックを使用する必要があります。

請求書の場合、有用なチェックには以下が含まれます：

• 必須の識別フィールド：ワークフローが必要とする場合、請求書番号またはベンダー名が存在する必要があります。
• 日付解析：03/04/26などの曖昧な文字列を信頼するのではなく、固定ポリシーで日付を解析します。
• 算術：明細項目金額の合計を、定義された許容範囲内でドキュメントの小計と比較します。
• 合計：小計に税とその他の手数料を加えたものが合計と一致するかを確認します。
• 通貨：ドキュメントが英語であるからといってUSDであると仮定しないでください。
• 来歴：ソースファイル名、ページ番号、抽出タイムスタンプ、および必要に応じて元のPDFのハッシュを保存します。
• レビューキュー：値を黙って埋める代わりに、欠落、矛盾、または低信頼度のケースを人間のレビューにルーティングします。

基本的なバッチ構造は、抽出と検証を分離できます：

from pathlib import Path
import json

for pdf_path in Path("inbox").glob("*.pdf"):
    source_text = extract_native_text(str(pdf_path))

    # If text is unusable, run your OCR or Docling branch here.
    record = extract_with_local_model(source_text)

    errors = validate_record(record)

    if errors:
        save_for_review(pdf_path, record, errors)
    else:
        output = Path("processed") / f"{pdf_path.stem}.json"
        output.write_text(
            json.dumps(record, ensure_ascii=False, indent=2),
            encoding="utf-8"
        )

ヘルパー関数は、請求書、契約書、税務フォーム、ラボレポート、発注書の間で検証ルールが劇的に異なるため、意図的にアプリケーション固有のままにしています。ユニバーサルバリデーターは誤った信頼感を生み出します。

CSVまたはExcelが必要な場合、実際に行と列に属するフィールドのみをフラット化してください。繰り返しの明細項目があるドキュメントの場合、すべてのフィールドを1つの広いスプレッドシート行に強制するよりも、ドキュメントIDでリンクされた1つのドキュメントレベルテーブルと2番目の明細項目テーブルを作成する方が、多くの場合クリーンです。

アクション：数千のファイルを処理する前に検証ルールを定義します。ラベル付きサンプルセットに対してテストし、「正常に処理されたドキュメント」だけでなく、フィールドレベルの精度を記録します。

実用的な完全ローカルアーキテクチャ

多くの中小規模の自動化ジョブでは、この責任の分担は、オールインワンモデルよりも維持しやすいです：

PDF inbox
   |
   +-- born-digital --> PyMuPDF -------------------+
   |                                               |
   +-- scanned/mixed --> OCRmyPDF/Tesseract -------+--> normalized text/layout
   |                                               |
   +-- layout-heavy --> Docling -------------------+
                                                   |
                                                   v
                                         local LLM / VLM
                                                   |
                                            JSON Schema
                                                   |
                                                   v
                                   deterministic validation
                                                   |
                            +----------------------+----------------+
                            |                      |                |
                           JSON                   CSV             database

この設計により、コンポーネントを独立して交換できます。OCR品質が弱い場合は、LLMを再トレーニングせずにOCRレイヤーを改善します。ローカルモデルが遅すぎる場合は、PDFパーサーを変更せずに小さいモデルを使用します。あるベンダーの請求書に特別なテーブル処理が必要な場合は、それらのファイルのみをDoclingまたはビジョンブランチ経由でルーティングします。

Ollama vs. llama.cpp vs. Docling VLM：どのローカルランタイムを選択すべきか？

公式のllama.cppリポジトリは、ローカルllama-serverと文法制約付き生成を記載しており、現在のサーバーコードもJSONスキーマ制約を受け入れます。Doclingのビジョンモデルドキュメントは、ドキュメント変換用のローカルVLMオプションをリストしています。

モデルリーダーボードのみに基づいてランタイムを選択しないでください。PDF抽出の場合、実用的な指標は、フィールド精度、ドキュメントあたりのスループット、マシン上のメモリ使用量、レイアウトでの失敗率、起動の複雑さ、誤った結果を検査しやすさです。

パイプラインを真にローカルに保つ方法

「クラウドAPIなし」は、単なるマーケティングラベルではなく、検証できるデプロイメントプロパティであるべきです。

Ollama

Ollamaの公式FAQは、ローカルプロンプトと回答がOllamaに送信されないことを述べています。また、クラウド無効化設定も記載しています：

OLLAMA_NO_CLOUD=1

または同等のdisable_ollama_cloudサーバー設定。OllamaのローカルAPIはhttp://localhost:11434で実行され、その認証ドキュメントによると、ローカルアクセスには認証が必要ありません。

localhostにバインドされたサービスは、LANに公開されたサービスとは異なることを覚えておいてください。バインドアドレスを変更したり、別のサーバーの後ろに配置したりする場合、アクセス制御はあなたの責任です。

Docling

Doclingは、リモートサービスの使用をデフォルトで無効にしています。そのドキュメントはまた、処理のプライバシーとモデル取得を区別しています：モデルは、事前にダウンロードしない限り、初回使用時に取得される場合があります。エアギャップシステムの場合は、接続されたステージングマシンでdocling-tools models downloadを使用するか、承認済みのモデルアーティファクトを事前にステージングし、オフライン環境をそのローカルアーティファクトディレクトリに向けます。

アクション：機密ドキュメントを処理する前に、オペレーティングシステムまたはネットワーク層でアウトバウンドネットワークアクセスをブロックし、接続を監視しながらテストを実行します。アプリケーション設定は有用ですが、ネットワーク制御は独立した検証レイヤーを提供します。

ローカルAIが解決しないこと

ローカルで実行することはデータ制御オプションを改善しますが、抽出が自動的に正しく、コンプライアンス準拠で、安全になるわけではありません。ローカルファイルは、デバッグログ、一時ディレクトリ、バックアップ、共有フォルダー、過度に寛容なサービス、またはコピーされたエクスポートを通じて依然として漏洩する可能性があります。ローカルモデルは、ホストされたモデルと同様に値を幻覚することもできます。

銀行口座番号、支払い指示、契約日付、医療値、規制識別子などの高影響フィールドの唯一の検証者としてモデルを使用しないでください。それらの場合、ソーステキストと比較し、決定論的な検証を適用し、信頼度が不十分な場合は人間のレビューを要求します。

フォルダ全体を自動化する前にテストする方法

実際に受け取るケースを含む小さなラベル付き評価セットを構築します：

• クリーンなデジタルPDF。
• 低解像度スキャン。
• 回転または傾いたページ。
• 複数ページの請求書。
• ページをまたぐテーブル。
• 欠落したオプションフィールド。
• 異なる日付と数値形式。
• 少なくとも1つの意図的に難しいドキュメント。

各ターゲットフィールドについて、抽出された値をグラウンドトゥルースと比較します。識別子の完全一致、金額の数値許容範囲、明細項目の行レベル精度を測定します。また、処理時間と手動レビューに送信されたドキュメントの割合も記録します。

よりシンプルなPyMuPDF-plus-LLMパスが必要な精度に達する場合は、それを維持します。スキャンが主な失敗である場合は、OCRを改善します。テーブル関係が問題である場合は、Doclingをテストします。視覚的に配置されたフィールドが依然として難しい場合は、そのサブセットをローカルビジョンモデル経由でルーティングします。この段階的なエスカレーションは、すべてのページに最も重いモデルを適用するよりも、速度とハードウェア使用量に対するより良い制御を通常提供します。

結論

優れたローカルPDF抽出システムは、ドキュメント読み取りとセマンティック抽出を分離します。PDFがすでに良いテキストを含んでいる場合はPyMuPDFを使用し、ページがスキャンされている場合はOCRmyPDF/Tesseractを使用し、構造とテーブルが重要な場合はDoclingを使用し、ビジネススキーマへの柔軟なマッピングが必要な場合はローカルOllamaまたはllama.cppモデルを使用します。テキストパイプラインが確実に保持できない情報を視覚的レイアウトが追加する場合にのみ、ローカルビジョンを使用してください。

最終的な要件は検証です。JSONスキーマはモデル応答の形状を制約できますが、金額、日付、名前、または口座番号がソースと一致することを証明することはできません。不確実なドキュメントが見え、レビュー可能になるようにパイプラインを設計すれば、ドキュメントをクラウドAPIに渡すことなく、またローカルAIが品質管理の必要性を排除すると見せかけずに、PDFデータ抽出の大部分を自動化できます。