目次
この記事で伝えたいこと
今回いちばん反省したのは、OCRを「不確実そう」という理由だけで長く避けていたことです。
対象図面はA3固定、タイトル位置固定、判定候補も6種類程度でした。問題をそこまで限定すると、固定ROIのOCRで十分実用になることが分かりました。
さらに、一度成功したOCRを「柔軟にしよう」と一般化して壊した経験から、固定された業務仕様を無理に設定化しないことも学びました。
背景
以前の状態
OCRは認識率が100%ではなく、フォント・解像度・ノイズで結果が揺れるものだと思っていたので、できれば使いたくありませんでした。最初はPDFから直接文字を取れないかを試していました。
ここで初めて、図面で使っていた DAゴシック が、PDF上では見た目どおりの文字列として取り出せないケースがあると知りました。画面では普通に文字に見えていても、内部では文字として抽出できないことがあります。
DAゴシックはCADで使われるフォントで、公開資料でもベクトルフォント変換の文脈で扱われています。今回のPDFでも実際にテキスト抽出できなかったため、フォント内部の仕組みを無理に追うより、見えているタイトル文字をOCRする方が現実的だと判断しました。
なぜ見直したのか
CAD側のフォントを自動化のために変更すると、既存図面や他の利用者にも影響します。そこでフォントを変えるのではなく、タイトル欄の必要な文字だけOCRする方向へ切り替えました。
今回やったこと
1. OCR対象をタイトル欄だけに限定した
対象図面には、A3横固定、タイトルブロック位置共通、判定候補が限定されているという条件があります。
A3 PDF
↓
400dpiでレンダリング
↓
タイトル部分だけ切り出し
↓
RapidOCR
↓
既知の6種類へ正規化 安定したROIは400dpi時でおよそ x=5040, y=4440, width=580, height=85 でした。
2. 利用者にPython環境を作らせない
会社PCへPythonランタイムを追加する構成は避け、RapidOCRのDLLをVBAから利用する形にしました。
PDFの部分画像化にはPopplerを使い、Excel/VBAを操作基盤にしています。
3. OCR結果を即ファイル操作に使わない
OCR
↓
DrawingKindへ正規化
↓
Validation
↓
Dry Run
↓
Execute未知タイトルや認識不能は自動処理せず停止します。
実際に確認したこと
固定ROIへ戻した正常系では、6図種すべてがAUTO判定になりました。
PASS
Rows=6
AUTO=6
REVIEW=0
ERROR=0認識対象は、平面・衛生・電気・排水・展開1・展開2です。
難しかったこと・うまくいかなかったこと
OCRを試す前から避けていた
一番大きな遠回りです。汎用OCRの不確実性を、そのまま今回の限定された業務条件にも当てはめていました。
一度動いたOCRを一般化して壊した
成功後、DPI・ROI・A3判定値を設定シートから変更できるようにしました。
柔軟性を増やす改善のつもりでしたが、統合版ではOCR結果が全件空になる回帰が発生しました。
最初は広いROIへフォールバックする処理も試しましたが改善せず、最後に確実に動いていた版と比較して固定値経路へ戻すことで復旧しました。
どう判断したか
採用した方法
- A3固定・タイトル位置固定という業務制約を使う
- 400dpiの狭いROIだけをOCRする
- RapidOCR DLLをVBAから利用する
- 不確実な結果は後段へ流さない
- 成功実績のある固定値を正本として扱う
採用しなかった方法
- 図面全体をOCRする
- OCRのためにCAD標準フォントを変更する
- Python環境を利用者PCへ必須導入する
- 変動しない値をすべて設定化する
汎用性を最大化するより、固定された業務条件を利用して不確実性を減らすことを優先しました。
結果
できるようになったこと
- PDFタイトルから6種類の図種を自動分類できる
- OCR対象を狭くして処理を安定させられる
- 認識不能時に自動処理を止められる
- Python環境を前提にせずExcel/VBAから利用できる
まだ確認・改善が必要なこと
- 実運用での誤認識率
- 新しい図面テンプレートやタイトル位置変更への対応
- OCRライブラリ更新時の回帰確認
AIを使った範囲
AIに任せたこと
- OCR候補の比較
- RapidOCR DLL連携コードの初稿
- ROI・DPI・エラーの切り分け
- 過去版との差分整理
自分で判断したこと
- OCRを採用するかどうか
- A3固定・タイトル位置固定という業務条件の確認
- 成功版へ戻す判断
- 認識不能時に止める運用
- 実ファイルでの受入確認
今回の学び
- 不確実な技術ほど、小さなPoCを早く作る
- 調査だけで採否を考え続けるより、限定条件で試した方が早く判断できます。
- 技術一般の弱点と、自分の業務条件での弱点を分ける
- OCR全般が不確実でも、固定ROI・限定候補なら問題はかなり小さくなります。
- 柔軟性は価値とは限らない
- 変動しない仕様まで設定化すると、壊れる状態を増やすことがあります。
OCRで図種は取れるようになりました。次に詰まったのが、約40MBある統合DXFの処理速度でした。
まとめ
今回、見た目が文字でもPDFの中では文字データとして取れないことがあると初めて知りました。そこから、テキスト抽出にこだわるより、画面に見えている文字をOCRした方が素直だと考え直しました。
OCRも、A3固定・タイトル位置固定・候補6種類まで条件を絞れば、思っていたほど大きな問題ではありませんでした。次に似た技術へ抵抗を感じたときは、一般論で判断する前に最小PoCを作ります。