RapidOCR で PP-OCRv6-small の日本語・英語 OCR を試す

Last updated at 2026-09-23Posted at 2026-07-12

RapidOCR で PP-OCRv6-small の日本語・英語 OCR を試す

こんにちは、皆さん。

画像の文字を読み取る OCR は便利ですが、「読めたように見える結果」をどこまで信用してよいかは気になります。

さて、今日は RapidOCR から PP-OCRv6-small を実行し、日本語と英語が混ざった画像を CPU でどこまで読み取れるか検証しました。

先に結果を書くと、代表的な14文字列のうち、完全一致は12件、表記差を許容すると13件を認識できました。縦書き、斜めの住所、小さいメールアドレスも読めています。

今回検証する内容

PP-OCRv6 は、画像内の文字領域を見つけて文字列へ変換する OCR モデル群です。今回は tiny、small、medium の3段階のうち、精度と軽さのバランスを狙った約770万 parameters の small を選びました。parameter は、モデルが学習によって得た調整値です。

RapidOCR 3.9.1 と ONNX Runtime の CPU backend を使い、次の点を確認します。

PP-OCRv6-small の検出・認識モデルを明示して実行できるか
日本語、英語、数字、記号、縦書き、斜めの文字を読み取れるか
モデル初期化を除いた OCR pipeline 全体の処理時間
認識結果の信頼度と、実際の正しさが一致するか

検証には、次の固定画像を使用しました。横書きだけでなく、縦書き、小さい文字、斜めに置かれた文字を含んでいます。

対象の lab: kiarina/labs/2026/07/12/pp-ocrv6-small-rapidocr

検証環境の再現

mise と uv、初回の共有画像取得にインターネット接続が必要です。

git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/kiarina/labs.git
cd labs
git sparse-checkout set .mise/tasks 2026/07/12/pp-ocrv6-small-rapidocr
mise trust . && mise trust 2026/07/12/pp-ocrv6-small-rapidocr
mise -C 2026/07/12/pp-ocrv6-small-rapidocr run

実行すると、全認識文字列、信頼度、座標、速度を標準出力へ表示し、文字領域を描画した output_ocr.jpg を生成します。

使用したモデルとライセンス

RapidOCR の wheel に同梱された次の3モデルを使いました。

段階	モデル	役割
1. 検出	`PP-OCRv6_det_small.onnx`	画像から文字がある領域を見つける
2. 方向分類	`ch_ppocr_mobile_v2.0_cls_mobile.onnx`	切り出した文字領域の上下を判定して補正する
3. 認識	`PP-OCRv6_rec_small.onnx`	補正した領域を日本語などの文字列へ変換する

データの流れを短く表すと、次のようになります。

入力画像
  -> 文字領域を検出
  -> 領域ごとに切り出し
  -> 文字の向きを補正
  -> 文字列と信頼度を出力

検出と認識には PP-OCRv6-small、方向分類には RapidOCR の標準モデルを使っています。推論はすべて ONNX Runtime の CPUExecutionProvider で実行しました。

モデルの再配布や製品への組み込みでは、ライセンス本文、著作権表示、依存物の条件を利用時点で確認してください。

検証方法

入力は、室内に日本語・英語、ホワイトボード、縦書きの本、PC画面、小さい連絡先、斜めの封筒を配置した固定の生成画像1枚です。

file: tests/assets/jpg/ocr_1448x1086_242kb.jpg
resolution: 1448x1086
SHA-256: 42d9024588f112ab9fbaf69c0e32a95462613c35b9cdbbb1a9c4bc1ff93ab96e

OCR 結果から代表的な14文字列を選び、記号と空白を除いて一致を確認しました。複数の領域に分割された文は、各部分が含まれていれば一致としています。

速度は、モデル初期化と最初の推論を測定から外しました。3回の warm-up 後、読み込み済みの同じ画像を pipeline 全体へ10回入力しています。warm-up は、初回だけ発生する準備処理の影響を減らすための事前実行です。

検証結果

次の画像は、左側が検出領域を重ねた元画像、右側が認識した文字列を配置した結果です。

Mac Studio（Apple M4 Max）の CPU で実行した結果です。

detected lines:       40
representative match: 12/14
mean confidence:      0.984
min confidence:       0.883
max confidence:       1.000

average time:         839.01 ms
min time:             758.89 ms
max time:             890.43 ms
standard deviation:    37.32 ms

representative match は、文字種の違いも区別する自動チェックの完全一致です。ノート の長音符がハイフンになった1件を、意味を読み取れている結果として許容すると13/14件です。

同じ環境で記事作成時に再実行したところ、完全一致12/14件と信頼度は同じで、速度は平均920.47 ms（最小835.24 ms、最大1090.61 ms）でした。839.01 msは固定された性能値ではなく、実行ごとに変動する参考値です。

信頼度は、モデル自身が認識結果をどれくらい確からしいと見積もった値です。1.000に近いほど高い評価ですが、正解を保証する値ではありません。

代表文字列の結果は次のとおりです。

種類	期待した文字列	結果
日本語	`OCR テストルーム`	PASS
英語	`Please knock before entering`	PASS
数字	`12345`	PASS
日本語・数字	`在庫確認：ノート12冊／ペン24本`	ACCEPT（長音符の表記差）
英語・記号	`Next review: Friday, 3:45 PM`	PASS
小さい日本語	`忘れずに水やり`	PASS
小さい英語	`Call Ken at 18:00`	PASS
縦書き日本語	`日本語の練習`	PASS
縦書き英語	`Deep Learning Basics`	PASS
日本語	`取扱注意`	MISS
英語	`FRAGILE`	PASS
斜めの日本語	`東京都千代田区1-2-3`	PASS
小さいメール	`test@example.com`	PASS
小さい電話番号	`03-1234-5678`	PASS

自動チェックで完全一致しなかった箇所は次のとおりです。

expected: 在庫確認：ノート12冊／ペン24本
actual:   在庫確認：ノ-ト12冊／ペン24本
score:    0.947

expected: 取扱注意
actual:   取极注意
score:    0.883

ノ-ト は長音符の文字種が違いますが、単語と文全体は読み取れているため、記事では認識成功として扱いました。明確な誤認識は 取扱注意 の1件です。

集計対象外では、Project Alpha が Project Alpi と認識されました。ただし、元画像では末尾の a 付近が鉛筆で隠れています。完全な文字列を読み取れない条件なので、これはモデルの明確な失敗とは扱いません。

検証環境は次のとおりです。

machine: Mac Studio (Apple M4 Max, arm64)
OS: macOS 26.5.1
Python: 3.12.10
RapidOCR: 3.9.1
ONNX Runtime: 1.27.0
OpenCV: 5.0.0

結果の考察

専門的な数値は上に載せたとおりですが、簡単に読むと次の3点です。

文字の向きや大きさが違っても、多くは読めた

横書きだけでなく、縦書きの日本語と英語、斜めの住所、小さいメールアドレスと電話番号も一致しました。固定画像1枚の結果ではありますが、文書以外の画像にも使える可能性を確認できました。

評価基準によって結果の見え方が変わる

完全一致だけなら12/14件ですが、ノ-ト を意味の通じる表記差として許容すると13/14件です。一方、取扱注意 が 取极注意 になった結果は意味にも影響するため、誤認識としました。用途に応じて「一字一句の一致が必要か」「内容を理解できればよいか」を決めて評価する必要があります。

CPUで1枚約0.84秒だった

1448x1086画像の検出、方向分類、認識、前後処理を含め、記録した2回の平均は839.01 msと920.47 msでした。大量処理やリアルタイム用途では追加の計測と最適化が必要ですが、手元の画像を順番に処理する用途なら扱いやすい速度に感じます。

今回は読みやすい生成画像1枚だけを使っています。一般的なOCR精度を示す結果ではありません。手書き、低照度、ぼけ、強い歪み、さらに小さい文字、別フォント、tiny・mediumモデル、GPU backendは未検証です。また、速度は実行環境や ONNX Runtime の最適化で変わります。

検証後の感想

RapidOCR は、検出・向き補正・認識の3段階をまとめて呼び出せるため、ONNX の OCR を試す入口として使いやすい印象でした。縦書きや斜めの文字まで読めた結果は、予想より良かったです。

ノ-ト のような表記差なら、検索や内容理解には十分使えそうです。一方、取扱注意 のように文字そのものが変わる場合もあります。LLM エージェントへ組み込むなら、OCR結果を確定情報ではなく観測のひとつとして持たせ、重要な値だけ再確認する仕組みと組み合わせたいです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up