Baidu系のオープンソース文書解析ツール「PaddleOCR」が視覚言語モデル「PaddleOCR-VL-1.6」を公開し、文書解析ベンチOmniDocBench v1.6で96.3%の新記録を達成、GitHubトレンドで急上昇している。
Baidu系のオープンソース文書解析ツール「PaddleOCR」が、視覚言語モデル「PaddleOCR-VL-1.6」を公開した。文書解析の標準ベンチマーク「OmniDocBench v1.6」で96.3%という新記録を達成し、テキスト・数式・表の認識でオープンソース・商用問わず首位に立った。GitHubトレンドでも本日+141スターと急上昇している。
中核モデルは0.9B（約9億パラメータ）と軽量で109〜111言語に対応し、PDFや画像をLLM向けのMarkdown／JSON形式の構造化データに変換する。GitHubでは7万件以上の評価を集め、DifyやRAGFlowなどRAG・AIエージェント構築のOSS基盤として採用されてきた。
バージョン3.6.0として2026年5月28日に公開され、前版1.5とモデル構造が完全互換のため差し替えるだけで移行できる。日本語の表・数式・図表まで扱えるため、社内文書のデータ化を低コストで進めたい企業の現実的な選択肢になる。一方で実装者からはGPU非搭載環境での実行難易度や他OCRとの精度比較といった導入実務の論点も並行して議論されている。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
PaddleOCRはPDFや画像を、大規模言語モデル（LLM）が扱いやすい構造化データ（JSON／Markdown形式）に変換するツールで、すでに7万件以上の評価を集めている。DifyやRAGFlowなど、検索拡張生成（外部文書を参照して回答するRAG）やAIエージェントを組む有名プロジェクトの基盤として使われてきた。中核となる視覚言語モデル「PaddleOCR-VL」は0.9B（約9億パラメータ）と軽量で、109〜111言語に対応する。今回の1.6はモデル構造が前版1.5と完全互換のため、差し替えるだけで移行できる。
高精度な文書解析を、軽量かつオープンソースで使える点が大きい。閉じた商用ソリューションを公開ベンチマークで上回りつつ、端末側（エッジ）やクラウドでも動く資源効率を保っている。日本語にも対応し、表・数式・古文書・印影・図表まで扱えるため、社内文書のデータ化やAIエージェント構築を低コストで進めたい企業にとって実用的な選択肢となる。
PaddleOCR-VL-1.6は、文書解析の標準ベンチマークであるOmniDocBench v1.6で96.3%という新記録を達成した。注目すべきは、その中核モデルが0.9B（約9億パラメータ）と軽量である点だ。テキスト・数式・表の認識で、オープンソース・商用を問わず首位に立った。
このモデルはPDFや画像を、大規模言語モデル（LLM）が扱いやすいMarkdownやJSON形式の構造化データに変換する。GitHub上のプロジェクト説明は、その役割をこう端的に示している。
Turn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100+ languages.
つまり、画像やPDFとAIの間の「橋渡し」を担う、100言語超対応の軽量OCRツールキットという位置づけだ。実際には109〜111言語に対応し、日本語の表・数式・図表まで扱える。
今回のPaddleOCR-VL-1.6は、バージョン3.6.0として2026年5月28日に公開された。実装者にとって重要なのは、モデル構造が前版のPaddleOCR-VL-1.5と完全互換である点だ。新バージョンへの切り替えは、モデルを差し替えるだけで済む。
この互換性は、すでにPaddleOCRを組み込んだ既存システムにとって移行コストを大きく下げる。検索拡張生成（外部文書を参照して回答するRAG）やAIエージェントを組む有名OSSであるDifyやRAGFlowは、文書読み取りの基盤としてPaddleOCRを採用してきた。こうした基盤の上に構築済みのシステムでも、精度向上の恩恵を低リスクで取り込める設計になっている。
導入を考えるうえで、実装者の間ではすでに現実的な検証が進んでいる。X上では「paddleOCRとqwenのOCRってどっちが精度出るんだろう？」「そもそもローカルの実行環境構築は難易度高いか？ NVIDIAのグラボもない可能性高いだろうし」という声が上がっている。0.9Bと軽量とはいえ、GPU非搭載環境での実行難易度は導入前に切り分けておく論点だ。
一方で、軽量さを活かした構成報告もある。あるユーザーは「PaddleOCRとNDLOCR-liteのペアは、メモリ使用量を最小限に抑えつつ、実用的な精度と速度のバランスを確保できました」と、組み合わせによるエッジ運用の実用性を報告している。
落とし穴として注意したいのは、ベンチ数値の高さと自社帳票での精度は別物だという点だ。OmniDocBench v1.6の96.3%は標準ベンチの値であり、印影や古文書、特殊なレイアウトの社内文書では結果が変わる。まず手元の代表的な帳票数枚で実際に変換させ、表や数式の崩れ方を確認してから本格導入を判断するのが現実的だ。
立場別、明日から動ける一手。
自社の対象帳票でPaddleOCR-VL-1.6とqwen等他OCRの認識精度・処理速度を比較する。
社内文書のデータ化PoCの成功条件を、表・数式の正答率と移行コストの観点で定義する。
GPU非搭載環境での100枚処理時のメモリ使用量と処理速度を測る。
Baidu発のオープンソースOCR「PaddleOCR」がGitHub Trendingで上位をキープし、+141★/日の急上昇。最新の「PaddleOCR-VL-1.6」は約0.9Bの軽量モデルながらOmniDocBench v1.6で96.33%の新記録を達成し、文書解析のSOTAを更新した。100以上の言語に対応しPDF/画像をLLM向けのJSON/Markdownに変換できる点が注目される。X上では「軽量さと性能の両立」を評価する声、qwenのOCRなど他モデルとの精度比較、ローカル環境構築の難易度やコストに関する実務的な議論が並ぶ。
PaddleOCR-VL-1.6が文書解析ベンチOmniDocBench v1.6で96.33%を突破しSOTAを更新した点に注目が集まる。約0.9Bと軽量ながら高精度を実現し、Web版やAPI呼び出しにも対応。GitHub Trendingで上位をキープし、PDF/画像をLLM向けJSON/Markdownに変換できる実用性が「高精度かつ軽量」と評価されている。
メモリ使用量を抑えつつ実用的な精度と速度を確保できたという実装報告が共有されている。PaddleOCRとNDLOCR-liteを組み合わせ、軽量さと性能を両立した効率的な構成を実現できたという声で、エッジやリソース制約環境での運用を検討するユーザーから具体的な構成情報として支持を集めている。
PaddleOCRとqwenのOCRでどちらが精度が出るのか、という比較検討の声が上がる。同時にNVIDIA GPUを持たない環境での実行や、ローカル実行環境の構築難易度がハードルになるという懸念も。導入を検討するユーザーが具体的なモデル選定や動作要件を見極めようとしている段階の議論が展開されている。
実際にDockerでPython環境を立ててPDFをスキャンし表抽出を試した報告や、PaddleOCR-ONNXで100枚処理した際の速度計測ブログなど、手を動かした検証結果の共有が見られる。一方でGoogle NotebookLMの完成度と比較して「格差がすごい」とローカルLLM構築の労力に言及する声もあり、実務的な評価が進んでいる。
PaddleOCRがTrendingで4位をキープ。100言語対応・軽量OCRでPDF/画像をLLM向けJSON/Markdownに変換。高精度・PP Structure V3搭載。
※トレンド検出時刻付近の人気投稿を表示
PaddleOCRがTrendingで4位をキープ。100言語対応・軽量OCRでPDF/画像をLLM向けJSON/Markdownに変換。高精度・PP Structure V3搭載。
PDFをPaddleOCRでスキャンできるかな？ スキャンした結果からPDFから表を抜き出せるかな？ って思って、手元にPythonのDocker入れて、適当なPDFスキャンさせて分かったことがひとつ。 Google NotebookLMってすごい。 ローカルLLM入れて頑張ろうという気が微塵も無くなった。格差がすごい。