Entry

業務用 OCR 製品の動向とか

2010年10月28日

先日は文句しか書かなかったので,某展示会の話をもう少し。

会社がバレるとアレなので,具体的な話はできないんですけれど,先日,某展示会であたしが勤めている会社の製品を出品していたのでした。小さい会社なので,開発部門にいる人もこゆとこに駆り出されるんですね(営業的な役割は期待されていなかったが)。展示会では,自分のとこの宣伝をするのはもちろんですけれど,周りの(業界の)様子を観察できたり,エンドユーザさんの話を聴けたりするので,開発者にとっても有益だったりします。

で,ドカタ仕事の傍ら,OCR 界隈の製品群をちょっと見てきました。

紙文書を電子化したいといったニーズは,もう長らくあるわけですけれど,なかなか実用的な精度と性能を備えた製品が出ていないのが実情だったりします。お客さんは大体2方面に分かれていて,

  • 手書き文書(特に帳票系)を電子化したい
  • 既存の活字文書を電子化したい

といったところに落ち着くみたい。特に目立ったのが,帳票系の OCR 製品。アンケート用紙とか注文票のような帳票に手で書いて FAX で送る,なんて実務は,21世紀の現在でも普通に行われていることで,この手書き文書を機械で読み取りたいというわけです。

おおまかな構成としては,どの製品も,あらかじめ帳票の雛形を登録しておいて,読み取る場所を定義した後,実際に手書きの箇所を読み取るような構成になっています。何もヒントがないところから自動的に帳票の形を読み取るようなアプリケーションは,あたしが見る限りなかった。

こうした構成をとる場合,たしかに読み取る箇所を特定できるので精度は上がるんですけれど,次のような話が問題になります。

  • 帳票のレイアウトを定義するのが面倒(人でカバー)
  • 帳票に記載してある識別コードを読み取るのが大変(人でカバー)
  • (当然のことながら)未知(未定義)のレイアウトに対しては読み取れない

最後の話は当たり前なので措いておくとして,なんというか,OCR は全体の業務フローの中でシステム化された業務として位置づけるようになってきているんですね。つまり,OCR システムの中のレイアウト定義機能(サブシステム)とか帳票種別判別機能とかいった具合に。実際に文字を読み取る機能も,そのサブシステムの中のひとつという位置づけになっているようです。

ScanSnap で有名な PFU も,ScanSnap を中軸としながらも各機能をバラして任意のシステムを構築できるようなソリューションを提案していました。しかし,システム化されるということは,通常人の手が入るということで,全自動というわけにはいきません。きっと,現状で考えられる妥協点は,そこら辺なのかもしれません。

で,そうした場合,人の手がどれだけ入るかが重要なポイントになると思うんですね。なぜなら,システム内で人件費が一番お金のかかる要素だから。例えば,業務で OCR 処理を行う場合,パートさんを雇うしても時間当たり約2000円程度のコストがかかります。OCR システムを導入する場合のポイントは,結局最もコストが高くつく人件費をどれだけ圧縮することができるかにかかっている,とも言えそうです。

従来,OCR の精度を見る数字は,誤認識率のようなものを参照にしていたわけですけれど,結局どこか間違えることを前提にするなら,高コストになっているところに注力するのは自然なことだったりします。しかし,やはり個人的には,オールインワンで前処理から認識までまったく人手をかけないで済む仕組みを目指したいところ。ここまでくると,もはや趣味の領域なんですが。

展示会の OCR 界隈はそんな感じ。もちろん,かなり新しいことをやっている製品もいくつかあったんですけれど,全体的な趨勢として汎用の OCR 製品は今時の流行でないようです。みんながやってないことをやるとしたら,この逆を行けばいいということでもあるわけですが。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN