2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

不鮮明な手書き伝票はどこまで読めるか?AI-OCRライブラリとAI(OpenAI)で検証してみた

2
Posted at

はじめに

業務の中で、FAXで受信したような画質の粗い手書き帳票をデータ化したいケースがあります。
しかし、このような帳票は以下のような特徴を持っており、一般的なOCRでは精度が出にくいです。

  • 手書き文字
  • 低解像度・ノイズあり
  • 傾き・歪みあり
  • レイアウトが統一されていない

本記事では、こうした条件下でどの程度OCRが実用になるのかを検証しました。


やりたいこと

本検証では以下を目的としています。

  • 手書き・低画質・不鮮明な帳票をOCRで読み取る
  • OCRエンジンごとの精度差を確認する
  • OpenAI API(画像解析)に帳票の構造をどこまで理解させられるか検証する

検証環境

  • OS: Windows
  • Python: 3.13
  • 使用ライブラリ
    • easyocr
    • pytesseract
    • paddleocr
    • opencv-python
    • openai

※Tesseractは別途インストールが必要


使用したOCRライブラリの紹介と特徴

EasyOCR

  • Pythonから簡単に利用可能
  • Deep LearningベースのOCRライブラリ
  • 日本語を含む多言語対応
  • GPU/CPUの両方で動作可能

EasyOCRは、Python環境から手軽に利用できるOCRライブラリです。
ニューラルネットワークを用いた文字認識を行い、多言語に対応しています。
追加の設定なしでも動作するため、検証用途やプロトタイピングに適しています。

Tesseract

  • 古くからある定番OCRエンジン
  • 印刷文字には強いが、手書きには弱い
  • 多言語対応(日本語含む)しているが、日本語手書き帳票はかなり苦手
  • 詳細なパラメータ調整が可能

Tesseractは、現在Googleが開発を主導しているオープンソースのOCRエンジンです。
印刷文字を対象とした認識に強みがあり、言語モデルやパラメータを調整することで挙動を細かく制御できます。
CLIツールとしても利用可能で、他システムとの連携もしやすい構成になっています。

PaddleOCR

  • Baiduが開発している比較的新しいOCRフレームワーク
  • Deep Learningベース(検出+認識の2段構成)
  • CPU/GPUの両方で動作可能
  • GPU環境で高い性能を発揮

PaddleOCRは、文字検出(Text Detection)と文字認識(Text Recognition)を組み合わせたOCRフレームワークです。
複数の事前学習モデルが用意されており、用途に応じた選択が可能です。
また、レイアウトの異なる画像にも対応できるよう設計されています。


使用サンプル



今回のサンプルは以下のような条件で作成しています。※AI生成

  • 手書き風の文字
  • 低解像度・ノイズあり・傾きあり
  • 伝票形式(ヘッダ+明細)
  • レイアウトは固定ではない

検証スクリプトと前提

前処理について

以下の簡易的な前処理を実施しています。

  • グレースケール変換
  • ガウシアンブラー(ノイズ除去)
  • 適応的二値化

目的は、文字をより認識しやすい状態にすることです。


検証パターン

各OCRについて以下を比較しています。

  • 生画像(raw)
  • 前処理後画像(preprocessed)

さらにOpenAIについても同様に比較しています。


スクリプトの内容

スクリプトでは以下を実施しています。

  • 画像読み込み
  • 前処理
  • 各OCRの実行
  • 結果のCSV/JSON出力

OpenAI API(画像解析)の設計方針

最初は、OCR結果を固定のJSONスキーマにマッピングする設計を試しましたが、
帳票ごとのレイアウト差異に対応できず、柔軟性に欠けることが分かりました。

そのため、以下の方針に変更しました。

  • JSONキーは固定しない(可変)
  • 帳票構造(ヘッダ・明細)をAIに推定させる
  • 表形式は配列として扱う

つまり、単なるOCRではなく、帳票の構造理解をAIに任せる設計です。


結果

今回の検証では、以下の観点で比較を行いました。

  • 手書き文字の認識精度
  • 金額・数量など数字の認識精度
  • 表構造の理解
  • 実行速度
  • 前処理による改善効果

EasyOCR

EasyOCRは、全文を読み取ろうとする動きは見られましたが、
誤認識が比較的多く発生しました。

特に以下のような傾向が見られました。

  • 「FAX送信先」→「FAX造底先」
  • 「蛍光ペン」→「数光ペン」
  • 数字や記号が崩れる
  • 罫線周辺の認識が不安定

また、前処理後も大きな改善は見られず、
手書き帳票用途ではやや厳しい印象でした。

出力例(EasyOCR)

FAX造底先 o-XXXX-XxXメ' 注;文; 書一
品名・規格
85ノ-ト
数光ペン(黄)
ホ-ルペン()

Tesseract OCR

Tesseractは今回の条件ではかなり苦戦していました。

  • 手書き文字
  • 低画質
  • ノイズあり
  • 罫線あり

といった条件が重なったことで、
ほとんど読み取れないケースも多く見られました。

前処理後についても改善幅は限定的でした。

出力例(Tesseract)

2 六角ポル   3x39
AX : 06-XXXX・XXXX

今回のような「手書き + 不鮮明帳票」用途では、
活字向けOCRエンジンの限界を感じる結果となりました。


PaddleOCR

PaddleOCRは、今回試したOCRライブラリの中では
最も高い認識精度を示しました。

一方で、一部の漢字や記号には崩れも見られました。

出力例(PaddleOCR)

株式会社 関西7一ドサービス
だレパ…7(50g×10入)
紙どんぶり 大 (夕)

ただし、CPU環境では処理速度がかなり遅く、
実運用ではGPU環境やモデル常駐化などの工夫が必要と感じました。


OpenAI(画像解析)

OpenAIは、今回の検証の中で最も自然かつ高精度な結果となりました。

特に従来OCRと大きく異なったのは、
単なる文字認識ではなく「帳票構造そのもの」を理解している点です。

例えば以下のように、

  • 注文番号
  • 発注者
  • 商品明細
  • 金額
  • 合計

などを、自動的にJSONとして構造化できていました。

出力例(OpenAI)

{
  "document_type": "注文書(商品発注書)",
  "order_number": "PO-2026-0418",
  "order_items": [
    {
      "product_name_spec": "冷凍うどん(200g×5食入り)",
      "quantity": 48,
      "unit_price": "¥398",
      "amount": "¥19,104"
    }
  ]
}

また、

  • 明細を配列として認識
  • ヘッダと明細を分離
  • 金額を適切に構造化

できており、
「OCR」ではなく「帳票理解」に近い挙動でした。

一方で、

  • APIコスト
  • 外部送信
  • 完全な再現性

などの課題はあります。


結果まとめ

今回の検証結果をまとめると、以下のような印象でした。

OCR 精度 速度 特徴
EasyOCR 手軽だが誤認識多め
Tesseract × 活字向け。手書きは厳しい
PaddleOCR 高精度だが重い
OpenAI 構造理解まで可能

特に、レイアウトが固定ではない帳票に対しては、
従来OCRの「文字認識」だけでは限界があり、
AIによる構造理解の有効性を強く感じる結果となりました。


所感

EasyOCR

全文を読み取ろうとする動きは見られましたが、
手書き文字に対する精度は低く、実用にはやや厳しい印象です。
前処理による改善も限定的でした。


Tesseract

今回の条件(手書き・低画質)ではほとんど読み取れず、
実用性はほぼありませんでした。
印刷文字前提のエンジンであることを考えると妥当な結果です。


PaddleOCR

EasyOCRよりも精度は高く、比較的まともに読めるケースが多かったです。
ただし、CPU環境では処理速度が遅く、
そのまま業務に適用するには工夫が必要です。

※モデル初期化時間が大きいため、常駐プロセス化などが前提になります。


OpenAI(画像解析)

精度・速度ともに非常に優秀でした。

特に以下の点が従来OCRと大きく異なります。

  • 帳票の構造を理解する
  • ヘッダ項目と明細を区別する
  • 表形式を配列として返す

つまり、「文字認識」ではなく
「帳票理解」まで行っている点が強みです。

一方で、以下の課題があります。

  • APIコスト
  • 外部送信のセキュリティ
  • 完全な再現性が保証されない

改善ポイント

1. 前処理の強化

今回の前処理は最低限のため、以下の追加で改善余地があります。

  • 傾き補正(deskew)
  • 罫線除去
  • コントラスト強調
  • ノイズ除去の最適化

2. セル単位の切り出し

帳票レイアウトが固定またはある程度パターン化できる場合は、

  • 項目ごとに領域を切り出す
  • 項目ごとにOCR設定を最適化する

ことで精度が大きく向上します。

ただし、レイアウトが不定の場合は運用コストが高くなります。


3. PaddleOCRの高速化

  • GPU環境を利用する
  • モデルを常駐化する
  • 画像サイズを最適化する

4. AI-OCRのチューニング

AI-OCRライブラリは学習による精度向上も可能ですが、
今回のような「手書き・低画質・不定レイアウト」の帳票では、
十分な学習データとチューニングコストが必要になります。

特にPaddleOCRは学習・Fine Tuning前提の構成になっており、
帳票形式をある程度固定できる場合は精度向上が期待できそうです。


5. AI活用(コストとのトレードオフ)

OpenAIのようなモデルを使うことで、

  • 精度
  • 柔軟性
  • 実装コスト

を大幅に改善できます。

今回使用した軽量モデル(例: gpt-4.1-mini)でも、
十分実用的な精度が確認できました。


コスト試算(参考)

仮に1枚あたりの処理コストを約0.01ドル(約1.5円)とすると、

  • 月1000枚 → 約1500円/月

程度になります。

※実際のコストは画像サイズやトークン量に依存


結論

  • 従来OCRは手書き・低画質帳票では限界がある
  • 前処理や切り出しで改善は可能だが、コストがかかる
  • OpenAIは構造理解まで含めて非常に強力
  • ただしコストと運用要件を考慮する必要がある

今回のような条件では、

少量・高精度が求められる場合はAIが最も現実的な選択肢

と感じました。


おわりに

今回の検証を通して、OCRは単なる文字認識ではなく、
「どこまで構造を理解できるか」が重要であると感じました。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?