エージェントに「ローカルの目」を：PP-OCRv6 ブラウザ版 OCR 実践ガイド

Baidu Paddle が次世代 OCR モデル、PP-OCRv6 を正式リリース。

Tiny、Small、Medium の 3 つのモデルサイズを提供し、50 以上の言語に対応。ブラウザサイド、組み込みデバイスからサーバーまで、あらゆるシーンをカバーします。

コアデータ：

• テキスト検出および認識タススコア：86.2 と 83.2
• OCR 総合性能（検出 + 認識）で世界 No.1。Qwen3-VL-235B、GPT-5.5、Gemini-3.1-Pro などの汎用視覚言語モデルをリード
• Tiny モデルはわずか 1.5MB、1 枚の画像予測を 97ms（CPU）で実行。ブラウザ環境でも動作可能
• UmiOCR や MinerU などのツールにすでに統合されており、GitHub スター数は 82,200 を超える

今回は、「地獄級の難易度」の画像 3 枚を使って、その実力を検証しました。

OCR 認識率が 68% しかないと、どうなるのか？

次のシナリオを想像してみてください。

英文と中文が混在する条項、金額、法律用語が含まれる金融契約書。

Tesseract で OCR を実行したところ、認識率は 68% でした。

3 分の 1 の内容が誤っています。

その後に行う LLM 分析、リスク抽出、自動アーカイブは、すべて誤ったデータに基づいて進められることになります。

これは Tesseract 自体の問題ではありません。

従来のオープンソース OCR が抱える共通の課題です。複雑なレイアウト（数式、表、印鑑、多言語混在）では、テキスト認識率が一般的に 70% を下回ります。引用

さらに悪いことに、「GPT-5.5 で OCR をやればいいのでは？」と考えるかもしれません。

235B のパラメータを持つモデルでも、高性能 GPU 上で 1 枚の画像認識に 2 秒かかり、有料で、精度も「まずまず」です。

PP-OCRv6 は何を実現したのでしょうか？

Tiny モデルはわずか 1.5MB で、ブラウザサイド（CPU）で 97ms で処理を完了。Medium モデルは 34.5M パラメータで、OCR 認識精度は 90% 以上。テキスト検出と認識の両方で、GPT-5.5 や従来のすべてのオープンソース OCR を凌駕します。

データは嘘をつきません。

この 10～20 パーセントポイントの差が、「使える」と「使えない」の分かれ目です。

実際に「地獄級の難易度」の画像 3 枚でテストした結果がこちらです。

テスト 1：暗い背景 + 密集した小さな文字

これは OCR にとって地獄級の難易度です。

テクノロジー系のポスターでテストしました。暗いネオン背景、光るデータパネル、密集した日中英混在テキスト、様々なフォントサイズが混在しています。

このような画像は、多くの OCR が惨敗するケースです。

テスト結果：

✅ メインタイル「Mastering Codex」「Master 97% of functions in 30 minutes」— 光るフォントも、一文字も欠かさず認識

✅ 小さなラベル「14 steps」「Skills」「MCP Connection」— 暗い背景の小さな文字も全て復元

✅ 統計数値「98%」「1200+」「85%」— 全て正確に認識

✅ 下部の詳細「Efficient Intelligent Data Processing Capability」— 最も小さなフォントサイズも認識

✅ 日中英混在テキストを、単一モデルで一度に処理

認識速度：

オンライン認識で約 1～2 秒（ネットワークアップロード時間を含む）

結論： 複雑な背景 + 発光効果 + 超小文字 + 日中英混在という 4 つの難題を同時にクリアしました。この「視力」は、Agent の目として十分に機能します。

テスト 2：財務請求書

実際のビジネスシナリオです。

次に、VAT 請求書をテストしました。これは企業にとって最も一般的な OCR 要件であり、データを絶対に外部に出せないシナリオです。

認識効果：

✅ 請求書コード/番号 031002200711、59905674 — 超小文字も 100% 正確

✅ 複雑な数字列 1+3-887•97•-9642-6-62967770 — 特殊記号を含む長い文字列も、一つの誤りもなく認識

✅ 金額 ¥535.00、¥504.72、¥30.28、税率 6% — 正確に認識

✅ パスワードエリアの長いランダム文字列 — 完全に復元

✅ 購入者/販売者名、税 ID、住所、電話番号 — 全て正確

✅ 赤い印鑑の中のテキストも認識（赤い円の干渉があっても）

最も驚いた点：

請求書上の極めて小さなフォントサイズ（おそらく 8～10 ポイント）、密集した数字、特殊記号（•, -, +）を、PP-OCRv6 はすべて正確に認識しました。この精度は、従来の OCR では到達できません。

重要な発見：構造的抽出能力

各フィールドの座標位置を返すことができるため、構造化抽出を直接実行できます。

1// 座標位置に基づいてフィールドタイプを判別
2results.forEach(item => {
3  if (item.box.y < 100) {
4    // 上部エリア → 請求書コード/番号
5  } else if (item.text.includes('¥')) {
6    // 通貨記号を含む → 金額フィールド
7  }
8});

この機能により、PP-OCRv6 は単に「テキストを見る」だけでなく、「文書構造を理解」することができます。これは OCR から Document AI への重要なステップです。

テスト 3：手書きメモ

ストレステストです。

最後に、手書きメモをテストしました。これは従来の OCR にとっての課題です。乱雑な筆跡、続け字、紙の折り目などがあります。

テスト結果：

✅ 日付認識「2025 年 8 月 30 日」— 完全に正確

✅ 手書き本文「今日は一日家にいて、ダンスを2回サボった」— 乱雑な「那」という文字も認識

✅ リフォームリストを完全認識：

• 「ハード装飾 109k」「エアコン 3 台：26k」「ガラス 3 枚：11.5k」
• 「家電 180k」「給湯器：3000」
• 「コンロ/レンジフード：7000」「洗濯機/乾燥機：5000」
• 「冷蔵庫 3000」 ✅ 複雑な数字「今日 44k 送金（冷蔵庫含む）」「現在：214.5k」— 手書きの数字と金額がすべて正確に認識

認識率評価：

• きれいな手書き：約 90% の認識率
• キー情報（日付、プロジェクト名、金額）：ほぼ 100%
• 乱雑な筆記体部分：約 70～80% の認識率だが、全体の理解には影響なし

予想外の発見：

手書きであっても、PP-OCRv6 は構造化情報（日付、金額、リスト）に対して高い認識能力を発揮します。これは、手書きのフォーム、請求書、会議メモなどに活用できることを意味します。キーとなるフィールドを捉えられれば、100% の正確性は必要ありません。

結論：

PP-OCRv6 は万能ではありません。極めて乱雑な手書き文字は依然として課題です。しかし、きれいな手書き、印刷テキスト、鮮明なスクリーンショット、スキャン文書については、商用グレードの性能を発揮します。

どのようなシナリオでローカライズ（オンプレミス処理）が必要か？

PP-OCRv6 のアプリケーションシナリオは、企業オフィス、ヘルスケア、教育/研究、開発者ツール、政府アーカイブ、E コマース、金融/保険をカバーしています。

いくつかの代表的なシナリオをご紹介します。

💼 企業オフィス：出張費の自動精算

ある製薬会社では、PP-OCR を組み込んだことで、出張旅費精算の時間を 5.3 日から 4.2 時間に短縮しました。引用

プロセス：

従業員が請求書をアップロード → ブラウザサイドでフィールド抽出（金額、日付、業者） → ルール検証 → 例外を LLM に送信 → 自動記帳。

なぜローカライズが必要なのか？

財務証憑には、仕入先、価格、原価構造などの業務データが含まれており、サードパーティ API へのアップロードはコンプライアンス上のレッドラインです。ローカライズにより、データはブラウザ内に留まります。

🏥 ヘルスケア：電子カルテ

カルテには患者のプライバシー情報（氏名、ID、病状）が含まれており、パブリッククラウドにアップロードすることはできません。

ソリューション比較：

• 従来のプライベートデプロイ：コスト高、メンテナンス負荷大
• PP-OCRv6 ブラウザサイド：直接実行、サーバーコストゼロ

プロセス：

スキャナーがカルテ画像をアップロード → ローカル OCR 認識 → データを匿名化して保存。元のデータはオペレーターのコンピューターから出ません。

⚖️ 法律契約：企業秘密の保護

法律事務所の AI アシスタントは、契約条項（当事者、金額、条件、責任）を抽出する必要があります。しかし、契約は顧客の核心的な企業秘密です。

ローカライズプロセス：

契約スキャンをアップロード → ブラウザサイド OCR で全文抽出 → ローカル LLM が条項抽出を実行 → レビューレポートを生成。データは弁護士のワークステーションから出ることはなく、弁護士・依頼者間の秘匿義務を満たします。

このシナリオでは、ローカライズが「可能」と「不可能」の分かれ目です。

実際のフィードバック：

ある法律事務所の開発者は、PP-OCRv6 にアップグレードした後、「速度と効果は V5 よりも確実に優れている」と報告しています。事件ファイルのフォーマット整形や匿名化に直接使用されています。引用

💻 開発者ツール：スクリーンショットからテキストへ

開発者は、デザインカンプ、ドキュメント、ログからテキストを抽出する必要がよくあります。クラウド API にはネットワークレイテンシ（200～500ms）、呼び出し制限があり、コードスニペットは外部送信に適していません。

ローカライズされた体験：

スクリーンショット → ホットキー → ローカル認識 → 貼り付け。全プロセスが 200ms で、インターネットは不要です。OCR が「API を待つ」ことから「ホットキーを押す」ことへと変わり、ワークフローの一部になります。

📚 その他のシナリオ

教育/研究： 採点補助、学術文献のデジタル化、手書きノートの整理。

政府アーカイブ： 歴史的アーカイブのデジタル化、ID 情報抽出、文書フロー。

E コマース： 商品情報入力、物流伝票認識、請求書検証。

金融/保険： 保険証券情報抽出、銀行明細認識、リスク管理資料処理。

完全なローカライズ Agent ループ

PP-OCRv6 の価値は、「正確な認識」だけではありません。「この認識ステップにインターネットが不要である」ことです。

ブラウザで動作するということは、データがローカルから決して出ないループを構築できることを意味します。

1ローカル画像/スクリーンショット
2   ↓
3PP-OCRv6（ブラウザサイド、97ms）   ← データはこのマシンから出ない
4   ↓
5構造化テキスト
6   ↓
7ローカル LLM / ローカルルール処理
8   ↓
9自動分類 / フォーム入力 / 保存

このループでは、画像と認識結果の両方がユーザーのデバイス上に留まります。機密性の高い証憑を扱うシナリオでは、これは単に「より良い」というだけでなく、「可能」と「不可能」の差を意味します。

以前は、このような要件には高価なプライベートデプロイが必要でした。今では、ブラウザを開くだけで実行できます。

これこそが、「Agent にローカルの目を与える」ことの真の意味です。Agent はついに「見る」ことができるようになり、しかもその「見る」プロセスで、目を他人に貸す必要がありません。

使用方法：3 つの統合方法

方法 1：オンライン体験（0 分で開始）

最も簡単な方法は、paddleocr.com にアクセスして画像をアップロードし、効果を確認することです。

適している用途： 機能のクイック検証、特定の画像のテスト。

制限事項： データはサーバーにアップロードされるため、機密コンテンツには適していません。

方法 2：ブラウザサイド統合（推奨）

ローカライズ（オンプレミス処理）が必要な Web アプリの場合は、PaddleOCR.js を直接統合します。

1// 1. インストール
2npm install paddleocr-js
3
4// 2. モデルを初期化
5import { createOCR } from 'paddleocr-js';
6const ocr = await createOCR({
7  detPath: '/models/det_tiny.onnx', 
8  recPath: '/models/rec_tiny.onnx',
9  dictPath: '/models/dict.txt'
10});
11
12// 3. 画像を認識
13const results = await ocr.recognize(imageElement);

主な利点：

• モデルファイルは一度読み込めば、その後の認識にネットワークは不要。
• 1 枚の画像認識は 97ms から開始（CPU、公式データ）。
• 文字単位の座標を返し、詳細なレイアウト復元が可能。

適している用途： ブラウザ拡張機能、Web アプリ、Electron デスクトップアプリ。引用

方法 3：Python ローカルデプロイ（高精度シナリオ）

最大限の精度が必要な場合やバッチ処理を行う場合は、Python SDK を使用します。

1# 1. インストール
2pip install paddleocr paddlepaddle
3
4# 2. 最高精度のために medium バージョンを使用
5from paddleocr import PaddleOCR
6ocr = PaddleOCR(use_angle_cls=True, lang='ch')
7
8# 3. バッチ認識
9result = ocr.ocr('invoice.jpg', cls=True)

高度な活用：

• NER モデルと組み合わせてフィールド抽出。
• ローカル LLM に接続して、完全なドキュメント理解 Agent を構築。
• FastAPI でラップして内部 API とし、チームで共有。

適している用途： サーバーサイドのバッチ処理、高精度要件、二次開発。引用

技術的な深掘り：なぜ 34.5M の OCR モデルが 235B の汎用モデルより正確なのか？

大規模モデルが数千億のパラメータを持つ時代に、PP-OCRv6 はわずか 34.5M パラメータで、Qwen3-VL-235B、GPT-5.5、Gemini-3.1-Pro よりも高い精度を達成しています。なぜでしょうか？

統合ベース：1 つのアーキテクチャで 2 つのタスク

PP-OCRv6 の核心的な革新は、LCNetV4 バックボーンネットワークです。これは検出と認識の両方に使用されます。

処理の違い：

• 検出：通常の画像スケーリングで特徴を抽出し、テキストの位置を特定。
• 認識：高さを圧縮し、幅を保持することで、テキスト画像をシーケンスに変換し、文字を一つずつ読み取ります。

同じアーキテクチャコードが 3 つのサイズ（Tiny/Small/Medium）で機能するため、開発とメンテナンスのコストが大幅に削減されます。

重要な理由： この「統合ベース」設計は、従来の 2 つの独立したネットワークよりも軽量で強力です。

より正確な検出：大規模な受容野を持つ特徴ピラミッド

PP-OCRv6 は大規模な受容野を持つ特徴ピラミッドを使用し、「視野範囲」を 3x3 から 7x7 に拡大しています。

効果： パラメータは少ないものの、小さく密集したテキストの検出が大幅に向上。

より強力な認識：軽量アテンション + 50 言語を 1 モデルで

認識部分には軽量アテンションモジュールが追加され、文字間のコンテキストを理解します。また、辞書はアクセント記号付きの文字を含めて約 200 文字拡張されました。

重要なブレイクスルー： 単一モデルで中国語、英語、日本語、および 46 のラテン系言語（合計 50 言語）を認識可能。言語ごとにモデルを切り替える必要はありません。

重要な理由： 多言語混在シナリオ（例：中国語の条項を含む英語契約書）にとって、質的な飛躍です。

パフォーマンスデータ：特化モデルの優位性

PP-OCRv6_medium はわずか 34.5M パラメータですが、PaddleOCR チームによる社内マルチシナリオテストでは、その OCR テキスト認識精度が Qwen3-VL-235B（2350 億パラメータ）、GPT-5.5、Gemini-3.1-Pro を上回りました。引用

なぜか？ 垂直タスクにおいては、特化モデルは依然として汎用大規模モデルよりも効率的です。VLM は文書理解、推論、生成のバランスを取る必要があり、OCR はそのサブタスクの 1 つに過ぎません。PP-OCRv6 は、「テキストをはっきりと見る」ことだけに特化して、アーキテクチャからデータトレーニングまで最適化されています。

主要データ：

• 認識精度 83.2%、前世代から 5.1% 向上。
• 検出 Hmean 86.2%、前世代から 4.6% 向上。
• GPU 推論速度が 2.37 倍に向上。

VLM の致命的な欠点：幻覚による訂正

VLM のようなマルチモーダルモデルは、OCR を処理する際に致命的な欠点があります。言語的な事前知識に基づいた「幻覚的な訂正」 です。

例：画像に「Welcme」（タイポ）と書かれている場合、GPT-5.5 は「スマートに」「Welcome」と訂正してしまう可能性があります。

文字通りの復元が必要なシナリオ（法的文書、コードスクリーンショット、製品シリアル番号）では、この「スマートさ」は致命的です。

データ比較：

• PP-OCRv6 完全一致率：93.2% — 画像内のすべての文字を忠実に復元。
• Qwen3-VL-235B 完全一致率：80.6% — 画像に存在しないテキストを「補完」する傾向がある。

この 12.6 パーセントポイントの差は、正確な復元が必要なシナリオでは、特化型軽量モデルが汎用大規模モデルよりも信頼性が高いことを意味します。

PP-OCRv6 の設計思想は「視覚コンテンツを忠実に復元する」ことであり、言語モデルに基づいた推測は行いません。公式比較によると、工業用文字、ドットマトリクステキスト、タイヤ痕などを処理する際、VLM は明らかな幻覚を生成する一方、PP-OCRv6 は元の文字を正確に認識します。引用

3 モデルの選択アドバイス

PP-OCRv6 は、エッジデバイスからサーバーまでをカバーする 3 つのティアを提供します。

選択アドバイス： ブラウザサイド Agent は Tiny/Small から始めるのが良いでしょう（十分な性能と高速ロード）。バックエンドのバッチ処理には Medium を使用します。引用

コスト比較

クラウド API は従量課金制（月 10 万画像あたり約 200～1500 元）ですが、ローカライズモデルは無料のオープンソースで、ランニングコストはゼロ、同時実行制限もなく、オフラインでも動作します。

最後に

OCR は長年にわたって競争が続いてきました。精度はもはや希少価値のあるものではありません。希少なのは、データを渡さずにテキストを正確に見ることです。

PP-OCRv6 はこれを、ブラウザ内での 97ms の呼び出し（Tiny モデル、CPU）で実現しました。Agent を構築する皆さんにとって、これは「画像読み取り」機能を、「ゼロデータ漏洩」を約束する製品にようやく組み込めることを意味します。

Agent にローカルの目を与えることは、あの一行のクラウド OCR 呼び出しを置き換えることから始まるかもしれません。

関連リソース

• PaddleOCR 公式サイト： paddleocr.com
• GitHub： github.com/PaddlePaddle/PaddleOCR
• HuggingFace： huggingface.co/collections/PaddlePaddle/pp-ocrv6
• オンライン体験： paddleocr.com（画像を直接アップロードしてテスト可能）

テクニカルペーパー： PP-OCRv6: From 1.5M to 34.5M Parameters, Surpassing Billion-Scale VLMs on OCR Tasks (arXiv:2606.13108)

👉 この記事が役に立ったなら、いいね、フォロー、ブックマークをお願いします！