PaddleOCR：ページを理解するOCR page

#まず検出を行うことで何が変わるのか

PaddleOCRはApache 2.0ライセンスで公開されているオープンソースのOCRツールキットです。ページを1行ずつ読むのではなく、まずテキストの位置を探し、次に各領域を読み取り、その後、ページや表の構造を再構成できます。この仕組みにより、請求書、フォーム、傾いたスキャン、多言語文書にも強く、Tesseractのようなエンジンが自信満々に意味不明な結果を出す場面でも対応できます。プロジェクトには2つの系統があります。モジュール式パイプライン（読み取り用のPP-OCRv6と構造解析用のPP-StructureV3）と、PaddleOCR-VLです。PaddleOCR-VLは約9億パラメータの視覚モデルで、1回の処理でページをMarkdownに変換し、開発元によるとOmniDocBench v1.6で96.33%を記録しています。その代わり、PaddlePaddleとモデルの重みが必要になるため、インストールの負担は大きくなります。また、VL版にはドキュメントに記載されたGPU要件があります。読み取りやすいテキストを大量に処理するなら、軽量なエンジンの方が手軽です。

従来のエンジンは、ページが本のように並んだテキストの行で構成されていると想定しています。しかし、実際の文書はそうではありません。請求書には枠があり、フォームには入力欄があり、プレゼンテーションでは画像の上にテキストが重なり、スキャン画像は傾いていることがあり、技術図面には斜めに配置されたラベルがあります。

PaddleOCR は問題を分離します。検出モデルはテキスト領域をどこに位置していても特定し、その位置を返します。認識モデルは各領域を読み取ります。傾いたテキスト、余白のキャプション、セル内の数値は、他の領域とともに三つの領域として扱われます。これにより、行ごとに処理するリーダーが誤りを示すことなく失敗する文書でも、PaddleOCR は対応できます。

#パイプラインのステップ

すべての工程が必須というわけではありません。少数のラベルを読むだけなら、検出と認識だけで十分です。一方、文書検索のために財務報告書を取り込む場合は、パイプライン全体を使う意義があります。2026年に公開された認識モデルの世代であるPP-OCRv6は、それだけで50言語（中国語、英語、日本語、およびラテン文字を使う46言語）を単一の統合モデルでカバーしており、言語ごとにモデルを切り替える必要はありません。

#PaddleOCR-VL : OCRがビジョンモデルに進化する

2025年10月以降、プロジェクトは同じ名称の下で第二のファミリーとして PaddleOCR-VL を公開しています。これはコンパクトなビジョン・言語モデルであり、5段階の全パイプラインを単一パスに置き換えます。2026年5月末にリリースされたバージョン 1.6 は、パラメータ数が約 0.9B であり、動的解像度のビジュアルエンコーダーと小型の言語モデルを組み合わせます。ドキュメントを Markdown または JSON に変換するための標準ベンチマークである OmniDocBench v1.6 では、96.33% というスコアを達成しており、プロジェクト自身もこれを新たな最上位性能（SOTA）と位置づけています。

注目すべき点はスコアだけではありません。そのスコアを達成したモデルのサイズです。InsiderLLMが公開したガイドは、この状況を一言で要約しています。0.9Bパラメータのモデルが、文書OCRにおいて72BモデルやGPT-4oを上回ったのです。同じ記事では、汎用競合製品のメモリコストも算出されています。Qwen2.5-VL-72BはQ4量子化で48 GB以上のVRAMを必要としますが、GGUF形式に変換されQ4_K_Mで量子化されたPaddleOCR-VLは、言語モデルとビジュアルプロジェクターの重みを合わせて約1〜1.5 GBを占めます。このGGUFへの対応は比較的新しく、PaddleOCR-VLのサポートは2026年2月にllama.cpp（バージョン b8110）に統合されました。また、利用可能なGGUFファイルはPaddleOCRチームではなくコミュニティによって提供されたものです。

OmniDocBenchのスコアを出している構成要素だけが、このプロジェクトのすべてではありません。PaddleOCR-VLに加え、プロジェクトはPP-StructureV3も保守しています。これは、複雑なPDFをMarkdownまたはJSONに変換し、表の各セルと各テキストブロックの正確な座標を含めるための専用パイプラインです。両者が目指すのは、実際の文書をきれいに変換するという同じ目標ですが、その方法は異なります。PaddleOCR-VLは単一のモデルを使い、PP-StructureV3は特化したコンポーネントを連携させます。どちらのエンジンも、マルチGPUとマルチプロセスによる推論を標準でサポートしています。これは、数万ページ規模のコーパスを現実的な時間内に処理する必要がある場合に重要です。

#PaddleOCRまたはTesseract

適切に設計された処理パイプラインでは、両方を使います。単純なページは軽量なエンジンに、複雑なページはコストの高いエンジンに振り分けます。この振り分けにはコストがかからず、大規模なコーパスでは何時間もの節約になります。傾きについての記述は些細な話ではありません。請求書から情報を抽出するソフトウェアを提供するKoncileは、独自のテストで、Tesseractの読み取り率が、傾きのない請求書では100％だったのに対し、スキャン画像がわずか3～5度傾くだけで31％に低下することを測定しました。これはまさに、PaddleOCRの向き分類の工程が対応するために設計されたケースです。

• Tesseract：軽量OCRエンジンと、それだけで十分な場合
• Docling：構造化ドキュメントの変換
• 請求書データの抽出を最初から最後まで行う
• ローカルのビジョンモデルを使用して画像を分析

#使用例：PaddleOCR に切り替える場合

請求および会計

請求書のスキャン画像は、完全にまっすぐな状態で取り込まれることはめったにありません。金額が意味を保ち、単なる数字の羅列にならないように、表の構造（数量、単価、付加価値税）が読み取れる状態を維持する必要があります。

多言語行政文書

さまざまな文字体系で書かれた申請書、身分証明書、書簡。PaddleOCRは幅広い言語に対応しているため、国や文字体系ごとに別のエンジンを用意する必要がありません。

RAG用の長文レポート

見出し、小見出し、表を含む数十ページの報告書は、その構造を保って変換すると効果的です。文字数で区切るより、セクションの区切りを尊重して分割するほうが適しています。

スキャンされたアーカイブ（未整理）

箱に入った紙文書を雑にスキャンし、ページの向きもばらばらになっている場合でも、向きの分類処理が、読み取り前に乱れの大部分に対処します。

大量処理と読み取りやすいテキスト

一方、すでに適切に枠内に収まっているレシートや明細書を大量に処理する場合は、より軽量なエンジンのほうが適していることが多いです。上記のTesseractとの比較を参照してください。

#インストールして最初の抽出を実行する

インストールにはpipを使いますが、注意点があります。3.xシリーズ以降は、paddleocrパッケージだけでは不十分です。ドキュメントでは、まず選択した推論エンジン（デフォルトはPaddlePaddle）をインストールし、その後にpaddleocrパッケージをインストールするよう求めています。使用する各パイプラインの初回起動時に、検出モデル、認識モデル、必要に応じてレイアウトモデルの重みがダウンロードされます。

1. 01
   ライブラリのインストール

   まず、公式インストールページに従ってPaddlePaddleをインストールする（マシンに応じてCPU版またはGPU版を選ぶ）。続いて、python -m pip install paddleocrを実行する。基本パッケージはPython 3.8以上に対応しています。文書解析用の追加機能（paddleocr[doc-parser]）にはPython 3.9以上が必要です。
2. 02
   最初の抽出を実行

   paddleocr ocr コマンドは、-i オプションで指定した画像を入力として受け取り、--save_path で指定したフォルダに結果を書き出します。PaddleOCR-VLでページをMarkdownに変換するには、paddleocr doc_parser コマンドを使います。このコマンドでも、同じ -i と --save_path オプションを指定します。
3. 03
   必要なステップを有効にします

   use_doc_orientation_classify、use_doc_unwarping、use_textline_orientation は、ページやテキスト行の傾きなどを補正する機能を有効にするオプションです。状態のよいスキャンでは、これらを False に設定すると処理が速くなります。公式ドキュメントでも、推論が遅すぎる場合は不要な機能を無効にすることが推奨されています。

python -m pip install paddleocr
paddleocr ocr -i ./facture.jpg --use_doc_orientation_classify True --use_textline_orientation True --save_path ./output

#消費するリソース

このプロジェクトはページあたりの汎用的な処理速度を公開していません。処理速度は文書の密度、有効化された処理ステップ、およびハードウェアに依存するため、推論が遅い場合は不要な機能を無効にするか、より軽量なモデルを選択するようドキュメントで推奨されています。コーパス全体に外挿する前に、約20ページで測定してください。PaddleOCR-VLについては、公式ドキュメントでGPUの前提条件としてNVIDIA（PaddlePaddle：計算能力7.0以上かつCUDA 11.8以上、vLLM：8.0以上かつCUDA 12.6以上）を記載しており、x64プロセッサ向けのパスも用意されています。重みは一度ダウンロードすれば、以降はすべてローカルで動作します。APIもページあたりのコストもかかりません。

#決め手となる理由：内容を捏造しない

PaddleOCRはピクセルを読み取ります。文字を誤読することがあり、数字が別の数字に置き換わっても、必ずしも気づけるとは限りません。汎用の画像認識モデルに文書の書き起こしを依頼すると、形式が整っていてもっともらしく見えるものの、ページには存在しない値を生成することがあります。しかも、出力にはそれを示すものが何もありません。PaddleOCR-VLでは、さらに注意が必要です。領域ごとに文字を読み取るのではなくテキストを生成するため、書き起こし用に学習されていても、汎用の画像認識モデルと同じ種類のリスクがあります。判別が難しい文字については、どのシステムも誤りを免れません。

文書のチェック、会計、その他監査可能でなければならない用途では、この違いを基準に選ぶ必要があります。判断の根拠にする数値には専用のOCRエンジンを、文書の文字起こしよりも内容の説明を求める場合には汎用のビジョンモデルを使います。重要な文書では、両方を使って比較することも、妥当な第3の選択肢です。

実際の確認作業では、すべてを読み直す必要はありません。各バッチから数十件の文書をサンプルとして取り、エンジンの出力と手作業で比較するだけで、系統的なずれを検出できます。フィールドの範囲指定の誤り、言語の誤認識、表の分割で繰り返し起きる誤りなどを、自動処理される数千ページに影響が広がる前に見つけられます。

• 出典：GitHub上のPaddleOCR公式リポジトリ
• 出典：PaddleOCR-VL-1.6のモデルカード
• ソース：ローカル環境におけるPaddleOCR-VLの独立した比較テスト

#FAQ