Open WebUIで社内PDFを活用する前に何を決めるか：OCRエンジン選びより先に見る3つの処理経路
Open WebUIは、文章生成AI（LLM）と対話するためのWebインターフェースです。PDFなどの文書を取り込み、その内容を検索・参照しながらAIに質問できます。
文書を取り込む際には、Open WebUIの既定の文書抽出方法に加えて、文書抽出に使うツールとしてDocling、MinerU、PaddleOCR-VLなどを選べます。文書抽出を外部のサービスへ渡す構成も可能です。そのため、PDFがもともと持つ文字情報を使うのか、ページを画像として読むのかによって、通る処理経路が変わります。
選択肢が多いと「どのOCRを使うか」から比較したくなりますが、その前に確認したいのが、実際に扱うPDFの状態です。まず1件を開き、PDF内の文字をそのまま使えるのか、画像として読む必要があるのか、ページごとに状態が違うのか、文字と画像が混在しているのかを確認します。
この記事では、PDFの状態から最初に試す処理経路を整理し、実測例を交えながら、Open WebUIで文書を扱うときにどこまで確認できたかを分けて見る方法を紹介します。どの製品が最も優れているかを順位付けするのではなく、PDFの状態に合った入口を見つけることが目的です。
社内規程、報告書、帳票など、外部AIへそのまま送る前に情報管理上の確認が必要なPDFを、Open WebUIなどのローカル環境で扱う場面もあります。ただし、ローカル環境で扱うこと自体が安全性を保証するわけではありません。情報管理、権限、構成、運用は別途確認が必要です。
構成図：今回の文書処理とLLM推論の役割分担
今回の検証では、Open WebUIとPDF取込・文書処理を文書処理用ローカルPCに、LLM推論エンジンをLLM推論用オンプレサーバーに置き、両者をOpenAI互換APIで接続しました。文書処理には、PDF内テキストの利用、OCR、VLMによる文書解析が含まれます。これは今回の役割分担であり、Open WebUIとLLM推論エンジンを同じ機器へ置く構成を否定するものではありません。
文書処理側とLLM推論側の役割を分けると、問題がどちらにあるかを切り分けて確認しやすくなります。同じAPI仕様で接続できる推論基盤であれば、Open WebUI側の接続先やモデル設定を変更することで、文書処理側を大きく変えずに推論基盤を差し替えやすくなります。ただし、認証方式やモデル名、ツール呼び出しなどの仕様差によって、追加設定が必要になる場合があります。
最初に確認する3つのポイント
- OCRエンジンを比較する前に、実際に扱うPDFの状態を確認する。
- PDFの状態に合わせて、最初に試す処理経路を決める。
- 「文字を取り出せた」「保存できた」「検索できた」「AIが答えられた」を分けて確認する。
図1：実際に扱うPDFで決める最初の三分岐
まず1件のPDFを開き、その中の複数ページで文字の選択・検索・コピー結果を確認する
├─ PDF内の文字が用途上十分 → PDF内の文字をそのまま使う
├─ 文字を直接使えない、または不十分 → 画像として読む
└─ ページごとに状態が違う、または混在 → 内容に応じて分けるこれは合否判定ではなく、最初の一手を決めるための分岐です。「文字を選択できる」だけで「OCR不要」とは決めません。
まず、実際に扱うPDFの文字を選択・検索する
手元のPDFから実際の利用対象に近い1件を、PDFビューアー（Acrobat Readerなど）で開きます。表紙だけでなく、本文、表、画像を含む複数ページを確認します。ページによって文字の状態が違うこともあります。最初からPDF全体を同じ方法で処理すると決めず、ページごとの違いや、文字と画像の混在も見ます。
確認するのは次の4つです。
- 文字を選択できるか。
- 文書内検索で、その文字を見つけられるか。
- コピーした文字が、検索や参照に使える形になっているか。
- ページごとに状態が違わないか、文字と画像が混在していないか。
確認後、最初の経路を一つ選びます。
- A：PDF内の文字をそのまま使う。 文字を選択・検索でき、コピーした内容も用途上十分なら、PDFがすでに持つ文字情報を使う経路を先に試します。ただし、表の行と列、読む順番、IDまで正しいとはまだ決めません。
- B：画像として読む。 文字を選択・検索できない、または取り出した文字が崩れて用途に足りないなら、ページを画像として読むOCRやVLM（画像と文章を扱えるモデル）の経路を先に試します。
- C：ページや内容に応じて分ける。 そのまま使える文字と画像が混在するなら、1つの方法をPDF全体にまとめて適用せず、ページや内容に応じてAとBを使い分けます。
判断しにくい場合はCの「混在・不明」として、ページごとの状態や、文字と画像の混在を確認します。
ツール名だけでなく、どの読み方を使ったかを見る
同じツールでも、リクエストの条件によってPDFの読み方は変わります。
ここでは、OCRとVLMを分けて扱います。OCRはページ画像から文字を認識する処理で、VLMは画像と文字・レイアウトなどをまとめて扱うモデルです。CPUとGPUは処理方式ではなく、これらをどのハードウェアで動かしたかを示します。
今回の検証では、同じ1ページのデジタル生成帳票を、同じDocling Serve 1.26.0に対して、OCRに関するリクエスト条件を変え、2通りで処理しました。これはOpen WebUIの画面上の切替ではなく、Docling Serveへ送るリクエストの条件です。
なお、Docling Serve 1.26.0は今回実測した構成です。現在のOpen WebUI公式ドキュメントでは、新しい設定方式との完全互換にはDocling server 2.0.0以上が必要とされています。
- OCRでページ画像を読み直す条件： ページを画像としてOCRで読み直す経路です。
- OCRを使わず、PDF内テキストの利用を想定した条件： PDF内にある既存テキストを利用する想定の経路です。
OCRを使わない条件の結果では、PDF内の既存テキストが使われたとみられます。ただし、各文字の取得元までは追跡していません。
同じDoclingを使っていても、PDF内の文字を利用した結果と、ページ画像をOCRし直した結果では、比較している処理が異なります。結果を見るときは、ツール名だけでなく、「PDF内の文字を使ったのか」「OCRしたのか」「VLMで画像を解析したのか」まで一緒に確認します。
経路を決めてから、ツール候補を見る
図1でPDFの状態を分けた後、どの読み方をどの構成で試したかを見ます。次の表はツールのランキングではなく、処理経路と今回実測した構成を分けて整理したものです。
図2：処理経路と今回確認した構成
| 処理経路 | どんなときに見るか | 今回確認した構成 | ここで見ること |
|---|---|---|---|
| PDF内の文字を使う | 文字を選択・検索・コピーでき、その内容を利用できるPDF | Docling Serve 1.26.0／OCRを使わないリクエスト条件／CPU | PDF内テキストが使われたとみられる。表、ID、空欄などは原本と照らして確認する |
| OCRでページ画像から読む | スキャンPDFなど、PDF内の文字を直接使いにくい場合 | Docling Serve 1.26.0／OCRで読み直すリクエスト条件／CPU MinerU 3.4.4／CPU |
文字の有無だけでなく、ID、空欄、チェック欄、表の行と列を原本と照合する |
| VLMでページ画像を解析する | 文字に加えて、表やレイアウトなどの文書要素も扱いたい場合 | PaddleOCR-VL 1.6／VLMによる画像解析／GPU | ID、空欄、チェック欄、表やレイアウトを原本と照合する |
| ページや内容に応じて読み方を分ける | PDF内の文字と画像が混在する場合 | 状態に応じて上記の経路を使い分ける | PDF全体を一つの方法で処理すると決めない |
DoclingのOCRを使わない条件では、PDF内の既存テキストが使われたとみられます。各文字の取得元までは追っていないため、表、ID、フッター、空欄、チェック欄は原本と照らして確認します。
CPU／GPUの表記は、各ツールの対応能力ではなく、今回実測した構成のハードウェアを示しています。今回のMinerUはCPUで動かしたAPI構成を確認し、GPU構成は実測対象に含めていません。これはMinerUをCPU専用とする意味ではありません。
PaddleOCR-VLは名称にOCRを含みますが、今回確認したPaddleOCR-VL 1.6（モデル名はPaddleOCR-VL-1.6-0.9B）で用いた処理方式は、VLMによる文書解析です。この実測で使ったハードウェアがGPUでした。
今回のPaddleOCR関連の確認では、PaddleOCR-VL 1.6のGPU構成とは別に、PaddleOCR 3.7.0とPaddleX 3.7.2をCPUで動かした確認用構成も扱っています。両者はバージョン、実行環境、入力、処理方法が異なるため、同じ条件でのCPU対GPU比較ではありません。
この表は、今回用意した1ページのテスト帳票で確認した結果を整理したものです。別のPDFや構成では、結果が変わる可能性があります。
この表で決めるのは、最初にどの処理経路を1件試すかまでです。ツールの総合順位、最高精度、本番運用の可否を示す表ではありません。
今回扱っていない文書抽出エンジン
Open WebUIには、今回確認したDocling、MinerU、PaddleOCR-VL以外にも、Apache Tika、Document Intelligence、Mistral OCR、Datalab Markerなどの文書抽出手段があります。今回は、Docling、MinerU、PaddleOCR-VLを使った構成へ実測対象を絞っており、Open WebUIで利用できる全エンジンを比較したものではありません。
Azure Document Intelligenceはクラウドサービスです。Mistral OCRはOpen WebUIの既定設定ではMistral APIへ接続しますが、APIの接続先は変更でき、自前または別のMistral OCRエンドポイントを指定する構成にも対応しています。今回は、Azure Document IntelligenceとMistral OCRを実測対象には含めていません。これはクラウドとローカルの優劣や安全性を比較するものではありません。
Apache Tikaはローカルサーバーとして利用できますが、今回は未検証です。Datalab Markerも今回は未検証です。Datalabには提供側が運用するAPIのほか、自社インフラで運用する選択肢もあるため、「クラウドだから除外した」とは整理しません。これらを含めた総合順位も示しません。
認識精度の前に、処理が最後まで動いたかを見る
OCR結果が出ない場合、文字認識の性能ではなく、ファイルの渡し方や必須設定で処理が止まっていることがあります。結果が返っていない段階では、認識精度はまだ評価できません。
この別のCPU向け確認では、Open WebUIを介さず、コマンドからOCRサービスのAPIへ検証用に用意した同じPNG画像を送って確認しました。使用したのはPaddleOCR 3.7.0とPaddleX 3.7.2です。このCPU構成は、Open WebUIを通した主要経路の比較ではなく、入力条件を切り分けるための別確認です。
最初は画像の種類を示すfileTypeの指定がなく、HTTP 422（入力条件を受け付けられなかった状態）となり、OCR結果のMarkdownは返りませんでした。同じ画像について、ほかの条件を変えず、画像を示す整数のfileType=1だけを加えると、再試行なしでHTTP 200となり、レイアウト解析結果とMarkdown形式の結果が返るところまで進みました。
この例で最初のHTTP 422が示したのは、認識精度の問題ではなく、入力条件を満たす前に処理が止まったことです。fileType=1はすべてのHTTP 422に共通する解決方法ではありません。別のAPI、バージョン、入力では、それぞれの必須項目を確認する必要があります。
この確認で分かったのは、必要な入力条件をそろえると処理結果が返るところまでです。読み取った内容が正しいか、Open WebUIへ取り込んだ後に保存・検索できるか、実運用に使えるかどうかは、それぞれ別に確認する必要があります。
Open WebUIでは、どこまで確認できたかを分ける
PoCの「成功」を一語でまとめると、どこまで確認でき、何が残っているかが見えにくくなります。Open WebUIでPDFを扱うときは、一連の操作を4つに分けると、次に見る場所が分かりやすくなります。
図3：取り出す・保存する・検索する・答える
取り出す → 保存する → 検索する → 答える
記入例：保存まで確認できた場合
確認済み 確認済み 未確認 未確認
✓ → ✓ → ? → ?
└──── ここまで確認できた ────┘ └ ここから未確認 ┘- 取り出す： PDF内の文字、OCRまたはVLMによる抽出結果に、必要な内容があるか。
- 保存する： 取り出した内容が、意図した形でOpen WebUIへ保存されたか。
- 検索する： 必要な語や問いから、原文の該当箇所へ戻れたか。
- 答える： 回答が検索された原文と合っているか。
Open WebUIを介さずOCRサービスへ直接送る確認で結果を得ても、確認できたのは「取り出す」までです。Open WebUIへ保存できても、検索と回答は別に残ります。検索で見つからない場合は、OCRだけを交換する前に、取り出した内容、保存内容、検索のどこで問題が起きたのかを順に確認する必要があります。
この記事では、検索方式の比較やAI回答の採点までは扱いません。最後に成功した段階と、最初の未確認段階を一つずつ特定できれば十分です。
「だいたい読める」で終えず、原本へ戻る
文章の多くが読めても、判断に使う一文字や行の対応が違えば、用途によっては先へ進めません。とくに次の5項目は、原本の該当箇所へ戻って確認する意味があります。
| 確認項目 | なぜ見るか |
|---|---|
| ID | Oと0、Iと1など、1文字違うだけで別のIDになるため |
| 否定表現 | 「しない」「禁止」「未承認」などが抜けると、文の意味が逆になるため |
| 表 | 文字が読めても、行と列の対応がずれると内容を取り違えるため |
| 空欄 | 本当に空欄なのか、読み取れなかったのか、0やfalseなのかで意味が変わるため |
| チェック欄 | 見た目で選ばれていても、後の処理で「選択済み」と扱えるとは限らないため |
今回の実測は、これらの誤りがどの程度の頻度で起きるかを示すものではありません。
すべてを同じ深さで確認する必要はありません。そのPDFの用途で、間違えると困る項目から確認します。たとえば、文書をあとで検索できればよい用途と、IDを正確に取り出して別のシステムへ登録する用途では、確認したい項目や厳しさが変わります。
今回の検証だけでは言えないこと
この記事で使った実測は、特定の入力、バージョン、ハードウェア、処理経路、少数回の確認に限られます。別のPDFや構成では、結果が変わる可能性があります。
今回の確認だけでは、次のことまでは分かりません。
- すべてのPDF、ページ構成、バージョンでの結果や、自分のPDFに対する一般的な認識精度。
- Open WebUIの現在のバージョンで4段階を完走できることや、一般的な検索精度、AI回答の正しさ。
- 平均処理時間、大量処理、同時処理、本番運用への適合。
- ツールの総合順位や、CPU・GPUの一般的な優劣。
結果を残す際は、入力、ツールとバージョン、ハードウェア、処理経路、実行回数をあわせて記録しておくと、後から条件を確認しやすくなります。途中でバージョンや処理経路を変えた場合は、別の条件として扱います。同じPDFをさらに細かく比べても、最初に試す経路が変わらないなら、比較対象を増やしすぎず、そこで一度区切る方法も考えられます。
まず1件の確認結果を5項目で残す
確認結果は、たとえば次の5項目で残しておくと、後から処理経路と判断理由を振り返りやすくなります。候補ツールがまだ決まっていなければ、3項目目は「未定」でも構いません。
1. PDFの状態:
2. 最初に試す経路:
3. 試す候補ツール / バージョン（未定でも可）:
4. 原本で確認する項目:
5. 次の対応: 続けて試す / 条件を見直す / いったん区切る（理由: ）実際に扱うPDFを1件取り上げ、文字を選択・検索できるかを確かめ、冒頭で整理したA（PDF内の文字）、B（画像として読む）、C（ページや内容に応じて分ける）のどこから始めるかまで整理しておくと、比較対象を増やす前に、次の確認を組み立てる際の手がかりになります。
関連記事
