DX事例
2024.08.05
開発者視点から見るAI-OCRによるペーパレス化【PART-3】
こんにちは、ペンネーム・傾奇者と申します。
今回は、AI-OCRのデータ送付編・受領についてご紹介した「開発者視点から見るAI-OCRによるペーパレス化【PART-2】」に続き、実装後の結果について詳しく解説します。今回も開発者の視点から感想を織り交ぜて詳しく記載します。
本PARTでは、申込書の取込と基幹システムの添付結果（概略図の青色点線で示された部分）について説明します。
スキャンした申込書の3カ月間の推移についてご紹介します。検証対象となるのは3月にスキャンした申込書で、その総数は986件です。申込書の動きは、3月から5月までの各月における推移を示した下図で確認できます。
3月末時点
申込書の取込総件数は986件で、その内訳はA部署が43件、B部署が943件です。A部署の取込率は約50％、B部署の取込率は約60％です。
4月末時点
A部署の取込率に変動はありませんが、B部署の取込率は約95％に向上しました。
B部署の取込率向上の主な要因は以下の通りです。
→定期保有データが取り込まれたため
→定期保有データが届かない保険会社分は手動で契約データを作成したため
→文字起こしに失敗した証券番号を手動で修正しているため
5月時点
都合上、月初めに計測したためA部署とB部署の取込率に変動はありません。
エラー件数
取込エラーの内容もご紹介します。件数を昇順で表示しています。ただし、この件数は先ほど説明した図の未取込件数を表していません。
トップには、①の基幹システムに契約が存在しないため、添付できなかったエラーがあります。これは、証券番号の文字起こしが失敗しているか、契約データが存在しないことが原因です。
②は、帳票定義に存在しない件数を示しています。
③は、証券番号と枝番で検索を行い、複数の契約データがヒットしたことを示しています。弊社では、被保険者の契約もシステムの一覧画面に表示するようにカスタマイズしているため、このような結果になっているのかもしれません。
④は、帳票定義は存在するものの、証券番号の位置を誤認している件数です。
⑤は、誰かが手動で添付していますね（笑）。いずれにせよ、添付されているので問題ありません。
この結果を見ると②④を対応するとエラーの半分くらいは解消するのでは？と思います。帳票定義はパターンの登録なのでエラー件数の100件全てを登録する必要もないですしね。
まとめ
このプロジェクトはペーパレス化の一環として始まりました。システムの構成は、ファイルのネーミングルールと帳票定義があれば、スキャナ機を使わずに基幹システムに直接取り込むことができる設計となっており、柔軟性のある構成です。この柔軟性を活かして、業務の委託先にネーミングルールに則った申込書を提供してもらい、弊社側で手動で指定フォルダに配置すると、翌日には基幹システムに添付されるという運用も行われています。
以上、AI-OCRのペーパレス化を連載形式でご紹介いたしました。弊社はビル内でもキャビネット保有数がとびぬけて多いようなので、数年後に台数が削減することを期待しています。
（編集者・傾奇者）
【連載記事】
⇒ 「AI-OCRによるペーパーレス化で業務効率化と顧客サービスの向上を実現」
⇒ 「開発者視点から見るAI-OCRによるペーパレス化【PART-1】」
⇒ 「開発者視点から見るAI-OCRによるペーパレス化【PART-2】」
お問合せ先
事例やコラムに関するご照会、案件に関するご相談やお見積は以下のフォームからお問合せください。